微软9名工程师用AI代理一天合并1211个PR，构建Copilot Cowork

今年1月，Microsoft的一个小团队开始构建Copilot Cowork——一个代表用户执行多步骤工作流的智能体执行层。这一成果将开发者如今拥有的强大AI辅助工具和能力带给日常知识工作者，同时具备Work IQ、Microsoft 365安全与治理、云执行以及Microsoft的多模型架构。

这是一个关于团队如何用大约四个半月将Copilot Cowork从空仓库推向全球正式发布（GA），随后又在线上运行期间将其运行时从Python迁移到Rust的故事。大部分代码由智能体编写。工作方式也随之改变，其他团队可以借鉴这些实践，像前沿开发团队一样构建产品：在快速推进的同时，兼顾可靠性、安全性和成本。

10月21日，九名工程师向Copilot Cowork后端的主分支合并了1,211个pull request。这个数字在一月份时对团队来说简直是天方夜谭，当时我们几个人刚向一个空仓库提交了第一个commit。

大部分代码由智能体编写，但工程师仍然负责定义工作内容和评判结果。我们这个小团队编写更清晰的规格说明，设定架构和安全边界，并将评审重点放在高风险变更、生产影响以及检查或评审者意见不一致的情况上。自动化检查和智能体评审者会审查每一处变更。智能体可以提出变更，但它们不能决定允许发生什么。

我们并非一开始就计划这样工作。但每隔几周，智能体就会变得更强，我们流程中的某一部分就会失效，然后我们就得调整。

这些变化催生了六项实践。它们涵盖了我们如何定义工作、如何在明确边界内运行智能体、如何测试我们的检查机制、如何保留团队所学、如何为并行工作塑造代码库，以及如何为自动化循环设定限制。它们并不是复制我们PR数量的配方。它们是其他团队可以借鉴的经验，用以像前沿开发团队一样构建产品，同时兼顾可靠性、安全性和成本。

最后我们将以一个将这些实践综合检验的项目收尾：将线上运行时从Python迁移到Rust。

第一个commit于1月13日提交。从一开始，代码就由智能体编写。

在最初几周，我们了解到，拖慢我们的很少是智能体本身。瓶颈在于不清楚自己到底想要什么。一个模糊的请求会得到看起来合理、快速浏览能过关、但实际做错事的代码。修复它的时间比一开始写一份规范的请求还要长。

于是我们采用了一条至今仍然有效的规则：没有先写好markdown规格说明，就不写代码。规格说明涵盖三件事：

一份好的规格说明节省的时间远超其前期成本。但一份薄弱的规格说明会导致几天后的返工。智能体实现得越快，我们就越需要精确地表达意图、需求和“好”的标准。

我们的许多规格说明始于口头表达。有人讲述一个功能，智能体将其转化为规格说明的初稿，然后由人来编辑。我认为这对我们速度的提升超过了任何一次单一模型升级。

我们在3月30日向Frontier计划中的首批企业客户发布了Copilot Cowork。

下一步是同时运行多个智能体。每个智能体在各自仓库副本中、针对一个任务、依据一份规格说明工作。一个智能体变成五个，五个变成几十个。

每月合并的PR从1月份的257个增长到5月份的2,754个。GA前最忙的一周有783个。

并行工作的效果比我们预期的要好，原因有两个：

在Copilot Cowork中，模型运行在一个没有用户凭据的容器中。容器外的一个可信宿主负责身份、策略、审批和工具，所有Microsoft 365操作都通过宿主进行。

我们不想限制智能体可以尝试什么，因为被严格限制的智能体不太有用。在我们的架构下，模型可以规划和请求任何事情，由宿主决定实际发生什么。

这种分离让我们可以增加并行工作的智能体数量，而不必给模型凭据或对操作的直接权限。宿主仍然在执行点应用身份、策略、审批和审计。

在开始时就把这一点构建进去，比后来再添加要容易得多。它还以一种我们未曾预料的方式帮到了我们。智能体只通过一个定义好的接口与宿主通信，因此我们后来可以在不改变智能体的情况下替换整个宿主——我们在迁移到Rust时就是这么做的。

我们在6月16日实现了全球正式发布，距离第一个commit大约四个半月，支持多个模型和16个插件。

由于大部分代码由智能体编写，九个人无法阅读每一处变更，等待人工评审成了每个PR最慢的环节。

几位工程师各自构建了自己的评审机器人，模仿他们自己评审代码的方式，这些机器人相互竞争。当一个机器人发现了另一个机器人遗漏的问题时，遗漏问题的机器人就会新增一条规则。随着时间的推移，每个评审者都积累了大量从自身遗漏中学习到的规则。每个评审者现在都经历了至少10,000代；在每一代中，评审者执行评审，然后反思自己遗漏了什么，并提升代码评审能力。

如今，一个有价值的首次评审通常会在pull request打开后几分钟内到达。在近期已合并PR的样本中，中位数约为四分半钟。

作者在变更仍然新鲜时就能获得快速反馈，而详细的阅读仍然会发生。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）