多 Agent 协同如何分工?

回答与解析

示例：分层编排 + 标准消息协议

以客服工单为例，可设置 Router、领域 Specialist 和 Validator 三类角色。Router 识别任务并拆分步骤，Specialist 处理退款、物流等受限动作，Validator 核对证据、权限和结果；高风险或不确定任务转人工。

通信与状态

消息使用版本化 Schema，至少包含 task_id、step_id、发送方、接收方、输入引用、截止时间、幂等键和状态。共享状态保存到有访问控制的任务存储中，消息只传引用和最小必要数据。每个步骤明确输入、输出、权限、成功条件与重试策略，避免 Agent 仅靠自然语言猜测职责。

协同机制

• 任务分配：按能力、权限、成本和当前负载路由；无匹配能力时拒绝或回退。
• 并行与依赖：独立子任务并行，有依赖的步骤通过 DAG 或状态机排序。
• 冲突处理：对有副作用的资源使用幂等键、版本控制或唯一租约，验证失败不直接提交。
• 失败处理：超时、重试次数、熔断和人工回退按任务风险及 SLA 配置，不使用统一固定秒数。
• 验证：关键结果由确定性规则、外部事实源或独立 Validator 检查，并保存审计轨迹。

这种设计便于模块化扩展和故障隔离，但会增加通信延迟、状态一致性和调试成本。是否采用固定分层、合同网或动态规划，应根据任务依赖、Agent 数量和失败成本通过仿真与线上指标决定，不存在“超过三层或十个 Agent 就必须切换协议”的通用阈值。

口语版讲法(约2分钟)

• 一句话定位：协同机制本质是平衡灵活性和解耦
• 场景：智能客服工单系统，分层角色+消息总线
• 设计原理：解耦、超时熔断、令牌机制
• 落地风险：延迟、状态一致性、角色边界
• 取舍：固定分层 vs 动态分配，看规模

我会用客服工单说明“分层编排加标准消息协议”。Router 负责识别任务和拆分步骤，退款、物流等 Specialist 只执行被授权的领域动作，Validator 核验证据、权限和结果；高风险或证据不足时转人工。

消息使用版本化 Schema，至少包含 task id、step id、发送方、接收方、输入引用、截止时间、幂等键和状态。共享状态放在有访问控制的任务存储里，消息只传最小必要数据。每个步骤明确输入、输出、权限、成功条件和重试策略，避免 Agent 靠自然语言猜职责。

独立子任务可以并行，有依赖的步骤通过 DAG 或状态机排序。对退款、发券等副作用操作，要用幂等键、版本控制或唯一租约保证只有一次提交；验证失败不能直接写业务系统。超时、重试上限、熔断和人工回退应按任务风险与 SLA 配置，不存在统一的五秒硬限。

这种设计便于模块独立迭代和故障隔离，但会增加通信延迟、状态一致性和调试成本。采用固定分层、动态任务分配还是合同网，应根据依赖图、Agent 数量、失败成本和压测结果决定，不能用层数或 Agent 数量的固定阈值替代验证。路由器发布新版本时，我会先做影子流量和任务回放，确认步骤分配、越权拦截与失败回退没有退化，再按租户逐步放量；一旦重复副作用率上升，就停止扩量并回滚编排版本。

最后我会验证端到端任务成功率、重复副作用、人工接管率、延迟分位数、消息重试和单位任务成本，并通过故障注入检查超时、节点失联和重复投递时的行为。

关键一句:状态一致性维护的代价：Saga模式补偿 vs 强一致性 vs 最终一致性的取舍

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商客服的多智能体系统，用户问一句“我的订单怎么还没到”，可能同时触发物流、退款、投诉多个Agent。你怎么设计它们之间的协作，才能又快又不打架？

2. 问法 2 · 层层追问

   多个AI Agent协作你一般怎么让它们沟通？……如果角色很多，谁来调度？……再进一步，两个Agent争同一个任务怎么办？比如一个工单既被退款Agent处理又被物流Agent处理，怎么避免重复？

3. 问法 3 · 直球架构

   设计一个多智能体系统的协同机制，包括角色分工、通信协议和冲突解决。要求说清楚设计原理、优势和一个具体挑战。你可以选一个场景比如工单处理来举例。