?Agent 系统设计¶

?2026/2027 年，Multi-Agent 题已经不只是“几?agent 串起来”的概念题，而更像是在?任务编排、状态管理、工具治理、失败恢复、评测和控制面。这题答得好不好，直接反映你是否真的理解 Agent 系统工程化?

这章解决什么问?¶

很多候选人?Multi-Agent 时会陷入两个问题? - 只会画几?agent 方框，没有运行时设计 - 只会讲“分工协作”，不会讲什么时候不该用?agent

真实面试更想听的是：

为什么需要多?agent
agent 之间怎么通信和共享状?- 如何避免死循环、重复调用、权限失?- 如何评估系统是否真的比单 agent 更好

先回答一个核心问题：什么时候需?Multi-Agent¶

不是所有任务都应该上多 agent? 更适合 Multi-Agent 的场景：

任务天然分阶?- 子任务需要不同工具或模型
需?planner / executor / reviewer 角色分离
需要多个视角做对照或审? 不适合的场景：
单轮问答
简?CRUD 自动?- 不需要中间状态和协作的短链路任务

一个成熟的表达¶

Text Only

我不会默认使?Multi-Agent。只有当任务存在明显角色分工、需要多步状态管理，或者单 agent 的上下文和控制复杂度已经过高时，我才会引入多 agent?```

这句话会让答案一下子更稳?
## 面试里最常见?4 种架构模?
不同架构模式没有绝对优劣，关键是你能不能说清楚各自适用的任务边界和治理代价?
## 1. Pipeline 模式

```text
Planner ?Retriever ?Executor ?Reviewer

适合? - 流程固定 - 阶段清晰 - 需要逐步落地和审? 优点? - 容易监控 - 容易 debug - 容易做检查点

缺点? - 灵活性有?- 一旦某步设计不好，后续都会被拖?

2. Manager-Worker 模式¶

Text Only

Manager
├─ Worker A
├─ Worker B
└─ Worker C

适合? - 任务需要拆分和汇?- 不同子任务并行度?- 需要统一调度和仲? 这也是最适合面试讲的一个模式，因为结构最清晰?

3. Debate / Reviewer 模式¶

Text Only

Solver A ?Solver B ?Judge

适合? - 方案比较 - 风险分析 - 代码审查 - 内容审核

重点不是“更聪明”，而是降低单视角偏差?

4. Blackboard / Shared Workspace 模式¶

多个 agent 共享一个工作区? - 共享文档 - 共享状?- 共享检索结?- 共享中间产物

适合复杂协作，但状态管理难度明显更高?

真正值钱的不是架构图，而是运行时设?¶

Multi-Agent 系统设计题要真正拉开差距，必须讲“runtime”? 至少要覆盖下?5 层：

任务编排
通信机制
共享状?- 工具执行
失败恢复

1. 任务编排¶

你要说明? - 谁负责接收用户任?- 谁负责拆子任?- 谁负责合并结?- 何时结束或升级人工处?

一个很实用的做?¶

把任务建成状态机? - created - planned - running - waiting_tool - needs_review - completed - failed

面试里只要你能提到状态机，成熟度就会高很多?

2. 通信机制¶

agent 之间至少?3 种常见通信方式? | 方式 | 优点 | 缺点 | |------|------|------| | 直接函数/API 调用 | 简单、低延迟 | 耦合?| | 消息队列 | 解耦、易追踪 | 延迟更高 | | 共享工作?| 灵活 | 状态复?|

一个更像生产的表达¶

Text Only

如果系统规模不大，我会先?manager + 直接调用实现?如果任务长、失败恢复重要，我会引入消息队列和检查点?如果多个 agent 需要围绕同一中间产物协作，则会使用共享工作区?```

## 3. 共享状态和记忆

这是 Multi-Agent 面试最容易漏掉的点?
你应该明确区分：

- 短期任务状?- 长期记忆
- 共享工作?
### 一个简单分?
- 短期：当前任务上下文、已执行步骤
- 长期：历史任务、用户偏好、知识积?- 共享：当前产出的中间文档、代码、计划、检索结?
如果不区分这三层，agent 很容易“记不住”或“记太多”?
## 4. 工具层和权限控制

真实系统里，?agent 的风险往往出在工具调用?
你至少要讲：

- 工具白名?- 参数校验
- 超时
- 重试
- 审计日志

如果任务能改代码、执行命令、访问外部资源，这一点尤其关键?
### 一个很重要的原?
```text
能力越强的工具，权限越应受限?高风险工具调用应支持人工确认或至少有强审计?```

## 5. 失败恢复

Multi-Agent 系统很少“一次全对”?
常见失败类型?
- LLM 输出格式?- 工具调用失败
- 依赖服务超时
- agent 循环
- manager 规划错误

### 推荐回答方式

我建议按“检?-> 止损 -> 恢复”讲?
#### 检?
- 最大轮?- 相似输出检?- 超时检?- 工具错误?
#### 止损

- 中断当前 agent
- 降级到更简单流?- 转人?
#### 恢复

- 从检查点继续
- 回放最近状?- 重新规划剩余任务

![多 Agent 运行时架构图](images/multi-agent-system-architecture.png)

*图源：[Google Cloud Architecture Center - Multi-agent AI system in Google Cloud](https://cloud.google.com/architecture/multiagent-ai-system)，许可：CC BY 4.0。当前主图重点展示协调者、子 Agent、MCP 工具调用和可观测性闭环。*

## 一个标准的?agent 系统?
```text
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 基线的对?

一个成熟表?¶

text 我不会默认认?multi-agent 更好，而是会拿?agent 作为基线，对比任务完成率、平均耗时、成本和人工返工率?只有在复杂任务上确实提升明显时，才保留多 agent 方案?

2026/2027 高价值追问怎么?¶

这一部分不是背答案，而是提前建立一套能覆盖 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
缓存中间结果
限制轮数和工具预?

一个很适合面试的结?¶

text 对我来说，多 agent 系统的核心不在于 agent 数量，而在于编排、状态、工具和治理?如果这些基础设施没有设计好，?agent 只会把问题放大；如果设计好，它才会在复杂任务上优于单 agent?

本章小结¶

Multi-Agent 题真正考的?runtime，而不是画几个 agent
高质量答案必须覆盖：编排、状态、通信、工具、失败恢复、评测和成本
2026/2027 面试里，一个能说明“什么时候不用多 agent”的候选人通常更成?

下一?¶

继续?04-LLM 推理服务架构设计
再看 07-AI 系统设计高频追问与深度题
配合 AI Coding工具链/13-MCP-Skills与Agent控制面一起理解控制面和工具层

⚠️ 核验说明（2026-03-26）：本页已纳入 2026-03-26 全站统一复核批次。若文中涉及外部模型、API、版本号、价格或第三方产品名称，请以官方文档和实际运行环境为准。

最后更新日期： 2026-03-26