多 Agent 项目面试表达：不要只讲多角色聊天
这篇文章解决什么问题
很多人在面试里讲多 Agent，会停留在：
- 规划 Agent 负责拆解任务
- 执行 Agent 负责执行操作
- 审查 Agent 负责检查结果
- 总结 Agent 负责生成报告
但如果只讲角色名，很容易显得像 Prompt 角色扮演，而不是工程系统。
核心观点：多 Agent 项目的关键不是有几个 Agent，而是它们如何协作、如何共享状态、如何调用工具、如何处理冲突、如何停止、如何评测。 这篇文章基于 HFL AI Agent Lab 中的 Agent 工程理解，整理面试中如何讲清楚一个多 Agent 项目。
面试官真正想考什么
| 考察点 | 面试官想确认什么 |
|---|---|
| 是否理解多 Agent 的适用场景 | 你知不知道什么时候该用多 Agent，什么时候不该 |
| 是否理解任务分解 | 你知不知道怎么把复杂任务拆成可执行的子任务 |
| 是否理解调度机制 | 你知不知道谁来决定哪个 Agent 做什么 |
| 是否理解共享状态 | 你知不知道 Agent 之间怎么传递必要信息 |
| 是否理解工具权限 | 你知不知道不同 Agent 应该有不同的工具权限 |
| 是否理解冲突处理 | 你知不知道 Agent 之间可能产生冲突，怎么解决 |
| 是否理解结果聚合 | 你知不知道怎么把多个 Agent 的结果合并成最终答案 |
| 是否理解 Trace 和 Evaluation | 你知不知道怎么追踪和评估多 Agent 协作效果 |
面试官想确认你理解多 Agent 的工程复杂度，而不只是会写多个 Prompt。
一句话回答框架
我不会把多 Agent 理解成多个角色聊天，而会把它看成一个任务协作系统。核心是：由 Planner 或 Supervisor 进行任务拆解和调度，不同 Agent 负责不同能力边界，通过共享状态或消息协议传递必要信息，通过工具权限控制各自可执行动作，通过 Trace 记录每个 Agent 的执行步骤，通过 Aggregator 汇总结果，最后用 Evaluation 评估任务完成率、协作效率、工具调用准确率和结果质量。
多 Agent 适合什么场景
适合的场景：
- 任务复杂，需要拆解成多个子任务。
- 需要多个专业能力，比如检索、分析、生成、审查。
- 需要执行和审查分离，避免自己检查自己。
- 需要工具权限隔离，不同 Agent 只能访问特定工具。
- 需要多人协作式流程模拟，比如产品经理 + 开发 + 测试。
- 需要长期任务推进，比如持续监控和处理。
不适合的场景：
- 简单问答，单 Agent 就能处理。
- 单轮检索，不需要多步协作。
- 明确固定流程，用 Workflow 更合适。
- 只为炫技增加角色，实际没有协作需求。
- 没有评测标准的场景，无法评估多 Agent 是否比单 Agent 更好。
多 Agent 系统结构怎么讲
| 模块 | 作用 | 面试表达 |
|---|---|---|
| Supervisor / Planner | 任务拆解和调度 | 负责把复杂任务拆成子任务，分配给合适的 Agent |
| Specialist Agent | 执行特定能力 | 每个 Agent 有明确的能力边界和工具集合 |
| Tool Agent | 专门调用工具 | 负责执行具体操作，如数据库查询、API 调用 |
| Reviewer | 审查执行结果 | 负责检查 Agent 的输出是否正确、是否符合要求 |
| Aggregator | 汇总最终结果 | 负责把多个 Agent 的结果合并成最终答案 |
| Shared State | 共享状态 | 负责 Agent 之间传递必要的任务信息 |
| Message Bus | 消息传递 | 负责 Agent 之间的通信和协调 |
| Trace | 执行轨迹 | 负责记录每个 Agent 的执行步骤和工具调用 |
| Evaluation | 效果评估 | 负责评估多 Agent 协作的质量和效率 |
| Security | 安全控制 | 负责权限控制、审计和敏感信息保护 |
协作模式怎么讲
Supervisor 模式
- 适用场景：需要中央调度的任务。
- 优点：控制权集中，容易管理。
- 风险：Supervisor 可能成为瓶颈，单点失败。
Planner-Executor 模式
- 适用场景：任务可以明确拆解成子任务。
- 优点：职责清晰，Planner 负责规划，Executor 负责执行。
- 风险：Planner 可能拆解不合理，Executor 可能执行偏差。
Debate / Review 模式
- 适用场景：需要审查和验证的任务。
- 优点：执行和审查分离，减少错误。
- 风险：Reviewer 可能过于严格或过于宽松。
Pipeline 模式
- 适用场景：任务有明确的先后顺序。
- 优点：流程清晰，每个 Agent 处理一个阶段。
- 风险：某个阶段失败会影响整个流程。
Blackboard / Shared State 模式
- 适用场景：需要多个 Agent 共享信息。
- 优点：信息共享灵活，Agent 可以按需读取。
- 风险：状态管理复杂，需要控制共享范围。
Human-in-the-loop 模式
- 适用场景：需要人工确认或决策的任务。
- 优点：关键节点有人工把关。
- 风险：人工响应速度可能成为瓶颈。
状态共享怎么讲
多 Agent 不能共享全部上下文。应该共享的内容：
task_id：任务唯一标识。run_id：执行唯一标识。- 任务目标：所有 Agent 都需要知道整体目标。
- 当前状态摘要：让其他 Agent 了解当前进度。
- 已完成步骤：避免重复工作。
- 工具结果摘要：如果一个 Agent 的结果对另一个有用。
- 待处理事项：接下来要做什么。
- 最终输出要求：确保最终结果符合预期。
不应该随意共享的内容：
- 无关对话历史：其他 Agent 不需要知道所有对话细节。
- 敏感信息：用户密码、Token 等不应该在 Agent 间传递。
- 低价值中间内容：过多的中间数据会增加上下文负担。
- 未确认推测：一个 Agent 的推测不应该被其他 Agent 当作事实。
- 其他 Agent 的完整上下文：每个 Agent 只需要和自己任务相关的信息。
工具权限怎么讲
不同 Agent 应该有不同工具权限：
- Planner：只能拆任务，不直接修改数据。
- Executor：能调用业务工具，如数据库查询、API 调用。
- Reviewer：只读检查结果，不能执行修改操作。
- Human Approval：处理高风险动作，如删除数据、发送消息。
面试表达：
多 Agent 系统里，工具权限必须按角色和风险分级。如果所有 Agent 都能调用所有工具，安全风险会成倍增加。我会为每个 Agent 定义工具白名单，高风险工具需要审批。
Trace 怎么讲
多 Agent Trace 要记录：
run_id：任务执行唯一标识。agent_id：执行操作的 Agent 标识。step_id：当前步骤标识。message：Agent 的输入和输出。tool_call：工具调用的名称、参数和结果。state_change：任务状态的变化。error_event：错误信息和处理方式。reviewer_comment：审查者的反馈。final_result：最终结果。
面试表达：
我会记录每个 Agent 的执行步骤和工具调用，这样可以复盘任务是如何被分派、执行、审查和聚合的。当结果不理想时，可以通过 Trace 定位是哪个 Agent 出了问题——是 Planner 拆解不合理、Executor 执行偏差、还是 Reviewer 没有发现问题。
结果聚合怎么讲
多 Agent 最终不是简单拼接答案。Aggregator 需要处理：
- 信息去重：不同 Agent 可能产出重复信息。
- 冲突识别：不同 Agent 可能给出不同结论。
- 结果排序：按重要性或置信度排序。
- 证据引用：标注每个结论的来源。
- 置信度说明：说明哪些结论是确定的，哪些是推测。
- 最终格式统一：确保输出格式一致。
- 不确定性说明：对于不确定的内容，明确告知用户。
冲突处理怎么讲
冲突来源：
- 不同 Agent 给出不同结论。
- 工具返回不一致。
- Planner 分派不合理。
- Reviewer 否定 Executor 结果。
- 用户目标变化。
处理方式：
- 引入 Reviewer：审查 Agent 的输出是否正确。
- 回到 Planner 重分解：如果任务拆解不合理，重新规划。
- 请求更多证据：如果结论不一致，需要更多数据支持。
- 人工确认：关键决策需要人工确认。
- 记录冲突原因：把冲突记录到 Trace，用于后续分析。
- 冲突样本进入评测集：把冲突案例积累起来，用于改进系统。
多 Agent 怎么评测
| 指标 | 关注点 |
|---|---|
| Task Success Rate | 任务是否被正确完成 |
| Collaboration Efficiency | 协作是否高效，是否有不必要的来回 |
| Tool Call Accuracy | 工具调用是否准确 |
| Conflict Resolution Rate | 冲突是否被正确解决 |
| Human Intervention Rate | 需要人工干预的频率 |
| Latency | 执行延迟是否可接受 |
| Cost | token 消耗和工具调用成本 |
| Final Answer Quality | 最终答案的质量 |
| Safety Violation Rate | 是否有安全违规 |
面试要强调：不能只看最终答案，还要看协作过程是否稳定、是否过度调用、是否成本过高。
常见追问
追问 1：多 Agent 比单 Agent 好在哪里？
回答要点：多 Agent 适合复杂任务拆解、多专业能力协作、执行和审查分离。但不是所有场景都需要多 Agent，简单任务用单 Agent 更高效。
追问 2：多 Agent 会不会增加复杂度？
回答要点：会。多 Agent 需要处理调度、状态共享、冲突解决、结果聚合等问题。只有当任务复杂度确实需要时，才值得引入多 Agent。
追问 3：怎么避免多个 Agent 互相循环？
回答要点：设置最大 step 数、最大耗时、状态变化检测。如果多个 Agent 之间来回传递但没有进展，强制停止。
追问 4：怎么共享状态？
回答要点：通过 Shared Blackboard 或消息传递。只共享任务目标、当前状态摘要、已完成步骤和工具结果摘要，不共享无关对话历史和敏感信息。
追问 5：怎么处理冲突？
回答要点：引入 Reviewer、回到 Planner 重分解、请求更多证据、人工确认。记录冲突原因到 Trace，冲突样本进入评测集。
追问 6：怎么做工具权限？
回答要点：为每个 Agent 定义工具白名单，高风险工具需要审批。Planner 只能拆任务，Executor 能调用业务工具，Reviewer 只读。
追问 7：怎么评测协作效果？
回答要点：从任务完成率、协作效率、工具调用准确率、冲突解决率、人工干预率等维度评估。不能只看最终答案。
追问 8：什么时候不该用多 Agent？
回答要点：简单问答、单轮检索、明确固定流程、没有协作需求、没有评测标准的场景。
容易踩坑的回答
- 只讲角色名——"规划 Agent、执行 Agent、审查 Agent"，没有讲协作机制。
- 把多 Agent 说成多个 Prompt——面试官会觉得你只是写了多个 system prompt。
- 不讲调度机制——面试官会觉得你不知道谁来分配任务。
- 不讲状态共享——面试官会觉得你不知道 Agent 之间怎么传递信息。
- 不讲工具权限——面试官会觉得你没有安全意识。
- 不讲 Trace——面试官会觉得你不知道怎么追踪多 Agent 执行。
- 不讲 Evaluation——面试官会觉得你不知道怎么评估协作效果。
- 不讲停止条件——面试官会觉得你没有考虑系统稳定性。
- 不讲成本和延迟——面试官会觉得你没有生产意识。
更好的表达方式
| 不推荐表达 | 更好的表达 |
|---|---|
| 我用了规划 Agent、执行 Agent、审查 Agent | 我设计了 Supervisor 调度、Specialist 执行、Reviewer 审查、Aggregator 聚合的协作结构 |
| 多 Agent 就是多个角色聊天 | 多 Agent 是任务协作系统，核心是调度、状态共享、工具权限和冲突处理 |
| Agent 之间互相通信 | 我用 Shared Blackboard 共享任务状态，只传递必要信息，避免上下文污染 |
| 每个 Agent 都能调用所有工具 | 不同 Agent 有不同工具权限，高风险工具需要审批 |
| 最后把结果拼起来 | Aggregator 需要处理信息去重、冲突识别、证据引用和不确定性说明 |
| 测试一下就知道效果 | 我从任务完成率、协作效率、工具准确率、冲突解决率等维度评估 |
| 多 Agent 比单 Agent 更好 | 只有当任务复杂度确实需要时才值得引入，简单任务用单 Agent 更高效 |
| 直接部署就行了 | 需要监控协作延迟、token 消耗、冲突率和人工干预率 |
对个人项目的启发
项目 B（多 Agent 运营中台 Copilot）：
可以围绕运营中台 Copilot 设计多 Agent 协作。面试表达时重点讲规划思路：任务分派机制、工具权限隔离、共享状态协议、Trace 记录、Evaluation 指标。不能只讲"有规划 Agent、执行 Agent"，要讲清楚协作机制、冲突处理和评测体系。Project B 已整理为作品集入口，本文只保留面试表达角度。
项目 A（RAG 工单系统）：
项目 A 不一定需要多 Agent。可以先把 RAG、Trace、Evaluation 做扎实。只有当任务复杂度上升时，再考虑引入多 Agent——比如检索 Agent + 生成 Agent + 审查 Agent 的分离结构。
后续 TODO
- 补充多 Agent 系统设计图。
- 补充多 Agent 3 分钟面试口述稿。
- 补充多 Agent 与单 Agent 对比表。
- 补充项目 B 的多 Agent 面试表达草稿。