子代理工作流加速代码库分析

我喜欢分析刚开始接手的代码库，或者那些被我搁置了几个月的代码库。我会这样询问我的编码助手——这里以 Copilot CLI 为例：“分析下面的代码库，并向我报告可以改进的地方和潜在的 bug。”这个问题足够宽泛，既可能得到一些糟糕的反馈，也可能收获一些有意思的洞见。

上周，我在一个代码库上进行了这样的尝试。Copilot 返回了一份包含十几个条目的清单。我让它为每个条目创建一个 GitHub issue，并添加相关 label，包括优先级。

其中三个 issue 都提到，某个库或 GitHub Action 的版本并不存在。然而，这三次它都完全错了。我使用的版本比它训练数据中的版本更新。于是，这些 issue 被以“won’t fix”关闭。

下一步是对剩余的每个条目进行分类处理（triage），既由我独立判断，也借助 Copilot 分析。有些条目感觉有点可疑，有些则看起来很靠谱。最终，我关闭了其中大约一半，还剩下四个。这四个相当不错。我希望以最高效的方式处理它们，于是决定使用 sub-agent。

新手决定使用 sub-agent 时，很可能会浪费大量时间。因为 sub-agent 是自主运行的，所以你需要为它们提供所有可能用到的信息，让它们无须额外询问就能选择最佳行动方案。你必须独立、完整地说明每个 issue。虽然从技术上讲，你仍然可以在 sub-agent 工作期间与它们交互，但这会显著降低它们的价值。

不过，这项工作可以在前面的 triage 阶段完成。如果你已经掌握了足以接受或关闭某个条目的信息，那么你很可能已经深入挖掘并获得了足够多的细节。更多信息可以参考《How I Use Claude Code》，尤其是其中的 Annotation Cycle 一节。

下面是我用来触发这些 Agent 的 prompt。这里的格式是为了方便你阅读，而不是专门为 Agent 设计的。欢迎改进，也请随时向我提供反馈。

对于每个 issue X、Y 和 Z，我希望你启动一个 sub-agent，分别执行以下操作：

• 使用 gh 工具获取 issue

• 使用 git worktree 命令创建一个专用分支

• 实现该功能或修复该 issue

• 如果该功能或 issue 有必要，为其创建一个或多个测试

• 在继续之前，所有测试都必须通过

• 使用 semantic commit 提交

• 将代码推送到 GitHub 上各自独立的分支

• 使用该分支创建 PR，并遵循以下命名模式：<describe your org naming pattern>

首先，Copilot 默认会连接 GitHub MCP Server，但仅拥有只读权限。如果你确实想创建或更新 issue，我的建议是使用 gh。在终端中完成 gh 身份验证，然后在同一个终端中运行 Copilot CLI。这样，Copilot 就能使用完整权限与 GitHub 交互。

其次，git branch 会在同一个文件夹中工作，每个 Agent 都可能互相干扰。Git worktree 优雅地解决了这个问题。简而言之，这条命令可以将一个分支映射到文件系统中的专用文件夹：

一个 git 仓库可以支持多个工作树，让你能够同时 checkout 多个分支。使用 git worktree add 时，一个新的工作树会与仓库建立关联，同时还会保存额外的元数据，用于区分该工作树与同一仓库中的其他工作树。这个工作树及其相关元数据合称为一个“worktree”。

有趣的是：我很早就知道 worktree，但以前一直没有遇到适合使用它的场景。

使用 sub-agent 最明显的好处是并行处理。虽然你必须依次研究每个条目，但 sub-agent 可以并行实现它们。不过，依我看，最主要的好处是上下文隔离。

Sub-agent 是一种利器：每个 sub-agent 都从全新的上下文开始。你不会用无关数据污染主上下文。

提醒一下，上下文包含 Agent 据以采取行动的一切信息：

• System prompt，例如：“你是一位拥有 20 多年经验的 Java 专家开发者和架构师”

• User prompt，例如：“重构这个类，尽可能使用不可变值”

• 由 RAG 设置的附加信息

• 之前的消息，也就是对话记录

• 工具可能产生的输出

人们很容易忍不住把所有内容都塞进上下文。然而，上下文容量有限，并以 token 衡量。一个精心构建的上下文应该包含完成当前任务所需的全部数据，但不多放任何无关内容。作为工程师，我们追求的是效率，而不是完美。每遇到一个不相关的任务，我们都应该开启一个新的上下文。有意思的是，Claude Code 最近开始在每次请求后提供上下文优化功能。是否保留优化后的上下文，由你自行决定。

现在，我们管理的是一支 Agent 团队，而不是一支初级开发者团队。两种情况在某种程度上很相似。你必须非常清楚地说明自己想要什么，必须提前完成细致的设计。被你委派任务的对象很可能不会提问，并且可能最终走向错误的方向。你需要仔细审查结果。

不过，两者之间存在两个主要区别。你会在几分钟内获得产出，而不是几天。另一方面，我们也不再培养下一代开发者。

从每家公司的角度来看，这似乎都很合理：既然 AI 可以取代初级开发者，为什么还要培养他们？市场数据已经显示出这种趋势。但高级开发者并不是凭空出现的。他们都曾是初级开发者，并一步步经历了完整的成长过程。对我而言，这并不会改变什么。从更宏观的角度看，再过几年，当这些使用 AI 的公司意识到自己已经多么依赖供应商，并开始面临高级开发者短缺时，它们一定会为自己的短视感到后悔。

《How I Use Claude Code》