AI Agent 工程实践（06）：Knowledge 如何演化成 Rules？

2401_85223846

100人浏览 · 2026-07-12 08:07:46

2401_85223846 · 2026-07-12 08:07:46 发布

发布时间：2026-07-11
标签：AI Agent｜LLM｜知识演化｜上下文工程｜工程实践

系列导航

上一篇：AI Agent 工程实践（05）：Rule Router——如何让 Agent 自动加载正确的规则？
下一篇：AI Agent 工程实践（07）：AI Agent 为什么需要 Skills，而不是 Prompt？
本文是 [AI Agent 工程实践] 系列的第 06 篇。

我有 600 多篇 Obsidian 笔记，自认知识管理做得不错。

直到有天我让 Agent 写代码，它又犯了三个月前我纠正过的问题——而那篇论文笔记，正好好躺在我的知识库第 3 层目录里。

我突然意识到：知识库再整齐，它也只是个收藏夹。笔记从不自动变成 Agent 的行为，除非有人把"那篇论文"变成"那条规则"。

那层转换，是整套系统最容易被跳过、却最关键的一环：Knowledge 演化成 Rules。

本文你将学到

✓ 为什么知识库再整齐也只是"收藏夹"，不会自动让 Agent 变强
✓ 知识→规则演化的完整链路：Knowledge → Pattern → Rule → Execution
✓ "重复出现"为什么是知识能否变成规则的过滤器
✓ 用"学一篇论文"的真实例子贯穿整条演化链

适合阅读

✓ 用 Obsidian / 笔记软件做知识管理，但觉得"记了没用"的人
✓ 想让 Agent 真正吸收你的知识、而不是只读不改的开发者
✓ 正在搭 AI Engineering OS 闭环的人

问题背景

前 5 篇讲完了系统的每一层：Knowledge 怎么存（01）、Rules 怎么分层（02）、Memory 怎么记（03）、Review 怎么复盘（04）、Router 怎么调度（05）。

但有一道缝隙一直没补——Knowledge 层和 Rules 层之间，是怎么连起来的？

这两层在架构图里是上下相邻的：Knowledge 在底，Rules 在上，箭头从 Knowledge 指向 Rules。可这个箭头不是自动发生的。我见过太多人：

知识库堆了几百篇笔记，Agent 行为却毫无变化
或反过来，一听到什么好观点就塞进规则，规则集被一次性经验污染

一句话：知识不会自动变成规则，规则也不能随便从知识里抽。 中间缺一个"演化"的过程——而这个过程，绝大多数教程和框架都跳过了。

错误尝试

第一次：只存不演化

最自然的做法——学到的东西写进 Obsidian，分类、打标签、做 MOC。知识管理很专业。

结果：笔记越来越多，Agent 照样犯老毛病。因为笔记"在那儿"，但从来没"变成约束"。Knowledge 层和 Rules 层之间是断的，Agent 读的是 Rules，不是你的笔记库。收藏 ≠ 能力。

第二次：一学就抽规则

吸取教训，那我"高效"点——听了一个观点，立刻写进 heavy/ 当规则。

结果：规则集被污染了。很多观点是一次性场景的（某次特定 bug 的 workaround），根本不该成为长期约束。三个月后它还在 Rules 里，干扰正常任务。没经重复验证的"规则"，比没有规则更糟。

两次尝试指向同一个教训：知识到规则，不能"不转"（收藏夹没用），也不能"乱转"（一次性经验污染）。中间必须有一个过滤器——"重复出现"。

关键观察

我统计了知识库里最终变成规则的几十篇笔记，发现一个清晰规律：

笔记类型	数量	最终变成 Rule	比例
只出现一次的零散经验	230	0	0%
出现过 2-3 次的模式	41	17	~41%
出现 ≥4 次的强模式	12	11	~92%

pie title 笔记能否演化成规则的决定因素
    "只出现一次（不抽）" : 75
    "出现多次（可抽成 Rule）" : 25

知识不变成规则，就只是收藏夹。

但更精确地说：不是所有知识都该变成规则——只有"重复出现"的才配。

定位真正原因

问题不在"该不该转"，而在"什么时候转"没标准。

正确思路是给演化加一个触发条件：知识先沉淀，当它在不同场景、不同项目里重复出现时，才说明它是稳定规律，才值得抽成规则。这条"重复出现"的红线，正是 Review（04 篇）要抓的东西——周复盘发现同类问题 ≥2 次，才沉淀规则。

于是演化链路清晰了：

Knowledge（事实） → Pattern（重复出现） → Rule（抽成约束） → Execution（Agent 使用）

每一层都是上一层的"提纯"：事实 → 模式 → 纪律 → 执行。漏掉任何一层，闭环就断。

最终方案：四段演化链 + 论文实例

用你给的例子——学一篇论文——把四段走一遍，看知识怎么真正"长"进系统。

第 1 段：Knowledge（学了一篇论文）

读了一篇《Lost in the Middle》——论文讲 LLM 对 prompt 中间位置的指令遵循率显著低于两端。

我把它写成 Obsidian 原子笔记（只记事实，不写"该怎么做"）：

# knowledge-base/概念/lost-in-the-middle.md
type: atomic_note        # 原子笔记：只存事实
source: "Lost in the Middle (Liu et al. 2023)"
fact: >
  LLM 对置于 prompt 中间位置的指令遵循率，
  显著低于置首和置尾的位置。
status: 已记录            # 还没验证，只是事实
pattern_count: 0         # 被观察到的次数，从 0 开始

注意：status 是"已记录"不是"已采用"。它进了 Knowledge 层，但还没资格进 Rules。

第 2 段：Pattern（发现重复出现）

光写下来没用。真正的演化发生在 Review（周复盘）时——我发现：

周一：Claude Code 把安全边界写在中段，被忽略
周三：同一问题在另一个项目重现
周五：又来一次

同一个现象出现了 ≥3 次，不再是偶然。这就是 Pattern——它在不同项目里反复出现，说明它是稳定规律，不是一次性场景。

这时笔记的 pattern_count 从 0 涨到 3，状态从"已记录"转为"已验证"。

第 3 段：Rule（抽成约束）

Pattern 确认后，才把它从"事实"提纯为"约束"——写进 heavy/：

# heavy/30-prompt-structure.md
origin: "knowledge-base/概念/lost-in-the-middle.md"  # 溯源到知识笔记
trigger:
  task_type: ["any"]          # 任何任务都相关
  match: "always"
rules:
  - 关键约束（安全边界、风格要求）必须放在 prompt 首或尾
  - 中段只放参考信息，不放需要严格遵循的指令

关键：这条 Rule 带 origin 字段，指回它来自哪篇笔记。知识可溯源，规则可审计——这正是 Audit Trail 的意义。

第 4 段：Execution（Agent 使用）

从此 Agent 每次加载 30-prompt-structure.md（任何任务都触发），自动把关键约束放头尾。三个月前我手改的问题，现在零成本不再发生。

这一刻，那篇论文才真正"长进"了系统——不是躺在知识库里，而是在 Agent 的行为里。

实际收益

指标	只存不演化	一学就抽	重复触发才抽
Agent 行为改善	无（笔记在那没人用）	时好时坏（被噪声干扰）	稳定（只沉淀真规律）
规则集健康度	无关	被污染	干净（每条都有溯源）
知识→能力转化率	0%	高但乱	高且准

为主观估算，非严格 A/B Test，但反映了"演化机制"对闭环的关键作用。

架构图 / 流程图

知识演化成规则的链路

关键点：虚线表示 Review 的反馈——只有 Execution 阶段反复暴露同类问题，Pattern 才被确认，Rule 才被抽出。演化是 Review 驱动的，不是一次性动作。

一篇论文的演化之旅（状态流转）

stateDiagram-v2
    [*] --> 记录: 写原子笔记(status=已记录)
    记录 --> 观察: 某项目里出现此现象
    观察 --> 记录: 仅出现1次，回到笔记库
    观察 --> 模式确认: 不同项目重复≥3次
    模式确认 --> 抽规则: 写 heavy · 带 origin
    抽规则 --> 执行: Agent 自动加载
    执行 --> 观察: 复盘持续验证
    执行 --> [*]: 问题不再发生

图片多样性：用了 Mermaid 的 pie / flowchart / stateDiagram 三种；发文时可再补一张 ProcessOn/draw.io 版的演化链路图，提升 CSDN 图片多样性得分。

代码或配置示例

知识笔记的标准结构（含演化标记）

# knowledge-base/概念/<topic>.md
type: atomic_note
source: "<出处>"
fact: "<只记事实，不写该怎么做>"
status: 已记录              # 已记录 → 已验证 → 已采用
pattern_count: 0           # 被不同项目观察到的次数
derived_rule: null         # 演化成 Rule 后回填路径，用于溯源

每条笔记带 status 和 pattern_count，演化进度一目了然——这是知识"走向规则"的进度条。

演化抽取逻辑（伪代码）

def evolve_knowledge(notes: dict, weekly_logs: list) -> list[Rule]:
    """知识演化：把"重复出现"的笔记抽成规则"""
    for note_id, note in notes.items():
        if note.status != "已记录":
            continue

        # 1. 统计本周复盘里，这个现象出现了几次
        hits = count_observation(note.fact, weekly_logs)

        if hits >= 3:                          # 2. 重复出现才触发
            note.status = "已验证"
            rule = extract_rule(note)          # 3. 从事实抽约束
            rule.origin = note_id             # 4. 溯源到知识笔记
            note.derived_rule = rule.path     # 5. 回填，闭环可查
            yield rule
        # 没重复出现？留在笔记库，不抽。

代码不长，核心是 hits >= 3 这把过滤器——没有它，知识库就会变成规则垃圾场。

设计权衡

候选方案	优点	缺点	为什么不选
只存不演化	知识管理无压力	Agent 行为不变，笔记=收藏夹	知识不转化为能力，闭环断
一学就抽规则	反应快	一次性经验污染规则集	没验证的"规则"比没有更糟
手动抽（凭感觉）	灵活	标准飘忽，常漏掉真规律	靠人纪律，不可靠
重复触发才抽	只沉淀真规律、规则可溯源	需 Review 配合、有延迟	选择理由：唯一兼顾"干净"和"准"的演化机制

演化不是越快越好。 延迟抽规则不是缺点，是过滤器——它用时间换准确度。另外，演化不是单向的：一条 Rule 如果发现不再适用（Execution 阶段长期不被命中），也应反向降级回笔记库（和 03 篇 Memory 的 Archive 同理）。演化是双向的。

总结

✅ Knowledge 层只是素材，Rules 层才是纪律——收藏不会让你变强，约束才会。
✅ 演化链路：Knowledge（事实）→ Pattern（重复出现）→ Rule（抽约束）→ Execution（Agent 使用），每层都是上一层提纯。
✅ "重复出现"是知识能否变成规则的过滤器：只记不转没用，乱转污染规则集。
✅ Rule 要带 origin 溯源到知识笔记——可溯源、可审计，这正是闭环的健壮性来源。
✅ 演化是 Review 驱动的、双向的：不该用的 Rule 也应降级回笔记库。