软件工程的终结 (论文)

半个多世纪以来，软件工程一直建立在一个基本前提之上：人类工程师负责分解问题，把决策逻辑编码进静态代码，并在需求变化时手动调整这些代码。本文认为，AI Agent 的出现并不是一次渐进式改良，而是对软件范式的根本重构。这里的 AI Agent 指的是以大语言模型作为主要推理引擎，并把动态生成和丢弃代码当作工具资源的系统。

作者从复杂度扩展的第一性原理出发，区分了传统软件和 Agent 系统：传统软件里，代码是决策逻辑的载体；Agent 系统里，代码只是 LLM 推理循环中的临时工具。论文回顾了从授权软件到 SaaS，再到作者所说的 AaaS 的历史路径，指出每一次转变都把更多复杂度从最终用户身上转移出去。

论文进一步提出「Agent 工程」这个新兴学科：它在研究对象、控制模型和人的角色上，都不同于传统软件工程。作者通过 SWE-bench Verified、EvoClaw、LangChain 多 Agent 协同研究等基准证据，展示 Agent 范式的变革潜力和当前限制。最后，论文给出一条通向自演化 Agent 生态的四阶段路线图，并为正在经历这场转变的实践者提出建议。

论文原文：https://arxiv.org/pdf/2606.05608

1. 引言

软件工程作为一门学科，通常追溯到 1968 年 NATO 软件工程会议。当时的背景是一场危机：系统复杂度正在超出临时编程实践能够管理的范围。软件工程的创始洞察是，严格的方法论可以驯服这种复杂性，比如结构化设计、模块化分解、配置管理和系统化测试。

五十年来，这个赌注大体上是成功的。软件行业从瀑布模型走向敏捷，从单体架构走向微服务，从手工部署走向 CI/CD。

但更深层的结构性问题始终存在。Brooks 在《人月神话》中指出，软件复杂度的扩展方式和其他工程领域根本不同。桥梁和电路有制造环节，而软件没有；在软件中，设计本身就是产品。每一个新功能、每一个边界情况、每一个集成点，都会把系统推向可能状态和交互关系的组合爆炸。Brooks 将这种复杂度称为「本质复杂度」：它来自问题本身，而不是实现方式的偶然缺陷。

本文主张，AI Agent 的出现并不是在既有范式中增加了一个新工具，而是消解了软件工程成立时的那个根本前提。当一个大语言模型能够理解任务、分解子任务、动态生成代码执行这些子任务，并在不再需要时丢弃代码时，代码的角色就从「系统本身」变成了「推理过程中的临时工具」。这种变化的重要性，类似于从模拟电路转向存储程序计算机。

论文提出三个核心主张：

1. 第一性原理上的必然性。 Agent 范式不是市场偏好，而是复杂度扩展规律的必然结果。传统软件要求人类工程师显式编码每一个决策；基于 LLM 的 Agent 可以把推理外包给模型，而模型能力会随训练算力增长，从而以非线性方式处理复杂度。
2. 这是范式转移，不是优化。 从「AI → 软件 → 结果」转向「Agent → 结果」，意味着软件制品不再是必要中介。这类似于 SaaS 让本地安装不再成为必要中介。作者将其形式化为软件交付的第三次主要范式转移。
3. 一门新学科正在出现。 Agent 工程正在形成自己的概念、工具和指标。它的从业者不是「更好的程序员」，而是一种不同的角色：意图架构师、Agent 协调者和结果审计者。

后文结构如下：第二节从第一性原理分析传统软件和 Agent 系统，并提出形式化复杂度论证；第三节追溯软件交付的历史范式变化，并把 AaaS 放在逻辑终点的位置；第四节定义 Agent 工程，并与传统软件工程对比；第五节回顾近期基准研究中的经验证据，同时承认突破和持续存在的挑战；第六节提出演进路线图；第七节总结对实践者和研究社区的影响。

2. 第一性原理分析

2.1 传统软件的本质

作者先给出一个精确定义。

定义 2.1：传统软件系统。 一个传统软件系统 S 是三元组：

S = (C, D, E)

其中：

• C 是一组计算资源，包括 CPU、内存、I/O；
• D 是编码在源代码中的一组确定性决策规则；
• E 是执行环境，它根据输入对 D 求值并产生输出。

关键属性是：D 相对于执行过程是静态的。也就是说，所有决策逻辑都必须在人类工程师遇到任何输入之前被显式写出来。

在这个定义下，每一次功能增加、每一次 bug 修复、每一次对环境变化的适配，都要求人类完成四件事：理解需要改变什么，定位 D 中正确的位置，在不引入回归的前提下修改逻辑，并验证正确性。每次变更的成本，是 D 的规模和其内部依赖密度的函数。

2.2 复杂度壁垒

Brooks 区分了偶然复杂度和本质复杂度。偶然复杂度来自具体实现，比如语言、工具、框架的限制；本质复杂度来自问题本身。过去几十年里，高级语言、框架、自动化测试不断降低偶然复杂度，但本质复杂度没有上限。事实上，随着系统增长，组件之间的交互面会以组合方式扩张。

命题 2.1：复杂度扩展。 对一个包含 n 个组件的系统，如果每个组件都可能和其他组件交互，那么可能的交互路径数量 P(n) 会呈指数级增长：

P(n) ∈ Θ(2^n)

原因是，在 n 个组件之间，每一对组件都可能存在或不存在有意义的交互，从而形成大量可能的依赖图。现实系统不会实现所有配置，但复杂度上界呈指数增长；与此同时，人类用于推理这些交互关系的认知能力基本是常数。

这种错配，是软件项目在规模变大后边际生产率下降的深层结构原因。传统应对方式是层级分解、模块化接口和封装。这些方法可以降低常数因子，却不会改变渐近行为。

2.3 Agent 系统的形式化模型

相较之下，Agent 系统遵循完全不同的原则。

定义 2.2：AI Agent 系统。 一个 AI Agent 系统 A 是四元组：

A = (M, T, Mem, Π)

其中：

• M 是作为推理引擎的大语言模型；
• T 是一组可执行工具，包括代码解释器、API、数据库、文件系统；
• Mem 是记忆子系统，包括短期上下文和长期向量存储；
• Π 是规划机制，它把用户意图分解为行动序列。

系统以迭代方式运行：模型根据当前状态和记忆选择行动，执行行动后进入下一状态。关键差异在于，在 Agent 系统中，决策逻辑是在运行时生成的。LLM 可以动态生成代码、调用工具，并根据中间结果调整行为，这些都不需要提前逐项编程。

它生成的代码不是系统本身，而是临时产物：需要时生成，不需要时丢弃。

这种区别可以和 Karpathy 的「Software 2.0」框架对应起来，但又更进一步。在 Karpathy 的表述中，神经网络用学习得到的权重取代手写程序逻辑。Agent 系统更进一步：神经网络不只是取代程序，它会按需编写程序，把代码作为更大推理目标的工具。这个模式也和 ReAct 框架、Chain-of-Thought prompting 的结果一致：将推理轨迹和工具调用交织起来，显著提升任务表现；显式的中间推理步骤可以释放 LLM 的潜在能力。

2.4 为什么 Agent 必然更能扩展

设想一个任务 T，其解决方案需要在规模为 N 的空间中推理。

在传统范式下：

• 人类工程师必须在心智上遍历这个空间，识别解决路径；
• 该路径必须被编码成静态程序；
• 人类认知容量 C_H 基本固定；
• 因此，当 N > C_H 时，这个任务在现实成本下不可行。

在 Agent 范式下：

• LLM M 负责遍历空间，其有效容量 C_M 会随模型规模和训练算力扩展；
• 规划机制 Π 把任务 T 分解成子问题，每个子问题可独立处理；
• 代码只针对具体解决路径生成，而不是为所有可能情况提前编写；
• 随着 LLM 能力提升，C_M 也随之增长。

因此，Agent 范式把解决问题的能力从人类认知限制中解耦出来。这不是 10% 的改进，而是经济上可处理的问题类型发生了质变。

3. 从 SaaS 到 AaaS：第三次范式转移

3.1 软件交付的三代形态

商业软件的历史，可以被理解为复杂度逐步从最终用户身上转移出去的过程。

每一次转变都遵循同一个模式：最有能力吸收复杂度的一方吸收复杂度，最不适合管理复杂度的一方被解放出来。SaaS 让企业从机房中解放出来；AaaS 则承诺让企业不再需要指定结果应该如何产生，只需要指定想要什么结果。

3.2 「AI → 软件 → 结果」为什么会失败

到目前为止，企业 AI 的主流范式是 AI 增强开发：用 LLM 帮助人类工程师更快写代码，但仍处在传统软件生命周期里。作者将其称为「AI → 软件 → 结果」管线。这个模式有三个结构性弱点：

1. 瓶颈仍然存在。 人类工程师仍然是设计决策、架构、集成测试和部署的关键路径。AI 加速的是代码生成，而代码生成只是实现过程中的一个子步骤，并没有把人类从任何阶段移除。
2. 复杂度上限没有变化。 最终交付物仍然是传统软件系统 S = (C, D, E)。其复杂度仍然随 D 的规模增长，任何修改仍然需要人类理解。AI 只是让 D 的构建略快一些。
3. 迭代延迟仍然存在。 即使有 AI 辅助，任何功能变化仍然要经过需求、设计、代码、测试、部署这条完整链路。这个延迟无法低于人类沟通和协调的速度。

3.3 「Agent → 结果」：消除中介

替代范式是消除软件制品作为必要中介：

1. 人类向 Agent 表达意图和约束；
2. Agent 自主规划、执行、验证并交付结果，过程中可以按需生成代码；
3. 人类审计结果并给出反馈。

在这个模型中，交付的不是软件，而是结果。Agent 可能生成数千行代码、执行数据库查询、调用外部 API、产出可视化，但这些都是临时的。真正持久存在的是 Agent 的能力，而不是其中间产物。

Kumar 和 Ramagopal 对这个差异的概括是：AI coding agent 擅长在一次用户驱动的会话中把意图翻译成代码；Agent 工程则处在更高抽象层，它是一个控制平面，用来编排跨团队工作流，在多个 Agent 之间维护长期记忆，并管理整个软件交付生命周期中的状态与可追溯性。

4. Agent 工程：一门新学科

4.1 定义这个领域

LangChain 在 2026 年 4 月正式提出 Agent 工程，将其定义为一种多 Agent 协调模型：AI Agent 像数字团队成员一样工作，每个 Agent 有明确角色、共享记忆和统一可观测层，用于推动软件穿过整个交付管线，而不只是更快生成代码。

Wang 等人给出了软件工程中基于 LLM 的 Agent 分类法，识别了三个核心模块。Guo 等人则系统梳理了 LLM 多 Agent 系统中的协作模式和进展。

论文中的框架图可以概括为：

• 感知模块：处理多模态输入；
• 记忆模块：维护语义记忆、情节记忆和程序性知识；
• 行动模块：执行内部推理和外部工具调用；
• LLM 推理核心：编排上述模块并与外部环境交互。

Hermes Agent 是这种架构的一个具体实现。它是 Nous Research 的开源框架，把「感知-记忆-行动」模型落实为可运行系统，并加入了自演化机制。其最重要的特性是闭环学习：完成复杂任务后，Agent 会自主创建可复用的 Skills，也就是参数化的程序性模块；这些 Skills 会在后续使用中自我改进，当发现自己不足时自动修补。

跨会话的情节记忆通过 FTS5 会话搜索和 LLM 摘要实现，让 Agent 能够随时间积累经验知识。子 Agent 委派机制则展示了早期多 Agent 协调在生产系统中的形态。

4.2 Agent 工程与传统工程的对比

4.3 人类角色被重新想象

最重要的变化，可能是人类角色的变化。在传统范式中，人类价值取决于能否写出正确、高效的代码。在 Agent 范式中，代码生成能力会商品化。新的差异化能力包括：

• 意图表达。 能否足够清晰地指定目标和约束，让 Agent 可以自主工作而不产出意外结果。
• 架构监督。 从系统层面理解多个 Agent 应该如何协调、哪些记忆应该共享、哪些地方必须有人类判断介入。
• 质量校准。 定义什么是「好」，并构建 Agent 可用于自我修正的评估框架。
• 伦理治理。 确保 Agent 行为符合组织价值、法律要求和社会期望。

作者认为，对个体实践者而言，这种变化影响深远。随着 Agent 能力成熟，掌握 Agent 编排的人所获得的生产力倍增，将远超传统意义上的「10x 工程师」。这不是因为打字更快，而是因为他们能够协调一群 Agent 达成复杂结果。上限不再固定，而会随着模型能力和编排基础设施的提升而上升。

5. 经验证据与当前限制

5.1 突破性结果

作者列举了四类代表性证据。

SWE-bench Verified。 Ma 等人展示了 Lingma SWE-GPT 72B 的结果：这是一个开放的、以开发过程为中心的模型，在 SWE-bench Verified 上解决了 30.20% 的 GitHub issue，接近 GPT-4o 的 31.80%，同时完全开放。值得注意的是，7B 版本也解决了 18.20%，说明如果模型接受的是过程数据训练，而不只是静态代码训练，小模型也能完成有意义的自动化软件工程任务。相对于 Llama 3.1 405B，这代表 22.76% 的相对提升，而后者模型规模接近其 6 倍。

多 Agent 协调。 Kumar 和 Ramagopal 报告了一项试点研究：在 20 多个企业调试工作流中部署协同 Agent 群，根因定位时间减少了 93%，一个月节省超过 200 个工程小时。关键在于，这些收益不是来自单个 Agent 更强，而是来自编排能力：在多个 Agent 之间维护共享上下文、并行调查、交叉验证发现。

自我演化。 Hermes Agent 是 Nous Research 的开源框架，拥有大量 GitHub star，是生产系统中比较完整体现自演化原则的案例。它实现了一个闭环学习架构：完成复杂任务后，Agent 会自主创建可复用的 Skills，以捕获成功策略；这些 Skills 在使用中自我改进，当 Skill 被调用且被发现不足时，Agent 会自动修补它。这个「创建、使用、发现弱点、自我修补」的模式不需要人类介入，正是 Agent 系统区别于传统软件的自演化动态。

泛化能力。 Wang 等人整理了数百项研究，覆盖软件生命周期的各个环节：需求分析、架构设计、代码生成、测试、调试、部署和维护。覆盖范围表明，Agent 模式并不限于狭窄任务，而是能泛化到多种软件工程活动。

5.2 持续存在的挑战

尽管进展很快，挑战仍然显著。EvoClaw 基准提供了一个冷静的视角。Deng 等人构建了一个要求 Agent 执行连续软件演化的基准：不是孤立 issue 修复，而是在一系列 commit 历史中持续开发，每次变更都要保持系统完整性，错误还会累积。

他们的关键发现是：在孤立任务上高于 80% 的表现，一旦进入连续场景，整体分数最多下降到 38%。这暴露了 Agent 在长期维护和错误传播上的深层困难。

作者归纳出四个核心挑战：

1. 上下文漂移。 当代码库超过有效上下文窗口时，Agent 会失去对系统级不变量和依赖关系的一致理解。
2. 错误传播。 早期 commit 中的一个小错误，会在后续工作中级联成复合失败；Agent 缺少可靠机制去检测和恢复这些错误链。
3. 技术债意识。 当前 Agent 还不能建模设计决策的长期成本。它们倾向于优化即时任务完成，而不充分考虑可维护性。
4. 验证保真度。 自动化测试仍不完整；Agent 可能通过测试，却引入微妙的语义错误，这些错误只有在新输入下才暴露。

EvoClaw 展示的性能断崖可以概括为：

评估设置 成功率     孤立任务 约 82%   连续演化 最高约 38%

当任务从孤立问题变成跨 commit 的持续开发，并且错误会累积时，成功率下降约 54 个百分点。这个结果来自对 12 个前沿模型和 4 个 Agent 框架的评估。

5.3 差距分析

孤立任务表现高于 80%，连续演化表现低于 38%，这中间的差距量化了当前 Agent 能力和完全自动化软件工程门槛之间的距离。

作者强调，这个差距不是根本性的。它反映的是上下文管理、记忆架构和验证机制的限制，而这些都是活跃研究方向。但它提供了重要校准：作为增强范式，Agent 工程已经真实存在，并且有变革性；但要让完全自主的软件开发在生产环境中可靠运作，还需要数年集中研究。

6. 演进路线图

基于当前能力和发展趋势，作者提出 Agent 工程演进的四阶段路线图。

6.1 第一阶段：工具增强，2023-2025

这是当前主导模式。Agent 作为助手嵌入人类主导的工作流。突破主要发生在编码层面：对范围明确的任务，模型可以接近专家水平地生成、解释和调试代码。限制在于，人类仍然必须分解问题、设计架构并验证正确性。6

6.2 第二阶段：单任务自主，2025-2027

Agent 开始从规格说明到部署完整拥有一个任务。Devin 和 OpenHands 之类系统显示，Agent 可以自主浏览代码库、实现功能并提交 pull request。人类从「做事」转向「指定做什么并验证做成了什么」。

6.3 第三阶段：多 Agent 团队，2026-2029

专业化 Agent 像人类工程组织一样协同工作。「产品经理 Agent」把业务需求翻译成技术规格，「架构师 Agent」设计系统结构，「开发 Agent」实现组件，「QA Agent」测试和验证。共享记忆和可观测性成为关键基础设施。LangChain 的试点研究是这种模式的早期验证。

6.4 第四阶段：自演化生态，2028 以后

Agent 获得改进自身架构、为新问题领域派生专业子 Agent、并在没有人类干预时适应环境变化的能力。在这一阶段，「软件」和「Agent」之间的区别彻底消失：Agent 就是系统，并且持续演化。人类参与转移到元层治理：设定伦理边界、定义价值函数、确保对齐。

7. 影响与建议

7.1 给实践者

向 Agent 工程的转变要求有意识地重塑技能：

1. 从代码生产转向意图工程。 最有价值的技能不再是高效写代码，而是用足够清晰的上下文和约束表达任务，让 Agent 能正确执行。
2. 建立 Agent 编排能力。 能否把工作拆给多个 Agent、管理共享记忆、设计评估 rubrics，将区分有效实践者和普通使用者。
3. 投资可观测性基础设施。 Agent 系统需要和传统软件根本不同的监控方式。追踪 Agent 推理链、检测幻觉、衡量结果质量，都需要新工具。
4. 采用「人在回路中，Agent 在驾驶位」的姿态。 今天最有效的模型既不是完全自主，也不是完全由人驱动。Agent 应该负责执行，人类应该负责意图、关键判断和伦理监督。

7.2 给研究者

几个开放问题尤其紧迫：

1. 长上下文状态管理。 EvoClaw 说明，Agent 在长序列开发中会失去一致性。如何大规模压缩、索引和检索相关上下文，是关键问题。
2. 开放场景中的验证。 当前基准测试的是孤立正确性；真实系统要求安全性、可靠性和可维护性在时间维度上都有保证。需要能捕获这些时间维度的新验证框架。
3. 大规模 Agent 对齐。 当 Agent 更自主，并被组合成团队时，确保其集体行为与人类价值一致，会更重要也更困难。
4. 经济模型。 Agent 服务应该如何定价？按解决 issue、部署 feature 等结果付费，可能取代订阅和按使用量计费，但激励结构和风险分配需要仔细分析。

7.3 给组织

组织应该现在就开始为 Agent 转型做准备：

1. 识别适合 Agent 的工作流。 不是所有软件工作都同样适合 Agent 自动化。成功标准清晰、范围定义明确、已有测试基础设施的任务，是理想起点。
2. 投资评估框架。 Agent 输出质量高度依赖评估信号质量。组织应该构建不只衡量正确性，也衡量鲁棒性、可维护性和业务意图对齐的测试套件。
3. 重新设计团队结构。 当个人生产力通过 Agent 杠杆倍增时，团队拓扑也必须演化。更小的「Agent 编排者」团队，可能替代更大的开发团队，相应地，招聘、晋升和职业发展也会变化。

8. 结论

本文主张，AI Agent 的出现构成的是软件范式转移，而不是工具升级。从「AI → 软件 → 结果」到「Agent → 结果」的转变，消除了静态软件制品作为必要中介的地位，就像 SaaS 曾经消除了本地安装，云曾经消除了物理基础设施。

这一转变建立在第一性原理上。传统软件要求人类工程师显式编码所有决策逻辑；这个任务的复杂度随系统规模指数增长，而人类能力保持固定。Agent 系统把决策外包给能力随训练算力扩展的 LLM，把解决能力从人类认知限制中解耦出来。这改变了哪些软件问题在经济上可以被处理。

但作者也承认，我们仍处在早期阶段。EvoClaw 这类基准揭示了孤立任务表现和持续自主开发之间的巨大差距。当前需要的是雄心勃勃但有校准的投入：把 Agent 工程作为增强范式的主导方向拥抱，同时承认完全自主的软件工程仍然是一个需要多年研究的挑战。

Agent 工程正在作为一门独立学科出现，拥有自己的概念、工具和职业身份。它的从业者不会只是学会了新工具的程序员，而会是一类新的专业人士：他们是意图架构师，负责指挥 AI Agent 群达成复杂结果。旧的软件工程正在结束，新的软件工程已经开始。

原文链接：软件工程的终结：AI Agent 如何从根本上重构软件范式（译）

汇智网编辑整理，转载请标明出处