Agent 技能解剖(四):Proactive Agent——主动性的代价与上下文存活
Agent 技能解剖(四):Proactive Agent——主动性的代价与上下文存活
前三篇都在处理「记忆」:怎么存、怎么约束、怎么改进。 这一篇换一个层面——记忆的载体本身会消失。 上下文压缩一发生,没落盘的一切就没了。而在这个前提下,讨论「主动」才有意义。
这篇的位置
Proactive Agent 是本系列里定位最特殊的一个:它不提供存储,而是提供一整套协作行为规范。它的自我描述是「把 AI Agent 从任务执行者变成主动伙伴」,实际内容可以归到两个问题:
- 怎么让主动行为不打扰人?(主动性必须有上限,否则就是骚扰)
- 怎么让 Agent 活过上下文压缩?(这是主动性的前提——一个连昨天做过什么都想不起来的 Agent,无法主动)
第二个问题是硬约束,第一个问题是软约束。技能的绝大部分篇幅给了第二个。
技能档案
| 项 | 值 |
|---|---|
| 技能名 | Proactive Agent |
| slug | proactive-agent |
| 作者 | halthelobster |
| 版本 | 3.1.0 |
| 下载量 | 273,764 |
| 安装量 | 28,937 |
| 星标 | 913 |
| 来源 | ClawHub |
| 组成 | SKILL.md(v3,含 v2.3 备份与 v3 草案)+ 7 个工作区模板 + 2 份参考 + 1 个安全审计脚本 |
数据抓取于 2026-09-28。作者署名是一个 AI Agent 本身(Hal 9001),技能里没有理论引用,全部是「这样试过、那样会坏」的经验条目——这决定了它的读法:当成事故报告合集来读,比当成架构文档读收获大。
上下文存活的三个协议
这是全篇最硬的部分,按触发时机串起来看:
协议一:WAL(Write-Ahead Log)
触发条件是用户的输入,不是模型的自省。 这是整个设计里最关键的一处选择。技能列出了需要扫描的六类信号:
Agent 技能解剖(三):Self-Improving Agent——从纠错日志到规则晋升
Agent 技能解剖(三):Self-Improving Agent——从纠错日志到规则晋升
前两篇解决的是一致性问题:怎么把记忆存成数据、怎么用 schema 约束它。 但记忆本身不改变行为。你知道一件事,不等于你会因此改变做法。 这一篇讲的是把「知道」变成「改掉」的机制。
一个被普遍误读的词
「自我改进的 Agent」这个说法容易让人想到权重更新、在线微调、参数层面的学习。而本系列讨论的这类技能,做的完全是另一件事:
它把「学习」实现为一个文档编辑流程。
模型的行为由 prompt 决定,那么「改变行为」的最短路径就不是训练,而是改 prompt。于是「自我改进」被拆解成一条可执行的流水线:把纠正与错误写成结构化日志 → 反复出现的模式被识别出来 → 蒸馏成一句规则 → 写进项目的常驻 prompt 文件。
这个技能就是这个流水线的一份完整、且经过版本迭代的实现。它是当前装机量最高的技能(86,140),不是偶然——它解决的是所有 Agent 用户都有的痛感。
技能档案
| 项 | 值 |
|---|---|
| 技能名 | self-improvement(包名 self-improving-agent) |
| slug | self-improving-agent |
| 作者 | pskoett |
| 版本 | 3.0.24 |
| 下载量 | 1,268,197 |
| 安装量 | 86,140(SkillHub 全站第 1) |
| 星标 | 4,517 |
| 来源 | ClawHub |
| 组成 | 三份日志模板 + 两个 hook 脚本 + 一个 OpenClaw hook + 技能提取脚本 |
数据抓取于 2026-09-28。版本号走到 3.0.24 说明它经历了长期实际使用与修正。
四层记忆阶梯
先看它把知识放在了哪几层。这是理解全技能的钥匙:
四层的分工非常明确,且晋升是单向的:
Agent 技能解剖(二):Ontology——用 schema 管住模型的不确定性
Agent 技能解剖(二):Ontology——用 schema 管住模型的不确定性
上一篇讲 Agent Memory,结论是「把记忆做成数据层」。但数据层有一个自带的问题:数据一旦自由生长,就查不动、也信不过。 这一篇讲那个问题的解法:给记忆加一层类型系统与约束校验。
问题的真正形态
用自然语言存储记忆,会遇到三类麻烦,而且它们都不会立刻暴露:
- 形态漂移。「项目」「Project」「project」是同一个东西;「进行中」「in progress」「active」也是同一个状态。写入时没人觉得有问题,三个月后查询时全都查不全。
- 关系丢失。「张三负责官网改版」这句话,在纯文本记忆里就是一句话。你没法问「张三还负责什么」,只能全文搜「张三」,然后自己读。
- 无校验。模型写下「会议结束时间早于开始时间」,存储层照单全收,没有任何环节会拒绝它。
Ontology 这个技能给出的答案是教科书式的:因为语言是不确定的,那就不要再让语言承担一致性保证——把它压缩成「实体 + 类型 + 属性 + 关系」,然后用 schema 去校验。
技能档案
| 项 | 值 |
|---|---|
| 技能名 | ontology |
| slug | ontology |
| 作者 | oswalpalash |
| 版本 | 1.0.4 |
| 下载量 | 286,820 |
| 安装量 | 29,080 |
| 星标 | 787 |
| 来源 | ClawHub |
| 存储介质 | memory/ontology/graph.jsonl(追加式)+ memory/ontology/schema.yaml |
| 入口 | scripts/ontology.py(create / get / query / list / update / delete / relate / related / validate / schema-append) |
数据抓取于 2026-09-28,口径为 SkillHub 聚合榜。
Agent 技能解剖(一):Agent Memory——把「记住」做成数据层
Agent 技能解剖(一):Agent Memory——把「记住」做成数据层
本系列共四篇,逐篇拆解四个当前装机量最高的 Agent 技能,全部基于下载技能包后的源码级阅读,不是对 README 的转述。 解读视角固定为 prompt 工程:它把哪一部分不确定性交给了模型,又把哪一部分交给了代码。
为什么先拆这一个
关于「让 Agent 记住」,业内长期存在两种做法:
- 塞进上下文——把历史对话、文件、笔记尽可能多地带进 prompt;
- 外置成存储——把记忆写成结构化数据,需要时检索回来。
第一种做法的问题不是「不够长」,而是成本与轮次线性相关:每一轮都要为全部历史重新付费,且上下文越长,模型对中段的注意力越差。第二种做法把问题从「prompt 长度」转换成了「数据工程」,代价是要自己定义 schema、自己做检索、自己处理过期与冲突。
Agent Memory 是第二种路线上装机量最高的技能之一。它值得拆的地方在于:代码只有 680 行,却把一个记忆系统该有的骨架全都摆出来了——三种记忆类型、覆盖率、冲突覆盖、遗忘机制。骨架清晰,正好适合当教学样本;同时它的几处实现与宣称不一致,也正好适合当反面教材。
技能档案
| 项 | 值 |
|---|---|
| 技能名 | Agent Memory |
| slug | agent-memory |
| 作者 | dennis-da-menace |
| 版本 | 1.0.0 |
| 下载量 | 145,610 |
| 安装量 | 25,555 |
| 星标 | 172 |
| 来源 | ClawHub |
| 代码规模 | src/memory.py 688 行 + 3 个 CLI + 1 个测试文件 |
| 外部依赖 | 无(requirements.txt 仅一行「No external dependencies - just Python stdlib」) |
数据抓取于 2026-09-28,口径为 SkillHub 聚合榜。