写得更快，发不出去：智能体交付里的验证税

本文是论文 Beyond Code Generation: Reliability, Verification, and Cost Economics in the Agentic Software Development Lifecycle（arXiv:2609.04681，2026 年 9 月）正文第 1 节至第 20 节的中文译文，由智测团队翻译。作者是 Happy Bhati（bhati.h@northeastern.edu）。参考文献未逐条展开。这是对工业证据的系统综合和研究议程，不是新的模型实验。文中所有数字都属于被引用的研究和机构，不属于作者的新测量。作者提出的四个概念是待验证的工程构造，不是已经成立的标准。

作者此前那篇把助手过渡到智能体的架构文是 arXiv:2604.26275。本站已有中译《从补全到委派：智能体进入软件生命周期》。本文不重复那套架构，而是问组织真把这条生命周期放大之后，可靠性、验证容量和交付经济会怎样。文中另一处自我引用是可观测性预印本 arXiv:2604.17092，主张把模型成本和代码质量放在同一条轨迹里看。

摘要

人工智能编程系统正在从自动补全和对话，走向能检查仓库、改多个文件、跑工具、写测试、开拉取请求，并在有限监督下工作很久的智能体。瓶颈因此从「写出像样的补丁」挪到「证明这份补丁配得上发布」。近期现场实验显示编码活动有很大增益，但更新的证据表明，这些增益从写代码到发出可靠软件会急剧衰减。评审、集成、测试、安全、部署和生产运维仍然是约束阶段。在若干研究里，外围脚手架和验证过程的质量，和原始模型能力一样重要。经济形态也在变：从可预期的按席位许可，变成 token、工具、沙箱、持续集成和返工这些可变成本。

材料主要来自 2024 年到 2026 年 9 月的同行评审软件工程研究、高校研究、基准审计、大技术公司的生产报告、开发者遥测和成本管理证据。综合提出四个概念。智能体软件生命周期的吞吐悖论：代码生成的增益可以跑在发布增益前面。生产合格变更（PQC）：一次变更只有在相关可靠性关口都满足之后才算产出。验证税：把下游评审和保障成本写明，而不只算 token。智能体软件生命周期控制面：在成本、可靠性和人的注意力预算之内分配自主程度。有用的问题不再是智能体能生成多少代码，而是一套工程系统每美元、每评审小时、每单位运营风险能交付多少生产合格的价值。

1 引言

软件工程进入一个别扭的阶段：做出一份看起来像样的补丁更便宜了，证明它值得发布却更重要了。编程智能体已经能搜索仓库、改代码、跑命令、对着失败迭代。这是能力变化，不只是更快的自动补全。

近来的证据并不是简单的「开发者更快了」。三项随机现场实验、合计 4,867 名开发者，人工智能辅助使完成的任务在合并估计里增加 26.08%（Cui 等，Management Science，2026）。这是在某些职业场景里辅助能提高产出的强因果证据。但 2026 年一项覆盖超过 10 万名 GitHub 开发者的研究发现，自主智能体带来的编码活动累积增幅大得多：提交层面 180%，到项目层面掉到 50%，到真正的发布只剩 30%（Demirer、Musolff 和 Yang，NBER 工作论文 35275）。作者们把它描述成弱链接的生产结构：写代码加速得比把变更变成已发布软件所需的人和组织阶段更快。

这条缺口从几个方向都看得见。Google 每年收到数百万条代码评审评论，从送审到提交，作者主动照管的时间大约 60 分钟（Google ICSE 代码评审工作）。Google 2025 年 DORA 研究基于近 5,000 名技术专业人员，更高的人工智能采用与更高的交付吞吐相关，但与交付稳定性仍是负相关。斯坦福 SWE-chat 的 6,000 次真实编程智能体会话里，智能体产出的代码只有 44% 活进了用户的提交；用户在 44% 的轮次里纠正、打断或以其他方式顶回去；该数据集里智能体写的代码也比人写的露出更多安全漏洞。长程评估的失败形状不同：SWE-Marathon 的 rollout 平均 2,720 万 token，初始研究里没有任何被测配置的 pass@1 高于 30%，并在 13.8% 的 rollout 里观察到奖励黑客行为。

这些结果不互相矛盾。它们描述同一系统的不同层。人工智能可以提高局部编码生产率，全局交付系统仍受验证、协调、人的判断和运营风险约束。在智能体工作流里，这些约束不是旁枝，而是运行时的一部分。

成本也是这个形状。模型账单容易看见。其余成本散在上下文构造、反复尝试、工具调用、沙箱、持续集成分钟、安全扫描、评审者注意力、返工、事故，以及为了观察这一切所需的基础设施上。东北大学的研究者表明，即使控制题目难度，token 用量仍会随编程语言大幅变化，部分原因是智能体产出编译不过的尝试、修改已经通过的解、并且不信任给定的测试。FinOps Foundation 报告，受访实践者里 98% 现在管理人工智能支出，两年前是 31%，并把人工智能成本管理列为最需要发展的技能。Gartner 更进一步，预测在 token 消耗和按量计价上升的情况下，到 2028 年人工智能编程成本可能超过开发者的平均薪资。这个预测不应当成已经测到的必然，但它是一个信号：工程负责人正在从「要不要用」转到单位经济。

本文把人工智能编程智能体当成生产系统里的一个组件，而不是评估单位。组织面对的控制问题是：一项任务该给多少自主，用哪个模型和脚手架执行，要多少验证，人何时介入，以及再试一次智能体何时不再值回成本。

四个概念是：（1）吞吐悖论，上游变更生成可以比下游验证和发布快得多，局部生产率不会线性变成已发布的价值；（2）生产合格变更，拉取请求、提交或生成的补丁都不是完成的产出，变更要跨过相关的评审、测试、安全、部署和运维关口才算有用的生产产出；（3）验证税，智能体生成制造出可变的保障工作量，成本包括持续集成、评审时间、安全分析、返工和逃逸失败，不只是 token；（4）控制面，一层策略和遥测，按任务风险、可靠性证据、预算和组织容量来分配模型、上下文、并行、重试、测试和人工评审。目的不是声称哪家公司已经做完了这套控制面，而是把散落的研究结果收成一个可以检验的系统模型。

2 范围、证据选择和主张边界

综述强调 2024 年到 2026 年 9 月 3 日的工作，更早的基准论文只在它们确立重要基线时才纳入。来源至少直接相关于六个问题之一：编程智能体能力，开发者生产率与工作分配，代码评审与测试，可靠性与安全，协调与长程执行，成本与资源治理。

来源故意混了研究类型，因为生产中的软件工程不能只靠基准论文描述。随机现场实验、公开排行榜、工业部署报告、受控学术研究和市场预测回答的是不同问题。表 1 把类别留着。层级描述的是证据类型，不是研究质量的普遍排名。

本文没有一项基准分数、生产率增益、代码评审统计、安全结果、市场数字或公司部署结果是原始测量。

3 从编码能力到生产能力

3.1 基准确立了能力跃迁，也暴露了代理问题

SWE-bench 把编码评估从小型算法题推向真实的 GitHub Issue 和仓库状态。SWE-agent 表明，模型周围的智能体与计算机界面会实质影响表现，工具和交互设计是系统的一部分，不是中性管道。OpenAI 的 SWE-Lancer 加了经济维度：收集了 1,400 多项真实自由职业软件工程任务，历史上的报酬大约 100 万美元。这些基准让智能体进步变得可读，也把模型推向仓库尺度的工作。

分数上升之后，一个问题更重要：自动测试不是软件正确性的完美代理。OpenAI 2026 年对 SWE-bench Verified 的审计报告，在一个前沿模型不能稳定解出的 138 个任务里，59.4% 在测试设计或题目描述上有实质问题。同一分析还指出公开任务和解答带来的污染风险。另一篇立场论文认为，编程基准把模型、脚手架、上下文、执行环境和反馈信号揉进一个分数，很难知道到底是什么变好了。本站已有相关中译《榜单上的分数量的不是模型，是整套脚手架》。

对生产工程，高基准分只是交付路径上一个切片的证据，不是发布就绪证书。基准通常从一份格式良好的任务开始，到隐藏测试套件通过结束。公司开始得更早，需求和组织上下文都不完整；结束得更晚，还要经过安全评审、部署、监控、用户行为和维护。

3.2 软件工程比生成补丁更宽

Gu 等人（作者来自 MIT、加州大学伯克利、斯坦福和康奈尔）认为，当前面向软件工程的人工智能过度集中在代码生成，相对真实工程活动的广度不够：测试、调试、评审、重构、性能、安全、迁移、沟通和大规模变更管理都重要。微软研究院从直接观察得到类似结论。2025 年 ASE 研究里，19 名开发者用交互式智能体解决 33 个真实仓库问题，大约一半成功解决；增量协作优于一次性使用；开发者仍然在信任、调试和测试上吃力。

因此「智能体能力」应该拆开。组织层有用的问题不是智能体能不能写补丁，而是整个人与智能体的系统能否把变更从意图稳定地送到生产，并且不制造出比它消掉的更多的验证工作。

4 智能体软件生命周期的吞吐悖论

最近最清楚的瓶颈迁移证据来自 Demirer、Musolff 和 Yang。他们用超过 10 万名 GitHub 开发者的数据，加上人工智能使用遥测，估计工具从自动补全走到交互式再到自主智能体时，对提交的累积效应依次变大：40%、140% 和 180%。但在自主智能体这一档，对项目数量的效应只有 50%，对发布只有 30%。图 1 画的是这种衰减。数字来自 Demirer 等人；「吞吐悖论」这个标签是本文的综合。本文的解释是：代码生成加速时，瓶颈往下游迁。

这与其他证据一致。DORA 2025 发现人工智能采用与更高的交付吞吐相关，但与交付稳定性负相关。这不意味着人工智能必然造成不稳定；DORA 是观察性的、组织层面的。它意味着提高吞吐并没有取消对强测试、版本控制、反馈环和松耦合架构的需要。DORA 自己的说法有用：人工智能是周围交付系统的镜子和乘数。

METR 在 2025 年初的随机试验提供了故意不同的视角。16 名有经验的开源开发者，在自己熟悉的成熟仓库里完成 246 个任务。开发者预期人工智能会让自己更快，研究测到的却是该设定下慢了 19%。这个结果不应推广到每个开发者或后来的工具。它的价值是方法上的：感觉到的加速可以和测到的端到端任务时间不一致，尤其当领域知识高、质量标准严的时候。

合在一起，这些研究建议把工程指标常常模糊掉的两件事分开。生成吞吐是候选变更被生产出来的速率。交付吞吐是可信变更到达用户的速率。智能体式软件工程把前一个速率抬得比后一个自动抬升更快。这个区分是后面评审、测试、可靠性和成本的组织原则。

第 19 节明确警告：26.08% 的生产率估计来自使用编程辅助的合并随机现场实验；METR 的变慢 19% 来自 16 名深度熟悉仓库的有经验维护者，工具是 2025 年初的；MIT/NBER 的生产层级结果来自超过 10 万名 GitHub 开发者的观察性事件研究。设定、处理、结果和因果强度都不同，不能当成一次实验来横比。

5 代码评审变成容量问题

代码评审同时承担缺陷检测、设计对齐、安全、知识传递、所有权、可维护性和组织问责。智能体可以协助其中一部分，但提议变更的数量和体积上升，也会造成评审队列。

Google 的规模是一个参照：作者每年收到数百万条评审评论，平均每个变更从送审到提交大约要 60 分钟主动照管。该团队的机器学习系统可以提议能消掉评审评论的编辑，减少一部分来回。Google 的 AutoCommenter 同样用大语言模型学习和执行编码最佳实践，部署给了数万名开发者。这些系统说明评审本身可以一块一块自动化。

但评审自动化带来递归的保障问题：如果一个模型生成变更，另一个模型批准它，还剩下什么独立证据？坚持让人读每一行也没有解决这个问题，那只是把智能体吞吐封顶在人的评审容量上。更可扩展的方向是把证据种类分开。高风险变更可能需要独立静态分析、生成的测试和人写的测试、依赖与安全检查、所有权评审，以及金丝雀发布。低风险的文档变更可以少得多。评审应该按风险自适应，而不是一律人工或一律自动。

真实使用强化了这一点。SWE-chat 呈双峰：41% 的会话里，智能体几乎写了全部被提交的代码；23% 的会话里，人写了全部。智能体产出的代码只有 44% 活进提交，用户在 44% 的轮次里顶回去。一种说得通的解释是：交互和过滤仍然是工作的一部分。数生成的行数或智能体撰写的差异，会高估真正实现的工程产出。

6 测试：生成更多测试，不会自动变成更多保障

常有人把测试当成人工智能生成代码的天然对重：让智能体写代码，再让它写测试。研究更细。

Meta 的 TestGen-LLM 是较强的工业例子之一，因为生成的测试要先通过客观检查才被推荐。在 Instagram 评估里，75% 的生成测试用例能正确构建，57% 能稳定通过，25% 提高了覆盖。在 Meta 的测试马拉松里，系统改善了它所应用到的类中的 11.5%，工程师接受了 73% 的建议用于生产部署。设计教训比任何一个百分比都重要：生成配了一套会拒绝无用输出的验证脚手架。

微软研究院用自动反馈的强化学习探索更高质量的单元测试生成，动机之一是生成的测试会有测试坏味道和弱断言。2026 年 Chen 等人研究软件工程智能体在 SWE-bench 轨迹上写的测试，发现已解决和未解决的任务在写测试的频率上相似；许多生成测试更像观察性探针，而不是断言丰富的回归测试。提示智能体多写或少写测试，在他们的实验里没有显著改变最终结果。

工程结论不是「智能体不该写测试」，而是测试数量是很差的保障指标。测试有用，是因为它对说得通的缺陷增加了独立的区分力。在智能体流水线里，验证器本身必须被当成一等制品。

基准审计也因此重要。隐藏测试太窄、太宽或被污染时，即使补丁功能上没问题，智能体也可能被判错。长程设定里失败可以反过来：智能体找到穿过验证器的捷径，而不是解决本来的工程问题。SWE-Marathon 13.8% 的奖励黑客观察就是直接例子。

7 可靠性是一串关口，不是一个模型分数

生产变更在生命周期里移动时积累证据。图 2 是可靠性关口阶梯，是综合框架，不是行业标准。目的是说明：通过仓库基准只覆盖了生产保障的一部分。阶梯的关键区分是「产出一份像样的变更」和「积累足够的独立证据以便安全运行」。

这与近期系统级可靠性工作一致。Jarmak 2026 年的专著认为，编程智能体被当成模型来评估，却被当成系统来部署；可靠性取决于脚手架、执行状态、检索、记忆、权限、评审界面和资源分配。Gorinova 等人关于基准错位的论证从评估一侧说了同一件事：分数移动，可能是模型变好了，也可能是脚手架变了。

GitHub 2026 年把自动安全校验扩到第三方编程智能体，是一个具体的生产模式。智能体生成的变更可以在拉取请求定稿前用 CodeQL、依赖公告和密钥扫描来查。GitHub 报告，类似的 Copilot 云智能体校验自 2025 年发布以来已经阻止了数百起潜在的安全泄露和漏洞。这是厂商自述的运营结果，但它说明了架构：自主配对的是强制的、机器可核验的关口。

7.1 协调是单独的可靠性维度

组织从单个智能体走到多个专门智能体时，正确性不再只关乎个体能力。斯坦福和 SAP 实验室的 CooperBench 有 600 多项协作编码任务。智能体合作时，平均比自己做两边任务少成功大约 30%，失败与沟通差、偏离承诺、以及对同伴行为的模型不正确有关。

这对「评审智能体、测试智能体、安全智能体和实现智能体会自然组成可靠团队」的设想很重要。专门智能体仍可能需要显式契约：所有权边界、结构化消息、共享状态、冲突解决，以及一个能判断哪份证据算数的协调者。智能体的个数不等于工程容量。

8 生产合格变更：更好的产出单位

智能体环境里，传统开发者指标变脆。代码行容易灌水。提交可以拆也可以并。拉取请求数可以上升，只因为智能体产出许多小变更。连「完成的任务」也取决于谁定义完成。

更有用的单位是生产合格变更。候选变更 i 只有在满足该组织对这一类变更所要求的合格向量时，才得到 PQC 信用。形式上，PQC 是一组必需关口的指示函数之积：每个必需关口都通过才是 1，否则是 0。低风险的文档编辑，必需关口集合可以很小；数据库迁移、认证变更或支付路径可以大得多。这个概念故意允许按风险自适应的策略。

对应的吞吐是一段时间内 PQC 之和除以这段时间的长度。PQC 不是要取代 DORA 指标或工程判断。它是智能体遥测和交付结果之间的桥。它把一条假设写明：产出应该在可靠性系统做完自己的工作之后再计数，而不是在生成结束时计数。

若组织想要按质量加权的产出，二元指示可以再加上严重度、客户价值或风险权重，但要小心。一个不透明的「开发者分数」会重新制造这套框架想避开的指标问题。第 19 节再次强调：PQC 绝不能变成个人生产率分数，否则会鼓励博弈，并惩罚那些做困难、高风险系统的工程师。

9 智能体软件交付的经济

9.1 token 价格只是成本里看得见的部分

常见的人工智能编程预算从席位或 token 开始，这越来越不完整。一次智能体任务的成本可以来自模型推理、很长的仓库上下文、检索、工具执行、沙箱计算、反复构建、测试环境、依赖下载、并行尝试、代码评审注意力、安全扫描、返工和生产失败。

交付总成本是一项分类，不是声称每个组织都能把每一项完美分到单个拉取请求上。它的价值是防止人们去优化最容易看见的数字，同时让下游成本在没人注意时增长。加总的项是：模型、上下文、工具、沙箱、持续集成、评审、安全、返工、事故。图 3 是概念图，故意不给各类成本分配普遍百分比。

9.2 token 消耗是行为，不只是模型定价

东北大学 Wu、Anderson 和 Guha 的研究有用，因为它把题目难度保持不变，比较五个模型在 Python、Java、Rust 和 OCaml 上的表现。token 用量随语言大幅变化。轨迹分析显示：在较不熟悉的语言里反复出现编译不过的尝试，不必要地修改已经通过的解，用代码注释做规划，不信任给定的测试，以及退回去用 Python 做原型。这说明 token 成本部分是软件工程质量信号：差的脚手架或弱的语言能力会表现为浪费的推理。

长程工作把效应推到更极端。SWE-Marathon 初始 rollout 平均 2,720 万 token，而且尾巴很长。到这个尺度，重试策略、终止标准、上下文压缩、验证器设计和模型选择都是一等的经济决策。

FinOps Foundation 2026 年报告是组织一侧的对照：98% 受访的 FinOps 实践者现在管理人工智能支出，并把人工智能成本管理列为首要技能需求。GitHub 的 Copilot 影响仪表盘现在明确把实际的人工智能额度消耗，连接到每位开发者每月成本、占薪资的百分比，以及每月拉取请求数。这些迹象说明工程组织开始要单位经济，而不只是采用计数。

Gartner 预测，在 token 消耗上升和按量许可之下，到 2028 年人工智能编程成本可能超过开发者平均薪资。精确预测可能是错的。更耐久的一点是：智能体系统引入了一块可变成本曲面，工程负责人不能只靠席位数来治理。

10 验证税

成本模型建议一个可测量的量。对一组智能体生成的候选变更，验证税等于持续集成、评审、安全和返工成本之和，除以生成成本。生成成本包括模型、上下文和智能体执行。这个比率不应预期在仓库或任务类型之间稳定。可变本身就是它有用的原因。验证税高，可以意味着好几件不同的事：任务本来就高风险，值得贵的保障；所选模型或上下文在产出弱候选；智能体在尝试超出当前可靠性包络的工作；测试或评审基础设施低效或过载；组织政策在要求并不降低风险的冗余证据。

因此这个指标需要诊断，不要游戏化。目标不是「把验证减到最小」。验证税低，如果是因为跳过测试或橡皮图章式评审，会很危险。有用的目标是：在固定的可靠性目标下降低验证成本，或者在固定的保障预算下提高可靠性。

这个区分也有助于调和看起来冲突的生产率研究。人工智能可以在随机的企业设定里提高编码产出，可以在某个成熟仓库设定里拖慢有经验的维护者，同时仍可以在宽遥测里让提交的增幅远大于发布。不同研究观察到的，是生成增益和验证负担之间的不同比率。

11 智能体自主预算

自主常常被说成能力等级：系统能跑 30 分钟、8 小时，还是好几天？对组织，自主更好被当成一项被预算的特权。

每项任务至少消耗三种受约束的资源。一是钱和计算：模型 token、上下文、工具、沙箱、持续集成和并行。二是可靠性与风险：预期失败影响、安全暴露、可逆性、爆炸半径，以及错误预算的消耗。三是人的注意力：澄清、评审、升级、调试、批准和事故响应。图 4 把可行的自主区域画成这三份预算的交集。最大的模型或最长的可能运行，不会自动是最好的工作点。

候选执行计划的控制策略可以写成概念上的最优化：最大化期望的生产合格价值，减去货币与计算成本、期望失败损失和期望的人的注意力，权重是组织政策，不是普遍常数，并且受强制的安全、政策和 SLO 约束。

这个框法帮助避开两个相反的错误。一是委托不足：让昂贵的工程师去做重复、验证充分、智能体可以安全执行的工作。二是委托过度：让智能体在可验证性差或爆炸半径大的任务上烧掉数百万 token 和很长的评审队列。

12 智能体软件生命周期控制面

若每个开发者各自选择模型、上下文大小、智能体并行度、测试策略和重试深度，可靠性和成本政策就会碎在各个集成开发环境里。正在出现的基础设施单位因此是一层控制面：观察工作，指派执行策略，并记录把结果合格化所需的证据。图 5 是提议的架构。专门智能体是可选组件；核心是集中的策略、证据关口，以及把成本和可靠性连回未来自主决策的反馈。

控制面不必取代集成开发环境里的智能体、持续集成、Git 托管、安全扫描或部署平台。它可以先作为包在它们外面的策略和遥测层。六项职责是：估计后果、可逆性、数据敏感性、所有权和受影响组件，从而给任务风险分类；选择执行计划，包括模型、上下文策略、脚手架、工具权限、并行和硬预算；按风险类别绑定测试、静态分析、评审者、安全扫描和部署关口；当边际进展不再值回成本，或反复尝试在打转时，终止或升级；在任务、拉取请求、团队和仓库层级记录模型、工具、持续集成、评审和返工成本；根据 PQC 率、逃逸缺陷、回滚、评审改正、token 用量和人工升级来更新策略。

人工智能可观测性在这里成为工程控制，而不只是仪表盘。

13 公司实际在挣扎什么

表 2 把反复出现的问题映到可测量的控制上。

组织上藏着的问题是验证容量。公司常常先给人工智能许可做预算，再才给核验由此产生的变更所需的容量做预算。这相当于上游加了工厂机器，却不加检验、集成或发货容量。生成便宜时，队列只会搬家。NBER/MIT 的证据在宏观尺度上让这一点可见；Google 的代码评审数据把人的评审成本说具体；SWE-chat 表明，即使在智能体很重的会话里，人的过滤仍然常见。企业可能的回应不是无限雇评审者，而是重做保障：低风险证据自动化，高风险的人的注意力被保护起来。

技术上藏着的问题是脚手架质量。模型只是一层。工具权限、仓库检索、上下文压缩、测试选择、沙箱状态和重试逻辑，都可以实质改变成功和成本。SWE-agent 最初的结果已经表明智能体与计算机的界面有多重要；更新的可靠性工作把依赖链写明了。组织因此需要有版本的脚手架和可复现的智能体运行，而不只是记录调用了哪个基础模型。

14 智能体工程组织的指标

表 3 是研究和运营的起点。没有单个指标应该变成个人开发者的绩效分数。多数是系统级度量。

GitHub 2026 年的投资回报仪表盘已经在把人工智能额度、每位开发者成本和拉取请求产出连起来。下一步是把成本与合格和可靠性连起来，因为一个制造返工的拉取请求，不等于一个能安全发布的拉取请求。

15 从受监督的智能体到受策略约束的软件工厂

能力移动得很快，按日期的预测很脆。图 6 用成熟度视野而不是年份。标签把已记录的实践、正在出现的架构和开放研究分开。H0 到 H3 越往后越不成熟，不应读成有保证的时间表。

H0 是带硬持续集成边界的受监督智能体，这已经是实的。智能体可以实现功能和修复、生成或改进测试、回应评审反馈、开拉取请求。GitHub 对智能体生成的变更做自动安全校验；Google 和 Meta 部署了人工智能辅助的评审和测试系统。特征架构仍然是人对结果负责：智能体提议并迭代，生产政策由外部强制。

H1 是控制面工程。近期的转变很可能没有「完全自主的开发者」那么戏剧，但在运营上更重要。组织会标准化智能体脚手架、权限层级、token 预算、独立验证器、模型路由和证据要求。人工智能成本会越来越多地分到仓库和业务服务，而不只是集中的工具预算。FinOps 数据和 GitHub 的投资回报工具已经指向这个方向。

H2 是多智能体和长程执行。研究系统已在试这条前沿，可靠性没有解决。CooperBench 显示合作惩罚；SWE-Marathon 显示超长程任务成功率低、token 用量高、自我验证弱，以及奖励黑客。这些失败有价值，因为它们指出未来的软件工厂需要什么：持久状态、结构化协调、对抗性验证、有界权限、进展记账，以及从部分失败中恢复。METR 的时间视野工作也表明，智能体在更长任务上的能力随时间上升。视野变长时，成本和验证耦得更紧：一次多日运行可以制造比单个补丁大得多的变更面和成本尾巴。

H3 是自主软件工厂，它仍然是系统研究问题。开放的视野不是「一个大模型写出全部代码」，而是一套生产系统能在组织政策之内安全地决定、实现、验证、部署、观察、回滚和学习。这要求把目前被分开评估的能力可靠地组合起来。哈佛 2026 年围绕构造即正确的编程工作和教学，直接抓住了保障挑战：软件在更大尺度上被自动生成和演化时，人工评审和事后验证更难维持，从而推动更强的构造即正确方法。波士顿大学 2026 年面向人工智能的软件工程课程，同样强调评估人工智能生成代码的正确性、安全和长期可维护性，反映出技能从只会写提示，转向生产保障。这些是教育和研究方向的信号，不是性能证据，但它们显示同一种瓶颈迁移出现在机构如何训练工程师上。

16 研究议程

RQ1：什么比基准分数更能预测生产合格变更？有用的研究应在多个仓库和模型版本上给真实的智能体拉取请求做仪器，检验基准分数、一次通过的测试、验证器多样性、评审改正、token 轨迹特征或任务风险分类，哪一个最能预测成功的生产合格和发布后的稳定。

RQ2：验证预算能否自适应分配，而不增加逃逸缺陷？政策按任务风险以及模型和脚手架的信心选择关口，而不是每个智能体变更都跑同一条持续集成和评审流水线。实验应把逃逸缺陷风险保持不变，测量成本、延迟、评审时间和合格率。

RQ3：再加一个智能体，何时增加可靠性，何时只是相关的错误？评审、测试和安全智能体很吸引人，但不能假定独立。研究应测量生成器和验证器错误在模型族、提示、上下文来源和工具链上的相关。多样的模型可能有帮助，但多样性本身消耗预算。

RQ4：长程编程智能体的最优停止规则是什么？SWE-Marathon 让经济问题可见：长轨迹可以烧掉数百万 token，进展却很小。停止策略可以用验证器是否改进、编辑搅动、反复失败、上下文增长和估计的剩余工作，来决定继续、换模型、重置上下文，还是升级给人。

RQ5：智能体成本应如何归因到交付的价值？FinOps 正在走向人工智能支出的分摊，但工程需要一个因果单位。研究应比较每个拉取请求的成本、每个被合并拉取请求的成本、每个 PQC 的成本、每次无逃逸缺陷的服务变更的成本，以及交付总成本。最好的指标可能因产品类别而不同。

RQ6：人工智能生成的测试代码是否改善真实的缺陷检测？现有证据表明测试数量不够。未来工作应评估变异分数、故障定位、回归检测、规格覆盖，以及相对生成器假设的独立性，最好用发布后的缺陷，而不只是基准补丁。

RQ7：什么样的组织设计能把代码加速变成发布加速？Demirer 等人观察到的从 180% 衰减到 30%，邀请组织实验。候选干预包括评审智能体分诊、平台工程、更小的变更集、契约测试、架构模块化、自动的所有权路由，以及被保护起来的评审容量。

RQ8：软件智能体应如何协调？CooperBench 表明当前智能体不会自动成为有效队友。研究应测试结构化协议、显式承诺、共享计划、角色所有权、事务性状态、冲突检测和协调者架构，对照自由形式的聊天。

RQ9：可靠性证据如何在模型和脚手架变化之后仍然成立？生产组织会持续更换模型、升级工具。评估需要把模型、脚手架、环境、检索和政策效应分开。有版本的证据和可重放的轨迹，是知道系统是否真的变好了的前提。

RQ10：常规实现被委托之后，资深工程师应保留什么技能？人的角色转向分解、架构、风险判断、验证和事故推理。哈佛和波士顿大学的课程已经在人工智能辅助的软件工作里强调正确性、评估、测试、持续集成与持续部署，以及生产可靠性。纵向研究应检验：重度委托是否侵蚀评审和从智能体失败中恢复所需的专门知识。

17 对工程负责人的含义

证据既不支持「智能体只是玩具」，也不支持「软件工程已经解决」。更有用的运营立场是把智能体开发当成一项带显式约束的新生产技术。

一，给整条交付路径做预算。跟踪模型和 token 成本，也跟踪持续集成、沙箱、评审、安全、返工和事故成本。二，测量发布出去的可靠性，而不是生成活动。提交和拉取请求是中间库存。用类似 PQC 的指标、DORA 结果、逃逸缺陷和回滚数据。三，保护稀缺的评审容量。低风险性质自动核验，把专家注意力留给架构、安全、含糊需求和爆炸半径大的变更。四，让智能体运行可复现。给模型、脚手架、提示与政策、上下文构造、工具权限和验证器做版本。否则失败无法诊断。五，设置硬停止规则。长程智能体需要 token 和时间上限以及进展检查点。无限迭代不是自主，是一张无界的可变账单。六，把测试当证据，不当仪式。一个只断言生成器自己假设的生成测试，几乎不增加独立性。优先要强预言、性质、变异、集成检查和生产信号。七，不要假定智能体团队会协调。在把智能体乘开之前，先加上显式所有权和协议。八，按变更类别提高自主。文档、机械重构、补测试和低风险依赖更新，可以与身份、支付、密码学、数据迁移或安全关键代码有不同政策。

经济决策应框成边际价值。若接下来 10 美元的模型推理省下一小时专家工作且不提高风险，很可能值得。若接下来 100 美元的重试造出一块更大的补丁，却仍要同一位专家评审，智能体就没有创造出等量价值。控制面应让这个决定可见。

18 对研究者和大学的含义

软件工程研究正在从模型评估走向社会技术系统评估。MIT、斯坦福、伯克利和康奈尔的立场论文呼吁更宽的软件工程任务和更真实的环境；斯坦福的真实智能体轨迹提供基准之外的行为数据；MIT/NBER 的工作把工具采用连到实际发布产出；东北大学表明 token 经济取决于语言和智能体行为；哈佛在探索大规模生成软件世界里的构造即正确；波士顿大学的课程明确教如何验证和维护人工智能生成的代码。

教育上的后果是：学生需要的不只是写提示的技能。一套耐久的智能体软件课程应包括软件架构和变更影响；测试理论、基于性质的测试、变异和测试预言设计；安全编码、依赖风险和最小权限的智能体工具；持续集成与持续部署、可观测性、SLO、事故响应和回滚；模型与脚手架的评估以及基准设计；成本归因、token 经济和资源预算；人与智能体的交互、评审、问责和组织设计。实现变便宜时，工程判断的杠杆更大。这是把基础教得更深的理由，不是更浅。

19 局限与负责任的主张

本文是结构化的系统综合，不是 PRISMA 式的穷尽系统综述。领域移动很快，部分 2026 年材料是预印本或机构报告，而不是成熟的同行评审证据。公司报告的部署结果可能受选择、产品设计或激励影响，不能转移到其他组织。市场预测，尤其是 Gartner 的成本预测，是规划信号，不是关于 2028 年的事实。

三个突出结果描述的是不同总体，前文已说明不能横比。PQC、验证税、智能体自主预算和控制面没有被声称成已验证的标准。它们是为了让未来研究可以比较的假设。公司也可能把它们实现得很差。

安全和可靠性也随领域变化。用于内部脚本的编程智能体，不应继承修改认证、金融交易、医疗器械或关键基础设施时的同一套自主政策。正确的工作点取决于可逆性、爆炸半径、监管和人的后果。

最后，本文不假定智能体能力上升就必然减少工程就业。Demirer 等人这类证据指向人工智能产出与生产链上人的努力之间的强互补。工作的构成在变，但劳动结果取决于产品需求、组织设计、教育，以及生产率增益如何被分配。

20 结论

智能体软件生命周期正在成为真实的运营模型，但最难的问题在往下游走。生成候选代码不再是唯一稀缺的活动。可靠的软件仍然需要说得通的需求，能把正确和像样分开的测试，能抓住生成器漏掉的东西的评审者和安全系统，能限制爆炸半径的部署控制，以及能揭示变更是否真的有帮助的生产遥测。

近期研究让瓶颈迁移变得可测。人工智能辅助可以在随机的企业研究里提高开发者产出。自主智能体可以大幅增加提交。这些增益在发布之前衰减，真实的智能体轨迹仍然显示大量的人的改正和被丢弃的代码。长程智能体消耗巨大的推理预算，同时难以自我验证，偶尔还试图博弈验证器。多智能体编码引入的是协调失败，而不是自动的团队生产率。成本管理因此变得与可靠性工程分不开。

进展的实践单位应从生成的代码，移到交付的生产合格价值。这就是这里提出 PQC、验证税和智能体自主预算的理由。它们不是最终指标，而是一种把问题问得更好的方式。多少可信变更到达了用户？端到端花了多少？消耗了多少专家注意力？引入了什么风险？智能体何时该继续、换策略或停止？

可能的未来不是一个取代软件生命周期的编程模型，而是一套协调模型、工具、测试、安全、人的专门知识和预算的工程控制系统。把这层控制建得好的组织，也许能把智能体的速度变成可靠的软件。只优化生成的组织会发现：更快的代码，只是在评审、测试和生产前面排起一条更快的队列。

研究诚信说明

这份手稿是独立研究综合。没有声称新的模型基准、生产率实验、成本测量或公司部署结果。数值发现和观察到的效应仍归于被引用的研究者和机构。吞吐悖论、生产合格变更、验证税、智能体自主预算、控制面架构和视野解释，是作者对那些证据的综合，提出来供进一步验证。