TL;DR
Agent 已经能重写 Prompt、生成 Skill、搜索 Workflow，修改 Harness，甚至进一步可以修改一整套负责闭环改进流程的元优化器（Meta-Optimizer）。尽管各类修改越来越容易，但仍然无法确认“Agent 是否真的变强”，因为一次执行变好，可能来自更多采样、记住测试样本、环境恢复或纯粹迎合了 Evaluator，这些并不是可迁移的能力增长。
最近花了点时间系统学习了下 Agent 自进化，尝试回答下实践中要重点考虑的三个问题：
• 经验是否形成了跨任务持久更新？
• 更新是否在未见过的任务上产生可归因的净增益？
• 增益是否通过回归、安全、成本、审计和恢复约束？
Key Insights
• 自进化是更新事实、能力判断与可靠性判断的三层问题。 经验驱动的持久更新只证明变化发生。只有在没有见过的任务上形成可归因净增益，才真正构成了有效进化，而通过回归、安全、成本和恢复约束后，才接近可靠进化。
• Agent 的完整进化空间由可更新对象与学习信号共同定义。 更新可以进入模型参数，也可以进入 Prompt、Memory、Tool、Workflow 与 Harness。Agent 自己生成的示例与执行轨迹、内部评价和外部环境反馈则基本可用于任何一层的进化。
• 自进化必须形成闭合的 Learning Loop。 执行经验只有经过归因、路由、候选生成、独立验证、发布与持续观察，并重新影响下一轮 Agent 的行为，才能成为能力。缺少写回，过程只能停留在分析；缺少观察，优化只能是一次性的；缺少独立选择，则可能把错误更新写回系统，形成污染回路。
• 可修改空间决定潜在增益空间，可验证空间决定可靠进化边界。 效果提升可能来自更多采样、选择偏差、环境恢复和人工介入，只有在计算、采样、时间和人工投入大致相当，并通过独立测试、迁移与回归控制后，才能把增益归因于持久更新。
• 可信自进化是在受保护前提下，进行范围有限、可验证、可撤回的改进。 Agent 可以修改 Harness，甚至修改负责组织改进流程的 Meta-Optimizer，但改进目标则根据业务目标来设定，最终评估由独立评估机制完成，发布、审计和恢复则由独立的发布与治理机制负责。
一、什么是 Agent 自进化
1. Agent 的行为不只来自模型
如果只把 Agent 看成基础模型，就会忽略 Prompt、Memory、Tool、Skill、Workflow 和 Harness 也会持续改变 Agent 的行为，而自进化可能发生在这些部分，而不只是模型参数里。更准确地说，Agent 的行为由模型参数和围绕模型组织的运行机制共同决定：
其中， 是时间 的模型参数， 是操作脚手架，包括 Prompt、Context、Memory、Tool、Skill、Workflow、Routing、Scheduling、Harness 代码与安全约束等。
《Self-Improvements in Modern Agentic Systems: A Survey》中进一步将 概括为：
其中， 是 Prompt， 是 Memory 及其读写机制， 是工具及接口， 是路由、调度、编排和安全控制逻辑。
一次任务还会产生临时执行状态 ，例如 KV Cache、中间计划、当前工作记忆、尚未提交的文件和局部环境状态等。它们可以让当前任务表现更好，却不会自动改变后续任务。
Agent 自进化的第一条原则：
经验必须被写入模型参数、Memory、Skill、Workflow 或 Harness 等能够跨任务持续生效的部分，否则就只是一次性经验。
当前任务中的反思、重试和重新规划，只能算学习信号，不能证明学习已经完成。只有当经验被持久写入 或 ，并在后续任务中持续影响行为，才称得上自进化。
2. 自进化事件、有效自进化与可靠自进化
“自进化”这个词到处都在提，仿佛只要 Agent 发生更新，系统就必然越来越好。
这个前提并不成立。错误规则也可以被持久写入记忆，脆弱的工作流也可以在后续任务中稳定复现，针对固定 Benchmark 的手段也可以提高分数。它们都发生了跨任务更新，但没有形成自进化的能力。
本文尝试采用三个层次来分析自进化：
自进化事件：自进化事件须同时满足三个条件：经验确实促成了更新，且更新能够跨任务保留下来，并且已经影响了后续任务的行为。
有效自进化：有效自进化包含三个条件：已经发生了自进化事件，且改进能够迁移到未见过的同类任务，以及在排除更多采样、人工介入等其他原因后，任务表现确实获得了净提升。
可靠自进化： 净增益没有以不可接受的回归、安全风险、成本、延迟和长期不稳定为代价，并且更新具备版本、审计和恢复机制。
先要证明确实发生了跨任务更新，再证明这次更新能迁移并带来实际提升，最后还要确认它没有带来不可接受的风险，并且可以被安全保留。此外，自进化系统不仅要能够生成变化，还必须能够拒绝变化。要让这三个层次成立，还需要满足三项基本要求：
持久更新。 如果经验没有改变跨任务持续的 或 ，就没有发生自进化事件；任务内反思只能生成学习信号。
验证约束。 扩大更新范围只会直接增加候选空间；可靠增益仍要求等预算、独立评价，以及未参与搜索任务上的迁移和回归检验。
控制面分离。 如果同一候选生成器可以改变并批准目标、最终评估、关键测试、审计和最高权限，既做裁判员又做运动员，系统就无法稳定区分能力增长还是评价标准变了。Agent 可以提出变更，但最终批准权必须独立。
3. 哪些算 Agent 自进化，哪些不算
记忆增强和 RAG 本身不等于自进化。保存偏好、事实、历史记录，或给知识库增加文档，改变的只是 Agent 能够调用的信息；只有这些经验进一步改变了 Agent 后续的行动方式，才可能构成自进化。
可以简单区分为三种情况：
• 只保存和召回信息，属于信息持久化或知识增强
• 改变记忆读写、检索决策、工具调用或结果验证，并在后续任务中持续生效，属于脚手架层面的自进化
• 把稳定泛化的经验训入模型参数，则属于参数层面的自进化。
一些具备 Memory、Skill 或 Workflow 写回能力的 Agent 产品，也会将这类功能称为“自进化”。但写回经验只证明系统发生了持久更新，并不能证明能力已经提升；还需要验证改进能否迁移到未见任务，并排除记住评测样本、增加检索次数或依赖人工介入等其他解释。
持久化不等于泛化，召回成功不等于策略进化，策略改变也不等于可靠进化。
同样，长任务、多 Agent 协作、更多工具调用和更复杂的 Workflow，描述的首先是执行结构。如果经验没有写入能够跨任务生效的模型或脚手架里，就不算 Agent 自进化。
Agent 反复改进代码、算法或其他外部 Artifact，也不等于 Agent 自身变强，而属于 Artifact 迭代优化。前者关心 Agent 是否获得了可迁移、可验证并能影响后续任务的能力，后者关心本次任务的产物是否变好。同一个 Agent 可以改进 Artifact，却没有改进自身。
因此，判断一个系统是否在自进化，只需问三个问题：
1. 什么在变化？ 是 Agent 的模型、Memory、Skill、Workflow 和 Harness，还是外部 Artifact？
2. 变化由什么驱动？ 是执行经验、环境反馈、用户纠正，还是单纯的复杂搜索和更多采样？
3. 变化是否写回并持续生效？ 它是否在未参与这次优化的后续任务中持续生效？
这三个问题分别判断什么在变化、变化由什么学习信号驱动，以及这次变化是否被持久写回，并在后续未见任务中持续产生作用。
二、Agent 自进化的技术手段
1. 两条更新路径
第一条路径是更新模型参数：
其中， 是执行产生的学习信号。参数更新通过 SFT、LoRA、蒸馏、RL 或持续后训练改变模型的默认能力分布，适合压缩稳定、重复、密集的经验，相应的代价是模型训练成本、责任归因（Credit Assignment）困难、旧能力遗忘、目标漂移，以及作用范围扩大后需要进行更全面的回归与安全验证。
第二条路径更新操作脚手架：
它可以改变 Prompt、Context、Memory、Tool、Skill、Workflow、路由、调度、Harness 代码乃至元优化器（Meta-Optimizer）。外围更新更快、更可解释，也更易版本化和回滚，也是目前用的最普遍的方式，但主要风险是规则冲突、Context 或 Memory 污染、工具语义漂移、工作流脆弱与代码级 Reward Hacking。
两条路径不是“真学习”和“假学习”的区别。只要经验驱动持久更新并跨任务改变行为，二者都可以构成自进化。它们真正不同的是更新对象、作用范围、生效机制、验证成本和可恢复性。
2. 三类学习信号
更新路径回答“经验最终写到哪里”，学习信号回答“系统根据什么经验来改”。现有的学习信号大致分为三类。
内在生成示范：Agent 自己生成的训练样本、任务轨迹、程序或候选解。它可以降低对外部数据的依赖，但也可能重复甚至放大 Agent 原有的错误和盲点，这类信号需要专业视角的清洗处理。
内在评估反馈：Agent 对自身表现进行评价，包括自我批评、偏好判断、置信度、一致性检查和 Judge 模型给出的反馈。它有助于发现问题，但如果执行者和评价者具有相同的盲点，也可能形成“自己认可自己”的错误自洽。
外在探索经验：来自环境和真实交互的结果反馈，包括沙箱或模拟器的运行结果、测试反馈、工具返回、用户纠正和人工评价。它更接近任务是否真正完成，但仍可能受到模拟环境与真实环境不一致、反馈延迟、业务因素混杂和环境噪声的影响。
学习信号与更新对象是两个相对独立的维度。同一条用户纠正，既可以写入 Memory，也可以被整理成 Skill、用于修改 Workflow 或 Harness，还可以进入模型训练数据。系统真正需要决定的是：
哪类经验应该写入哪一层，以多大的范围生效，又需要什么证据才能接受这次更新。
3. 主要更新对象
Agent 自进化的更新对象不只包括模型参数，还包括 Prompt、Context、Memory、Tool、Skill、Workflow、Harness 和元优化器（Meta-Optimizer）。不同对象改变行为的方式、适用问题、风险和验证要求并不相同：
更新对象行为改变机制适合的问题常见风险核心验证Prompt / Context改变决策时可见的信息与约束局部知识与策略指导评测规则泄漏、规则冲突和注意力稀释未见任务、规则冲突与开关对照实验Memory改变跨任务检索与调用内容事实、事件和策略经验样本记忆、污染召回和过时知识版本开关、误用率与时间有效性Tool / Skill增加或修订可执行动作与操作方法接口、程序性经验与工具组合固化偶然路径、依赖漂移和权限扩大单元测试、依赖失效与权限检查Workflow / Orchestration改变任务分解、状态转移和恢复路径编排、重试、等待与恢复更多调用、绕过约束和路径投机同等条件单次通过率、路径审计与状态恢复Harness改变上下文、工具、状态和控制流的运行机制上下文、工具、状态与控制流改写评估、隐藏失败和扩大可编辑范围隔离执行、外部评估器、Lineage 与权限检查元优化器（Meta-Optimizer）改变候选生成、验证与选择机制改进路线与更新策略修改评估、放大搜索偏差和扩大可编辑范围外部评估器、搜索与测试隔离、Lineage 与权限检查Model改变模型默认能力分布稳定、重复、广泛的能力缺口局部增益伴随遗忘或目标漂移Held-out 迁移、跨能力回归与数据删除验证
这些对象会相互嵌套：Skill 可封装 Tool，Workflow 由 Harness 执行，元优化器（Meta-Optimizer）又可修改 Harness。更新的作用范围越大、越接近完整运行时或模型默认能力，潜在收益与风险通常越高，对独立证据、权限控制和恢复能力的要求也越高。所有技术路线都不能脱离相应的验证方法讨论。
4. 混合进化：模型与脚手架共同更新
模型参数与操作脚手架不必二选一。
脚手架更新速度快、容易观察和回滚，适合先验证新的知识与策略；当某类经验在未参与更新的任务和回归测试中持续成立，再考虑把高频、通用的部分写入模型参数。新模型上线后，Prompt、Tool、Workflow 和 Harness 也需要重新适配。
SIA（Self Improving AI with Harness & Weight Updates）论文提出并开源了一套同时更新 Harness 和模型权重的自改进框架。它让 Feedback-Agent 根据完整执行轨迹，在两种更新方式之间进行选择。实验显示，仅更新 Harness 的收益达到瓶颈后，继续更新权重还能带来额外提升。
这也符合直觉，说明两条路径可以互补：脚手架主要改变 Agent 如何行动，模型参数主要改变它默认掌握什么、倾向如何判断。但两者也可能共同迎合固定的 Verifier，造成 Reward Hacking 和过拟合，因此收益不能简单相加。
5. 递归进化：当改进机制本身也成为更新对象
普通自进化修改的是 Agent 完成任务的能力，而递归进化进一步修改“如何产生改进”的机制，例如如何收集证据、生成候选、安排验证、选择更新和决定停止。也就是说，负责组织这些过程的元优化器（Meta-Optimizer），本身也成为了更新对象。
论文《Self-Taught Optimizer（STOP）: Recursively Self-Improving Code Generation》探索了让“负责改进程序的机制”继续改进自身的方法。它从一个初始改进器（Seed Improver）出发，让模型生成新的改进策略，再由外部效用评价（Meta-utility）选择更好的策略，用于继续优化改进器自身和下游程序。
这项研究证明了改进机制可以被修改，但任务、底层模型和评价标准仍由外部固定，因此并不等于完整的递归自我改进（RSI）。能力较强的元优化器可以在线组织证据、修改顺序、候选选择与停止，能力较弱时仍需要预定义流程。
需要注意，递归并不保证系统一定进步；它会同时放大有效信号、错误判断和评价漏洞。Agent 可以组织改进路线，但目标、最终评价、最高权限、发布与恢复仍须由独立机制控制。
三、Agent 自进化的作用机制
经验写入不同对象，会通过不同方式改变 Agent 后续看到的信息、能够执行的动作和采用的决策流程。
1. Prompt 与 Context：改变 Agent 当下看到的信息和约束
Prompt 和 Context 不会直接增加新的能力组件，而是改变 Agent 决策时能看到什么、应优先考虑什么，以及必须遵守哪些要求。它们修改快、反馈周期短，适合根据失败轨迹补充局部知识、示例和策略，也适合快速验证某种改法是否有效。
但这些约束最终仍要依赖模型本身的理解和指令遵循能力。规则可能彼此冲突，过长的 Context 会稀释重点，针对固定评估集总结出的答案模式也可能只对测试数据集有效。
因此，Prompt 和 Context 适合快速验证知识与策略，不适合承载不可逆动作、最高权限和硬安全边界。 能由代码强制的约束，不应只依赖模型概率性的指令遵循。
2. Memory：改变 Agent 后续能够召回的经验
Memory 的更新不只是保存更多文档，而是决定哪些经验会在后续任务中被重新调用。
情节记忆（Episodic Memory）记录发生过什么，语义记忆（Semantic Memory）保存提炼后的事实与规律，程序性记忆（Procedural Memory）记录下一次应该如何行动。其中，程序性记忆会直接影响工具选择、操作顺序和验证方式，因此最接近策略能力更新。
经验从一次事件沉淀为长期规则时，需要同时记录来源、时间、适用范围、冲突关系和失效条件。否则，系统无法区分稳定规律、个人偏好和已经过期的状态。
Memory 既能保存可复用经验，也可能持续传播错误信息。当缺少冲突处理和废弃机制时，检索越准确，错误记忆反而会被调用得越稳定。
3. Tool 与 Skill：改变 Agent 能做什么以及怎样做
Tool 层的更新可以根据经验持续调整工具选择策略，修订现有工具，以及创建新工具。
单次任务中临时选择不同工具不算自进化，只有选择策略或工具本身被持久修改，并在后续任务中继续生效，才构成 Tool 层的更新。
Tool 扩大 Agent 可以执行的动作，Skill 则把操作步骤、工具组合、失败恢复和领域规则封装为可重复使用的方法。成功轨迹被整理成 Skill 后，Agent 不必每次从头探索，但偶然成功的路径也可能因此被固化为默认行为。
可靠的 Tool 和 Skill 需要明确输入输出、前置条件、依赖、版本、适用范围、权限和验证方法。只有模型自己能“读懂”、运行时却无法检查验证的 Skill，在高风险场景不适合使用。
4. Workflow：改变任务如何拆解与推进
Workflow 不一定让模型本身更聪明，但可以通过更好的任务分解、步骤顺序、状态管理、重试和恢复，让同一个模型更稳定地完成长任务。
论文《AFlow: Automating Agentic Workflow Generation》把 Workflow 表示为由节点和连接关系组成的图，并自动搜索任务步骤、执行顺序和 Prompt 的组合，说明执行结构本身也具备表征能力。
Workflow 适合修复任务分解、工具衔接、状态转移和搜索策略问题。如果失败来自基础模型不具备的知识或推理能力，增加步骤通常只会增加调用次数和成本。
评价指标（Fitness）也不能只看最终答案，还要覆盖工具预算、状态恢复、权限路径和关键步骤检查，防止系统通过增加调用或绕过约束来提高评测分数。
5. Harness：改变 Agent 的完整运行方式
Harness 决定模型看到什么、可以调用什么、状态如何保存、失败如何恢复、何时派发子 Agent，以及怎样验证结果。它把模型连接到真实环境，因此修改 Harness 可以同时改变上下文、工具、状态和控制流，作用范围通常比单独修改 Prompt、Skill 或 Workflow 更大。
生产级 Harness 同时包含两类职责。上下文组织、压缩策略、工具描述、任务编排和恢复流程属于能力层，可以在约束下持续优化；沙箱边界、审批、最高权限、审计和发布控制属于控制层，不应交给同一套自修改机制自由改写。
OpenAI 开源的 Codex Harness 进一步说明，即使模型不变，Harness 对推理状态和上下文的处理方式也可能显著改变任务表现和 Token 成本。这证明 Harness 是重要的能力杠杆，但工程师优化 Harness 并不等于 Agent 发生了自进化；只有修改由执行经验驱动、被持久写回并通过独立验证，才属于本文讨论的自进化。
论文《Meta-Harness: End-to-End Optimization of Model Harnesses》使用外部强 Coding Agent 读取候选代码、分数和原始轨迹，再提出新的 Harness。
论文《Self-Harness: Harnesses That Improve Themselves》则让目标 Agent 在预先限定的范围内，根据失败轨迹提出最小修改建议。
前者诊断能力更强，但成本和外部依赖更高。后者自主性更强，却更容易受到自身盲点限制。两者能否可靠改进，关键都不在于是不是“自己修改自己”，而在于是否限制可编辑范围、保留完整的版本来源与修改记录（Lineage），并使用独立测试检查回归。
OpenAI Codex Harness 还把一次交互拆成 Item、Turn 和 Thread，并由外部应用负责审批敏感操作。这种设计使动作、会话状态和人工介入更容易追踪，也把“Agent 可以提出动作，但不能自行批准”落实成运行时约束。对自进化系统而言，经验库不仅要保存文本轨迹，还应记录任务与会话标识、配置版本、审批结果和状态变化，才能支持后续归因与重放。
可靠的 Harness 更新还需要像数据库事务一样执行：先保存快照，再隔离修改、解析依赖并完成验证，最后决定提交还是撤销。
DeepSeek Harness 的 Cordis 提供了组件替换和依赖管理所需的运行时基础。代码恢复到旧版本并不代表系统状态已经恢复，相应的监听器、缓存、计时器和服务引用等已产生的副作用也必须一起撤销。
事务式修改解决的是“一次 Harness 修改怎样安全执行和回退”，但它只覆盖单次更新的执行安全。经验如何形成候选修改、候选如何被选择和发布，以及结果如何继续影响下一轮 Agent，还需要一个完整的自进化闭环。
6. Model：改变 Agent 的默认能力和行为倾向
模型参数更新改变的是 Agent 在没有额外提示时默认掌握什么、倾向怎样判断，因此作用范围最大，也最难局部解释和撤销。
它适合任务模式高度重复且结构化、学习信号数量和质量足够，并且团队具备训练、评估、安全复验和版本治理能力的场景。随时变化的局部规则、个人偏好和租户特例通常不应直接写入模型参数。
执行经验可以被整理为训练样本，通过持续后训练、经验回放（Replay）或 LoRA 等轻量级参数更新方法写入新的模型版本，再由未参与训练的任务测试和 Held-out Gate 决定是否采用。但“能够周期性训练新版本”不等于模型会稳定地越用越强；旧能力遗忘、目标漂移、数据删除和全局回归仍需单独验证。
即使最终更新的是模型参数，用于保存执行轨迹、反馈和纠正记录的经验库，以及训练管道、评估、版本发布和回滚机制，仍位于模型之外。参数层面的可靠自进化，依然依赖操作脚手架提供完整的控制闭环。
7. 如何选择应该修改哪一层
一次失败出现后，不应直接把问题交给模型“再聪明一点”，而应先判断根因属于知识、接口、执行流程、基础能力还是治理约束，再选择作用范围最小、成本最低、最容易验证和撤回的更新对象。
事实或局部规则缺失，优先修改 Context 或 Memory；接口、参数和前置条件有误，优先修改 Tool 或 Skill；任务分解、状态转移、重试和恢复有问题，优先修改 Workflow 或 Harness；只有稳定、广泛的能力缺口无法通过较浅层的修改在未参与更新的任务上得到改善时，才考虑更新 Model。
身份、权限、审计和最高安全约束属于治理问题，不应交给同一个自修改循环。
不同对象的更新速度也不同：Context 和部分 Memory 最快，Tool、Skill、Workflow 和 Harness 居中，模型参数更新最慢。选择更新对象的原则不是“越深越好”，而是用最小且足够的修改命中根因。否则，系统可能用模型训练放大一个局部问题，或者把本应由代码强制的安全约束交给 Prompt。
四、执行经验如何变成能力
前面解释了经验写入不同对象后，Agent 的行为为什么会发生变化。但确定应该修改哪一层，还需要完整轨迹、责任归因、预先定义的验收标准和作用范围约束。
这些条件如何在学习闭环（Learning Loop）中把执行经验转化为可验证、可审计的候选更新呢？
1. 一个完整的自进化闭环
轨迹不会自行变成能力。
自进化需要形成一个闭合的学习闭环（Learning Loop），即系统从执行结果中发现问题，提出候选修改，经过独立验证后发布到下一版本，再根据真实运行结果决定保留、撤销还是继续改进。
新版本产生的执行轨迹、环境反馈和用户纠正反馈会再次进入经验库，成为下一轮改进的依据。没有写回，过程只是分析；没有持续观察，优化只是一次性的；没有独立选择，错误更新就可能被反复写回，形成污染回路。
从经验到可接受的更新，需要依次完成：保存执行现场、提炼稳定问题、预先定义验收标准、选择更新对象、生成候选修改、独立验证、分阶段发布、持续观察，以及最终撤销或巩固更新。
对应的完整链路是：
这条链路需要完成三件事：定位失败原因、生成并写入候选更新，以及根据独立证据决定保留、撤销还是继续观察。 生成候选前，还要通过优化契约明确目标、可修改范围、预算、数据边界、不可退化能力和发布条件。具体改进方式可以在这些边界内动态调整，所有人工介入都应进入版本来源与修改记录（Lineage）。
2. 学习闭环真正难在哪里
系统看到的经验本身并不完整。 Agent 当前的策略决定了它会遇到什么、避开什么，因此收集到的经验不是彼此独立、来自固定分布的样本。被过滤、人工接管、主动放弃或从未探索的任务不会自然进入经验库，成功也可能只是因为系统避开了难题。系统必须记录这些缺口，并通过受控探索或反事实评估补足，否则可能把任务范围缩小误判为能力提升。
一次失败往往无法直接归因到某个组件。 责任归因（Credit Assignment）既跨越多个执行步骤，也跨越 Memory、Tool、Workflow 和 Harness 等层级。最终失败可能源于早期检索、权限、工具或状态，也可能由多个组件共同造成。仅凭相关性不能判断应该修改哪一层，还需要版本化轨迹、最小范围干预、组件开关和反事实重放来验证。
真正重要的结果经常来得很晚。 快速的过程反馈可以筛除明显失败，但它可能无法反映最终目标，甚至诱导系统进行 Reward Hacking。只有较慢的真实结果，才能支持巩固更新或扩大作用范围。在长期结果尚未出现之前，候选更新只能被临时保留，不能直接扩大作用范围或写入更深层。
每次更新都会改变下一轮经验。 Workflow、Memory 或模型参数发生变化后，Agent 的行为和错误类型也会变化，旧评估集和原有阈值可能逐渐失去代表性。每个版本都应记录对应的数据分布、评估器和能力覆盖范围，并根据新失败扩充测试，同时保留用于长期对照的稳定测试集。
探索新策略可能影响生产安全。 重放和模拟适合进行较宽范围的探索，沙箱可以验证真实工具，小流量灰度（Canary）可以提供有限的生产证据，高权限动作仍需人工审批。探索预算、影响范围和停止条件必须提前写入优化契约。
多个更新回路可能相互干扰。 当 Context、Memory、Harness、模型和评估器以不同速度共同追逐短期指标时，系统可能反复振荡、不断堆积规则，或者多个回路共同迎合错误的评估指标（Coupled Goodhart）。浅层更新通常应当快而窄，深层更新则应更慢并提高证据门槛，同时尽量避免多个主要变量一起变化。
因此，学习闭环不能只关注迭代速度，还要关注候选数量、独立测试通过率、未见过任务上的保留增益、回归率和额外成本。否则，闭环越快，只会越快地把偶然相关固化成长期错误。
3. 如何形成完整的学习闭环
完整闭环可以压缩为四个阶段：保存并提炼经验、预先定义证据、选择并生成更新，以及验证、发布与巩固。每一阶段都要留下可追踪的输入、判断和结果。
保存并提炼经验（Capture & Mine）。 系统首先要保存完整的决策现场，包括任务、单次运行、完整轨迹和跨多次运行的连续记录（Task、Run、Trace 与 Thread），以及组件版本、动作、状态、环境反馈、人工介入和终止原因。随后从轨迹中识别稳定、可复现、可行动的失败模式（Failure Pattern），区分问题来自模型、工具、数据还是环境。聚类只能发现相似性，不能证明因果；环境噪声、无法复现的样本以及用户编辑、重试或接管，也都需要进一步归因。
DeepSeek Harness 采用只追加、不覆盖的会话日志，并支持恢复、分支、搜索和回放，为重建执行过程提供了运行时基础，但这不等于已经完成经验提炼。回放外部操作时，读取可以真实重放；不确定调用需要录制或模拟；写入则需要只演练不执行（Dry-run）、模拟接口（Mock）或补偿机制，避免重复产生副作用。
预先定义证据（Pre-Evaluate）。 候选生成前，系统必须明确原始失败应如何消失、哪些能力不能退化、允许使用多少预算，以及哪些安全和成本边界不能突破。可由程序检查的证据应优先于自由式文本评价；开放任务可以使用专家评分规则（Rubric）或评审模型（Judge Model），但Evaluator、候选生成器和发布者不应完全重合，评估集中还要保留候选生成器不可见的部分。
选择并生成更新（Route & Repair）。 完成归因后，系统要选择主要更新对象，并决定更新只对个人、团队还是整个组织生效。一次同时修改多个层级，会削弱责任归因并增加撤回难度。生成的 Context、Memory、Tool、Skill、Workflow、Harness 补丁或参数训练数据都只是候选更新，必须记录来源、适用范围、依赖、版本、预期变化和回滚方式。更新越接近完整运行时或模型参数，越应限制编辑范围并保持最小改动。
验证、发布与巩固（Post-Validate, Release, Observe & Consolidate）。 每项候选更新至少要通过四类检查：原始失败是否修复（Held-in）、未参与修改的同类任务是否改善（Held-out）、已有能力是否退化（Regression），以及成本、安全风险和外部副作用是否可接受。通过沙箱测试后，更新还应根据影响范围进入小流量灰度、人工审批或正式版本，并持续观察性能漂移和新的失败类型。
多次验证都稳定成立的经验，才适合从单次事件提炼为事实、行动方法，甚至模型参数：
局部、易变、需要随时撤销的知识可以长期留在 Context；只有稳定、通用并经过充分验证的模式，才适合训入模型参数。
闭环也必须允许做减法：删除没有增益的组件、清除受污染的 Memory、淘汰过时的 Harness，避免持续学习退化为组件和规则的持续堆积。
学习闭环不会自动把经验变成能力，它只能把经验转化为可追踪、可验证、可撤回的候选更新。只有失败原因能够被定位、修改范围受到约束、候选通过独立验证，并在发布后持续产生净增益，经验才可能沉淀为能力。
即使候选通过发布门，也只能说明它可以在有限范围内上线，不能证明 Agent 已经进化。更多采样、人工介入或搜索集泄漏同样可能提高分数。
那如何判断观察到的增益能否真正归因于自进化呢？
五、如何证明 Agent 真的进化了
1. 分数上涨为什么不等于能力上涨
一次性能上涨可能来自持久更新，也可能来自更多计算和采样、候选筛选、环境变化或人工介入。
这些因素还可能相互影响，因此不能从分数上涨直接推断 Agent 获得了新能力。可靠的实验结论必须对齐计算量、Token、实际运行时间和人工投入，并严格分离候选搜索（Search）、验证（Validation）和最终测试（Test）。
判断自进化是否成立，最有效的方法不是先接受分数，而是先寻找能够解释分数的其他原因，再用针对性实验逐一排除：
观测现象尚未排除的其他解释必要实验Benchmark 分数提高搜索样本被写入更新对象独立的未见任务测试（Held-out Test）Pass@K 提高增加采样，而非单次能力提高等预算下的 Pass@1 与成本对齐原始失败被修复只针对单个案例打补丁同机制、未见任务的迁移测试新 Skill 被生成文件存在，但行为没有改善Skill 开关消融与依赖失效测试Harness 自改后得分提高改写评估、跳过测试或隐藏失败受保护的外部评估器与执行审计参数更新后局部性能提高局部增益伴随其他能力退化跨能力回归测试线上成功率提高环境、工具或人工介入发生变化版本对照、环境控制和人工预算对齐
这张表构成判断有效自进化与可靠自进化的最低证据链。只证明原始失败消失，最多说明候选修改修复了当前问题。只有排除其他解释后，才可能把增益归因于持久能力更新。
2. 什么样的证据才能证明能力增长
验证尺度必须与更新持续生效的范围匹配：单步尺度（Run-level）检查一次决策，任务尺度（Trace-level）检查一次端到端任务，跨任务尺度（Thread-level）检查多次任务之间的记忆、状态和行为变化。
前两者反馈快，却看不到跨会话污染，而参数更新和长期 Memory 不能只靠短期 Benchmark 验证。一个可信的实验不仅是一个分数，还需要更深层的分析：
• 完整性能轨迹、多个随机种子及结果波动；
• 计算量、Token、实际运行时间和人工投入；
• 未见任务迁移与回归率；
• 安全违规、成本和延迟；
• 使用基于指标还是基于评审模型的评估器；
• 评审模型使用的模型、Prompt、评分规则（Rubric）、Context 和预算。
同一个评审模型不应既提供主要学习信号，又担任最终裁判。将候选生成器与验证器分离，可以降低两者共享相同盲点的风险，但不能彻底解决开放任务缺少可靠判断标准的问题（Oracle Problem）。最终仍要结合环境证据、专家判断和真实使用结果。
3. 为什么不同研究会得出相反结论
Harness 自进化研究说明，同一种技术路线也可能因评估方式不同而得到相反结论。
《Rethinking the Evaluation of Harness Evolution for Agents》在统一预算下发现：缺少可靠外部信号时，Harness 自进化可能不如简单采样；收益也可能主要体现在多次采样至少成功一次的 Pass@K，而不是反映单次能力的 Pass@1；严格分离候选搜索、验证和未见任务测试后，平均迁移增益接近于零。
这意味着，Harness 自进化带来的分数提升可能只是扩大了搜索和采样，而不代表 Agent 的单次、可迁移能力真正提高；只有在预算对齐和严格数据隔离后仍然保留的增益，才能归因于自进化。
与此同时，Self-Harness、Meta-Harness 等研究在未见任务、分布外任务或跨模型测试中报告了改进。这些结果并不必然矛盾，因为它们在可编辑范围、反馈方式、数据隔离、预算协议和评价指标上并不相同。
不同方法只有在统一预算和测试协议下比较，结论才有可比性。Harness 被修改，只能证明发生了更新；在未见任务上优于等预算基线，才能说明更新可能有效；跨版本保持成本、安全和权限稳定，才接近可靠进化。
4. 评估器既决定进化方向，也可能被系统利用
评估器决定哪些修改能够被保留，因此系统可能学会提高分数，而不是真正提高能力。
常见的一些利用方式，比如利用奖励定义中的捷径（Reward Hacking）、记住固定评测分布（Benchmark Overfitting）、让多个更新回路共同迎合指标（Coupled Goodhart），以及通过修改运行时跳过测试、隐藏失败或扩大权限（Agent Hacking）。
候选生成能力强于评价能力时，系统会更快找到评估规则的漏洞。而当评价能力更强时，进步可能较慢，但错误更新更难被保留。因此，可修改空间只决定系统能产生多少变化，可验证空间才决定其中多少能够被可靠接受。
可验证空间取决于优化契约、验证预算、数据隔离、风险容忍度和反馈质量，并不是组件的固定属性。可重放、能够执行测试的 Harness 修改较容易验证，缺少及时结果反馈的长期开放任务则很难验证。
评估器既决定进化方向，也可能成为候选更新钻空子的对象。修改权、评价权和发布权如何分配，最终决定系统能否区分能力增长与指标投机。
六、Agent 自进化的边界与未解问题
1. 当前自进化机制的能力边界
现有 Agent 自进化机制的边界可以直接概括为四点：
• 适用任务有限。 当前最可靠的是目标明确、结果可验证、环境可重放的任务，例如代码与终端操作；开放知识工作、长期协作和高风险生产任务仍缺少可靠的反馈与验证机制。
• 改进范围有限。 Prompt、Memory、Skill、Workflow、Harness 和模型参数都已可以根据执行经验更新，但多数成果仍是特定任务和受控环境中的局部改进，尚未证明能够长期、跨领域稳定迁移。
• 递归程度有限。 STOP、DGM 等研究表明，负责改进 Agent 的机制也可以被修改，但目标、任务、评价标准和版本选择仍由外部定义或监督。受约束的递归改进已经可以实验化，开放式递归自我改进（RSI）尚未实现。
• 自主权有限。 Agent 可以提出和执行候选修改，但不能同时掌握目标定义、最终评价、最高权限、发布审批和恢复机制，否则系统将无法区分能力增长与评价标准被改写。
因此，当前 Agent 自进化的准确边界是：系统已经能够在受控范围内根据经验修改自身，并通过外部验证积累局部能力；但还不能在开放环境中长期自主地设定目标、修改评价标准并证明自己持续进步。
2. 研究前沿与尚未解决的问题
Agent 自进化的研究重心，正从扩大可修改范围转向提高候选更新的选择与验证可靠性。
这一方向仍面临四类关键问题：
• 长期稳定与遗忘。 少量任务或有限轮次上的提升，不能证明系统长期运行后仍然有效。自进化可能逐渐造成能力退化、行为漂移和知识污染，而错误经验一旦写入模型参数，也很难准确删除。
• 开放任务缺少可靠的评价标准。 代码可以通过编译器和测试判断结果是否正确，但研究分析、经营决策、法律意见和战略规划往往没有唯一正确答案，其质量还取决于事实依据、适用情境、风险权衡和长期结果。固定评估器容易过时，让评估器与候选生成器一起变化，又可能使二者共同迎合错误指标。如何持续可靠地判断“哪个版本更好”，是递归自进化的核心难题。
• 多 Agent 共同进化难以归因。 一个 Agent 的更新可能改变团队分工、通信方式和其他 Agent 接触的数据，因此系统表现的变化很难归因于某个 Agent 或某次更新，单体测试也无法覆盖协作关系变化产生的新问题。
• 短期收益可能损害长期质量。 一次任务成功，不能说明新版本更容易维护、兼容旧系统或适合长期使用。自进化可能用更高的复杂度、迁移成本和组织依赖换取短期分数。
因此，Agent 自进化的下一阶段不在于生成更多修改，而在于能否在长期、开放和多 Agent 环境中，可靠判断哪些修改带来了真实、可持续的能力增长。
小结
Agent 自进化有三个误区要注意：任务内反思和重试不等于自进化，生成新的 Memory、Skill 或 Harness 不等于能力提升，评测分数上涨也不等于获得了可迁移、可靠的新能力。
实践中，应根据见效速度、预期收益和实施难度选择更新方式。对于局部知识、规则或检索问题，优先调整 Prompt、Context 或 Memory，见效最快、成本最低，也最容易验证和回滚。
对于反复出现的工具使用、任务分解和执行流程问题，再考虑更新 Tool、Skill、Workflow 或 Harness，投入和风险更高，但更可能形成稳定、可复用的收益。
只有当某类能力缺口长期存在、影响范围广、训练数据和评估体系都足够成熟，并且预期收益能够覆盖训练与全局回归成本时，才适合更新模型参数。
无论修改哪一层，都应先小范围验证，再根据实际净收益决定是否扩大应用。判断标准不是分数是否提高，而是更新能否在相近成本下改善未见任务，同时不带来不可接受的回归、安全风险和维护负担。
References
1. “Self-Improvements in Modern Agentic Systems: A Survey”, arXiv, 2026. https://arxiv.org/abs/2607.13104
2. “SIA: Self Improving AI with Harness & Weight Updates”, arXiv, 2026. https://arxiv.org/abs/2605.27276
3. “Self-Taught Optimizer（STOP）: Recursively Self-Improving Code Generation”, arXiv / COLM, 2024. https://arxiv.org/abs/2310.02304
4. “AFlow: Automating Agentic Workflow Generation”, arXiv, 2024; ICLR, 2025. https://arxiv.org/abs/2410.10762
5. “Meta-Harness: End-to-End Optimization of Model Harnesses”, arXiv, 2026. https://arxiv.org/abs/2603.28052
6. “Self-Harness: Harnesses That Improve Themselves”, arXiv, 2026. https://arxiv.org/abs/2606.09498
7. “DeepSeek Harness developer preview: Everything is a plugin”, DeepSeek, 2026. https://deepseek.com/harness/en/
8. “Rethinking the Evaluation of Harness Evolution for Agents”, arXiv, 2026. https://arxiv.org/abs/2607.12227
9. “Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents”, arXiv, 2025; revised 2026. https://arxiv.org/abs/2505.22954
10. “Rethinking Self-Evolving Agents: Do We Still Need Prescribed Optimization Pipelines?”, arXiv, 2026. https://arxiv.org/abs/2608.09629
11. “Codex as a platform: build on the open agent harness”, OpenAI, 2026. https://developers.openai.com/blog/codex-as-a-platform
12. “Unlocking the Codex harness: how we built the App Server”, OpenAI, 2026. https://openai.com/index/unlocking-the-codex-harness/
13. “How enabling two settings tripled our scores on ARC-AGI-3”, OpenAI, 2026. https://openai.com/index/how-two-settings-tripled-our-arc-agi-3-scores/
14. “openai/codex”, GitHub, 2026. https://github.com/openai/codex
