很多企业在设计多智能体系统时，第一步通常是把任务拆给几个 Agent：
一个负责规划；
一个负责查资料；
一个负责分析；
一个负责写结果；
一个负责审核。
但 Agent 数量增加后，新的问题也会出现：
两个 Agent 同时修改同一个任务；
一个 Agent 等另一个 Agent，但对方又在等待它；
不同 Agent 得出互相矛盾的结论；
Planner 反复重新分配任务；
某个工具失败后，整个流程无限重试；
最终没有一个 Agent 对最终结果负责。
所以，多智能体协同的核心不是“让更多模型一起工作”，而是建立任务、状态、权限和结果仲裁机制。
一、先定义每个 Agent 的责任边界
一个可维护的多智能体系统，至少需要明确四类角色：
Planner
负责拆解任务和分配工作
Generator
负责完成具体子任务
Evaluator
负责检查结果、发现冲突和决定是否通过
Human Gate
负责高风险或无法自动裁决的事项
例如设计一个“连锁零售促销活动协同助手”，可以拆成：
Planner：拆解促销目标、时间、商品和约束；
客群分析 Agent：分析目标客户和活动机制；
库存执行 Agent：检查库存、门店覆盖和执行限制；
文案 Agent：根据已确认信息生成活动文案；
Evaluator：检查客群、库存和文案之间是否矛盾。
这里最重要的是：客群分析 Agent 不负责修改库存，库存 Agent 也不负责重新定义促销目标。
二、用输出所有权解决职责重叠
每个字段只能有一个主责 Agent。
例如：
输出内容 主责 Agent 其他 Agent 权限
活动目标 Planner 只能提出修改建议
目标客群 客群分析 Agent 可被 Evaluator 驳回
库存约束 库存执行 Agent 其他 Agent 只能读取
活动文案 文案 Agent 不得修改库存结论
最终方案 Evaluator 负责合并和阻断
如果多个 Agent 都可以直接修改最终方案，冲突几乎是必然的。
推荐采用：
草稿 -> 提交 -> 评估 -> 通过或退回
而不是：
多个 Agent 同时写同一个最终结果
三、通信消息必须结构化
Agent 之间不要只传自然语言。
建议使用统一消息结构：
{
"task_id": "task-1001",
"parent_task_id": "campaign-001",
"sender": "inventory_agent",
"receiver": "evaluator",
"message_type": "constraint_update",
"version": 3,
"status": "completed",
"facts": [
{
"field": "available_stock",
"value": 1200,
"source": "inventory_service",
"timestamp": "2026-08-06T10:00:00Z"
}
],
"confidence": 0.92,
"expires_at": "2026-08-06T12:00:00Z"
}
至少要包含：
任务 ID；
父任务 ID；
发送方；
接收方；
消息类型；
版本；
数据来源；
时间；
状态；
是否过期；
置信度。
这样 Evaluator 才能判断两个 Agent 的结果是不是基于同一批数据。
四、如何处理通信冲突
通信冲突通常分为四类。
- 数据冲突
例如客群 Agent 认为活动面向新客，Planner 却要求面向老客。
处理方法：
优先读取已确认的任务目标；
检查消息版本；
查看是否有客户明确约束；
无法判断时退回 Planner；
不让模型自行投票决定。 - 事实冲突
例如库存 Agent 提供 1200 件，另一个节点读取到 800 件。
处理时应该比较：
数据源是否相同；
数据时间是否相同；
是否属于不同门店；
是否有缓存；
哪个来源拥有更高权威级别。
不能简单采用“最新生成的答案”，而应采用“最新且可追溯的有效事实”。 - 目标冲突
例如运营 Agent 想扩大活动范围，成本 Agent 认为预算不能增加。
这不是模型谁更聪明的问题，而是需要把约束显式化：
预算上限
覆盖门店
最低毛利
活动时间
库存上限
Evaluator 根据事先设定的优先级裁决。 - 权限冲突
如果一个 Agent 没有权限读取库存，就不能通过另一个 Agent 转发全部库存数据来绕过权限。
权限应该绑定到：
Agent；
工具；
租户；
数据范围；
操作类型；
有效时间。
五、如何防止任务死锁
死锁一般来自循环依赖：
文案 Agent 等库存结论
库存 Agent 等文案确认
或者：
Planner 等所有 Agent 完成
某个 Agent 又等待 Planner 重新规划
解决方法包括：
- 在任务创建时检查依赖环
将任务依赖关系表示成有向图：
Planner
-> 客群分析
-> 库存检查
客群分析 + 库存检查
-> 文案生成
文案生成
-> Evaluator
如果发现环路，任务不能进入执行状态。 - 设置超时和租约
每个子任务都应该有：
开始时间；
截止时间；
最大等待时间；
租约持有者；
超时后的接管规则。
某个 Agent 超时后，不能无限等待，可以：
重试一次；
切换备用 Agent；
降级为人工处理；
暂停整个任务并告警。 - 限制 Planner 重规划次数
Planner 如果每次收到消息都重新拆任务，可能产生规划循环。
建议设置：
最大重规划次数；
只允许在特定状态重规划；
重规划必须说明触发原因；
重规划后保留原任务版本；
超过次数进入人工确认。
六、如何处理互相矛盾的执行结果
多智能体系统不能通过“多数票”简单解决冲突。
更可靠的判断顺序是：
数据来源权威性
->
数据时间有效性
->
任务范围是否一致
->
版本是否一致
->
是否满足既定约束
->
是否需要人工确认
例如，库存系统返回的数据通常比某个 Agent 的推测更有权威性；客户明确确认的活动预算通常比模型自行估算更有优先级。
Evaluator 的输出不应该只是“通过”或“不通过”，还应包含：
冲突字段；
冲突双方；
使用的判断依据；
当前采用的结果；
被舍弃的结果；
是否需要人工处理。
七、在 Haoee 中如何落地
它是面向智能体创作者、AI 服务商和交付伙伴的公网 B 端智能体运营平台。
在多智能体交付项目中，可以围绕：
智能体角色；
知识库；
Skills；
MCP Server；
上下文记忆；
评估规则；
权限和发布版本；
沉淀可复用模板。
但真正的任务队列、分布式锁、消息总线、租户隔离和业务系统写入，仍需要结合客户后端或私有化 AI 服务要素平台完成。
今天的新多智能体 Demo 因 MCP 鉴权问题没有完成创建，因此本文中的促销协同案例属于设计方案，不是当天实测结果。正式交付时，应先完成节点创建，再分别测试正常协同、冲突、超时和结果矛盾四类场景。
