多 Agent 协作框架的自我进化之路

BUG店长

396人浏览 · 2026-05-24 23:22:05

BUG店长 · 2026-05-24 23:22:05 发布

关键词： 多 Agent 协作、自我修复、框架进化、Agent Bridge、Amazon 铺货系统

摘要

本文记录了多 Agent 协作框架从"能管理项目"到"能管理自己"的演进过程。在一次连通性测试中意外发现框架自身的模型映射 Bug，由此触发了从问题发现、根因排查、代码修复、回归测试到业务验证的完整闭环。这次经历不仅修复了一个关键基础设施问题，更重要的是验证了框架的自我诊断与自我优化能力。

二、架构背景：从远程 API 到真正的多 Agent 协作

2.1 中转切换与深层问题

原有的 API 中转服务被关闭后，系统切换到 packyapi 作为新的中转。但在切换过程中，发现了一个更深层的问题：

整个框架之前调用的并不是 Claude Code CLI，而是远程大模型 API。

这意味着之前的"多 Agent 协作"本质上是——零在中间当路由器，把任务转给远程 LLM，再把响应转回来。Agent 之间没有真正的终端交互，没有独立的工作空间隔离，也没有真正的工具调用能力。

2.2 调整为真正的 Claude CLI 调用

发现问题后，调整了通讯方式：Agent Worker 直接通过 spawn 调用本地的 Claude CLI 二进制文件，每个 Agent 拥有独立的 tmux 会话、git worktree 和独立的 API key。

结果： 实现了真正的多 Agent 协作——每个 Agent 独立运行在自己的终端环境中，通过共享文件和 Git 实现状态同步。每个 Agent 能读写文件、执行命令、操作 git，是真正的"开发者"而不是"对话机器人"。

代价： 比原来的远程 API 调用慢了几秒（每个任务约多 5-8 秒），但完全可接受。换来的是真正的隔离性、可追溯性和工具能力。

一、背景：多 Agent 协作架构概览

1.1 团队角色

代号	职责	模型
零 (Zero)	PM / 协调员 / 架构师	qwen3.6-plus/deepseek-v4-pro
老钱 (laoqian)	前端开发	claude-haiku-4-5/claude-sonnet-4-6
老六 (laoliu)	后端开发	claude-sonnet-4-6/claude-opus-4-7
老严 (laoyan)	测试 / Bug 排查	claude-sonnet-4-6/claude-opus-4-7

1.2 基础设施

Agent Bridge：基于 Claude CLI + tmux + worktree 的 MCP 桥接服务
Agent Worker：负责接收任务 → 调用 Claude CLI → 返回结果的执行器
共享存储：通过 Obsidian + git 实现跨 Agent 状态同步
飞书通知：任务完成/失败自动推送

二、问题发现：三个 Agent 两个挂掉

2.1 现象

早上进行一次简单的连通性测试——给每个 Agent 发一个"回复联通正常"的任务。结果：

老钱（haiku 模型）：8 秒完成，正常 ✅
老严（sonnet 模型）：5 分钟超时，无任何输出 ❌
老六（sonnet 模型）：5 分钟超时，无任何输出 ❌

特征非常明确：所有用 haiku 的正常，所有用 sonnet 的卡死。

2.2 排查路径

排查过程遵循"从现象到根因"的递进式方法：

第一步：看日志

[调用 Claude CLI: model=claude-sonnet-4-20250514, agent=laoliu]

之后没有任何输出——没有完成日志，没有错误日志，什么都没有。

第二步：看进程
Worker 进程（PID 53901）活着，但没有 spawn 出任何 Claude CLI 子进程。说明进程要么启动失败秒退，要么卡住了。

第三步：看 tmux
tmux 会话里只剩空 shell 提示符。Claude CLI 已退出，但没留下 stderr。

第四步：直接测试（关键转折点）

# 测试 1：短参数 + 短模型名
claude -p "say hi" --model claude-sonnet-4-6
# 结果：秒回 ✅

# 测试 2：长参数 + 短模型名
claude --print "回复OK" --model claude-sonnet-4-6
# 结果：秒回 ✅

# 测试 3：长参数 + 长模型名
claude --print "回复OK" --model claude-sonnet-4-20250514
# 结果：30 秒超时，无输出 ❌

第五步：定位代码
在 agent-worker.js 第 544 行找到模型映射表：

const cliModelMap = {
    "claude-haiku-4-5-20251001": "claude-haiku-4-5-20251001",  // 恒等
    "claude-sonnet-4-6": "claude-sonnet-4-20250514",            // ← 问题在这
    "claude-opus-4-7": "claude-opus-4-20250514",
};

Worker 在调用 Claude CLI 时，会通过这个映射把 claude-sonnet-4-6 转成 claude-sonnet-4-20250514，然后传给 --print 模式。

2.3 根因分析

直接原因： packyapi 中转 API 的 Claude CLI 在 --print 模式下不接受 claude-sonnet-4-20250514 这个长模型名，导致进程卡死无响应。

深层原因： 模型名映射是在早期基于官方 Claude CLI 的文档设计的，官方 CLI 使用 YYYYMMDD 格式的长模型名。但切换到 packyapi 中转后，这个中转服务只识别短模型名，而映射表没有同步更新。

为什么老钱没事： haiku 的映射恰好是恒等映射（claude-haiku-4-5-20251001 → claude-haiku-4-5-20251001），所以不受影响。

讽刺之处： 这个映射的本意是"让模型名更标准"，结果反而成了系统里最不稳定的一环。

2.4 修复

将映射表全部改为恒等映射：

const cliModelMap = {
    "claude-haiku-4-5-20251001": "claude-haiku-4-5-20251001",
    "claude-sonnet-4-6": "claude-sonnet-4-6",     // 短名用短名
    "claude-opus-4-7": "claude-opus-4-7",         // 短名用短名
};

同时：

超时时间从 5 分钟 → 10 分钟（全面排查类任务耗时较长）
清理了残留的旧 worker 进程和队列文件

2.5 验证

修复后三个 Agent 全部恢复正常：

Agent	模型	耗时	结果
老严	sonnet-4-6	6 秒	✅ 老严联通正常
老钱	haiku-4-5-20251001	7 秒	✅ 老钱联通正常
老六	sonnet-4-6	5 秒	✅ 老六联通正常

三、业务验证：项目 Bug 修复全流程

框架修复后，立刻进入业务验证阶段——对一个项目进行全面的 Bug 排查和修复，完整走了一遍标准流程：

第一步：老严排查
老严执行全面排查，10 个测试用例中发现 7 个 Bug（1 个 P0、3 个 P1、3 个 P2）。

第二步：并行修复
老六修 4 个后端 Bug，老钱修 3 个前端 Bug，并行执行，5 分钟内完成。

第三步：老严验证
修完后老严做回归验证，确认全部通过。

第四步：交叉校验（重点）
后续新增功能（文件管理升级、在线编辑、下载）时，严格遵循零分析 → 老严 opus 交叉校验 → 确认方案 → 老六/老钱开发 → 老严验证的标准流程。

老严在交叉校验中发现多次方案遗漏：

文件管理升级：发现 file_id 设计冲突、清洗不写磁盘、级联删除遗漏等 7 个问题，直接打回重做
在线编辑 + 下载：发现下载接口路径错误（直接 404）、上传到亚马逊是异步 5 步流程不可一次完成等严重问题
前端 Bug 修复：发现 handleSave 缺 columns 字段、page_size 超限、下载未取 .data 等 3 个 P1 Bug

零的角色：不是亲自修代码，而是排查问题、写分析方案、分派任务、跟踪进度、汇报结果。

老严的价值：用 opus 模型做深度交叉校验，多次发现 PM 分析中的遗漏，避免了"带着 Bug 上线"。这是整个流程中最关键的一环——没有交叉校验，PM 的方案就可能带着盲点进入开发。

四、框架自我进化：从"管项目"到"管自己"

4.1 过去的问题

多 Agent 协作框架从 2026-03-10 设计以来，一直有一个隐性缺陷：

框架能管理项目，但不能管理自己。

具体表现：

框架出 Bug → 只能 PM（零）亲自来排查、修代码 → 退化回"单人开发"
模型不兼容 → 没有自动检测 → 发现问题纯靠运气
配置变更 → 没有回归测试 → 同样的坑可能反复踩
经验没沉淀 → 修完就忘 → 下次还犯

4.2 今天的闭环

今天完成了第一次完整的框架自我修复闭环：

发现问题（老严老六不通）
    ↓
排查根因（搜索日志 → 对比测试 → 定位映射表）
    ↓
修复代码（改映射为恒等映射）
    ↓
回归验证（重新测试三个 Agent）
    ↓
业务验证（亚马逊项目 7 个 Bug 全流程）
    ↓
经验沉淀（写入 MEMORY.md）

4.3 "自我框架优化"的定义

从今天起，多 Agent 协作框架具备了自我优化能力，包含四个层次：

层次一：自动诊断

框架有能力检测自身运行状态。当 Agent 不通时，不是等用户报告，而是通过连通性测试主动发现。

层次二：驱动修复

发现问题后，不是 PM 亲自修代码，而是按照标准流程：PM 排查 → 老六修后端 → 老钱修前端 → 老严验证。框架的修复也走和业务发展一样的标准流程。

层次三：修 Bug 验证

老钱修前端引入新 Bug → 启动时编译失败 → 立即检测并修复。这是"修复-验证"循环的体现。

层次四：经验沉淀

今天的模型映射问题 → 记录到 MEMORY.md → 下次换 API 或改模型时自动参考。

4.4 进化路线图

┌──────────────────────────────────────────────────────────┐
│ V1 (过去)                                                │
│ 多 Agent 做项目 → PM 修框架 Bug → 框架不能修自己         │
├──────────────────────────────────────────────────────────┤
│ V2 (今天)                                                │
│ 多 Agent 做项目 → PM 排查框架 Bug → PM 修 → 经验沉淀     │
├──────────────────────────────────────────────────────────┤
│ V3 (下一步)                                              │
│ 多 Agent 做项目 → 框架自动检测自身问题 → 驱动老六修框架  │
│ 包含：自动连通性测试 + 模型兼容性验证矩阵                │
├──────────────────────────────────────────────────────────┤
│ V4 (目标)                                                │
│ 框架持续自我优化 → PM 只审批 → 不亲自动手                │
│ 包含：自动回归测试 + 代码审查 + 部署前验证               │
└──────────────────────────────────────────────────────────┘