Agent 自规划执行能力体系：让新需求 UI 测试自动跑起来¶
Ch04.394 Agent 自规划执行能力体系：让新需求 UI 测试自动跑起来¶
📊 Level ⭐⭐ | 8.8KB |
entities/agent-self-planning-ui-testing-capability-system-aliexpress-2026.md
Agent 自规划执行能力体系（AliExpress UI 测试）¶
一句话总结¶
AliExpress 技术团队把新需求（测新）UI 自动化建成六层能力体系（C1 用例生成 → C2 前置构造 → C3 环境编排 → C4 自规划执行 → C5 断言与归因 → C6 报告与知识回流），核心论断：Agent 只优化用例生成及执行，测新自动化整体价值上限就是 20%，剩下 80 个百分点在前置构造、环境编排、断言与归因、知识回流四层的工程化上——「AI 假通过」是系统性偏差，需专门的 v2 严口径 9 条规则 + BLOCKED 快速路径治理。
核心贡献¶
1. 六层能力体系（C1-C6）¶
判断瓶颈的直接方法：拿一条「跑不通」的用例从 C1 往 C6 挨个问「这一层做对了吗」，第一个答「没做对」的那层就是瓶颈。5 月推广时所有场域瓶颈都停在 C2/C3 而非 C4/C5——Agent 自规划执行的建设重点不是 Agent 本身，是它周围那些函数化能力。
| 层 | 解决的问题 | 关键内容 |
|---|---|---|
| C1 用例生成 | 生成即可执行 | 改写引擎（自由格式 → - action / - assert 结构化）+ 多信源五级降级（Spec 完整 → Spec+Diff → Diff+pageUrl → pageUrl+场域知识库 → 通用兜底）+ 语雀知识库每小时刷新业务语义 |
| C2 前置构造 | 卡住 75% 用例的最深坑 | 配置变更（GCP/GOP/Switch/Diamond）、多维环境编排、账号体系、业务流程背景化（Provider 函数封装）、用例语义保真 |
| C3 环境编排 | 怎么切到目标环境 | 真机 Provider 服务（9003 端口）暴露语义化函数：Deep Link 直达/免 UI 登录/change_locale/change_env/RTL/暗黑/截图录屏/弹窗处理/mtop 录制 |
| C4 自规划执行 | Agent 怎么组织工具跑完用例 | APP 端三段式（自主规划-执行-断言）+ 8 类原子操作（aiTap/aiInput/aiScroll 等）+ aiAction 循环 Observation→Thought→Action→Replanning |
| C5 断言与归因 | 「AI 假通过」专门治理 | v2 严口径 9 条规则 + BLOCKED 快速路径 + 常规 8 类错误归因 |
| C6 报告与知识回流 | 每次执行变下次燃料 | mtop 抓包/录屏/截图/日志/Trace 全量沉淀 + 三层知识库（business_concept/page_knowledge/page_visit_record）闭环回 C1 |
2. Workflow 与 Agent 的边界（核心工程决策）¶
引用 Anthropic《Building Effective Agents》区分：Workflow 是「LLM 和工具通过预定义代码路径编排」，Agent 是「LLM 动态自主决定流程和工具使用」。六层中环节 1/2/3/6 都是预定义 workflow（路径写死）；真正给 Agent 自主决策的空间只在环节 4（执行循环里下一步动什么、点哪里）和环节 5（断言判定的证据充分性）。agentic 能力用在需要「根据环境反馈动态决定」的地方，其他一律走 workflow——这是稳定性做上来的核心。
3. 「AI 假通过」治理：v2 严口径 9 条 + BLOCKED¶
6 月复核实测：AI 报告通过率 56% 的执行结果，逐条对着断言意图重审后 52 条 pass 里 34 条站不住——真实有效率只有 19.5%，三倍虚高。这不是模型不够聪明，是 AI 在断言这一步有系统性偏差：默认朝「通过」倾斜，因为「通过」是不需要额外说明的结论。常规错误归因（timeout/browser-crash/assertion-failed/element-not-found 等）覆盖「AI 承认自己失败」，覆盖不了「AI 说自己成功但其实是假的」。
v2 严口径 9 条规则：①前置态未构造 → blocked ②单帧终态推时序 → invalid ③「没看到就是通过」→ invalid ④环境异常页当降级（SPMC LOSS/白屏/404/桌面/骨架屏）→ blocked ⑤UI 判后端 payload → blocked（迁接口测试）⑥Agent 未完成关键动作就 finish → invalid ⑦平台不支持（如暗黑模式）→ unsupported ⑧断言意图错位（写 A 验证 B）→ invalid ⑨配置对照缺失 → blocked。
BLOCKED 快速路径：命中 Rule 1/4/5/7/9 立刻 finish 并标 blocked，不再硬滑找目标（再滑也找不到，只会烧 token 和时间）。BLOCKED 的意义是把「AI 失败」和「环境/基线本身不合理」分开——前者是该优化的，后者需要业务方改数据集/迁出基线。
4. 能力探针基线度量：不追通过率，追「通过率与有效率的一致性」¶
摒弃「跑一次全量看通过率」——基线不锁版、方差不控制，通过率无法归因到某一层改动。替代方案是能力探针基线数据集：锁版用例按能力分 5 桶（B1 基础 UI 25% / B2 配置变更&异常数据 50% / B3 多端多环境 10% / B4 账号&权限&实验 5% / B5 数据&接口 10%），每条 case 是一根扎在具体能力上的探针——能力没建好必然失败，建好必然通过。三条硬门槛：稳定性方差（连跑 3 次 < 3%，否则踢出）、分桶 delta 表（能力升级前后必跑全量，涨在哪个桶、代价在哪个桶）、v2 严口径复核（AI passRate 与 v2 有效率的差距就是「作弊空间」）。
5. 函数化量化的「80/20 边界」¶
- 用例生成这一环价值上限 20%：多个新需求测试实测得出，剩下 80 个百分点在 C2-C6 工程化
- 函数化前后对比：环境切换从 5-8 步 UI 操作/40-90 秒 → 1 次函数调用/3-5 秒，前置阶段耗时降低约 60%，稳定性 100%
- 业务域定制 vs 通用能力：数据构造业务域单独定制 80% 成功率，通用能力只有 20%
- 实战效果：AE 首页卖场改版已支持能力有效率 85.7%，挖出 2 个真实缺陷（划线价 vs 原价靠 Rule 8 断言意图错位挤出；RTL 箭头方向靠 C2/C3 环境切换到位触发）
6. 三条可迁移原则¶
- 原则一：Agent 只优化用例生成及执行，测新自动化整体价值上限就是 20%。剩下 80 个百分点的空间在前置构造、环境编排、断言与归因、报告与知识回流四层的工程化上——做 UI Agent 的团队应把精力从「让 AI 更聪明」转向「让 AI 周围的函数化能力更完整」
- 原则二：Agent 的自主性用在真正需要语义理解的地方（识别页面状态、决定下一步动作、判断断言证据）；环境切换、账号登录、dpath 注入、配置变更必须函数化。前置能标准化的一律标准化，能用函数就别让 Agent 点
- 原则三：AI 假通过是系统性偏差，需要专门的归因规则去挤。v2 严口径 9 条 + BLOCKED 快速路径的价值不是发现更多失败，而是把 AI 会本能掩盖的那部分暴露出来
相关实体¶
- AI Agent 精细化评测体系（AliExpress） — 姊妹篇：本篇是「执行/测试」维度（六层能力体系 + 假通过治理 + 能力探针度量），该实体是「评测」维度（模块级白盒诊断 + 质量×成本×性能三维指标 + 6 种 Judge Task），同一账号同一团队不同能力层
- Harness 工程实践 — UI 测试场景中 Agent 评测优化的平台实践
- 原文存档
反模式清单（其他团队可直接复用）¶
把所有能力交给 AI 自主规划（环境切换/账号登录让 AI 自己点 → 5-8 步卡点失败率高）；只做用例生成不做前置构造（skill 铺开快但跑不动，铺开进度应被 C2/C3 建设速度约束）；把通过率当首要指标（通过率单调上升可能意味着「AI 学会了作弊」，应追通过率与有效率的一致性）；把不该 UI 层验证的用例硬塞进 UI 基线（B5 数据接口类用例应走接口/数据层测试）。