Harness

从 Session 到 Skill——AI Agent 如何自我进化

一、一个困扰我很久的问题

我用 Agent 做开发已经几个月了。每天产生几十条会话，每条会话里有几十次工具调用。数据量是够了，但一个尖锐的问题一直摆在那里：

这些历史数据，除了翻出来看，还有别的用吗？

Hermes 有 session_search，能搜到过去的对话。但当我想从中提炼点什么的时候，过程完全是手动的——翻历史、找模式、写成 skill。做得多了，我开始想：能不能自动化？

这就是我研究 ECC 的 Continuous Learning 系统的动机。

ECC 的连续学习 v2 定义了一个管道：

这不是理论。它有 Hook 采集数据、有后台服务做分析、有 Instinct 系统做评分、最终产出可复用的 Skill 文件。

但 ECC 不是唯一能做到这一点的。任何有历史记录的系统，加上一点自动化逻辑，都能实现类似的效果。

二、连续学习的四步管道

阶段 1：观察——数据从哪里来

ECC 用 PostToolUse Hook 做传感器。每次工具调用完成后，Hook 记录结构化数据：

• 用了什么工具（terminal / write_file / read_file）
• 输入了什么参数（命令、文件名、搜索词）
• 返回了什么结果（exit_code、输出摘要、错误信息）
• 上下文是什么（当前任务、相关文件）

关键点：数据必须是结构化的。如果只是原始日志，后面的分析就做不了。

维度	ECC	很多系统的现状
数据采集	PostToolUse Hook 自动记录	可检索但非结构化
记录格式	结构化 JSON	纯文本对话
采集粒度	每次 tool call	每次消息
关联上下文	有（任务/文件）	无

差距很明显：我们有历史数据，但缺少结构化记录层。连续学习的第一步，不是分析，而是把数据存成可分析的格式。

阶段 2：分析——从噪音中找信号

ECC 的后台分析器定期扫描采集到的记录，提取模式：

• 高频操作：某个命令在一天内出现了 50 次——可能是一个应该脚本化的重复劳动
• 错误模式：某个类型的错误反复出现——可能是一个系统性问题
• 成功路径：某种操作序列总是成功——可能是一个值得固化的工作流

分析器的输出不是最终 Skill，而是 "Instinct（本能）"——一个有置信度分数的模式候选。

这个过程不需要人工参与。分析器跑在后台，像后台垃圾回收一样，静静地处理数据，产出候选。

阶段 3：Instinct 评分——什么样的模式值得保留

ECC 给每个检测到的模式打分：

• 置信度：这个模式出现了多少次？频率越高，越可能是真模式
• 稳定性：模式的变化大吗？稳定的模式比变化大的模式更有价值
• 效果：这个模式是否关联到成功的结果？

只有分数超过阈值的模式，才会被提升为 Instinct。

为什么需要评分？ 因为 Agent 的使用模式里大部分是噪音。你今天改了三个文件，明天改了另外三个——这不代表有模式。只有那些"每次做 X 之前都会先做 Y"的序列，才值得保留。

阶段 4：演化为 Skill——从本能到可复用资产

Instinct 经过人工审核，就可以成为正式的 Skill。ECC 的做法是：

1. 系统自动生成 SKILL.md 草稿（包含模式描述、触发条件、示例）
2. 人工审核：确认模式是真的、示例是准确的、没有附带敏感信息
3. 正式创建 Skill，加入技能库

这个过程体现了 ECC 的一个重要设计哲学：机器做采集和分析，人做判断和确认。

三、在现有系统上实现连续学习

第一道：把会话数据结构化了再说

这是最关键的一步。连续学习对数据格式有硬性要求——纯文本不够。你需要这样存：

{
  "session_id": "abc-123",
  "timestamp": "2026-07-07T10:30:00Z",
  "tools": [
    { "name": "terminal", "input": "npm test", "exit_code": 0, "duration": 12 },
    { "name": "search_files", "input": "TODO", "results": 5, "duration": 0.5 }
  ],
  "context": { "task": "修复登录页面 bug", "repo": "my-app" }
}

格式不一定完美，但必须包含三个要素：什么操作、什么结果、什么上下文。

第二道：用 cron 定期跑分析

设定一个定时任务，每周跑一次分析器。分析器做的事很简单：

def analyze_sessions(sessions):
    patterns = []
    for session in sessions:
        for i in range(len(session["tools"]) - 1):
            pair = (session["tools"][i]["name"],
                    session["tools"][i+1]["name"])
            patterns.append(pair)
    from collections import Counter
    freq = Counter(patterns)
    return freq.most_common(10)

这个脚本 50 行就能写出来。不需要 AI，不需要复杂算法——纯统计就够用了。

第三道：人工审核 + 确认

自动化产出的东西，必须经过人工审核才能进入技能库。这是安全底线。

审核流程：

1. 系统生成草稿 Skill（Markdown 文件）
2. 人审：模式是否真实？示例是否脱敏？
3. 确认后正式创建 Skill

这个"机器干活、人做判断"的分工，在 Agent 系统里会反复出现。

四、连续学习的复利效应

时间	会话数量	Skill 数量	状态
第 1 周	50 条	0	全是原始数据
第 4 周	200 条	3	提炼出 3 个高频模式
第 8 周	500 条	8	开始覆盖日常工作的 30%
第 12 周	1000 条	15	大部分重复劳动已经自动化

注意 Skill 数量的增长速度——初期慢（因为要积累数据），后面会加快（因为模式开始互相关联）。这不是线性的，是指数的。

当你有了 15 个 Skill 覆盖大部分日常工作后，你的 Agent 的开发效率已经不是"有没有助手"的区别，而是"有没有积累"的区别。

五、从今天可以做的三件事

1. 今天就改你的会话存储格式。 如果现在存的是纯文本，加一个结构化字段。从 { "tools": [], "context": "" } 开始，格式随用随扩。

2. 写一个 50 行的分析脚本。 用 Python 的 Counter 统计你最近的会话，看看有没有重复发生的高频操作。你可能会惊讶地发现，有些命令你在过去一周执行了 30 次。

3. 定一个每周的"Skill 提炼日"。 每周五下午，花 30 分钟看分析脚本的输出，挑一个模式做成 Skill。不需要完美，完成比完美重要。

参考资源

• ECC Continuous Learning v2 Spec
• ECC Memory Persistence Hooks