过去几十年的人工智能发展，主要围绕大规模训练这一范式展开：通过更多数据、更大模型和更多计算资源，在训练阶段获得更强的智能能力。然而，基础模型在部署到真实环境后仍然面临一个关键限制——模型参数在训练完成后基本固定，无法根据持续交互中的反馈主动学习和调整自身行为。

因此，尽管 Foundation Model 具备强大的知识和推理能力，本质上仍是一种一次训练、持续使用的静态智能形态。它能够根据输入生成结果，却缺少跨任务、跨时间的经验积累和自我优化能力。

Agent 的出现推动人工智能系统从静态能力调用走向动态能力演化。不同于仅依赖模型参数的 Foundation Model，Agent 以基础模型作为认知核心，通过 Harness 连接环境、工具和长期状态。Harness 中的 Prompt、Memory、Skill、Tool、Workflow 和 Control Logic 等组件，共同决定 Agent 如何理解任务、规划行动、调用工具以及利用历史经验。

在真实运行过程中，Agent 的每一次任务执行都会产生大量可用于改进的反馈信号，包括任务轨迹、工具调用过程、成功与失败模式、环境反馈以及用户评价等。当系统能够从这些运行经验中发现问题、提炼知识，并进一步优化自身 Harness 结构和执行策略时，Agent 就不再只是完成任务，而是能够通过实践持续提升能力。

这种从执行任务到从任务中学习，从一次性智能到持续进化智能的转变，构成了 Agent Self-Evolution（自主进化）的核心范式。

从 Agent 到自主进化

Agent 自主进化定义

一个自我改进的智能体能够主动利用由自身执行时产生的反馈信号——例如交互结果、评判、验证结果或候选修改，来持久地进化其底层的计算组件，从而形成"经历 → 反思 → 进化 → 再验证"的内源性闭环。依据被改进的对象是什么，Agent 自主进化方法目前被划分为两条主要路径：

1. 基础模型 FM 改进（Foundation Model Improvement）：改进的对象是模型最核心的部分-神经网络的权重  。即通过 SFT、强化学习（RL）、蒸馏（Distillation）、持续学习（Continual Learning）等方式，将运行过程中产生的高价值经验写回模型参数。更新成本高，训练周期长，但对模型能力影响更加深远，一旦完成，能力提升可以长期保留。
2. 脚手架改进（Scaffolding / Harness Improvement）：通过非参数化变更，将运行时脚手架（即 Harness）从  更新为  。

提示/系统指令、 记忆及其检索/更新策略、 工具集+调用接口、 路由/调度/安全等控制逻辑。相比模型参数更新，Harness 进化修改成本更低，迭代速度更快，更适合在线环境持续优化。

在 The What & When of Self-Evolving Agents^[1]技术报告中，除了这两条主要进化路径，还增加了一个更新层面：外部文件（external files），即外部可编辑产物，例如 Artifacts 产出物（如代码/论文/算法…）、记忆库、经验文档、需求产物、CLAUDE.md、AGENTS.md、Skills（说明：简单的 Skill 作为可持久化经验属于 External files；当 Skill 进一步包含执行逻辑、工具编排和行为约束时，则成为 Harness 的可演化组件）。

当前 Agent 的进化已突破单一层级，模型、Harness 与外部可编辑文件三者的传统边界正逐渐消融，形成深度的相互反哺机制。Harness 在运行过程中积累的经验可以沉淀为高质量训练数据，同时推动训练流程和训练基础设施的优化；经过增强的模型能力又能够反向提升 Harness 的自我优化能力，进一步产出更高质量的 Artifacts 等外部文件。这些新的能力资产又会成为 Harness 的工具和知识来源，持续增强 Agent 的执行能力。最终，模型、Harness 与 Artifacts 三个层面形成闭环演进，共同推动 Agent 能力持续提升。

以下内容围绕 Agent 自进化领域的前沿技术方向展开介绍，重点梳理近期的具有代表性的研究工作，提炼其中的核心技术思路与发展趋势，为后续自主进化算法的工程落地和持续探索提供参考。

Harness 自进化

Harness 工程被视为支撑 Agent 持续进化的基础设施，涵盖工具编排、安全护栏、持久化记忆、验证循环、可观测性等多层，负责捕获执行轨迹（traces）、路由行为决策（actions）、提供反馈信号（feedback），并管理运行过程中不断变化的信息。

在真正进行模型参数更新之前，Agent 可以优先通过运行时层面的改进，将交互经验沉淀为可复用的 Workflow、Skill、Memory 以及更丰富的执行环境能力。只有当这些经验经过持续验证，证明具备稳定性、泛化性和长期收益后，才进一步考虑将其固化到模型参数中，实现更深层次的能力提升。

联合进化

Harness 联合进化主要包含三个关键环节：

1. 全面观测与定位：通过 Trace、执行状态等数据，定位影响性能的关键 Harness 组件。
2. 生成修改方案：将诊断结果转化为 Prompt、Workflow、Tool、Memory 等组件的可执行修改。
3. 验证与闭环：通过自动化评测和回归验证筛选有效修改，形成持续进化闭环。

这一方向的重要意义在于：Agent 能力提升不再完全依赖更大规模的模型，而是通过优化外围认知结构，将部分复杂能力迁移到 Harness 层，使小模型也能获得强大的任务执行力。

代表性研究：

该工作指出 Agent 的性能瓶颈已经不再完全来自基础模型能力，而越来越依赖于外围 Harness 的设计，包括任务规划流程、工具调用策略、上下文管理、执行控制以及反馈机制。论文提出 Agentic Harness Engineering（AHE）框架，通过 Observability-driven Evolution机制，使 Harness 能够基于自身运行经验持续优化。整体框架包含三个核心环节：

• Component Observability将 Harness 中可影响 Agent 行为的关键组件显式化，包括 Prompt、工具配置、执行流程和控制逻辑等，使 Agent 能够定位优化对象并进行针对性修改；
• Experience Observability收集 Agent 执行过程中的轨迹信息，包括任务执行路径、工具调用记录、错误模式以及最终结果，将运行经验转化为可用于优化的反馈信号；
• Decision Observability记录 Harness 修改过程中的优化假设、变更内容和预期影响，并结合后续任务结果验证修改效果，从而形成“发现问题—提出改进—执行验证—保留有效策略”的闭环进化过程。

AHE 在 Terminal-Bench 2 等 Coding Agent Benchmark 上验证了 Harness 自主进化的有效性。经过多轮自动演化后，Agent 的 pass@1 从 69.7% 提升至 77.0%，超过人工设计 Harness 以及其他自进化方法，证明了 Harness 层面的持续优化能够显著增强 Agent 能力。

进一步分析表明，演化后的 Harness 并非针对单一 benchmark 的过拟合策略，而是能够迁移到不同任务和基础模型中，在 SWE-bench-verified 以及多个模型族上继续带来性能收益。此外，消融实验发现，性能提升主要来源于工具、Middleware 和长期记忆等结构化 Harness 组件，而非简单的 System Prompt 调整。这说明 Agent 自主进化的关键不仅在于优化语言指令，更在于让外围认知系统能够从运行经验中持续演化。

由 Carnegie Mellon University（CMU）团队提出，从 Agent 系统工程角度探索了一个重要问题：提升 Agent 能力是否一定依赖更大规模的基础模型。作者提出，Agent 的最终表现不仅由模型参数决定，也受到围绕模型构建的 Harness 影响，包括系统提示（System Prompt）、工具配置（Tool Specification）、任务规划流程（Workflow）、上下文管理以及记忆机制等。一个针对大模型设计的 Harness 并不一定适用于小模型，因此通过自动优化 Harness，可以进一步释放小模型的 Agent 能力。

该工作将 Harness Adaptation 建模为一个由任务反馈驱动的自动优化过程。对于给定的模型、任务和初始 Harness，系统首先运行 Agent 并收集执行轨迹，包括中间决策、工具调用、环境反馈以及最终任务结果。随后分析失败轨迹，识别导致任务失败的关键因素，并将问题归因到具体 Harness 组件。

基于失败分析结果，系统自动生成候选 Harness 修改方案，包括 Prompt 优化、工具描述增强、Workflow 调整以及上下文策略改进等。每一次修改都被视为一个新的 Harness 版本，并通过 Benchmark 进行回测，根据任务成功率等指标判断该版本是否有效，从而形成持续迭代的优化闭环。

与传统人工 Prompt Engineering 不同，该方法将 Harness 从静态工程配置转变为可优化对象，通过 Agent 自身运行经验发现系统瓶颈，并自动探索更适合当前模型和任务分布的 Harness 结构。

实验方面，论文构建了覆盖多个业务场景的 Agent Benchmark，包括考勤审计、预算审批、库存管理、异常检测、网站管理以及代码重构等任务，并在多个小模型上验证 Harness Adaptation 的有效性。实验共覆盖 7 类任务和 3 个小模型系列，在 21 个 task-model 组合中，自动优化后的 Harness 在 16 个组合上取得性能提升，其中部分任务能够显著缩小小模型与大模型 Agent 的性能差距。最佳结果显示，小模型 Agent 在优化 Harness 后可以达到大模型约 89.7% 的任务表现，同时推理成本降低约 96%。

进一步分析表明，Harness 优化的收益并非简单来自更长的 Prompt，而是通过针对模型能力短板进行结构化调整，将部分原本依赖模型规模的能力迁移到外部认知结构中。例如，通过增加规划、验证、工具约束以及上下文组织机制，可以有效弥补小模型在复杂任务执行中的不足。

Self-Harness 提出了一个类似的视角：Harness 不应只是固定的运行框架，而应该成为能够观察自身行为、发现问题并自动改进的软件系统。 同样将 Agent 运行过程中的执行轨迹（Trace）、反馈信号和任务结果作为优化依据，通过分析系统行为找到 Harness 中影响性能的关键因素，并生成针对性的改进方案。

当系统发现失败或低效行为时，它不会简单地针对单个 Bad Case 修改 Prompt，而是进一步分析失败模式背后的根因，自动生成候选 Harness 修改方案，并通过回放测试和评估机制验证修改是否真正提升系统能力，最终将有效改动合并到新的 Harness 版本中。

RHO（RETROSPECTIVE Harness Optimization）同样利用历史运行轨迹自动优化 Agent Harness 的方法。首先从历史任务中选择具有代表性和挑战性的任务样本，而不是简单随机抽取大量数据。随后，系统让当前 Agent 对这些任务进行多次重新执行（Group Rollout），通过比较不同执行过程发现潜在问题：一方面，分析单次执行过程中是否存在明显错误，另一方面，通过比较同一任务不同执行结果之间的差异，发现 Agent 行为是否存在不稳定性（Self-Consistency）。

在识别潜在问题后，RHO 会生成多个候选 Harness 修改方案，系统让不同版本 Harness 在相同任务上重新运行，并通过 Self-Preference 机制判断哪个版本产生的行为更优，从而选择更好的修改方案进行更新。整个过程不依赖人工标注或显式 Reward，而是利用 Agent 自身产生的运行结果作为优化信号。

Prompt 进化

Prompt 是 Agent Harness 中影响模型行为的重要控制组件。传统 Prompt Engineering 主要依赖人工设计和经验迭代，但随着 Agent 执行任务复杂度提升，Prompt 已不再只是简单的任务描述，而逐渐承载任务规划策略、行为约束、工具使用规则以及领域经验。因此，静态 Prompt 难以满足 Agent 长期运行过程中的持续优化需求。

Prompt Evolution 的发展方向正在从“自动生成更好的 Prompt”转向“让 Agent 的认知上下文持续演化”，Prompt 也逐渐成为 Harness 中可观测、可优化、可验证的动态能力组件。

GEPA（Genetic-Pareto Prompt Evolution）通过利用 Agent 执行轨迹中的反馈信号，实现 Prompt 的自动优化。它将 reasoning trajectory、tool call、tool output 等执行记录作为反思对象，由 LLM 对失败案例和成功案例进行自然语言分析，识别当前 Prompt 或系统设计中的不足，并提出新的修改策略。

GEPA 的基础架构融合了两种计算思想：遗传算法和多目标优化中的帕累托前沿概念，它维护一个由多个候选文本组件构成的“种群”，这些组件代表了对特定任务解决方案的不同探索路径。与传统单点优化不同，GEPA 的目标不是找到单一的最优解，而是发现一个“帕累托最优前沿”的解集，在准确率、成本、鲁棒性等多目标间权衡，筛选出帕累托最优的个体进入下一轮进化。这个“评估-反思-演化”的循环不断重复，使文本组件得以像生物一样“进化”，逐步逼近理想的性能水平。

Trajectory Collection → Reflection → Prompt Mutation → Evaluation → Pareto Selection

实验结果表明，GEPA 在多个任务上超过了基于强化学习的 GRPO 方法，同时显著减少所需 rollout 数量；论文报告其平均提升约 6%，最高可达到 20%，并且最多减少 35 倍的 rollout 成本。相比传统 Prompt 优化方法 MIPROv2，GEPA 也取得了明显提升。

Skill 进化

在 Agent 系统中，Skill 是介于基础模型和具体任务执行之间的重要能力抽象。相比 Prompt 主要约束模型行为，Skill 封装了更加结构化的任务解决策略，包括任务流程、工具调用方式、领域知识以及经验规则。因此，随着 Agent 长期运行，仅优化 Prompt 已不足以覆盖复杂任务中的能力提升需求，根据 Agent 在实际部署过程中的运行证据，持续更新和优化技能库，使技能随着经验积累不断改进，成为 Agent 自进化的重要方向。

SkillOpt 是微软研究院提出的一种系统化、可控的智能体技能文本空间优化框架，它的核心目标是在不改变大语言模型权重的情况下，像训练神经网络参数一样，可靠地“训练”和优化 Agent 的自然语言技能文档（如 Prompt 或策略指南） 。通过引入“前向-反向-更新”的机制，把文本优化变成了一套有严格数学优化理论影子的工程范式：有明确的输入输出、有可计算的误差反馈、有受控的更新步长、有严格的验证机制。

SkillOpt 将技能视为冻结 Agent 的“外部可训练状态”，并通过一个独立的“优化器模型”驱动以下闭环流程：

• Rollout（执行与采样）——对应模型训练的前向传播：目标Agent使用当前版本的技能文档执行任务，系统记录其完整的执行轨迹及最终得分
• Reflect（反思）——对应模型训练的反向传播：优化器模型分别分析成功和失败的轨迹批次，诊断 recurring errors（重复性错误），并提取可复用的纠正规则
• Edit（有界编辑）——对应模型训练的参数更新：优化器提出具体的“添加/删除/替换”文本编辑操作。为了防止有益的规则被破坏性的重写覆盖，系统引入了“文本学习率”（textual learning rate）预算来限制单次编辑的幅度
• Gate（门控验证）：这是保证稳定性的关键。候选技能只有在严格提升了保留验证集（held-out validation set）的性能时才会被接受；否则将被拒绝，并作为负反馈存入缓冲区，指导后续优化

尽管 SkillOpt 提出了严谨的优化框架，但其工程复杂度极高：强制将“执行”与“优化”拆分为两个独立的逻辑角色和调用流，反思的上下文有损，同时需要精细调节“文本学习率”、“编辑预算”等超参数，且细粒度的“增删改”操作导致收敛缓慢。

SkillOpt-Lite 取消独立优化角色，执行与反思在同一个连贯的上下文中完成，流程扁平化，产出逻辑更连贯、结构更优化的全新技能文档，且收敛快，性能上限更高：一步到位的全局重构能迅速跳出局部最优，实验证明其最终表现甚至优于全功能版 SkillOpt。

• Rewrite（单步全局重写）：抛弃 SkillOpt 中受限的“增/删/改”操作，主模型基于挖掘出的共识，直接对当前的技能文档进行一次性的、大范围的重写。这是一种粗粒度的更新方式。
• Gate（门控验证）：与 SkillOpt 一样，重写后的新技能必须在验证集上进行测试。只有性能提升才被接受，否则回滚。

核心创新在于构建了一个前所未有的、围绕 Skill 展开的完整生命周期闭环，在一个统一的框架内，完整地实现了技能的“创建-测试-存储-使用-评估-精炼-退役”整套流程。将技能形式化为一种结构化的、带有元数据和独立记忆的、可被版本控制和管理的实体，使得技能库可以被压缩、分发、验证。通过强制性的单元测试机制，MUSE-Autoskill 优先考虑技能的质量而非数量，采取了“慢即是快”的策略，确保了技能库的长期健康度和可用性。

该框架采用领域/任务绑定的局部记忆（Skill-level memory），将记忆与技能演化深度绑定，每个被创建的技能都被赋予了一个专属的记忆空间，仅存储与该技能直接相关的执行轨迹、成功/失败经验、异常边界等，极大降低了检索时的噪声干扰，提高了上下文相关性，并为后续的技能微调提供了精准、高纯度的数据支撑。

该论文并非提出单一的算法模型或特定的应用程序，而是一篇具有高度概括性和指导意义的综述性文献。该论文致力于为 Agent Skill 建立一套标准化的定义和分类体系，并提出了一套更为精细和多维度的评估框架，强调不仅要衡量任务是否完成，更要考察技能的利用率、性能提升效果以及鲁棒性等多个维度，构建了一个涵盖“评估-优化-迭代”的完整生命周期框架。同时系统性地总结和归纳现有的多种 Agent Skill Evolution 策略，如基于强化学习的迭代优化、基于失败分析的递归自我完善、协同演化与持续学习等。

Memory 进化

Memory 是连接过去经验和未来行为的状态层。它不仅负责保存经验，还通过表示、操作和演化机制决定哪些经验能够被保留、优化和重新激活，从而持续影响 Agent 后续决策。因此 Memory Evolution 不仅指记忆内容的持续积累和更新，更包括记忆管理机制自身的优化。前者关注 Agent 从交互轨迹中提炼什么知识、技能和经验；后者关注如何组织、检索、评估、更新和淘汰这些经验，使 Memory 系统能够随着任务分布和经验规模变化持续适应，从而持续影响 Agent 后续决策。

该工作重新思考了主流的记忆建模范式，指出记忆的价值不仅在于其内容本身，更在于其所承载的知识单元之间关系的动态性和可塑性。该研究认为，一个真正高效的记忆系统应该是一个能够根据任务需求和环境变化，自主地调整其内部结构的有机体。论文进一步提出了一种名为 FluxMem 的训练-free 自调节记忆框架，其目标正是要修复断裂的链接、修剪冗余的噪声，并通过动态的连接演化来构建一个更加健壮、高效和适应性强的知识网络。

FluxMem 的架构采用图网络作为记忆的基本数据结构，记忆被明确地表示为一个图（Graph），其中的节点（Nodes）代表 Agent 经历的具体事件、观察到的事实、生成的结论或任何其他有意义的认知单元 。每一个节点都包含了一个关于该记忆单元的丰富信息，例如文本描述、时间戳、情感标签或其他元数据。而连接这些节点的边（Edges）则构成了记忆网络的骨架，它们代表了不同知识点之间的语义、逻辑或因果关联。它使得抽象的知识不再是一系列孤立的数据点，而是被组织成了一个相互关联、层次分明的知识体。这种显式的结构化表示天然地支持复杂的推理过程，因为推理可以被形式化为在图上执行的一系列操作，例如路径搜索、子图匹配或基于图神经网络的消息传递。

FluxMem 的图结构与传统的知识图谱（Knowledge Graph, KG）既有相似之处，也存在本质区别。两者都使用图来表示知识，但 FluxMem 的图是动态生成和演化的，它编码的是智能体在与环境交互过程中产生的实时经验，可以被视为一种“经验图谱”或“体验图谱”。相比之下，知识图谱通常是静态的、人工构建或半自动构建的，侧重于编码人类已知的先验知识。因此，FluxMem 的图结构与知识图谱形成了有益的互补，前者为后者提供了一个由智能体自身经验驱动的、不断进化的动态知识视图。静态知识图谱提供宏观的世界观和背景知识，而 FluxMem 的动态图则记录智能体在微观层面的个性化经验和交互历史。

FluxMem 由三个协同工作的、训练-free 的自调节子系统精确驱动：链接修复、链接修剪和链接巩固。根据内部状态和外部任务需求，能够主动地构建、清理和强化其内部的连接。

Evo-Memory 是一个综合性的流式基准测试与框架，专门用于评估大语言模型智能体自进化记忆（Self-Evolving Memory） 的能力。其核心论点是：将评估范式从“测试固定能力”转向“衡量智能体从连续的任务流和经验中动态学习与进化的能力”——这一过程被称为 “推理时进化”（Test-time Evolution）。Evo-Memory 的核心目的在于提供严格、标准化的方法，以量化大语言模型智能体是否真正能够从经验中学习，而不仅仅是检索预存信息。

传统基准测试通常评估特定的已知技能或事实（即智能体“已经知道什么”）；相反，Evo-Memory 通过流式（Streaming） 特征，将数据集构建为连续的任务流，迫使智能体增量处理信息，持续更新其内部状态和记忆。

• ReMem 等专用模块：在 Evo-Memory 生态系统中，类似 ReMem 的组件被明确设计用于增强智能体的推理时学习能力。它的作用是提取已完成任务中的“经验教训”，并将其提炼为可供未来使用的策略，从而实现框架所期望的“进化”。
• 认知科学启发的多存储系统：先进的架构开始借鉴人类认知，实施多层级的记忆系统。例如：
• 情景记忆（Episodic Memory）：用于回忆特定事件和交互历史。
• 语义记忆（Semantic Memory）：用于保存通用的世界知识和事实。
• 程序记忆（Procedural Memory）：用于存储“如何做”的知识或技能（如工具调用流程）。
• 推理时适应（Test-time Adaptation）：除了外部记忆库，研究者还在探索无需微调模型权重的适应方法。例如推理时提示微调（TPT），能够根据单个测试样本动态学习自适应提示；以及基于强化学习（RL）的记忆管理，训练智能体主动优化外部记忆中的高价值信息。

上下文优化

ACE（Agentic Context Engineering，智能体上下文工程）框架将 Context 视为一种持续演化的 Playbook（策略手册），通过模块化的 生成（generation）、反思（reflection）和治理（curation）流程，不断积累、优化和组织执行策略。Playbook 不再是过去交互的流水账，而是一个经过提炼、组织和结构化的知识库，包含了成功的策略、失败的教训、通用的推理模式和特定领域的知识片段。ACE 通过结构化、增量式的更新方式避免上下文坍缩，在保留细粒度知识的同时，能够随着长上下文模型的发展持续扩展。

这里 ACE 的核心设计原则很值得参考：将 Context 表示为一组结构化、可独立管理的条目（itemized bullets），而不是一个整体式的 Prompt。

这里的 bullet（条目）类似于 LLM Memory 框架中的 Memory Entry，但 ACE 在此基础上进行了扩展。每个 bullet 由两部分组成：

1. Metadata（元数据）

包括：

• 唯一标识符（unique identifier）；
• 统计信息，例如该条目在历史任务中被认为有帮助（helpful）或有害（harmful）的次数。

2. Content（内容）

表示一个小粒度的知识单元，例如：

• 可复用的执行策略（reusable strategy）；
• 领域概念（domain concept）；
• 常见失败模式（common failure mode）。

当 Agent 处理新的任务时，Generator 会标记哪些 bullet 对当前任务有帮助，哪些 bullet 可能误导了执行过程，并将这些反馈提供给 Reflector，用于生成后续修正更新。

这种条目化设计带来了三个关键能力：

1. Localization（局部更新）：系统只需要更新与当前问题相关的 bullet，而不需要重新生成整个 Context。这避免了传统 Prompt Rewrite 方法中修改范围过大、无关知识被覆盖、原有有效经验丢失等问题。
2. Fine-grained Retrieval（细粒度检索）：由于 Context 被拆分为独立知识单元，Generator 可以针对当前任务召回最相关的知识，而不是加载整个 Context。这使得 Agent 能够：根据任务类型选择不同经验； 根据当前状态选择不同粒度知识； 降低无关 Context 对推理过程的干扰。
3. Incremental Adaptation（增量适配）：条目化 Context 支持在运行过程中进行：高效合并（merging）； 删除无效内容（pruning）； 去重（de-duplication）。 因此，Context 可以随着 Agent 执行持续演化，而不会因为长期积累导致失控增长。

与传统方法直接重新生成完整 Context 不同，ACE 采用增量 Delta Context 更新机制：即每次只生成一小组新的候选 bullet，由 Reflector 提炼，再由 Curator 合并进入已有 Context。这种方式避免了完整 Context Rewrite 带来的：高计算成本；高延迟； 信息丢失风险。同时 ACE 提出在长上下文模型和 KV Cache 技术支持下，Agent 更应该保留丰富、结构化的经验资产，而不是过早压缩，与传统观点认为 Context 越长，Agent 成本越高，因此需要不断压缩 Memory / Knowledge的观点相反。

基础模型改进

参数更新路径（parameter path）并不是对 Harness 更新路径（harness path）的替代，而是一个更慢的能力沉淀过程。只有当运行时积累的经验满足稳定（stable）、泛化性（general）、价值足够高（valuable enough）并且其收益足以证明值得进行一次更难回退的更新时，这些有价值的经验才会被进一步固化为模型更新，使其能够超越简单的上下文复用，迁移到更广泛的任务场景中。

SEED: Self-Evolving On-Policy Distillation for Agentic Reinforcement Learning探索了 Agent 在强化学习过程中如何利用自身交互经验实现策略层面的自主进化。作者指出，现有 Agentic RL 方法通常依赖任务最终结果反馈（Outcome Reward）进行优化，但对于包含长程规划、多轮交互和工具调用的复杂 Agent 任务，单一的轨迹级奖励难以准确指导中间决策，导致奖励信号与具体行为优化之间存在较大鸿沟。

SEED 的训练过程分为两个阶段。首先，模型通过 Supervised Fine-Tuning（SFT）阶段学习基础的 Agent 行为能力，使其具备完成任务所需的推理、规划和工具交互能力。在此基础上，进入自演化强化学习阶段，模型利用自身策略与环境交互产生 on-policy trajectory，并从这些真实执行轨迹中提炼可复用经验。

SEED 让 Agent 同时承担“执行者”和“经验提炼者”两个角色：一方面，当前策略与环境交互生成任务轨迹；另一方面，Agent 对成功或失败轨迹进行分析，提取其中具有泛化价值的 hindsight skill，包括有效的任务执行流程、关键决策模式以及失败规避策略。随后，SEED 将这些 skill 作为额外上下文重新输入模型，通过比较引入 skill 前后的行为概率变化，构造 token-level 的自蒸馏信号，并与强化学习目标联合优化，使经验能够反向更新当前策略。

其中， 控制 OPD 信号的权重。强化学习损失项负责优化智能体在环境交互中的任务结果，而 OPD 损失项则通过蒸馏智能体自主生成的 hindsight skills，使模型能够将这些经验中蕴含的有效策略内化为自身能力。

与依赖外部奖励或静态经验库的方法不同，SEED 强调 on-policy experience alignment：经验始终来自当前策略产生的交互过程，并服务于当前策略优化。因此，Agent 不仅通过奖励信号学习，还能够主动总结自身经历，将一次次任务执行转化为策略改进的监督信号。

实验方面，SEED 在多个 Agentic RL Benchmark 上进行了验证，包括文本交互环境 ALFWorld、WebShop以及视觉交互环境 AndroidWorld等任务。实验结果表明，在相同基础模型和训练预算下，引入自生成 skill 作为蒸馏信号后，Agent 在任务成功率和样本效率方面均获得提升。进一步分析显示，SEED 学习到的经验具有一定迁移能力，能够帮助 Agent 在未见任务中获得更好的表现。

SEED 展示了一种面向 Policy Evolution的自主进化范式：通过“执行任务 → 总结经验 → 蒸馏经验 → 更新策略”的闭环，使 Agent 的运行轨迹从一次性数据转变为持续提升自身能力的学习资源。

作者团队主要来自 LV-NUS Lab、复旦大学、北京大学以及字节跳动等机构，该篇论文指出现有 Agent 自我提升方法通常依赖 Memory、Skill Library 或 Reflection 机制，让 Agent 能够保存历史经验并在后续任务中复用。然而，拥有 Memory 并不等同于具备自主进化能力。Memory Agent 更多解决的是“如何利用过去经验完成当前任务”，而真正的 Agent Evolver 需要进一步解决“如何从经验中持续学习并改变未来行为”。

OPD-Evolver 针对这一问题提出了一种 Slow-Fast Co-evolution（快慢协同进化）框架，目标是训练一个具备完整经验管理能力的 Agent Evolver。作者认为，一个真正具备自主进化能力的 Agent，需要同时具备四类能力：

1. Experience Selection：从不断增长且存在噪声的 Memory 中选择真正有价值的经验；
2. Experience-grounded Execution：将选择出的经验转化为当前任务中的有效行动；
3. Experience Writing：从新的任务轨迹和反馈中提炼可复用知识；
4. Experience Management：对长期 Memory 进行评估、合并、更新和淘汰。

论文的核心思想是：让 Agent 在运行过程中先通过 Memory 进行在线进化，再将这些进化过程中产生的高价值行为模式蒸馏回模型参数，使模型逐渐内化“如何进化”的能力。

在 Fast Evolution Loop 中，Agent 与环境持续交互，并基于四层 Memory 体系（Trajectory、Tips、Skills、Tools）完成任务。Agent 首先根据当前任务选择相关经验，利用经验完成多轮执行，并根据执行结果、奖励反馈以及新的轨迹总结和维护 Memory。在这一过程中，论文提出 Outcome-calibrated Memory Attribution 机制，将最终任务结果反向归因到具体 Memory 操作，判断哪些经验选择、使用、写入和维护行为真正促进了任务成功，从而生成训练监督信号。

随后，在 Slow Evolution Loop 中，作者通过 On-Policy Self-Distillation 将 Fast Loop 中产生的有效进化行为蒸馏到模型内部。与传统 SFT 学习任务解决过程不同，OPD-Evolver 学习的是 Agent 的“进化过程”，即如何选择经验、如何利用经验、如何总结经验以及如何管理长期 Memory，使模型从依赖外部 Memory 的系统逐渐演化为具备内生经验管理能力的 Agent Evolver。

实验部分在多个领域 Benchmark 上验证了方法有效性。结果表明，OPD-Evolver 相比现有 Memory-based Agent（如 ReasoningBank）以及基于训练的 Agent 优化方法均取得明显提升，证明通过学习经验管理能力，Agent 可以获得更强的持续改进能力。进一步分析显示，即使使用较小规模模型（如 OPD-Evolver-9B），经过进化能力训练后，也能够挑战更大规模模型的性能，说明 Agent 自主进化不仅依赖模型规模，也依赖模型是否具备有效利用和管理自身经验的能力。

EvolveR 关注 LLM Agent 在长期运行过程中难以从自身经验中持续学习的问题。现有 Agent 通常将每次交互视为独立过程，即使产生大量成功或失败轨迹，也难以沉淀为可复用能力，导致“经验无法转化为能力”的问题。为此，EvolveR 提出了一种基于经验生命周期（Experience-Driven Lifecycle）的自进化框架，通过在线交互、经验抽象、经验管理和策略优化形成闭环。

EvolveR 构建了一套由在线交互和离线经验演化组成的闭环生命周期。首先，Agent 通过 GRPO 强化学习与环境进行交互，在任务执行过程中产生包含决策过程、工具调用、反馈结果以及最终奖励的完整轨迹（trajectory）。这些轨迹随后被进一步自蒸馏，将具体任务中的成功行为模式和失败原因抽象为更高层次、可迁移的策略原则（principles），例如有效的问题分解方式、任务规划策略以及需要避免的错误模式。

为了保证经验库能够长期稳定演化，EvolveR 进一步设计了经验库管理机制，通过语义去重、经验合并、效果评分以及低价值经验淘汰等方式持续维护经验质量，避免经验累积带来的噪声和冗余。

在后续任务执行过程中，Agent 可以主动检索相关经验原则，将其作为决策参考，并通过持续的强化学习优化“何时检索经验、选择哪些经验以及如何利用经验”的策略，使外部经验逐渐转化为 Agent 自身的行为能力，实现从经验积累到能力提升的闭环进化。

实验表明，EvolveR 在多个多跳问答 Benchmark 上优于现有 RL 和 Memory Agent 方法。在 Qwen2.5-3B/7B 模型上分别取得 0.382/0.417 的平均 EM，验证了经验驱动闭环对于提升 Agent 长期任务能力的有效性。此外，实验发现一定规模模型的自蒸馏效果可以超过外部 Teacher 蒸馏，说明与自身能力边界和失败模式更加匹配的经验可能更有助于 Agent 自我提升。

Harness 进化工程设计

通过近期前沿工作的了解，一个明显的趋势就是希望从自身经验中持续学习，不管是Harness层面改进还是经验固化到模型参数中，本质上是一个从轨迹（trace）到能力（capability）的转化问题。同时一个完整的Harness自进化流程不是简单的“自动改 Prompt”，而是一套围绕 Trace → Diagnosis → Modification → Evaluation → Deployment的自动化工程闭环。

以下重点探索一下 Harness 层面的自进化算法落地。企业内部自研 Harness 大概的样子：

Trace 采集&消费

在 Harness 自进化场景中，Trace（执行轨迹）并不是传统意义上的运行日志（Log），而是描述 Agent 完整行为过程的结构化经验记录（Behavior Trajectory）。

一个 Agent 任务的最终结果只是执行链路的终点，而 Harness 自进化真正关注的是：Agent 为什么采取某种行为、依赖了哪些上下文、经过了怎样的决策路径，以及这些行为最终产生了什么效果。

因此，一个有效的 Evolution Trace 需要同时回答四个问题：

• 任务是什么（What）：Agent 面对什么目标和约束；
• 如何执行（How）：Agent 使用了哪些知识、工具和执行流程；
• 为什么这样执行（Why）：Agent 如何进行任务规划和决策；
• 效果如何（Result）：最终结果、反馈以及质量指标如何。

只有具备这些信息，Trace 才能够从简单的运行记录转变为支持 Harness 优化的经验资产。一个完整的 Trace 主要包含以下几个层面：

1. Task Context（任务上下文）：描述 Agent 为什么开始执行任务。主要用于：按任务类型分析效果 ，聚合同类任务，后续评测集生成。
2. Context Assembly（上下文构建过程）：记录 Agent 执行前获得的信息。例如：检索了哪些知识，加载了哪些 Memory，使用了哪些 Skill，注入了哪些 Prompt，当前 Workflow 状态
3. Planning Trace（任务规划轨迹）：记录 Agent 如何拆解任务。用于发现：是否缺少规划步骤，是否存在错误任务拆解，是否需要新增 Workflow
4. Reasoning / Decision Trace（决策过程）：记录 Agent 每一步决策信息。不一定保存完整 CoT，可以保存结构化摘要。关注：为什么选择这个动作，有没有错误判断，有没有反复尝试
5. Action Trace（行为轨迹）：这是 Agent 最核心的数据，记录 Agent 每一次动作。包括：Tool 调用（工具名称、输入参数、输出结果、执行时间、是否成功）、Skill 调用、Agent 间调用
6. Environment State（环境状态变化）：Coding Agent 特别重要。记录：文件变化、Git diff、编译结果、测试结果、运行环境
7. Feedback Signals（反馈信号）：包括：系统反馈、用户反馈、自动评测
8. Outcome（最终结果）：记录任务最终状态。成功 / 失败、完成质量、消耗成本、错误类型、用户是否继续修改。

此外，Agent Evolution 并不是简单地遍历所有历史日志进行学习，而是根据当前优化目标，在合适的经验空间中召回相关 Trace，进行问题分析和 Harness 修改。因此，Trace 需要具备多维组织能力：

• 来源维度：哪个 Coding Agent
• 业务维度：哪个项目 / 需求
• 用户维度：谁产生的行为
• 时间维度：单次 Session 或长期历史
• 任务维度：什么类型任务

不同进化目标对应不同 Trace Scope，这种组织方式使 Harness Evolution 从全量日志分析转变为目标驱动的经验检索：

诊断归因

Harness 自进化不能只依赖失败信号，否则系统只能不断修复 Bug，而无法持续提升能力。因此，一个完整的 Evolution Loop 需要同时包含：Failure-driven Evolution（从失败中发现缺陷）和 Opportunity-driven Evolution（从成功轨迹中发现优化空间）。

1. Failure-driven Evolution（从失败中发现缺陷）

Agent 运行过程中会产生大量失败：结果失败、执行异常、流程异常、效率异常等。但单个 Bad Case 本身并不足以指导 Harness 修改。一次失败可能来自模型随机采样、外部环境波动、工具异常、任务不可解、评测误差等多种因素。如果直接针对单个失败样本修改 Prompt 或 Workflow，容易产生过拟合。系统可能记住某个具体任务的解决方式，却没有真正提升 Agent 的泛化能力。

因此，更合理的方式是将大量执行 Trace 中的异常行为进行聚合分析，将其从单次失败事件提升为 Failure Class（可复现、可归因的一类系统性问题）。

2. Opportunity-driven Evolution（从成功轨迹中发现优化空间）

Failure-driven Evolution 解决哪里坏了，Opportunity-driven Evolution 解决还能不能变得更好。生产环境中，大量 Agent Trace 并不会失败，但仍然存在优化空间，例如：

• 成功任务使用了过多 Tool Call；
• Memory 检索命中率低但最终靠模型推理完成；
• 相同任务不同 Rollout 路径差异巨大；
• Agent 经常重复尝试；
• 用户频繁修改 Agent 输出。

这些并不是明显 Bug，而是效率、稳定性和泛化能力问题。因此系统需要从 Trace 中发现弱监督信号：例如执行规则异常（Agent 是否遵守 Harness 设计约束）、运行效率信号（成功任务中非常重要）、无效行为（很多 Agent 的问题不是错误，而是浪费）、多轨迹不一致（说明Agent 策略不稳定）、用户行为反馈（用户没有明确说失败，但行为表达了问题）。和 Failure 类似，不能分析单条 Trace，需要聚合生成优化 Patch，不是发现问题立即修改。

候选进化动作

把发现的问题转换为可执行修改，首先需要把 Harness 拆成可修改的 Action Space，Harness 中各组件应该保持模块化，使 Evolution 可以针对不同对象生成 Patch：

• Prompt 层：优化任务理解、行为约束和决策规则；
• Skill 层：新增或增强可复用任务能力；
• Memory 层：优化经验沉淀、检索和注入；
• Knowledge 层：优化知识资产、检索；
• Workflow 层：调整任务执行流程、规划阶段和控制逻辑；
• Tool 层：优化工具描述、调用策略和错误处理机制。

每一个候选修改都应该形成 Evolution Candidate：

• Problem:解决什么问题
• Diagnosis:Root Cause 是什么
• Change:修改哪个 Harness 组件
• Expected Impact:预期收益
• Risk:可能影响范围

最终通过 Replay、Benchmark、Regression 和线上灰度验证，选择能够稳定提升 Agent 能力的方案，并形成新的 Harness Version。同时维护进化历史，方便新的类似问题可以快速召回。

这里重点讲一下 Knowledge 和 Memory 两个层面的进化，记忆面向项目和用户上下文的持续状态，包括项目知识、历史任务、代码结构、用户偏好、近期执行经验等，用于帮助 Agent 保持连续性。而知识是从多个 Agent 执行轨迹中抽象出的可复用能力资产，用于提升 Agent 在新任务中的泛化能力。

Agent 自进化不仅是知识和经验的持续积累，更是知识资产生命周期的持续优化。对于长期运行的 Agent 系统而言，Memory 和 Knowledge 会随着任务执行不断增长，如果仅采用简单的追加式存储，容易产生信息冗余、知识冲突以及低价值内容堆积，反而降低 Agent 的决策效率。因此，知识演化需要覆盖从产生、治理到使用的完整生命周期。

首先，在知识生成阶段（Knowledge Acquisition），Agent 每一次执行都会产生大量原始信息，但并不是所有 Trace 都应该进入 Knowledge Base。

进化系统需要识别其中具有长期复用价值的经验，例如：一次 Coding Agent 解决依赖冲突问题：安装失败 → 分析依赖树 → 修改版本约束 → 重新安装成功。

原始 Trace 并不是最好的知识形式。系统应该进一步抽象：当 Python 项目出现依赖版本冲突时，可以通过分析依赖树定位冲突包，并优先调整直接依赖版本，而不是修改所有依赖。

最终沉淀为：troubleshooting knowledge；debugging pattern；reusable Skill；workflow rule。

即：Execution Experience → Generalized Knowledge → Reusable Capability，这也是 Agent 从记住过去到学习经验的关键区别。

其次，在知识治理阶段（Knowledge Governance），随着 Agent 长期运行，Knowledge 和 Memory 会不断膨胀，因此需要类似数据治理的机制。主要包括：

• 去重与合并（Deduplication & Consolidation）：识别多个相似经验，将低粒度记录融合为更高层次的通用知识；
• 冲突检测（Conflict Resolution）：发现不同来源或不同时间产生的矛盾经验，并根据时间、可信度、成功率等因素选择更可靠版本；
• 质量评估（Quality Assessment）：结合实际任务效果评估知识价值，例如被成功调用次数、带来的收益以及适用范围；
• 生命周期管理（Lifecycle Management）：对于长期未使用、低收益或已经失效的知识进行降权、归档或删除，避免知识库持续膨胀。

最后，在知识利用阶段（Knowledge Utilization），Agent 需要不断优化如何选择和使用已有经验。知识规模扩大后，简单的向量相似度检索已经不足以保证效果，需要根据任务类型、项目上下文、用户行为以及历史反馈优化检索和注入机制。例如：

• 根据当前任务阶段选择不同粒度的知识；
• 根据项目、用户或环境上下文进行个性化召回；
• 根据历史使用效果动态调整 Memory 优先级；
• 优化 Context Injection 策略，避免无关知识占用有限上下文窗口。

因此，Memory Evolution 的本质是建立一个从经验产生 → 知识抽象 → 资产治理 → 智能检索 → 效果反馈的闭环，使过去的执行经验逐渐沉淀为 Agent 的长期能力。从 Harness 自进化角度看，Knowledge 和 Memory 本身就是一种可优化的 Harness 组件：系统不仅可以优化其中存储的内容，也可以优化这些内容的组织结构、管理策略以及影响 Agent 行为的方式。

验证

Harness 自进化的核心挑战不是生成修改，而是判断：新 Harness 是否真的提升了 Agent 能力？一次修改可能：

• 修复某个 Case；
• 但降低其他任务能力；
• 增加成本；
• 引入新的风险。

因此 Evolution Validation 需要覆盖三个层面：

1. Replay Evaluation（回放验证）：验证候选 Harness 修改是否解决触发进化的问题，推荐使用沙箱，但不是完整复制用户环境，而是最小可复现环境。根据场景不同，可以采用平台侧 Mock/Replay、用户侧 Sandbox 或 Skill 驱动的本地验证等方式，在保证真实性和安全性的前提下评估 Harness 修改效果。具体而言，将历史运行轨迹、失败 Case 或代表性任务重新输入新旧 Harness，通过对比执行过程、工具调用路径、中间状态以及最终结果，判断修改是否真正改善了原始问题。
2. Benchmark Evaluation（能力评估）：验证 Harness 优化是否带来整体能力提升，需要更完整的评测环境。由于单个 Case 的改善可能来自针对性优化甚至过拟合，因此需要在覆盖不同任务类型和难度分布的评测集上，对新 Harness 进行系统测试，评估任务成功率、执行效率、成本以及泛化能力。同时，对于由线上 Trace 沉淀出的 Failure Class 或 Opportunity Case，可以持续补充新的评测样本，形成随 Agent 演化而增长的动态 Benchmark。
3. Regression Evaluation（回归验证）：保证 Harness 演化过程的稳定性，需要稳定基准环境，不一定需要完整 sandbox。由于 Harness 包含 Prompt、Skill、Memory、Workflow、Tool 等多个相互影响的组件，一处优化可能影响其他任务能力，因此需要在历史成功 Case、关键业务场景以及安全约束 Case 上进行回归测试，检测是否出现能力退化、成本异常增加或新的风险行为。

这里有一个问题，对于平台型 Harness，可能不能完整复现用户真实执行环境。传统软件工程里的 Replay（完整环境回放）在 Agent 场景通常不可行：

• 用户代码已经变化；
• 外部 API 状态变化；
• 数据库状态不可复制；
• 用户私有数据不可进入测试环境；
• 模型存在随机性。

因此，Replay 更适合定义为：基于历史 Trace 构建的可控验证场景。

具体而言，系统首先从历史 Trace 中提取任务输入、上下文信息、关键状态变化、工具调用序列以及环境反馈等信息，形成可复用的 Replay Case。根据验证目标的不同，可以采用不同粒度的回放方式：

• 行为级回放（Behavior Replay）：固定任务输入和关键上下文，通过 Mock 或缓存工具返回结果，验证 Harness 修改是否改变了 Agent 的决策路径，例如是否减少错误工具调用、增加必要规划步骤或正确利用 Memory。
• 结果级回放（Outcome Replay）：复用历史任务结果或环境状态，比较新旧 Harness 在相同条件下的最终任务完成情况，用于验证目标问题是否得到改善。
• 流程级回放（Workflow Replay）：针对 Harness 中的 Workflow、Skill、Middleware 等结构变化，重点比较执行流程、状态转移和控制逻辑是否符合预期。

由于 Replay 环境通常无法完全等价线上环境，其结果更多用于判断候选修改是否值得进入进一步评估，而最终是否合入生产 Harness，还需要结合 Benchmark、Regression Test 以及线上灰度实验进行综合判断。

部署

Harness 自进化并不意味着 Agent 可以直接修改线上运行逻辑，为了保证：

• 可追踪；
• 可审计；
• 可回滚。

需要借鉴软件工程中的版本管理体系。

可以将 Harness 作为 Git 管理的软件资产。将修改转换为标准化 Harness Patch，提交到 Harness Repository，并通过 Pull Request（PR）进入发布流程。

每个 Evolution PR 需要关联：

• Evolution Case；
• Root Cause；
• 修改目标；
• Replay 结果；
• Benchmark 结果；
• Regression 结果。

使人工 Review 可以基于完整证据判断。

PR 合入后，系统会构建新的 Harness Artifact，并生成唯一版本标识。Agent Runtime 根据配置加载指定 Harness 版本，而不是直接读取动态修改内容，从而保证运行环境的稳定性和版本可追踪性。

通过版本化管理、自动化验证和人工治理相结合，Agent 能够持续优化自身运行机制，同时保证进化过程具备可解释、可验证、可控制、可回退。 这也是 Agent 从可使用系统走向持续成长系统的关键工程基础。

总结

回顾已有研究，Agent 自主进化的核心目标始终一致：让 Agent 不再只是完成任务，而是能够从每一次执行中学习，并将运行经验持续转化为自身能力。无论是模型参数的更新，还是由 Prompt、Memory、Tool、Workflow 等组成的 Harness 的优化，本质上都是一个 从 Trace 到 Capability 的转化过程。

从进化路径看，Harness 优化与模型优化并非替代关系，而是能力沉淀的不同阶段。Harness 具备低成本、快速迭代、易回滚的特点，适合承载 Agent 的在线学习和快速试错；而模型参数更新则需要经过长期验证，将稳定、泛化的经验进一步内化为基础能力。因此，未来成熟的 Agent 自进化体系应形成“Harness 快速演化 → 经验沉淀 → 模型能力内化”的分层闭环。

然而，将自进化研究落地为生产系统，真正关键的是建立一套可观察、可诊断、可验证、可控制的工程体系，Harness 自进化依然面临很多工程和算法的细节问题需要解决。

参考资料