多 Agent 协同最难的不是通信，而是状态：分工、死锁和冲突治理实践

多智能体系统常见的错误设计是：

一个任务 -> 多个 Agent -> 大家自由交流 -> 生成最终结果

这种方式在简单 Demo 中可能有效，但进入生产环境后，很容易出现：

• 消息重复；
• 任务抢占；
• 状态覆盖；
• 循环等待；
• 结果互相矛盾；
• 无法追溯最终结论。

更工程化的设计是把多智能体系统拆成：

任务编排
  ->
受控通信
  ->
状态管理
  ->
结果评估
  ->
人工确认或提交

1. 分工：每个 Agent 只负责一种结果

以连锁零售促销活动为例：

Planner
  -> 拆解活动目标和任务依赖

Customer Agent
  -> 输出目标客群和活动建议

Inventory Agent
  -> 输出库存、门店和执行约束

Copy Agent
  -> 生成活动文案草稿

Evaluator
  -> 合并结果并检查冲突

需要注意的是，Agent 的职责不能只写在名称里，还要限制它的输入和输出。

例如库存 Agent 的输出可以包含：

{
  "stock_limit": 1200,
  "covered_stores": ["S001", "S002"],
  "source_time": "2026-08-06T10:00:00Z",
  "status": "confirmed"
}

但不能让库存 Agent 直接修改活动预算或活动文案。

2. 通信：不要让 Agent 只发自然语言

建议每条消息带上：

task_id
parent_task_id
sender
receiver
message_type
version
status
source
timestamp
expires_at

其中 version 很关键。

如果 Evaluator 收到两个库存结论：

• 版本 2：库存 800；
• 版本 3：库存 1200；

它不能根据消息到达顺序判断，而应该根据数据时间和来源确认哪个版本有效。

3. 冲突：先区分冲突类型

事实冲突

两个 Agent 给出的数据不一样。

解决方法是检查数据源、时间和范围。

目标冲突

一个 Agent 想扩大活动范围，另一个 Agent 受预算限制。

解决方法是让 Planner 提前定义优先级，而不是让模型临时争论。

权限冲突

一个 Agent 没有库存访问权限，不能通过别的 Agent 间接拿到完整库存数据。

版本冲突

旧结果晚到，覆盖了新结果。

解决方法是使用版本号、乐观锁和提交状态。

4. 死锁：把依赖关系显式化

死锁往往不是模型“卡住”，而是任务图设计出了环。

错误示例：

文案 Agent 等库存 Agent
库存 Agent 等文案 Agent

正确方式是先由 Planner 生成 DAG：

Planner
  -> 客群分析
  -> 库存检查
客群分析 + 库存检查
  -> 文案生成
文案生成
  -> Evaluator

执行层还需要：

• 依赖环检测；
• 超时；
• 最大等待时间；
• 重试上限；
• 备用节点；
• 人工接管；
• 任务取消。

5. 结果矛盾：Evaluator 不能只是最后润色

Evaluator 的作用不是把两份答案拼在一起，而是验证：

• 是否回答了原始目标；
• 是否满足预算和库存约束；
• 是否使用最新事实；
• 是否引用了可追溯来源；
• 是否存在未解决冲突；
• 是否超出 Agent 权限。

最终结果最好包含：

结论
采用依据
未采用结果
未解决冲突
需要人工确认的事项

6. 运行时状态建议

可以把任务状态设计成：

CREATED
PLANNED
RUNNING
WAITING
CONFLICT
RETRYING
EVALUATING
APPROVED
HUMAN_REVIEW
FAILED
CANCELLED

不要只使用“成功”和“失败”两个状态。

例如某个 Agent 返回结果，但结果与库存约束冲突，它应该进入 CONFLICT，而不是被标记为成功。

7. Haoee 中的交付边界

它适合帮助交付伙伴创建和运营智能体、管理知识库、Skills、MCP Server 和评估规则。

如果客户需要真正的企业级多智能体运行环境，还需要进一步配置：

• 任务队列；
• 消息服务；
• 分布式锁；
• 统一身份；
• 租户隔离；
• 审计日志；
• 失败恢复；
• 版本和回滚。

今天的新多智能体案例没有因 MCP 鉴权阻塞而完成实际创建，因此本文的促销协同链路是设计示例，不是已发布生产方案。