写在前面:为什么要搞懂这件事
2026 年市面上的 agent 框架在快速同质化——MCP、tool use、memory、skill 这几个组件大家都有。但组件一样,效果差一个数量级。差距不在有没有这些组件,而在组件之间的反馈闭环有没有设计好。
市面上有两种典型路线:一种偏"给你一个能跑的 agent"(Hermes 类),一种偏"给你一套能进化的 skill 系统"(OpenClaw 类)。表面是功能差异,底层是对"智能从哪里来"的判断不同——智能在模型里,还是在规则的积累里。
Hermes 派相信智能在模型里,agent 框架越完善、产出越好。OpenClaw 派相信智能在规则的积累里——模型是引擎,但方向盘是 skill,skill 会进化,agent 才真正变聪明。
这篇文章不为某个具体工具而写,是为理解 agent 进化的底层逻辑而写。搞懂了底层,再看任何新框架都能快速判断它的上限,不被任何单一工具锁死。这比学会用某个工具更底层——是在 AI 时代给自己建不会过时的知识资产。
一、先理解进化的本质
skill 每一次"v1.1",背后都是一次具体的失败——某篇稿子看着别扭但说不出哪里别扭,下次写之前不得不多想一层,这个"多想一层"被写进 SKILL.md。所以 skill 文件本质上是失败模式的墓碑群:每一条规则都对应一次翻车。
这个过程有三层递进:
显性化。原本靠手感判断"这标题不行",现在写成"标题 15-25 字含数据锚点"。隐性知识变成显性规则,代价是失去灵活性,收益是可复现。
边界化。规则从"要做 X"演化为"A 场景做 X,B 场景做 Y"。成熟的 skill 不是规则越来越多,而是规则之间的触发条件越来越清晰。
压缩化。十条表层规则可以合并为两条更深的原则。规则变少,判断力反而更强——因为被压缩掉的是描述,留下的是结构。
skill 进化的终点不是规则变多,而是脱离你也能跑——你不在现场的时候,它依然能产出你会认可的东西。
二、反馈不是单一信号,是光谱
设计自进化机制的第一步,是分清反馈信号的不同强度:
第一层:显性否定——用户说"不对"、"太 PR 了"、"重写"。信号最强,信息量最低:只告诉你错了,没告诉你怎么错。
第二层:定向修改——用户说"标题改成 XX"、"加一段竞品对比"。信号强度中等,信息量高,因为"正确答案"直接给了你,可以从 diff 里反推规则。
第三层:隐性偏离——用户不说话,自己动手改了一遍。最容易被忽略的信号,但信息密度最高。用户懒得解释为什么,但改动本身就是规则。
第四层:沉默放弃——这次没说话,下次不用了。最弱信号,也最危险,因为你完全不知道发生了什么。
好的反馈机制要做到两件事:一是让每种信号都能被无损捕获,二是让不同强度的信号路由到不同的处理流程。用同一种方式处理四类信号,强信号会淹没弱信号。
三、三层架构:执行 / 审批 / 宪法
让 Claude 承担 skill 进化的大部分工作是可行的,但必须先分层: 执行层(Claude 独立跑):产出内容、记日志、分析反馈、生成规则候选、起草新版 SKILL.md。
审批层(你保留否决权):新规则写入 SKILL.md 之前,你看一眼,yes 或 no。你不用自己写规则,只做判断。
宪法层(只有你能改):一份 meta-SKILL.md,规定"什么样的规则能进 skill"、"什么样的反馈算有效信号"、"什么情况下 Claude 必须停下来问你"。这是 Claude 永远不能触碰的。
分层的意义是:Claude 在宪法内自由演化,你只在宪法层和关键节点出现。这样既解放你的精力,又不让 skill 漂移成 Claude 版的你。
四、让 Claude 接管执行层的五个机制
1. 日志里加"Claude 自评字段"
每次产出之后,Claude 自己先打分:
让 Claude 先承认哪里心虚。用户反馈回来后对照看——如果用户改的正是 Claude 自评薄弱的地方,说明判断力在线,这条反馈权重正常;如果改的是 Claude 以为没问题的地方,说明存在盲区,这条反馈权重更高,要特别关注。
让 Claude 的自我认知也进入闭环,而不只是被动等用户反馈。
2. 触发机制做成"Claude 主动申请"
不靠脚本定时扫描,让 Claude 每次用 skill 之前先看最近 N 条日志。如果发现模式(比如"最近 5 次里有 3 次标题被改"),Claude 在产出之前先说:
我注意到标题规则可能需要调整,理由是最近 5 次产出中有 3 次标题被改,改动模式集中在"数据锚点不够具体"。是否先更新 skill 再产出?
你回 yes,进入更新流程;你回 no 或不理,Claude 按当前 skill 继续产出。Claude 负责发现,你负责授权。
3. 规则生成用"双盲复核"
单实例容易自我强化——它写的规则它自己看当然觉得对。加一层对抗审查:
- 实例 B 不知道规则谁写的,扮演挑刺者,找反例和冲突
- 实例 A 根据 B 的反驳改稿或坚持原案并说明为什么
你看到的不是"Claude 建议加这条规则",而是"Claude 辩论完之后留下这条规则,以及它被挑战时的回应"。可信度高一个量级。
4. 版本证据链
每次 skill 升级,把触发升级的那批日志归档到 archive/v2.1-evidence/,配一个 CHANGELOG.md 写明每次升级的原因和触发证据。
这一步看起来琐碎,但关系到 skill 能不能传承。半年后你或另一个 Claude 实例回头看 v2.1 为什么长这样,证据链完整才不会靠猜。
5. 风格指纹检测
最大风险是 skill 悄悄变得不像你了——每一步升级都合理,整体却已经跑偏。
解决方法:留一批"黄金样本"(10 篇你最满意的历史产出)。每次 skill 升级后,用新 skill 重写这批样本,对比新旧差异。差异超过阈值(可以用向量相似度或你盲测判断),触发警报:"新 skill 可能偏离了原始风格"。
这是防熵增机制。没有它,skill 会在迭代中无声地漂移。
五、宪法层的硬约束
meta-SKILL.md 里至少写死这些,Claude 不能绕过:
规则新增必须带证据链。任何进入 SKILL.md 的新规则,必须附带触发它的原始日志条目 ID,不能凭空产生。
规则删除比新增更严。删除最危险,因为你看不见"少了什么"。设定删除必须经你明确确认,Claude 不能自行删除。
规则冲突必须显性化。新规则和旧规则矛盾时,Claude 不能自行合并,必须列出两条让你裁决。
品味类规则禁止自动化。涉及"什么好看"、"什么有品"的规则,永远要你拍板。Claude 可以建议,不能写入。
定期回滚演练。每季度做一次"如果回到 v1,会损失什么"的对照,防止规则虚胖。
这些约束不是为了限制 Claude,是为了让 Claude 的自由演化始终在可控边界内发生。
六、为什么不建议 100% 自动化
技术上 Claude 可以自己改自己的 skill、自己评估、自己回滚——完整闭环能跑。但有两个根本问题让这件事不该做到底:
一是责任不对称。skill 产出的内容署名是你,翻车是你承担。让一个不承担后果的系统全权决定规则,本质是责任和权力的分离。保留审批权不是技术需要,是责任需要。
二是品味会熵增。Claude 的规则优化目标是"让历史反馈模式被满足"——这是向后看的优化。你本人有一种向前看的能力:虽然过去没人反馈过这个问题,但你预感下一步市场会这样走,skill 要提前变。这种前瞻判断 Claude 学不会,因为日志里没有未来。
如果 100% 自动化,skill 会越来越贴合过去,越来越跟不上你的直觉。
七、设计的终点
好的 skill 自进化系统,不是"让 AI 接管 skill 维护",而是让 AI 承担 95% 的机械工作,让你的判断集中在 5% 最关键的节点。
这 5% 是:
其余 95%——记录、统计、分析、起草、复核、归档——都应该自动化。
一句话:好的自动化不是取代判断,是把判断点压缩到最少、最关键的几个位置。skill 的自进化设计,本质是帮你把精力省下来,用在那些 AI 替代不了的事情上。
八、这只是起点:agent 设计哲学的一块碎片
这篇文章只是 agent 底层逻辑的第一块地图碎片。完整的地图还需要画:
- 记忆系统:上下文如何选择、长期记忆何时触发、什么该被遗忘
- 工具调用:什么该做成 tool、什么该做成 skill、什么该硬编码
- 多 agent 协作:多实例如何分工、如何交叉复核、如何做对抗审查
- 人机边界:哪些决策永远保留给人、哪些可以完全交给 agent
每一块单独成文,三个月之后手里就是一套属于自己的 agent 设计手册。不管谁家出新框架、新概念,都能快速判断它值不值得学、学哪部分、上限在哪里。
这种认知不是线性积累,而是复利——每理解一层底层逻辑,下一个新工具的上手成本就低一点;每设计一个自己的 agent 组件,对"AI 能做什么、不能做什么"的边界就清楚一点。2026 年开始攒,到 2027、2028 会拉开和"只会用工具"的人的巨大差距。
工具会被淘汰,设计哲学不会。