Single-Agent 还是 Multi-Agent？面试里真正考的不是 Agent 数量

面试官让你设计一个 Agent 系统，你画出规划 Agent、检索 Agent、代码 Agent、审核 Agent 和协调 Agent，看起来很完整。真正危险的追问是：“如果一个 Agent 加四个显式工具就能完成，为什么要让五个模型互相发消息？”

多 Agent 不是更高级的同义词。高分答案从最小可行架构开始，只在专业化、并行或隔离产生可测价值时拆分，并把新增协调成本放进同一张账。

为什么“多 Agent 更高级”是危险开场

Agent 数量不是业务能力，也不是架构成熟度。一个单 Agent 可以调用检索、数据库、代码执行和审核工具，配合状态机、策略层与人工确认完成复杂流程。只要任务主线、工具契约和停止条件清楚，它并不等于把所有逻辑塞进一段巨大 Prompt。

默认从单 Agent 开始有三个好处。第一，输入、决策、工具结果和最终输出沿一条主线流动，故障更容易定位。第二，评估可以直接连接任务结果，不必先判断是哪段协作出了问题。第三，成本与延迟基线清楚，后续拆分才知道多出来的调用换回了什么。

“角色扮演更像团队”也不是充分理由。多个角色标签如果读取相同上下文、使用相同模型、执行相同工具，只会重复计算。面试官想听的是边界：每个所有者拿到什么输入，产生什么可验证产物，失败由谁处理，为什么工具或普通函数不足以承担它。

OpenAI 的实践指南支持渐进式构建 Agent；Anthropic 公开的是研究任务中的特定多 Agent 架构与工程权衡。两者都不能被简化成“官方推荐所有系统上多 Agent”。

如果还需要补齐任务、工具与停止条件的岗位语境，可以参考 AI Agent 面试指南，再回到本题判断是否真的需要新增协作所有者。

并行、隔离和专业化分别何时成立

专业化成立的前提是子任务确实需要不同工具、知识、权限或评估标准。例如，一个子任务需要在受限数据域检索，另一个只处理公开资料；拆分可以让上下文和能力更聚焦。但如果所谓专业 Agent 只是换了一段人设提示，没有稳定输入输出契约，专业化很可能只是命名。

并行适合彼此独立、合并规则明确的子任务。多个资料源可以同时收集，多个候选方案可以独立生成，再由确定的评估步骤汇总。若后一个步骤必须依赖前一个步骤的完整结果，强行并行只会制造等待、取消和合并问题。并行缩短的是关键路径，不代表减少总计算量。

隔离可能来自权限、故障域或敏感数据。把只读检索与可产生外部副作用的动作放在不同执行边界，可以限制能力扩散；把不可信内容处理与高权限工具分开，也更容易设置策略闸门。但隔离要由授权、运行环境和数据边界实现，不能只靠给 Agent 起不同名字。

三种理由都应落到可测假设：专业化是否提高任务正确率，并行是否缩短端到端关键路径，隔离是否减少可访问资源和事故半径。无法测量的拆分理由，很难抵抗后续复杂度。

消息、状态、冲突与重试怎样吞掉收益

单 Agent 失败时，通常沿一条调用链查输入、工具和输出；多 Agent 还要追踪消息版本、发送顺序、共享状态、过期上下文与合并决定。一个子 Agent 根据旧计划完成了正确工作，也可能在全局上成为错误结果。于是系统需要关联标识、版本、超时、取消和可重放记录。

共享状态是第二个陷阱。所有 Agent 都能写同一份记忆，容易发生覆盖和不可解释的顺序依赖；完全不共享，又会重复检索并丢失关键约束。更稳的设计是明确单一状态所有者，其他参与者提交带版本的候选结果，由确定规则接受或拒绝。

这类状态问题本质上也属于上下文边界问题，上下文工程深挖可以帮助你进一步解释哪些信息应共享、压缩、隔离或随任务版本失效。

冲突不能靠“再叫一个裁判 Agent”无限向上堆。两个答案不一致时，应先判断能否用规则、测试、来源优先级或人工确认裁决。若裁判仍只凭生成偏好选择，系统只是把不确定性移动了一层，还增加一次成本和延迟。

重试会放大问题。协调者重试整个任务、子 Agent 又重试工具，可能造成调用倍增或重复副作用。每层都要规定尝试预算、幂等边界、可重试错误和停止条件。评估也必须看端到端任务，而不是分别展示每个 Agent 的局部成功率。

用可逆实验决定是否拆成多个 Agent

先用单 Agent 加显式工具建立基线，记录任务成功率、质量评分、首个可用结果时间、完整耗时、模型与工具调用成本、人工介入率和失败恢复时间。然后只选择一个拆分假设，例如把两个真正独立的研究分支并行，不要一次改成完整“Agent 团队”。

实验范围要有限：固定任务集、明确流量比例、受限权限、可观察消息和一键回到单 Agent 路径。提前定义成功条件，例如端到端质量提升且长尾延迟、成本和故障率仍在接受范围；也要定义退出条件，例如冲突率上升、人工排障显著变慢或收益只出现在少数样例。

观测设计要跟实验一起上线。每个子任务需要共同的任务标识、输入版本、工具结果摘要、交接时间与最终采用状态，这样才能判断新增 Agent 提供了独立价值，还是只生成了最后没有被使用的内容。只统计“各 Agent 都成功返回”，会漏掉合并失败、重复工作和过期结果。

还要比较非 Agent 替代方案。固定规则能完成的分类，普通函数可能更便宜、更稳定；结构化工作流能表达的顺序，不一定需要模型协商；只缺少权限边界时，可以先拆工具与执行环境，而不是拆出新的推理角色。证明简单方案不够，再增加 Agent，决策更可逆。

当面试官把问题转向工具、权限和执行环境时，Harness 工程方法能补充为什么显式工具契约往往比继续增加角色更重要。

对研究型开放任务，多 Agent 可能利用并行探索扩大覆盖；对步骤稳定、工具明确、风险集中的业务流程，单 Agent 或确定性编排常常更容易治理。结论必须绑定任务，不能从一个公开研究系统推导到所有客服、招聘、编码或面试产品。

这里讨论的是面试中的架构判断，并不授权在当前产品中引入自治多 Agent 实现。一个可信收口是：我会先证明单 Agent 的瓶颈，再针对专业化、并行或隔离中的一个原因做可逆实验；如果收益不能覆盖协调、评估和故障复杂度，就保留更简单的架构。

来源

• OpenAI：A practical guide to building agents，2025 年
• Anthropic Engineering：How we built our multi-agent research system，发布于 2025-06-13
• Microsoft AutoGen Docs：AgentChat teams，访问于 2026-07-28
• NIST：AI Risk Management Framework 1.0，发布于 2023-01-26

这些来源说明单 Agent 与多 Agent 都是可用模式，并呈现了特定场景的工程取舍；它们不提供适用于所有任务的拆分阈值，也不证明 Agent 越多质量越高。

常见问题

Multi-Agent 一定比 Single-Agent 质量更高吗？

不一定。更多 Agent 可能带来专业化或并行收益，也可能因上下文丢失、冲突、重复工作和协调失败降低端到端质量。必须以同一任务集比较。

什么情况下值得考虑拆成多个 Agent？

当任务存在可验证的专业边界、可并行子任务或必须隔离的权限与故障域，并且预期收益能够覆盖消息、状态、评估与恢复成本时，才值得实验。

单 Agent 是否等于把所有逻辑塞进一个 Prompt？

不是。单 Agent 仍可使用多个显式工具、确定性工作流、策略校验和人工确认，只是由一个清晰的编排所有者维护任务主线与状态。

怎样证明多 Agent 拆分有效？

用同一任务集比较成功率、质量、耗时、调用成本、冲突率、人工介入和恢复难度，并在实验前写明保留、回滚与停止条件。

下一步

• 查看 Interview AiBox 功能全景
• 深入了解 核心功能使用指南
• 通过 产品路线图 了解当前能力边界
• 下载 Interview AiBox 建立自己的 Agent 架构复盘清单