现有的 coding agent 已经能检视仓库、跑测试、改文件——但部署后就是静态的。同一个 bug 在 repo A 里踩过的坑，到 repo B 照踩不误。软件开发是动态反馈闭环，Agent 却不会从中积累经验。这篇综述要回答的就是：让 coding agent 从编码经验中进化自己，这件事做到什么程度了，还有哪些坑。
软件工程为什么是自进化的天然试验场
软件工程和一般 Agent 任务有一个根本区别：它提供可执行反馈。编译器报错、测试红灯、CI 失败、代码 review 评论——这些都是具体的、可验证的信号。一般 Agent 任务环境中，反馈要么是人工的 yes/no，要么是弱信号。而软件工程中的反馈天然丰富、可自动化执行、可重复验证。
同时，仓库级上下文（代码结构、依赖关系、历史修改）提供了比单次任务丰富得多的环境信息。一个 Agent 如果能在 repo A 中学到的调试策略应用到 repo B，它的价值就远超"每次从零开始"的静态 Agent。
这就是 self-evolving coding agent 的动机：让 Agent 通过更新自身的框架、记忆、技能、工具、模型或协作结构，把编码反馈变成持续改进。
五层分类法：什么东西在进化
这篇综述的核心贡献是一个以"进化对象"为中心的分类体系。不是按算法分类，不是按应用场景分类，而是按Agent 中什么组件在改变分类。这五层从轻到重：
Framework（框架层）：Agent 直接改自己的代码。代表工作 SICA 和 Darwin Gödel Machine——Agent 把自己的实现当作可修改对象，用 benchmark 成绩验证改进。
Memory（记忆层）：不改动代码，但积累仓库知识、修复经验、失败案例。AGENT KB 做跨域经验共享，MemEvolve 做记忆系统的元进化。成本最低，但"记忆污染"风险最高。
Skills & Tools（技能与工具层）：从编码轨迹中自动抽取可复用技能或动态创建新工具。Socratic-SWE 从解题 trace 中派生技能，Live-SWE-Agent 在解题过程中实时创建和修订工具。把一次性成功变成可检索的经验库。
Model（模型层）：用编码反馈做后训练或 RL 微调。SWE-RL 把 SWE-bench 上的执行反馈转为 RL 信号，CURE 让 coder 和 tester 协同进化。最重，但改变最持久。
Workflow & Topology（工作流与拓扑层）：进化 Agent 间的协作结构和沟通拓扑。SEW 自进化 agentic workflow，EvoMAC 动态调整协作网络。权力最大，但过拟合和协调开销的风险也最大。
图1：Self-Evolving Coding Agent 全景。从底层的 LLM 到顶层的 Workflow & Topology，每一层都可以从编码反馈中进化。虚线箭头表示进化信号的流动方向。
两个正交维度：何时进化、靠什么进化
五层分类回答了"什么在变"。论文还补充了两个正交维度来回答"什么时候变"和"凭什么变"。
进化时机分三层：任务中（test fail 立即调整策略）、任务后（轨迹总结成经验）、阶段式（积累一批验证过的轨迹后做批量更新）。持久度和成本依次递增。
驱动证据分三类：结果证据（pass rate、resolve rate，粗但可比较）、环境反馈（编译错误、测试日志、运行时异常，细但局部）、轨迹证据（完整解题记录，最丰富但提取成本最高）。
软件工程的独特之处在于：这三种证据天然存在且可执行验证，比一般 Agent 任务环境中的反馈丰富得多。但丰富不等于可靠——测试可能不完整，编译器报错可能误导，CI 结果可能是暂态的。
进化对象 × 时机 × 证据：组合空间
这三个维度（五层进化对象 × 三种时机 × 三类证据）构成了一个设计空间。不同组合适用于不同场景：
| 场景 | 进化层级 | 时机 | 证据 |
|---|---|---|---|
| 调试当前 bug | 任务中 | 环境反馈 | Tool 层 |
| 跨仓库经验积累 | 任务后 | 轨迹证据 | Memory 层 |
| 定期模型升级 | 阶段式 | 结果 + 轨迹 | Model 层 |
| 多 Agent 协作优化 | 阶段式 | 结果证据 | Workflow 层 |
| 工具链自完善 | 任务中 + 任务后 | 环境 + 轨迹 | Skill 层 |
真正的挑战：不在"能不能进化"
这篇综述最有价值的部分不是分类法本身，而是它列出的开放问题。这些问题的存在，说明 self-evolving coding agent 离生产可用还有显著距离。
反馈可靠性
测试可能不完整（覆盖率不足）、编译器报错可能误导（依赖冲突被误报为语法错误）、CI 结果可能是暂态的（网络抖动导致的 flaky test）。Agent 如果盲信这些信号做进化决策，会系统性地积累错误经验。
这个问题的严重程度被严重低估。目前几乎所有工作都假设"能跑通的测试就是可靠的反馈"，但实际上测试质量参差不齐，Agent 无法区分"测试真正验证了正确性"和"测试恰好没覆盖到错误路径"。
Benchmark 过拟合
大部分工作在 SWE-bench 上训练和评估，用 pass rate 作为进化选择压力。这直接导致 Agent 可能变成"考试机器"——在 benchmark 上表现越来越好，但在真实项目中表现未知。
更深层的问题：如果一个 Agent 的进化目标是"通过 SWE-bench 上的测试"，它学到的不一定是"如何写好代码"，而是"如何通过 SWE-bench 上的测试"。这两件事不是同一件事。
记忆污染与技能衰退
仓库会变、依赖会升级、API 会废弃。三个月前积累的修复经验，可能现在不仅没用，反而有害。但现有记忆系统的遗忘和更新机制几乎是空白。
这跟人类开发者类似——一个老工程师的经验值钱，但如果他拒绝更新知识库，经验反而成了负担。Agent 目前没有"验证记忆是否过期"的能力。
安全约束
框架层进化意味着 Agent 能修改自己的代码。这在生产环境中是不可接受的——你不会希望一个代码审查 Agent 在没有人类审计的情况下重写自己的审查逻辑。
自修改必须有审计边界。但这个边界怎么画，目前没有共识。太紧则 Agent 无法进化，太松则安全无法保证。
评估体系缺失
现在的评估几乎全是短任务通过率。但真实软件工程还要求：可维护性（生成的代码能不能被人类理解）、安全性、效率（时间和空间复杂度）、可审查性。这些维度目前没有 benchmark 覆盖。
让 Agent 进化是容易的。让它可靠地进化——在真实项目中持续改进、不过拟合、不积累错误经验、不突破安全边界——才是真正的挑战。
对 Agent 系统设计者的启示
这篇综述的框架对实践者有几个直接启示：
选对进化层级比进化算法本身更重要。记忆积累、技能抽取、模型微调、工作流重构、框架自修改——是不同重量级的进化。不要因为"self-evolution"这个词听起来酷就选最激进的方式。大多数场景下，记忆层 + 技能层已经能提供足够的自适应能力。
进化安全必须前置设计。不要先让 Agent 随便进化，事后再加约束。安全边界应该在架构层面就确定：哪些组件可以自修改，哪些必须人工审批，进化结果如何回滚。
评估体系决定进化方向。如果你的 Agent 只在 pass rate 上进化，它就会优化 pass rate。如果你在乎代码质量，就必须把代码质量纳入进化信号。进化算法不创造价值观——它放大已有的评估标准。
本质判断
这篇综述的价值不在于提出了新方法，而在于把一个散乱的研究方向拉到了一个可以比较、可以设计的框架里。五层分类法 + 两个正交维度的组合空间，让研究者可以清晰地定位自己的工作，也让工程师可以按需选择进化策略。
最大的缺口不在算法，而在进化安全性和评估体系。下一个真正有用的 self-evolving coding agent，很可能不是进化算法最强的那个，而是安全约束和评估体系设计得最明白的那个。