关于ImToken智能合约交互
2026/5/16 19:35:29
多 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 出现三次越位行为：
- 收到 Bug 后自行排查代码，而非分派测试
- 测试报告产出后自行修复 Bug，而非分派开发
- 收到新的技术问题后再次自行排查
4.2 原因分析
给 Agent 编写流程文档不等于其会严格遵守。语言模型存在惯性倾向——收到问题后倾向于直接给出解决方案，而非走分派流程。
4.3 解决方案
在操作链中增加确认闸门：
- 交互类型区分— 对话类（聊天/讨论方案）由 PM 直接响应；技术操作类（Bug 排查/代码修复）必须先分派
- 分派前确认— 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
如果你觉得这篇文章对你有帮助，欢迎点赞收藏。有问题可以在评论区交流。