夜雨聆风【地球 Online · AI 道具拆解室】
大家好，我是楚歌。 今天和大家聊一聊：【OpenClaw 多 Agent 架构实战：如何避免任务黑屋，让 AI 协作透明可控】 ——
1. 背景与痛点：为什么需要多 Agent 架构
事情是这样的。
最开始我用单 Agent，用户给指令 → Agent 干活 → 出结果。看起来挺简单。
但实际用起来，问题一个接一个。
传统单 Agent 的问题：
用户 → Agent → ??? → 结果
│
└─ 黑屋操作：不知道 Agent 内部做了什么
| 问题 | 描述 | 影响 |
|---|---|---|
| 结果不准确 | 无法追溯原因 | 需要反复重试 |
| 任务复杂时迷失 | Agent 无法处理多步骤任务 | 完成率低 |
| 无法分工协作 | 所有工作由一个 Agent 完成 | 效率低下 |
| 出错难定位 | 不知道哪个环节出了问题 | 修复成本高 |
说白了：就像一个玩家既要打怪又要采药又要炼金还要做任务——不是不能做，是容易累死在副本里。🎮
2. 多 Agent 架构的核心价值
多 Agent 架构：
用户 → COO → CTO → Dev → QA → SRE → 结果
│ │ │ │ │
└─ 每个环节透明可追溯
| 优势 | 说明 | 收益 |
|---|---|---|
| 任务拆解 | 复杂任务分解为多个子任务 | 完成率提升 50%+ |
| 过程透明 | 每个环节有记录 | 问题定位时间减少 80% |
| 专业分工 | 每个 Agent 专注特定领域 | 结果准确率提升 20%+ |
| 易于修复 | 问题定位到具体环节 | 修复成本降低 60% |
核心逻辑：把一个大 NPC 拆成一群小 NPC，各司其职，互不干扰。
3. 7 角色组织架构图
这是我们的多 Agent 团队配置：
┌─────────────┐
│ CEO │ (用户)
└──────┬──────┘
│
┌──────▼──────┐
│ COO │ (首席运营官 - 总协调)
│ qwen3.5 │
└──┬────┬────┼────┬────┬────┐
│ │ │ │ │ │
┌────────▼┐ │ ┌─▼────┼─┐ │ ┌─▼────────┐
│ CTO │ │ │Delivery│ │ │ Growth │
│qwen3-max│ │ │ glm-5 │ │ │ MiniMax │
└────┬────┘ │ └───┬───┘ │ └───────────┘
│ │ │ │
┌─────────┼───────┼──────┼──────┘
│ │ │ │
┌────▼───┐ ┌───▼───┐ ┌─▼────┐
│ Dev │ │ QA │ │ SRE │
│coder+ │ │ kimi │ │coder-│
└────────┘ └───────┘ └──────┘
7 个独立 Bot 账号（飞书）：
| 账号 | App ID | 用途 | 需要@ | 群策略 |
|---|---|---|---|---|
| coo | cli_a9282c4a... | 首席运营官 | ❌ 否 | allowlist |
| cto | cli_a93dde89... | 首席技术官 | ✅ 是 | allowlist |
| delivery | cli_a9253499... | 交付总监 | ✅ 是 | allowlist |
| dev | cli_a93dd7a2... | 研发工程师 | ✅ 是 | allowlist |
| qa | cli_a938d787... | 质量保障 | ✅ 是 | allowlist |
| sre | cli_a938d15f... | SRE 专家 | ✅ 是 | allowlist |
| growth | cli_a938d1ba... | 用户增长官 | ✅ 是 | allowlist |
4. 各角色详细职责
4.1 COO - 首席运营官
| 配置项 | 值 |
|---|---|
| Agent ID | coo |
| 模型 | qwen3.5-plus |
| 上下文窗口 | 1,000,000 tokens |
| 最大输出 | 65,536 tokens |
核心职责：
✅ 需求入口：接收用户消息，理解需求 ✅ 意图识别：L1-L4 四级分类 ✅ 任务拆解：将复杂任务分解为可执行子任务 ✅ 智能路由：根据任务类型分发给对应 Agent ✅ 汇报汇总：收集各角色结果，汇总给 CEO
角色限制：
❌ 不负责技术架构决策（交给 CTO） ❌ 不负责进度追踪（交给 Delivery） ❌ 不直接写代码或测试用例 ❌ 不跳过 CEO 直接修改项目范围
可调用子 Agent：CTO, Dev, QA, SRE, Delivery, Growth（全部）
4.2 CTO - 首席技术官
| 配置项 | 值 |
|---|---|
| Agent ID | cto |
| 模型 | qwen3-max-2026-01-23 |
| 上下文窗口 | 262,144 tokens |
| 最大输出 | 65,536 tokens |
核心职责：
✅ 技术选型：选择合适的技术栈 ✅ 架构设计：设计系统架构 ✅ 技术方案文档输出 ✅ 技术评审：评审 Dev 的代码和方案 ✅ 向 COO 汇报技术风险
角色限制：
❌ 不能代替 Dev 写业务代码 ❌ 不能代替 QA 写测试用例 ❌ 不能代替 COO 修改 PRD ❌ 不能跳过 COO 直接接收用户需求
可调用子 Agent：Dev, QA, SRE
4.3 Dev - 高级研发工程师
| 配置项 | 值 |
|---|---|
| Agent ID | dev |
| 模型 | qwen3-coder-plus |
| 上下文窗口 | 1,000,000 tokens |
| 最大输出 | 65,536 tokens |
核心职责：
✅ 功能开发：根据 PRD 和技术方案实现功能 ✅ 代码审查 ✅ 单元测试编写 ✅ Bug 修复 ✅ 技术文档编写
角色限制：
❌ 不能直接修改生产环境配置 ❌ 不能跳过测试直接发布 ❌ 不能代替 CTO 做技术选型 ❌ 不能代替 QA 写测试用例
可调用子 Agent：QA
4.4 QA - 质量保障专家
| 配置项 | 值 |
|---|---|
| Agent ID | qa |
| 模型 | kimi-k2.5 |
| 上下文窗口 | 262,144 tokens |
| 最大输出 | 32,768 tokens |
核心职责：
✅ 测试用例设计 ✅ 自动化测试实施 ✅ 质量报告输出 ✅ 验收测试执行 ✅ 缺陷跟踪管理
角色限制：
❌ 不能直接修改代码 ❌ 不能代替 COO 验收需求 ❌ 不能跳过测试直接发布
可调用子 Agent：无
4.5 SRE - SRE 专家
| 配置项 | 值 |
|---|---|
| Agent ID | sre |
| 模型 | qwen3-coder-next |
| 上下文窗口 | 262,144 tokens |
| 最大输出 | 32,768 tokens |
核心职责：
✅ CI/CD 配置和管理 ✅ 应用部署和发布 ✅ 监控和告警配置 ✅ 故障处理和复盘 ✅ 成本优化和性能调优
角色限制：
❌ 不能直接修改业务代码 ❌ 不能跳过审批直接发布 ❌ 不能代替 CTO 做技术选型
可调用子 Agent：无
4.6 Delivery - 交付总监
| 配置项 | 值 |
|---|---|
| Agent ID | delivery |
| 模型 | glm-5 |
| 上下文窗口 | 202,752 tokens |
| 最大输出 | 16,384 tokens |
核心职责：
✅ 进度追踪：监控各角色任务进度 ✅ 资源协调 ✅ 阻塞处理：识别和处理项目阻塞 ✅ 风险升级：重大风险升级给 COO ✅ 制定项目排期
角色限制：
❌ 不负责需求分析（交给 COO） ❌ 不负责技术决策（交给 CTO） ❌ 不能直接修改代码 ❌ 不能跳过 COO 直接修改项目范围
可调用子 Agent：Dev, QA, SRE
4.7 Growth - 用户增长官
| 配置项 | 值 |
|---|---|
| Agent ID | growth |
| 模型 | MiniMax-M2.5 |
| 上下文窗口 | 204,800 tokens |
| 最大输出 | 131,072 tokens |
核心职责：
✅ 用户支持和问题解答 ✅ 用户反馈收集 ✅ 满意度追踪 ✅ 主动挖掘用户需求 ✅ 提出产品迭代建议给 COO
角色限制：
❌ 不能直接修改产品功能 ❌ 不能代替 COO 做决策 ❌ 不能承诺未确认的功能
可调用子 Agent：无
5. 任务流转全流程
5.1 标准任务流转图
1. 用户发送消息 (飞书)
│
▼
2. COO Bot 接收 (cli_a9282c4a...)
│
▼
3. COO 意图识别 (L1-L4 分类)
│
├── L1 简单任务 ──→ COO 直接执行
├── L2 标准任务 ──→ 委托单一角色 (CTO/Dev 等)
├── L3 复杂项目 ──→ 多 Agent 并行协作
└── L4 紧急事件 ──→ 升级 CEO + 相关角色
│
▼
4. 子代理执行 (sessions_spawn)
│
├── CTO: 技术方案设计
├── Dev: 功能开发
├── QA: 测试验证
└── SRE: 部署上线
│
▼
5. Delivery 进度追踪
│
├── 定期检查各角色进度
├── 识别阻塞和风险
└── 汇总进度给 COO
│
▼
6. COO 汇总结果 → 回复用户
5.2 意图识别机制（COO 核心能力）
4 级分类系统：
| 级别 | 任务类型 | 触发关键词 | 涉及角色 | 预估时间 | 置信度阈值 | 路由策略 |
|---|---|---|---|---|---|---|
| L1 | SIMPLE | 你好、查询、统计、小修复 | coo | <2 小时 | >0.5 | DIRECT_EXEC |
| L2 | STANDARD | 需求、功能、技术方案、测试 | coo + 1 角色 | <2 天 | >0.7 | DELEGATE |
| L3 | COMPLEX | 项目、系统、架构、重构 | coo + 多角色 | >2 天 | >0.8 | MULTI_AGENT |
| L4 | CRITICAL | 紧急、故障、安全、合规 | coo + CEO + 相关 | 立即 | >0.6 | ESCALATE |
意图识别输出示例：
{
"level": "L2",
"task_type": "STANDARD",
"confidence": 0.85,
"reason": "技术方案设计任务，需要 CTO 介入",
"involved_roles": ["coo", "cto"],
"action": "DELEGATE",
"estimated_hours": 2,
"priority": "P1"
}
路由决策逻辑：
if confidence < 0.6:
action = "CLARIFY" # 置信度低，先澄清
elif "紧急" in input or "故障" in input or "安全" in input:
action = "ESCALATE" # L4 紧急事件
elif "项目" in input or "系统" in input or "架构" in input:
action = "MULTI_AGENT" # L3 复杂项目
elif "需求" in input or "功能" in input:
action = "DELEGATE" # L2 标准任务
else:
action = "DIRECT_EXEC" # L1 简单任务
6. 五种协作方式详解
6.1 方式一：DIRECT_EXEC（直接执行）
适用场景：L1 简单任务
流程：
用户消息 → COO 意图识别 → COO 直接执行 → 回复用户
示例：
用户："今天天气如何？"
COO: (调用天气工具查询) → 回复用户
特点：
✅ 响应快，无需分发 ✅ 适合简单查询、统计类任务 ❌ 不适合复杂任务
6.2 方式二：DELEGATE（委托单一角色）
适用场景：L2 标准任务
流程：
用户消息 → COO 意图识别 → sessions_spawn 委托单一角色 → 等待结果 → 汇总回复
示例代码：
const result = await sessions_spawn({
agentId: "cto",
task: `## 技术方案设计
### 背景
用户需要一个登录系统，支持手机号 + 验证码、邮箱 + 密码、OAuth 三种方式。
### 目标
1. 输出技术方案文档
2. 包含数据库设计、接口设计、安全设计
### 约束
- 技术栈：Node.js + PostgreSQL
- 时间：2 小时内完成
### 验收标准
- 方案经 CTO 评审通过
- 无重大技术风险`,
mode: "run",
timeoutSeconds: 7200,
label: "login-tech-design"
});
// 汇总结果回复用户
return result.output;
特点：
✅ 专业分工，结果更准确 ✅ 适合技术方案、测试策略等专业任务 ❌ 需要等待子代理完成
6.3 方式三：MULTI_AGENT（多 Agent 并行）
适用场景：L3 复杂项目
流程：
用户消息 → COO 意图识别 → 并行启动多个子代理 → 等待所有完成 → 汇总回复
示例代码：
// 并行启动 4 个子代理
const [techResult, devResult, qaResult, sreResult] = await Promise.all([
sessions_spawn({ agentId: "cto", task: "设计技术方案", mode: "run" }),
sessions_spawn({ agentId: "dev", task: "实现功能", mode: "run" }),
sessions_spawn({ agentId: "qa", task: "编写测试用例", mode: "run" }),
sessions_spawn({ agentId: "sre", task: "配置 CI/CD", mode: "run" })
]);
// 汇总所有结果
return {
tech: techResult.output,
dev: devResult.output,
qa: qaResult.output,
sre: sreResult.output
};
特点：
✅ 并行处理，效率高 ✅ 适合大型项目 ❌ 需要协调各角色结果
6.4 方式四：PIPELINE（流水线）
适用场景：有先后依赖的任务
流程：
用户消息 → COO → CTO(设计) → Dev(开发) → QA(测试) → SRE(部署) → 回复用户
示例代码：
// 串行执行，后一个依赖前一个结果
const techPlan = await sessions_spawn({
agentId: "cto",
task: "设计技术方案",
mode: "run"
});
const devResult = await sessions_spawn({
agentId: "dev",
task: `根据以下技术方案实现功能：${techPlan.output}`,
mode: "run"
});
const qaResult = await sessions_spawn({
agentId: "qa",
task: `根据以下代码编写测试：${devResult.output}`,
mode: "run"
});
return qaResult.output;
特点：
✅ 保证执行顺序 ✅ 适合有依赖关系的任务 ❌ 总耗时长（串行）
6.5 方式五：ESCALATE（紧急升级）
适用场景：L4 紧急事件
流程：
用户消息 → COO 识别为紧急 → 立即通知 CEO + 相关角色 → 并行处理 → 汇总回复
示例：
用户："生产环境故障！网站无法访问！"
COO:
1. 立即通知 CEO（用户）
2. 并行启动 SRE（排查故障）、Dev（修复代码）、QA（验证修复）
3. Delivery 追踪进度，每 5 分钟汇报一次
4. 故障解决后汇总报告给用户
特点：
✅ 响应最快 ✅ 适合紧急故障、安全事件 ❌ 资源消耗大
7. 如何避免任务黑屋
任务黑屋：用户不知道 Agent 内部做了什么，只能等结果。
解决方案：
7.1 全程记录
每个子 Agent 的执行过程都记录到会话历史：
const history = await sessions_history({
sessionKey: "cto-xxx",
limit: 50,
includeTools: true // 包含工具调用记录
});
7.2 进度透明
Delivery 角色定期汇总进度：
【项目进度汇报】
- CTO: 技术方案已完成 ✅
- Dev: 功能开发 50% 🔄
- QA: 等待开发完成后开始测试 ⏳
- SRE: 环境已就绪 ✅
- 预计完成时间：明天下午 3 点
7.3 结果可追溯
每个任务的输入、输出、执行时间都记录：
{
"task_id": "login-tech-design",
"agent_id": "cto",
"start_time": "2026-04-10T10:00:00+08:00",
"end_time": "2026-04-10T10:30:00+08:00",
"input": "设计登录系统技术方案",
"output": "技术方案文档（链接）",
"status": "completed"
}
8. 如何保证结果准确性
8.1 多层评审
CTO 设计方案 → Dev 实现 → QA 测试 → SRE 部署
│ │ │ │
└────── 互相评审 ──────┘
8.2 自动化测试
QA 角色编写自动化测试脚本，每次代码变更后自动运行：
// QA 自动化测试
const testResult = await sessions_spawn({
agentId: "qa",
task: `对以下代码运行自动化测试：${code}`,
mode: "run"
});
if (testResult.status !== "pass") {
// 打回 Dev 重新修复
await sessions_spawn({
agentId: "dev",
task: `修复以下测试失败：${testResult.failures}`,
mode: "run"
});
}
8.3 验收标准前置
任务开始前就明确验收标准：
### 验收标准
- [ ] 技术方案经 CTO 评审通过
- [ ] 单元测试覆盖率 > 80%
- [ ] 无 P0/P1 级别 Bug
- [ ] 性能测试达标（响应时间 < 200ms）
9. 实战案例分析
案例 1：开发一个登录系统
任务类型：L3 复杂项目
参与角色：COO, CTO, Dev, QA, SRE
执行流程：
1. COO 接收需求 → 识别为 L3 项目
2. COO 并行启动：
- CTO: 设计技术方案（2 小时）
- Dev: 实现功能（8 小时）
- QA: 编写测试用例（4 小时）
- SRE: 配置 CI/CD（2 小时）
3. Delivery 追踪进度，每 2 小时汇报一次
4. 所有任务完成后，COO 汇总结果回复用户
总耗时：约 10 小时（并行处理）
如果用单 Agent：约 30 小时（串行处理）
效率提升：约 3 倍
案例 2：生产环境故障处理
任务类型：L4 紧急事件
参与角色：COO, CEO, SRE, Dev, QA
执行流程：
1. COO 接收故障报告 → 识别为 L4 紧急事件
2. COO 立即通知 CEO（用户）
3. 并行启动：
- SRE: 排查故障原因（15 分钟）
- Dev: 准备修复代码（30 分钟）
- QA: 准备验证测试（15 分钟）
4. Delivery 每 5 分钟汇报一次进度
5. 故障解决后，汇总报告给用户
总耗时：约 45 分钟
如果用单 Agent：可能超过 2 小时（且容易出错）
10. 最佳实践与注意事项
10.1 配置要点
| 要点 | 说明 |
|---|---|
| 每个 Agent 独立配置 | 独立的工作目录、记忆文件、配置文件 |
| 合理设置超时时间 | 子 Agent 超时时间要设够（默认 10 秒可能不够） |
| 避免共享写入 | 同一时间只允许一个 Agent 写入同一个文件 |
| 使用消息通信 | Agent 间优先用 sessions_send 通信，不要直接 exec |
10.2 性能优化
| 优化项 | 说明 |
|---|---|
| 批量 API 调用 | 避免频繁调用飞书/微信 API，容易触发限流 |
| 合理使用缓存 | 用户偏好、选题库等适合缓存 |
| 超时与重试 | 设置合理的超时时间和重试机制 |
10.3 避坑指南
| 坑 | 解决方案 |
|---|---|
| 子 Agent 卡住 | 用 subagents list 查看状态，必要时 kill 掉重来 |
| 多 Agent 同时写同一文档 | 用队列机制，同一时间只允许一个 Agent 写入 |
| Token 过期 | 定期检查 Token 有效期，过期前刷新 |
| 权限不足 | 授权时勾选所有需要的权限 |
11. 常见问题 Q&A
Q1: 子 Agent 卡住了怎么办？
A: 用 subagents 工具查看状态，必要时 kill 掉重来。
subagents list # 查看运行中的子 Agent
subagents kill target=xxx # 强制终止
Q2: 多个 Agent 同时访问同一个飞书文档会冲突吗？
A: 会。飞书文档锁是乐观锁，后写入的会覆盖先写入的。 解决方案：
用不同的文档 或用队列机制，同一时间只允许一个 Agent 写入
Q3: 如何调试多 Agent 问题？
A: 开启会话历史查看。
sessions_history({
sessionKey: "xxx",
limit: 50,
includeTools: true // 包含工具调用记录
})
Q4: Agent 之间可以共享记忆吗？
A: 可以，但要小心。
共享文件： planning/topic-pool.md（只读或加锁）独立文件： memory/2026-04-10-cmo.md（按 Agent 隔离）
Q5: 子 Agent 执行失败了怎么通知主 Agent？
A: sessions_yield 会自动推送结果，包括错误信息。
主 Agent 检查返回消息中的 error 字段即可。
12. 总结
多 Agent 架构的核心，其实就是把一个大 NPC 拆成一群小 NPC。
COO 专心做协调，CTO 专心搞技术，Dev 专心写代码，QA 专心做测试。 各司其职，互不干扰，需要协作时喊一声就行。
关键要点回顾：
7 角色分工明确，职责清晰 4 级意图识别，智能路由 5 种协作方式，灵活应对不同场景 全程记录，避免任务黑屋 多层评审，保证结果准确性
最后说一句：
普通 NPC 的生活，也有自己的彩蛋。 多 Agent 架构，就是让每个小 NPC 都能找到自己的彩蛋。🎮
——
字数：约 5500 字
栏目：🤖 AI 道具拆解室
标签：#AI 道具 #科技围观 #OpenClaw #多 Agent #架构设计
【互动可选】你在用多 Agent 架构吗？遇到过什么坑？欢迎在评论区聊聊～
