Agent 为什么会越用越顺手？技能沉淀、自我改进与复用机制

摘要

Agent 越用越顺手，不是因为它在背后神秘地自动升级，而是因为两类东西被有结构地保留下来：稳定事实进入 Memory，可复用方法沉淀为 Skill，并在合适的场景被重新加载。Memory 让它知道发生过什么——被 query 命中就召回；Skill 让它知道下次遇到同类问题该怎么做——场景匹配就装载。二者的触发方式、表达形式与演化速度都不同，因此不能合并。Hermes 提供 /learn 让 Agent 把会话中值得沉淀的流程提炼成 SKILL.md，并通过 /skills pending 审批，避免"无边界自改"。一份合格的 Skill 必须写清四件事：何时使用、按什么步骤执行、成功标准是什么、哪些边界不能越过。真正的关键不在于沉淀得多，而在于它可审查、可复用、可在产品变化时被更新。

引子：经验如果不能复用，就只是一次聊天

回想一次配合得特别好的协作。你和 Agent 一起排查了一个问题，或者产出了一篇质量不错的发布说明。过程中你纠正了它三四次：范围要收窄、格式要统一、某个检查项不能漏。最后结果令人满意。

一周后同类任务再来。如果那些纠正只留在上次的聊天记录里，你会发现自己在重复同样的话——上次的调优没有变成资产，只变成了一次性的消耗。

这就是"越用越顺手"这件事的核心命题：不是让 Agent 变得神秘地更聪明，而是让已经验证过的东西被结构化地留下来。留什么、怎么留、留在哪里，决定了它是真的在积累，还是每次从零开始。

一、两类积累，不能混为一谈

Agent 的积累分两类，它们的性质完全不同。

举一对具体例子来对照：

• "这位用户偏好结论先行" → 这是 Memory。它是一条关于你的事实。
• "写发布说明前先核对版本号与链接是否有效" → 这是 Skill。它是一段遇到某类任务就该执行的流程。

两者不能合并，原因至少有三条：触发方式不同（query 命中 vs 场景匹配）、表达形式不同（短句条目 vs 步骤流程）、演化速度不同（每天变 vs 几个月不动）。把稳定的流程和高频变化的事实混在一处，稳定的部分会被冲刷掉。完整论证见《Memory 不是 Skill：Hermes Agent 的事实记忆与程序性记忆有何不同？》。

理解这个区分有直接的实践价值：当你发现自己在重复纠正同一类做法时，需要沉淀的是 Skill，不是往记忆里再加一条事实。

二、Skill 长什么样

Hermes 里一份 Skill 通常是一个 SKILL.md，头部带 YAML frontmatter 声明触发条件与配套信息。它的形态大致是：

---
name: release-note-format
trigger:
  when: "user asks to write release notes"
---

# 写发布说明的标准流程

1. 确认版本号与发布日期
2. 按「新增 / 修复 / 变更」三类归集
3. 核对每个外部链接可访问
4. 检查是否包含内部项目名或端口，若有则替换为占位名
5. 输出前确认长度符合发布渠道限制

关键在于 trigger：它让 Skill 不需要你每次手动调用，而是在识别到匹配场景时被自动装载成高优先级提示，指导本次行动。

Hermes 还提供两层组织能力：

• Skill Bundle：把相关 Skill 打包成一组整体启用、停用或分享。例如"发布流水线"这个 bundle 可以包含发布前检查、变更日志格式、回滚步骤三份 Skill。
• fallback_for_toolsets：Skill 可以声明"当某个工具集调用失败时兜底"，让异常路径也有明确的处理流程。

这两层让 Skill 从单点 SOP 变成可组合的工作方法论。

三、/learn：把一次成功的流程变成方法

沉淀 Skill 不需要你离开对话去写文件。Hermes 提供 /learn 命令，让 Agent 把当前会话里"值得沉淀成 Skill 的一段流程"提炼成新的 SKILL.md。

这个设计的价值在于沉淀发生在记忆最清晰的时刻。刚刚完成一次协作，你和 Agent 都清楚哪几步是关键、哪个纠正是必要的。如果等到一周后再补写，细节已经流失。

但自动提炼带来一个必须解决的问题：如果 Agent 能随意给自己增加行为规则，它的行为就会变得不可预期。 Hermes 的处理方式是引入审批环节——通过 /skills pending 查看待确认的 Skill，由你决定是否采纳。这与 Memory 侧的 /memory pending 是同一种设计思路。

自我改进不等于无边界自改。 可靠的改进路径是：新方法先变成一条可审查的规则，经过确认后才生效。这样 Agent 的能力增长才是可解释、可复用、可纠正的。

四、一份合格的 Skill 必须写清四件事

这是决定 Skill 有用还是有害的关键。四要素缺一，Skill 就会在实际使用中失效或产生副作用。

第一，何时使用。 触发场景要具体。"处理文档时"太宽，会导致在不该触发的场景被装载；"用户要求撰写发布说明时"足够具体。触发条件过宽的 Skill 比没有 Skill 更糟，因为它会干扰其他任务。

第二，按什么步骤执行。 步骤要有顺序、可执行。"注意质量"不是步骤，"核对每个外部链接可访问"是步骤。判断标准：另一个人拿着这份 Skill 能不能做出大致一致的结果。

第三，成功标准是什么。 没有成功标准，Agent 无法自检，你也无法判断这次执行是否合格。成功标准应该是可验证的，比如"三类归集齐全且每类至少一条，或明确写明该类无内容"。

第四，哪些边界不能越过。 明确禁止事项。比如"不得在示例中出现真实内部项目名与端口"。边界是 Skill 里最容易被忽略、但事故率最高的部分。

四要素齐全的 Skill 有一个共同特征：它对人和 Agent 同样可读。 你能看懂它在做什么，因此能在它出错时精确修正——这是"可纠正"的前提。

五、让积累真正产生价值的三个阶段

沉淀不是一次性动作，而是一个有顺序的过程。跳过任何一步都会降低质量。

阶段一：先在真实任务中验证流程。 不要凭想象写 Skill。一段没有在真实任务里跑通的流程，写成 Skill 只会把错误固化。先做一次，把过程中的纠正记下来。

阶段二：把稳定且可复用的步骤沉淀为 Skill。 注意两个限定词——稳定（不会下周就变）和可复用（不只适用于这一个特例）。只用一次的流程不值得沉淀，它带来的维护成本高于收益。

阶段三：在产品、工具或政策变化时更新 Skill。 这一步最容易被忽略。一份写于半年前的 Skill，如果引用的功能入口已经改了、限制已经调整了，它会持续给出过时指导。旧经验无限沿用比没有经验更危险，因为它带着"已验证"的可信度。

一个可操作的维护习惯：当你发现某个 Skill 的输出需要你反复手动修正时，说明它已经过期，应该更新而不是继续将就。

六、常见误区

其中第四行值得强调：Skill 库的价值不与数量成正比。 一份过期的 Skill 造成的损失，可能超过十份好 Skill 带来的收益，因为它会被自动装载、并且看起来很可信。

七、LightVela 的做法：把方法也变成用户资产

Hermes 已经把 Memory / Skill 的分层做到工程可用，但它仍然是面向直接编辑 Markdown 的使用者。LightVela 采用云端托管模式，不提供面向用户的文件系统操作，这两类积累的使用方式如下：

• 技能来自公开市场：所有技能来自 Skills.sh 与 ClawHub —— OpenClaw 与 Hermes 共享的技能市场，不需要你从零编写。
• 通过对话安装与删除：告诉 Hermes 要安装哪个技能即可完成安装，删除同理；安装后在对话中验证是否可用。管理台面板安装即将推出。
• 记忆在管理台可查看：记忆页用于查看 Agent 记住了什么，并可调整容量上限；增删则通过对话完成。
• 跨模型与跨通道稳定：切换模型不会清除技能与自动化设置；多个通道共享同一套技能与记忆。
• 异常可追溯：技能行为异常时，可在诊断中心查看并导出近期日志（可选 1、3、6、12 或 24 小时范围）定位问题。

也就是说，在 LightVela 上使用 Agent 时，你积累的是两类东西：一份关于你的 Memory，一套已安装并验证过的 Skill。这两类积累比某个具体模型更长期地服务于你。

小结

• "越用越顺手"来自有结构的积累，而不是模型的神秘自我升级。
• 两类积累不可混淆：Memory 存事实（query 命中即召回），Skill 存方法（场景匹配即装载）。
• 发现自己在重复纠正同一类做法时，该沉淀的是 Skill，而不是再加一条事实。
• /learn 在记忆最清晰时沉淀方法；/skills pending 提供审批，确保自我改进不等于无边界自改。
• 合格的 Skill 必须写清四件事：何时使用、执行步骤、成功标准、不可越过的边界。
• 沉淀分三阶段：真实任务验证 → 沉淀稳定可复用步骤 → 变化时更新。过期 Skill 比没有 Skill 更危险。