全队用上编码智能体后：代码量涨了三成，交付的软件却没多一个

过去一年，许多团队都撞上过同一种矛盾感：代码行数确实上去了，PR 也更多了，但真正发布出去、真正被用户用上的功能，好像并没有等比例变多。团队里的人还经常觉得比以前更忙。这不是错觉，也不一定是工具没用对，它背后有一条能被讲清楚的机制链。

编码智能体把「写代码」这一段变得又快又能并行，同时把成本推给了那些没法简单扩容的环节。这篇专题就沿着这条链走一遍：先看清智能体到底由什么组成，再用约束理论和排队论解释机制，然后看 718 家企业的实测数字和它的边界，接着下钻到「为什么评测没暴露这件事」，最后回答一个越来越难回避的问题：在智能体时代，生产系统该把什么算作「完成」。

写代码更快，交付就会更快吗？——生成只是串联链上的一环

要判断「写得更快」能不能变成「交付更多」，得先知道编码智能体到底是什么。它不是一个能力更强的黑盒模型，而是模型外面套着的一整套运行时。2026 年 7 月的一项源码级研究把这层运行时解剖了出来：一个 agent 就是「模型 + harness」，harness 是除模型之外的全部工程层，负责把大模型通过循环、工具、上下文管理、安全控制和扩展接口接到真实代码库上Harness Eng。

研究从 11 个生产级系统（Claude Code、Codex CLI、Gemini CLI、Mistral Vibe，加上 OpenHands、Aider、Mini-SWE-Agent、Hermes、Pi、OpenCode、OpenClaw）里归纳出同一套解剖结构：围绕一个 agent loop，共有七个子系统。这七个子系统，从只有 100 行的研究基线到上百万行的生产 CLI，每个系统都要对它们各自表态。看懂这张结构图，是理解后面一切的前提。

图注：编码智能体等于「模型 + harness」。中央红框是 agent loop，也就是「想一步、做一步」的执行循环；上下的 LLM 集成与记忆/上下文、右侧的工具与动作、安全与权限、扩展能力，加上下方的编排层，合起来被虚线框成一个 harness。左上的 Interface Layer 是人或程序驱动它的入口。生成这件事，只发生在中心那个循环里。Harness Eng

值得注意的是，这个循环本身一点也不复杂。同一项研究把 11 个系统的 loop 归成三种范式，9 个系统都属于最简单的第一种。

图注：三种 agent loop 范式。左边（a）是最主流的迭代式动作-观测循环：提示词进入模型，模型决定调用哪个工具，环境返回观测，再进入下一轮。中间（b）在循环外挂了一个反思分支，Aider 走这条路。右边（c）是协调者-工作者结构，一个协调者派生多个子智能体再汇总，Claude Code 和 Codex 采用。11 个系统里 9 个属于第（a）类，而且循环大多手写，几十行就能跑起来。Harness Eng

这件事很重要，因为它说明了生成这一环的工程特性：它简单、可复制、可以并行扩张。研究还发现，系统的代码量跨了三个数量级，但循环的复杂度和 benchmark 成绩之间并不存在对应关系，那个 100 行的最小实现和上百万行的生产系统落在同一档成绩区间。换句话说，把生成做得更快、更多，工程上是能办到的。稀缺的从来不是生成。

现在把镜头从智能体内部拉回到团队。同一批企业里的另一项观察，给出了三个同时发生的数字。哈佛的两位研究者 Chen 与 Stratton 分析了 718 家企业、约 3 亿次工作事件，发现智能体采用后代码行增长约 30%、PR 数增长约 23%，而 PR 从提交到合并的时间延长了约 49%Chen & Stratton。代码更多、提交更多、合并更慢，三件事在同一个样本里同时出现。

图注：六个面板的事件研究，分别对应 agent 与 assistant 在代码行、提交数、PR 数三个指标上的效应。横轴是采用 AI 前后的月份，纵轴是每名工人的效应量，虚线标出采用时点和零效应位置，每个点是点估计并带 95% 置信区间。可以看到采用代理工具的那一列三个指标全部显著上移，采用助理工具的一列则要弱得多。Chen & Stratton

于是问题被磨利了：如果生成既简单又能扩容，为什么上游提速没有穿透成下游的交付？答案藏在这条链的形状里，下一章就来讲它。

生成多了，卡点为什么会落在审查？——约束理论与排队论的机制

软件交付不是一堆可以同时推进的独立任务，而是一条串联链：上游交不出东西，下游就只能干等，谁也绕不过谁。约束理论给这条链提供了一句人话总结：在任一时刻，系统只有一个约束，整个系统的产出等于这个最慢环节的产出；提速任何非约束环节，只会把半成品堆在约束的上游，系统整体并不会更快TOC。把这句话落到交付链上，就是下面这张示意图。

图注：软件交付作为一条串联链，中间那个环节被标成瓶颈。约束上游会堆积待办，非约束环节则有余量空转。图的要旨是一句话：系统吞吐由最慢的一环封顶，优化非约束只能堆起半成品。这是一张用于说明约束理论的概念示意图，不是说审查在每支团队里都必然是瓶颈，那是一个要靠数据回答的经验问题。

产品开发领域最有名的那句话来自 Reinertsen，他说队列是产品开发中大量问题的根，它们抬高变动性、风险和周期，压低效率、质量和士气。他还给了一组诊断数字：在他的课程学员里，只有约 2% 的人测量自己的队列，只有约 15% 的人知道自己延迟的代价。

那为什么「利用率」会变成陷阱？这里要引入第二件工具，排队论。先看它最朴素的一条结论：系统里平均同时存在多少件工作，等于平均到达率乘以平均停留时间Queueing。换成 PR 审查的场景就好懂了：如果队列里常年躺着 20 个没审的 PR，而团队每天能审完 10 个，那么每个 PR 平均要等 2 天。这条式子不是因果律，它只说明三者之间的会计关系，想压缩等待时间，就得动到达率、单件处理时间或审查人数中的某一个。

真正让人不舒服的是利用率曲线。排队论里有一条近似，把平均排队等待表达成「利用率因子 × 变动性因子 × 服务时间」。只看利用率这一项，它长成 $\rho/(1-\rho)$ 的样子。$\rho$ 就是审查者被占用的比例。代入具体数字，会看到一条非常陡的曲线：

把审查队伍从 70% 占用推到 80% 占用，等待不是线性加 10%，而是乘上约 1.7 倍；一旦越过 90%，每多占用 1 个百分点，等待都会显著跳升。另一项要用到直觉的结论是变动性：两项因子里的「变动性」一栏意味着，两个利用率相同的队列，等待时间可以差出好几倍。小改动十分钟能审完、一次 schema 迁移可能要三个小时，加上周五下午 PR 集中涌入，都会把这条曲线往上推、把方向推向非线性。

图注：三格 PR 审查队列快照，利用率从低到高逐格恶化。左侧格子队列稀疏、等待短；越往右，队列越拥挤，底部的等待曲线越往上弯。图的重点是那个弯：利用率逼近上限时，等待不是缓慢变多，而是加速爆炸。

现在把两章接起来，机制就浮出来了。智能体提高了进入审查环节的到达率。而审查这一环，掌握的是领域上下文和合并责任，这两样东西不像生成那样能靠加并发硬堆，审查者的人数和他愿意投入的会话时间在短期内几乎不变。于是利用率 $\rho$ 沿曲线右移，审查队列承受的压力随之上升，等待与返工都可能被推高。第 1 章那个「+49%」到这里可以接上，但它只印证方向，说不了构成。这里要守住一条口径：这 49% 是 PR 从提交到合并的日历时间，里面包含排队等待，它并不等于审查者主动阅读的时间，也不能读成「审查者变忙了」。更准确的表述是条件性的：+49% 的日历历时与审查队列受压相一致，但不能单凭这一个指标分辨等待、主动审查和返工各自增加了多少。

把这个推理画成因果链，是这样：

到这里，机制是清晰的，但它还只是「机制支持这个解释」。企业数据真的落在这条曲线上吗？下一章去看证据，也去看它的边界。

718 家企业的实测：产出涨、吞吐平、等待涨——以及它的证据边界

第 2 章给出的是一套机制预测。要检验它，得看真实企业里的数据。Chen 与 Stratton 的观察研究是目前唯一一项把「AI 采用、代码行、PR、Jira 事项完成」四个层级全部打通的大型企业级测量。数据来自工程分析平台 Jellyfish，覆盖 718 家企业、约 72.6 万名工作者，时间跨度从 2021 年 1 月到 2026 年 3 月。识别策略是错时双重差分，也就是利用不同企业采购 AI 工具的时点差异来估计效应Chen & Stratton。

把八个关键数字摆在一起，图景非常清楚：

这张表值得多读两遍。最刺眼的对比在最后两行：代码侧的产出涨了三成，而真正被标记为「已解决」的工作事项没有显著增加，其上界离三成还差得远。作者用两套方法验证过这个「零结果」不是任务变大造成的假象，事项的平均规模并没有显著变化。第 1 章那张六面板事件研究里，agent 与 assistant 的差别也在这里显形：代理工具在代码行、提交、PR 三个指标上都显著上移，而助理工具只有提交数显著。

再看审查侧。三个指标一起，与审查环节受压、等待上升的解释一致。不过这里要立刻把口径钉住：它们是历时长短和审查信号多寡的度量，单看这几个数字，并不能把队列等待、主动审查与返工这三样拆开，所以只能说与解释一致，不能说它们证明了受挤压的究竟是其中的哪一项。

图注：PR 从提交到合并的耗时事件研究，两个面板。采用代理工具的一侧（上），天数在采用前后从低位单调抬升；采用助理工具的一侧（下），点估计一直贴着零附近波动。要点是那个「+49%」衡量的是从提交到合并的日历历时，里面含排队等待，不能直接读成审查者主动工作多了多少天。Chen & Stratton

审查强度还体现在另外两个信号上，下面这组面板把它们一起画了出来。

图注：四个面板，上排是含「请求修改」的 PR 比例，下排是每 PR 评论数（左列代理工具、右列助理工具）。代理工具两项都显著上移，助理工具两项都不显著。要留意的是，「变更请求近乎翻倍」是审查信号变多的证据，它并不是缺陷率或 bug rate 的直接度量，论文明确说没有直接测质量。Chen & Stratton

这三组数字合起来，与审查环节受压、等待上升的解释一致：产出涨、等待涨、下游完成度平。和第 2 章那条曲线一样，这只是一组方向性的印证，够不上对机制的证明，因为这些指标同样无法单独拆分队列等待、主动审查与返工各自贡献了多少。还有一条容易被忽略的旁证：截至 2026 年 3 月，约 80% 的企业已经用上了 AI 审查工具，但只有 23.3% 的评论由 AI 生成、只有 10.8% 的 PR 收到过至少一条 AI 评论。企业仍然把人作为合并门槛，AI 审查并没有让人脱离回路。

读到这里必须停下来，把边界钉死，否则结论会被用错。

第一，这是观测研究，不是随机试验。错时双重差分利用企业采购流程长短的差异作为外生性来源，作者也用多种替代估计器复核过，但论文自己承认，这类设计支持把数字读成因果机制，而不是证明具体因果效应幅度。也就是说，「审查导致吞吐停滞」这句话，数据支持它、却没有独立证明它。

第二，「+49%」是日历时间含排队等待，不等于主动审查工时。第三，「+4pp」是执行审查的人占比，不是工时。第四，「变更请求近乎翻倍」不是 bug rate 的直接度量。

如果觉得这些边界太抽象，可以看一项方法完全不同的研究。METR 做了一个随机对照试验：16 位有经验的开源维护者，在他们自己熟悉的大型成熟仓库上完成真实任务，共 246 个 issue，随机分配是否允许使用 AI。结果是，允许 AI 时开发者平均多用 19% 的时间完成任务，95% 置信区间是 +1% 到 +39%METR。更能说明问题的是预测与实际的反差：开发者在任务开始前预测 AI 会让自己快 24%，任务结束后估计快了 20%，54 位机器学习专家平均预测快 38%，34 位经济学者预测快 39%，四条线的方向一致，而实际测量的那条线正好相反。

图注：双面板对照。左侧是开发者对「用 AI」与「不用 AI」两种情况下实现时长的预测，右侧是实际观测到的时长，两侧各自带比率估计的置信区间。放在一起看，中间的落差就是这张图想说明的事：预测和感知同向，实际观测却站到了另一边。METR

METR 的结果有明确的适用条件，大且成熟的仓库、经验丰富的维护者、2025 年上半年的工具版本。新手样本的既有研究方向相反，METR 自己也强调这并不意味着新手不会因 AI 提速。但它和 Chen 与 Stratton 一起给出了同一个结论的两个侧面：AI 提速的承诺本身就值得怀疑，而且这个怀疑是有条件的、不可无限外推的。

既然瓶颈在审查，为什么这么久了评测没把这件事暴露出来？这就把问题引到了评测侧。

单轮补丁通过率，为什么测不出真实成本？——评测盲区

回到你熟悉的那个场景。单轮编程评测通常这么测：给模型一个 issue 描述，让它产出一个补丁，跑测试，通过就算解决。SWE-bench 类基准的得分就是这么来的。问题在于，真实的编码智能体使用根本不是这个形状。

JetBrains Research 的 Slinko 等人采集了 4,782 个真实 IDE 生产会话，约 1.4 万条用户消息，其中三分之一是至少三轮的长会话。他们把这些消息归成 16 类意图，包括解释、提问、规划、调试、重构、审查、执行等等。对照之下，SWE-Bench Pro 的任务里新功能加 bug 修复占了 93.8%。真实会话和基准的形状，差得很远。

图注：左边是单轮 SWE-Bench Pro 的任务流，只有新功能和 bug 修复两个节点，加上很细的边；右边是按真实会话校准过的多步任务流，有 16 个不同意图的节点和更粗的有向边，边的粗细表示意图之间转换的频繁程度。左右对比直白地点出一件事：单轮评测把一个多步、来回切换的过程压扁成了「一个问题、一个补丁」。Slinko

更关键的是成本。研究者把单轮任务改造成多步协议，保留原来的仓库、需求和测试，只把交互层重新生成，然后在 700 个任务上跑了一轮。结论是：多步协议让 agent 的成本约翻倍，而解决率没有稳定提升。

图注：散点图，横轴是每个 issue 的平均 agent 成本（对数尺度），纵轴是解决率，四个模型乘以三种条件。多步方案的点整体明显右移、落在更高的成本区间，而纵轴上的解决率起伏很小、跨模型也相近。要留意，误差棒是三次运行的最小到最大值，不是置信区间，论文也没有做显著性检验，所以「成本约翻倍、解决率无稳定提升」是一个方向性结论。Slinko

这就把评测的激励结构暴露出来了。只测最终补丁是否通过，就等于把澄清、纠偏、验收这些人类付出全部排除在指标之外。单轮成绩越好看，越可能意味着有人替它把这些成本付了。Slinko 等人的工作是一个侧面，另外三项研究从不同角度收紧了同一个结论。

第一，同一个标签下的基准，测的其实不是同一件事。Shayanfar 等人给每个任务的「金补丁」算了三条轴：变更落在代码库的什么位置（散度）、增删比（新颖性）、被触及代码的架构分量（中心度）。拿五个主流基准来算，每一对基准都至少在两根轴上统计分离Shayanfar。也就是说，两个都叫「bug 修复」的基准，测的可能完全是两种工作。

图注：三行小提琴图，每行对应一条轴（散度、新颖性、中心度），列出五个基准金补丁的分布。行内的虚线分隔的是统计上可区分的分组边界，落在同一段里的基准在该轴上分不出高下。图证明的是这个更弱的结论：同一标签的基准并不等价。Shayanfar

第二，「用另一个 AI 廉价通过审查」这条捷径走不通。Groundability 研究团队做了 411 条带执行标签的真实轨迹和 101 个对照案例。结论是：在没有可机械检查的证据时，弱审查者会把缺陷漏检和过度驳回同时抬高。比如 GPT-4.1 在一组「整理过但没独立校验」的证据上，缺陷捕获率升到 0.91，但同时驳回了 86% 本可接受的补丁。只有当证据换成可执行、可机械核验的形态，捕获率和过度驳回才会解耦，六位审查者里有五位同时做到更准、更少误杀Groundability。这里还有个反直觉之处：可靠性来自证据的可核验程度，而不来自模型规模，研究中 235B 的模型在整理过的证据上表现反而差于 8B 的模型。

图注：横轴是过度驳回，纵轴是缺陷捕获，六个审查者各有两个点，箭头从「整理过的证据」指向「可执行证据」。除了一条虚线标出的例外，箭头都指向右上方向，意味着捕获率更高、误杀更少。要注意这是用官方执行证据得出的上限诊断，不是部署里能直接拿到的输入。Groundability

第三，真实部署里的账本更不好看。SWE-chat 数据集覆盖约 1.8 万个真实会话、22.9 万条 prompt、707 个仓库，全部智能体产出里只有 59.4% 真正进入了用户提交，其余被智能体自己重写或被人类删掉；用户在 50.2% 的 prompt 上对智能体做过纠正、否定或打断SWE-chat。它的会话分布还呈现明显的双峰：完全不用 AI 的占 25%，几乎全靠 AI 的占 41.1%，中间的协作式只占 33.9%。

图注：横轴是提交代码中由智能体生成的比例，纵轴是会话数。两端各有一个尖峰，一端是零、另一端接近百分之百，中间是一大片很矮的高原。均值 55.3% 低于中位数 75.6%，这个反差本身就是双峰形态的证据，不能把均值直接读成「智能体平均写了一半代码」。SWE-chat

四条证据放在一起，结论是一致的：单轮补丁通过率把澄清、纠偏、验收的成本全部挤到了指标之外，评测在系统性地奖励这种成本外部化。真实使用里那些来回切换的意图、那些被丢弃的产出、那些必须人来做的核验，都不会出现在最终得分里。

该把什么当作「完成」？——端到端稳定变更成本

如果只有一家企业、一项研究给出这个图景，还可以说它是特例。但行业级调查给出了同向的独立印证。DORA 的 2024 年生成式 AI 报告估计，AI 采用每提高 25%，软件交付吞吐量变化 −1.5%，交付稳定性变化 −7.2%，两者都带 89% 的不确定区间。同一份报告里，文档质量是 +7.5%、代码质量 +3.4%、代码审查速度 +3.1%、代码复杂度 −1.8%。这些是标准化回归系数，属于「每提高 25% 采用」对应的方向性数字，不是普适的效应量DORA。

DORA 自己给的解释很直白：AI 带来的生成速度跃升，可能让团队忘掉了交付里最基本的纪律，也就是小批量。同样时间里能产出更多代码，变更集就可能变大，而更大的变更历来更慢、也更容易引入不稳定。换句话说，速度提升如果没有配套的护栏，就会转化成验证与协调成本的上升。

到了 2025 年，DORA 的结论有了新变化：AI 现在能提升交付吞吐了，但仍然抬高交付不稳定。这份报告把 AI 的角色总结成一句话，AI 像放大器，它放大高效能组织的优势，也放大挣扎中组织的失调DORA。报告还指出，摩擦没有变、倦怠没有变、交付不稳定仍在上升，用词是这些结果很「顽固」。这说明 AI 是被嵌在一个更大的系统里起作用的，系统不变，单点工具就改变不了整体结果。

DORA 的指标本身也在演进。2024 年的「四个关键指标」是变更前置时间、部署频率、变更失败率、失败恢复时间。2025 年它被拆成两组因子，一组是吞吐，一组是不稳定。

把吞吐和不稳定分开看，是这一章往前推的关键。因为只盯吞吐，会得出「AI 让人更快」的结论；只有把不稳定和返工一起纳入，才会看到成本去哪了。这也解释了为什么不能再用单一指标衡量生产力。SPACE 框架把开发者生产力拆成五个维度，并明确说它不能靠任何单一指标来衡量。

同一份 review 数据，按不同维度看就是五件不同的事：review 次数属于活动，review 速度属于效率与流动，review 质量属于沟通，团队级的交付影响属于绩效，开发者对审查负担的感受属于满意度。这个例子恰恰说明，拿一个数字（不管是代码行、PR 数还是补丁通过率）去代表「生产力」，一定会丢掉东西。

所以优化单位要改写。把「补丁是否通过测试」替换成「每个经过验证、稳定上线的变更的端到端成本」，也就是把审查等待、返工、缺陷全部算进去。

落到工程动作上，有几件事是可以今天就做的。风险分级审查，把低风险改动走轻量通道，把人类注意力集中到高风险变更上。小批量，控制进入队列的变更体量，让利用率留在曲线的平坦区，第 2 章的曲线说明了为什么这一条回报最高。给审查者配 AI 助手，而不是让 AI 单独批准，用可机械核验的证据帮人更快做判断，Groundability 的结论正指向这里。把基准对齐到真实会话，用 Slinko 等人提出的思路生成贴近真实任务流的评测任务，让评测测的东西和团队实际在做的事对得上。

收口：让生成速率服从真实约束

现在可以把整条链收回来了。补丁通过测试是中间品，不是终点。它度量的是「生成能不能做出一个看起来对的东西」，而生产系统真正关心的，是「每个经过验证、稳定上线的变更，端到端花了多少成本」。Chen 与 Stratton 的结论把这一点说得更直接：应当优化的是端到端变更成本，并配上相应的组织投入，而不是单看补丁层面的成功率Chen & Stratton。排队论那边则给了最便宜的一招，限制在制品的数量就等于压短队列，因为队列里躺着的越少，每件工作的平均停留就越短。

带走三句话。第一，用串联系统和排队论去识别自己团队交付链的瓶颈形状，先弄清楚约束在哪、队列有多长，再决定加什么。第二，别再拿代码行数和补丁通过率当成功指标，它们会让成本外部化这件事看起来像是成绩。第三，评测和工程指标都要校准到目标场景的真实任务流与端到端成本，让生成速率服从真实约束。

否则，「更快」只是把队列烧得更长。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Artificial Intelligence in the Firm: Bottlenecks in Software Production（Fiona Chen & James Stratton, Harvard working paper, 2026）— https://fion.ac/jellyfish.pdf
2. Coding-Agent Benchmarks Should Match Their Users' Task Flows（Slinko, Golubev, Titov, JetBrains Research, 2026）— arXiv:2610.09633
3. What Does an Agentic Software Engineering Benchmark Measure?（Shayanfar, Gallaba, Hassan, 2026）— arXiv:2609.01271
4. Queueing Theory for Software Delivery（Pestelos reference note, 2026）— https://ngpestelos.com/reference/queueing-theory/
5. Theory of Constraints applied to software engineering（David J. Anderson, Agile Management for Software Engineering, 2003; Donald G. Reinertsen, The Principles of Product Development Flow, 2009）— https://demo.pyrite.wiki/site/anderson/agile-management-for-software-engineering
6. Groundability, Not Scale Alone: When Weak Reviewers Can Audit Strong Coding Agents（Guo, Gu, Jin, Lavaei, 2026）— arXiv:2610.01023
7. Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents（Barbaste, Darrigol, Vu, Wiltberger, 2026）— arXiv:2609.00006
8. SWE-chat: Coding Agent Interactions From Real Users in the Wild（Baumann, Padmakumar, Li, Yang, Koyejo, Stanford SALT-NLP, 2026）— arXiv:2604.20779
9. DORA 2025: State of AI-assisted Software Development（Google Cloud / DORA, 2025）— https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
10. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（Becker, Rush, Barnes, Rein, METR, 2025）— arXiv:2507.09089