技术速递｜在 Copilot 应用科学中的智能体驱动开发

作者Tyler McGoffin排版Alan Wang我使用编码智能体来构建智能体从而自动化了我工作中的一部分内容。以下是我在更高效地与编码智能体协作方面的一些经验总结。我可能刚刚把自己“自动化”进了一份完全不同的工作……这在软件工程师中其实很常见出于灵感、挫败感甚至有时只是因为“偷懒”我们会构建各种系统来消除重复劳动把精力投入到更具创造性的工作中。而最终我们往往又会成为这些系统的负责人和维护者让身边的其他人也能享受到自动化带来的收益。作为一名 AI 研究员我最近把这件事推进到了一个此前难以实现的程度——我将自己的“脑力劳动”也自动化掉了。现在我反而在维护这样一个工具让 Copilot 应用科学团队的同事们也能够做到这一点。在这个过程中我学到了很多关于如何高效地使用 GitHub Copilot 进行创建与协作的经验。将这些经验应用之后我不仅为自己构建了一个极其高效的开发闭环也让团队成员能够快速打造符合各自需求的解决方案。在详细介绍我是如何实现这一切之前先让我为这个项目的诞生背景做一个铺垫这样你可以更好地理解使用 GitHub Copilot 所能达到的能力边界。GitHub Copilothttps://github.com/features/copilot动机我工作的很大一部分是基于标准化评测基准例如 TerminalBench2 或 SWEBench-Pro来分析编码智能体的性能。这通常需要仔细查看大量被称为“轨迹”的数据——本质上就是智能体在执行任务过程中其思考过程和行动步骤的列表。评测数据集中的每一个任务都会生成一条对应的轨迹用来展示智能体是如何尝试解决该任务的。这些轨迹通常是包含数百行代码的.json文件。当你把这些数据扩展到一个基准测试中的几十个任务再叠加每天需要分析的多次评测运行时就意味着需要处理数十万行代码。这显然不是一个人能够独立完成的任务因此我通常会借助 AI 来协助分析。在处理新的基准测试结果时我发现自己不断重复同一个流程先使用 GitHub Copilot 从这些轨迹中提取模式然后再由我自己进行深入分析——这样就能把需要阅读的代码量从数十万行缩减到几百行。但作为一名工程师我看到这种重复性的工作时的第一反应是“我想把它自动化。”而智能体正好为自动化这种“脑力劳动”提供了手段于是eval-agents项目也就应运而生了。TerminalBench2https://www.tbench.ai/?wt.mc_id3reg_webpage_reactorSWEBench-Prohttps://scale.com/leaderboard/swe_bench_pro_public/?wt.mc_id3reg_webpage_reactor计划工程团队与科研团队协同工作时往往能发挥更大的价值。这也是我在着手解决这个新挑战时所秉持的核心原则。因此在这个项目的设计与实现策略上我设定了几个目标让这些智能体易于分享和使用让创建新的智能体变得简单让“编码智能体”成为主要的贡献方式前两个目标可以说是 GitHub 的核心基因也是我在职业生涯中积累的重要理念与能力尤其是在担任 GitHub CLI 开源维护者期间。不过真正对项目影响最大的是第三个目标。我发现当我借助 GitHub Copilot 来高效构建这个工具时也无形中让这个项目本身变得更易于使用和协作。这段经历让我总结出了一些关键经验而这些经验也以出乎意料的方式进一步推动了前两个目标的实现。让编码智能体成为你的主要贡献者我先介绍一下我的智能体编程环境配置编码智能体Copilot CLI使用模型Claude Opus 4.6IDEVSCode另外值得一提的是我还借助了 Copilot SDK 来加速智能体的创建——而它底层正是由 Copilot CLI 驱动的。这让我可以直接使用现成的工具和 MCP 服务器同时也能方便地注册新的工具与技能以及获得一整套开箱即用的智能体能力而无需从零开始重复造轮子。在此基础上我通过遵循几个核心原则很快就将整个开发流程大幅简化提示策略当你以对话式、信息充分的方式与智能体交互并在进入执行模式前先使用规划模式时智能体的表现最佳。架构策略频繁重构、频繁更新文档、频繁清理代码。迭代策略“信任但验证”已经演变为“把问题归因于流程而不是智能体”。当我逐步总结并践行这些策略后出现了一个令人惊讶的现象新增智能体和功能变得又快又简单。项目中有 5 位成员第一次参与进来在不到三天的时间里我们就创建了11 个新的智能体4 个新的技能以及一种名为 eval-agent workflows 的新概念可以理解为“科学家式推理流程”这些改动总计涉及 345 个文件代码变更达到28,858 / -2,884行。简直不可思议接下来我会详细讲解这三大原则以及它们是如何促成如此高效的协作与创新的。提示策略我们知道AI 编程智能体在解决边界清晰的问题时表现非常出色但在面对更复杂、通常只有资深工程师才会处理的问题时仍然需要一定程度的引导与“手把手”指导。因此如果你希望你的智能体表现得像一名工程师那就要用对待工程师的方式去对待它引导它思考、充分解释你的假设并利用它极快的检索与研究能力在真正开始修改代码之前先完成规划。我发现比起给出一个简短的问题描述或直接的解决方案把我在思考问题时的一些“意识流式”的想法写进提示词并在规划模式中与 GitHub Copilot 交互效果要好得多。下面是我为了给这个工具增加更健壮的回归测试而写的一个提示示例/plan Ive recently observed Copilot happily updating tests to fit its new paradigms even though those tests shouldnt be updated. How can I create a reserved test space that Copilot cant touch or must reserve to protect against regressions?这个问题最终引发了一系列来回讨论并逐步形成了一套类似契约测试的防护机制这些测试只能由人类进行更新。我一开始有一个大致的想法而通过与 Copilot 的对话它帮助我逐步逼近了正确的解决方案。事实证明让人类工程师高效工作的那些方法同样也是让这些智能体高效工作的关键。架构策略工程师们可以欢呼了还记得那些你一直想做但没时间做的重构吗那些为了让代码库更易读而想调整的结构那些一直没补上的测试以及那些你在入职时希望就已经存在的文档在“智能体优先”的仓库中这些工作现在反而成为最重要的任务。过去那种“为了新功能不得不降低这些工作优先级”的时代已经结束了因为当你拥有一个维护良好、以智能体为中心的项目时通过 GitHub Copilot 交付功能变得极其简单。在这个项目中我的大部分时间都花在重构命名与文件结构、为新功能或模式编写文档、以及为过程中发现的问题补充测试用例。我甚至还会花一些精力清理那些智能体就像你的初级工程师一样在实现新功能时遗漏的“死代码”。这些工作让 Copilot 能够像任何一名工程师一样轻松地理解并在代码库中导航。我甚至可以直接问“如果现在重新设计你会怎么做”然后我可以在 Copilot 的帮助下真正回过头去重新架构整个项目。这简直是梦想成真而这也自然引出了我最后一条建议。迭代策略随着智能体和模型能力的提升我的心态也从“信任但验证”逐渐转变为一种更偏向信任、而非怀疑的方式。这也类似于行业中对人类团队的管理理念“把问题归因于流程而不是个人”。这是高效团队运作的方式因为人一定会犯错所以我们要围绕这种现实去构建系统。这种无责文化的核心是为团队提供心理安全感使其能够持续迭代与创新而不必担心犯错会带来指责。其基本原则是我们通过流程与防护机制来避免错误发生而当错误真的发生时我们会从中学习并引入新的流程和防护机制确保团队不会重复同样的错误。将同样的理念应用到智能体驱动开发中是释放高速迭代能力的关键。这意味着我们会为智能体构建流程与“护栏”来防止它出错而当它确实犯错时我们不会简单止步而是进一步增加新的护栏和流程——例如更严格的测试、更精细的提示词从而让同样的错误不再发生。再进一步这也意味着必须认真实践 CI/CD 的最佳原则。严格类型校验等实践能够确保智能体符合接口规范。功能强大的代码检查工具会为智能体设定实现规则使其始终遵循优良的编程范式与开发准则。此外集成测试、端到端测试以及契约测试——这类测试若手动构建往往成本高昂——在智能体的辅助下实现起来会更为经济高效同时也能让你确信新的代码变更不会破坏现有功能。当 GitHub Copilot 在开发循环中拥有这些工具时它甚至可以“自我检查工作”。你实际上是在为它创造成功条件就像你为团队中的初级工程师搭建一个良好的成长环境一样。无责文化https://circleci.com/blog/value-of-blameless-culture/?wt.mc_id3reg_webpage_reactorCI/CDhttps://github.com/resources/articles/ci-cd/?wt.mc_id3reg_webpage_reactor整合起来当你的代码库已经为“智能体驱动开发”做好准备时这一切意味着你的开发循环会变成如下流程使用 GitHub Copilot 的/plan来规划一个新功能对这个计划进行迭代优化确保计划中包含测试设计确保计划中包含文档更新并且在代码实现之前完成这些更新——这些文档也可以作为与计划并行存在的额外约束与指导让 Copilot 使用/autopilot来实现该功能触发 Copilot Code Review 智能体进入评审循环通常流程是请求评审 → 等待结果 → 处理相关评论 → 再次请求评审如此循环直到没有新的有效反馈人工最终审查这是我用来强化前文提到那些架构与流程原则的关键环节此外在功能开发循环之外我还会持续且尽早地让 Copilot 执行以下“检查型任务”/plan检查是否存在缺失测试、被破坏的测试以及死代码/plan检查代码是否存在重复或是否有抽象机会/plan检查文档与代码识别文档缺口并更新copilot-instructions.md以反映相关变化这些任务我通常会每周自动运行一次但在新功能或修复不断进入时我也经常在一周内多次手动触发以持续维护我的智能体驱动开发环境。带走这些思考最初我只是因为一个重复性极强、几乎无法忍受的分析任务而感到困扰但最终这件事演变成了一个更有意思的结果一种关于我们如何构建软件、如何协作以及如何成长为工程师的新思维方式。以“编码智能体优先”的思维方式构建智能体彻底改变了我的工作方式。这不仅仅是自动化带来的效率提升——尽管看到四位“科学家”在不到三天内交付 11 个智能体、4 个技能以及一个全新概念本身就已经非常惊人——更重要的是这种开发方式迫使你去优先关注那些真正重要的事情清晰的架构、完善的文档、充分的测试以及深思熟虑的设计——这些我们一直知道很重要但却总是没有时间去做的事情。“初级工程师”的类比在这里被不断验证。你会为他们提供良好的入职引导给出清晰的上下文构建防护机制以避免错误演变成灾难然后逐步信任他们成长。如果出了问题就归因于流程而不是个人或智能体。如果说我希望你从中带走什么那就是让你成为优秀工程师和优秀团队成员的那些能力也正是让你能够用 Copilot 构建出色系统的能力。技术是新的但原则不是。所以去整理你的代码库吧去写那些你一直拖延的文档吧并开始把 GitHub Copilot 当作团队中最新的一名成员来对待。你可能真的会把自己“自动化”到职业生涯中最有趣的那一类工作里。觉得我在胡说那就试试这个下载 Copilot CLI在任意仓库中启用 Copilot CLIcd repo_path copilot输入以下提示词/plan Read link to this blog post and help me plan how I could best improve this repo for agent-first developmentCopilot CLIhttps://github.com/features/copilot/cli/?wt.mc_id3reg_webpage_reactor