Microsoft Copilot Cowork 开发：九名工程师、1,211 个拉取请求与验证瓶颈

Microsoft 表示，在 10 月 21 日的 Copilot Cowork 开发中，九名工程师合并了 1,211 个拉取请求，其中大部分代码由代理编写。拉取请求是在整合前提交变更以供审查的一种方式。这一区别至关重要：标题衡量的是已合并的变更，而生产力还取决于这些变更的实用性、可靠性和维护负担。

这份于 11 月 2 日发布的工程实践报告，描述了一个团队如何改变软件的规格定义、审查与运营方式。其核心矛盾在于，不断扩大的实现能力与有限的验证能力之间的冲突。只有当组织能够判断哪些变更值得交付给用户时，生成更多变更才会创造价值。

Anthropic 的代理研究与 Google 的软件交付研究提供了有价值的参考，但并未独立验证 Microsoft 的成果。两者都将注意力引向 AI 工具周围的系统。随着代码生产能力更容易扩展，工程领导者面临的压力将更多落在审查实践、架构和问责机制上。

Copilot Cowork 开发里程碑实际衡量的是什么

根据 Microsoft 的 Copilot Cowork 工程实践报告，后端团队自 1 月启动工作后达到了这一单日总量。工程师仍负责需求定义及风险较高的决策。自动化检查和代理审查员会检查变更。Microsoft 还描述了一项敏感变更：人工审查员发现了四个代理审查员遗漏的阻断性问题。

已合并的拉取请求记录的是被接受的活动；其业务价值仍需要独立证据来证明。

组织可以将一项功能拆分为许多变更，也可以将相关工作合并成一次较大的提交。两种做法都会改变数量，但都无法证明这些工作交付了多少客户价值。因此，仅以总量比较团队，可能是在奖励打包方式的差异，而非工程表现的差异。

较小的变更可以使审查更容易，因为每项提案提出的问题更聚焦。然而，一组单独看来都容易理解的变更，仍可能产生意料之外的综合影响。相关的评估单位有时会变成发布版本、客户工作流，或服务在一段时间内的表现。

设想一个假设的日程安排助手：它读取请求、检查可用时间并准备会议邀请。每个组件都可能通过各自的测试，但完整工作流却可能错误处理取消操作。统计成功的组件变更会遗漏客户真正遇到的问题。

这个例子说明，尽管该里程碑值得关注，但不应成为通用目标。这一数量表明整合流程异常繁忙，却没有披露功能复杂度、客户收益或维护最终系统所需投入的标准化衡量指标。

时间维度同样重要。这份报告描述的是通过持续开发逐步形成的运营模式，而非一次短暂的代码生成演示。读者应将其主张视为一家公司的生产案例研究，并考虑这种形式固有的全部背景和选择性限制。

因此，Copilot Cowork 工程实践提出了一个超越编码速度的管理问题：接受一项变更需要什么证据？不同答案意味着不同的人员配置需求。强调本地测试结果的团队，其组织方式将不同于要求安全审查、运营证据和客户结果检查的团队。

单日总量无法为另一家组织回答这个问题，但它让这一问题更难被继续搁置。一旦实现能力扩张，薄弱的验收标准就会成为运营约束，而不再只是偶尔的不便。

对采购方而言，这一区别同样实际。供应商的开发节奏描述的是其改变产品的能力。采购方仍需要证据证明，这些变更改善了员工所依赖的工作流。

工程领导者面临验证能力问题

当实现能力扩张时，稀缺资源就变成了对交付内容建立有充分依据的信心。

信心有多个来源：精确的需求、有意义的测试、知情的审查，以及运行中服务提供的证据。这些来源回答的是不同问题。测试可以证明特定输入下的预期行为，却无法证明需求本身是否服务于客户。

Google 的 AI 辅助软件开发研究提供了更广泛的比较。其 2025 年 DORA 研究结果将 AI 采用与交付吞吐量提升联系起来，同时强调周边组织的重要性。该研究将 AI 描述为现有优势和弱点的放大器。

这一视角支持对 Microsoft 里程碑采取审慎解读。拥有清晰责任归属和可靠发布控制的团队，有能力将新增的实现能力导向合适位置。职责尚未厘清的团队，则可能积累更多无人能放心批准的提案。

因此，压力首先落在工程经理和平台团队身上。他们决定谁负责验收标准、哪些变更需要专家关注，以及如何回滚一次发布。当提案更快到来时，这些决策会变得更加重要。

安全专家面临相关的资源分配问题。以同等强度审查每项变更，会无视风险而消耗注意力。只审查明显涉及安全的文件，则会遗漏在其他位置引入的行为。困难之处在于，将变更与其影响的权限、数据和客户操作关联起来。

产品经理也承担了更多责任。当软件能够在分歧浮现前就被产出时，模糊的请求会变得昂贵。即使从技术上看修改代码仍然直接，一个看似完善的实现也可能围绕被误解的需求形成惯性，使纠正变得更具政治难度。

组织在这里应区分等待与必要审议。某些延迟源于信息缺失或审查员超负荷，另一些延迟则是在保护不可逆的决策。将两者都视为浪费，会鼓励团队仅因保护措施拖慢仪表盘指标就将其移除。

一种有用的管理应对方式，是审视不确定性在哪个环节进入流程。如果审查员反复询问某项功能应当如何运作，需求就需要改进。如果他们反复质疑部署影响，发布流程就需要更好的可见性。

这些是组织层面的诊断，而不是为无限制流程辩护。每一项额外控制都会带来成本。标准应是：它是否回答了其他控制尚未解决的重要问题。

Copilot Cowork 开发故事以异常直观的形式呈现了这种权衡。工程领导者如今需要说明，如何在扩张实现能力的同时扩张验证能力。购买编程代理的访问权限，并不能解决这一运营决策。

对企业采购方而言，相应的问题在于变更质量。当员工经历更少中断、更清晰的权限以及更可靠的任务完成时，更快的发布才会变得有用。仅凭发布频率无法确定这些结果。

Copilot Cowork Rust 迁移将语言与架构区分开来

Microsoft 报告称，在一个比较窗口内，Copilot Cowork Rust 迁移将首轮响应时间中位数从 7.9 秒降至 2.7 秒。它还将部分改善归因于迁移代理循环，并未提出每轮成本方面的主张。

一次迁移可以改善服务，却不能证明编程语言造成了每一项改善。

运行时是执行应用程序工作的软件机制。在不同语言之间迁移这套机制，可能改变内存管理、调度、部署和启动行为。若多项元素同时改变，最终测量结果捕捉到的便是它们的综合效应。

这一区别很重要，因为编程语言之争往往将一项架构项目压缩成简单的竞赛。这种框架能制造醒目的标题，却无法为另一个团队的投资决策提供良好依据。真正相关的问题是，哪种机制能解决其自身的瓶颈。

Rust 的并发保障提供了具体的技术参考。并发意味着程序的不同部分可以独立取得进展。Rust 利用所有权规则和类型检查，在执行前捕获许多内存与并发错误。

这些保障也有局限。它们不能证明响应包含正确的业务信息、操作具有相应权限，或用户会按预期顺序收到事件。语言安全与应用正确性只存在部分重叠。

日程服务说明了这种差异。它的代码可以安全处理内存，却选择错误的日历。它的任务可以在没有数据竞争的情况下执行，却在获得批准前发送邀请。语言层面的保障无法弥补缺失的产品规则。

因此，迁移证据需要多个层面。一层涉及资源使用和响应时间，另一层涉及真实流量下的行为，还有一层涉及替代方案是否保留了此前隐含的义务。

理想的受控比较会在保持工作负载和基础设施条件稳定的同时，记录待评估的变更。生产迁移很少能提供完美的实验性分离。这一限制应影响归因方式，而不是抹去有用的运营测量结果。

对于阅读 Copilot Cowork Rust 迁移报告的开发者而言，实际含义是进行分析。在概括结果之前，应先确定相关问题是否涉及执行调度、启动开销、内存行为或应用设计。

对采购方而言，语言本身通常不如服务结果重要。更快的初始响应很有价值，但并不能证明完成整项任务更快。系统可能更早开始回答，却仍需更长时间才能产出正确的交付物。

同样的区别也适用于经济性。延迟改善并不自动意味着运营成本降低。基础设施使用、模型调用、重试和支持工作都会影响计算结果。

这使得该迁移成为归因问题的有用案例研究。它说明，当工程结果成为公开性能主张时，为什么应保留其架构背景。

代理审查需要独立的信任依据

只有当新增审查员的检查提供有用且足够独立的证据时，才能提高信心。

AI agent 是一种由模型驱动的系统，它会围绕目标选择行动并使用工具。Agent 审阅者可以检查拟议变更、识别问题并要求修正。其判断仍然是一项需要评估的输出，尤其是在编写 agent 已提供了大量周边说明的情况下。

Anthropic 的 agent 工作流模式描述了将生成与评估分离的系统。该公司建议采用简单的设计、明确的评估标准，并且仅在复杂性能够改善结果时才增加复杂度。这为日益增长的自动化审阅作用提供了一个有益的对照。

当成功可以被直接观察时，评估者的工作会更容易。数值计算可以通过独立计算进行核验。对权限敏感的工作流则需要不同类型的证据，因为正确行动取决于身份、策略和上下文。

核心风险在于共同误解。编写者和审阅者可能因为以同样的方式理解了含糊的需求而达成一致。他们的一致并不能消除这种歧义。只有当独立的模型或提示带来与证据或推理相关的差异时，它才有帮助。

测试也有类似的局限性。与实现一同编写的测试可能会复现实现所依据的假设。通过测试证明这些产物彼此一致，但并不一定证明它们与预期行为一致。

独立证据可以来自现有契约、观察到的行为、已批准的需求，或精心挑选的失败案例。正确的来源取决于变更本身。关键区别在于，这些证据是否能够反驳实现。

设想一项自动检查：即使没有收到相关输入，它仍报告成功。其结果看起来像一次成功的检查，但其中并不包含有关拟议变更的信息。当用户无法判断检查实际审查了什么时，一个可见的通过标记就会产生误导。

这就是为什么审阅质量不能简化为分配的 agent 数量。一小组目的明确且彼此不同的检查，能比反复进行的广泛审阅提供更多信心。目标是在不制造难以阅读的评论流的前提下，覆盖关键的失败模式。

人工参与同样需要明确的角色。要求某人在没有时间或上下文的情况下批准变更，只会形成名义上的监督。有效审阅需要清晰的决策、相关证据，以及否决提案的权限。

对于 Copilot Cowork 开发而言，更广泛的启示在于自动化与问责之间的关系。更快的自动化反馈可以支持人类判断，但组织仍需要明确的风险接受依据。

这一依据应当在最初的作者退出讨论后仍然易于理解。可搜索的需求与决策记录有助于未来审阅者重建原意。负责管理这些上下文的团队可以探索一个可搜索的知识库，但不应把存储的文档视为软件行为正确的证据。

生产力研究让拉取请求的标题变得更复杂

Microsoft 的案例研究与独立生产力研究衡量的是不同事物，因此二者的发现不能相互替代。

METR 的开发者生产力实验提供了一个有益的制衡。在其 2025 年初的研究中，16 名经验丰富的开源开发者完成了 246 项任务。在该环境下，允许使用 AI 使完成时间增加了 19%，尽管参与者认为这些工具有所帮助。

这一结果涉及特定的开发者、代码仓库、任务和工具。它并不能证明 AI 会拖慢每一个工程团队。它也无法直接评估后来围绕大量并发 agent 组织的工作流。

METR 随后进一步限定了这一结论。其 2026 年 2 月的生产力实验更新描述了选择问题，以及开发者并发使用 agent 时测量时间的困难。研究人员认为，较新的结果并不可靠，无法精确估计当前影响。

这些来源共同揭示的是测量问题，而非普遍性的结论。任务完成时间、合并的变更数量和自我报告的实用性可能以不同方式变化。在解读结果之前，可靠的评估会明确哪一种结果才是重要的。

对于个体开发者，工具可能减少不愉快的工作，却不减少耗费的时间。对于组织，工具可能扩大可行项目的范围，却不降低维护成本。这些好处值得考虑，但需要准确的标签。

一个团队也可能因为选择了更小的任务而完成更多工作。这可能通过减少等待和不确定性来改善交付。它也可能在重大客户问题仍未解决时，夸大活动指标。仅凭数量无法区分这些解释。

反事实同样重要。评估生产力需要说明：如果没有该工具或流程，本会发生什么。一次成功发布证明团队交付了某些成果，但并不能独立证明其中有多少加速归因于 AI。

Microsoft 的公开说明提供的是一个运营实例，而非随机对照比较。这种形式可以揭示有用的机制和失败模式，但无法分离开发者专业能力、基础设施、组织支持和模型能力各自的全部贡献。

同样的谨慎也适用于竞争对手。Anthropic 的架构指导说明了一种设计方法，而 Google 的研究描述了更广泛的模式。两者都不能证明哪一家供应商能为特定企业工作负载带来最佳结果。

对于工程领导者而言，这意味着应避免把一个令人印象深刻的数字变成编制公式。人员配置决策需要关于持续交付、质量、支持负担以及仍处于测量流程之外的工作的证据。

这个故事还留下了一个经济问题。被接受工作的总成本包括生成、评估、基础设施、人类注意力，以及发布后的修正。更多实现活动可以与更好或更差的经济效益并存。

因此，应将 Copilot Cowork 工程视为重组工作的一个具体案例。它最强的贡献在于促使人们就证据提出更好的问题，而不是给出工程师与 agent 之间的通用换算率。

三项信号将使开发模式更容易评估

下一批有用证据将涉及持续结果、可重复验证，以及被接受工作的完整成本。

第一项信号，是将开发活动与生产可靠性联系起来的后续报告。在未来数月中，披露发布失败、回滚或反复出现的客户问题，将有助于读者解读已合并变更的数量。

如果可靠性改善的同时交付得以持续，这将强化该运营模式的论点。若修复工作增加，情况则会更复杂。无论哪种结果，都比另一条孤立的活动记录更具决策价值。

比较应使用一致的定义。报告实践的变化可能让一项服务看起来更健康，而其行为实际上并未改变。读者应寻找稳定的测量窗口，以及对何种情况构成失败的清晰说明。

第二项信号，是验证实践能够迁移到原团队之外的证据。一份有记录的评估、可复现的测试设置，或可比较的生产案例，将有助于区分一种广泛有用的方法与依赖特殊条件的结果。

复现并不要求另一个团队达到相同的每日总量。它要求证明，额外的实现能力能够产生被接受的结果，而不会压垮审阅和运营。不同工作负载理应产生不同的活动水平。

如果其他团队能在不同约束条件下复现这些收益，这一案例就更具普遍性。如果成功高度依赖专业基础设施或集中的专业知识，其适用范围就会更窄。即便如此，这对买方和工程领导者而言仍是有用信息。

第三项信号，是可信的经济核算。每项成功完成的客户任务成本，将把工程变更与产品的运营现实联系起来。它也会揭示重试和纠正工作是否消耗了表面上的效率收益。

一项有用的披露应说明哪些成本被纳入计算。排除审阅或基础设施成本，回答的是一个更狭窄的问题。将其纳入，则有助于组织把这种方法与现有流程进行比较。

这些是观察重点，而非已宣布的报告承诺。Microsoft 尚未承诺提供这里讨论的每一项测量。它们的缺失只会让案例的部分内容仍未解决，而不会自动证明失败。

对于企业买方，眼下的行动是要求供应商提供与实际工作流相关的证据。选择员工会执行的一项任务，定义可接受的结果，并检查系统如何处理例外情况。将开发活动与客户成功区分开来。

对于正在评估 Copilot Cowork 开发的工程领导者而言，应利用这一里程碑来明确自身采用决策背后的问题。识别团队难以验证的内容、意图容易丢失的环节，以及哪些结果值得增加自动化。在具有意义的一段时期内比较被接受的工作，包括修正这些工作所需的投入。阅读底层工程说明时，也应结合生产力研究，因为它们回答的是不同问题。然后审视你的组织是否能够说明，为什么一项变更值得发布。当实现能力变得更容易扩展时，这种说明就成为工程领域的一项核心责任。什么证据能让你的团队相信，更多生成的代码已经变成了更可靠的软件？