2.4 Agent 干不了所有事——结构化执行（Structured Execution）
现象
你让 Agent "重构这个项目"。它试图同时修改 30 个文件，跑到一半上下文溢出，留下一堆半成品代码，测试全挂。
Agent 什么都想干，什么都干不好。
这不是能力问题，而是执行缺乏结构——没有任务分解、没有优先级、没有完成标准。
问题本质
🤖 Agent 的典型执行模式（无结构）
触发用户："重构项目"
↓
修改文件 A
↓
修改文件 B
↓
发现 C 也需要改
↓
改 C 的时候发现 D 有依赖
↓
改 D 的时候上下文满了
↓
中断，留下一堆半成品
没有计划——想到哪改到哪
没有边界——不知道何时停止
没有验收——不知道是否完成
没有回滚——错了无法恢复
Harness 解决方案
方案一：Init + Coding Agent 分离
把"规划"和"执行"分成两个阶段：
Init Agent（规划者）
分析项目结构
制定重构计划
生成有序的任务列表
不写任何代码
职责分离避免混乱
Coding Agent（执行者）
按任务列表逐项执行
每完成一项 → 运行测试 → 提交
不跳步、不并行
方案二：Planner-Worker-Judge 三角色
Planner规划者分解任务 → 生成子任务列表
Worker执行者逐个执行子任务 → 每个完成后报告
Judge评审者检查每个子任务的完成质量 → 通过/打回
通过路径Planner 分解 → Worker 执行 → Judge 评审 → 下一个子任务
打回路径Judge 打回 → Worker 修改 → Judge 再审
三个角色可以是同一个模型，但必须在不同的上下文窗口中运行——确保评估的独立性
方案三：Sprint Contract
借鉴敏捷开发的 Sprint 概念：
yaml
sprint:
goal: "重构支付模块的错误处理"
tasks:
- id: 1
title: "定义错误类型枚举"
files: ["src/errors.py"]
done_criteria: "Linter 通过 + 类型检查通过"
- id: 2
title: "替换 try-catch 为统一错误处理"
files: ["src/payment/*.py"]
depends_on: [1]
done_criteria: "所有测试通过"
max_context_tokens: 50000
rollback_on_failure: true每个 Sprint 有明确的目标、范围和完成标准。做不到就回滚，不留半成品。
方案四：Stripe Minion 模式
Stripe 的实践——每个任务一个独立的小 Agent：
主 Agent接到任务 → 拆分为 N 个最小粒度的子任务
↓
分配每个子任务分配一个 Minion（迷你 Agent）
↓
Minion 1独立上下文只看相关信息完成后销毁
Minion 2独立上下文只看相关信息完成后销毁
Minion N独立上下文只看相关信息完成后销毁
↓
主 Agent汇总结果
优势
没有上下文溢出（每个 Minion 只处理小任务）没有任务干扰（Minion 之间隔离）失败影响小（一个 Minion 挂了不影响其他）
本节小结
📌 本节核心要点
- 现象：Agent 什么都想干，什么都干不好——缺乏执行结构
- 根因：没有任务分解、没有边界、没有验收标准、没有回滚机制
- 方案：Init + Coding 分离、Planner-Worker-Judge 三角色、Sprint Contract、Stripe Minion
- 核心原则：规划与执行分离，每个任务有明确的完成标准和回滚策略
思考题
- Planner-Worker-Judge 三个角色用同一个模型可行吗？有什么风险？如何降低？
- Sprint Contract 的"回滚"策略，和 Git 的回滚有什么区别？在什么场景下需要 Sprint 级别的回滚？
- Stripe Minion 模式的"用完即销毁"策略，和微服务架构的理念有什么相通之处？
下一节预告
结构化执行解决了"怎么干"的问题。但还有一个容易被忽视的问题——Agent 看不到关键信息，因为信息被淹没在了海量上下文中。