第 8 章：消化产出

论点：一旦并行执行跑通，瓶颈就会迁移到"你看不完报告"。解法就是把同一个把戏再往上套一层：让 Agent 来消化 Agent 的产出。

没人警告你的那个问题

到第三阶段你有三四个 Agent 每天产出真正有用的工作。第三部分的三把钥匙把你从对齐、正确性、可维护性的实时回路里挪走。第 7 章的调度模式让你把它们摊到跨项目、跨功能、跨事务类型。吞吐真实。

然后你撞到新墙。不是代码。是报告。

每个 Agent 每天产出：

  • 一两个 PR
  • 一组测试结果
  • 一份 Agent 当用户测试报告
  • 一份设计 / 架构总结
  • 一份它做不了想要输入的事清单
  • 有时候还有一份后续建议清单

乘以四个 Agent，每天你有一堆几十条杂质混合的产物要处理，每条都索要某种量的你的注意力。你以前卡在写代码上，现在卡在读你自己 Agent 的产出上。第 1 章的主题以全力回来：瓶颈只是转移，不会消失。你只是又挪了它一次。

这就是破进并行 AI 开发的工程师开始燃尽的那个点。不是因为工作差——吞吐比以前强——而是因为一天读 24 份质量参差的报告，认知上比一天读一个 PR 贵得多。

新瓶颈的结构

和第 1 章的三个卡点不同，这个瓶颈不关于判断。它关于未加区分的信息体积。工作是：

  • 扫过所有进来的东西。
  • 注意两份报告在讲同一个底层问题。
  • 注意一份是关键阻塞、另一份是"有就好"。
  • 把每条路由到对的后续（另一个 Agent、你自己、忽略）。
  • 保留该保留的，扔掉该扔的。

这经典地是分诊。而分诊从结构上就是Agent 擅长的工作——只要你给它对的输入。解析报告、按主题聚类、按严重度排序、每条写一句总结：这在任何现代 Agent 能力内。缺的不是能力，是管道的结构。

示意图：多个执行 Agent 的产出汇入分诊 Agent；你只处理需要拍板的事项

把戏：让 Agent 分诊 Agent

动作是把 Agent 产出流当作代码一样对待：一个不应该需要你在内循环里的东西。

一个分诊 Agent 坐在执行 Agent 下游。它的工作是：

  1. 读自上次扫描以来所有新报告。 PR、测试结果、用户测试报告、bug 清单、设计总结。
  2. 聚类。 把描述同一底层问题的报告聚在一起（两个 Agent 都说 staging DB 慢；三份 UI 报告都是同一条文案问题；等等）。
  3. 排优先级。 按简单的两轴 rubric 给 cluster 排——用户影响 × 有没有变通办法，或类似的。第三阶段及以上的工程师，具体 rubric 不如一致性重要。
  4. 路由。 每个 cluster 拿一个处置：升给你、送回执行 Agent 修、记为已知问题、丢弃。
  5. 总结。 产出一份短的人类可读报告：今天需要你注意的事，排好序，每条一句理由。

你读分诊 Agent 的总结。可能十条而不是一百条。你对升级的做决定。其它已经路由了。

这和三把钥匙的模式一样：你被从"未加区分体积"阶段里移出来，只放在决策点上。

为什么管用

分诊 Agent 相对你做同样工作有三点优势：

  1. 耐心无限。 它以同样的注意深度读完 24 份报告。你不会。
  2. 体量上的模式匹配。 把五十项按主题聚类，这件事对人类急剧退化，对 Agent 不。当天第二十九项拿到的分析质量和第一项一样。
  3. 一致性。 它用的 rubric 对每一项都一样地用。你自己的 rubric 会随你累而退化；它的不会。

它也有真实局限：分诊 Agent 只跟它的输入一样好，执行 Agent 产出垃圾报告，它就造垃圾堆。这又是一次 skill 的论据——执行 Agent 的报告应遵循结构化形状。

诚实谈成熟度

这一章我最需要说实话的地方是：分诊层不是一个已解决的产品。你可以建。我建过一个（zero-review/auto-triage skill 是参考实现，仍在开发中）。但你现在还拿不到一个预装的。

你能做的是：

  • 定义一个结构化报告格式，要求执行 Agent 产出（作为 skill 加载）。
  • 在每个工作周期末跑一个独立 Agent 作为分诊 skill。
  • 迭代 rubric。第一版会升级过多或过少；几周打磨。

这（恰当地）又是磨合期露面的地方。分诊层随着你学你这些 Agent 常犯什么错而成熟。

参考：[zero-review/auto-triage](https://github.com/A7um/zero-review/tree/main/skills/auto-triage) （开发中——部分参考）

分诊层成熟前你能做的

今天就能部署的短期防守：

  • 批量读。 别像看聊天消息那样看报告。每天两三个 inbox 处理窗口。想把报告当聊天消息处理会撕碎你的注意力。Mitchell Hashimoto 明确描述过 他在深度工作时关通知，跑"下班后 Agent"让报告在夜里完成，他一次读一批产出，而不是实时读。
  • 在源头强制结构化报告。 每个执行 Agent 以一致格式产出报告：状态、做了什么、失败了什么、需要你输入的、能等的。一条强制这种格式的 skill 立刻回本。
  • 系统通知只用于"需要输入"，不用于"完成"。 Cherny 的配置在 X 上公开，他显式地把系统通知用作反弹信号——只在 Agent 需要我时告诉我，而不是它完成时。单是这一个改变把 inbox 模式变成 pull 模式，往往就是"五个 Agent 感觉像混乱"和"五个 Agent 感觉像监督"的区别。
  • 对"能等"那桶心狠。 很多报告只需要确认，不需要行动。一句"记下了，继续"往往就是对的。
  • 维护一个可见队列。 一张简单的待办清单，带 Agent 来源、日期、状态，即便没有 Agent 也给你一个粗略分诊层。一天扫一次队列——而不是每条到达时响应——本身就是大赢。

一个最小结构化报告 skill

在真正分诊层存在之前，早期最杠杆的一个加法，是一条强制每个执行 Agent 在结束工作前产出结构化报告的 skill。最小可用版本规定六节——状态（COMPLETE / NEEDS_INPUT / BLOCKED）、做了什么、测试（绿 / 红 / 未跑）、我不确定的事、需要人输入的、我推荐的后续——并禁止在这几节之外写自由散文。

这条 skill 加载到每个执行 Agent 上，就把 20 份自由格式报告变成 20 份有同样六节的报告。那时分诊 Agent——或你用眼扫——能在一小部分时间里处理这批，因为你知道该报告里哪一节找你在乎的部分。这类 skill 本身的写作细节属于 The Skill Design Book；这里要紧的是机制。它和 Cherny 的 [/commit-push-pr slash 命令](https://x.com/bcherny/status/2007179833990885678) 是同一个形状的小尺度版本——把产出强制成可预测形状，让下游消费者不用每份都从头读。

结构化报告是分诊层成熟之前你能部署的最大单一收益。 本章你只做一件事，就做这个。

二阶效应

分诊层跑起来后，会发生不显眼的事。你的执行 Agent 开始产出更好的报告，因为：

  • 你不再读单个报告。你读分诊总结。
  • 分诊 Agent 因此是执行 Agent 产出的主要消费者。
  • 于是执行 Agent 的 skill 演化以产出分诊层能干净摄取的报告。

这是正循环。管道的结构开始编码一个共享报告 schema，不需要有人自上而下设计一个。你会在几周后注意到：你的 Agent 产出的报告看起来像写给机器的，因为它们就是。

瓶颈下一个去哪

你读得仔细的话已经知道：瓶颈又会转移。分诊跑起来后，下一个它出现的地方是决策层——按构造，分诊层升给你的是最难的那些。你不会每项花更少认知能量；你会在一堆更难的小堆上花它。墙钟时间下降；每决定负担上升。

第 9 章会直接处理这个。眼下的要点是：没有最终瓶颈。只有你处理过的和你还没处理的。这本书讲的就是这个序列。

外部声音

  • 支持：把决定路由过自动分诊层的模式在事件管理（PagerDuty 风格）、客户支持（Zendesk 风格）、规模化代码审查（PR bot）里久经验证。把同样模式应用到 Agent 产出是自然翻译。
  • 反驳：怀疑者（正确地）指出分诊 Agent 可能系统性地漏掉新颖失败模式——它们按模式路由，真正新问题不匹配任何模式。这是真实极限。缓解：定期（比如每周）做一次整流审，你读原始报告而不是分诊产出，专门抓分诊漏的。

下一章

第 9 章用坦白收尾：这整套不会让你更轻松。你用肌肉记忆换了持续判断力，认知成本是真实的——即便吞吐是。