本文永久链接 – https://tonybai.com/2026/08/19/self-evolving-coding-agent-harness-map

大家好，我是Tony Bai。

【导读】

我在专栏里手搓复刻极简版 OpenClaw Harness——ReAct 主循环、工具注册表、上下文压缩、错误自愈——本质上都是“写死”的工程约定。但南京大学团队最新发布的综述《Self-Evolving Coding Agents》提出了一个更尖锐的问题：这套 Harness 本身，能不能在跑任务的过程中自己进化？论文系统梳理了这一新兴方向，把“进化对象”拆成框架、记忆、技能工具、模型、工作流拓扑五大类，并给出了“何时进化”、“靠什么证据进化”的坐标系。这篇文章带你读透这篇综述，并回头看看，专栏里挖的那些坑，最新的学术界给出了什么答案。

【文章要点】

  • Coding Agent≠自进化 Coding Agent：后者的关键是把编码交互中产生的证据，转化为对未来行为的持久性改动。
  • 五维分类法：框架自进化（Darwin Gödel Machine）、记忆自进化（SWE-Exp）、技能与工具自进化（CODESKILL）、模型自进化（Agent-RLVR）、工作流拓扑自进化（EvoMAC）。
  • 进化的“时机”分三层：任务内（task-time）、任务后（post-task）、阶段性（stage-wise），越往后越慢但越持久。
  • 进化的“证据”分三类：结果证据、环境反馈、轨迹衍生证据——这决定了自进化是“选优”还是“内化经验”。
  • 论文同时泼了冷水：可复现性、反馈可靠性、记忆腐化、评测短视，是这条路线当前最大的四个坑。
  • 结合极简版 Harness 专栏（go-tiny-claw）逐章回看：Context Compaction、错误自愈、Subagent、Benchmark 这几章，最新研究其实已经把“手工版”往“可进化版”推了一步。

我们都在手搓 Harness，但 Harness 会不会自己长大？

过去这段时间，“手搓 Agent Harness”成了一件“热门”的事儿。从 ReAct 主循环、Read / Write / Bash 三件套工具，到基于文件系统的持久化记忆、阶梯降级的上下文压缩——这些工程实践的共同前提是：Harness 是人写出来、调好、然后固定下来的。它会随着人类工程师的迭代而升级，但在两次发版之间，它对每一个任务、每一次失败都是“无记忆”的。

这在软件工程场景里其实很别扭。因为写代码这件事，天然就是一个反馈极其丰富的过程：单元测试会挂、编译器会报错、CI 会红、代码评审会打回。人类工程师从来不会对同一个坑摔第二次跤，但绝大多数 Coding Agent，今天还是会。

南京大学团队在这篇题为《Self-Evolving Coding Agents》的综述里，正是把这件事情摆到了台面上：能不能让 Coding Agent 把每一次编码交互中产生的执行反馈，转化为对未来行为的持久性改动——不管这个改动发生在框架、记忆、技能工具、模型，还是协作结构层面。这类系统被统称为“自进化 Coding Agent”（Self-Evolving Coding Agents）。

这篇综述的价值不在于提出了某个新算法，而在于第一次把这个正在快速膨胀、边界模糊的方向，梳理成了一张可以按图索骥的地图。作为一个刚写完 24 讲 Harness 专栏的人，读完之后最大的感受是：专栏里手写的那套“静态 Harness”，其实每一章背后，学术界都已经在悄悄推进“让它自己进化”的版本。

先把概念理清楚：三个容易混着说的词

在展开分类法之前，论文先划了一条边界线，这条线其实决定了后面所有讨论的范围。

  • Coding Agent（编码智能体）：能在软件工程环境里“行动”的系统——检查仓库、调用工具、执行命令、跑测试、生成补丁。SWE-agent、OpenHands 是这一类的代表，但它们在部署之后，模型、提示词、工具接口、记忆机制基本是固定的。
  • 通用自进化 Agent（General Self-Evolving Agents）：不局限于编码场景，强调“智能体能基于自身执行轨迹和环境反馈修改自己的行为或内部组件”，反馈来源可以是文本评价、奖励信号、任务结果，改动对象可以是提示词、记忆、工具、策略或架构。Reflexion、ExpeL、AGENT KB 是典型代表。
  • 自进化 Coding Agent（Self-Evolving Coding Agents）：二者的交集，但不是简单叠加。它的独特之处在于，反馈来源是可执行的软件制品——单测、编译诊断、运行时报错、CI 日志、代码评审，这些证据比通用场景里的文本评价更具体、更可重复，但也更容易“过拟合”到某个仓库或某条测试用例上。

论文用一张表把这三者的边界划定了：

概念 核心思路 反馈来源 改动对象
Coding Agent 在软件工程流程中行动 工具输出、测试、用户指令 任务状态、生成的补丁
通用自进化 Agent 跨任务 / 跨环境适应行为 文本反馈、奖励、任务结果 提示词、记忆、工具、策略或架构
自进化 Coding Agent 通过编码经验适应软件工程行为 仓库、测试、CI、日志、评审的可执行反馈 仓库记忆、编码技能、工作流、策略或脚手架本身

一句话总结：普通 Coding Agent 只是在“用”反馈修补当前这个 Bug，自进化 Coding Agent 是在“攒”反馈，把它变成能穿越到下一个任务的资产。

五维分类法：进化对象拆开来看

这是全文的骨架。论文没有把“自进化”当成单一技术，而是按“到底改动了 Agent 系统的哪一部分”分成五类，并强调这五类并不互斥——一个系统完全可能同时进化多个对象。

框架自进化（Agent Framework Self-Evolution）

最激进的一类：智能体把自己的实现代码当作可修改对象。

  • A Self-Improving Coding Agent（SICA）：给 Agent 配上基础的软件工具，让它直接编辑自己的代码库，探索新的提示词方案或工具，再用编码基准验证结果。
  • SIFT：延续“脚手架级自改”的思路，但用 LLM-as-a-judge 加轻量树搜索，避免每个候选改动都要完整跑一遍评测，提升采样效率。
  • Darwin Gödel Machine / Mendel Gödel Machine / Huxley Gödel Machine：这一系列把自改进过程建模成对多个可执行 Agent 变体的开放式演化，维护一个“变体档案库”，研究如何在谱系之间选择、继承和评估自我修改。

这一类的风险也最直接：改的是“生成未来行为的机制本身”，一次有害的框架修改可能直接搞垮整个 Agent 循环，甚至学会钻评测框架的空子。论文特别强调，框架自进化需要的不只是性能驱动的搜索，还要有验证、回滚和鲁棒性检查机制。

记忆自进化（Memory Self-Evolution）

记忆自进化不是简单地把交互历史存起来，而是持续构建、提炼、复用一个记录软件工程经验的显式记忆组件。

  • SWE-Exp：从历史 Issue 解决轨迹（包括成功和失败的修复尝试）中构建“经验库”，让 Agent 复用之前的定位策略、补丁决策和失败教训。
  • Repository Memory（仓库记忆）：不把仓库当作静态输入上下文，而是从历史提交、关联 Issue、高频修改区域的功能摘要中构建记忆，用于支持未来的代码定位任务——这是软件工程独有的记忆形态，绑定在代码库的时间结构上。
  • EvoRepair：把这套思路专门化到漏洞修复场景，在一个漏洞内部积累修复经验，并跨漏洞复用，形成领域感知的知识库而非通用交互记录。
  • SAGE：把一次初始 rollout 提炼成一个简洁的“计划”，作为后续执行的上下文引导——一种轨迹衍生的记忆形态。

论文提醒了一个很容易被忽视的问题：记忆自进化的关键挑战不是“存得更多”，而是“存得对”。噪声日志、误导性测试、脆弱补丁、仓库特有的约定，都可能生成一旦被无差别检索就会拖累后续表现的“坏记忆”。

技能与工具自进化（Skill and Tool Self-Evolution）

如果说记忆记录的是“发生了什么”，技能和工具记录的是“下次该怎么做”。

  • CODESKILL：从编码轨迹中提炼、演化、维护一个技能库，粒度分两层——任务级技能（如何检查仓库、如何验证修复）和事件驱动技能（对命令失败、测试输出模式等重复性事件的局部响应）。技能管理本身被建模成一个可学习的策略，用评分反馈 + 下游可验证执行反馈共同驱动。
  • GSkill（Automatically Learning Skills for Coding Agents）：为目标仓库学习“技能文档”——架构说明、编码规范、测试流程、常见坑点——本质上是给 Agent 自动生成的仓库 onboarding 文档，通过 SWE-smith 生成可验证任务，再用演化优化循环迭代技能内容。
  • Socratic-SWE：把历史求解轨迹当作训练信号而非用完即弃的中间产物，蒸馏出一个“Agent 技能注册表”，用来指导针对性修复任务的生成，再反过来训练求解器——这是技能自进化和策略级自进化的交叉地带。
  • Live-SWE-Agent：从一个只有 bash 的极简脚手架出发，在解决仓库级 Issue 的过程中动态创建和修订自己的工具（编辑器、代码搜索工具、领域专用分析器），是目前工具自进化里最贴近“在线”自进化的例子。

模型自进化（Model Self-Evolution）

这一类改动的是模型侧组件本身——基座模型、适配器、策略、奖励模型或验证器。论文划了一条清晰的边界：普通的后训练成为“自进化”，仅当软件特定的经验被反馈进了那些决定未来行为的模型侧组件。

  • Self-play SWE-RL：让 Agent 自己在真实仓库里制造 Bug、尝试修复，用可执行验证的结果去训练后续的求解器——环境不再只是评测工具，而是学习闭环的一部分。
  • Agent-RLVR：Agent 先产出轨迹，获得引导和环境奖励，再用引导后的重新尝试更新策略。
  • CURE / ZeroCoder / Sol-Ver / ACE：这几篇都是“生成器与验证器共同演化”的思路——程序员角色和单测生成角色互相博弈，用可执行的分歧作为训练信号，而不是把验证当成固定的裁判。

这里论文也做了一次“祛魅”：像 SWE-RL 这样用软件演化数据训练推理能力的工作，更准确的定位是“面向 SWE 的模型优化”，除非训练信号真正闭环在 Agent 自身不断演化的尝试上，否则不算严格意义上的自进化。

工作流与拓扑自进化（Workflow and Topology Self-Evolution）

这一类把“进化对象”从单个组件提升到了整个 Agent 系统的组织方式——角色分工、通信路径、协作拓扑。

  • SEMAG：根据任务难度动态协调规划、编码、调试、讨论等角色，模型选择本身也可以随可用的编码后端演化。
  • EvoMAC：把软件开发团队建模成一个“多智能体协作网络”，用文本环境反馈、单测验证和文本反向传播来更新智能体和连接关系。
  • SEW / AFlow / EvoAgentX：把整个智能体流程表示成一张图，节点是规划、生成、重写、评审、测试、调试，边是信息流和执行顺序，用蒙特卡洛树搜索或执行反馈来搜索最优工作流拓扑。
  • AgentConductor：面向竞赛级代码生成，生成任务自适应、密度感知的通信 DAG——简单任务少讨论，难任务多协作，用执行反馈显式权衡协作开销。

这一类的风险同样值得警惕：演化出的工作流可能过拟合基准反馈，增加不必要的协调开销，或者为了通过测试而牺牲可维护性。

进化的“时机”与“证据”：两条正交的坐标轴

分类法回答了“改什么”，论文还补充了两个正交视角：什么时候改，靠什么改。

三种进化时机

  • 任务内进化（Task-time）：任务还没做完，测试失败、编译报错就已经触发了当下策略的调整。最快、最局部，代表如 Live-SWE-Agent 的在线工具创建、SEMAG / AgentConductor 的动态协作结构调整。
  • 任务后进化（Post-task）：一条轨迹跑完之后，把结果抽象成记忆、技能、仓库知识或修复经验，供未来任务复用。SWE-Exp、Repository Memory、CODESKILL、GSkill 都属于这一档，速度慢一些，但持久性更强。
  • 阶段性进化（Stage-wise）：等一大批验证过的轨迹、自对弈任务、仓库交互结果积累到一定规模后，才触发对模型策略或 Agent 变体档案库的更新。Self-play SWE-RL、Agent-RLVR、Darwin Gödel Machine 家族都在这一档，最接近“跨代”意义上的自我提升，但也最依赖训练环境和验证器的可靠性。

三类证据

  • 结果证据（Outcome Evidence）：基准通过率、测试通过率、修复成功率——粗粒度但提供了明确的选择压力，决定哪个 Agent 变体 / 工作流 / 策略该被保留。
  • 环境反馈（Environmental Feedback）：命令输出、编译诊断、运行时异常、失败的测试日志——更局部，暴露的是“策略在哪个中间环节卡住了”，是任务内进化和工具创建最主要的证据来源。
  • 轨迹衍生证据（Trajectory-Derived Evidence）：来自一条完整轨迹的记录——仓库检查、故障定位、工具调用、文件编辑、失败分支、恢复步骤——最难处理，但最适合被抽象成记忆和技能，因为它揭示的是“怎么发生的”而不只是“发没发生”。

论文的判断很实在：结果证据擅长“选优”，环境反馈擅长“即时纠偏”，轨迹衍生证据擅长“沉淀经验”。三者不是互相替代关系，而是共同构成了一个自进化系统的证据供应链。

怎么评测一个会“进化”的 Agent

传统 Coding Agent 评测已经有 SWE-bench 系家族（SWE-bench、SWE-bench Verified、SWE-Bench Pro）撑起了仓库级 Issue 解决这个主战场，也有 HumanEval、MBPP、LiveCodeBench 这类函数级 / 竞赛级基准做补充。但论文指出，对自进化 Coding Agent 来说，光看最终 pass rate 是不够的——一个分数变高的系统，你根本看不出这个提升是来自记忆、技能、工作流改动，还是模型侧适配。

因此论文建议评测至少要往三个方向补齐：

  1. 暴露进化过程本身：是否追踪了 Agent 改动在成本 / 时间约束下是否真的带来了提升（如 SICA），是否维护了可比较的变体档案（如 Darwin Gödel Machine）。
  2. 效率与开销：自进化往往意味着额外的搜索、重复执行、检索、轨迹存储或模型更新，成本、运行时、Token 消耗、检索开销都该被单独报告。
  3. 跨场景泛化：演化出的能力能不能迁移到没见过的仓库、新基准、不同模型甚至不同编程语言——这一点目前证据最弱。

论文没有回避的四个坑

一篇负责任的综述，应该谈问题多过谈成绩。这篇论文专门用一整节列出了当前最突出的四类挑战：

  • 可复现性、数据污染与基准过拟合：自进化系统天然难复现——Agent 会随运行、任务、仓库、工具环境甚至模型版本本身变化，用基准结果去选自我修改的系统对评测噪声和基准泄露格外敏感。
  • 反馈可靠性、安全性与工具依赖：测试、编译器、CI 日志、生成的单测、学习出来的奖励模型都不完美。当 Agent 修改的是工具、工作流甚至自身脚手架时，一次误导性反馈影响的不再是一次输出，而是未来所有行为。
  • 长期记忆、技能与多智能体协调：经验库、仓库记忆、技能库都可能变得陈旧、冗余、过度仓库特化，或被失败轨迹污染；演化中的角色分工和通信拓扑也会带来额外的成本、不稳定性和责任模糊问题。
  • 超越短基准的评测：现有评测大多只看短期 pass rate / resolve rate，但真实软件工程还要求可维护性、安全性、可评审性、长期可靠性；“自进化能力是否能迁移到非编码领域”这个问题目前基本是空白。

论文的结论很克制：这个方向要走向真正可信，需要的不只是让 Agent“学会进化”，而是让“进化过程本身”变得可验证、可审计、可约束。

回到专栏：我们埋的坑，学术界给出了什么新答案

写完 24 讲 Harness 专栏之后再读这篇综述，最大的收获是能对上号——专栏里很多章节讨论的是“怎么把 Harness 做对”，而这篇综述讨论的是“怎么让 Harness 做对之后，自己变得更对”。挑几个直接相关的章节做个串讲：

  • 第 12 讲《突破内存：基于阶梯降级的 Context Compaction 策略》 —— 我们讨论的是“怎么在单次会话里优雅地丢信息”，本质上是任务内的临时压缩。而论文里的 Repository Memory 和 SWE-Exp 给出的是另一条路：与其在压缩时丢掉，不如在任务结束后把有价值的部分提炼成跨会话的持久记忆，下次遇到相似 Issue 直接检索复用，而不是重新探索一遍仓库。压缩解决的是“装不下”，记忆自进化解决的是“不用重新学”，两者其实是互补关系。

  • 第 14 讲《错误自愈：上下文感知的 Error Recovery 提示模板注入机制》 —— 专栏里做的是“针对特定错误模式，注入预设的恢复提示词”，本质是人工穷举的静态规则库。论文里的 CODESKILL 的“事件驱动技能”和 Socratic-SWE 的 Agent Skill Registry，则是把这件事变成了一个自动化闭环：从大量失败轨迹里自动挖掘“命令失败 / 测试输出模式 / 重复报错”对应的有效应对策略，再持续更新技能库——相当于把第 14 讲的“提示模板”从人工维护升级成了自动学习。

  • 第 17 讲《任务委派：引入 Subagent 隔离复杂探索任务的上下文瓶颈》 —— 专栏关注的是“何时该拆出子智能体”这个静态设计决策。而工作流与拓扑自进化这一支——EvoMAC、SEMAG、AgentConductor——研究的正是“协作结构本身能不能根据任务难度自动伸缩”：简单任务少开子智能体、少讨论，复杂任务才动态拉起更密集的协作拓扑，用执行反馈决定要不要维持这条协作路径。这给 Subagent 设计提供了一个可以对标的进阶方向：从“人工划定何时委派”走向“系统自己学会何时委派”。

  • 第 20 讲《科学度量：如何构建 Benchmark 自动化评估脚本》 —— 专栏关注的是怎么给单次 Harness 版本打分。论文第五节则提醒了一层更深的坑：如果评测对象是一个会自我修改的系统，用来筛选自我修改的基准信号本身也可能被“钻空子”（如 Darwin Gödel Machine 系列面临的基准过拟合风险）。这意味着自进化 Harness 的评测脚本，除了要测“这一版好不好”，还得测“筛选自我修改的机制本身有没有被过拟合”。

  • 第 15 / 16 讲（System Reminders 防死循环、Middleware 高危命令拦截） —— 这两讲讨论的是运行时的行为干预机制，本质是防止 Agent 在单次任务内失控。论文第六节提到的“反馈可靠性与安全性”问题，把这个担忧扩展到了更长的时间尺度：如果 Agent 能修改自己的脚手架或工具，一次误导性反馈可能造成的不是单次任务失控，而是未来所有任务的行为漂移——这对 Middleware 拦截机制提出了更高的要求：不仅要拦截高危命令，还可能需要拦截“高危的自我修改”。

如果用一句话概括这次串讲：专栏搭的是一套“人工调优、版本发布”式的 Harness，而这篇综述指向的是下一步——让 Harness 里那些原本靠工程师手动迭代的部分（记忆策略、错误恢复规则、协作拓扑、甚至脚手架代码本身），逐渐变成可以被执行反馈自动驱动的进化对象。

这不代表专栏里的工程实践过时了——恰恰相反，framework/memory/skill 这些“进化对象”的边界，正是靠这些手工 Harness 先趟出来的；自进化研究要做的，是在这些边界清晰之后，把“什么时候改、靠什么改、怎么验证改得对不对”这套机制给系统化。

写在最后

这篇综述最有价值的地方，不是列了多少篇论文（虽然作者维护的 Awesome-Self-Evolving-Coding-Agents 仓库已经收录了几十篇），而是提供了一套坐标系：改什么（五维分类）、什么时候改（三种时机）、靠什么改（三类证据）、怎么验证改得对不对（评测与四大挑战）。

对于正在手搓 Harness 的工程师来说，这套坐标系的实际价值在于——它把“要不要给 Agent 加一个记忆模块 / 技能库 / 动态工作流”这类工程决策，从“感觉需要”变成了“可以按图索骥去对照现有方案的利弊”。自进化 Coding Agent 这条路线现在还很年轻，坑也和机会一样多，但至少现在，我们有了一张地图。

论文与资源：

  • 论文原文：Self-Evolving Coding Agents, arXiv:2608.03392 - https://arxiv.org/abs/2608.03392
  • 论文集合仓库：github.com/zhouhao1024/Awesome-Self-Evolving-Coding-Agents

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。