王浩、孟瑞杰、叶喆、Alex Gu、Naman Jain、刘晓源、Swarat Chaudhuri、Thomas Zimmermann、Sumit Gulwani、Armando Solar-Lezama、Ion Stoica、宋达

加州大学伯克利分校、CISPA、麻省理工学院、Cursor、得克萨斯大学奥斯汀分校、加州大学尔湾分校、微软

2026年7月26日

（完整立场论文：

迈向自主软件开发

在软件工程的大部分历史中，其组织方式始终围绕一种稀缺资源展开：能够编写和审查代码的人。当前编程语言、框架、测试系统和组织中的所有最佳实践，都是围绕这一约束条件构建的。这些实践的目的，是在管理有限的时间、注意力和认知能力的同时，帮助人们将需求转化为可靠的软件。

随着 AI 的出现，这一约束条件正在开始松动。

前沿编程智能体现在能够自主地在整个代码库中进行推理、编写并执行测试、识别漏洞，以及协调多阶段工作。一个引人注目的演示中，由十六个并行运行的 Claude 智能体组成的团队，以不到 2 万美元的成本构建了一个可用的 C 编译器。然而，在那些旨在测试持续软件演进而非孤立任务的基准上，前沿智能体仍然急剧退化：它们能够添加功能，但在连续变更中难以保持正确性和架构一致性。

这两个现实应当放在一起考量。编程智能体的能力已经足以承担有意义的职责，但还不足以让我们把自主性视为一种单一的、无差别的能力。

因此，关键问题不再仅仅是“AI 如何帮助开发者完成一个明确的任务？”，而是“在整个软件开发生命周期中，责任如何从人类转移到 AI？这种转移要安全、可靠、可问责，需要满足哪些条件？”

软件自主性的共享词汇表

自动驾驶研究很早就认识到，一个领域如果没有共享的词汇表，就无法清晰地讨论安全性、能力和责任问题。SAE 自动化分级使得区分驾驶辅助、条件自动化与完全自动化成为可能，并明确了在每个阶段谁仍然承担责任。

软件开发领域没有类似的框架。“自主编码智能体”目前既可以指一个能建议几行代码的工具，也可以指一个能发起拉取请求的智能体，还可以指一个能自行测试并部署自身改动的系统，甚至指一个能决定该构建哪些功能的智能体。这些是本质上不同的系统，其失败模式也根本不同。

受 SAE 自动驾驶分级标准的启发，我们根据软件开发生命周期中哪些阶段已从人类职责转变为完全由 AI 控制，提出并定义了软件开发自主性的三个级别。

我们的分级标准界定了 AI 系统拥有软件开发生命周期中多大范围的所有权，以及哪些职责仍由人类承担。

第一级——代码自主

AI 完全接管系统设计与实现，无需人类逐行审批。智能体产出一个完整的拉取请求，包括设计依据、代码和文档。人类仍决定要构建什么，在拉取请求粒度上审查拟议的变更，监督测试与安全审计，并掌控部署环节。我们认为当今的 AI 辅助编程是迈向这一级别的先导阶段。

第二级——流水线自主

AI 运行从设计、实现到测试、审计和部署的完整流水线。人类既不编写也不审查代码。他们提出高层级需求，并评估最终产生的行为。这是一个质变：它假定人类意图可以被捕获到足够完整的规格说明中，并且自动化的验证与校验可以被信任，即使没有任何人检查中间产物。目前这两项假设在大规模场景下都不成立。

第三级——需求自主

AI 不仅构建、测试和部署软件，还决定应该构建什么。它从遥测数据、用户行为、安全公告、依赖变更以及系统自身的演化状态中识别需求。人类在周期性开发循环中的最终角色消失了，尽管系统仍受制于由人类确立的创始使命。核心挑战变成确保自主生成的需求持续服务于该使命，而不是悄然重新定义它。

我们预计，不同领域的组织将以不同速度推进这一自主性框架。高保障性领域可能在较长时间内停留在 Level I 或以下，而内部工具和一次性应用可能更快接近 Level II。该分类体系旨在让能力声明、部署选择和问责机制变得清晰可辨。

人们很容易认为，使用最新模型时我们已经深入 Level I 或 Level II 自主性，但这些级别旨在达成稳定一致的能力，而非今天那种虽有功能但错误频发、且没有正式正确性保证的输出。

自主性不止一个维度

三个自主性级别回答了一个核心问题：AI 系统拥有软件开发生命周期的哪些阶段？但级别本身并不能完全刻画系统的自主程度。处于同一级别的两个系统，可能因三个额外的跨切面维度而运行方式截然不同：

• 规格粒度：一份附带复现测试的详细 bug 报告会约束智能体的行为。而像“添加多租户支持”这样的请求则迫使其推断范围、架构、权衡和成功标准。薄弱的规格说明甚至可能将名义上更低级别的系统推向更高自主性的挑战。
• 时间维度上的自主性：智能体可能以工单级别、迭代级别、发布级别运行，或持续运行数月乃至数年。长周期运行会引入记忆、来源追溯、回归和架构一致性问题，而这些是单次评测基准无法捕捉的。
• 监督模式：人工参与的范围可以从共同制定规格和操作级审批，到拉取请求审查、策略护栏、仅监控运行以及自动回滚。合适的模式在很大程度上取决于领域风险和可逆性。

统一的核心问题：守护人类意图

在全部三个级别中，一个挑战以不同形式反复出现：随着直接人工控制的退场，如何守护并忠实执行人类意图。

在 Level I，人类仍可通过审查来还原意图。在 Level II，意图必须被编码进一份没有任何人进行端到端核验的规范中。在 Level III，AI 必须自行综合并维护这份规范，而系统将在多年间持续演进。

许多看似彼此独立的故障，其实都是同一个问题的不同表现。规范漂移意味着实现逐渐偏离了人们真正想要的东西。奖励黑客意味着系统满足了一个可度量的代理指标，却违背了底层目标。多智能体分歧意味着不同智能体基于互不兼容的解释行事，却未将冲突浮出水面。一个测试编写智能体可以产出一份实现和一套测试套件，二者彼此自洽，但合在一起却是错的。

核心风险：当同一个智能体既编写实现又编写测试时，测试通过可能只能证明一致性，而非正确性。

正因如此，更高的自主性改变了保证（assurance）的对象。仅验证软件产物已不再足够。我们还需要审计产出该产物的智能体本身：它的规范、技能、记忆、决策溯源、通信协议以及执行轨迹。

已在浮现的错误实践：跳级（Level-Skipping）

最直接的风险并不是某种新奇的完全自主系统，而是各类组织跳过等级。

一个团队可能在名义上按 Level I 运作，由人类对审查和部署负全责，但实际操作中却合并了没有任何人真正审查过的智能体生成改动。该团队采用了 Level II 的实践，却没有 Level II 的核验、治理或问责机制。当团队允许智能体基于遥测数据或外部内容发起变更，却没有保护好触发这些变更的渠道时，类似的压力也会出现。

因此，我们主张明确的等级门控（level gating）：只有当当前等级所对应的挑战已被切实解决时，系统才能向前推进。举证责任应随部署的自主性、持续时间和风险程度而提升。

六个结构性转变

当实现变得唾手可得时，软件开发并不会简单地变成今天工作流程的加速版。它会经历更深层次的变革。软件工程的主要产物会改变。工程流程本身也会改变。最终，软件工程生态系统会重新组织。

我们预计，在这三个层面上将发生六种结构性转变。

一、软件变得具有生成性

第一个转变发生在软件产物本身。人类意图日益取代实现，成为软件的持久表征，而实现则变得更容易生成、修改和重新生成。

1. 规格说明成为主要开发产物

随着人类与代码的直接交互减少，规格说明成为人类意图与机器执行之间的主导接口。它们不仅必须捕获功能需求，还必须涵盖安全约束、可维护性预期、架构不变量、产品惯例和测试策略。

手动维护此类规格说明，最终可能比维护催生它们的交互历史更加困难。因此，我们预计会出现规格说明蒸馏：人类通过与智能体对话、提供示例和反馈来协作，而智能体则持续将这些交互编译为持久、结构化的规格说明。随着时间推移，规格说明可能与软件系统趋近于近乎一一对应的关系，使得仅凭规格说明即可重建实现。

2. 抽象边界变得可渗透

现代软件抽象栈，如函数、模块、库、API、框架和服务，是为了适应人类认知极限而存在的。随着自主智能体获得跨更大范围软件栈进行推理的能力，这些抽象仍然是宝贵的组织工具，但它们不再是实现的刚性约束。只要有助于改善整体系统，智能体就可以常规性地重写、合并、拆分、内联或绕过抽象。

这并不意味着抽象会消失。相反，它们的角色从开发者必须在其内部工作的结构，转变为智能体可以适应和重新组织的灵活约定。随着时间推移，软件共享可能从实现本身演进为协议、行为规范、接口契约和参考实现，赋予智能体更大的优化自由度，同时保持互操作性。

3. 软件从静态制品转变为动态、持续演进的系统

自主开发不仅改变了软件的构建方式，也改变了软件本身是什么。软件系统不再是按离散版本发布的静态制品，而可以成为神经符号系统——将确定性保证与神经灵活性相结合；可以自我进化——持续适应运行信号；可以对话化——模糊使用系统与修改系统之间的界限；也可以瞬时化——为单一任务生成，当重新生成比复用更便宜时便被丢弃。

一个成熟的系统可能同时具备上述多种特性：在其安全关键核心处是确定性的，在其自适应边缘是神经性的，在生产环境中持续演进，并在其界面上是对话式的。

二、工程转向以智能体为中心

随着软件变得越来越具有生成性，工程流程本身也必须演进。验证、协调和开发工作流不能再假设人类是软件的主要生产者。

4. 保障从制品转向智能体

AI 生成的实现即使满足相同的规范，也可能存在显著差异。这种多样性削弱了依赖熟悉编码模式或稳定实现的保障技术。更重要的是，自主智能体可能同时生成实现、测试、文档和设计依据，从而在原本旨在相互验证的所有制品中产生关联性故障。

独立的验证智能体只有在以真正独立的目标、可信的评估机制以及解决分歧的原则性协议运行时，才能发挥作用。因此，保障的范围从验证软件工件，扩展到评估生成这些工件的自主智能体及其开发流程。

5. 多智能体协作超越人类组织形态

当前大多数多智能体系统仍类似于人类组织：管理者分派工作，专家执行任务，审查者检查产出，沟通主要通过自然语言进行。这些结构反映的是人类的认知局限——注意力、沟通带宽、记忆和管理幅度——而非协作的根本性要求。

自主智能体在不同的约束条件下运行。它们可以分叉和合并执行状态，共享完整上下文，通过结构化协议进行协调，并扩展到数千甚至数百万个并发协作者。因此，我们预计会出现根本性新型的 AI 原生协调形态，同时也会带来新的协调失败、安全风险以及问责问题。

三、软件工程生态系统的重构

随着软件工件和工程工作流程的变化，周边的软件生态系统也必须随之演进。组织、机构、教育和市场都在适应这样一个世界：实现能力变得充裕，而可信的自主性则日益珍贵。

6. 软件工程生态系统重构

随着自主智能体承担更多实现工作，软件开发组织将能够以更小的工程团队交付和维护日益复杂的系统。人类的贡献转向产品定义、架构、规格说明、评估、安全、治理和事件响应。

与此同时，全新的生态系统机构变得不可或缺。独立审计机构、认证组织、可信度评估服务商以及治理服务，其重要性可能不亚于当今的测试平台或云服务商。软件工程教育也将更加注重规格说明、验证、安全、治理和系统级判断，而不再仅仅强调手工实现。

关于软件开发未来的十大预测

上述结构性转变预示着一系列具体且可检验的预测。这些预测刻意面向未来，而非必然发生。不同领域的发展速度会有所差异，但综合来看，这些预测展示了自主软件开发在未来十年可能如何重塑软件工程。

软件制品

1. 规格说明成为软件的基因组

软件系统的持久化表征将越来越多地体现为其规格说明：即需求、约束、架构决策、测试策略和设计理由的持续演进记录。代码则成为该意图的一种编译实现，而非权威制品本身。

2. 重新生成成为重构的实用替代方案

对于能够根据其规格说明忠实重建的软件，重新生成一份干净实现可能比逐年修补累积的复杂性更为经济。这一转变并非普遍适用。我们预计，那些包含大量未记录知识或遗留系统集成的软件将继续以增量方式演进。而对许多其他应用而言，重新生成将从根本改变维护的经济性。

3. 软件共享从实现转向协议

随着定制实现变得廉价，库、框架和 SaaS 平台将越来越多地充当行为标准、接口契约和参考实现，而非不可变依赖。自主智能体将在本地适配、优化或重新生成实现，同时保持对外可见的行为不变。

4. 动态软件成为常态

软件将日益把确定性保证与神经网络的灵活性、持续适应能力、对话式界面以及按需生成结合起来。许多生产系统将不再只有一个标准实现，而是会在保持外部行为稳定的同时持续演进。

工程实践

5. 规格蒸馏成为核心工程能力

开发者将不再预先编写完整的需求文档，而是越来越多地通过对话、示例、评审和纠错来进行沟通。自主智能体将不断把这些交互蒸馏为结构化、可维护的规格说明，并随系统一同演进。

6. 保障重点从审查代码转向认证智能体

代码审查仍将重要，但保障工作将日益聚焦于生产软件的自主智能体。组织将检查智能体的规格、权限、记忆、执行轨迹、来源、评估结果和治理控制。信任生产过程与信任生产出的产物同样重要。

7. AI 原生的协作结构取代模仿人类的工作流

当今的多智能体系统大多沿袭了人类组织模式。随着时间推移，智能体团队将发展出围绕机器能力而非人类管理约束来设计的沟通、委派、共识和冲突解决机制，从而实现在人类团队中不切实际的大规模协作。

8. 项目上下文成为持久资产

随着实现的重生成成本变得低廉，组织将日益重视那些引导软件生成的持久项目上下文，而非任何特定实现。规格说明、架构决策、工程约定、约束、评估历史和累积反馈可能比多代代码更长寿。以可移植、厂商中立的形式保存这些项目上下文，将成为跨模型、跨工具、跨平台保持连续性的关键。

组织与生态

9. 软件开发组织变得更小、治理更密集

以工程实现为主的团队规模可能会大幅缩减，而架构、规格说明、验证、安全、治理、合规以及事件响应等环节的相对重要性将不断提升。与此同时，新的生态机构——包括独立审计方、认证组织和保障服务提供方——将成为软件生命周期中日益重要的组成部分。

10. 软件变得充裕，信任变得稀缺

自主开发将大幅降低定制软件的生产成本，从而扩大可构建软件的范围以及可参与构建的人群。与此同时，生成式软件的泛滥将使信任变得越来越稀缺。建立来源追溯、验证行为、认证自主智能体以及构建可信治理机制，可能成为软件生态中最具价值的能力。

研究议程，以及我们仍需走多远

这份路线图的目的并非宣告完全自主的时代已经到来，而是阐明在更高等级的能力可以被负责任地宣称之前，必须具备哪些能力和保障措施。

规格综合与行为理解

我们需要仓库级规模的方法，用于推断、生成并维护机器可检查的规格说明。评测基准应衡量规格说明在多个开发周期中是否始终与实现保持一致。而今天，这类评测基础设施几乎还不存在。

可信验证变得至关重要

随着软件开发日益走向自主化，智能体需要可信的方式来判定其输出是否真正满足预期的规格说明。形式化验证是最有前景的路径之一，但当前的技术在覆盖范围和可扩展性上仍然十分有限。验证大型且不断演进的软件系统，从根本上说仍然十分困难。

安全、治理与问责

自主软件开发引发了横跨安全、治理与问责等领域的根本性研究问题。新的攻击面来自多个不同方面，包括智能体记忆、工具、外部数据、多智能体协作以及自主执行，这要求我们在安全架构、权限系统、监控、溯源和恢复等方面探索新的方法。

在技术安全之外，该领域还必须为可信治理奠定基础。自主智能体应如何被授权、监督、审计和问责？什么样的证据足以建立信任？随着自主软件日益成为关键基础设施的重要组成部分，我们需要什么样的标准、认证流程和责任框架？

以智能体为中心的系统与语言设计

当今的许多软件栈都是为人类编写、理解和维护代码而设计的。自主软件开发对这一假设提出了挑战。一个核心研究问题是：如何重新设计编程语言、开发环境、记忆系统、溯源模型和协作协议，以支持智能体优先的软件工程，同时不牺牲人类的监督、可解释性或控制力。

人机交互界面与经济模型

随着自主智能体承担越来越多的软件开发流程，关于人类与智能体应如何协作的根本性问题随之浮现。项目知识、设计意图、需求和约束应如何传达？人类如何在不成为瓶颈的前提下，有效地理解、监督和引导日益自主的智能体？

我们还需要为自主软件开发建立新的经济模型。传统的生产力指标已不再足够；评估自主开发还必须考虑推理成本、人工监督、维护开销、技术债务、系统可靠性和运营风险。

研究优先事项：我们最具体的呼吁是：构建仓库规模的规格合成基准，以及对规格与实现漂移的长期评估。没有这些，关于二级或三级就绪状态的声称就无法得到证实。

当编写代码不再是瓶颈时，会发生什么？

这一转变引发了一些没有任何基准测试能独立回答的问题：

• 当智能体完成大部分编码工作时，开发者的最高杠杆工作会变成什么？
• 未经人工代码审查就发布的软件，是一种成熟的工程实践，还是一种我们尚不知道如何衡量的风险？
• 智能体是在让软件创作民主化，还是将专业知识转移到规范制定、评估、架构和治理之中？
• 当自主智能体部署了造成损害的软件时，谁该负责？
• 即使智能体在技术上能够做出某些决策，哪些决策仍应保留给人类？

我们并不认为软件开发的未来是一个人类从流程中消失的简单故事。持久的人机协作仍然是有可能的，而且采用过程将是渐进且不均衡的。但发展方向已经足够清晰，研究界应当开始将软件开发视为一条自主性不断提升的轨迹来研究，而不是一堆孤立的编码任务。

在智能体 AI 峰会上继续讨论

我们将在 8 月 1 日至 2 日于加州大学伯克利分校举办的智能体 AI 峰会的“软件工程未来”分论坛上探讨这些问题。该分论坛将汇聚从事编码智能体、开发者工具、评估、安全以及智能体驱动软件开发新兴基础设施的研究人员和构建者。

该小组将不仅讨论编码智能体已经变得多么强大，还将讨论当实现不再是主导瓶颈时，这门学科本身如何发生变化，以及在自主性可以被信任之前，需要什么样的技术、组织和治理基础。

如需完整的框架、分类法和研究议程，请阅读立场论文：《迈向自主软件开发》。