综述 | Self-Evolving Coding Agents：自进化编程智能体

导读

编程智能体正在从“会写代码的助手”走向“能在真实软件仓库里行动的工程代理”。它们可以阅读项目结构、搜索代码、编辑文件、调用命令行、运行测试、诊断错误并生成补丁。但现实软件工程是动态的：仓库持续演化，依赖会更新，测试会失败，修复尝试会留下可复用经验，人工代码审查也会提供反馈。如果智能体部署后一直保持静态，就很容易在不同任务里重复同样的定位错误、测试误判和补丁缺陷。 《Self-Evolving Coding Agents》正是围绕这一新方向展开的综述。论文关注的不是一般意义上的自进化智能体，也不是普通代码生成模型，而是一个更具体的问题：编程智能体能否从自己的软件工程交互中持续改进未来行为。所谓自进化，可以发生在智能体框架、记忆、技能和工具、模型、工作流与多智能体拓扑等不同对象上；也可以发生在任务执行中、任务结束后，或积累一批轨迹后的阶段性更新中；其证据来源则包括测试结果、编译错误、运行日志、代码审查、仓库历史和完整执行轨迹。 这篇综述的价值在于，它把一个还很新的研究方向整理成可比较的框架：什么在进化、什么时候进化、凭什么证据进化、如何评估进化是否可靠。对软件工程智能体研究者来说，这篇论文提供了一张清晰的路线图；对大模型应用开发者来说，它也提醒我们：未来可靠的代码智能体不仅要“解当前题”，更要把失败、修复、测试和项目经验转化为可验证、可维护、可复用的能力。

论文信息

论文题目：Self-Evolving Coding Agents 作者：Hao Zhou, Haichuan Hu, Ye Shang, Quanjun Zhang 机构：南京理工大学、南京大学 论文链接：https://arxiv.org/abs/2608.03392 项目清单：https://github.com/zhouhao1024/Awesome-Self-Evolving-Coding-Agents 发布时间：2026 年 8 月 4 日

引言：为什么编程智能体需要自进化

论文首先指出，现代编程智能体已经明显超出代码补全或函数生成。它们被嵌入到真实软件工程工作流中，需要理解自然语言需求、检查仓库、定位相关文件、修改多处代码、运行测试、解释失败、迭代修复，并在必要时参与代码评审和调试。这样的任务通常是长程、工具密集、强依赖项目上下文的，而不是一次性文本生成。 静态智能体在这里会遇到天然瓶颈。模型、提示词、工具接口、记忆机制和控制流一旦固定，智能体就很难适应不断变化的仓库、依赖、接口和项目规范。更重要的是，软件工程本身提供了大量高质量反馈：单元测试、编译错误、运行时异常、静态分析警告、持续集成日志、人工审查意见、补丁是否通过等。这些反馈比许多一般任务中的文本评价更具体、更可执行，也更适合转化为后续改进信号。 因此，自进化编程智能体的核心目标不是简单重试，而是把过往编码尝试和软件特定反馈转化为持久适应：更新框架、记忆、技能、工具、模型策略或协作结构，使未来软件工程任务表现更好。论文围绕三个研究问题组织全文：哪些组件会进化、进化何时发生、应如何评估自进化编程智能体的性能、可靠性和泛化能力。

背景与定义

论文第二部分先澄清概念边界。 编程智能体不是单纯的代码生成模型。传统代码模型主要根据自然语言说明或局部上下文生成代码，而编程智能体是在软件开发环境中行动：它能查看文件、调用搜索和编辑工具、运行命令、执行测试、观察反馈并迭代修改。其系统形态通常由大模型、上下文管理、工具接口、控制逻辑和验证机制共同组成。 自进化智能体则是一个更广泛的概念，指智能体能根据执行轨迹、环境反馈和累积经验修改自身行为或内部组件。它不必一定更新模型参数，也可以通过反思、记忆、提示词优化、工具库、技能库、策略或架构搜索实现改进。Reflexion、Self-Refine、ExpeL、Voyager 等工作都体现了这种从经验中改进行为的思路。 自进化编程智能体位于二者交叉处。论文将其定义为：一种智能体式软件工程系统，能够基于过去的编码尝试和软件特定反馈更新自身行为或内部组件。这些更新可能作用于智能体框架、仓库记忆、修复经验、技能文档、工具、模型策略或多智能体协作结构。它与一般自进化智能体的关键区别在于反馈来源更工程化：测试、编译器、运行日志、持续集成、仓库历史和代码审查可以提供可执行、可复现、可验证的证据。

论文强调，这种反馈丰富性既是机会也是风险。测试可能不完整，日志可能有歧义，基准结果可能被过拟合，一个通过本地测试的补丁也可能损害长期可维护性。因此，自进化编程智能体必须被视为软件工程系统，而不是只追求分数提升的代理。

分类体系：哪些对象会进化

第三部分是论文的核心。作者提出一个以“进化对象”为中心的分类体系，将已有工作分为五类：智能体框架自进化、记忆自进化、技能和工具自进化、模型自进化、工作流和拓扑自进化。这些类别并非互斥，一个系统可能同时更新多类对象，但这样的划分能帮助比较不同机制。

智能体框架自进化把智能体自身当作可修改的软件工件。现代编程智能体通常有一个 scaffold，负责任务分解、模型调用、文件编辑、shell 执行、测试、调试和控制流。框架自进化的思路是让智能体检查自己的实现，提出对自身代码、提示或工具链的修改，运行修改后的版本，并通过测试、运行结果或基准性能判断是否保留。SICA、SIFT、STOP、Darwin Gödel Machine 等工作都属于这一类。它的优势是能够直接改造“产生未来软件工程行为的机器”，风险也更大：错误修改可能破坏智能体循环，过拟合评测 harness，甚至学会利用验证漏洞。 记忆自进化关注智能体如何把软件工程经验存储、抽象和检索。这里的记忆不只是聊天历史，而是 issue 解决轨迹、仓库历史、失败补丁、成功修复、测试结果、编译诊断、运行日志、漏洞模式和代码审查意见等软件特定经验。SWE-Exp 将过往 issue-resolution 轨迹构造成经验库；EvoCoder 区分通用经验和仓库特定经验；Subtask-Level Memory 按分析、定位、编辑、验证等子任务粒度存储经验；Repository Memory 利用历史提交、关联 issue 和高频修改区域支持未来代码定位。记忆自进化的核心难题不是存得越多越好，而是如何过滤噪声、抽象规律、避免陈旧和误检索。 技能和工具自进化关注“如何行动”。记忆记录发生过什么，技能和工具则编码遇到相似情形时应该怎样做。CODESKILL 从编程轨迹中抽取任务级和事件级技能，例如如何检查仓库、如何验证修复、如何处理某类命令失败。GSkill 学习仓库特定技能文档，类似为智能体自动生成项目入门手册，描述架构、测试流程、编码约定和常见陷阱。Socratic-SWE 从历史求解轨迹中提炼 Agent Skill Registry，再用这些技能生成更有针对性的修复任务。Live-SWE-Agent 则展示了工具自进化方向：从极简 bash scaffold 出发，在解决仓库级问题时创建和修改自定义工具。 模型自进化指更新模型侧组件，包括基础模型、适配器、策略、奖励模型或 verifier。其边界在于，普通软件工程数据后训练不一定是自进化；只有当训练信号来自智能体自己的编码尝试、可执行反馈或自生成任务，并改变未来智能体行为时，才符合论文定义。Self-play SWE-RL 通过 bug 生成、bug 修复和可执行验证形成闭环；Agent-RLVR 用软件工程轨迹、环境奖励和引导重试更新策略；ReVeal、CURE、ZeroCoder、Sol-Ver、ACE 等工作则围绕 coder-verifier 共进化、生成测试和对抗测试构建模型侧改进信号。模型自进化强大但脆弱，因为不完整测试、弱 verifier 或合成数据偏差可能固化成跨任务行为。 工作流和拓扑自进化改变的是智能体系统的组织方式。很多失败并非因为模型不会写代码，而是因为系统先定位错文件、过早编辑、跳过复现、太晚测试，或把错误日志交给不合适的角色。SEW、AFlow、EvoAgentX 将工作流表示为可搜索或可演化的图；SEMAG、EvoMAC、AgentConductor 研究多智能体角色、通信结构和协作密度如何随任务难度与执行反馈变化。这一类机制更全局，能决定何时搜索、何时测试、谁来审查、失败如何路由，但也可能增加协调成本、过拟合基准或只优化通过测试而忽略可维护性。

演化时机与证据

第四部分从两个正交维度补充分类：什么时候进化，以及依据什么证据进化。 从时间上看，论文区分三类。任务内演化发生在当前编码任务尚未结束时，智能体根据测试失败、编译错误、运行日志、工具异常或无效搜索立即调整补丁、工具使用或协作流程。Live-SWE-Agent 在任务过程中创建和修改工具，SEMAG 和 AgentConductor 则可以根据任务难度和反馈调整协作结构。任务内演化响应快，但通常影响局部，若要产生长期价值，需要后续沉淀为记忆、技能或工作流模式。 任务后演化发生在一次 issue 解决、修复尝试或完整开发轨迹结束之后。此时智能体不只是用反馈修当前补丁，而是把完整轨迹解释为未来经验。失败测试、错误定位、补丁审查和成功修复都可以被抽象成仓库知识、修复启发或可复用技能。SWE-Exp、Repository Memory、EvoRepair、SAGE、CODESKILL、GSkill 等系统都强调把任务后证据转化为持久状态。它比任务内演化慢，但更容易跨 issue、跨仓库或跨智能体版本迁移。 阶段式演化则发生在积累了一批软件工程交互之后，通常用于更新模型策略、智能体变体或更大范围的框架。Self-play SWE-RL、Agent-RLVR、coder-verifier 共进化和对抗测试生成都属于这一类。它最接近跨代自改进，但也最依赖可靠训练环境和 verifier。论文特别提醒，生成更多自训练数据并不必然带来进化；如果迭代间没有可学习的信息增益，循环可能只是在放大冗余和偏差。 从证据上看，论文分为三类。结果证据是 patch 是否通过、solve rate、test pass rate、verifier score、修复成功率、成本和延迟等整体指标。它适合比较候选智能体、工作流、技能或策略，但只能说明“哪个更好”，不一定解释“为什么更好”。环境反馈来自交互过程中：编译器诊断、运行异常、测试日志、shell 输出、依赖失败和工具响应。它适合支持任务内调试、工具创建和局部策略调整。轨迹衍生证据来自完整执行记录，包含仓库检查、定位、工具调用、编辑、测试、失败分支、恢复步骤和最终补丁。它最适合构建记忆、技能、课程和长期经验。 这部分的重要观点是：自进化的可靠性不只取决于更新算法，还取决于反馈信号是否可信、粒度是否合适、持久化方式是否正确。

评估：不止看一次任务成功

第五部分讨论基准与评估。论文指出，评估在自进化编程智能体中有双重角色：它既衡量性能，也是智能体进化证据的重要来源。一个 benchmark result、失败测试、verifier 判断或高成本轨迹，都可能决定记忆是否保留、技能是否复用、工作流是否修改、模型是否更新。 仓库级 issue resolution 是最核心的评估场景。SWE-bench 及其 Lite、Verified、SWE-Bench Pro 等变体要求智能体在真实软件项目中理解 issue、检查仓库、定位文件、修改代码、运行测试并根据可执行反馈修复。这类任务非常适合研究自进化，因为仓库上下文、失败尝试、补丁结果和执行日志都可以成为未来适应的经验。SWE-Gym 等环境进一步把软件工程任务转化为可执行训练和评估环境，为模型或 verifier 改进提供基础。 函数级和竞赛式编程基准仍然有价值，如 HumanEval、MBPP、APPS、CodeContests、LiveCodeBench 等。它们适合评估代码生成、算法推理和工作流优化，但不足以代表真实软件工程中的长程仓库交互、依赖管理、持续集成和项目约束。因此论文将其视为补充证据，而不是仓库级评估的替代。 指标方面，pass rate、solve rate、resolve rate、repair rate、benchmark score 和 Pass@k 是必要但不充分的。对于自进化智能体，还应评估进化过程本身：修改后的智能体是否稳定提升，经验库是否真的帮助未来任务，技能是否跨仓库迁移，工作流变化是否降低成本，模型更新是否提升鲁棒性。效率和泛化也很重要，因为自进化往往需要额外搜索、重复执行、轨迹存储、检索或模型训练。理想评估应同时报告成本、时间、token、步骤数、检索开销、跨仓库泛化、跨模型泛化和不同编程语言迁移。 论文认为，目前评估最擅长衡量功能正确性和基准成功率，但对长期可维护性、鲁棒性、安全性，以及智能体能否从不完整或误导性反馈中学到可靠行为，仍然评估不足。

挑战与开放问题

第六部分总结开放挑战。自进化编程智能体的风险高于普通编程智能体，因为错误反馈不只影响一次补丁，还可能被存入记忆、提炼成技能、选为工作流或用于更新模型。 第一是可复现性、污染与基准过拟合。智能体会跨运行、任务、仓库、工具环境和模型版本变化，导致结果难以复现。基于 benchmark 选择自修改或智能体变体的系统尤其容易受到评测噪声和数据泄漏影响。未来需要区分真正能力提升、记忆化、反复调参和对公开验证信号的过拟合。 第二是反馈可靠性、安全与工具依赖。测试、编译器、持续集成日志、生成测试和奖励模型都可能有盲点。若智能体依赖这些信号修改工具、工作流或自身 scaffold，误导性反馈就会塑造未来行为，而不只是造成一次错误输出。因此，工具可靠性、沙箱一致性和安全检查都应被视为自进化问题本身。 第三是长期记忆、技能和协作的质量控制。经验库、仓库记忆和技能库可能过时、重复、过度仓库特定，或被失败轨迹污染。多智能体系统还会带来角色责任不清、通信成本升高和协作不稳定。真正有用的自进化系统需要能审计记忆、更新技能、删除陈旧经验，并约束协作结构。 第四是超越短期基准的评估。真实软件工程不仅要求通过测试，还要求可维护、安全、可审查、高效和长期可靠。当前多数证据仍集中在同域或近域泛化，例如跨相关仓库或相关代码任务。软件工程反馈中学到的进化行为能否迁移到非编码任务，仍基本未被充分探索。

结论

论文最后强调，自进化编程智能体代表了从静态软件工程助手走向持续适应系统的转变。它们通过与代码、仓库、工具、测试和人类反馈的持续交互，改进未来的软件工程行为。这个方向不应被理解为单一算法，而是一系列由可执行软件工件和仓库级上下文驱动的适应过程。 这一区域的难点恰恰来自它的优势：软件工程提供了具体反馈，但这些反馈并不总是完整、明确、低成本或长期可靠。未来进展需要能够验证反馈、修订陈旧记忆、审计学到的技能、约束自修改，并在即时任务成功之外评估长期软件质量。只有这样，自进化编程智能体才可能从“更会刷 benchmark 的代码代理”走向真正可靠、可维护、可部署的软件工程协作者。