来自 Happy Bhati 等人，2026/4/29 提交，9 页 survey，综合 Anthropic、OpenAI、DeepMind、Microsoft Research、Princeton、Stanford 多方研究。

论文提出 Agentic SDLC（A-SDLC） 概念，把软件工程的核心对象从「代码生成」转移到「人在监督下的委托执行」，并给出六层参考架构。

📌 核心问题：从 Copilot 到 Agent，软件工程范式正在重构

2023 年 GitHub Copilot 还在做行级补全，2026 年 Claude Code / Codex CLI / AlphaEvolve 已经能在仓库级自主执行任务。这不是工具升级，是软件开发范式的根本性转变。

论文的核心主张是：我们需要一个新的参考架构来理解这场变革。传统的 SDLC 模型（瀑布、敏捷、DevOps）都是以「人」为中心设计的，而 A-SDLC 以「人-Agent 协作」为中心。

这不是学术界的空想——SWE-bench 的数据已经证明了 Agent 的工程能力：

📊 关键数据：SWE-bench 两年 40 倍跃升

  • SWE-bench Verified：1.96%（2023.10）→ 78.4%（2026.4），2.5 年提升 40 倍
  • 生产效率：控制实验中 13.6%-55.8% 的时间节省
  • 劳动力市场：Anthropic 2026 年采样，49% 的岗位 AI 已承担至少 1/4 任务
关键洞察：SWE-bench 从 2% 到 78% 不只是模型变强了。Harness 设计——测试反馈、环境编排、迭代策略——才是推高成功率的关键变量。这印证了 Harness Engineering 的核心观点：工程能力 > 模型能力。

🏗️ 六层参考架构：A-SDLC 的骨架

论文提出的六层架构，从底层到顶层，描述了 Agent 如何嵌入软件开发全生命周期：

  1. 任务理解层（Task Understanding） — Agent 解析需求、上下文、约束的能力
  2. 规划层（Planning） — 将复杂任务拆解为可执行步骤
  3. 代码生成层（Code Generation） — 最成熟的一层，也是当前竞争最激烈的
  4. 验证层（Verification） — 测试、linting、类型检查、安全扫描
  5. 迭代层（Iteration） — 基于反馈的自我修正循环
  6. 集成层（Integration） — PR、代码审查、部署流水线

这个架构的关键洞察是：代码生成只是六层中的一层。当前 Agent 进展最快的是第 3 层，但真正决定工程质量的是第 4-6 层——验证、迭代、集成。

关键洞察：Harness Engineering 的核心就是设计第 4-6 层。测试反馈循环（验证）、环境编排（迭代策略）、PR 流水线（集成）——这些「Harness」才是 Agent 能在真实工程中落地的关键。

🔄 A-SDLC 范式：从「写代码」到「监督执行」

论文提出的 A-SDLC 范式，核心变化是：

  • 人的角色： 从「编写者」变成「监督者」
  • Agent 的角色： 从「辅助工具」变成「委托执行者」
  • 协作模式： 从「人写代码 + AI 补全」变成「AI 执行 + 人审查」

这不是未来——Claude Code、Codex CLI、AlphaEvolve 已经在实践这个模式。工程师的核心价值正在从「写代码的能力」转向「监督 Agent + 定义问题的能力」。

❓ 五个开放问题：行业最缺共识的地方

论文最后提出了五个尚未解决的关键问题，也是当前行业争论最激烈的地方：

  1. 评估（Evaluation） — 现有 benchmark 能否衡量 Agent 的真实能力？SWE-bench 测的是修复已有 issue，但真实开发中 80% 的工作是定义问题而非解决问题。
  2. 治理（Governance） — Agent 生成的代码出了 bug，谁负责？开发者？Agent 提供商？还是审查通过的人？法律责任归属问题远未解决。
  3. 技术债（Technical Debt） — Agent 生成的代码谁来维护？它不理解团队的架构哲学，只追求「能跑」。长期来看，这可能制造比它解决的更多的问题。
  4. 技能再分配（Skill Redistribution） — 工程师角色从「写代码」转向「监督 Agent」，那新人怎么培养？没有写过代码的人，能有效监督写代码的 Agent 吗？
  5. 注意力经济学（Attention Economics） — 代码审查成本是否从「写代码」转移到了「审查 Agent 输出」？Agent 生成代码很快，但审查 Agent 输出可能比审查人写的代码更累。
关键洞察：五个问题中，评估和治理是最紧迫的。评估决定了我们能不能信任 Agent，治理决定了出了事谁担责。这两个问题没有共识，A-SDLC 就只能停留在实验阶段。

🧠 引发思考：Harness Engineering 的理论基础

这篇 survey 最大的价值不在于数据（SWE-bench 分数网上都能查到），而在于它提供了一个系统性的框架来理解 Agent 在软件工程中的位置。

六层架构直接映射了 Harness Engineering 的实践：

  • 任务理解 → Prompt Engineering + Context 管理
  • 规划 → Agent Loop 设计 + ReAct/Tree-of-Thought
  • 代码生成 → 模型能力（最不缺的部分）
  • 验证 → 测试反馈循环（Harness 核心）
  • 迭代 → 环境编排 + 错误恢复策略
  • 集成 → CI/CD 流水线 + 代码审查自动化

论文的五个开放问题，本质上都是 Harness 设计问题——如何让 Agent 在真实工程环境中可靠地工作，而不仅仅是在 benchmark 上刷分。

这和我们之前推的 Harness Engineering 系列、SWE-CI、TDAD 完全呼应。

📎 相关阅读

  • 论文原文：arXiv 2604.26275
  • SWE-CI：阿里+中大，持续集成驱动的 Agent 评测
  • TDAD：测试驱动 Agent 开发
  • Harness Engineering 系列：工程能力 > 模型能力的系统性论证

逍遥云初 | 2026.05.03