多 Agent 系统设计¶
到 2028，Multi-Agent 题已经不只是“几个 agent 串起来”的概念题，而更像是在考
任务编排、状态管理、工具治理、失败恢复、评测和控制面。这题答得好不好，直接反映你是否真的理解 Agent 系统工程化。
这章解决什么问题¶
很多候选人讲 Multi-Agent 时会陷入两个问题：
- 只会画几个 agent 方框，没有运行时设计
- 只会讲“分工协作”，不会讲什么时候不该用多 agent
真实面试更想听的是：
- 为什么需要多个 agent
- agent 之间怎么通信和共享状态
- 如何避免死循环、重复调用、权限失控
- 如何评估系统是否真的比单 agent 更好
先回答一个核心问题：什么时候需要 Multi-Agent¶
不是所有任务都应该上多 agent。
更适合 Multi-Agent 的场景：
- 任务天然分阶段
- 子任务需要不同工具或模型
- 需要 planner / executor / reviewer 角色分离
- 需要多个视角做对照或审查
不适合的场景：
- 单轮问答
- 简单 CRUD 自动化
- 不需要中间状态和协作的短链路任务
一个成熟的表达¶
这句话会让答案一下子更稳。
面试里最常见的 4 种架构模式¶
不同架构模式没有绝对优劣，关键是你能不能说清楚各自适用的任务边界和治理代价。
1. Pipeline 模式¶
适合：
- 流程固定
- 阶段清晰
- 需要逐步落地和审查
优点：
- 容易监控
- 容易 debug
- 容易做检查点
缺点：
- 灵活性有限
- 一旦某步设计不好，后续都会被拖累
2. Manager-Worker 模式¶
适合：
- 任务需要拆分和汇总
- 不同子任务并行度高
- 需要统一调度和仲裁
这也是最适合面试讲的一个模式，因为结构最清晰。
3. Debate / Reviewer 模式¶
适合：
- 方案比较
- 风险分析
- 代码审查
- 内容审核
重点不是“更聪明”，而是降低单视角偏差。
4. Blackboard / Shared Workspace 模式¶
多个 agent 共享一个工作区：
- 共享文档
- 共享状态
- 共享检索结果
- 共享中间产物
适合复杂协作，但状态管理难度明显更高。
真正值钱的不是架构图，而是运行时设计¶
Multi-Agent 系统设计题要真正拉开差距，必须讲“runtime”。
至少要覆盖下面 5 层：
- 任务编排
- 通信机制
- 共享状态
- 工具执行
- 失败恢复
1. 任务编排¶
你要说明：
- 谁负责接收用户任务
- 谁负责拆子任务
- 谁负责合并结果
- 何时结束或升级人工处理
一个很实用的做法¶
把任务建成状态机：
createdplannedrunningwaiting_toolneeds_reviewcompletedfailed
面试里只要你能提到状态机，成熟度就会高很多。
2. 通信机制¶
agent 之间至少有 3 种常见通信方式：
| 方式 | 优点 | 缺点 |
|---|---|---|
| 直接函数/API 调用 | 简单、低延迟 | 耦合高 |
| 消息队列 | 解耦、易追踪 | 延迟更高 |
| 共享工作区 | 灵活 | 状态复杂 |
一个更像生产的表达¶
如果系统规模不大，我会先用 manager + 直接调用实现；
如果任务长、失败恢复重要，我会引入消息队列和检查点；
如果多个 agent 需要围绕同一中间产物协作，则会使用共享工作区。
3. 共享状态和记忆¶
这是 Multi-Agent 面试最容易漏掉的点。
你应该明确区分：
- 短期任务状态
- 长期记忆
- 共享工作区
一个简单分层¶
- 短期：当前任务上下文、已执行步骤
- 长期：历史任务、用户偏好、知识积累
- 共享：当前产出的中间文档、代码、计划、检索结果
如果不区分这三层，agent 很容易“记不住”或“记太多”。
4. 工具层和权限控制¶
真实系统里，多 agent 的风险往往出在工具调用。
你至少要讲：
- 工具白名单
- 参数校验
- 超时
- 重试
- 审计日志
如果任务能改代码、执行命令、访问外部资源，这一点尤其关键。
一个很重要的原则¶
5. 失败恢复¶
Multi-Agent 系统很少“一次全对”。
常见失败类型：
- LLM 输出格式错
- 工具调用失败
- 依赖服务超时
- agent 循环
- manager 规划错误
推荐回答方式¶
我建议按“检测 -> 止损 -> 恢复”讲。
检测¶
- 最大轮数
- 相似输出检测
- 超时检测
- 工具错误码
止损¶
- 中断当前 agent
- 降级到更简单流程
- 转人工
恢复¶
- 从检查点继续
- 回放最近状态
- 重新规划剩余任务
一个标准的多 agent 系统图¶
User Request
↓
Orchestrator / Manager
├─ Planner Agent
├─ Retrieval Agent
├─ Tool / Execution Agent
├─ Reviewer Agent
└─ Reporter Agent
Shared Workspace / State Store
Tool Layer / Sandbox
Trace & Eval Layer
Policy / Guardrail Layer
如果你能把后四层也讲出来，答案就不会停留在玩具架构。
3 个高频面试场景¶
下面这 3 类题型最常被拿来追问，因为它们最容易暴露候选人是否真的做过 agent 系统。
场景 1：AI Coding 系统¶
很适合讲成：
- Planner 负责拆 spec
- Repo agent 负责检索仓库
- Patch agent 负责改代码
- Reviewer 负责检查 diff
- Test agent 负责跑验证
这类题和 AI编程实战/07-实战项目 很容易联动。
场景 2：企业任务助手¶
例如：
- 查制度
- 查日报
- 调内部 API
- 汇总报告
适合讲权限、工具治理和审计。
场景 3：数据分析或研究助手¶
例如：
- 数据理解 agent
- 分析规划 agent
- 可视化 agent
- 报告生成 agent
- reviewer/judge
很适合讲共享工作区和检查点。
怎么评估 Multi-Agent 是否真的有价值¶
这是非常高价值的问题。
不要只说“效果更好”，要说指标。
建议至少看：
- 任务完成率
- 平均完成时长
- 工具调用成功率
- 平均 agent 轮数
- 人工介入率
- 成本 / token 消耗
- 与单 agent 基线的对比
一个成熟表达¶
我不会默认认为 multi-agent 更好，而是会拿单 agent 作为基线，对比任务完成率、平均耗时、成本和人工返工率。
只有在复杂任务上确实提升明显时，才保留多 agent 方案。
2028 高价值追问怎么答¶
这一部分不是背答案，而是提前建立一套能覆盖 trade-off、可靠性和组织化的表达框架。
1. 如何防止 agent 死循环¶
答：
- 最大轮数
- 重复输出检测
- tool budget / token budget
- manager 重新规划或人工接管
2. 如何处理 agent 间分歧¶
答：
- 由 manager 汇总裁决
- 引入 reviewer / judge
- 根据置信度、规则或优先级做决策
3. 如何做观测和排障¶
答：
- request id / task id 贯穿全链路
- 每个 agent 的输入输出和耗时可追踪
- 工具调用与错误码记录
- trace 能回放
4. 如何做安全和权限¶
答：
- 工具白名单
- 参数校验
- 输出过滤
- 审计日志
- 高风险步骤人工确认
5. 如何控制成本¶
答：
- 小模型做简单 agent
- 高成本模型只给 planner / reviewer
- 缓存中间结果
- 限制轮数和工具预算
一个很适合面试的结尾¶
对我来说，多 agent 系统的核心不在于 agent 数量，而在于编排、状态、工具和治理。
如果这些基础设施没有设计好，多 agent 只会把问题放大；如果设计好，它才会在复杂任务上优于单 agent。
本章小结¶
- Multi-Agent 题真正考的是 runtime，而不是画几个 agent
- 高质量答案必须覆盖：编排、状态、通信、工具、失败恢复、评测和成本
- 2028 面试里，一个能说明“什么时候不用多 agent”的候选人通常更成熟
下一步¶
- 继续看 04-LLM 推理服务架构设计
- 再看 07-AI 系统设计高频追问与深度题
- 配合 AI Coding工具链/13-MCP-Skills与Agent控制面 一起理解控制面和工具层