Agent 自进化：从半年实践到 Trajectory Mining Pipeline
一篇经验文章，记录我们在 Hermes Agent 体系中实践自进化的过程：从 8 篇论文调研到 4-Agent pipeline 落地，从两条路线之争到 Executor-Curator 分离架构，从 196 个 session 聊天记录到自动提取 intelligence 的完整链路。
一篇经验文章，记录我们在 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 读写、合并、编辑来演化。
| 工作 | Skill 是什么 | 演化方式 |
|---|---|---|
| Trace2Skill | 单 skill.md | 离线批量分析 → 平行 patch → 层次化合并 |
| CoEvoSkills | 多文件包 | 在线 Generator ↔ Verifier 对抗演化 |
| SkillX | 三层级知识库 | 离线构建 + 主动探索扩展 |
| SkillClaw | 文本 skill | 跨用户轨迹聚合 → 持续更新 |
| SkillOpt | skill.md | DL 式训练（学习率/batch/gate） |
| SkillOS | 单 Markdown | RL-trained Curator 在线管理生命周期 |
路线 B：参数内化
Skill = 模型权重中的参数知识。通过 RL 训练让模型内化，最终 zero-shot 执行。
| 工作 | 内化方式 | 优化目标 |
|---|---|---|
| SKILL0 | Dynamic Curriculum：从全 skill 上下文开始，逐步收回 | 最终 zero-shot 不需要 skill 注入 |
| Skill1 | 信号分解：低通滤波给 selection，高通滤波给 distillation | 一个策略同时做三件事 |
分歧的本质
| 维度 | 符号路线 | 参数内化路线 |
|---|---|---|
| 可审计性 | ✅ 完全可读可改 | ❌ 权重不可解释 |
| 跨模型迁移 | ✅ 文本复制即用 | ❌ 需重新训练 |
| 推理 token 开销 | ❌ 每次注入 3-5K token | ✅ zero-shot |
| 维护复杂度 | 低（git 管理） | 高（RL 训练 pipeline） |
| 适用场景 | 多模型、多平台、需审计 | 固定模型、高频重复任务 |
我们的选择：短期符号路线，长期混合。原因很简单——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.md4 个角色，职责完全分离：
- Trace Ingestor：读取 state.db，批量产出结构化 session 摘要。不分析、不判断，只做数据清洗。
- Pattern Miner：跨 session 发现三类模式——重复错误（≥2 次）、成功模式（≥2 次同类任务）、来源洞察（错误率 > 30%）。每条模式必须经过自质疑：是根因还是表象？
- Knowledge Distiller：将简单信号（如"qqbot 源有 67% 错误率"）写入 fact_store，复杂模式（如错误排名、任务分布趋势）写入 compound-system/knowledge。用 AutoRefine 的维护评分
effectiveness × log(frequency) × precision排优先级。 - Validation Curator：从成功 session 中提取验证任务，去重后加入 validation set，保持 30 条上限。
7 个设计决策
全部来自论文验证，不是拍脑袋：
| # | 决策 | 来源 | 效果 |
|---|---|---|---|
| 1 | 并行批量合并 > 顺序编辑 | Trace2Skill | 3min vs 60min，质量更高 |
| 2 | 纯分析师分离：只产 intelligence 不写代码 | Vadim | 可审计、可回滚 |
| 3 | ≥2 次阈值 + 自质疑 | Vadim + AutoRefine | 首轮过滤 13/62 假阳性 |
| 4 | 非对称失败分析：深 vs 浅 | Trace2Skill | 失败 session 更多维元数据 |
| 5 | 编译+验证闭环 | Skill-DisCo | 0% 执行错误（论文数据） |
| 6 | 维护评分驱动优化 | AutoRefine | Low 分模式自动降级 |
| 7 | 双形模式：简单→fact_store，复杂→compound-system | AutoRefine | 按信号密度分配存储 |
P1：基础链路（Harvest + Mine）
第一版不做分析，先打通链路。
trajectory-miner.py harvest → mine → write-solutions首轮数据：
| 指标 | 数值 |
|---|---|
| Session 分析数 | 189 |
| 发现真实模式 | 49 |
| 过滤假阳性 | 13 |
| 写入 compound-system bugs | 43 |
| 写入 compound-system knowledge | 6 |
我们立刻发现了一个有趣的事：所有来源的错误率都在 52-66% 之间。这不太可能是巧合，更可能是检测阈值设得太宽——大量不是真错误的信号也被标记了。这个发现直接指导了 P2 的假阳性过滤优化。
P2：知识蒸馏 + 验证策展
在 P1 的基础上加了两个下游消费者：
-
Knowledge Distiller：产出一个 fact-staging.json（5 个候选条目，含评分权重），一个 memory-staging.md（5 条 MEMORY.md 更新建议），3 条 compound-system/knowledge 聚合条目（Top 错误排名、Success 聚合、Task 分布）。
-
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 可以是一个小模型 + 确定性规则的混合体——不一定需要大模型。
没有系统做了全部五件事
完整能力集应该是：
- 提取：从轨迹中提取模式 ✓（Trajectory Miner / Trace2Skill）
- 验证：改进质量 ✓（Validation Gate / CoEvoSkills）
- 共享：跨用户积累经验（SkillClaw 方向，尚未落地）
- 优化：受控迭代提升 ✓（SkillOpt）
- 维护：生命周期管理 ✓（Curator / SkillOS）
我们基本覆盖了 1/2/4/5，缺的是 3——跨用户共享。如果这个系统有多个用户，一个人踩过的坑其他人自动受益。这是 SkillClaw 的思路，也是 SaaS agent 产品最天然的价值点。
不可逆的趋势
2026 年 3-5 月，8 篇论文几乎同时爆发。这不是巧合。Agent 领域正在从"用 prompt engineering 调教单个模型"转向"构建能持续积累经验的系统"。就像软件工程从过程式编程走向面向对象一样——我们需要封装、继承、多态，只不过这次不是代码，而是经验。
我们的 pipeline 不是终点。它只是证明了：你可以自动地从聊天记录中提取 intelligence。 下一步的问题不是"能不能"，而是"怎么消费这些 intelligence 才能最大化 agent 的长期表现"。
这个问题，我们还在探索中。
附录：论文引用
- Ni et al., Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills, arXiv:2603.25158, 2026.
- He et al., CoEvoSkills: Co-evolving AI Agents with Diverse Skill Packs, arXiv:2604.01687, 2026.
- Yang et al., SkillX: Evolving AI Agent Skill from Number to Knowledge Base, arXiv:2604.04804, 2026.
- Wu et al., SkillClaw: Multi-agent Skill Evolution from Collective Agent Trajectories, arXiv:2604.08377, 2026.
- Wang et al., SKILL0: Zero-Shot Agent with Internalized Skills, arXiv:2604.02268, 2026.
- Hu et al., SkillOpt: Optimizing Agent Skills through Textual Learning Rate, arXiv:2605.23904, 2026.
- An et al., SkillOS: On a Unified Skill Operating System for LLM Agents, arXiv:2605.06614, 2026.
- Guo et al., Skill-DisCo: Distilling and Compiling Agent Traces into Reusable Procedural Skills, arXiv:2606.26669, 2026.
- Vadim Nicolai, Why Do AI Agents Keep Making the Same Mistakes?, 2026. vadim.blog/trajectory-miner-research-to-practice