01核心判断CORE JUDGMENT
F-007 讲过多 Agent 的三种基本形态：流水线、评审团、分诊台，也给过默认答案——默认不要多，真正需要"多"的理由只有三类：装不下、种类杂、需要独立性。这篇笔记把那份答案推进到工程判断：怎么识别真需要，加的时候要配什么，以及那笔常被漏算的账。
核心判断是：加第二个 Agent 之前，必须先回答"单个 Agent 为什么不够"，而且答案必须指向结构——职责需要分离、上下文需要分工、权限需要隔离。如果答案是"单个效果不好"，那么加 Agent 几乎总是错的方向：单个 Agent 的质量问题，会被协作原样继承，再加上协作自身的新成本——多 Agent 放大的是结构，不是质量。
一个朴素的类比：一个人干不好的活，招十个人来干，通常不会变好，只会错得更热闹——除非那个活本来就需要分工。
02多出来的成本THE HIDDEN BILL
多 Agent 的成本在演示里和边界一样隐形（N-006 的老话题），F-007 把它叫"协作的隐藏账单"；本篇把它摊开成三笔：
通信即复制。Agent 之间没有心灵感应，协作靠把上下文互相传递——每传一次就是一次重读（F-004 的账）。同一份材料在三个 Agent 的窗口里各放一份，成本三倍，口径漂移的机会也是三倍。
误差会传染。单 Agent 的误判在自己的循环里滚雪球，已经够麻烦；多 Agent 里，一个 Agent 的幻觉会变成另一个 Agent 的"输入事实"——后者没有理由怀疑它，因为那是"同事"给的。误差跨过 Agent 边界之后，回溯难度不是相加，是相乘。
问责被稀释。出了错，是分析的那个 Agent 错了，还是执行的那个错了，还是它们之间的传递错了？trace 要跨 Agent 拼接才能回答（N-007 的要求在多 Agent 下加倍），而公开复盘里常见的状态是：每个 Agent 各有一段日志，中间的接缝谁都没记。
03三个正当理由THREE GOOD REASONS
反过来，确实存在必须加 Agent 的场景。F-007 的三类理由落到工程上，前两类——装不下、种类杂——合成"上下文需要分工"，第三类"需要独立性"就是"职责需要分离"；本篇再补一维 F-007 没展开的：权限需要隔离。
职责需要分离。审查者不能是执行者——让写代码的 Agent 自己评审自己的代码，评审就是走过场。评审团结构的本质不是"多几个意见"，是立场分离：批评者不背负"证明自己刚才没错"的包袱。
上下文需要分工。任务大到一个窗口装不下（F-011 的台面有物理上限），或者两类活的工作台差异太大——检索要装资料、写作要装草稿——硬塞进一个窗口互相稀释。流水线和分诊台解决的是这个。
权限需要隔离。高风险动作交给一个权限受限、单独审批的 Agent（F-012 的房间思想用在组织层）：读全库的不能写，能写的只看白名单。这时多 Agent 是安全设计，不是性能设计。
三个理由有个共同点：全是结构性的，没有一条是"单个不够聪明"。这正好可以当试金石——你的理由若不在这三类里，多半是在用架构逃避调试。
04判断顺序ORDER OF OPERATIONS
顺序和 F-005 的三种手段一样，从便宜的开始：先修单 Agent——提示词、上下文（F-011 的四类东西哪类腐坏了）、工具清单；修不动了，再问是不是结构问题；确认是，才加 Agent。
加的时候，一个 Agent 要配三样东西一起上：通信预算（它和谁说话、传什么、传多大），跨 Agent 的 trace（接缝处的记录比 Agent 内部的更重要），责任归属（这个 Agent 的输出出了错，算谁的、谁审）。三样配不齐，加上去的不是帮手，是共犯。
规模上限的判断也简单：每加一个 Agent，问一遍第 02 节的三笔账还付不付得起。付不起的那一刻，就是这个系统的组织规模上限——这一点上，和人类团队没有本质区别。
05作品集里的多 AgentIN PORTFOLIOS
最后说一个具体场景。作品集里，"多 Agent 系统"是近来最常见的标签之一——它听起来先进。但按 F-010 的两句追问测试，第一句"为什么这么做"落到多 Agent 上就是："为什么需要第二个？"答案不在第 03 节三类里的项目，当场现形。
反过来，能讲清"我评估过多 Agent，最后只用了一个，因为职责不需要分离、一个窗口装得下"的人，展示的判断力比十个 Agent 的编排图更值钱。架构上的克制，是比架构上的繁复更稀缺的信号。
06边界声明BOUNDARY
本篇的判断对象是"以协作换质量"的常见误用，依据是公开的工程实践与失败复盘的模式归纳；不针对任何具体产品或框架，也不否认三类正当场景之外存在特例——特例应当由它自己的 trace 与评测来辩护（F-013 的考卷对多 Agent 同样适用）。随着协作框架的演化，通信与 trace 的成本可能下降，第 02 节的账需要按当时的价重算。
07检查清单CHECKLIST
- "单个 Agent 为什么不够"——写下来了吗？答案指向结构还是效果？
- 新加的 Agent，职责和谁分离？分离带来了什么？
- 通信的账算过吗：传什么、传多大、传几次？
- 接缝处的 trace 有人记吗？出错能从终点回溯到起点吗？
- 每个 Agent 的输出，出了错算谁的？
- 砍掉一个 Agent，系统会变差还是变简单？