Claude Code 高级编排：子 Agent 模式与防耗尽策略

几天前，我在 Clarity 的 AI 工具实践社区做了一场关于 Claude Code 高级用法的内部分享。这是现场演示的书面整理版，供需要回顾的朋友参考。

这是《Pi：最小化 Agent 框架》的姐妹篇：前一篇讲的是"最小化工具"以及因为不藏任何东西所以能学到的一切；这一篇讲的是榨干一个功能完备框架的所有价值。

在开始之前先提醒一句：这是进阶内容，假设你已经习惯在 auto 模式下运行 Claude——也就是说，你信任这个 agent，放心让它直接执行而无需逐条审批。如果你是刚上手的新手，建议先走基础路径——plan 模式、迭代、review——等熟悉了再来看这篇。之所以这样建议，是因为下面几乎所有内容都以这种信任为前提。

常规流程仍然占 90%

在讲那些花哨的东西之前，值得记住的是：最常见的流程依然是"常规的那一个"，而它才是一切的基础：

在 plan 模式下描述任务。

反复迭代直到计划合理。

执行计划。

这基本上就是 90% 的场景。值得内化的新规则只有一条：如果你发现自己重复同样的指令三次或以上，就把它们做成一个仓库专属的 skill。这个习惯比本文任何其他技巧都更有杠杆效应。在我们的前端仓库里已经有好几个 skill（create MR、remove a feature toggle、remove warnings、debug），妙处在于它们都是针对这个仓库适配的，所以 agent 知道去哪里找、用什么工具，不用你每次都解释一遍。

Agent 的编排：串行还是并行

当一个任务在单次对话里装不下时，可以让 Claude 把任务分散到多个 agent 中去做。编排的方式有很多种，选对方式在控制力和成本上差异巨大。以下是我目前尝试过的两种最基础的模式：

第一种是串行：一个可恢复的循环，每做一个改动，等它的 MR 合并之后，才进入下一个。状态保存在一个 markdown 文件里，所以你可以合上笔记本，第二天继续。这适合当你有大量相似的改动、但每个 MR 都需要人工 review 后才能继续的场景。这种方式成本低，因为同一时间只有一个任务在跑；而且虽然 Claude 做了大部分工作，但人类始终在循环中把控。

第二种是并行：Claude 同时启动多个 sub-agent 来同步处理各自独立的部分。适用于没有顺序依赖的重复性工作——比如给每个文件加返回类型、提高测试覆盖率、数据迁移等——每个 sub-agent 都可以独立地在自己的文件或模块上工作。你可以要求 Claude 来编排这些 sub-agent，让每个在独立的工作树中工作或创建自己的提交，然后由主 agent 统一处理合并和 MR 的创建。这速度快得多，但 token 消耗也大得多。每个 sub-agent 都像一次独立的对话，只是这次的对话发生在编排器和 sub-agent 之间，按照你之前制定的计划进行。要激活这个模式，只需要在制定计划时用"fan out"或"spawn agents"这样的词：任何一个都会指示 Opus 制定一个并行的编排方案。

⚠️ 一个真正能帮你省钱的小技巧：明确指定 sub-agent 使用 Sonnet。如果不这样做，它可能会用 Opus 或 Fable 来运行它们，token 消耗会相当惊人（经典案例就是 Fable "疯狂烧钱"）。规则是：用 Opus 编排，用 Sonnet 执行子任务。

值得了解的命令

除了编排之外，还有几个我在演示中展示过且经常使用的命令：

Deep research。功能类似于 Perplexity 或 Google 的深度搜索：它并行生成多个 agent，搜索来源并编译一份带引用的报告。对于研究新主题、探索市场替代方案、审查特定问题的文献，非常有用。再提醒一下模型的选择：Opus 效果更好但成本更高；Sonnet 更便宜。

Handoff。你让 Claude 写一份 markdown 格式的计划，包含在新会话中继续所需的一切。当你发现一个重构或子任务不想塞进当前的 MR，或者你即将用完上下文时，这非常完美。有一个知名的 skill 专门做这件事，但实际上只需要四行代码：你直接问 Claude 就行了。

/insights。分析你所有的会话，生成一份 HTML 报告，包含统计数据、你通常踩的坑、改进建议，甚至还有"moonshots"。非常适合用来调试你自己的 skills、hooks 和 agents。值得时不时跑一次。

Remote control。让你可以从手机或另一个浏览器监控和操控一个正在运行的会话，而会话继续在终端中跑。文档在这里。它有点不稳定——有时候连接会断掉，得切回终端——但它真正的价值在于让你能离开椅子：在厨房批准计划、出去散步。有一点提醒，半是法律半是健康：不要在工作时间以外使用；在西班牙这在法律上是不允许的。这就引出了下一点，而这一点很严肃。

这些流程很快，而且高度上瘾。因为它们进展得太快，你会觉得停下来就是在赔钱或在浪费时间，这让你一直盯着屏幕。这会导向 burnout。休息一下、站起来、不要仅仅因为可以就同时跑五个 agent。这不是开玩笑——已经有太多案例了，如果这已经是我们职业中的一个严重问题，情况只会变得更糟。

但我们是怎么走到这里的？

如果停下来想一想，这个飞跃是巨大的。我已经在博客上写了好几年了，重读那些帖子有点令人眩晕：

在《Developing with ChatGPT》（2023 年 4 月）中，我讲述了如何向 ChatGPT 要代码片段然后手动粘贴，惊叹于它能给我写出一个像样的 Dockerfile 或 README。

一年后，在《LLMs review, one year on》中，事情看起来已经是范式转换了，尽管仍被怀疑包围，对于未来走向也没有清晰认知。

而在今年 1 月的《2025 review in 'assisted' development》中，我已经在谈论整个项目在几天内完成而不是几个月，手写代码开始变得毫无意义。

不到三年，我们从在聊天中复制粘贴代码片段，发展到编排能自己开 MR 的 agent 群，而我们在屏幕前 review。本文描述的一切——编排 sub-agent、让它们在 auto 模式下运行、用手机操控——在我写第一篇文章时听起来都像科幻小说。我有一种感觉，再过一年这也会显得过时了。这就是为什么我认为值得把这些笔记留下，作为我们今天所在位置的一个快照。

如果我要选三件这周可以尝试的事：

把这周重复的指令转变成一个 skill，在你自己实际工作的仓库里做。

跑一次 /insights，采纳至少一条它的建议。

用 sub-agent 在 Sonnet 上编排一个小规模的串行批次，处理一组相似的 tickets。

一如既往，你可以在 github 上评论，或者在 bluesky 上给我写私信。如果你建立了自己的 agent 编排，我想听听效果如何。