Self-Evolving Coding Agents：给"自我进化代码 Agent"画一张地图

💬 这是一篇综述：系统梳理"自我进化代码 agent"这一新兴方向，提出 object-centered 分类法（进化什么/何时进化/何种证据驱动），并指出可执行反馈、仓库级上下文、丰富的编码轨迹让软件工程天然适合做 agent 自我进化的试验场，同时点出 benchmark 过拟合、反馈可靠性、长期记忆退化、评测维度单一等尚未解决的挑战。适合作为该子领域的入门地图，而非某个具体新方法的论文。

🎯 问题

代码 Agent 部署后大多"一成不变"，但软件开发本身是反馈丰富的动态过程

当前基于 LLM 的代码 agent 已经能读代码库、调工具、跑测试、修 bug、出 patch，但作者观察到一个反差：软件开发本身是"动态、反馈丰富"的过程（每次编辑都有编译结果、测试结果、CI 日志作为即时信号），可现有的多数 agent 在部署之后却"基本保持静态"——遇到新代码库、新任务分布时不会自我调整。这催生了一类新方向：agent 基于过去的编码经验，主动修订自己的"框架、记忆、技能、工具、模型或协作结构"，也就是"自我进化代码 agent"。论文的首要目标是先把这个概念定义清楚，把它和"标准代码 agent"（静态）以及"通用自我进化 agent 系统"（不特指代码场景）区分开——这是一个仍缺乏统一术语和分类框架的新兴交叉领域。

自我进化 agent（self-evolving agent）：泛指那些能在部署后，依据与环境交互产生的反馈信号，持续修改自身某些组成部分（而非仅更新对话上下文）的智能体系统，是目前 agent 研究中与"静态 prompt/静态权重"agent 相对的一大类方向。

🔬 方法

Object-centered 分类法：五类"进化什么"

论文核心贡献是一套"以进化对象为中心"的分类法，把已有工作归入五个（可重叠、非互斥）类别：

Agent Framework 自我进化——agent 直接修改自己的脚手架/实现代码本身，代表工作如 SICA、SIFT、STOP，以及 Darwin/Mendel/Huxley 等 Gödel Machine 系列。
Memory 自我进化——构建并持续精炼显式记忆，内容包括"issue 修复轨迹、仓库历史、成功与失败的 patch"，代表工作如 SWE-Exp、EvoCoder、Subtask-Level Memory、EvoRepair、Repository Memory、SAGE。
Skill 与 Tool 自我进化——把轨迹蒸馏成可复用的程序性技能或新工具，代表工作如 CODESKILL、GSkill、Socratic-SWE、EffiSkill、Live-SWE-Agent。
Model 自我进化——通过闭环反馈更新底座模型、策略或验证器本身，代表工作如 Self-play SWE-RL、Agent-RLVR、ReVeal、CURE、ZeroCoder、Sol-Ver、ACE。
Workflow 与拓扑自我进化——调整多 agent 的协作结构、角色分工、通信图，代表工作如 SEW、AFlow、EvoAgentX、SEMAG、EvoMAC、AgentConductor。

▶ 另两个维度：何时进化 + 什么证据驱动

进化时机分三种：①任务内进化（task-time）——agent 在解决当前任务的过程中就发生调整（比如中途修订工具）；②任务后进化（post-task）——一条轨迹结束后做反思，把结果沉淀为记忆、技能、仓库知识或修复经验；③阶段式进化（stage-wise）——积累一批验证过的轨迹、self-play 任务或验证结果之后再批量更新，最接近"跨代自我改进"的范式。

驱动证据也分三类：①结果证据（outcome evidence）——粗粒度、比较性的信号，如 benchmark 解决率、测试通过率、验证器打分；②环境反馈（environmental feedback）——更即时局部的信号，如命令输出、编译诊断、运行时异常、失败的测试日志；③轨迹派生证据（trajectory-derived evidence）——完整交互记录，用于构建记忆/技能库，价值在于把"具体的一次编码尝试"转化为"可复用的经验"。

📊 结果

评测现状盘点 + 四大待解挑战

作为综述，这部分不是实验数字，而是对现有 benchmark 生态和评测方法的系统盘点，以及对开放问题的总结：

常用 benchmark：仓库级 issue 修复类以 SWE-bench 系列（含 Lite/Verified/Pro）和提供可执行训练环境的 SWE-Gym 为主；函数级/竞赛式编程类则用 HumanEval、MBPP、APPS、CodeContests、LiveCodeBench。评测指标覆盖结果型（解决率/修复率/Pass@k）、过程型（在成本约束下追踪自我修改是否真的带来提升）、以及效率与泛化型（成本、运行时间、token 用量、向未见仓库的迁移能力）。

四大开放挑战：①可复现性、数据污染与 benchmark 过拟合——依据 benchmark 结果来筛选自我修改的做法，对评测噪声和 benchmark 泄露高度敏感；②反馈可靠性、安全性与工具依赖——测试、CI 日志、奖励模型本身并不完美，误导性信号可能"塑造未来行为，而不只是影响单次输出"；③长期记忆、技能与协调——经验库和技能库存在变得"陈旧、冗余、过度绑定特定仓库、或被污染"的风险；④短基准之外的评测——当前指标低估了可维护性、安全性、可审查性、效率与长期可靠性，跨领域迁移能力"基本未被探索"。

💡 我的看法

作为"自我进化代码 agent"子领域的入门地图，也给 duplex agent 的记忆/进化设计提了个醒

这篇综述最大的价值在于把一个还没有统一术语的散乱领域，用"进化什么 × 何时进化 × 何种证据"这三个正交维度做了清晰的坐标系——读完之后再去看 SWE-Exp、AFlow、Agent-RLVR 这类具体工作，能很快判断它们落在分类法的哪个格子里，是理解这个方向很高效的入口。作者提出"软件工程是 agent 自我进化天然试验场"的论点也站得住脚：可执行反馈（编译/测试）、仓库级上下文、丰富的编码轨迹，这三者恰好构成了自我进化所需的高质量、低成本信号来源，这也是为什么这个方向在 SE 社区里比在更开放的通用 agent 场景发展得更快。

和我关注的 duplex agent 方向对照，最值得记一笔的是"驱动证据"这个维度和"长期记忆退化"这个挑战。DuplexOmni 的 Thinking Layer/Interaction Layer 分工本质上也需要某种"进化"机制来沉淀交互经验（比如哪些打断时机是错的、哪些延迟预算分配失败了），而这篇综述里 memory/skill 自我进化类别下反复出现的"经验库陈旧化、过度绑定特定场景"问题，在实时交互场景里可能更尖锐——因为交互轨迹比代码修复轨迹更难被"可执行反馈"验证对错（没有单元测试能告诉你一次打断是否得体）。这提示一个值得关注的方向：如果要把 SE 领域这套"以可执行反馈驱动自我进化"的经验往 duplex/实时交互场景迁移，核心瓶颈会是如何构造出可类比"测试通过/失败"的低成本、高信噪比验证信号。此外，作为综述本身的局限是它止步于分类和现状梳理，没有给出跨类别的定量对比（比如哪类进化机制在同一 benchmark 上收益更大），这点留给了后续工作。

给"自我进化代码 Agent"画一张地图 · Self-Evolving Coding Agents

🎯 问题

🔬 方法

📊 结果

💡 我的看法