Agent 自进化：从半年实践到 Trajectory Mining Pipeline

一篇经验文章，记录我们在 Hermes Agent 体系中实践自进化的过程：从 8 篇论文调研到 4-Agent pipeline 落地，从两条路线之争到 Executor-Curator 分离架构，从 196 个 session 聊天记录到自动提取 intelligence 的完整链路。

一、问题的源头

做一个每天高强度使用的 Agent 系统，半年后回头来看，最核心的问题其实只有一个：

聊天记录越积越多，但价值在衰减。

state.db 里躺着 196 个 session、29k 条消息。一个 session 可能花了几百条消息、十几轮工具调用才解决一个复杂问题——但如果不去复盘，这个经验就永远沉睡在数据库里。session_prune 每周删数据时，等同于在销毁未被开采的知识矿。

更深刻的问题是：Agent 在反复踩同样的坑。今天遇到一个 git 错误，下周又遇到同样的错误，每次都从头调试。我们缺的不是记住答案（那是 RAG 的事），而是从经验中提炼可复用的行为模式——也就是 skill。

这不是我们的独有问题。2026 年 3 到 5 月，学术界突然爆发了一批研究同一问题的论文：Trace2Skill、CoEvoSkills、SkillX、SkillClaw、SkillOpt、SkillOS、SKILL0、Skill1。8 篇来自不同机构的工作，几乎同时在探索同一个核心问题：

Agent 如何从自身的操作轨迹中学习，实现自我进化？

二、两条路线：符号 vs 参数

这 8 篇论文清楚地分成了两条路线。

路线 A：符号/文本演化

Skill = 外部文本文件（SKILL.md）。可读、可写、可审计。通过 LLM 读写、合并、编辑来演化。

路线 B：参数内化

Skill = 模型权重中的参数知识。通过 RL 训练让模型内化，最终 zero-shot 执行。

分歧的本质

我们的选择：短期符号路线，长期混合。原因很简单——Hermes 在多模型、多平台间切换（deepseek、gemini、claude……），符号 skill 的跨模型迁移能力是不可放弃的。但 SkillOS 的 RL-trained Curator 给了我们启发：未来可以把符号 skill 库的管理交给一个专门训练的 policy，而高频 skill 选择性内化。

三、架构分水岭：Executor-Curator 分离

SkillOS 提出的 Executor-Curator 分离是整件事的架构分水岭。

核心思想：执行者（Agent）和技能管理者（Curator）应该是两个完全独立的系统。Agent 只管做事，Curator 管 skill 的创建、合并、淘汰、评估。Curator 有自己的目标函数（下游任务成功率），有自己的训练循环，和 Agent 的语言模型完全解耦。

SkillOS 的惊人结果是：一个 8B 参数的专门训练 Curator，比 Gemini 2.5 Pro 的 zero-shot 提示效果更好。 小模型专门训练 > 大模型通用提示。

回头看，我们的 Hermes 体系已经潜意识地做到了这件事：

• Executor：Hermes Agent 本身（执行任务、调工具、写代码）
• Curator：确定性 pipeline（compound-system 反思、重复 skill 合并、decay-check）
• 外挂系统：SkillOpt 训练、pattern-detector、validation-set

但我们一直没意识到这就是 Executor-Curator 分离。我们的 Curator 是确定性规则（SKILL.md 比对、关键词匹配），而不是 RL policy。认识到这个模式后，后面的设计就有了统一的指导框架。

四、Trajectory Mining Pipeline：从聊天记录到 intelligence

有了 Executor-Curator 框架，具体怎么做？我们基于 Trace2Skill、Skill-DisCo、AutoRefine 和 Vadim's Trajectory Miner 四篇工作，设计了一个 4-Agent 流水线。

架构

Trace Ingestor → Pattern Miner → Knowledge Distiller → Validation Curator
     │                │                  │                     │
 state.db       compound-system       fact_store           validation-set
                /bugs  /knowledge     +MEMORY.md

4 个角色，职责完全分离：

1. Trace Ingestor：读取 state.db，批量产出结构化 session 摘要。不分析、不判断，只做数据清洗。
2. Pattern Miner：跨 session 发现三类模式——重复错误（≥2 次）、成功模式（≥2 次同类任务）、来源洞察（错误率 > 30%）。每条模式必须经过自质疑：是根因还是表象？
3. Knowledge Distiller：将简单信号（如"qqbot 源有 67% 错误率"）写入 fact_store，复杂模式（如错误排名、任务分布趋势）写入 compound-system/knowledge。用 AutoRefine 的维护评分 effectiveness × log(frequency) × precision 排优先级。
4. Validation Curator：从成功 session 中提取验证任务，去重后加入 validation set，保持 30 条上限。

7 个设计决策

全部来自论文验证，不是拍脑袋：

P1：基础链路（Harvest + Mine）

第一版不做分析，先打通链路。

trajectory-miner.py harvest → mine → write-solutions

首轮数据：

我们立刻发现了一个有趣的事：所有来源的错误率都在 52-66% 之间。这不太可能是巧合，更可能是检测阈值设得太宽——大量不是真错误的信号也被标记了。这个发现直接指导了 P2 的假阳性过滤优化。

P2：知识蒸馏 + 验证策展

在 P1 的基础上加了两个下游消费者：

1. Knowledge Distiller：产出一个 fact-staging.json（5 个候选条目，含评分权重），一个 memory-staging.md（5 条 MEMORY.md 更新建议），3 条 compound-system/knowledge 聚合条目（Top 错误排名、Success 聚合、Task 分布）。

2. Validation Curator：从成功 session 提取验证任务，自动去重（命中 15/27 已有），滚动替换保持 30 条上限。

全链路跑完 < 30 秒。

五、同步推进的其他工程

Pipeline 是主线，但不是全部。过去半个月还做了这些：

1. Memory 体系重构

19 个碎片脚本 → 3 个统一脚本（memory-core.py 维护、memory-sync.py 同步、memory-health.py 监控）。5 个 cron job 代替 11 个。内存占用从 2450B 降到 1374B。

2. state.db 优化

两层清理：FTS5 重建消除内容复制（351 MB → 200 MB），删除 >7 天 session 的 tool 消息（200 MB → 134 MB）。-62% 总空间。

原则：原始聊天记录是临时缓存，永久记录在 fact_store + compound-system + MEMORY.md 中。

3. SkillOpt 集成

SkillOpt 的输出（优化后的 skill）自动摄入 compound-system 和 skill 库，形成"训练→验证→入库"闭环。

4. 验证集构建

从 session 历史自动构建验证任务，初始 15 条，经 Validation Curator 扩展到 30 条，覆盖成功和失败场景。

5. Pi 轨迹吸入

Pi coding agent 的 session 数据通过专用脚本定期吸入，与 Hermes 轨迹统一处理。

六、执行时序

最终形成的自动化链条：

周日 01:00  Trajectory Pipeline（全 4 阶段）
周日 01:45  fact_store 应用（LLM 驱动的 cron）
周日 02:00  session_prune（安全删除旧消息）

每天还有：

• 03:00 SkillOpt 自动进化 + compound-system refresh
• 04:00 memory-core 维护
• 05:00 Pi 轨迹吸入
• 06:00 Curator 验证 + Hermes 配置备份
• 07:00 system-health + skill-rejuvenate
• 08:00 memory-health + skillopt-ingest
• 09:00 validation-set-refresh + skill-index-rebuild

每周定时任务 22 个，构成一个自我维持的进化系统。人类不介入也能持续发现问题、提炼知识、更新技能。

七、经验与教训

做对了的事

1. 先用调研开路。

在写一行代码之前，先读了 8 篇论文 + 4 篇技术博客。这让我们避免了"目盲实现"——如果不读 Trace2Skill，我们大概率会写一个顺序处理的 pipeline，然后重复论文里已经被证明慢 20 倍的路线。

2. 纯分析师原则。

Pipeline 不写 skill、不编辑代码、不做决策。它只产出结构化的 intelligence 文件。一开始觉得这是约束，实际发现这正是它干净的根源——每个组件职责单一，输出格式明确，下游可以自由选择消费方式。

3. ≥2 阈值 + 自质疑。

单次出现叫 incident，两次才算 pattern。每条 pattern 强制回答"是根因还是表象？"。这消灭了大量噪音（首轮 13/62 信号被过滤）。

4. 先搭链路再调质量。

P1 只做 harvest + mine，不管标题好不好看、条目是不是完美。稳定跑通一轮后，P2 再上 distillation 和 curation。渐进式交付。

5. 管道跑在 prune 之前。

删除数据之前先把值提出来——这个执行时序保证了 state.db 始终是先消费后清理。

可以做得更好的

1. P1 的标题质量。

bugs 目录下的文件名全是从错误 JSON key 直接生成的，看起来像 2026-07-05-auto-success___true___diff____---_a__path__n____b.md。虽然内容有正确的 frontmatter 元数据，但影响可读性。

2. 假阳性检测阈值。

当前把所有带 error/fail/❌ 的信号都标记为错误，导致来源错误率高达 52-66%。实际上很多是 harmless 的工具权限警告和空输出。需要一个更细粒度的信号分类器。

3. 验证集缺少反馈闭环。

现在只是单向往里加任务，还没有"这条验证通过了 / 没通过 → 调整 pipeline 阈值"的反馈回路。

4. fact-staging.json 需要 LLM 驱动才能消费。

fact_store 是 agent tool，纯脚本改不了。需要用 LLM cron 做衔接层——增加了架构复杂度。

八、更长远的思考

两条路线正在收敛

SkillOpt + SkillOS 已经是符号路线在吸收 RL 思想（学习率、batch、gate、RL-trained curator）。而 SKILL0 + Skill1 在探索"哪些 skill 值得内化"的选择问题。

我觉得最终形态会是：由 RL-trained Curator 管理外部 skill 库（做筛选、排序、组合），高频高价值 skill 选择性内化到模型参数。 Executor 只关心当前任务，Curator 提供上下文窗口内的最佳技能组合。Curator 可以是一个小模型 + 确定性规则的混合体——不一定需要大模型。

没有系统做了全部五件事

完整能力集应该是：

1. 提取：从轨迹中提取模式 ✓（Trajectory Miner / Trace2Skill）
2. 验证：改进质量 ✓（Validation Gate / CoEvoSkills）
3. 共享：跨用户积累经验（SkillClaw 方向，尚未落地）
4. 优化：受控迭代提升 ✓（SkillOpt）
5. 维护：生命周期管理 ✓（Curator / SkillOS）

我们基本覆盖了 1/2/4/5，缺的是 3——跨用户共享。如果这个系统有多个用户，一个人踩过的坑其他人自动受益。这是 SkillClaw 的思路，也是 SaaS agent 产品最天然的价值点。

不可逆的趋势

2026 年 3-5 月，8 篇论文几乎同时爆发。这不是巧合。Agent 领域正在从"用 prompt engineering 调教单个模型"转向"构建能持续积累经验的系统"。就像软件工程从过程式编程走向面向对象一样——我们需要封装、继承、多态，只不过这次不是代码，而是经验。

我们的 pipeline 不是终点。它只是证明了：你可以自动地从聊天记录中提取 intelligence。 下一步的问题不是"能不能"，而是"怎么消费这些 intelligence 才能最大化 agent 的长期表现"。

这个问题，我们还在探索中。

附录：论文引用

1. Ni et al., Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills, arXiv:2603.25158, 2026.
2. He et al., CoEvoSkills: Co-evolving AI Agents with Diverse Skill Packs, arXiv:2604.01687, 2026.
3. Yang et al., SkillX: Evolving AI Agent Skill from Number to Knowledge Base, arXiv:2604.04804, 2026.
4. Wu et al., SkillClaw: Multi-agent Skill Evolution from Collective Agent Trajectories, arXiv:2604.08377, 2026.
5. Wang et al., SKILL0: Zero-Shot Agent with Internalized Skills, arXiv:2604.02268, 2026.
6. Hu et al., SkillOpt: Optimizing Agent Skills through Textual Learning Rate, arXiv:2605.23904, 2026.
7. An et al., SkillOS: On a Unified Skill Operating System for LLM Agents, arXiv:2605.06614, 2026.
8. Guo et al., Skill-DisCo: Distilling and Compiling Agent Traces into Reusable Procedural Skills, arXiv:2606.26669, 2026.
9. Vadim Nicolai, Why Do AI Agents Keep Making the Same Mistakes?, 2026. vadim.blog/trajectory-miner-research-to-practice