智能体驱动开发：AI主导代码库的实战指南

引言

“我可能刚刚把自己的工作流程，自动化成了另一种形态……”

这句话出自 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 个新技能
• 1 个新 workflow 概念
• 345 个文件变更

这揭示的不是“AI 一次能生成多少行代码”，而是：当代码库围绕 Agent 重新组织后，团队的交付方式会发生根本性变化。

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

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

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

如果你目前正在让 Claude Code、Codex 或 Copilot 承担更多编码任务，这篇文章最有价值的地方在于：它把一个非常具体的问题讲透了——当 AI 开始成为代码库的主要贡献者，团队真正需要改变的，不只是 prompt，而是整套开发方式。