外观
多 Agent 何时有价值，何时只是增加复杂度？
3 分钟速学卡
30 秒口述： 多 Agent 只有在任务可按专业能力或独立状态明确拆分、子任务能并行、输入输出契约清晰，且协调收益大于通信成本时才有价值。若只是让多个相似模型轮流讨论，往往会增加 Token、延迟、冲突、共享状态和失败恢复复杂度，未必提升正确率。我会先建立单 Agent 或确定性工作流基线，再用任务完成率、端到端延迟、成本、冲突率和人工接管率证明拆分带来的增量。
- 本质： 多 Agent 的价值来自可分解的专业并行，而不是把同一问题交给更多模型讨论。
- 核心机制： 先建立单 Agent 基线；子任务需独立所有权和稳定契约。
- 关键判断： 最终合并要有唯一责任边界；用质量、延迟、成本和冲突率证明收益。
- 项目落地： 示例对比：文档迁移可让多个 Agent 独占分类目录，主 Agent 维护索引；若所有 Agent 同时改同一 README，冲突成本会抵消并行收益。
- 边界与坑： “Agent 越多能力越强。” 通信和冲突会非线性增长；“让多个 Agent 投票就更正确。” 同源模型错误可能高度相关。
目录
面试官为什么问
考察系统分解、并发边界、协调成本和反过度设计意识。
小白先看懂
装修房屋由水电、木工和验收人员并行协作很合理，因为职责和交付物清晰；若三个人都同时改同一张设计图，却没人负责最终合并，就会反复争论和覆盖。
专业映射是：专业工种对应角色 Agent，施工单对应任务契约，共享图纸对应状态，监理对应编排器。类比忽略了模型输出不确定和上下文复制成本。
主题教学图片
图：教学图片｜多 Agent 何时有价值，何时只是增加复杂度？
替代文本： 围绕“多 Agent 何时有价值，何时只是增加复杂度？”组织的中文教学图，通过分区、箭头和标签解释核心机制。
读图结论： 任务可拆、结果可合，才值得使用多 Agent。
这张图片用于建立主题机制的直觉。精确公式、参数、失败分支和事实边界仍以正文与 Mermaid 为准。
图片生成记录： model=gpt-image-2，generated=2026-07-15，prompt_version=v1，reviewed=2026-07-16，review_basis=user-confirmed；查看生成 Prompt。
图：架构｜可并行分工与协调瓶颈
替代文本： 编排器把独立研究、代码和审查任务分给不同 Agent，并行结果按契约汇总；共享写入冲突和高通信任务回退单 Agent。
图表加载中…
读图结论： 多 Agent 的前提是可分解与可合并，不能把协调本身变成最大的工作量。
分配独占文件、数据库分区或工具权限能减少冲突。最终决策必须有单一责任人或确定性合并规则。
核心原理
适合拆分的信号：独立输入、稳定输出 Schema、少共享写、可并行、角色需要不同工具或权限。不适合：强顺序依赖、上下文高度共享、任务很小或错误代价难归因。
项目和生产视角
示例对比： 文档迁移可让多个 Agent 独占分类目录，主 Agent 维护索引；若所有 Agent 同时改同一 README，冲突成本会抵消并行收益。应先用同一任务集比较单 Agent 与多 Agent 基线。
常见错误回答
- “Agent 越多能力越强。” 通信和冲突会非线性增长。
- “让多个 Agent 投票就更正确。” 同源模型错误可能高度相关。
- “共享同一 Memory 就能协作。” 还需所有权、版本和合并协议。
递进追问
- 如何定义子任务输入输出契约？
- 多 Agent 共享状态如何避免覆盖？
- 什么指标证明并行有收益？
- 一个子 Agent 超时后如何降级？
关联阅读
总结
一句话记忆： 多 Agent 的价值来自可分解的专业并行，而不是把同一问题交给更多模型讨论。
- 先建立单 Agent 基线；
- 子任务需独立所有权和稳定契约；
- 最终合并要有唯一责任边界；
- 用质量、延迟、成本和冲突率证明收益。