第 32 课：Agent Teams 与长时运行任务

第六章：Claude Code 工程化工作流 | 第 32 课

课前思考

有两个场景你大概率遇到过：

场景 A：你要重构一个项目，涉及前端、后端、数据库三个模块。单个 Claude 一次只能做一件事，你等它做完前端再做后端，做完后端再做数据库。串行等待占用了你大量时间。

场景 B：你让 Claude「把这个项目的测试从 Jest 迁移到 Vitest」。它改了 5 个文件后告诉你「完成了」，你跑了一下发现还有 30 个文件没改。

场景 A 需要的解决方案是并行协作，场景 B 需要的是持续循环。这一课同时解决这两个问题。

---

一、单 Agent 的瓶颈

单个 Claude 实例的天然局限：

瓶颈	表现	影响
串行处理	一次只能做一件事	即使多个任务互不依赖，也只能排队
上下文拥挤	对话越长，早期信息越容易被淹没	AI 可能忘记 50 条消息前讨论的架构决策
单一视角	没有「同事」讨论和验证	复杂设计决策缺乏多角度审视
过早停止	AI 觉得「差不多了」就停	任务只完成了 60%，但 AI 自己不知道

---

二、Agent Teams：多 AI 并行协作

Agent Teams 是 Claude Code 的高级功能——让多个独立的 AI 实例像真正的开发团队一样协同工作。

核心机制

传统模式：你 → Claude（串行处理所有任务）

Agent Teams 模式：
       ┌→ Agent B（前端 UI）
你 → Agent A（架构师）
       ├→ Agent C（后端 API）
       └→ Agent D（测试）

每个 Agent 拥有独立的 200K token 上下文，互相之间可以直接通信。Anthropic 内部测试显示，大型项目重构效率可提升约 50%。

实战场景：微服务拆分

任务：单体应用拆分为微服务

Agent A（架构师）：输出整体拆分方案
Agent B（后端 A）：拆分用户服务
Agent C（后端 B）：拆分订单服务
Agent D（前端）：适配新 API 网关
Agent E（测试）：端到端测试

流程：
1. A 输出方案 → 所有 Agent 读取
2. B、C 并行拆分各自服务
3. D 等待新 API 定义后开始适配
4. E 在所有服务部署后运行集成测试
5. 发现问题 → Agent 间通信协调修复

---

三、长时运行：让 AI 持续工作

为什么 AI 会「过早停止」

LLM 有一个根本缺陷：它无法准确判断自己的工作是否真正完成。它可能因为：

• 「感觉差不多了」
• 「输出够多了」
• 「不知道接下来该干什么」

就停下来。解决方案的核心思想：让 AI 在循环中工作。每次它想退出时，外部系统检查：真的完成了吗？符合客观标准了吗？如果没有，重新注入任务。

Ralph Wiggum：官方长时运行方案

以《辛普森一家》中「永不放弃」的角色命名，Anthropic 官方出品。

/plugin marketplace add anthropics/claude-code
/plugin install ralph-wiggum@claude-code-plugins

核心机制——Stop Hook：

Claude 想要退出
    ↓
Stop Hook 拦截
    ↓
检查：输出了指定的完成标记吗？
    ├── 是 → 允许退出
    └── 否 → 重新注入任务，开始下一轮迭代

使用范式

/ralph-wiggum:ralph-loop "
构建完整的 todo API，分阶段执行：

阶段 1 - 基础功能：
POST /todos、GET /todos（分页）、PUT /todos/:id、DELETE /todos/:id

阶段 2 - 输入验证：
标题不能为空，completed 必须是布尔值

阶段 3 - 测试：
为每个端点写测试，覆盖率 > 80%

验收标准：
- npm test 全部通过
- npm run lint 通过
- 手动 curl 测试每个端点正常

完成后输出：<promise>TODO_API_COMPLETE</promise>
" --max-iterations 50 --completion-promise "TODO_API_COMPLETE"

Prompt 黄金法则

不好的 Prompt：「写一个 todo API」 → AI 可能写个基础框架就停了

好的 Prompt：分阶段描述 + 验收标准 + 唯一完成标记

---

四、适合 vs 不适合

适合用 Ralph（有客观标准）	不适合（需要人类判断）
测试框架迁移（Jest → Vitest）	架构设计决策
大规模代码重构	安全相关代码
批量添加类型注解	需求模糊的任务
测试覆盖率提升	创意性设计
代码风格统一	需要持续反馈的探索

判断标准——问自己三个问题：

1. 我能定义明确的完成标准吗？
2. 有客观的验证方法吗？（测试、构建、类型检查）
3. 这个任务需要我持续反馈吗？

三个都自信地回答了，就放手让 Ralph 去做。

---

五、安全机制

{
  "maxIterations": 50,
  "rateLimitPerHour": 100,
  "completionPromise": "TASK_COMPLETE",
  "costAlertThresholds": [10, 50, 100]
}

• 硬性限制：达到最大迭代次数强制停止
• 速率限制：防止 API 账单失控
• 成本预警：花费达阈值时暂停并通知

---

六、真实案例

• YC 黑客松过夜 6 项目：晚上 11 点设置 Ralph，200 次迭代。第二天 6 个可演示项目，API 成本仅 $297
• Boris Cherny 的 30 天（Claude Code 负责人）：259 个 PR，497 次提交，新增 40,000 行代码，100% 由 Claude Code + Ralph 完成

---

课后练习

1. 安装 Ralph Wiggum，用一个已完成的简单任务测试循环机制
2. 设计一个「过夜任务」的 Prompt——选一个你一直想做但没时间的项目维护工作
3. 思考：你的项目中哪些工作适合 Agent Teams 并行处理？