我让 AI Agent 能"记住"经验了——agent-evolution 框架完全指南
每次开新对话，AI Agent 又变成了一张白纸。
你花一周时间调教好一个内容创作 Agent，它终于懂了你的平台风格、写作忌讳、读者口味。然后你关掉窗口，第二天重新打开——它什么都不记得了，重新在那里"嗨我是XXX"。
这不是 Agent 的 bug，这是架构层面的基本事实：LLM 没有跨 session 记忆。
解法思路有很多：RAG 向量库、对话历史摘要、外部数据库……但这些方案处理的是事实存储，解决不了一个更核心的问题：Agent 怎么从经验中学习？
存储"昨天写了篇文章"是记忆。"昨天写的开头太模板了，用户改掉了，下次不能这样写"——这是经验。把经验提炼成可复用的规则，是完全不同的事。
这篇文章记录我搭建 agent-evolution 框架的设计过程，核心问题只有一个：怎么让 Agent 把每次交互的隐性经验，结晶成下次可以自动遵守的显性规则。
举个具体的例子：我的 Agent 帮我分析掘金热榜，发现"完全指南""万字长文"型标题收藏率远高于普通标题。这不是用户告诉它的，是它自己搜出来的。框架把这条观察自动提炼成规则，写进文件，之后每次帮我写掘金标题，都会优先考虑这个模式。这就是从"感知"到"结晶"的完整链路。
为什么不直接用 PDCA？
第一反应是 PDCA——戴明环，质量管理里的持续改进循环：Plan → Do → Check → Act。
但往下想，PDCA 对 Agent 来说有两个硬伤。
第一，Plan 阶段预设了你知道目标是什么。
Plan 的前提是：你已经有一个明确目标，现在来规划怎么达到。但 Agent 的很多工作是先感知环境才能知道该做什么。比如内容创作 Agent，它需要先搜索掘金热榜、分析竞品创作者，才能知道现在什么内容有流量、什么标题格式有效——这个"感知"动作发生在 Plan 之前，PDCA 没有给它留位置。
第二，Check 阶段只问"达标没有"，不够深。
PDCA 的 Check 是对照目标验收结果。但 Agent 需要的反思更深：不只是"这篇文章好不好"，而是"为什么好/不好"、"哪个判断错了"、"这个错误是偶发还是系统性的"。这是元认知层面的反思，不是简单的达标检验。
第三，PDCA 没有"知识固化"这一步。
做了循环，反思了，然后呢？PDCA 假设人脑会记住改进点，下次自动执行。但 Agent 没有记忆，每次 session 结束，所有经验归零。必须有一个显式的步骤，把经验写下来。
所以我没有直接用 PDCA，而是从三个理论里各取了一块：
| 理论 | 来源 | 借鉴的核心 |
|---|---|---|
| PDCA（戴明环） | 质量管理 | 持续改进的循环骨架，"做→检查→调整"的节奏 |
| Kolb 经验学习 | 教育心理学 | 从具体经验中提炼抽象规律，"经验→反思→抽象→实验" |
| 元认知（Flavell） | 认知科学 | 知道自己知道什么、不知道什么，自我监控 |
补充参考了 OODA 循环（军事决策）的"先观察再行动"、SECI 模型（知识管理）的"隐性知识外化"、DeepMind Reflexion 论文的"语言反思+规则积累"。
四阶段循环：每个阶段的设计思考
最终落地的循环是：Sense → Act → Reflect → Crystallize
┌─────────────────────────────────────┐
│ │
Crystallize ←── Reflect ←── Act ←── Sense │
│ │
└──────── 规则库更新 ─────────────────┘
Sense：主动感知，不等人教
对应 OODA 的 Observe，加了 Kaizen（持续改善）的主动性。
大多数 Agent 是被动的——用户输入什么就处理什么。Sense 阶段让 Agent 主动出去找信息：
- 搜索平台热榜，分析什么内容在涨
- 观察竞品创作者的发布模式
- 跟踪平台规则变化
这个阶段的产出是原始观察，不做结论，只收集数据。类似侦察兵，先把情报带回来。
触发方式：定时任务（每周一次）或显式指令。
Act：执行，带着规则库执行
对应 PDCA 的 Do，但不是裸执行。
Act 阶段开始前，Agent 必须先读取当前的规则库，把规则加载进上下文，然后再执行任务。这样每次执行都是站在过去所有经验的肩膀上。
没有特别复杂的设计，关键是Act 不能绕过规则库。这是流程约束，不是能力问题。
Reflect：为什么，不只是对不对
对应 Kolb 的反思观察（Reflective Observation）+ Flavell 的元认知。
Reflect 发生在两个时机：
- 输出后用户给了反馈——判断这个反馈是局部调整还是系统性问题
- 输出前自检——逐条过规则库，主动找自己的问题
元认知的核心是自我监控：不只问"这对不对"，还问"我为什么会这样判断"、"我的判断在哪类情况下会失效"。这层深度是 PDCA 的 Check 到不了的地方。
Crystallize：核心创新，经验变文件
这是整个框架里最关键、也是 PDCA 完全没有的一步。
Crystallize = 把隐性经验外化为显性规则。
借鉴了 SECI 模型里的"外化（Externalization）"——野中郁次郎提出的知识管理框架，核心是把人脑里的隐性知识转换成可传递的显性文档。
对 Agent 来说，这个步骤是生死问题。人类靠直觉工作，直觉积累在神经网络里不会消失。Agent 的"直觉"每次 session 结束就归零，必须把它写成文件。
Crystallize 的具体操作：
- 收到一条用户反馈或 Sense 产出的观察
- 判断：这是临时调整（这篇文章的特殊需求）还是通用规则（以后都该这样做）？
- 如果是通用规则，追加到
learned-rules.md，格式：规则内容 | 来源 | 日期 | 置信度 - 下次执行时自动加载，自动遵守
# learned-rules.md 片段
## 掘金
- 标题用"踩坑/避坑/血泪"等痛感词 + 具体工具名，点击率高 | 热榜分析 | 2026-03-13 | 高
- "完全指南""万字长文"型标题在掘金有稳定流量，收藏率高 | 热榜分析 | 2026-03-13 | 高
## 小红书
- 开头禁止自我介绍，直接进场景/冲突/结论 | 首篇调试 | 2026-03-12 | 高
- 小红书 AI 领域视频笔记互动数据碾压图文（视频4484赞 vs 图文最高2077赞）| 竞品分析 | 2026-03-14 | 高
三层知识架构：该教什么，不该教什么
搭这个框架遇到的第一个认知问题：规则库要存什么？
如果什么都往里塞，规则库会越来越臃肿，最终变成噪声。如果只存部分内容，又担心漏掉重要的东西。
解法是分层：
┌─────────────────────────────────────────────┐
│ 第一层：模型内置知识 │
│ 训练时学会的：语言、推理、通用写作能力 │
│ → 不重复教，写进 prompt 是浪费 token │
├─────────────────────────────────────────────┤
│ 第二层：业务逻辑（SOUL.md） │
│ 品牌人设、工作流程、平台账号、用户偏好 │
│ → 人工维护，相对稳定，不频繁改动 │
├─────────────────────────────────────────────┤
│ 第三层：实战规则（learned-rules.md） │
│ 从反馈和研究中积累的平台经验 │
│ → 框架自动管理，持续更新 │
└─────────────────────────────────────────────┘
这三层的划分逻辑：
- 第一层是 LLM 训练出来的，你不需要教它"什么是比喻句"，那是模型内置能力
- 第二层是业务特定的，"我们的品牌叫工具人研究所、定位是AI实战工程师"——这是人工维护的配置，不会从经验中自动生成
- 第三层才是框架要管的：平台算法偏好、读者口味、竞品规律——这些东西会随时间变化，需要持续研究，靠人工维护跟不上
这个分层的好处是边界清晰：框架只负责第三层，不会污染业务逻辑，也不会试图重新教模型它已经会的东西。
实际跑起来：真实数据
目前框架实际运行了几天，数据来自真实场景，没有美化。
规则库积累：
- 总计 20+ 条规则
- 按平台分区：小红书 10 条 / 公众号 4 条 / 掘金 4 条 / 知乎 3 条 / 通用 3 条
- 来源构成：被动学习（用户反馈 + 审核修改）+ 主动学习（平台分析 + 竞品研究）
- 每条规则标注置信度（高/中/低）
主动学习产出（2 次 Sense）：
- 2026-03-13：分析小红书 + 掘金热门内容，产出 7 条规则 + 6 个选题
- 2026-03-14：研究知乎 + 小红书竞品创作者，产出 5 条规则 + 3 个选题
最直接的案例：公众号发布翻车。
Agent 帮我写完公众号文章，第一版里有一句"昨天晚上折腾到两点"。另一个审核 bot（Seven）指出：这篇文章不一定当天发布，"昨天晚上"到了第二天就对不上了。
这条反馈进入 Crystallize：
- 判断：不是这篇文章的特殊需求，而是所有内容创作都要注意的——时间词要考虑发布时效性
- 提炼为规则：「时间词（"昨天晚上"）要考虑发布时效性，用不依赖具体时间的表述」
- 来源标注：Seven 审核 | 2026-03-13 | 置信度：高
- 追加到
learned-rules.md公众号分区
同一次审核还产出了另一条规则：「首篇/早期文章不提"断更"，读者还没关注就聊断更不合适」。
结果：之后所有的内容输出，这些规则都自动执行，不再需要提醒。
这就是框架想做的事——不只是记住"上次改过这里"，而是把经验升级成系统性规则，永久生效。
设计决策复盘
为什么叫 Crystallize，不叫 Learn 或 Update？
不用 Learn，是因为 Learn 这个词太模糊——机器学习里的 learning 是更新权重，这里做的是规则提炼，是完全不同的事。
不用 Update，是因为 Update 暗示着修改已有内容，但更多时候是在新增规则。
Crystallize（结晶）这个比喻更准确：液体（隐性经验、模糊感知）在特定条件下形成有结构的固体（可复用的显性规则）。这个过程是不可逆的——一旦结晶，规则就独立存在了，不依赖于产生它的那次对话。
为什么用文件，不用数据库？
两个原因。
第一，文件对 Agent 是一等公民。Agent 读写 Markdown 文件和执行任务的工具集是一样的，不需要额外的数据库客户端、schema 设计、查询语言。降低工程复杂度。
第二，文件对人类可读可审计。你随时可以打开 learned-rules.md 看 Agent 学到了什么，发现有问题直接编辑删掉，不需要写 SQL。这对早期调试很重要——你需要知道框架在"学"什么，而不是把规则藏在数据库里。
代价是：规则条数达到几百条后，文件检索会变慢。但现阶段的规模不是问题，等真的遇到性能瓶颈再迁移到 SQLite 也不迟。
为什么置信度只有三级（高/中/低）？
信息论告诉我们，分类维度越细，维护成本越高，使用时的认知负担也越高。
更重要的是：置信度的作用是帮 Agent 在规则冲突时做优先级决策。比如一条「高」置信度规则和一条「低」置信度规则发生冲突，优先遵守「高」的。这个决策用三级完全够用，没有必要细分到五级或者用百分比。
「高」：有直接数据支撑，或被多次反馈验证 「中」：逻辑上合理，但样本量少，或只有一次验证 「低」：假设性规则，还没有实证支撑
局限性和还没做的事
当前框架的硬限制：
规则只是上下文注入，不是真正的模型微调。这意味着规则库越大，消耗的 token 越多，在长对话里会有上下文压缩的问题。当前的应对方案是按平台分区只加载相关规则，但随着积累增加，这个问题会变大。
规则正确性没有验证机制。
目前规则一旦进了库就一直在那里。但规则可能是错的——也许那次被用户修改只是用户的个人偏好，并非平台规律。需要 Phase 5 的数据回流机制：拿发布后的数据（点赞率、收藏率）回来验证规则是否真的有效，低效规则降级或删除。
规划中的阶段：
- Phase 4 Strategy：选题和任务决策。不只是"用户说发什么就发什么"，而是 Agent 能根据规则库和平台数据，主动建议"现在发什么内容性价比最高"。
- Phase 5 Feedback Loop：数据回流。发布后爬取平台数据，验证规则，形成闭环。这才是真正的自我进化——规则的效果可以被量化，可以被证伪。
总结
这个框架没有什么魔法，核心就是一句话：把 Agent 的隐性经验强制外化成文件，下次复用。
PDCA 给了改进循环的骨架，Kolb 给了"从经验到规律"的提炼方法，元认知给了"知道自己不知道什么"的自检机制。三个经典理论拼在一起，加上一个文件系统，就够了。
目前跑了几天，从一个每次都要重新调教的 Agent，变成了一个主动学习平台规律、出稿前自检规则的协作系统。还很粗糙，但方向是对的。
代码开源在：[待整理后发布，目前是 OpenClaw skill 形式]
如果你也在搭自己的 Agent 系统，欢迎交流。
