AI Agent 自进化管线：从 8 篇论文到生产级闭环的架构全貌

半年，196 个 session，29k 条消息，134MB 的 state.db。这里面埋着无数踩过的坑、找到的最优解、反复出现的错误模式——但没有任何机制把它们挖出来。这篇文章记录了我如何从 8 篇同期论文出发，用 6 步管线让 Agent 学会从自己的聊天记录中提取可复用的 skill。

---

一切从一个很现实的问题开始。

我用 Hermes Agent 做日常开发，半年下来 state.db 膨胀到了 134MB。196 个 session，29,000 多条消息。里面藏着大量「我怎么又踩了这个坑」的时刻——同样的 web_search 权限问题、同样的 pip 依赖冲突、同样的 cron 配置语法错误。我手动写过很多 skill，但完全依赖回忆和灵感。

写过的 skill 是有限的，踩过的坑是无限的。

问题是：能不能让 Agent 自己从聊天记录中发现模式，自动提炼成 skill？如果能，自进化就从一个 marketing 口号变成了真正的工程闭环。

2026 年 H1，arXiv 上同时涌现了 8 篇高度相关的论文。这不是偶然——整个领域都在思考同一个问题：AI Agent 怎么从经验中学习。我花了两个月调研、实验、落地，最终产出了一套 6 步管线。这篇文章是完整的架构复盘。

---

一场论文洪流：8 篇论文的路线之争

先快速过一下这 8 篇论文。它们几乎在同一时间发表，但走了两条完全不同的技术路线。

符号路线的 6 篇论文各有侧重：

Trace2Skill（阿里，2603.25158）是最直接的灵感——并行分析执行轨迹，层级合并成统一 skill。35B 模型学到的 skill 迁移到 122B 模型上提升了 57 个百分点。跨模型的泛化能力，这是符号路线的核心优势。

CoEvoSkills（UIC/哥伦比亚/UBC，2604.01687）提出了信息隔离的验证思路：Generator 产 skill，Surrogate Verifier 验证——验证者不看到真实答案，只通过测试来打分。这解决了 Agent 领域一个深层的信任问题。

SkillOS（Google Cloud + UIUC + MIT，2605.06614）可能是我最看重的一篇。它明确提出了 Executor-Curator 分离的架构原则：Frozen Executor + RL 训练的 Curator，8B 的 Curator 在 skill 管理上超过了 Gemini-2.5-Pro 的零样本表现。一个 8B 的模型，专注于 skill 的插入、更新、删除，效果比通用大模型更好。

结论很清晰：管理 skill 的质量，比生成 skill 的能力更重要。

另外三篇——SkillX（预建知识库即插即用）、SkillClaw（跨用户聚合轨迹）、SkillOpt（深度学习的优化范式搬到文本空间）——各有亮点，但对我这种单人开发场景来说，SkillOS 的架构分离 + Trace2Skill 的并行分析 + CoEvoSkills 的对抗验证，构成了最坚实的组合。

RL 路线的两篇（SKILL0 和 Skill1）相当惊艳——SKILL0 用动态课程学习，逐步撤回 skill 上下文，最终实现 <0.5K tokens/step 的零样本推理；Skill1 在 ALFWorld 上达到了 97.5% 的 SOTA。但我最终没有选。

为什么放弃 RL 路线？

坦率地讲，RL 路线的效果数据比符号路线更亮眼。但三个原因让我做了相反的选择：

1. 跨模型迁移：我换过 3 次 backbone（GPT → Claude → DeepSeek）。RL 训练的 skill 是绑定模型权重的，换了模型一切重来。符号路线的 skill 是 Markdown 文件，换模型只是重新阅读理解的问题。
2. 可审计性：我需要知道「这个 skill 是从哪个 session 来的、基于什么模式」。RL 训练的权重是黑盒。
3. 基础设施成本：RL 训练需要稳定的大规模算力。符号路线只需要 LLM 调用 + 文件操作。

这是我第一个关键决策：选符号路线，不选 RL 路线。

---

六步管线：从轨迹到 Skill

有了方向，接下来是工程实现。这套管线经历了三个迭代，最终定型为 6 步流水线。

Step 1: Harvest — 从 state.db 提取结构化 session 轨迹
  → 脱敏、分类信号（real_error / harmless_warning / permission_prompt）
  → 输出：trajectory JSON

Step 2: Mine — 并行分析轨迹，聚类模式
  → parallel-miner.py: 9 组并行
  → 分析：tool errors, repeated patterns, success patterns
  → 输出：聚类后的模式候选

Step 3: Distill — 层级合并
  → hierarchical-distiller.py
  → guardrail 过滤 + prevalence 评分 + merge 相似模式
  → 输出：高质量 skill 草案

Step 4: Curate — 验证和提炼
  → surrogate-verifier.py（CoEvoSkills 式 6 维验证）
  → review-gate.py 安全门控
  → 输出：就绪的 skill

Step 5: Feedback — 闭环验证
  → validation-curator.py
  → 分析 real_error 比例 / outcome 分布 / 验证集通过率
  → 自动调 RECURRENCE_THRESHOLD

Step 6: Dual-Form — 双形模式
  → skill pattern → SKILL.md
  → subagent pattern → Pi agent config
  → 产出：18 个 proposal（15 skill + 3 subagent）

我按因果逻辑拆一下，不是罗列功能。

Step 1: Harvest — 信号分类是第一个坑

从 state.db 提取轨迹不算难——SQLite 读 message 表，按 session 分组。难的是 信号分类。

一条消息是 real error 还是 harmless warning？web_search 返回 permission_denied 是真正的错误，但 Agent 自己修的 typo 只是开发过程的正常噪音。我一开始用了非常简单的规则——只要 message 里包含 'error' 就标红——结果假阳性率飙到 55%。

后来不得不做三层信号分类：real_error（真正妨碍任务的东西）、harmless_warning（不阻塞流程的噪声）、permission_prompt（工具调用被用户拦截）。这个分类系统的精度直接决定了后续所有环节的质量。

分类错了，后面全是 garbage in, garbage out。

Step 2: Mine — 为什么选批量并行而不是在线增量

196 个 session，如果每个 session 单独分析，大约需要 30-40 分钟。但如果把 session 分成 9 组并行分析，<5 分钟就能跑完。

当时有一个选择：做在线增量分析——每次 session 结束就立刻分析一条，实时更新模式库。听起来很优雅，但我放弃了。

为什么？

增量模式面临严重的「冷启动」问题。前 10 个 session 的数据不足以支撑有意义的聚类——你看到的「模式」可能只是随机噪音。而且增量更新的状态管理极其复杂：某个模式今天看到 3 次，算不算 signal？明天又看到 1 次，要衰减吗？状态机写起来没完没了。

批量并行就简单得多：固定 9 组 parallel sub-agent，每组读 20-25 个 session，各自产出一个 pattern 列表。然后合并去重。9 组并行 <5 分钟完成，14 分钟包括后续的 LLM API 消费。简单、可预测、好 debug。

Step 3: Distill — 频率不是价值

这步踩了最深的坑。

Mine 阶段产出了很多模式候选——有些模式在 20 个 session 里出现了。直觉告诉我：频率高 = 重要。

完全错了。

很多高频模式是 cron 重试带来的噪音——某个 API 因为限流失败，Agent 重试 3 次，每次都被记录为独立事件。看起来「错误模式出现 3 次」，实际上是同一个事件被重复计数。

还有一类：web_search 返回空结果。太常见了，几乎每个 session 都有。但这是有价值的模式吗？大部分时候只是搜索词不够精确，不是系统性问题。

模式频率 ≠ 模式价值。

Hierarchical Distiller 引入了 prevalence 评分 + guardrail 过滤来解决这个问题。prevalence 评分考虑的是「这个模式在不同上下文中出现的多样性」而不是「总共出现了多少次」。guardrail 则直接过滤掉已知的噪音类别——cron 重试、搜索空结果、权限提示。

这两层过滤把候选模式的数量从 130+ 降到了 18，质量却大幅提升。

Step 4: Curate — LLM 会自我放行

Surrogate Verifier 是 CoEvoSkills 最聪明的贡献。它用 6 维评分（clarity, correctness, completeness, relevance, actionability, safety）来验证 skill 草案。关键是：验证者不看到生成者的 prompt。 信息隔离，防止共谋。

我在实现时发现了一个真实的问题：如果用同一个 LLM 既当 verifier 又当 reviewer，它对同一份 skill 的评价会系统性偏高——LLM 不擅长批评自己的产出。用 Separated Verifier（不同的模型实例、不同的 prompt 模板）解决了这个问题。

这个教训可以推广：任何涉及到「自检」的环节，都要考虑 Agent 的自我放行倾向。

Review Gate 是另一层安全网。它检查 skill 的 token 效率、section 覆盖、潜在的安全问题。Scope filter 限定只审查自己管辖区内的 skill，避免了误伤第三方安装的 skill。

Step 5: Feedback — 闭环让阈值自调节

这一步骤是后来加的——我发现前三步都是「开环」的。

RECURRENCE_THRESHOLD（一个模式出现多少次才算 signal）开始设的是 3。运行两周后发现：很多有价值的模式只出现了 2 次，但它们是真正罕见但关键的问题（比如某个特定 API 的兼容性问题）。同时一些出现 5 次以上的模式是 cron 噪音。

Feedback 环节做了一个很简单的闭环：每个自动生成的 skill 被标记为 applied/ignored，然后观察 applied 的 skill 在实际使用中的表现——被调用了多少次？是否减少了对应的 real_error？根据这些数据自动调整 RECURRENCE_THRESHOLD。

目前稳定的阈值在 2-3 之间。不是固定的，是根据实际效果动态调的。

Step 6: Dual-Form — 同一个模式两种形态

最后这步是锦上添花的。

同一个模式可以有两种呈现形态：作为 SKILL.md 让 Hermes Agent 在上下文中读取，或者作为 Pi agent 的配置（YAML 格式的 tool 定义和 instruction）。前者适合需要 Agent「理解」的复杂任务，后者适合需要 Agent「严格执行」的确定性流程。

18 个 proposal 中，15 个走了 skill 路径，3 个走了 subagent 路径。双形模式的好处是：不 bias 结果——让模式自己「选择」最适合的形态。

---

关键决策：一张表说清所有 trade-off

整条管线最值钱的部分可能不是代码，而是这些决策：

选符号路线我前面说了。Executor-Curator 分离是最有远见的一个决策——把「怎么做」和「学什么」拆成两个不同的系统，各自的优化目标不再互相干扰。

Surrogate Verifier 替代真实执行这个选择，同行可能会有不同意见。但对我来说很直接：真实执行需要搭建隔离环境、mock 外部依赖、处理各种边界情况。在单人开发场景下，这笔投入的 ROI 远远低于用 LLM 做自动评分。后者有偏差，但偏差是已知且可控的——我们观测到 verifier 的评分标准差在 12-15 分之间，偏差有规律可循。

---

实际效果：数据说话

管线运行了 8 周后：

8 个自动生成的 skill 听起来不多，但每个都确实被用到过——不是「为了生成而生成」的充数产物。3 个 CRITICAL 级别的安全问题是真正有价值的发现，包括一个 API key 明文写入 trajectory JSON 的漏洞。

但最让我有感触的是假阳性率从 55% 降到 0% 的过程。一开始几乎所有 auto-detected pattern 都是噪音。花了整整两轮迭代来加过滤层。

假阳性治理比真阳性挖掘更耗时——而且更值得投入。 因为用户对「机器给了一个错误建议」的容忍度远低于「机器没给建议」。

---

踩过的坑

几个值得单说的教训。

坑 1：LLM 作为 QA Agent 会自我放行

这个前面提过。一个验证体系最关键的原则：验证者和生成者不能是同一个 LLM 实例。 分开不是成本翻倍，分开是让验证有意义的最低条件。

坑 2：模式频率 ≠ 模式价值

再强调一遍。高频模式很可能是 cron 重试、工具失败重试、搜不结果重试——都是系统性的噪音。有价值的模式往往只出现 2-3 次，但每次出现在不同的上下文中。多样性比频率重要。

坑 3：EVOLUTION_LOG 的噪音污染

我有一个 EVOLUTION_LOG 来记录进化事件。结果 SkillClaw bridge sync（每小时跑一次）的 cron agent 自动往日志里写「Hourly bridge sync: skills + sessions」。8 周后日志被撑到 202 行，其中 160 行是这种噪音。

修复很简单：cron prompt 里显式禁止写入 EVOLUTION_LOG。但在修复之前，噪音已经淹没了真正有价值的日志。

教训是：cron 自动化越成功，日志污染越严重。 每个自动化的 side effect 都要显式控制。

坑 4：Cron 模型漂移

创建 cron job 时如果不固定 provider，切换模型后 cron runner 会认为 model 不匹配而告警。一个微小的配置疏忽，半夜收到告警通知。解决：创建 cron 时同时指定 --model 和 --model-provider。

---

升维：自进化不只是技术问题

技术讲完了，聊点更大的。

这 6 步管线本质上是把一个隐性的知识管理流程显式化了。在没有这套系统的时候，经验在人的脑子里——写好 skill、记笔记、踩过坑下次注意。有了这套系统，经验在 Agent 的 skill 库里——自动提取、自动验证、自动更新。

但我越来越觉得，Agent 自进化不是一个纯技术问题。

它首先是一个组织知识管理的问题。

想想传统软件工程里的知识管理——wiki、文档、onboarding guide。存在什么问题？文档没人写、写了没人看、看了记不住。自进化管线做的事情本质上是一样的：把隐性经验变成显式资产。只不过执行者是 Agent 而不是人。

这套管线不会让一个平庸的工程师变成优秀的工程师。但它能把一个优秀工程师的经验沉淀下来，让开发团队每次遇到同样的问题时，不需要重新发明轮子。

你想想看，如果每个 Agent session 结束时不只是留下一段聊天记录，而是一个经过验证的、可复用的模式，那半年后、一年后，系统积累的就不是 134MB 的数据，而是一个不断成长的「经验资产库」。

SkillOS 论文里有一句话我一直记着：

Curator 比 Executor 重要 10 倍。

我可以换个说法：

让 Agent 学会学习，比让 Agent 学会执行，重要 10 倍。

管线会继续迭代。下一步可能是 Pi agent 的 subagent 模式接入、跨机器的 SkillClaw 聚合、更细粒度的验证闭环。但方向已经清楚了——让每一次交互都产生可复用的价值，而不是在 134MB 的聊天记录里默默腐烂。

不是每个问题都需要 AI 来解决。但 AI 解决过的问题，不应该让下一个开发者再解决一次。

---

这篇文章涉及的完整代码和配置在 Hermes Agent 的自进化系统目录中。论文引用：Trace2Skill (arXiv 2603.25158)、CoEvoSkills (arXiv 2604.01687)、SkillOS (arXiv 2605.06614)、Skill0 (arXiv 2604.02268)、Skill1 (arXiv 2605.06130)。