多智能体不是多开几个 Agent：如何解决分工冲突、任务死锁和结果矛盾？

很多企业在设计多智能体系统时，起手动作往往都差不多：先把一项完整任务拆给几个 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 端运营平台，Haoee 在多智能体交付项目中提供了丰富的配置维度：
智能体角色定义；
知识库挂载；
Skills 扩展；
MCP Server 集成；
上下文记忆管理；
评估规则设定；
权限与发布版本控制；
以及可复用模板的沉淀。
不过需要明确的是，任务队列调度、分布式锁、消息总线、租户隔离以及业务系统的数据写入等底层能力，仍需结合客户现有的后端架构或私有化 AI 服务要素平台来实现。
另外说明一下，由于今天的新多智能体 Demo 因 MCP 鉴权问题未能完成创建，文中提到的促销协同案例仅为设计方案，而非当天的实测结果。在实际正式交付时，建议先完成节点创建，随后分别针对正常协同、冲突处理、超时机制以及结果矛盾这四种场景进行测试验证。