从执行结果到技能更新的学习路径是可编程的

2026 年 4 月，Nous Research CEO Jeffrey Quesnelle 做了一次公开演示：让 Hermes Agent 在数十个独立会话中自主撰写一篇 79,000 字的小说。这项任务要求 Agent 跨越数周时间、维持角色设定与情节线索的一致性，且每次会话重启后不丢失上下文。

在传统 Agent 架构中，这种长程任务几乎必然走向崩坏——每次新会话都是一次失忆，用户被迫反复粘贴背景、重申偏好。但在 Hermes 的演示里，Agent 不仅记住了剧情脉络，还从每一次写作经验中提炼出了叙事技巧，将其沉淀为可复用的技能文件。

这个演示揭示了一个关键事实：从执行结果到技能更新的学习路径，本质上是一段可定义、可管理、可编程的自动化流水线。当其他 Agent 框架仍将“学习”视为模型参数微调或用户手动维护的笔记时，Hermes 已经将其提升为工程系统的第一等能力。

这意味着你不再需要思考“怎么让 Agent 学会这个”——你只需定义学习流水线的规则，Agent 自己的执行历史就是它的老师。

现象：经验的半衰期与自动化的必要性

Agent 在真实生产环境中面临一个与人类知识工作者相同的困境：经验的半衰期极短。

一个复杂任务通常包含多步推理、工具调用、错误处理和上下文判断。如果这些经验只存在于当次会话的上下文窗口中，会话结束之时就是知识消亡之时。即便你手动把经验整理成提示词或知识库文档，下一次任务的差异性也可能让这些静态记录迅速过时。

Hermes 给出的解决方案是闭环学习路径（Closed Learning Loop）：任务执行完成后，系统自动将解题过程、有效策略、失败路径等经验固化为结构化的技能文件（SKILL.md），下一次遇到类似任务时直接加载这些技能，不再从零开始推理。

这条流水线包含三个关键阶段，每个阶段都是可编程的：

理解这三个阶段如何协同工作，是构建自进化 Agent 系统的核心。

第一维度：成功任务的模式提取

Hermes 学习流水线的第一阶段，是让 Agent 具备“从自己成功完成的任务中抽象模式”的能力。这并非简单的日志记录，而是一次结构化的逆推过程。

当前调研资料显示，Hermes 的技能提取基于一个核心流程：Agent 分析对话日志，识别出任务的关键步骤、使用的工具、工具调用的参数模式以及决策分叉点，然后将这些信息提取到一个独立的 SKILL.md 文件中。这个文件包含：

• 元数据块：技能名称、触发描述、参数列表
• 执行步骤：结构化的步骤序列
• 前置条件与输出：明确输入输出契约
• 置信度评分：反映该技能在类似场景下的成功率

举个例子：假设某次任务中 Agent 成功地从一组 PDF 中提取了表格数据并完成了统计分析。经验捕获流程会自动生成一个名为 pdf-table-extract-analysis 的技能文件，其中记录了“先用 PyMuPDF 解析表格结构，再用 pandas 清理缺失值，最后用 matplotlib 生成可视化”的完整路径。下次遇到类似任务，Agent 直接加载这个技能作为起点，而不是从工具列表里重新摸索。

这里有一个重要的工程决策点：什么触发技能提取？

Hermes 采用的是组合触发机制：

这种组合机制确保了技能库既能自动生长，又不至于被无效经验污染。

第二维度：失败任务的修正学习

如果说成功任务的模式提取是“正向学习”，那么失败任务的修正学习就是“负向学习”——两者同等重要，且后者的工程实现往往更复杂。

当前调研资料明确提到，Hermes Agent 能在任务执行失败后，自动将失败的路径、错误原因和修正策略记录到 MEMORY.md 文件中，形成避坑指南。但具体的错误分类策略与修正建议生成逻辑在公开资料中尚未详细展开。

根据现有代码仓库的提交记录与社区讨论（参见 GitHub Issue #38552 关于 Automated Workspace Memory 的提案），我们可以梳理出修正学习的关键步骤：

1. 失败识别：Agent 通过 LLM 输出的完成状态、工具调用的异常返回或用户反馈来判断任务是否失败。
2. 根因定位：分析对话日志中失败前的 N 步操作，识别因果链。这里 Hermes 使用了 LLM 摘要技术对长对话进行压缩后再做分析。
3. 修正策略生成：基于失败原因生成一个或多个修正方案，记录在 MEMORY.md 的 ## Pitfalls 部分。
4. 关联技能更新：如果失败与某个已有技能相关，降低该技能的置信度评分，并追加边界条件说明。

举个实际的工程场景：Agent 尝试通过 SSH 连接到一台服务器执行部署脚本，但因为目标服务器的 SSH 端口不是默认的 22 而导致连接超时。修正学习流程会：

• 在 MEMORY.md 中记录：“SSH 连接前需显式检查端口配置，不要假设默认端口 22”
• 更新 remote-deploy 技能，在步骤中增加“端口确认”环节
• 将 remote-deploy 技能的置信度从 0.9 降至 0.8，直到通过后续成功执行恢复

这整个流程完全由 Hermes 的自动化流水线驱动，开发者只需要定义 MEMORY.md 的存放路径和触发条件即可。

第三维度：技能更新的审核与回滚

如果技能更新完全自动化且无任何监管，Agent 很快就会陷入“技能退化”——一个错误的经验可能毒化后续所有基于该技能的任务。

Hermes 对此的解决方案是引入了技能更新的审核与回滚机制。从当前调研资料来看，这个机制的核心组件是 versions 表（技能版本历史记录），以及一个可选的人工审批门控。

具体的工作流程如下：

1. 技能变更提案：当 Agent 要从经验中创建新技能或更新现有技能时，它并不直接写入主技能文件，而是生成一个“变更提案”（diff 文件）。
2. 自动测试：系统使用该技能的测试用例（若存在）对新版本进行回归测试。测试用例可以是用户预先定义的输入-输出对，也可以是 Agent 自己从历史成功案例中提取的。
3. 审批门控（可选）：如果配置了人工审批，提案会被发送到指定的审核渠道（如企业微信、飞书、Email）。审核者可以批准、拒绝或要求修改。
4. 版本归档：无论审批结果如何，每次变更都被记录在 versions 表或 git 历史中，支持一键回滚到任意历史版本。

以下是一个技能版本管理的实际对比：

在实际工程落地中，建议对技能采用分级管理策略：

• L1 技能（核心业务流程相关）：必须走人工审批 + 自动测试双门控
• L2 技能（效率类辅助技能）：自动测试通过即可自动上线
• L3 技能（实验性技能）：不自动更新，仅记录建议，由用户手动采纳

这种分级机制让学习路径的可编程性从“自动无脑执行”变成了“按规则精准执行”，既不损失效率，也不牺牲可控性。

结论：学习路径作为一等架构特性

回顾本章的核心论点，我们可以得出一个清晰的结论：

Agent 的学习路径不应是模型训练的黑箱，也不应是用户手动维护的外挂——它应当是一条可观测、可版本化、可按需回滚的工程流水线。 Hermes Agent 的实践证明，将经验捕获、技能抽象、版本管理三个环节串联为闭环，就能让 Agent 表现出近似“持续成长”的行为特征。

下面的对比表格总结了传统方法与可编程学习路径的关键差异：

按场景推荐：

• 如果你正在构建一个面向个人的研究助手，建议启用完整的自动学习流水线，人工审批设为可选，快速积累领域技能。
• 如果你要为企业内部部署一个自动化运维 Agent，核心技能（涉及生产服务器操作）必须走审批门控，并配置自动回归测试。
• 如果你的 Agent 需要跨团队共享技能，务必采用 agentskills.io 兼容格式，并建立共享技能仓库，实现跨实例的知识迁移。

这条从“执行结果”到“技能更新”的流水线，让 Agent 的记忆与能力不再依赖于单次推理的偶然正确，而是通过工程化的手段实现了可积累的成长。

然而，当技能不断累积、记忆持续增长，一个新的挑战浮现出来：Agent 面对越来越长的对话历史和知识库，如何在不丢失关键信息的前提下控制上下文长度？下一章我们将探讨 上下文压缩算法是长对话 Agent 的生命线——你将在其中看到从滑动窗口到结构化摘要的不同压缩策略，以及如何在精度与成本之间做出最优权衡。