郝旺、王瑞杰、叶哲、亚历克斯·顾、纳曼·贾因、刘晓源、斯瓦拉特·乔杜里、托马斯·齐默尔曼、苏米特·古尔瓦尼、阿曼多·索拉尔-莱萨马、伊恩·斯托伊卡、宋达恩
加州大学伯克利分校、CISPA、麻省理工学院、Cursor、得克萨斯大学奥斯汀分校、加州大学尔湾分校、微软
2026年7月26日
（完整立场论文：
迈向自主软件开发
在软件工程的大部分历史中，其组织方式始终围绕一种稀缺资源展开：能够编写和审查代码的人类。当前编程语言、框架、测试系统以及组织中的所有最佳实践，都是围绕这一约束条件构建的。这些实践的目的，是在管理有限的时间、注意力和认知能力的同时，帮助人们将需求转化为可靠的软件。
随着AI的出现，这一约束条件正在开始松动。
前沿编程智能体如今能够自主地在整个代码仓库中进行推理、编写并执行测试、识别漏洞，以及协调多阶段工作。在一项引人注目的演示中，一个由十六个并行Claude智能体组成的团队，以不到2万美元的成本构建了一个可运行的C语言编译器。然而，在那些旨在测试持续软件演进能力而非孤立任务的基准测试中，前沿智能体的表现仍会急剧下降：它们能够添加功能，但在连续变更中难以保持正确性和架构一致性。
这两种现实应当被放在一起考量。编程智能体已经变得足够强大，能够承担有意义的自主权，但尚未可靠到让我们将自主性视为一种单一的、无差别的能力。
因此，关键问题不再仅仅是“AI如何帮助开发者完成一个指定的任务？”，而是“在整个软件开发生命周期中，如何将责任从人类转移到AI？要实现这种转移的安全、可靠和可问责，必须具备哪些条件？”
软件自主性的共享词汇表
自动驾驶研究很早就认识到，如果没有一套共享的词汇表，一个领域就无法清晰地讨论安全性、能力和责任。SAE自动化等级使得区分驾驶辅助、条件自动化与完全自动化成为可能，并明确了在每个阶段谁仍然负有责任。
软件开发领域目前还没有类似的框架。“自主编码智能体”这个说法，现在既可以指代一个能建议几行代码的工具，也可以指一个能发起拉取请求的智能体，还能指一个能自行测试并部署修改的系统，甚至是一个能决定该开发哪些功能的智能体。这些是本质上截然不同的系统，它们各自有着根本不同的故障模式。
受自动驾驶 SAE 分级标准的启发，我们根据软件开发生命周期中哪些环节已从人类负责转变为完全由 AI 控制，提出并定义了三个级别的软件开发自主性。
我们的分级标准界定了 AI 系统在软件开发生命周期中掌握多少环节，以及哪些职责仍由人类承担。
第一级——代码自主
AI 完全负责系统设计与实现，无需人类逐行审批。智能体生成完整的拉取请求，包括设计依据、代码和文档。人类仍负责决定构建什么内容，以拉取请求为粒度审查提议的变更，监督测试与安全审计，并控制部署。我们认为当今的 AI 辅助编码是该级别的前身。
第二级——流程自主
AI 运行从设计与实现，到测试、审计和部署的整个流程。人类既不编写也不审查代码。他们只需提出高层次需求，并评估最终产出的行为。这是一个质的飞跃：它假设人类意图能够被足够完整的规格说明所捕获，并且自动化的验证与确认即使在没有人类检查中间产物的情况下也是可信的。目前，这两个假设在规模化场景下均不成立。
第三级——需求自主
AI 不仅构建、测试和部署软件，它还决定应该构建什么。它从遥测数据、用户行为、安全公告、依赖项变更以及系统自身的演进状态中识别需求。人类在持续开发循环中的最终角色消失了，尽管该系统仍受人类设定的创始使命约束。其核心挑战在于，确保 AI 自行生成的需求始终服务于该使命，而不是在不知不觉中重新定义它。
我们预计不同领域的组织会以不同速度推进这一自主性框架。高保障领域可能长期停留在第一级或以下，而内部工具和一次性应用可能更快接近第二级。该分类法是一种让能力声明、部署选择和问责制变得清晰可辨的方式。
自主性不止一个维度
三个自主等级回答了一个核心问题：AI 系统拥有软件开发生命周期的哪些阶段？但仅凭等级本身并不能完整描述系统的自主程度。两个处于同一等级的系统，可能因以下三个额外的交叉维度而运行方式截然不同：
- 规格粒度：一份附带复现测试的详细缺陷报告会约束智能体。而像“添加多租户功能”这样的请求则迫使其推断范围、架构、权衡和成功标准。薄弱的规格说明甚至可能将一个名义上等级较低的系统推向更高自主性所面临的挑战。
- 时间维度上的自主性：智能体可能以工单级别、冲刺级别、发布级别运行，也可能在数月或数年内持续运行。长周期运行会引入记忆、溯源、回归和架构一致性问题，这是单次评测基准无法捕捉的。
- 监督模式：人类的参与范围可以涵盖共同制定规格、操作级审批、拉取请求审查、策略护栏、仅监控模式以及自动回滚。合适的模式在很大程度上取决于领域风险和可逆性。
核心问题：保留人类意图
在所有三个等级中，有一个挑战以不同形式出现：随着人类直接控制的减弱，如何保留并忠实地执行人类意图。
在第一级，人类仍可通过审查来恢复意图。在第二级，意图必须编码到一份无人进行端到端验证的规格说明中。在第三级，AI 必须在系统多年演进的过程中自行综合并维护这份规格说明。
许多看似独立的失败，其实都是同一个问题的不同表现。规格漂移意味着实现过程逐渐偏离了人们的期望。奖励黑客意味着系统在满足某个可衡量的代理指标的同时，违反了其根本目标。多智能体分歧意味着不同的智能体基于互不兼容的解释采取行动，却没有将这种冲突暴露出来。一个编写测试的智能体可以产出一套实现代码和一套测试用例，它们彼此一致，但共同错误。
核心风险：当同一个智能体既编写实现代码又编写测试时，通过测试可能只证明了内部一致性，而非正确性。
这就是为什么更高的自主性会改变保证的对象。仅仅验证软件制品已经不够了。我们还需要审计生成该制品的智能体：它的规格、技能、记忆、决策溯源、通信协议以及执行轨迹。
已出现的错误实践：跳级
最直接的风险并非某种奇特的完全自主系统，而是组织进行跳级操作。
一个团队可能名义上处于第一级，人类仍对审查和部署负全责，但实际上却合并了无人真正审查过的智能体生成的变更。该团队采用了第二级的实践，却没有第二级的验证、治理或问责机制。当团队允许智能体根据遥测数据或外部内容发起变更，却没有保护好触发这些变更的渠道时，也会出现类似的压力。
因此，我们主张实行明确的等级关卡制度：只有当当前等级相关的挑战已被明确解决时，系统才能向前推进。举证责任应随着部署的自主性、持续时间和风险程度而提高。
六大结构性转变
如果实现变得充裕，软件开发并不会仅仅变成今天工作流程的加速版。它会经历更深层次的变革。软件工程的主要制品会改变。工程流程本身也会改变。最终，软件工程生态系统会重新组织。
我们预计在这三个层面上将发生六大结构性转变。
一、软件变得具有生成性
第一个转变发生在软件制品本身。人类意图日益取代具体实现，成为软件的持久化表征，而具体实现则变得更容易生成、修改和重新生成。
1. 规格说明成为主要的开发制品
随着人类与代码的直接交互减少，规格说明成为人类意图与机器执行之间的主要界面。它们不仅必须捕获功能需求，还必须涵盖安全约束、可维护性预期、架构不变性、产品惯例以及测试策略。
手动维护此类规格说明最终可能比维护从中衍生出的交互历史更为困难。因此，我们预期会出现规格说明蒸馏：人类通过对话、示例和反馈与智能体协作，而智能体则持续将这些交互编译为持久化、结构化的规格说明。随着时间的推移，规格说明可能与软件系统形成近乎一一对应的关系，使得仅凭规格说明即可重构具体实现。
2. 抽象边界变得可渗透
现代软件抽象层级——如函数、模块、库、API、框架和服务——的存在是为了适应人类认知的局限性。随着自主智能体获得跨更大范围软件堆栈进行推理的能力，这些抽象仍然是宝贵的组织工具，但它们不再是实现上的刚性约束。只要有助于改进整体系统，智能体可以常规性地重写、合并、拆分、内联或绕过这些抽象。
这并不意味着抽象会消失。相反，它们的角色从开发者必须在其内部工作的结构，转变为智能体可以适应和重组的灵活约定。随着时间的推移，软件共享可能从具体实现转向协议、行为规格说明、接口契约和参考实现，从而在保持互操作性的同时，赋予智能体更大的优化自由度。
3. 软件从静态制品转变为动态、持续演进的系统
自主开发不仅改变了软件的构建方式，也改变了软件本身的性质。软件系统不再是以离散版本发布的静态制品，而是可以成为神经符号系统——将确定性保障与神经网络的灵活性相结合；可以自我进化——持续根据运行信号进行适应；可以对话化——模糊了使用系统与修改系统之间的界限；也可以瞬时化——为单一任务生成，当重新生成比复用更经济时便被丢弃。
一个成熟的系统可能同时具备上述多种特性：在其安全关键核心上是确定性的，在其自适应边缘上是神经网络的，在生产环境中持续进化，并在其界面上实现对话化。
二、工程实践转向以智能体为中心
随着软件日益生成化，工程流程本身也必须演进。验证、协调和开发工作流不能再假设人类是软件的主要生产者。
4. 保障从制品转向智能体
即使满足相同的规格说明，AI 生成的实现也可能存在显著差异。这种多样性削弱了依赖熟悉编码模式或稳定实现的保障技术。更重要的是，自主智能体可能同时生成实现、测试、文档和设计原理，从而在原本旨在相互验证的所有制品中造成关联性失效。
独立的验证智能体只有在具备真正独立的目标、可信的评估机制以及解决分歧的原则性协议时才有帮助。因此，保障的范围从验证软件制品扩展到评估产生这些制品的自主智能体和开发流程。
5. 多智能体协调超越人类组织模式
当前大多数多智能体系统仍然模仿人类组织：管理者分配任务，专家执行任务，审查者检查输出，通信主要通过自然语言进行。这些结构反映的是人类的认知局限——注意力、通信带宽、记忆力和管理幅度——而非协作的基本要求。
自主智能体在不同的约束条件下运行。它们可以分叉和合并执行状态，共享完整的上下文，通过结构化协议进行协调，并扩展到数千甚至数百万个并发协作者。因此，我们预计将出现全新形式的 AI 原生协调，同时也会出现新的协调失败、安全风险以及责任归属问题。
三、软件工程生态系统重构
随着软件制品和工程工作流程的变化，周边的软件生态系统也必须随之演进。各类组织、机构、教育和市场都将适应这样一个世界：实现能力变得充裕，但值得信赖的自主性却愈发珍贵。
6. 软件工程生态系统重构
随着自主智能体承担更多的实现工作，软件开发组织将能够用更小的工程团队交付和维护日益复杂的系统。人类的贡献将转向产品定义、架构设计、规格说明、评估、安全、治理和事件响应。
与此同时，全新的生态系统机构也变得不可或缺。独立审计方、认证机构、可信度评估提供商以及治理服务，其重要性可能不亚于当今的测试平台或云服务提供商。软件工程教育也将更加侧重于规格说明、验证、安全、治理和系统级判断，而不仅仅是手工实现。
关于软件开发未来的十项预测
上述结构性转变暗示了一系列具体且可检验的预测。这些预测是前瞻性的，而非必然发生的。不同领域的发展速度会有所不同，但这些预测共同说明了自主软件开发在未来十年内可能如何重塑软件工程。
软件制品
1. 规格说明将成为软件的基因组
软件系统的持久化表示将越来越多地体现为其规约：即需求、约束、架构决策、测试策略和设计原理的持续演进记录。代码将成为该意图的一种编译实现，而非规范性的制品本身。
2. 重生成成为重构的实用替代方案
对于能够从其规约中忠实重建的软件而言，重新生成一份干净的实现，其成本可能低于逐步修复多年积累的复杂性。这一转变并非普遍适用。我们预计，那些包含大量未文档化知识或遗留集成的系统将继续以增量方式演进。但对于许多其他应用场景，重生成将从根本上改变维护的经济性。
3. 软件共享从实现转向协议
随着定制实现变得廉价，库、框架和 SaaS 平台将越来越多地作为行为标准、接口契约和参考实现，而非不可变的依赖项。自主智能体将在本地适配、优化或重新生成实现，同时保持对外可见的行为不变。
4. 动态软件成为常态
软件将越来越多地结合确定性保证与神经网络的灵活性、持续自适应、对话式界面以及按需生成。许多生产系统将不再拥有单一的规范实现，而是在保持稳定外部行为的同时持续演进。
工程实践
5. 规约提炼成为核心工程能力
开发者将不再预先编写完整的需求文档，而是越来越多地通过对话、示例、审查和修正来进行沟通。自主智能体将持续将这些交互提炼为结构化、可维护的规约，并随系统一同演进。
6. 保障从审查代码转向认证智能体
代码审查仍将重要，但保障工作的重点将日益转向生产软件的自主智能体。组织将审查智能体的规格说明、权限、记忆、执行轨迹、来源、评估结果和治理控制。信任生产过程变得与信任生产出的工件同等重要。
7. 原生AI协调结构取代人类启发的工作流程
当今的多智能体系统在很大程度上继承了人类的组织模式。随着时间的推移，智能体团队将发展出围绕机器能力而非人类管理约束设计的沟通、委派、共识和冲突解决机制，从而实现人类团队难以企及的大规模协作。
8. 项目上下文成为持久资产
随着具体实现的重新生成成本变得低廉，组织将越来越重视指导软件生成的持久项目上下文，而非任何特定的具体实现。规格说明、架构决策、工程惯例、约束条件、评估历史以及累积的反馈，其生命周期可能超越多代代码。以可移植、供应商中立的格式保存此项目上下文，对于跨模型、工具和平台保持连续性将变得至关重要。
组织与生态系统
9. 软件开发组织变得更小，治理更密集
偏重实现的工程团队可能会大幅缩减，而架构、规格说明、验证、安全、治理、合规及事件响应的重要性将相对提升。同时，新的生态系统机构，包括独立审计方、认证组织和保障服务提供商，将成为软件生命周期中日益重要的组成部分。
10. 软件变得充裕；信任变得稀缺
自主开发将大幅降低定制软件的生产成本，从而拓展可构建的内容以及参与构建的人群。与此同时，生成式软件的泛滥将使信任变得愈发稀缺。建立来源追溯、验证行为、认证自主智能体以及构建可信治理机制，可能成为软件生态系统中最具价值的核心能力。
研究议程，以及我们仍需走多远
这份路线图的目的并非宣告完全自主化时代已经到来，而是阐明在能够负责任地宣称达到更高自主水平之前，必须具备的能力与保障措施。
规约综合与行为理解
我们需要仓库级别的方法，来推断、生成并维护机器可检查的规约。基准测试应衡量规约在多个开发周期中是否与实现保持一致。目前，这种评估基础设施几乎不存在。
可信验证变得至关重要
随着软件开发日益自主化，智能体需要可信的方式来判定其输出是否真正满足预期的规约。形式化验证是最有前景的方法之一，但当前的技术在范围和可扩展性上仍然有限。验证大型、不断演进的软件系统从根本上来说依然困难重重。
安全、治理与问责
自主软件开发引发了涵盖安全、治理与问责等领域的根本性研究问题。新的攻击面来自不同方面，包括智能体记忆、工具、外部数据、多智能体协调以及自主执行，这需要针对安全架构、权限系统、监控、来源追溯和恢复提出新的方法。
在技术安全之外，该领域还必须为可信治理奠定基础。自主智能体应如何获得授权、接受监督、进行审计并承担责任？需要哪些证据才能建立信任？随着自主软件日益成为关键基础设施的重要组成部分，又需要哪些标准、认证流程和责任框架？
以智能体为中心的系统与语言设计
当今大部分软件栈是为人类编写、理解和维护代码而设计的。自主软件开发对这一假设提出了挑战。一个核心研究问题是：如何重新设计编程语言、开发环境、内存系统、溯源模型和协调协议，以构建智能体优先的软件工程，同时不牺牲人类的监督、可解释性或控制力。
人机交互界面与经济模型
随着自主智能体承担越来越多的软件开发流程，人类与智能体应如何协作这一根本性问题随之浮现。项目知识、设计意图、需求与约束应如何传达？人类如何在不成为瓶颈的前提下，有效理解、监督并引导日益自主的智能体？
我们还需要为自主软件开发建立新的经济模型。传统的生产力指标已不再足够；评估自主开发还必须考虑推理成本、人类监督、维护开销、技术债务、系统可靠性和运营风险。
研究优先级：我们最具体的呼吁是——构建仓库级别的规约-合成基准测试，以及针对规约-实现漂移的长周期评估。没有这些，任何关于达到二级或三级就绪状态的声明都无法得到证实。
当编写代码不再是瓶颈时会发生什么？
这一转变提出了任何基准测试都无法单独回答的问题：
- 当智能体完成大部分编码工作时，开发人员最具杠杆效应的工作是什么？
- 未经人工代码审查就发布的软件，是一种成熟的工程实践，还是一种我们尚不知如何衡量的风险？
- AI 智能体究竟是让软件创造变得大众化，还是将专业知识转移到了规范制定、评估、架构设计和治理层面？
- 当自主智能体部署的软件造成损害时，谁应当承担责任？
- 即使智能体在技术上能够做出某项决策，哪些决策仍应保留给人类？
我们并不认为软件开发的未来会是人类从流程中消失的简单故事。一种持久的人机协作伙伴关系仍然是可能的，而技术采纳也将是渐进且不均衡的。但发展的方向已经足够清晰，研究界应当开始将软件开发视为一条自主性不断提升的轨迹，而非一系列孤立的编码任务。
在智能体 AI 峰会上继续讨论
我们将在 8 月 1 日至 2 日于加州大学伯克利分校举行的智能体 AI 峰会的“软件工程的未来”环节中探讨这些问题。该环节将汇聚从事编码智能体、开发者工具、评估、安全以及智能体驱动软件开发新兴基础设施的研究人员和构建者。
该小组讨论不仅会探讨编码智能体已变得多么强大，还会探讨当实现不再是最主要的瓶颈时，该学科本身将如何改变，以及在自主性值得信赖之前，需要奠定哪些技术、组织和治理基础。
如需了解完整的框架、分类法和研究议程，请阅读立场论文：《迈向自主软件开发》。