用 agent 造 agent 的四种范式

「用 agent 造 agent」现在指的不是一件事，是四件。它们优化的对象不同、验证方式不同、代价也不同，混着谈会得出互相矛盾的结论。

先把四条路摆开：

A 搜索：把 agent 写成代码，让 meta agent 去搜

ADAS 提出的框架叫 Automated Design of Agentic Systems，核心动作是让一个 meta agent 用代码去编写更好的 agent。

它的立论很干净：agent 用代码定义，而编程语言是图灵完备的，所以理论上任何可能的 agent 系统 —— 新的提示词、工具用法、控制流以及它们的组合 —— 都在搜索空间里。

报告的结果是在编码、科学、数学等多个领域上，搜出来的设计大幅超过人工设计的最好水平，而且换领域、换模型之后仍然保持优势。

这条路最诱人的地方是搜索空间没有天花板；最麻烦的地方也在这儿 —— 空间无限大，而每评估一个候选都要真跑一遍。

B 自我修改：改自己的代码，还要留档

Darwin Gödel Machine（ICLR 2026）比 A 更进一步：被改的 agent 和执行改动的 agent 是同一个。它修改自己的代码，从而也提升了自己修改代码的能力。

数字很硬：SWE-bench 从 20.0% 提到 50.0%，Polyglot 从 14.2% 提到 30.7%。 它自己发明出来的改进包括更好的代码编辑工具、长上下文管理、以及同行评审机制。

但真正值得学的是它的两个约束：

一、每次改动都要用基准实证验证。 不是「模型觉得这样更好」，是跑一遍看分数。

二、维护一个存档（archive），而不是一条链。 它从存档里采样 agent 去自我修改，长出一棵多样的树。这一条是防止早熟收敛的 —— 只留最好的那一个，就会一头扎进局部最优。

存档 + 基准，是这条路能成立的全部原因。 去掉任何一个，它就退化成「让模型随便改自己」。

C harness 优化：模型不动，动它周围的东西

第三条路的前提不一样：模型是冻住的，能改的只有 harness。

SBCO 把 harness 形式化成一个三元组 —— 提示词、一组冻结的工具、工作流 —— 然后优化其中三样：提示词、一组学出来的按约束划分的验证器，以及用验证器去检查并修复输出的策略。

它的循环是 提出 → 打分 → 批评 → 修订，全部闭合在模型自己的输出上，没有人工标注。验证器有质量门槛：精确率低于 0.80 或召回低于 0.55 的直接不要。

结果值得注意的不是绝对分数，是效率：

用低 4–5.5 倍的算力达到同等或更好的成绩。 这是这条路最有说服力的地方 —— 它不比谁跑得更高，它比谁更便宜。

Co-Harness 是同一范式的另一个变体：让一个 HarnessCritic 读失败轨迹、提出经过验证的 harness 改动，再拿改进后的 harness 产出的轨迹去微调模型 —— harness 和权重交替进化。

D 组织：不改 agent，改它们的协作方式

第四条路最不像研究，最像工程。Anthropic 那个用 16 个并行 Claude 写 C 编译器的项目，产出是十万行 Rust，跑了约 2000 个 Claude Code 会话、两周、20 亿输入 token 和 1.4 亿输出 token，花掉大约 两万美元。

结果：多数编译器测试套件上 99% 通过率，成功编译了 Linux 6.9 的 x86、ARM 和 RISC-V 版本。

而它的协调机制简单到令人意外 —— 文件锁加 git：

agent 认领任务 → 往 current_tasks/ 写一个文件（如 parse_if_statement.txt）
两个 agent 抢同一个任务 → git 同步时直接冲突
干完 → 拉取上游、合并、推送、释放锁

作者自己说得很清楚：这是个很早期的研究原型，agent 之间没有别的通信方式，也没有任何管理高层目标的流程。

没有消息总线、没有中央调度器、没有角色分工 —— 用版本控制系统本来就有的冲突检测，当并发原语。

四条路的共同地基

把四条路放在一起看，会发现一件事：它们的成败全部取决于同一样东西 —— 有没有一个便宜且可信的验证器。

• A 靠基准分数
• B 靠基准分数，而且明确写着「每次改动都要实证验证」
• C 干脆把验证器本身当成优化对象，还给它设了精确率和召回的门槛
• D 那个编译器项目最关键的一手，是拿 GCC 当 oracle：随机用 GCC 编译内核的大部分文件，只留剩下的给 Claude 的编译器，然后比对

那个 GCC oracle 我认为是整个项目里最聪明的设计。它解决的是「怎么知道一个十万行的编译器对不对」这个几乎无解的问题 —— 答案是不去证明它对，而是找一个已经被验证过的东西来对比。

这一条我有第一手教训。我自己那套东西加过一道判据检查门，实测开火十几次真阳性为零 —— 因为我压根没有一个可信的参照物去判断「这条判据到底好不好」，只能拿正则去猜。没有验证器的时候，你加的门是在猜，不是在验。

反过来说：没有便宜验证器的领域，这四条路都会退化成自说自话。 这也是为什么这些成功案例集中在编码、数学、规划这些有客观判据的领域 —— 不是因为它们更重要，是因为它们能被便宜地判对错。

边界与代价

四种范式不是替代关系，代价结构完全不同。 A 和 B 要反复跑基准，算力开销在评估上；C 的开销在学验证器；D 的开销是真金白银的 token（两万美元买十万行代码）。选哪条取决于你哪种资源便宜。

「大幅超过人工设计」这类结论要看基准边界。 ADAS 报告的优势是在它选的那些任务上。搜索出来的 agent 会不会过拟合到评估方式，是这类工作的通病 —— 而它恰恰很难自证。

D 那条路的成本容易被低估。 两周、两万美元、二十亿输入 token，换来的是一个「多数测试 99% 通过、但生成代码明显不如 GCC 高效」的编译器。它证明了可行性，没有证明经济性。

四条路我都没有第一手数据。 这一篇是读来的，不是跑出来的。

下一篇

上面那条「共同地基」值得单独展开：验证器不只是这四条路都需要的东西，它还决定了自我改进的上限在哪。

下一篇拆这个 —— 包括那个用 GCC 当 oracle 的做法为什么比它看起来更深刻。