交付物：一套 vs 一张图
单 Agent 的交付是提示词、工具清单、评测集与运行配置；多 Agent 还要加编排图、消息协议、各节点契约与超时策略。验收时要逐项确认这些文件真的存在，而不是只在演示里出现，否则换人接手就得重做。怎么验收，逐项对照文件清单，而不是只看演示。
工期：两头不同
单 Agent 通常两到四周能出可用版本；多 Agent 的编排与联调往往占掉一半以上时间，因为要处理超时、重试与合并。若排期把多 Agent 按单 Agent 估算，后期只能靠砍验收项来交付，质量很难守住。为什么工期差这么多，因为编排要处理超时、重试与合并。
变更：一句话 vs 一个节点
单 Agent 调提示词、换模型都能当天回归；多 Agent 改一个节点要重跑整条链路，还要确认下游没被影响。上线后业务规则一改，多 Agent 的回归成本会持续发生，且随节点数增加而放大。怎么降低回归成本，把规则放到共享配置里，而不是散在各节点。
成本：调用次数与延迟
多 Agent 的调用次数是串行链路的累加，延迟随之上升；并行能压时间但会抬高瞬时配额。单 Agent 的成本曲线更平缓。做预算时应按任务量估算调用次数，而不是按席位数或按年估算。怎么估算，先测单任务平均调用数，再乘月任务量。
失败模式：错一处 vs 错一段
单 Agent 出错通常是答错或漏条件，定位快；多 Agent 常见的是交接丢失、合并冲突与超时，表现为看起来完成了但缺项。验收用例要专门覆盖这些失败形态，而不是只跑顺畅路径。怎么验证这些失败形态，验收用例要专门放跨节点样例。
适用与不适用
适合谁
- 正在写方案对比、需要向决策层解释差异的负责人
- 已有多 Agent 提案、想评估真实代价的企业
- 需要为两种路线分别排期的项目经理
不适合谁
- 只关心功能清单、不看交付物的采购
- 尚无真实任务样本可比的项目团队
典型场景
某集团同时收到两份方案：一份单 Agent、一份四个角色编排。评审按六项对照发现，多 Agent 方案没写消息协议与超时策略，工期却只多两周。集团要求供应商补齐契约文件并按阶段验收，最终先上线单 Agent 版本，把并行核验留到二期。
可执行步骤
- 用同一批真实任务让两家各做一版可运行原型，再放在一起比较结果与耗时
- 对照交付物清单，逐个确认文件是否真实存在、能否交接，逐项签收
- 分别记录平均步数、P95 延迟与单任务调用次数，连续测三天看波动
- 写出各自的失败形态与接管方式，说明谁来处理、多久响应，写进方案
- 按阶段设定验收点与回退方案，写进项目确认单，并由双方签字确认
常见坑
- 只比功能列表、不比交付物，多 Agent 方案缺契约文件也能中标，上线后无人能接手维护。
- 用单 Agent 的工期估算多 Agent，联调阶段被压缩，最后砍掉异常处理与评测，故障率明显上升。
- 忽略调用次数，试运行期间成本可控，全面推广后账单翻倍，预算里没有对应科目可以承接。
- 验收只测顺畅路径，交接丢失与合并冲突没被覆盖，业务方在真实单据上才发现缺项，返工很被动。
自检与验收清单
- 两份方案是否用同一批任务做过可运行原型对比
- 交付物清单是否逐项落实为文件并能交接给他人
- 是否记录了步数、P95 延迟与单任务调用次数
- 失败形态与接管方式是否写明并由双方确认过
- 是否约定分阶段验收与回退方案，写入确认单
常见问题
能不能先做单 Agent 再演进？
可以，这也是更常见的路径。把流程、工具与评测集先跑通，等到确实出现并行或隔离需求再拆；演进时沿用同一套评测集，才能判断拆分到底带来了什么变化，也便于向业务方解释投入产出。
多 Agent 一定更贵吗？
通常调用次数更多、延迟更高，但是否更贵取决于任务量与并行度。按单任务调用次数估算，比按席位或按年估算更接近真实；推广前用一个月真实流量复核一次，能避免预算失真。
方案里怎么体现差异？
建议把六项做成一张对照表，每项写事实而不是形容词：交付哪些文件、几步、多少调用、失败时谁接管。形容词无法验收，事实可以，也便于事后复盘时判断当初的选择是否合理。