How AI Agents Are Restructuring the Software Paradigm
- 关联论文：2606.05608
- 作者：Tom
- 更新：2026-07-20
一句话结论
本文从软件工程学科视角，论证 AI Agent 的出现是对"软件"本身的根本性重构——从"代码是决策逻辑的载体"到"Agent 本身就是软件，决策逻辑在运行时生成"，并提出 Agentic Engineering 作为扩展软件工程学科的新范式。
解决什么真问题
过去半个世纪，软件工程建立在同一套基础假设上：人类工程师分解问题 → 将决策逻辑编码为静态代码 → 随需求变化手动维护代码。本文认为这个范式正在被动摇，但不是以"更好的 IDE"或"更强的 Copilot"这类渐进式改进的方式——而是以根本性重构的方式。
作者要回答的核心问题是：AI Agent 的出现，究竟是软件工程的进化，还是软件工程本身的终结？
核心方法
本文是一篇立场论文（Position Paper），不是实验论文。方法论核心是概念框架建构 + 历史脉络梳理 + 证据综合分析。
核心概念框架
确定性软件 vs. Agentic 软件
| 维度 | 传统确定性软件 | Agentic 软件 |
|---|---|---|
| 决策逻辑载体 | 静态源代码 | LLM 驱动的运行时生成 |
| 代码的作用 | 预先编写的决策逻辑本身 | 可被动态生成/丢弃的工具性资源 |
| 变更机制 | 人类工程师手动修改代码 | Agent 自主推理与行动 |
| 核心对象 | 源代码 | Agent 系统行为 |
| 控制模型 | 人类预先定义 | LLM 驱动 |
历史弧线：从 Licensed Software → SaaS → AaaS
Licensed Software → SaaS → Agent-as-a-Service (AaaS)
↑ ↑ ↑
操作复杂性 运营复杂性 决策复杂性
转移给用户 转移给用户 转移给用户
+ Agent
作者认为，每一次范式转移都把更多复杂性从最终用户转移出去：AaaS 不仅是转移运营复杂性，而是把决策复杂性本身也转移给了 Agent。
Agentic Engineering 的学科定义
作为软件工程学科的扩展，Agentic Engineering 有三个本质区别：
- 核心研究对象：Agent 系统（而非静态源代码）
- 控制模型：LLM 驱动（而非人类预定义）
- 人的角色：Intent Architect——定义意图而非编写代码（而非 Code Author）
证据基础
作者援引了三类证据：
- SWE-bench Verified：软件工程任务 benchmark，用于证明 Agent 当前在代码任务上的能力边界
- EvoClaw：进化式 Agent 能力测试
- LangChain 多 Agent 协作研究：多 Agent 协调的现状与局限
⚠️ 重要核查说明：原文未详细列出这些 benchmark 的具体数值结论，三类证据均仅作为背景引用，核心论点依赖二手引用的间接支撑。
四阶段路线图（Four-Stage Roadmap）
Stage 1: Tool-Augmented — Agent 具备工具调用能力
Stage 2: Workflow-Agentic — Agent 按预设工作流协作
Stage 3: Self-Organizing — Agent 自主发现协作模式
Stage 4: Self-Evolving — Agent 自主改进自身能力
作者认为当前行业整体处于 Stage 1 → Stage 2 的过渡期，Stage 3 和 Stage 4 是中长期目标。
关键实验与数据
本文为立场/分析论文，核心"实验"是对现有 benchmark 证据的综合分析，具体数据原文未完整披露。主要引用：
- SWE-bench Verified：作为当前 SOTA Agent 在软件工程任务上的能力证明（⚠️ 具体分数原文未引）
- EvoClaw：⚠️ 原文未给出具体数值
- LangChain multi-agent studies：⚠️ 原文未给出具体数值
重要说明：由于原文为立场论文且部分证据引用未给出具体数字，本文所有分析性结论应视为作者主张，而非经过同行评审验证的实验事实。
亮点与局限
亮点
- 概念框架的雄心：将 AI Agent 的出现放到软件工程历史长河中审视，提出从 Code-as-Product 到 Agent-as-Software 的本体论转变，视野开阔。
- Intent Architect 角色定义：为 AI 时代软件工程师的新身份提供了很有启发性的命名和定义。
- AaaS 的概念提炼：将当前 Agent 云服务的趋势归纳为继 SaaS 之后的第三次范式转移，具有思想实验价值。
- 四阶段路线图：将 Agent 能力发展具象化为可评估的阶段目标，对从业者有战略参考意义。
局限
- 缺乏原创实验数据：核心论点依赖现有 benchmark 的二手引用，且未提供具体数字支撑，可证伪性弱。
- 预测性质强：AaaS 是否会真的取代 SaaS、Intent Architect 是否会成为主流开发模式，都是开放性问题，论文提供的是论证而非定论。
- 商业现实：当前 Agent 系统依赖 LLM API，成本、延迟、可靠性等问题在论文中着墨有限，生产环境的大规模采纳路径不清晰。
- 原文未明确：SWE-bench Verified、EvoClaw 的具体分数；Stage 3/4 的具体技术路径；当前行业处于 Stage 1~2 的什么位置。
- 利益相关声明缺失：原文未披露作者背景和可能的利益冲突。
与同方向工作的关系
| 工作 | 核心主张 | 与本文关系 |
|---|---|---|
| SWE-bench 系列 | Agent 在代码任务上的能力评测 | 本文的主要证据来源 |
| AutoGPT / LangChain | Agent 框架与工程实践 | 本文描述的 Stage 1-2 现状 |
| Agentic AI 商业分析 | AaaS 商业模式 | 本文理论框架的产业背景 |
| 软件工程教科书 | 软件工程学科定义 | 本文试图扩展/重构的对象 |
本文与现有工作的最大区别在于学科框架层面的建构意图：大多数 Agent 研究关注"如何构建更好的 Agent"，本文关注"Agent 的出现对软件工程学科本身意味着什么"，是两篇不同层次的论文。
适合谁读
- 软件工程研究者：关心学科定义和未来方向的学术人员。
- AI 产品/战略负责人：需要理解 AI Agent 浪潮对软件开发行业影响的决策者。
- 技术管理者：规划团队如何向 Agent-Augmented 开发模式转型的管理层。
- 对 AI 哲学感兴趣的工程师：不满足于"怎么用"，而想思考"这意味着什么"的从业者。
⚠️ 重要提示：本文为立场论文（Position Paper），核心论点尚属一家之言，缺乏大规模实证数据支撑。部分概念（如 AaaS 必然取代 SaaS 的结论）应视为预言性观点而非已确立事实。
📝 原文未明确：SWE-bench Verified / EvoClaw 具体数值；作者 affiliations 和利益冲突声明；Stage 3/4 的具体技术里程碑定义；当前有多少比例的 Agent 系统处于各阶段。
工程落地与核查（Jay）
1. 事实核查结论
| 核查项 | 结论 | 可信度 |
|---|---|---|
| 立场论文，无原始实验数据 | ✅ 本文定位为 Position Paper，方法论是概念框架建构 | 高（原文自述） |
| SWE-bench Verified / EvoClaw 具体数值 | ❌ 原文未给出，仅作背景引用 | 低 |
| Stage 1-4 路线图 | ✅ 原文显式描述 | 高（但为路线图，非已验证事实） |
| 当前行业处于 Stage 1→2 过渡期 | ⚠️ 原文主观判断，无量化依据 | 低 |
| AaaS 取代 SaaS 的预测 | ⚠️ 开放性问题，文中作为论点而非结论 | 低 |
| Intent Architect 能否成为主流 | ⚠️ 开放性问题，无实证支撑 | 低 |
| 利益相关声明 | ❌ 原文未披露 | 低 |
核查结论：本文核心价值在概念框架，而非实证数据。文中的数据性结论（如"AaaS 是 SaaS 的继承者"）均属预言性观点，需与经过同行评审的实证研究区分对待。对本文的引用应区分「概念启发」和「事实引用」两种场景，后者须另找同行评审来源。
2. 实际系统落地的关键坑
坑 1：Position Paper 不能直接当工程蓝图用 本文的 Agentic Engineering 四阶段路线图是战略思考框架，不是工程实施路径。Stage 3（Self-Organizing）和 Stage 4（Self-Evolving）目前没有可操作的工程方法——团队如果把这些路线图阶段当成近期目标来规划，会导致资源错配。建议把本文当作战略参考，而不是技术路线图。
坑 2：「Intent Architect」概念对团队能力模型有重大影响，但没人知道怎么培养 本文最有工程价值的洞察可能是：未来工程师的核心能力从「写代码」变成「定义和调试意图（goal/prompt specification）」。但这个转变目前缺乏可操作的培训体系：- 如何评估一个 Intent Architect 的能力？ - 如何建立 prompt engineering 的工程规范？ - 如何在团队内部建立 Intent Architect 的职业发展路径？
这些问题目前没有行业标准，团队不应假设「已有的工程师稍加培训就能转型」，而应把这个转型当成独立的组织能力建设项目。
坑 3：AaaS 商业模式的成本结构与 SaaS 有本质不同，但本文未讨论 AaaS 的成本模型是「按 LLM API 调用计费」，而非 SaaS 的「订阅制/座位制」。这个差异意味着： - Agent 系统的成本随 query 复杂度非线性增长 - Agent 的自主行动范围直接影响成本（Agent 能执行多少步？每步多少钱？） - 成本控制和成本分摊机制在 AaaS 场景下是工程问题，不是商务问题
本文没有讨论这些，实际落地时团队需要自己建模。
坑 4：Agent 作为决策逻辑载体带来的合规挑战被严重低估 如果 Agent 本身成为软件的核心（而非工具），则： - 当 Agent 做出错误决策导致损失时，责任归属是什么？ - 如何对 Agent 系统做审计？（代码可 review，LLM 决策不可直接 review） - 金融/医疗/法律等受监管行业的 Agent 部署，监管框架目前几乎空白
本文未涉及这些风险维度，但它们是 Agentic 软件进入生产环境的硬约束。
3. 工程落地检查清单
- [ ] 战略 vs 工程区分：团队是否把本文的路线图阶段当作战略参考而非实施计划？
- [ ] Intent Architect 能力模型：团队是否已开始建立 prompt engineering 的工程规范和能力评估标准？
- [ ] 成本建模：Agentic 系统的 LLM API 成本模型是否建立？不同 query 复杂度下的单位成本曲线？
- [ ] 合规框架：受监管行业是否已有 Agent 部署的合规路径？目前是法律/合规空白区。
- [ ] 可观测性：当 Agent 的决策过程不可直接 review 时，用什么方式做端到端 trace 和事后审计？
- [ ] Benchmark 验证：SWE-bench Verified / EvoClaw 的具体数值建议从原始论文获取，用以校准团队对 Agent 能力的实际预期
4. 核心工程决策参考
本文作为战略思考的价值在于提醒工程师：以工具思维引入 Agent 是渐进式改进，以系统思维引入 Agent 才是范式转移。但从工程落地角度，当前阶段实际可操作的是：
- 工具增强（Stage 1）：在现有系统里给 Agent 叠加 tool calling 能力，如 CI/CD pipeline 里用 Agent 做代码审查/测试生成
- 工作流 Agentic（Stage 2）：用 Agent 协调多个已有服务（如自动化的跨系统数据同步+报告生成），但每步有预设工作流约束
- Stage 3/4：目前无可靠的工程方法，不建议作为近期项目目标
切忌：把 Position Paper 的概念野心当成当前工程能力的上限。Agent 的工程落地现状远落后于本文描述的愿景，当前阶段「务实落地 Stage 1-2」比「规划 Stage 3-4」更重要。