8.0
热点
AI SCORE
编程提效2026-08-09 13:42
我简化GitHub Copilot多Agent编队的过程与收获
dev.to · AI#GitHub Copilot#多Agent#AI编程工具
Editor brief · 编辑速览
作者将原有的4个角色（Capbya路由、Otter实现、Owl审查、Squirrel辅助）简化为更轻量的方案，详细分析了角色分离对上下文管理和代码质量的影响，附GitHub仓库。
有一段时间我构建了 GitHub Copilot Squad，这是一个面向 GitHub Copilot 编程 Agent 的自定义多 Agent 协作方案。经过在实际任务中使用后，我将它重构为一个更简单的版本。这就是我尝试了什么、学到了什么、以及最终得到了什么的过程。
最初的想法是角色分离。不要让一个 Agent 同时做规划、编码和审查三件事。所以我把它拆成了四个 Agent：
目标是保持实现和审查作为独立的视角，这样技术任务在最终输出前会经过一个"实现 → 审查"的循环，不同模型贡献不同视角。
当使用一个 Agent 处理所有事情时，prompt 经常会把规划、编码和审查混在一起一次完成，上下文窗口很快就会填满。这个方案强制了角色分离：
路由和迭代控制……
目标是保持实现和审查作为独立的视角，这样技术工作在返回给你之前会经过一个"构建 → 审查"的循环。
分离在纸面上看起来很干净。但在实践中，有几件事困扰着我：
一个独立的全能实现者并没有带来太多价值。启动一个单独的 Agent 只是为了转移执行工作，只有当那个 Agent 是专业化的（前端专家、特定框架专家）时才值得。我的 Otter 是一个通才，就像 Capybara 一样。两个通才给我的只是交接开销，而不是更多视角。
每个请求的新鲜独立上下文成本很高。因为 Otter 是一个单独的子 Agent，每个请求都从全新的上下文开始。这意味着更多的 token 和更多的时间让它重新读取代码库并重新分析问题，即使对于直接建立在前序工作基础上的后续请求也是如此。
对上下文窗口的恐惧被夸大了。我最初担心把构建者合并到入口点的担忧是上下文窗口会很快填满。但在运行了真实的、多步骤的任务后，它的增长速度比我预期的要慢，而温暖的、可持续的上下文的好处超过了成本。
所以我构建了一个更简单的版本。
Simplified version of my GitHub Copilot Squad, a custom multi-agent orchestration for GitHub Copilot coding agent with role-based routing.
简化版的 GitHub Copilot Squad，面向 GitHub Copilot 编程 Agent 的自定义多 Agent 协作方案，支持基于角色的路由。它以两种模式交付：
Trio（默认）：Capybara（入口 + 实现者）+ Owl（代码审查员）+ Cat（注释/文档字符串审查员）。
Duo：仅 Capybara + Owl，没有专门的注释/文档字符串审查流程。Duo 的行为在 CapybaraDuo.agent.md 中。
两种模式的目标相同：保持实现和审查作为独立的视角，这样技术工作在最终输出前会经过一个"构建 → 审查"的循环。相比原始的 4 Agent 团队，去掉了单独的执行 Agent 和单独的轻量助手的开销。
原始团队将实现工作委托给专门的构建者 Agent（Otter），Capybara 充当纯路由器。在将其用于实际任务后，这种分离被证明是不必要的……
我把 Otter 合并到了 Capybara 中。现在 Capybara 是入口和实现者。它接收请求、完成工作，然后交给 Owl 审查。我也去掉了 Squirrel（说实话它没什么用，我在实际中从来没真正用过它 😂），所以 Capybara 直接处理简单的问题。Owl 保留了作为审查员。
它以两种模式交付：
Duo。Capybara + Owl（精简版）
Trio（默认）。Capybara + Owl + Cat（Cat 的更多细节稍后再说）
对于技术请求，Capybara 实现，然后与 Owl 循环直到 Owl 批准。在 Trio 模式下，然后与 Cat 循环直到 Cat 批准，最后返回结果。
有段时间 Duo 模式就足够了。但我注意到一件事：Agent 有时会写出不必要的、冗余的或不恰当的注释和文档字符串，即使规则已经说了不要这样做。Owl 的审查涵盖了这一点，但 Owl 也要审查代码实现，所以这些文字问题有时会被跳过。
所以我添加了 Cat，一个只专注于注释和文档字符串的审查员。它在 Owl 批准后运行，所以此时代码已经是正确的了。Cat 的全部工作就是打磨文字。每次审查流程都会写一份报告文件，所以有一个轻量的审计跟踪。
这就是 Trio 模式：Capybara 和 Owl（代码审查），然后 Capybara 和 Cat（注释/文档字符串审查），然后结束。
两种设置都将 AGENTS.md 文件作为项目特定规则（技术栈、测试命令、linter、命名规范以及预期的注释/文档字符串规则）的事实来源。Agent 的 profile 保持通用和可复用。项目特定的细节放在 AGENTS.md 中，这比编辑打包好的 Agent profile 更容易更新和维护。
我还没有发布 AGENTS.md 的示例或模板。等我有时间整理出一个干净的模板后，我会添加一个。在此之前，你可以自己编写 AGENTS.md 来描述你的技术栈、测试命令、linter，以及你希望 Agent 遵守的任何硬约束。
因为给东西起名字本身就是一半的乐趣：
简而言之：我从 4 个 Agent 开始，发现一个通才实现者就够了，最终得到了一个 2 Agent 的设置，外加一个可选的第 3 个用于文档字符串打磨。配置只是一些 markdown 格式的 Agent profile，你可以直接拖入 VS Code Copilot Chat 中使用。