引言

“我可能刚刚把自己的工作方式，自动化成了另一种样子……”

这是 GitHub Copilot Applied Science 团队高级应用研究员 Tyler McGoffin 在博客文章里的开场白。

软件工程师一直在用自动化消除重复劳动。但最近的变化有点意思——自动化开始往“智力劳动”这层推进了。

这篇文章讲的是 Tyler 如何用 GitHub Copilot 搭建一个叫 eval-agents 的项目，以及他在这个过程中总结出来的 Agent-Driven Development 方法。

核心看点在于：当 Agent 开始进入主流程以后，代码库、文档、测试、审查和协作方式会怎么一起变化。

一、问题背景：不可能完成的任务

Tyler 的工作是分析编程 Agent 在标准化评估基准上的表现，比如：

• TerminalBench2
• SWEBench-Pro

这些 benchmark 跑完以后，会留下大量轨迹数据。每条轨迹本质上都是 Agent 在执行任务过程中的思考和行动记录，通常是几百行甚至更长的 JSON。

真正的工作量不在某一条轨迹，而在规模：

• 数十个任务
• 多个 benchmark 运行
• 最后堆成数十万行需要阅读和整理的代码与数据

Tyler 最初的办法，是先用 GitHub Copilot 帮他从这些轨迹里提取模式，再由他自己继续深入分析。

这已经把阅读量从数十万行压到了几百行，但问题还在：很多工作仍然是重复的。

于是他开始做一件很典型的工程师会做的事：既然这件事已经能看出模式，就继续把它自动化。

二、三个设计目标

这个项目一开始定的目标有三条：

设计目标

这三个目标里，第三条影响最大：让编码 Agent 成为项目里的主要贡献者。

这意味着项目本身就要对 Agent 友好。代码结构、文档、测试和开发流程都要能让 Agent 读得懂、走得通、改得动。

三、开发环境与工具

Tyler 用的核心环境其实不复杂：

• GitHub Copilot in VS Code (Insiders)
• /plan
• /autopilot
• Copilot CLI
• Copilot SDK

这里的关键不在工具名单，而在它们的分工：

• /plan 用来规划
• /autopilot 用来自动实现
• CLI 和 SDK 用来注册工具、技能和 Agent 能力

也就是说，Copilot 在这个项目里不是“写代码时偶尔帮一下”的助手，而是开发流程里的常驻角色。

四、三条核心原则

Tyler 后来把自己的实践压成了三条原则。

三条核心原则

原则一：Prompting 策略

核心想法是：如果你想让 Agent 像工程师一样行动，就按工程师的方式给它输入。

具体做法包括：

• 引导它的思考过程
• 把假设讲完整
• 先规划，再动手

原文里有一句经验很直白：把自己对问题的思考过程放进提示词里，再配合规划模式，效果会比只给一个简洁问题陈述更好。

这其实很符合日常工程协作。你带一个新同事时，也不会只丢一句“把这个功能做了”。你通常会补：目标是什么、哪些地方可能有坑、你为什么担心这里、先看哪几块。对 Agent 也一样。

原则二：架构策略

原文里提到一个很关键的转向：过去那些总被推迟的重构、没时间写的测试、一直欠着的文档，在 Agent-Driven Development 里反而变成了最优先的事。

原因很简单：

• 名字乱，Agent 就更容易读错
• 文件结构乱，Agent 就更容易改错地方
• 文档缺失，Agent 就更容易靠猜
• 测试不足，Agent 犯错的代价就更高

所以 Tyler 会主动把时间花在这些事情上：

• 重构名称和文件结构
• 写文档
• 增加测试
• 清理死代码

这套动作对人类工程师有用，对 Agent 同样有用。

原则三：迭代策略

第三条原则很接近工程里的无责文化：责怪流程，而不是责怪 Agent。

如果 Agent 做错了，不是简单下结论“它不行”，而是反过来问：

• 有没有缺测试
• 有没有缺护栏
• prompt 有没有给清
• review 流程有没有漏

然后再把这些流程补上。

原文里把这套做法落成了几类具体工具：

• 严格类型检查
• 健壮的 linter
• 集成测试
• 端到端测试
• 契约测试

核心逻辑很明确：让 Agent 在开发循环里也能用这些工具检查自己的工作。

五、Agent-Driven Development 的开发循环

Tyler 把完整开发循环写得很清楚，大致就是下面这套：

开发循环

顺着这套流程看，会发现它并不神秘：

1. 先用 /plan 把功能规划清楚
2. 再用 /autopilot 自动实现
3. 然后进 code review loop
4. 最后再做人工审查

功能循环之外，还有一层固定维护动作：

• 查缺失测试
• 查坏测试
• 查死代码
• 查重复逻辑
• 查文档缺口
• 更新 copilot-instructions.md

这其实已经不是“让 AI 写一点代码”，而是一套完整的 Agent-first 工程流程。

六、结果为什么会让人印象深刻

文章里给出的结果是：

成果数据

这组数字最容易让人误解成“AI 写代码太快了”。但如果只看到速度，就会把重点看偏。

真正值得注意的是：

• 5 个人
• 首次参与项目
• 不到 3 天
• 11 个 Agent
• 4 个新技能
• 一个新的 workflow 概念
• 345 个文件变更

这说明的不是“AI 能一次生成多少行代码”，而是：当代码库本身开始围着 Agent 重新组织后，团队交付方式会一起变化。

七、这篇文章最后留下来的几句话

这篇文章最值得记的，不是“Copilot 有多强”，而是下面这几句：

1. 技术是新的，原则不是新的。
2. 让你成为好工程师的那些能力，也会决定你会不会用好 Agent。
3. 干净的架构、清楚的文档、完整的测试，以前就重要，现在更重要。
4. 当 Agent 真进入主流程以后，流程设计和护栏会比“单次生成效果”更重要。

如果你现在也在让 Claude Code、Codex 或 Copilot 逐渐承担更多编码工作，这篇文章最有价值的地方，在于它把一个很具体的问题说清楚了：当 AI 开始成为代码库的主要贡献者，团队真正要改的，不只是 prompt，而是整套开发方式。