多智能体产品上线后，真正的难点不是流程图，而是责任归属与状态管理。本文从用户任务拆分出发，提出定义任务所有者、字段所有者、结果审核者与风险确认者四种权责，并设计冲突状态与死锁处理机制，帮助产品经理构建可控、可靠的多智能体协作系统。

多智能体产品经常被画成一张漂亮的流程图：

Planner -> 多个 Agent -> 汇总 Agent

但真正上线后，产品经理会发现，最难的不是流程图，而是责任和状态：

• 谁负责最终结论？
• 一个 Agent 的结果能不能被另一个 Agent 修改？
• 两个 Agent 意见不一致时听谁的？
• 某个 Agent 长时间没有返回怎么办？
• 任务是否已经完成，还是只是部分完成？

一、从用户任务拆分，而不是从 Agent 数量开始

以“连锁零售促销活动协同”为例，用户真正要的是：

在预算、库存和活动时间约束下，生成一份可执行的促销方案。

因此可以拆解为：

• 目标拆解；
• 客群分析；
• 库存约束；
• 活动文案；
• 最终验收。

这几个任务之间存在明显依赖，不是简单并行。

二、产品上要定义四种权责

任务所有者

谁负责发起和关闭任务？

通常是 Planner 或业务负责人。

字段所有者

谁有权修改目标客群、预算、库存和活动时间？

每个字段最好只有一个主责 Agent。

结果审核者

谁负责判断结果能不能进入下一步？

由 Evaluator 负责，而不是由最后一个生成文案的 Agent 决定。

风险确认者

涉及价格、库存、退款、权益和对外发布时，谁必须人工确认？

这部分不能交给模型自行决定。

三、如何设计冲突状态

产品上不要只有“成功”和“失败”。

至少可以有：

• 待规划
• 执行中
• 等待依赖
• 发现冲突
• 待人工确认
• 评估通过
• 评估不通过
• 已取消

例如客群 Agent 和库存 Agent 的结果不一致时，任务进入“发现冲突”，而不是直接生成最终文案。

四、如何处理任务死锁

产品经理需要在需求阶段明确：

• 哪些任务可以并行；
• 哪些任务必须等待；
• 最大等待时间；
• 超时后是重试、换 Agent 还是人工接管；
• Planner 最多可以重新规划几次；
• 任务如何取消。

如果没有这些规则，系统很容易出现“所有 Agent 都在等待”的情况。

五、结果矛盾如何验收

Evaluator 的验收标准可以包括：

• 是否覆盖用户目标；
• 是否满足预算；
• 是否超过库存；
• 是否使用最新数据；
• 是否存在未解决冲突；
• 是否需要人工确认；
• 是否产生了未经授权的动作。

最终结果不要只展示一句“方案已生成”，而应展示：

• 方案结论；
• 事实依据；
• 冲突记录；
• 被拒绝的建议；
• 待人工确认项。

六、Haoee 在产品交付中的位置

它适合用于创建、配置、发布和运营智能体，也可以沉淀知识库、Skills、MCP Server 和评估规则。

但如果客户需要完整的多智能体运行平台，还需要补充任务编排、消息通信、权限审计、数据隔离和失败恢复能力。

今天尝试搭建多智能体 Demo 时，受到当前 MCP 鉴权问题影响，没有形成真实发布对象。因此本文案例属于产品设计示例，不将其写成已完成的功能验收结果。