第八周：造一个自主的多 agent 系统

收尾项目是一个多 agent 系统：几个 agent 协作，从大量商品里找出真正的便宜货并通知你。

这类项目最容易学到的是「怎么搭」，最该学到的是**「什么时候不该搭」**。

先问：一个 agent 卡在哪

加第二个 agent 的合理理由只有几种：

理由	是不是真的需要多 agent
上下文装不下	是 —— 拆开各看各的那部分
需要不同的模型/能力	是 —— 比如一个便宜的筛选、一个贵的判断
需要独立的判断视角	是 —— 这是最强的理由，下面细说
步骤多、看起来复杂	否 —— 那是 workflow，代码编排就行
想让架构图好看	否

前三条成立就上，后面的别上。多 agent 的调试成本是超线性的（加第二个之前的三个问题）：一个 agent 出错你看它的输出；四个出错你得先定位是谁、再看它拿到的输入对不对 —— 而它的输入是上一个的输出。

最强的那条理由：独立的判断视角

这条值得单独说，因为它是多 agent 唯一无法被「一个 agent 多跑几轮」替代的价值。

让写东西的那个来评判自己写得好不好，它会夸自己。 这不是智力问题，是它没法跳出自己的视角：它脑子里装的是「我为什么这么写」的一整套理由，所以它看到的不是结果，是那串说服自己的过程。

Anthropic 在讲长时程 harness 的时候把这件事称为一个强杠杆：把干活的和判活的分开。同一现象在别处叫 No Ground Truth —— 模型会报告成功，不管它是不是真的成功了。

而且有个反直觉的结论：教一个独立的评估器变挑剔，比教生成器自我批评容易得多。

所以在找便宜货这个项目里，「找」和「判断值不值」应该是两个 agent —— 不是为了并行，是为了让判断不被寻找过程说服。

评估器要动手，不能只读

换个 agent 还不够。如果评估器只是读一遍产出，它判的是「这看起来对不对」，不是「这真的对不对」。

在这个项目里的具体化：判断一个价格是不是真便宜，不能只看模型对商品描述的理解，要去查历史价格、查同类商品。

这条推广到一般情况就是：判断的依据要从「看起来合理」变成「我核对过了」。

一个具体的失败模式

多 agent 系统里最阴险的失败是错误沿着链路洗白。

我在自己的项目里撞过一次：第一步让模型从产品文档抽状态机，它编了一个文档里根本不存在的状态；第二步直接读那个状态机去生成用例，从它铺出来的每一条用例都继承了这个错。

传染率是 100%，因为每一步的产物是下一步唯一的输入。

而想量清楚这件事有多严重，还有一个更隐蔽的坑等着。我做第一次消融对比，拿到的结果是个漂亮的零 —— 两组毫无差别。查了半天才明白：我读的那份结果文件里只有被留下来的产出，被拒收的根本不在里面。 拿幸存者去比较，当然比不出淘汰率的差别。多 agent 系统里这类统计陷阱特别多，因为每一层都在悄悄地筛。

有一份多 agent UI 测试的案例研究给了同一条建议，作为它五条设计准则之一：在 agent 交接处校验显式契约。

而我从这次踩坑里加的一条更具体：下游校验的时候，出处只认原始材料，不认上一步的产物 —— 否则上一步脑补的东西会被当成事实引用。

通知这一步也要有门

「找到便宜货就通知你」听起来无害，但它是一个对外的动作。

值得设一道门的理由很实际：如果判断错了，代价不是一条日志，是你的信任。一个每天推送三条假便宜货的系统，一周之内就会被静音 —— 而被静音之后，它真找到好东西也没用了。

这和测试系统里那条「误报比漏报致命」是同一个道理：一份没人看的报告，红了也不会有人去看 —— 所以进 CI 的 agent 第一步不是自动修，是先把话说准。

边界与代价

多 agent 的收益需要被证明，而不是被假设。 有实验量过让 meta agent 去设计 agent 结构的经济性，回本点在约一万五千个样例，很多场景下永远回不了本。多 agent 编排比那个便宜得多，但同样的问题存在：先量一个 agent 的上限，再决定加不加。

这个 capstone 的判据比多数项目好，但仍然不完美。 「价格低于历史均价」是能程序判死的，这是它的优势；但「这东西值不值得买」不是 —— 后半段仍然需要人。

我自己那套多步骤系统没有跑完过完整的多 agent 协作。 上面关于交接和洗白的经验是真的，关于评估器分离的做法我认同但还没实现 —— 我的判定现在还是正则，不是独立 agent。