用 Copilot 构建智能体，我把自己自动化了

我可能刚刚把自己‘自动化’到了一个完全不同的岗位上。

这其实是软件工程师的常见模式：出于灵感、挫败感，有时甚至是懒惰，我们会构建系统来消除重复性工作，从而专注于更有创造性的任务。然后，我们就成了这些系统的维护者，并把这种自动化带来的便利分享给周围的人。

作为一名 AI 研究员，我最近把这件事推向了新的高度——自动化了我的‘智力’重复劳动。现在，我正在维护这个工具，以便让 Copilot 应用科学团队的所有同事都能做到同样的事。

在这个过程中，我学到了很多关于如何有效使用 GitHub Copilot 来创建和协作的知识。应用这些经验，不仅为我个人解锁了极快的开发循环，也让我的团队成员能够构建出满足他们需求的解决方案。

在解释我是如何做到这一点之前，让我先说明一下这个项目的起因，这样你就能更好地理解利用 GitHub Copilot 所能实现的范围。

项目起因

我工作的很大一部分，是分析编码智能体在标准化评估基准（如 TerminalBench2 或 SWEBench-Pro）上的表现。这通常需要仔细研究大量的‘轨迹’（Trajectories），这些轨迹本质上是智能体在执行任务时的思维过程和行动列表。

评估数据集中的每个任务都会产生自己的轨迹，显示智能体如何尝试解决该任务。这些轨迹通常是包含数百行代码的 .json 文件。一个基准测试集有几十个任务，而每天又有很多基准测试运行需要分析，这意味着要分析数十万行代码。

单靠人力是不可能完成的任务，所以我通常会求助于 AI。在分析新的基准测试运行时，我发现我不断重复着相同的循环：使用 GitHub Copilot 来发现轨迹中的模式，然后自己进行调查——将需要阅读的代码行数从数十万减少到几百行。

然而，工程师的本能让我看到了这个重复性任务，并说：“我想自动化它。”智能体为我们提供了自动化这类智力工作的手段，于是 eval-agents 项目诞生了。

项目规划

工程团队和科学团队合作会更好。这是我着手解决这个新挑战时的指导原则。

因此，我在设计和实施这个项目的策略时，考虑了以下几个目标：

1. 让这些智能体易于分享和使用
2. 让创建新智能体变得容易
3. 让编码智能体成为主要的贡献载体

前两点是 GitHub 的基因，也是我职业生涯中（尤其是在担任 GitHub CLI 开源维护者期间）获得的价值和技能。

然而，第三个目标对项目的影响最大。我注意到，当我设置好 GitHub Copilot 来帮助我高效构建工具时，它也使得项目更容易使用和协作。这段经历教会了我几个关键的经验，最终以我意想不到的方式推动了前两个目标的实现。

让编码智能体成为你的主要贡献者

首先介绍一下我的智能体编码设置：

• 编码智能体：Copilot CLI
• 使用的模型：Claude Opus 4.6
• IDE：VSCode

值得一提的是，我利用了 Copilot SDK 来加速智能体创建，其底层由 Copilot CLI 驱动。这让我可以访问现有的工具和 MCP 服务器、注册新工具和技能，以及一大堆开箱即用的智能体功能，而无需自己重新发明轮子。

有了这些基础，我通过遵循几个核心原则，很快就能简化整个开发流程：

• 提示策略：与智能体对话时，要像与人交流一样，详细、健谈，并在进入智能体模式前充分利用规划模式。
• 架构策略：经常重构、经常更新文档、经常清理。
• 迭代策略：从“信任但要验证”转变为“归咎于流程，而非智能体”。

发现并遵循这些策略带来了一个惊人的现象：添加新智能体和功能变得又快又容易。我们让五个人第一次接触这个项目，在不到三天的时间里，总共创建了 11 个新智能体、4 个新技能，以及 eval-agent 工作流（可以理解为科学家的推理流）的概念。这相当于在 345 个文件中，代码变更量达到了 +28,858/-2,884 行。

太惊人了！

下面，我将详细介绍这三个原则，以及它们是如何促成这次惊人的协作和创新壮举的。

提示策略

我们知道，AI 编码智能体非常擅长解决范围明确的问题，但对于那些你只会交给资深工程师的复杂问题，它们需要更多的指导。

所以，如果你想让你的智能体表现得像个工程师，那就把它当成工程师来对待。引导它的思考，过度解释你的假设，并利用它的研究速度在做出更改之前进行规划。我发现，把我正在思考的问题的一些意识流想法写进提示词，然后在规划模式下与 Copilot 协作，远比给它一个简洁的问题陈述或解决方案有效得多。

以下是我为了给工具添加更健壮的回归测试而写的一个提示词示例：

> /plan I've recently observed Copilot happily updating tests to fit its new paradigms even though those tests shouldn't be updated. How can I create a reserved test space that Copilot can't touch or must reserve to protect against regressions?

这引发了一场来回讨论，最终形成了一系列类似于契约测试的安全护栏（Guardrails），并且只能由人类更新。我对想要的东西有个想法，通过对话，Copilot 帮助我找到了正确的解决方案。

事实证明，让人类工程师最高效地完成工作的因素，同样也让这些智能体高效地完成它们的工作。

架构策略

工程师们，欢呼吧！还记得你们一直想做但没时间做的那些重构吗？那些为了让代码库更易读而做的改动，那些你一直没时间写的测试，还有你刚入职时希望存在的文档？现在，当你构建一个智能体优先（Agent-first）的仓库时，这些成了你最重要的工作。

那种为了新功能而将这类工作优先级降低的日子已经一去不复返了，因为当你拥有一个维护良好的、智能体优先的项目时，用 Copilot 交付功能就变得轻而易举。

我在这个项目上花费的大部分时间都在重构命名和文件结构、记录新功能或模式，以及为我发现的问题添加测试用例。我甚至花了一些周期来清理死代码——就像初级工程师可能会在实现所有新功能和更改时遗漏的那样。

这项工作使得 Copilot 能够轻松地浏览代码库并理解其中的模式，就像任何其他工程师一样。

我甚至可以问：“根据我现在知道的情况，我会如何重新设计这个项目？”然后，我就可以理直气壮地回去重新架构整个项目（当然，是在 Copilot 的帮助下）。

这简直是梦想成真！

这引出了我的最后一点建议。

迭代策略

随着智能体和模型的改进，我的心态已经从“信任但要验证”转变为更加信任而非怀疑。这反映了行业对待人类团队的方式：“归咎于流程，而非个人。”这是最高效团队的运作方式，因为人会犯错，所以我们围绕这个现实构建系统。

这种无责文化（Blameless Culture）的理念为团队提供了心理安全感，让他们可以放心地迭代和创新，知道即使犯错也不会受到指责。其核心原则是，我们实施流程和安全护栏来防止错误，如果确实发生了错误，我们就从中学习，并引入新的流程和安全护栏，这样我们的团队就不会再犯同样的错误。

将同样的理念应用于智能体驱动开发（Agent-driven Development），对于解锁这个极其快速的迭代管道至关重要。这意味着我们添加流程和安全护栏来帮助防止智能体犯错，但当它确实犯错时，我们就添加额外的安全护栏和流程——比如更健壮的测试和更好的提示词——这样智能体就不会再犯同样的错误。再进一步，这意味着实践良好的 CI/CD 原则是必须的。

严格的类型检查确保智能体符合接口规范。强大的代码检查器对智能体施加实现规则，使其遵循良好的模式和实践。而集成测试、端到端测试和契约测试——这些手动构建可能成本很高——在智能体的协助下实现起来要便宜得多，同时还能让你确信新的更改不会破坏现有功能。

当 Copilot 在其开发循环中可以使用这些工具时，它就能检查自己的工作。你这是在为它创造成功的条件，就像你为项目中的初级工程师创造成功条件一样。

综合运用

当你的代码库为智能体驱动开发做好准备时，这一切对你的开发循环意味着：

1. 使用 /plan 与 Copilot 规划新功能。
   • 迭代规划。
   • 确保规划中包含测试。
   • 确保规划中包含文档更新，并在代码实现之前完成。这些可以作为额外的指南与你的规划并存。
2. 让 Copilot 在 /autopilot 模式下实现该功能。
3. 提示 Copilot 启动与 Copilot Code Review 智能体的审查循环。对我来说，通常是这样的：request Copilot Code Review, wait for the review to finish, address any relevant comments, and then re-request review. Continue this loop until there are no more relevant comments.
4. 人工审查。这是我强制执行前面讨论过的模式的地方。

此外，在你的功能循环之外，请务必尽早并经常用以下内容提示 Copilot：

• /plan Review the code for any missing tests, any tests that may be broken, and dead code
• /plan Review the code for any duplication or opportunities for abstraction
• /plan Review the documentation and code to identify any documentation gaps. Be sure to update the copilot-instructions.md to reflect any relevant changes

我让这些任务每周自动运行一次，但我经常发现自己在整个星期中，随着新功能和修复的加入，也会运行它们，以维护我的智能体驱动开发环境。

核心启示

最初对一个不可能完成的重复性分析任务的挫败感，演变成了更有趣的东西：一种关于我们如何构建软件、如何协作以及如何成长为工程师的新思维方式。

以编码智能体优先的心态构建智能体，从根本上改变了我的工作方式。这不仅仅是关于自动化的胜利——尽管看着四位科学家在不到三天的时间里交付 11 个智能体、4 个技能和一个全新的概念，这本身就非常了不起。更重要的是，这种开发方式迫使你优先考虑：清晰的架构、详尽的文档、有意义的测试和周到的设计——这些我们一直知道很重要但从未有时间去做的事情。

与初级工程师的类比不断得到验证。你很好地引导他们，给他们清晰的上下文，建立安全护栏，这样他们的错误就不会演变成灾难，然后信任他们成长。如果出了问题，你归咎于流程。而不是智能体。如果有一件事我希望你从这篇文章中学到，那就是：让你成为一名优秀工程师和优秀团队成员的技能，同样也是让你擅长使用 Copilot 构建的技能。技术是新的。但原则不是。

所以，去清理你的代码库，写下你一直拖延的文档，开始把你的 Copilot 当作团队的最新成员来对待。你可能会把自己‘自动化’到职业生涯中最有趣的工作中去。

觉得我疯了？好吧，试试这个：

1. 下载 Copilot CLI
2. 在任何仓库中激活 Copilot CLI：cd <repo_path> && copilot
3. 粘贴以下提示词：/plan Read <link to this blog post> and help me plan how I could best improve this repo for agent-first development

作者简介

Tyler 是 Copilot 应用科学团队的高级应用研究员。他拥有科学、教育、游戏设计/开发和软件等多元背景。他目前职位中最喜欢的部分是加速团队和整个组织的学习和研究。