auto_control

230 Commits 2 Branches 6 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
butubb	34a03db1b9	feat(条件判断): 支持「选中元素 → 拿它的文本和设定的值比」（等于/不等于/包含/不包含）需求原话：条件判断需要能选择元素，比如我设置了一个抖音号，让它采集这个元素的文本和我设的值做条件判断。原来的条件判断只会判「元素在不在」（找到走 then、没找到走 else），没法判"内容对不对"。现在加两个可选参数： - `cmp_op`：等于 / 不等于 / 包含 / 不包含（`==`/`!=`/`contains` 这类别名也认）；留空 = 老行为，完全向后兼容（现有任务不用改）。 - `cmp_value`：要比对的值。填了就变成：先按选择器取到元素文本 → 和 cmp_value 比 → 比对结果才是命中与否。用户那个例子就是：元素 `com.ss.android.ugc.aweme:id/506` 的文本是 `抖音号：35377983067`，选「包含」、值填 `35377983067` 即可；要抓"登录的不是这个号"就用「不等于」。 - 读取只走 `get_text()`（只读，2 秒超时），不点击、不改状态。 - 两条防误判规则（都写进文档了）： · 元素没找到时一律算未命中（走 else）——"没读到"绝不能被当成"和我设的不一样"，否则界面还没加载出来就会误判成"账号被换了"； · 元素在但文本为空时按空文本参与比对（用于抓"栏位是空的"），日志会打出实际读到的值。 - 比对不污染「选择器健康」统计：统计用的仍是"元素在不在"——"找到了但值不对" 是条件按预期走了 else，不是选择器失效，不该攒出「连续未命中」告警。 - 支持比对的类型：所有元素类选择器 + `foreground`（比前台包名）+ `ocr`（比 OCR 命中的那段字）。 `screen`（亮/熄）没有文本可比，设了会忽略并告警。 - 前端：条件判断面板多一块「文本比对」（运算符下拉 + 比对的值），只在元素/OCR/前台App 条件下出现；保存前校验"选了运算符却没填值"和"screen 上设了比对"。 - AI 建任务草稿校验（`core/task_draft.py`）同步拦"运算符拼错""有运算符没值"—— 执行器对认不出的运算符是"一律不命中"，不拦就会变成悄悄走 else。自测：比对函数 16 项（含别名、空值、None、拼错运算符）、`_exec_if_el` 全分支 20 项（含"没找到+不等于"这个关键边界、健康统计用存在性、screen 忽略比对、u2 抛异常不炸）、真机验证（cs1 上真读一个 TextView 的文本再比对：包含/等于/不等于全对，元素不存在时不误判）、草稿校验 5 项、GET 路由冒烟 55 个 0 个 500。（测试里踩到一个坑记一笔：u2 的 `XPathSelector.exists` 是纯 bool 属性，而 `UiObject.exists` 是"可调用的 Exists 对象"（`bool()` 即时判断、`exists(timeout=)` 带等待），两套语义不能想当然统一——单测的假设备一开始没模拟对，是测试写错了不是代码写错了。）	2026-09-24 09:22:32 +08:00
butubb	46e6ea1f37	feat(AI 建任务): AI 自己在真机探索 → 写出可调度任务 → 人工确认入库 AI 控制台下新增子分栏「🧭 AI 建任务」：描述要做什么（例：建一个跑 2 小时的任务、自动刷某 App、随机点赞），AI 用 de_* 工具自己在设备上探索（看屏/读元素树/点按验证），把走通的路径写成一条任务草稿，经服务端校验后交人在步骤编辑器里核对/手改/试跑，保存才入库。链路：POST /api/agent/run{mode:"designer", settings} → Agent 自探 → 本地工具 submit_task(draft) → core/task_draft 校验（失败把 errors 回灌模型让它改） → 只暂存（运行态 + app_meta.agent_task_draft，不落库） → SSE done{mode,draft,warnings} → 页面草稿预览 → openTaskModal(null, prefill) 预填关键实现 - core/task_draft.py（新）：把执行器的"静默跳过点"（未知 type/空 selector/空 children/ 嵌套>5/节点>60/cron 非法/必填缺失）前移成显式 error——POST /api/jobs 对 params 是盲存的，执行器又静默跳过错误步骤，没有这道闸门就是"任务建好了、跑起来什么都没做"。归一化兜底任务名/target/schedule/retry/时长；页面填的设置以 overrides 优先于模型。故意不比执行器更严：loop_mode 近义值归一（count→rounds）、缺 max_iterations 补默认 10 （执行器本来就默认）——实测卡太死会把一轮探索耗在改字段上。有副作用的步骤（评论/发送/购买/删除…）只警告并把触发概率压到 30%（编辑器可改回）。 - mcp_agent/agent.py：双系统提示词（CHAT/DESIGNER）+ 平台级本地工具（LOCAL_TOOL_SPECS，不进 MCP）+ 每工具调用上限 40 + designer 输出上限 8192 + json.loads 容错（草稿被截断时给模型可读错误，而不是整轮失败）。 - web/agent_api.py：mode/settings 透传、submit_task 处理器（app_context 内校验+暂存）、 done 带 draft、GET /api/agent/task_draft{,+POST,/clear}（草稿走 app_meta，不新建表）。 - 前端：static/admin/taskgen.js + #agent-sub-taskgen 子面板（showSubTab 机制）； tasks.js 的 openTaskModal(jobId, prefill) + 信封归一化 + 唯一 draftKey； agent.js 按 mode 门控（一个 run 只有一个事件队列，两个 EventSource 会互相瓜分事件）。顺带修掉一个 chat 也踩的协议 bug：一轮里同时调 de_screenshot 与别的工具时，截图图像会被插在两条 tool 消息之间 → 模型侧判"工具回应不足"直接 400。改为本轮 tool 消息发完再附图像， _repair_tool_messages 也改成只数连续的 tool 消息。真机实测（Redmi 22120RN86C，设置页）：8 步探索（含 tap_text 验证）→ submit_task 一次通过 → 草稿 8 个顶层步骤（screen_on/open_app/wait_el/click/wait/key_event…）、max_duration 1800、无 click_xy、3 条 evidence；页面恢复草稿 + 预填编辑器 + 提示块渲染均正常，无 JS 报错。自测数据已清理（草稿已丢弃、未创建任何任务）。文档：AI_TASK_GEN.md 状态改「P0 已实现」+ §10 实现记录（差异/护栏/未做项）、AI_CONSOLE.md （子分栏、designer 分支、SSE done 负载、app_meta 键）、API.md、DATA_MODEL.md、ARCHITECTURE.md、 DEVELOPMENT.md（自测入口）、README.md 索引、backlog 勾掉 P0。	2026-09-13 23:08:59 +08:00

Author

SHA1

Message

Date

butubb

34a03db1b9

feat(条件判断): 支持「选中元素 → 拿它的文本和设定的值比」（等于/不等于/包含/不包含）

需求原话：条件判断需要能选择元素，比如我设置了一个抖音号，让它采集这个元素的
文本和我设的值做条件判断。

原来的条件判断只会判「元素在不在」（找到走 then、没找到走 else），没法判"内容对不对"。
现在加两个可选参数：

- `cmp_op`：等于 / 不等于 / 包含 / 不包含（`==`/`!=`/`contains` 这类别名也认）；
  留空 = 老行为，**完全向后兼容**（现有任务不用改）。
- `cmp_value`：要比对的值。

填了就变成：先按选择器取到元素文本 → 和 cmp_value 比 → 比对结果才是命中与否。
用户那个例子就是：元素 `com.ss.android.ugc.aweme:id/506` 的文本是
`抖音号：35377983067`，选「包含」、值填 `35377983067` 即可；
要抓"登录的不是这个号"就用「不等于」。

- 读取只走 `get_text()`（只读，2 秒超时），不点击、不改状态。
- **两条防误判规则**（都写进文档了）：
  · 元素**没找到**时一律算未命中（走 else）——"没读到"绝不能被当成"和我设的不一样"，
    否则界面还没加载出来就会误判成"账号被换了"；
  · 元素在但文本为空时按空文本参与比对（用于抓"栏位是空的"），日志会打出实际读到的值。
- 比对**不污染「选择器健康」统计**：统计用的仍是"元素在不在"——"找到了但值不对"
  是条件按预期走了 else，不是选择器失效，不该攒出「连续未命中」告警。
- 支持比对的类型：所有元素类选择器 + `foreground`（比前台包名）+ `ocr`（比 OCR 命中的那段字）。
  `screen`（亮/熄）没有文本可比，设了会忽略并告警。
- 前端：条件判断面板多一块「文本比对」（运算符下拉 + 比对的值），
  只在元素/OCR/前台App 条件下出现；保存前校验"选了运算符却没填值"和"screen 上设了比对"。
- AI 建任务草稿校验（`core/task_draft.py`）同步拦"运算符拼错""有运算符没值"——
  执行器对认不出的运算符是"一律不命中"，不拦就会变成悄悄走 else。

自测：比对函数 16 项（含别名、空值、None、拼错运算符）、`_exec_if_el` 全分支 20 项
（含"没找到+不等于"这个关键边界、健康统计用存在性、screen 忽略比对、u2 抛异常不炸）、
**真机验证**（cs1 上真读一个 TextView 的文本再比对：包含/等于/不等于 全对，
元素不存在时不误判）、草稿校验 5 项、GET 路由冒烟 55 个 0 个 500。

（测试里踩到一个坑记一笔：u2 的 `XPathSelector.exists` 是纯 bool 属性，而
`UiObject.exists` 是"可调用的 Exists 对象"（`bool()` 即时判断、`exists(timeout=)` 带等待），
两套语义不能想当然统一——单测的假设备一开始没模拟对，是测试写错了不是代码写错了。）

2026-09-24 09:22:32 +08:00

butubb

46e6ea1f37

feat(AI 建任务): AI 自己在真机探索 → 写出可调度任务 → 人工确认入库

AI 控制台下新增子分栏「🧭 AI 建任务」：描述要做什么（例：建一个跑 2 小时的任务、自动刷
某 App、随机点赞），AI 用 de_* 工具自己在设备上探索（看屏/读元素树/点按验证），把走通的
路径写成一条任务草稿，经服务端校验后交人在步骤编辑器里核对/手改/试跑，保存才入库。

链路：POST /api/agent/run{mode:"designer", settings}
  → Agent 自探 → 本地工具 submit_task(draft)
  → core/task_draft 校验（失败把 errors 回灌模型让它改）
  → 只暂存（运行态 + app_meta.agent_task_draft，**不落库**）
  → SSE done{mode,draft,warnings} → 页面草稿预览 → openTaskModal(null, prefill) 预填

关键实现
- core/task_draft.py（新）：把执行器的"静默跳过点"（未知 type/空 selector/空 children/
  嵌套>5/节点>60/cron 非法/必填缺失）前移成显式 error——POST /api/jobs 对 params 是盲存的，
  执行器又静默跳过错误步骤，没有这道闸门就是"任务建好了、跑起来什么都没做"。
  归一化兜底任务名/target/schedule/retry/时长；页面填的设置以 overrides 优先于模型。
  故意**不比执行器更严**：loop_mode 近义值归一（count→rounds）、缺 max_iterations 补默认 10
  （执行器本来就默认）——实测卡太死会把一轮探索耗在改字段上。
  有副作用的步骤（评论/发送/购买/删除…）只警告并把触发概率压到 30%（编辑器可改回）。
- mcp_agent/agent.py：双系统提示词（CHAT/DESIGNER）+ 平台级本地工具
  （LOCAL_TOOL_SPECS，不进 MCP）+ 每工具调用上限 40 + designer 输出上限 8192 +
  **json.loads 容错**（草稿被截断时给模型可读错误，而不是整轮失败）。
- web/agent_api.py：mode/settings 透传、submit_task 处理器（app_context 内校验+暂存）、
  done 带 draft、GET /api/agent/task_draft{,+POST,/clear}（草稿走 app_meta，不新建表）。
- 前端：static/admin/taskgen.js + #agent-sub-taskgen 子面板（showSubTab 机制）；
  tasks.js 的 openTaskModal(jobId, prefill) + 信封归一化 + 唯一 draftKey；
  agent.js 按 mode 门控（一个 run 只有一个事件队列，两个 EventSource 会互相瓜分事件）。

顺带修掉一个 chat 也踩的协议 bug：一轮里同时调 de_screenshot 与别的工具时，截图图像会被
插在两条 tool 消息之间 → 模型侧判"工具回应不足"直接 400。改为本轮 tool 消息发完再附图像，
_repair_tool_messages 也改成只数**连续**的 tool 消息。

真机实测（Redmi 22120RN86C，设置页）：8 步探索（含 tap_text 验证）→ submit_task 一次通过 →
草稿 8 个顶层步骤（screen_on/open_app/wait_el/click/wait/key_event…）、max_duration 1800、
无 click_xy、3 条 evidence；页面恢复草稿 + 预填编辑器 + 提示块渲染均正常，无 JS 报错。
自测数据已清理（草稿已丢弃、未创建任何任务）。

文档：AI_TASK_GEN.md 状态改「P0 已实现」+ §10 实现记录（差异/护栏/未做项）、AI_CONSOLE.md
（子分栏、designer 分支、SSE done 负载、app_meta 键）、API.md、DATA_MODEL.md、ARCHITECTURE.md、
DEVELOPMENT.md（自测入口）、README.md 索引、backlog 勾掉 P0。

2026-09-13 23:08:59 +08:00