Agent 执行：把 AI 当执行团队

人负责判断和编排，AI 负责执行。Agent 执行不是连续聊天，而是把规格拆成可验收的工作单，让每个执行节点都有明确的输入、产物和检查点。

前几章已经把GMV 清洗迁移链路从一句话变成了规格。现在才轮到 AI 大规模动手。

本章是执行篇的总纲，回答两个问题：执行阶段人和 AI 的决策权如何划分，以及为什么"让 AI 自己写、自己审、自己相信自己"在机制上不可靠。具体的工作单格式见 Agent 工作单，多角色如何组合成流水线见 多 Agent 编排。

一、反例：聊天式打补丁，以及它为什么必然失败

很多人的执行方式是在一个聊天框里连续下指令：

迁移生态店铺 GMV 清洗链路。
再加一个预览模式。
再把九个平台拆开。
再补部分失败继续执行。
再限制目标表。
再写测试和新旧核对。
刚才这个不对，你再修一下。

表面问题大家都能感觉到：越改越乱、改东坏西、测试只覆盖最后一轮。但要经得起追问，得说清楚它为什么在机制上必然失败，而不只是体感不好：

1. 需求以增量补丁的形式存在，没有任何一处是"当前完整需求"。 最终需求 = 六轮对话的叠加，其中还夹着两次口头否决。人自己都无法指着某一段话说"这就是终版"，模型更不能。后补的幂等要求和第一轮生成的表结构冲突时，模型只能猜哪个优先。

2. 长会话中，早期约束会被稀释。 上下文窗口不是均匀记忆。随着会话变长，模型对最近几轮指令过拟合，对早期约束（比如第一轮里说过的"不要改平台源表"）的遵循度持续衰减。这是长上下文模型的普遍行为特征，不是某个模型的缺陷——业内常称之为 context rot。靠"它应该还记得"来守约束，等于没有约束。

3. 没有验收基线，收敛与否全凭观感。 每一轮"再修一下"都没有定义"修好"的判据。没有判据的迭代不叫收敛，叫随机游走——你感觉在进步，实际可能在原地打转。

第三点不是危言耸听。METR 在 2025 年做过一个随机对照实验：让资深开源开发者在自己维护的仓库上完成真实任务，使用 AI 工具的组实际耗时多了 19%，而开发者自己估计快了 20%。生成得快和交付得快是两回事——中间隔着理解、纠偏、返工和验证。聊天式打补丁把所有这些成本都推到了"感觉不到"的地方。

所以问题不是"AI 写得不好"，而是这种组织方式让好坏无从判定。

二、分工模型：按决策权分层，而不是按工种分活

Agent 执行的核心原则：

人定义目标、边界、拆解和验收；AI 在边界内执行、分析、审查和修复。

但"人做判断、AI 做执行"这句话太粗，实际操作中要按决策的层级来划分：

决策层	内容	归属	例子
方向性决策	做不做、目标是什么、取舍怎么定	人独占	确定预览/写入、重跑、部分失败和汇总刷新的业务语义
结构性决策	架构、模块边界、数据模型、接口契约	人主导，AI 可提案	总控只依赖 PlatformExecutor，平台特例留在各执行器
实现性决策	具体代码、测试用例、文档措辞	AI 主导，人验收	Service 内部的实现细节、测试的组织方式

这个分层和 Anthropic 在《Building Effective Agents》里的工程建议一致：他们把系统分成 workflow（执行路径由人预先定义，模型在节点内工作）和 agent（模型自主决定路径），并明确建议生产系统从最简单的可行结构做起。我的立场更进一步：在有存量系统、有质量要求的业务交付里，绝大多数场景应该用 workflow 式编排——路径、边界、检查点由人定义，AI 只在节点内部自治。让模型自主决定"接下来该干什么"，等于把方向性决策让渡出去，这是事故的主要来源。

这也是"会用 AI"和"会组织 AI"的分界线：前者把 AI 当更快的键盘，后者把 AI 当一支需要管理的执行团队——团队能力再强，也不能没有任务书、边界和验收。

三、为什么不能让同一个上下文自写自审

"写完让 AI 自己 review 一下"是最常见的伪验证。它在机制上有两个问题：

自我偏好偏差。 有研究（Panickssery et al., 2024, LLM Evaluators Recognize and Favor Their Own Generations）表明，大模型在评审时能识别出自己生成的内容，并系统性地给出更高评价。让实现者给自己打分，分数天然虚高。

上下文污染。 更隐蔽的是：如果实现过程中模型做了一个错误假设（比如"这个系统是单实例的"），这个假设已经写进了会话上下文。同一会话里再做 review，模型会把这个假设当成已确认的事实，而不是待审查的疑点。错误和它的审查者共享同一套前提，审查就失效了。

这和传统工程里"测试不能由被测代码自己断言自己通过"是同一个道理。工程做法有三条：

• 换上下文：review 在新会话或独立 subagent 里做，输入只给规格和代码 diff，不给实现过程的对话史；
• 换视角：review 的依据是验收清单和架构边界，而不是"看看代码写得好不好"；
• 必要时换模型：关键链路可以用不同模型交叉审查，进一步降低同源偏差。

四、执行链路：GMV 清洗迁移链路的分工

把上面的原则落到GMV 清洗迁移链路上，执行链路是五个节点。注意每个节点都有独立的输入、明确的产物和人工检查点——节点之间靠文档交接，不靠会话延续：

节点	输入	产物	人工检查点
需求审查 Agent	需求体检结果	缺口清单（平台范围、日期/金额口径、重跑、失败策略、目标表和验收是否明确）	缺口是否真实、优先级是否认可
架构 Agent	规格文档	模块边界、数据模型、接口契约的自洽性检查报告	结构性决策逐条确认
实现 Agent	规格 + 工作单	代码改动 + 实现说明（只实现约定的平台执行器或总控，不跨越平台 Mapper 与汇总服务边界）	抽查关键路径：平台选择、失败策略、目标表白名单与汇总门禁
测试 Agent	验收标准	覆盖预览、未知平台、无效日期、两种失败策略、白名单、完整成功的测试 + 未覆盖风险	测试能否真实失败，而不是只验证 happy path
Review Agent	规格 + diff（干净上下文）	问题清单：边界违反、平台口径泄漏、预览副作用、汇总门禁、旧链路影响	逐条裁决：修复 / 接受风险 / 驳回

两个关键设计：

产物落盘，文档交接。 每个节点的产物写成文件（spec.md、review.md、测试报告），下一个节点读文件，而不是继承上一个节点的聊天记录。这保证了每个节点的上下文干净、可审计，也意味着任何一个节点可以随时重跑而不牵连其他节点。

人工检查点设在决策处，不设在劳动处。 人不需要逐行看 AI 写的每一行代码，但结构性决策（表结构、契约、事务边界）必须逐条过目。检查点的位置，就是第二节那张决策分层表的落地。

工作单的完整字段和写法见 Agent 工作单；链路的并行化、集成契约和文件归属规则见 多 Agent 编排。

五、任务分级：不是每个需求都值得全链路

全链路编排有真实成本：token 消耗、编排延迟、每个节点重建上下文的开销。专业的做法不是"所有任务都上流程"，而是按缺陷逃逸的代价分级：

级别	特征	执行方式
S：低风险	单文件、无状态变更、文案/样式级改动	单会话直接做，自测通过即可
M：有边界风险	涉及数据写入、权限、对外契约中的一项	工作单 + 独立上下文 review，两个节点
L：核心链路	跨模块、涉及经营数据口径与存量链路	全链路：证据梳理 → 需求审查 → 架构 → 实现 → 测试 → 新旧核对 → review

判断标准只有一条：这个改动出缺陷的代价，是否高于编排的开销。 GMV 清洗迁移涉及经营口径、九个平台和下游汇总，是标准的 L 级；改一个错误提示文案硬跑全链路，是形式主义。

方法论如果不写分级，就会被合理地质疑"这套流程太重、没人真的这么干"。分级就是回答：流程的重量必须和风险成正比。

六、把纪律变成默认动作：Skill、Hook、Subagent

流程写在文档里会被遗忘，写进工具里才会被执行。以 Claude Code 为例（其他 agent 工具有对应机制），四类原生机制各守一层：

• CLAUDE.md / 项目记忆：让项目级约束（架构边界、平台、日期范围与目标表规则、禁改清单）常驻上下文，不依赖每次手动粘贴；
• Skill：固化高频流程——需求体检、测试审查、代码 review 各做成一个可调用的技能，保证每次执行的步骤一致；
• Hook：守硬边界——提交前强制跑测试、修改GMV 平台模块前强制读取规格、失败测试禁止跳过。Hook 的本质是把"必须"从自觉变成拦截；
• Subagent：提供天然的独立上下文，正好承接第三节说的"审查必须换上下文"。

开源社区已有成型的技能库（如 Superpowers 等 Claude Code 技能集）可以直接复用，不必从零造。选型判断只有一条：它是否让流程更稳定，而不是它是否热门。

三条落地原则：

约束能进 Hook 的，不要靠自觉；流程能进 Skill 的，不要靠记忆；判断不能进任何工具——判断留给人。

七、失效边界：这套方法什么时候不适用

一套方法论如果宣称自己处处适用，就不值得信任。Agent 执行模式在三种情况下会失效，甚至帮倒忙：

需求还没澄清就开始编排。 多个 Agent 会基于各自的假设并行开工，编排只会放大混乱。此时应该退回需求体检，而不是加流程。

规格处于高频变更期。 每次变更都要重发工作单、重跑链路，编排开销超过收益。此时更适合人和单会话紧密迭代，等规格稳定再切回编排。

探索性任务。 原型验证、技术调研、"先跑起来看看"的场景，价值在于快速试错，不在于交付质量。硬套流程是用 L 级的成本做 S 级的事。

识别自己方法的边界，本身就是方法论的一部分。

八、本章小结

• 聊天式打补丁的失败是机制性的：需求无终版、早期约束衰减、没有验收基线——感觉快不等于真的快（METR 2025：自估快 20%，实测慢 19%）。
• 人机分工按决策权分层：方向性决策人独占，结构性决策人主导，实现性决策 AI 主导、人验收。
• 自写自审不可靠有实证依据（自我偏好偏差）和机制解释（上下文污染），review 必须换上下文、换视角、必要时换模型。
• 执行链路节点间用文档交接而非会话延续；人工检查点设在决策处。
• 任务按缺陷逃逸代价分 S/M/L 三级，流程重量和风险成正比。
• Skill / Hook / Subagent 把纪律变成默认动作；判断永远留给人。

下一章 Agent 工作单，把本章的分工模型落成一张张可验收的任务卡。

---

参考资料

• Anthropic, Building Effective Agents（2024）——workflow 与 agent 的区分、常见编排模式。
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025）——随机对照实验：AI 辅助下资深开发者实测慢 19%，自估快 20%。
• Panickssery et al., LLM Evaluators Recognize and Favor Their Own Generations（2024）——大模型评审自身输出时存在系统性自我偏好。