面试重点不是堆 Agent 数量，而是说明为什么需要多个执行角色，以及它们如何分工、通信、管理状态、控制权限和处理失败。
💡 答案要点
先给结论： Orchestrator-Worker 适合需要集中分解、权限控制、状态管理和结果汇总的任务，因此是常见起点，但不是唯一生产拓扑。事件驱动、队列 Worker 或点对点协作也可能合适；应根据任务依赖、共享状态、吞吐和一致性要求选择。
三类常见反模式：
| 反模式 | 现象 | 危害 | 识别方法 |
|---|---|---|---|
| 伪多体 | 把几个调 LLM 的函数包装成"多 Agent"，没有真实分工 | 本质是单 Agent 套壳，复杂度白加，出了问题还难排查 | 各"Agent"职责是否重叠、是否共享全部上下文 |
| 无契约通信 | Worker 任意互发自然语言消息，没有 Schema、身份或追踪信息 | 状态难以推断，权限和审计边界不清 | 检查消息契约、trace、幂等与权限 |
| 无限循环 | 动态路由没设终止条件，Agent A→B→A 反复横跳 | token 成本爆炸、任务永远完不成 | 没设最大轮数/循环检测/超时熔断 |
可选的职责划分（不要求每项都是独立 Agent）：
规划 Agent（Planner）：拆解任务、分配执行节点
执行 Agent（Worker）：调用工具完成具体任务，无状态、干完就走
评审 Agent（Critic）：校验结果、纠错打回（对抗验证）
状态/记忆层（Memory）：保存任务状态和必要上下文，通常更适合确定性基础设施手撕场景题：自动处理客服工单的 Agent 架构
工单接收 → 意图分类 → 信息提取 → 方案匹配 → 自动处理 → 归档
角色拆分：
- 分类 Agent：意图识别（退款/咨询/投诉/技术问题）
- 知识库 Agent：检索 FAQ/方案（RAG）
- 执行 Agent：调工单系统、发通知、改状态
- 人工兜底流程：证据不足或高风险操作转人工
关键设计：
- 置信度阈值：低于阈值不自动执行，转人工
- 全流程留痕：每一步决策、依据、结果可回溯（审计）
- 每个 Worker 只做一件事，做完退出，不关心全局任务常见追问：
- 早期决策被挤出上下文时，如何用结构化状态、证据引用和检查点避免漂移？
- 动态路由陷入循环时，如何通过步骤预算、状态重复检测、超时和人工接管止损？
面试话术：
"客服工单不必把每一步都做成 Agent。我会先用工作流编排分类、检索、策略判断和受控执行；只有确实需要开放式推理的环节才调用 Agent。每个角色使用结构化输入输出和最小权限，任务状态由确定性存储维护，并设置步骤、时间与成本预算。证据不足或高风险动作进入人工审批，完整 trace 用于审计和复盘。"
版本: v3.129 | 更新: 2026-08-14 | by 二狗子 🐕