先说结论：Agent 自进化真正进化的，通常不是模型本身，而是模型外面的 harness（运行外壳，即承载上下文、工具、记忆、流程的那层系统）。
过去一段时间，我一直在看 Agent 自进化相关的论文和系统，也在自己的项目里做了一些记忆、评估和 evolve 机制的尝试。
一开始我以为这个问题的核心是：Agent 怎么学会新东西？后来发现，更准确的问题应该是：Agent 的哪些部分可以被更新？这些更新如何被验证？以及，更新之后到底有没有让未来任务变好？
这几个问题把我带到了上面那个判断。下面展开说为什么。
Agent 不只是模型#
过去讨论 Agent，很容易把能力归因到模型上。
模型更强，所以 Agent 更强。模型会推理，所以 Agent 会规划。模型会调用工具，所以 Agent 能完成任务。
但真实系统跑久了以后会发现，Agent 的稳定性并不只取决于模型。很多失败不是模型完全不会，而是系统没有给它一个足够好的工作环境。
- 它有没有长期记忆？
- 它能不能看到之前失败的证据？
- 它调用工具时有没有权限边界？
- 它写完结果后有没有验证？
- 它失败后能不能定位是哪一层出了问题？
- 它能不能把成功经验沉淀下来，下次复用？
这些东西都不在模型权重里，而在模型外部的系统结构里。
所以现在更合理的理解是：
Agent = Model + Harness模型负责理解、推理、生成和判断。Harness 负责上下文、工具、记忆、权限、工作流、验证、轨迹和反馈。
没有 harness，模型只是一次性生成器。有了 harness，模型才变成可以行动、可以恢复、可以复盘、可以持续改进的 Agent。
Harness 到底是什么#
Harness 这个词容易被误解成“胶水代码”。但在 Agent 系统里，它远不只是把模型和工具接起来。
一个成熟的 harness 至少包括几类东西。
第一类是 prompt 和 instruction。它们定义 Agent 的目标、角色、边界、输出格式和行为习惯。
第二类是 memory 和 context。它们决定系统能记住什么、忘掉什么、什么时候召回历史经验、如何把经验注入当前任务。
第三类是 tools 和 APIs。它们让模型不只是说话，而是能搜索、读写文件、运行命令、访问数据库、调用业务系统。
第四类是 skill 和 workflow。它们保存可复用的任务流程，比如如何做代码审查、如何写研究报告、如何分析一次失败轨迹。
第五类是 workspace 和 artifacts。复杂任务不能只靠上下文窗口完成。中间笔记、日志、草稿、测试结果、报告、轨迹，都需要外部化到文件或结构化状态里。
第六类是 policy 和 sandbox。Agent 能做事，就必须有边界。哪些路径能写，哪些命令能跑，哪些工具需要确认，哪些权限不能被自动扩大，都应该由 harness 控制。
最后是 evaluation 和 observability。如果没有 trace、span、score、diff、case result 和 regression signal，系统就不知道自己为什么失败，也不知道改动是否真的有效。
这些组件合起来，才是 Agent 的真实运行环境。
自进化到底在进化什么#
如果接受 Agent = Model + Harness，那么自进化的对象就不再只是模型权重。
更现实的自进化，是在优化 harness 的不同部分。
比如 prompt evolution：系统根据成功和失败轨迹，修改提示词和策略文本。
比如 memory evolution：从 badcase、用户反馈和执行轨迹中抽取经验，合并重复记忆，修订过时记忆，删除低价值记忆。
比如 skill evolution：把多次成功的操作路径沉淀成可复用 skill，让 Agent 下次不用从零探索。
比如 tool evolution：改进工具描述、参数约束、错误处理和 wrapper，让模型更容易正确调用工具。
比如 workflow evolution：调整任务拆解、检索、执行、验证、重试和停止条件。
还有 workspace evolution：让 Agent 在外部文件系统里积累假设、日志、反例和回归测试，而不是把所有状态塞进上下文窗口。
这些方向看起来不同，但本质都是一件事：让模型外部的执行系统变得更适合未来任务。
几类典型方法#
现在很多自进化方法，都可以放进这个 harness-centric 框架里理解。它们的区别不在于“谁更像真正的自我进化”，而在于优化的是 harness 的哪一层，以及更新如何被验证。
GEPA：从轨迹反馈中演化 Prompt#
论文：GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning（arXiv:2507.19457）
GEPA 代表的是 prompt / 策略演化（prompt / strategy evolution）。
它的核心不是让模型凭空“反思一下”，而是把一次执行中的自然语言轨迹变成优化信号。系统会读取 reasoning、tool calls、tool outputs、compiler errors、rubric feedback 等文本反馈，判断当前 prompt 的哪一部分导致了成功或失败，然后生成新的 prompt 候选。
这里进化的不是模型权重，而是 compound AI system 里的 module prompts。GEPA 每轮只选择一个模块 prompt 做 mutation，再用反馈集和 Pareto candidate selection 保留不同样本上表现好的候选。
这说明一件事：在有丰富文本反馈的 Agent 系统里，语言本身就是一种高带宽的优化介质。相比只从稀疏 reward 学习，把轨迹和错误信息直接转成 prompt 更新，往往更符合 LLM 系统的工程现实。
SkillOpt：把 Skill 当成可训练的外部状态#
论文：SkillOpt: Executive Strategy for Self-Evolving Agent Skills（arXiv:2605.23904）
SkillOpt 优化的是 skill 文档。
它的出发点是：如果一个 skill 承载的是工具使用策略、任务流程和领域经验，那它就不应该只是一次性手写 prompt，而应该像模型参数一样被训练。
它的训练过程大致是：
run tasks
-> collect trajectories
-> analyze successes and failures
-> propose textual edits
-> validate edits on held-out set
-> update best_skill.md这里的关键不是“模型自己改了几句话”，而是整个更新过程被验证集、rejected-edit buffer、textual learning rate 和 epoch-wise update 约束住。
最终部署的不是一个更大的模型，而是一个更好的 best_skill.md。这很符合 harness evolution 的思路：把程序性经验沉淀成外部可读、可审计、可迁移的 artifact。
Agentic Harness Engineering：把 Harness 组件显式化、可观测化、可修改化#
论文：Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses（arXiv:2604.25850）
Agentic Harness Engineering 更系统化。
它不只优化 prompt，也不只优化 skill，而是把 coding agent 外围的 harness 拆成多个可观察组件：
- system prompt
- tool description
- tool implementation
- middleware
- skill
- sub-agent configuration
- long-term memory
然后系统通过真实任务轨迹分析失败模式，让 evolution agent 修改对应组件。
它最重要的贡献不是“让 agent 自己改代码”，而是提出了三层 observability：
Component observability:
知道哪些 harness 组件可以被修改。
Experience observability:
把大量执行轨迹整理成可导航、可检索、可消费的 evidence corpus。
Decision observability:
每次修改都记录改了什么、为什么改、预期修复什么、可能引入什么回归。这让 harness evolution 不再是“看日志凭感觉调 prompt”，而是更接近一个可复盘、可回滚、可归因的工程循环。
Meta-Harness：直接搜索完整 Harness Code#
论文：Meta-Harness: End-to-End Optimization of Model Harnesses（arXiv:2603.28052）
Meta-Harness 把优化对象进一步扩大到完整 harness code（包在模型外面的整段程序）。
在这个框架里，harness 不只是 prompt 或配置，而是包在 LLM 外面的 Python 程序：它决定模型看到什么上下文、如何更新 memory、怎么检索、怎么构造 prompt、怎么调用工具、怎么处理环境反馈。
系统会保留每个候选 harness 的代码、分数、执行轨迹、失败日志、prompt、model output、tool call、成本和延迟。新的 proposer 可以像工程师一样查看历史版本、分析哪个 case 退化、定位是 retrieval、memory、prompt 还是 control flow 出了问题，再提出新的 harness code。
这类方法把 harness engineering 从人工经验调参，推进到了外循环搜索问题。
这些方法的共同点#
这些方法表面上差异很大：
- GEPA 改 prompt。
- SkillOpt 改 skill。
- Agentic Harness Engineering 改多类 harness 组件。
- Meta-Harness 改完整 harness code。
但它们的共同点很清楚：
不直接改模型权重。
把执行轨迹变成反馈。
把反馈转成外部 artifact 的修改。
再用评估决定修改是否保留。这也是为什么我更倾向于把 Agent 自进化理解为 harness evolution，而不是 model self-improvement。
Updating 不等于 Benefit#
这一节的框架来自论文 Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents（arXiv:2605.30621），它把自进化能力拆成“能不能更新”和“更新有没有用”两层来分别评估。
这里有一个很重要的区分：
Harness updating != Harness benefit
（系统会改自己 != 改完真的更好）系统会更新，不代表系统真的变好了。
- 能写入记忆，不等于答案变好。
- 能召回经验，不等于模型用对了经验。
- 能修改 prompt，不等于未来任务更稳。
- 能生成 patch，不等于系统真的进化。
我自己做记忆和 evolve 机制时，对这一点感受很深。
有时经验确实被写进去了，也能在相似 query 下召回，但最终答案没有明显变好。原因可能是经验太宽、边界不清，或者模型只是把它当背景文本看了一眼。
有时 evolve 能生成候选，也能通过局部训练样本，但到了 selection 或相邻任务族上反而退化。它不是没学到东西，而是学到的策略适用边界太窄。
所以自进化至少要拆成两层看：
Updating capability:
系统能不能根据反馈产生修改。
Benefit capability:
这些修改能不能在未来任务中稳定产生收益。很多系统停在第一层，看起来会总结、会写记忆、会改 prompt、会产出候选，但没有证明第二层成立。
这也是为什么自进化不能只看“有没有更新动作”，而要看答案前后的真实差异（answer delta）、按任务族切分的表现（task-family split）、不容退化的保护集（protected set）、回归（regression）、回滚（rollback）和长期收益。
一个更可靠的闭环#
我现在更相信的自进化闭环大概是这样：
run
-> trace
-> failure attribution
-> proposal
-> controlled patch
-> train / selection / protected eval
-> accept or reject
-> deploy or rollback
-> continue collecting evidence第一步是运行任务，留下完整轨迹。没有轨迹，就没有归因。
第二步是失败归因。要判断问题到底在 prompt、memory、tool、workflow、policy、evaluator，还是任务本身。
第三步是生成 proposal。注意这里应该是提案，不应该直接改生产系统。
第四步是受控 patch。修改对象必须有边界，哪些文件能改、哪些字段不能改、哪些权限不能扩大，都要提前定义。
第五步是评估。不能只看训练样例（train case），也要看选择集（selection）、留出集（held-out）、保护集（protected set）和关键任务族。
最后才是接受、拒绝、部署或回滚。
这套流程听起来没有“自我进化”那么性感，但它更接近真实工程系统需要的东西。
自进化首先是治理问题#
Agent 自进化最吸引人的想象，是系统能从经验中学习，越用越好。
这个方向当然值得做。但如果没有边界，它也很容易变成新的技术债来源。
- 记忆会堆积。
- 规则会互相覆盖。
- prompt 会越来越长。
- workflow 会越来越复杂。
- 局部优化会伤害其它任务。
- 评估器会被讨好。
- 错误经验会被长期固化。
所以自进化不是让 Agent 自由修改自己，而是在明确边界内，基于高质量反馈，持续优化可变组件，并稳定证明这些改动值得保留。
换句话说，自进化首先是反馈、评估和治理问题，其次才是算法问题。
真正有价值的 Agent 自进化，不是系统看起来一直在变，而是它能回答三个问题：
- 这次为什么要改？
- 改了什么？
- 有什么证据说明它真的变好了？
如果回答不了这三个问题，那就不是进化，只是自动变动。
参考#
- GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning — arXiv:2507.19457
- SkillOpt: Executive Strategy for Self-Evolving Agent Skills — arXiv:2605.23904
- Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses — arXiv:2604.25850
- Meta-Harness: End-to-End Optimization of Model Harnesses — arXiv:2603.28052
- Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents — arXiv:2605.30621