自进化Agent

简介（未整理）

从“怎样把任务持续运行下去”推进到“任务结束以后怎样从中学习”。Harness/Agent干过的活，存下来的 Memory 和 Skill，就放在那儿；下次遇到类似问题，它会不会真用上、用上了有没有变好、上次那条经验是不是已经过时了。过去这一步全靠人：任务结束后，得有人回头把记录看一遍，把该补的事实补进记忆，把能复用的做法整理成方法。可什么时候该整理、要检查哪些，只要没人惦记，这事就直接略过去了。更现实的是，一个人一天能盯几个 Session？线上一天成百上千次请求，靠人一条条翻根本看不过来，真正有价值的经验就藏在这些轨迹里。自进化，就是把复盘这件事从人手里接过来：系统自己从经历里学、自己改自己。

模型从自然语言的分布中学习到了生成非结构化文本序列的能力；接下来神奇的是，模型从语言中也学到了推理和规划的能力。或者一部分是出于偶然，人类的自然语言中本就存在着如何拆解任务、执行任务的模式；又或者是模型训练者刻意构造数据，刻意强化了模型在这方面的能力。总之，模型一旦具备了规划、执行的能力，可以想象，只要配置合适的工具，模型下一步很快也会对物理世界产生影响。但不管是驱动数字世界还是驱动物理世界，都需要「精确」的流程，而非模糊的序列。精确执行，这似乎与模型的概率学本质相悖。在这里，随机性实际上表现为某种自主性：针对同一个任务目标，模型可以自主地找到可行的执行路径，甚至在一条路径碰到障碍时自动尝试新的路径。当然，它并不能保证总是成功，稳定性的隐患总是存在。AI的自主执行对于数字世界（甚至物理世界）是有实际影响的，因此执行的安全性就有非常迫切的要求，对于产品形式的设计也会有较大的影响。

对于 Agent 来说，经验积累，就是持续提升学习能力，这项能力大致沿着这样一条路线发展：任务内适应 → 长程连续运行 → 跨会话记忆 → 经验技能化 → 评测驱动的自进化 → 多 Agent 集体进化。

自进化/Self-Evolving

Hermes引入了一种动态的Skill沉淀机制（把做过的事变成会做的事）。在每次完成复杂任务，尤其是那些经历了曲折路径或人工干预的任务后，Hermes不会简单地丢弃对话历史，而是会启动一个“复盘”流程。它会回过头来审视整个执行轨迹(Trajectory)，提取其中的关键步骤，特别是那些“踩过的坑”、有效的纠错手段以及人工验证过的最佳实践。随后，系统将这套经验总结、抽象为一个结构化的Skill技能文件包。这就带来了一个根本性的转变：Skill从“静态调用”变成了“动态生成”。当 Hermes 下次遇到类似问题的时候，Agent也就不再是从零开始探索，而是直接读取并复用已有的沉淀好的Skill。通过这种方式，Hermes 实现了真正的“吃一堑，长一智”。

通过动态生成 Skill 沉淀实现的“外挂式”进化在时效性和可解释性上表现优异 —— 毕竟明文记录的 Markdown 文件允许人工进来进行干预和纠偏，但我们必须承认一个事实：这并不是真正意义上的“自进化”或者“自我学习”。因为无论 Agent 积累了多少 Skill，其底层的“模型权重”始终没变。对于追求极致性能、或在特定垂直领域需要突破通用模型瓶颈的场景来说，这种基于Context Engineering的优化方式依然存在着天花板。因此，Hermes 引入了第二条更深层、更直接的进化路径：基于强化学习（RL）的模型训练闭环。它就是在通过改变模型权重，实现真正的能力“自进化”。整个RL训练过程分阶段来看，主要是下面几个部分：

1. 任务定义：用户可以指定具体的训练目标，例如“提升数学推理能力”或“优化特定业务问题”的成功率。
2. 轨迹捕获 & 批量数据合成：Hermes 内置了批量处理模块batch_runner.py，能够自动去合成Agent的运行轨迹（Trajectory），并且筛选过滤出高质量的数据集（轨迹数据生成 、压缩）。然后将这些轨迹数据清洗并转换为标准的ShareGPT格式，为后续的模型训练提供高质量的“原料”。
3. 渐进式训练与自动评估：为了降低试错成本，Hermes 采用“小步快跑”策略：先使用小规模数据集进行实验性训练，验证可行性后，再启动正式的大规模训练。训练结束后，系统会自动评估（Evaluate），分析各项指标是否有显著提升。如果效果未达预期，反馈信号将指导下一轮的参数调整或数据优化；如果效果显著，则将该版本模型固化。
4. 渐进式训练与自动评估：为了降低试错成本，Hermes 采用“小步快跑”策略：先使用小规模数据集进行实验性训练，验证可行性后，再启动正式的大规模训练。训练结束后，系统会自动评估（Evaluate），分析各项指标是否有显著提升。如果效果未达预期，反馈信号将指导下一轮的参数调整或数据优化；如果效果显著，则将该版本模型固化。

RSI(Recursive Self-Improvement)

我们认为把“运行任务 → 排查失败轨迹 → 修改 Agent → 重新评测”的闭环交给 Agent 自动迭代在跨轮次间保留有效改动，系统就能持续自我演进；当演进过程本身也成为优化对象，便进入递归自改进（RSI）。

人今天学会了 Java，晚上突触就长出来了，明天照样会写——学习这件事物理性地改写了大脑本身。大模型完全相反：它跑完一件事、”解决”了一个问题，参数权重一个字节都不会变，下次启动还是那个出厂模型；如果我们不把这次的经验、结论、教训持久化到外部存储、下次通过 context 再喂回去，等于什么都没发生过。所以 Agent 不会”自动变强”——它只在你为它建了外部记忆的那部分变强。

普通 Coding Agent Loop 的目标，是使用当前系统完成当前任务。失败之后，它修改代码、重新运行，直到测试通过或者达到停止条件。RSI 进一步追问：这次执行产生的经验，能否反过来改善执行下一次任务的系统？这里需要特别澄清：递归自我改进不等于模型每完成一次任务就重写自己的权重。从工程实现看，更现实的第一阶段通常发生在模型外部：

1. 更新任务策略和系统提示词；
2. 把人工纠正沉淀成可复用 Skill；
3. 为高频问题增加新的工具；
4. 改进记忆检索和上下文组织；
5. 建立更可靠的测试集与验证器；
6. 调整路由、权限、重试和停止条件；
7. 收集高质量轨迹，再用于后续训练或微调。 大模型行业的竞争重心，正在从一次性生成能力，转向长期运行、自动验证、经验积累与系统改进。 真正的瓶颈：生成越来越便宜，验证仍然昂贵。Coding Loop 能首个跑通，是因为测试相对便宜。

用两根轴把这堆「self-refine / self-reward / self-play / self-evolve」的词汇摊开：改什么 × 谁验收

1. 系统改的是什么，部署期自演化（改输出、脚手架、技能库，权重不动）、训练期自迭代（改权重）、自我评价（改评价器本身）、自动研究（改研究流程）。
2. 谁来验收这次改动，分三档：人审每一次改动、信号自动但人审结果、以及生成/验证/应用全自动的闭环。
3. 改进信号的来源，是不是还留在系统够不着的地方。

自我改进必须是个闭环：经验存下来，还要能在新任务上比较新旧方法，结果一旦变差，查得出是哪次改动带来的、退得回原来的版本。

RSI 的目标：逐渐把人移出 improvement loop，可以粗略理解成三个阶段：

1. Human-in-the-loop（人在环路）：AI 提出改进，但每次修改都需要人确认。
2. Human-on-the-loop（人在环上）：data、reward、verifier 等已经可以自动产生，人主要负责监督结果和控制部署。
3. Closed loop（闭环）：系统自己产生、验证并应用改进，不再需要人工审核。

按改进对象分三层

1. 靠训练改进模型。Agent 先跑出一批 rollout，就是它跑任务留下的完整轨迹。这些轨迹攒起来、筛过，拿去更新权重，得到下一代模型，再放回 Harness 当底座
2. Harness 本身是代码。Code Agent 会写代码，于是可以直接改自己下一次运行依赖的那部分，下次启动就跑在改进后的自己身上，有点像编译器自举。
3. 更新 Memory 和 Skill。Hermes 的官方表述是，Skill 就是它的程序记忆，Memory 就是陈述性记忆，两者一起构成自我改进循环。这一层不用动模型权重，也不必先打通训练管线，每一条事实和方法都读得见、审得了、能版本化，将来换了底座模型，这套积累还在。

    if (
        final_response
        and not interrupted
        and (_should_review_memory or _should_review_skills)
    ):
        agent._spawn_background_review(
            messages_snapshot=list(messages),
            review_memory=_should_review_memory,
            review_skills=_should_review_skills,
        )
   

memory

(Hermes)复盘模型要做的，是在提示词引导下自主判断，这次对话里有没有值得记住或需要修正的内容，再决定改哪条、用 add、replace 还是 remove。

Review the conversation above and consider saving to memory if appropriate.

Focus on:
1. Has the user revealed things about themselves — their persona, desires, preferences, or personal details worth remembering?
2. Has the user expressed expectations about how you should behave, their work style, or ways they want you to operate?

If something stands out, save it using the memory tool. If nothing is worth saving, just say 'Nothing to save.' and stop.

从 Rollout 中自主创建 Skill

_SKILL_REVIEW_PROMPT 要求模型主动回顾执行经历，寻找能够用于后续任务的新经验。

回顾本次会话，主动寻找值得学习的内容。重点检查：
1. 用户是否纠正了操作流程、执行步骤、输出格式或表达要求？
2. 是否发现了新的有效技术、调试路径、修复方法或工具使用方式？
3. 本轮使用的 Skill 是否暴露了新的问题？
发现值得学习的经验时，应考虑将其保存到技能库。只有没有合适的已有 Skill 时，才创建新 Skill。没有产生值得保存的内容时，可以不做修改。

_LESSON_LAYER_BLOCK 规定 Skill 的编写方式。

Skill 应当指导 Agent 高效、正确地完成一类任务。

1. Procedure first。按操作顺序写清步骤、具体工具调用和关键决策点。将经验教训融入对应步骤。
2. 提炼通用规则。说明应该怎样做，以及为什么这样做。不要将本次事故的经过写成操作说明。
3. 去除一次性信息。不保留工单编号、日期和事故流水账。
4. 避免重复。不重复已有规则和工具本身的使用说明。
5. 分层组织
   SKILL.md 保存始终需要遵守的核心规则。
   references/ 保存按需查阅的详细资料。

_DO_NOT_CAPTURE_BLOCK 排除不可靠的经验。

不要保存：

1. 缺少依赖、凭据未配置、路径错误等依赖当前环境的临时问题。
2. 因为一次调用失败，就断言某个工具或功能永久不可用。
3. 已经恢复的一次性错误。如果重试解决了问题，应记录有效的重试方式。
4. 只描述单次工单或事故经过的任务记录。
5. 尚未找到有效解法，却被包装成可靠流程的失败尝试。

如果工具因环境配置而失败，应记录经过确认的修复步骤，而不是将工具判定为不可用。

例如，Agent 在排障时发现某个诊断工具无法运行，后来确认只是环境缺少依赖。这时，不能把“这个工具不可用”写成长期规则。如果安装依赖的方法具有复用价值，可以记录有效的配置步骤。这组指令的作用，是避免临时环境问题和未经验证的操作，在后续任务中被当成长期有效的规则。三组指令共同约束一次技能复盘：主动寻找学习机会，将执行经验组织为通用技能，并排除不可靠的内容。

小结

大模型和通用 Harness 可以提供基础能力，但企业自己的业务规则、知识边界、验收方式和风险责任，仍需要工程师完成设计与落地。自进化也不会自动让 Agent 变得可靠；相反，它会把长程运行、状态管理、经验积累和版本更新中的问题进一步暴露出来。当 Agent 开始从工作中学习，工程师还要对它记住什么、改变什么，以及如何证明这些变化有效负责。具体而言，Agent 工程师需要具备以下三方面能力：

1. 理解并选择 Harness。 看懂不同 Harness 如何组织任务执行、状态管理、上下文、工具调用和权限控制，理解设计取舍，判断哪些能力可以复用，哪些需要结合业务扩展。
2. 把业务要求落实为系统设计。 将岗位目标、工作方法、责任边界和验收标准转化为任务流程、工具权限、人工介入和结果检查机制，让 Agent 的工作可观察、可验证、可控制。
3. 构建受控的进化闭环。 从运行轨迹、工具结果和人工纠正中提炼 Memory 与 Skill 候选，通过评测、审批和发布每次更新，让有价值的经验沉淀下来，也让错误变化能够被发现和撤回。