Goal-Driven 的关键，是多 Agent 里的一个控制环
最近读了 lidangzzz/goal-driven。它很短，几乎没有花活，但看完之后反而记得很清楚。
它在讲的不是“多 Agent 怎么并行”，而是“一个长任务怎么一直被推着往前走，直到真的过线”。这件事听上去简单，做起来并不简单。很多 Agent 系统都能启动，真正难的是跑久了以后还不跑偏，不提前收工，不把局部完成当成最终完成。
最有价值的一点，是把职责切得很干净
这个仓库把系统拆成四个角色：
GoalCriteriaSubagentMaster Agent
翻成工程语言就是：
Goal说的是最后要做成什么Criteria说的是怎样才算真的做成Subagent负责干活Master Agent负责盯结果，没过线就继续推
这套拆法很实用，因为它把执行和验收拆开了。很多 Agent 系统的问题，恰恰出在这两个角色混在一起。执行者自己判断自己完成，最后很容易把“差不多”当成“已经好了”。
Goal-Driven 的态度很直接：先把成功条件说清楚，再谈让谁去做。
它真正强调的，是持续性，不是并发
以前看多 Agent，第一反应也是拆任务、并行跑、最后汇总。Goal-Driven 不是这个路子。
它关心的是另一件事：
当任务很长、很难、又能被验证的时候，系统怎么保证自己不会中途停掉。
这类任务很像编译器、数据库、证明、仿真或者系统级架构设计。最麻烦的地方不是“第一轮做不了”，而是“做到一半以后很容易自信地错下去”。
所以它的核心不是调度多少个 Agent，而是有没有一个外部控制环：
- 先给出明确目标
- 再给出可验收标准
- 让子 Agent 继续推进
- 主 Agent 检查结果
- 不达标就继续
这就是它最朴素的地方，也正是它最像工程系统的地方。
可以把它看成一种长任务的运行方式
这个思路对 Codex、Claude Code 这类工具很有启发，因为平时真正碰到的不是“会不会开始”，而是“怎么一直做下去”。
比如你在做这些事的时候：
- 重构一个老系统
- 补一个跨度很长的功能链路
- 追一个很深的 bug
- 做一个必须过测试和 benchmark 的实现
你会特别需要三件事：
- 目标别变形
- 结果别自我宣布完成
- 失活后能继续接着跑
Goal-Driven 其实就在提醒你这三件事。
它不迷信 Agent 的自觉性，也不把“完成”这件事交给执行者自己判断。它更像一个外部裁判，持续问同一句话：
还没过线，那就继续。
它适合什么，不适合什么
它的前提很明确：它适合可验证、长周期、结果导向的问题。
如果你要的是：
- 做一个编译器
- 实现一个数据库组件
- 跑一个能自动验收的算法项目
- 长时间推进一个系统级任务
那这套控制方式很合适。
但如果 Criteria 写得很虚，比如“做得更好”“更优雅”“尽量完善”，那它就会变成空转。主 Agent 没法稳定判断子 Agent 到底有没有过线，最后只会陷入重复推进。
所以这套方法最重要的不是“让 Agent 一直干活”，而是“把验收条件写成能检查的东西”。没有这一层，Goal-Driven 就只剩下一句听起来很硬的口号。
可以怎么借用
放进工作流，可以做三件事。
第一，把 Criteria 写得更像测试清单，而不是愿望清单。能跑的测试、能看的输出、能对比的结果，都比“更好一点”靠谱。
第二，给主 Agent 留证据，而不是留口头汇报。日志、测试结果、diff、构建产物，这些都比一句“已经搞定了”有用。
第三，给长任务准备恢复包。任务跑到一半被打断，新的执行者应该接得上，而不是从头读一遍所有上下文。
最后
Goal-Driven 最让人记住的，不是它有多复杂，而是它克制。它没有试图解释所有 Agent 问题，只是把一个很现实的事情说清楚了：
长任务不是靠一轮生成完成的，而是靠一个外部控制环，持续把系统推到验收线。
这比很多“多 Agent 很强大”的说法更实在。