反方：让 meta agent 设计 agent，多数时候回不了本

前两篇讲的都是这条路怎么走通。这一篇是算账的。

Inefficiencies of Meta Agents for Agent Design 去量了「让 meta agent 设计 agent」的实际收益，得出三条都不太好看的结论。

一、把历史设计塞进上下文，反而更差

meta agent 搜索的直觉做法是：把之前设计过的 agent 都放进上下文，让它在前人基础上改进。这叫累积式（cumulative）上下文。

实测结果是累积式比完全忽略之前的设计还差：

只有演化式带来了提升，在 MGSM 上最多 +10%。

这条结论违反直觉，但仔细想很合理：把一堆历史设计塞进上下文，等于给模型一个强锚点，而锚点会压制探索。 它会倾向于在已有设计上做小改动，而不是提出结构上不同的东西。

「让模型看到更多信息」不总是好事 —— 这一条和上下文工程里那些「塞满窗口反而变差」的观察是同一个形状。

第二个问题是行为多样性低，而且演化式最严重 —— 它产出的 agent 之间相似度更高。

这一条要和第一条一起读才有意思：演化式分数最高，但多样性最差。

多样性为什么重要？因为搜出来的 agent 如果想互补部署（不同的 agent 处理不同的输入），彼此太像就没有互补价值。你花了搜索的成本，得到的是一堆近亲。

这也解释了为什么 Darwin Gödel Machine 要专门维护一个存档而不是一条最优链 —— 那正是为了对抗这种收敛。

这是最硬的一条。设计 agent 本身要花算力，而设计出来的 agent 每次推理也更贵。所以要回本，得靠部署规模摊平设计成本。

那篇算了回本点：在 DROP 和 MMLU 上用并行式上下文，大约需要 15000 个样例才能打平。 而在其他数据集上，无论规模多大，性能收益都不足以覆盖设计成本。

还有一句补刀：即使在理论上能回本的场景里，meta agent 设计出的 agent 仍然比初始库里那些更贵。

换句话说，你不但要付设计费，还要一直付更高的运行费。

上一篇提到 SBCO 用低 4–5.5 倍的算力达到同等或更好的效果。这两篇看起来矛盾，其实优化的东西不一样：

搜索空间的大小直接决定了这笔账划不划算。 图灵完备的代码空间听起来很美，但它意味着评估成本乘以一个巨大的基数。

所以这两篇合起来给的启示是：约束搜索空间，比扩大搜索空间更可能回本。

我读完最直接的三个判断：

一、先别碰 meta agent 搜索。 除非你有上万个样例要跑，而且已经确认瓶颈在 agent 结构上。按那篇的数，多数垂类项目的规模根本到不了回本点。

二、如果要搜，用演化式而不是累积式，并且额外维护多样性。 那篇推荐演化式，但同时指出它多样性最差 —— 所以要么像 DGM 那样显式维护存档，要么接受你会得到一堆近亲。

三、优先优化 harness 的固定组件，而不是搜索结构。 提示词和验证器这类东西的搜索空间小得多，评估也便宜，而且改动本身还能带来几十个点。先把便宜的杠杆用完。

我自己的经验支持这一条，而且是从反面：我那套东西真正的瓶颈从来不在结构上。它坏过的地方是可选参数没人传、注释和代码不一致、SDK 偷偷重试了两次 —— 全是接口和契约的问题，没有一个是「agent 结构不够好」。 拿 meta agent 去搜结构，一个都解决不了。

回本点是按特定成本模型算的。 模型价格、任务长度、部署规模都会改变那个 15000。价格下降会让回本点左移 —— 这篇的结论有保质期。

它量的是分数和成本，不量别的价值。 meta agent 搜索可能产出人想不到的结构，那种「发现」的价值不体现在平均分上。这篇没有否认这一点，只是说按分数和成本算不划算。

「累积式更差」这个结论可能和实现方式绑定。 怎么把历史设计塞进上下文（全文？摘要？只给分数？）会显著影响结果。那篇比的是它自己实现的几种策略，不能推广成「任何形式的历史信息都有害」。

这一篇是我读来的，没有第一手对照。 我没跑过 meta agent 搜索 —— 而按它给的回本点，我大概率也不该跑。

学术这边算下来是「多数时候不划算」。而工业界那边，Anthropic 用 16 个并行 Claude 花两万美元写出了十万行的编译器，还说自己 80% 的生产代码由 Claude 写。

这两个画面怎么并存？最后一篇看工业界的做法 —— 它们优化的不是 agent 的结构，是 agent 和世界之间的接口。