多 Agent 协作架构：从 Bug 响应链路看流程设计的缺失

摘要： 多 Agent 协作框架在角色配置齐全的情况下，实际运行中仍暴露出流程链缺失、通知中断、角色越位等问题。本文基于真实项目中的 Bug 响应场景，记录问题发现、原因分析与方案落地的完整过程。

---

一、背景

多 Agent 协作框架采用四角色架构：

角色	代号	职责
PM/协调员	零 (Zero)	任务拆解、分派、进度跟踪
前端	老钱 (laoqian)	前端代码、UI 开发
后端	老六 (laoliu)	后端代码、API 开发
测试	老严 (laoyan)	Bug 排查、测试报告

框架已实现 workspace 隔离（git worktree）、共享上下文加载、交叉校验机制，底层通信基于 MCP（Model Context Protocol） 协议，而非 ACP。

代码开发完成后的验收流程也已定义：

老钱/老六开发完成 → 老严全链路测试 → 零复核 → 验收/打回

但在实际项目中遇到用户侧 Bug 时，暴露出该流程并未覆盖"用户报 Bug 时的响应链路"。

---

二、问题一：Bug 响应流程缺失

2.1 问题描述

框架定义了"代码开发完成后的验收流程"，但未定义"用户上报 Bug 时的响应流程"。导致 PM Agent 收到 Bug 报告后，直接自行排查代码，而非按职责分派给测试 Agent。

2.2 解决方案

新增用户侧 Bug 响应流程：

用户报 Bug → 零接收并确认分派目标 → 老严排查并输出报告 → 零汇总汇报 → 零分派老钱/老六修复 → 老严验证

关键规则：

• PM 角色不直接参与代码排查和修复
• 收到技术问题后，先明确分派目标，确认后再执行
• 区分交互类型：对话/讨论由 PM 直接响应；Bug 排查/代码修复走分派流程

---

三、问题二：任务完成通知链断裂

3.1 问题描述

测试 Agent 完成 Bug 排查后，将报告写入 results 目录并发送飞书通知，但 PM Agent 的 session 未被唤醒，导致任务完成信息出现 20 分钟空窗期——PM 不知道测试已完成，直到被主动询问才去查询系统状态。

3.2 原因分析

底层 Worker 完成任务后的通知是单向的：写文件 + 发消息。PM Agent 的 session 处于空闲状态，没有机制被自动触发检查任务结果。

3.3 解决方案

放弃轮询方案，采用事件驱动：

方案	实现方式	缺陷
轮询（已废弃）	cron 每 2 分钟检查任务状态	资源消耗大，有延迟
事件驱动（最终方案）	接入框架原生 hooks 机制，Worker 完成时触发 webhook 唤醒 PM session	0 轮询，10 秒内响应

hooks 机制工作流程：

Worker 完成任务 → 触发 completion hook → 调用 webhook → 唤醒 PM session → PM 读取结果并汇报

---

四、问题三：PM 角色越位与惯性操作

4.1 问题描述

在多轮交互中，PM Agent 出现三次越位行为：

1. 收到 Bug 后自行排查代码，而非分派测试
2. 测试报告产出后自行修复 Bug，而非分派开发
3. 收到新的技术问题后再次自行排查

4.2 原因分析

给 Agent 编写流程文档不等于其会严格遵守。语言模型存在惯性倾向——收到问题后倾向于直接给出解决方案，而非走分派流程。

4.3 解决方案

在操作链中增加确认闸门：

1. 交互类型区分 — 对话类（聊天/讨论方案）由 PM 直接响应；技术操作类（Bug 排查/代码修复）必须先分派
2. 分派前确认 — PM 收到技术问题后，先输出分派计划（“我打算分派给谁、做什么”），等待确认后再执行

核心思路：通过强制确认环节阻断惯性操作，而非单纯增加规则数量。

---

五、上一篇文章发布后，部分功能优化

上一篇文章发布后，框架在实际运行中持续迭代，落地了以下功能优化：

优化维度	具体实现
多轮对话上下文	新增 history/ 目录，实现多轮对话记录保存与加载，Agent 可跨 session 延续上下文
Workspace 隔离升级	从"独立目录"方案升级为 git worktree，各角色代码隔离更严格，分支管理更清晰
共享上下文自动加载	Agent 启动时自动加载全局状态文件（如 MEMORY.md、项目配置），无需手动初始化
MCP Server 统一架构	从一开始采用单 Server 架构，避免多 Server 通信带来的复杂度和延迟

---

六、总结：六条实践教训

#	结论	说明
1	配置有 ≠ 流程通	角色配置齐全不等于流程可运行，需实际验证
2	链路断裂比 Bug 更危险	任务完成但无人感知，问题会被掩盖
3	治惯性靠闸门不靠规则	单纯增加规则无效，需在关键节点强制确认
4	能触发就别轮询	事件驱动优于定时轮询，零资源消耗
5	架构是成长出来的，不是设计出来的	第一篇文章写完后，实际运行中又新增了大量优化
6	对话与派活是两件事	不分派和乱分派都不可取，需按场景选择

---

核心观点： 架构不是一次设计完成的，而是在"发现问题 → 修正流程 → 固化机制"的循环中逐步完善的。

上一篇： 《从单 Agent 到多智能体协作：一个真实落地项目的架构演进与实践》

项目地址： 《多 Agent 协作项目》

技术栈： OpenClaw + claudecode（mcp协议） + 飞书 + Gitee

---

如果你觉得这篇文章对你有帮助，欢迎点赞收藏。有问题可以在评论区交流。