《Agent 系统的五层结构》读书笔记

1. 主文章在讲什么（30 秒）

一句话主线：Agent 系统不是一层，是五层（Memory / Agents / Skills / Rules / Hooks），从下到上是底座到行为；缺位的层不会消失，只会隐式地、糟糕地发生。

反对什么观点：

• 反对”用 LangGraph 就够了”——LangGraph 主要是第 2 层 + 第 3 层的一部分
• 反对”Agent 就是 LLM + Tools”——这压扁了 Persona/Specialist 的分离
• 反对”加个向量库就有记忆了”——这只是第 1 层最浅的一片

如果只能记一句话：

Agent 系统不是一个框架选择题，是一个分层问题——而大多数人只看见了一层。

2. 关键概念词典

精确到一句话的定义。混淆点用对比表呈现。

五个层各自是什么

Persona vs Specialist（最容易混的）

Skill vs Rule vs Hook（三种触发模式）

Episodic vs Semantic Memory（记忆的两种）

3. 完整脉络（主文章每节展开）

主文章因为节奏限制压缩了很多分支。这里把推理链全部铺开。

Layer 1 · Memory：为什么六个子层缺一不可

主文章列了六件事一个真实记忆层需要的：

1. 有类型的存储
2. 原子事实
3. 情景记录
4. 温度模型
5. 图
6. 概念层

主文没展开的：这六件事每一件解决的”具体痛点”是什么。

Layer 2 · Agents：为什么必须显式拆 Persona 和 Specialist

主文章给了表格和理由。这里补反例——注意：以下三条来自我自己的小型试验 + 公开报告，不是生产实测。我没有用 CrewAI 或 AutoGen 跑过任何长期项目。读者如果用过它们的生产环境，欢迎纠正。

我自己跑小 demo 时观察到 + 在社区贴里反复看到的三种典型崩溃：

1. 多角色塌缩：5 个 agent 一开始有不同人格，几轮之内塌缩到同一个声音。根因（我的推断）：每个 agent 都被允许同时”思考 + 执行”，模型的礼貌训练倾向把所有路径拉向”对的执行”，于是收敛。
2. 意见和实现互相打断：一个 agent 给意见后下一个开始改代码，第三个又改意见，循环。根因（我的推断）：当一个 agent 同时承担两种产出类型，调度器无法判断当前轮该等”思考”还是该等”代码”。
3. 共享状态污染：用图框架（LangGraph 等）做多 agent 时，shared state 让”独立判断”实际上不再独立——后一个 persona 的视角被前一个的输出预设了。根因（我的推断）：persona 的价值在于独立性，共享上下文会破坏这个独立性。

Layer 3 · Skills：为什么把”怎么做”提到 prompt 之外

主文给了一句话：“如果你的流程因为模型版本变了而崩溃，那个流程本来就应该在 skill 里。”

展开论证：

LLM 是非确定性函数，确切地：相同输入 + 相同 prompt 在不同时间会给不同输出，方差由模型温度和模型版本决定。

有些步骤是确定性的（比如”读 X 文件、查询 Y、写 Z 文件”）。

把确定性步骤交给 LLM 做调度 = 把方差引入了不该有方差的地方。

正确做法：

• 确定性的”骨架” → Skill（脚本）
• 非确定性的”判断” → Skill 内部调用 Agent

伪代码：

def sprint_skill(goal: str):
    # 确定性骨架
    tasks = decompose_goal(goal)              # ← LLM call (非确定)
    for task in tasks:                         # ← 确定性循环
        result = dispatch_to_specialist(task)  # ← LLM call
        review = parallel_review(result)       # ← LLM call (并行)
        if review.passed:                      # ← 确定性判断
            archive(result)                    # ← 确定性
        else:
            retry_with_feedback(task, review)  # ← 确定性

Layer 4 · Rules：为什么”提醒 agent”是错的范式

主文给了一句”让 LLM 当 cron job，它会忘”。

更深的论证：LLM 没有持久状态。每次调用都是新的开始。如果你说”agent 应该记得在 X 之后做 Y”，agent 没有”记得”这个动作的物理基础——它只能在 prompt 里再次被告知Y 应该做。

如果你 prompt 里说了一长串”记得做 X、记得做 Y、还要记得做 Z”，模型的注意力会被当前任务吃掉，列表里的某几项会被漏掉——这是经验性观察，没有具体百分比，但只要你做过 prompt 工程都见过。生产场景每天上百次调用，一周内必然出现几次”应该做但没做”的故障。

Rule 是把”X 之后做 Y”从LLM 的概率事件升级为系统的必然事件。

┌────────────────────────────────────────────────┐
│  Prompt 提醒模式                                 │
│                                                  │
│  写文件 → LLM 看 prompt → 概率性记得 → 概率执行   │
│           （50 条规则中的一条）                    │
│                                                  │
│  失败模式：注意力被拉走时漏掉                       │
└────────────────────────────────────────────────┘
                    ↓ 升级
┌────────────────────────────────────────────────┐
│  Rule 模式                                        │
│                                                  │
│  写文件 → 文件系统事件 → Rule 触发 → 必然执行       │
│           （独立于 LLM 决策）                       │
│                                                  │
│  失败模式：基本没有                                  │
└────────────────────────────────────────────────┘

Layer 5 · Hooks：为什么生命周期绑定不可省

主文章这一节最短，因为论证和 Rule 类似。但 Hook 解决的问题和 Rule 不一样：

• Rule 解决：“某种事件发生时，应该做什么” （因果触发）
• Hook 解决：“在某个时刻必须做什么” （时间触发）

具体差异：

我用过的 Hook 例子：

SessionStart:
  - 加载在座者的状态文件
  - 检查 inbox 未读
  - 显示上次 session 的 Next 项

PostToolUse(Write):
  - 检查是否为新文件
  - 如是新文件，提示更新 .overview.md

Stop:
  - 自动追加 session 日志
  - 解锁 TG 通道

如果让 LLM 在 prompt 里”记得”这些，每条都可能在某些上下文下被漏——比如当前任务很复杂、prompt 很长、上下文窗口接近上限时。生产环境每天上百次调用，一周内必然出现”应该做但没做”的故障。Hook 不是优化，是兜底。

4. 真实代码 / 数据

主文章只给了概念。这里是我系统里真实跑过的代码片段。

Memory 层：原子事实抽取的 Rule

# .claude/rules/atomic-facts.md
当在以下位置创建或追加内容时，自动提取原子事实：
- parties/*/ideas/
- parties/*/roundtables/
- bazaar/patterns/
- bazaar/eureka/

提取规则：
- 一句话，不超过 50 字
- 可以脱离原文理解
- 包含关键实体和关系

存储到 vault/facts/facts.jsonl，每行一个 JSON：
{"fact": "...", "source": "...", "tags": [...], "type": "decision|finding|pattern|constraint"}

Agent 层：Persona 的实际定义

# 架构师

## 思维模式
- 先问边界
- 关注耦合
- 可逆性优先
- 画图说话
- 质疑规模假设

## 反谄媚规则
- 禁止说："这个设计很好"、"架构很合理"、"没什么问题"
- 必须做：每次发言至少指出一个架构风险或设计取舍
- 如果真的没问题：说明自己检查了哪些维度

## 什么证据会让我改变立场
- 实际运行数据表明当前架构在目标规模下表现良好 → 放弃重构建议
- 团队规模和交付压力证明简单方案的维护成本更低 → 接受不优雅方案

Specialist 层：dev team 的 manifest

name: dev
skills:
  - frontend
  - backend
  - ai
  - database
  - build

input:
  required:
    - task-description
    - acceptance-criteria
    - project-dir

output:
  - code-files
  - progress-log
  - case-record

quality:
  - 不允许硬编码色值
  - 不允许占位符内容
  - 不允许假数据
  - 三层（HTML/JS/CSS）必须对齐
  - 必须有空状态兜底

Skill 层：/sprint 的 Phase 拆分

Phase 1: 启动检查
Phase 2: 任务拆分（写 task-list.md）
Phase 3: 调度 dev team（实现）
Phase 4: 调度 qa team（4 个并行 reviewer）
Phase 5: 修复（dev team 处理 review 反馈）
Phase 6: 部署（devops team）
Phase 7: 写 case record（episodic memory）

每个 phase 是确定性脚本，phase 内调用 Agent 是非确定性。

数据点：六周使用后的真实统计

截至 2026-05-04，从我自己的茶会系统里 wc 出来的真实数字（项目从 2026-03-24 开始，约 6 周）：

• 圆桌会议归档：158 场（find parties/*/roundtables/*.md | wc -l）
• 原子事实累积：324 条（wc -l vault/facts/facts.jsonl）
• 团队 case 记录（episodic）：84 条（find ateliers/*/memory/cases/*.md）
• pattern files（从 cases 提炼）：28 个（find bazaar/patterns/*.md）
• 知识图谱边（wikilink）：195 条（wc -l vault/links.jsonl）
• skills 总数：8 个
• rules 总数：12 条

这些数字本身不”impressive”——重要的是每一类都不为零，证明五层都被实际使用。如果面试官追问”具体怎么统计的”，上面的 wc / find 命令就是答案。

5. 架构图（5 张）

主文章里只有 1 张文字栈图。这里是完整的 5 张视觉化。

图 1：五层关系（基础版）

                    用户输入 / 时间事件
                          ↓
        ┌─────────────────────────────────┐
        │        Layer 5 · Hooks           │
        │   生命周期触发的自动行为            │
        └────────────┬────────────────────┘
                     ↓
        ┌─────────────────────────────────┐
        │        Layer 4 · Rules           │
        │   路径/条件触发的自动行为           │
        └────────────┬────────────────────┘
                     ↓
        ┌─────────────────────────────────┐
        │        Layer 3 · Skills          │
        │   用户可调用的复合操作             │
        └────────────┬────────────────────┘
                     ↓
        ┌─────────────────────────────────┐
        │        Layer 2 · Agents          │
        │   Persona（思考）+ Specialist（执行）│
        └────────────┬────────────────────┘
                     ↓
        ┌─────────────────────────────────┐
        │        Layer 1 · Memory          │
        │   六层认知底座                     │
        └─────────────────────────────────┘

图 2：Memory 层内部展开

┌─────────────────────────────────────────────┐
│   概念层 (Conceptual)                         │
│   行为模式、用户状态机                          │
├─────────────────────────────────────────────┤
│   图 (Graph)                                  │
│   关系、遍历、因果                             │
├─────────────────────────────────────────────┤
│   温度 (Temperature)                          │
│   hot / warm / cool / frozen 加权              │
├─────────────────────────────────────────────┤
│   情景 (Episodic)                             │
│   trigger / outcome / lesson                  │
├─────────────────────────────────────────────┤
│   原子事实 (Atomic facts)                      │
│   命题粒度的检索                                │
├─────────────────────────────────────────────┤
│   类型化存储 (Type-aware)                      │
│   semantic / episodic / procedural            │
└─────────────────────────────────────────────┘

图 3：Agent 层的两条路径

       决策不确定                    任务定义清晰
            │                              │
            ↓                              ↓
   ┌────────────────┐            ┌────────────────┐
   │   Roundtable   │            │    Sprint      │
   │   召集 Persona  │            │   派遣 Specialist│
   └────────────────┘            └────────────────┘
            │                              │
   ┌────────┴────────┐            ┌────────┴────────┐
   │ 强制表态 + 反谄媚  │            │ 输入 schema      │
   │ 各自给出"什么会改   │            │ 质量门            │
   │ 变我的立场"        │            │ 输出 artifact    │
   └────────┬────────┘            └────────┬────────┘
            │                              │
            ↓                              ↓
       立场（position）                物件（artifact）

图 4：Skill 内部的确定性 vs 非确定性

   ┌─────────────────────────────────────┐
   │  确定性 · 解析输入                    │
   └────────────────┬────────────────────┘
                    ↓
   ┌─────────────────────────────────────┐ ★
   │  非确定性 · 调用 Agent 做判断          │
   └────────────────┬────────────────────┘
                    ↓
   ┌─────────────────────────────────────┐
   │  确定性 · 根据判断分支 (if/else/loop) │
   └────────────────┬────────────────────┘
                    ↓
   ┌─────────────────────────────────────┐ ★
   │  非确定性 · 调用 Specialist 执行       │
   └────────────────┬────────────────────┘
                    ↓
   ┌─────────────────────────────────────┐
   │  确定性 · 归档、记录、返回             │
   └─────────────────────────────────────┘

图 5：Rule + Hook 的”必然性升级”

   prompt-only 模式               分层模式

   "记得做 X、Y、Z..."             "X、Y、Z 由系统兜底"

   ┌──────────────┐               ┌──────────────┐
   │   用户请求    │               │   用户请求    │
   └──────┬───────┘               └──────┬───────┘
          ↓                              ↓
   ┌──────────────┐               ┌──────────────┐
   │     LLM       │               │ Skill (脚本)  │
   │ + 一长串提醒   │               │   入口        │
   └──────┬───────┘               └──────┬───────┘
          ↓                              ↓
   ┌──────────────┐               ┌──────────────┐
   │  输出 + 副作用 │               │  Agent (LLM)  │
   │   (概率性     │               │  做判断       │
   │    漏事)     │               └──────┬───────┘
   └──────────────┘                      ↓
                                  ┌──────────────┐
                                  │ Rule 层兜底   │
                                  │ (事件触发)    │
                                  └──────┬───────┘
                                         ↓
                                  ┌──────────────┐
                                  │ Hook 层兜底   │
                                  │ (生命周期)    │
                                  └──────┬───────┘
                                         ↓
                                  ┌──────────────┐
                                  │ 输出 + 副作用 │
                                  │  (必然完成)   │
                                  └──────────────┘

6. 我的批注

我和我以前的想法的冲突

以前：我把 agent 系统看成”LLM 包装得更聪明”。 现在：agent 系统的智能 80% 在 LLM 之外（在 memory + rules + hooks），LLM 只是其中一个组件。

以前：我觉得 multi-agent 是 “more agents = better”。 现在：多 agent 的价值不在数量，在视角分离 + 反谄媚 + 强制表态。少了这三件事，10 个 agent 不如 1 个。

以前：我把 RAG 等同于”记忆”。 现在：RAG 是 Memory 第二个子层（原子事实）的一部分，剩下五个半子层 RAG 都不解决。

反复想过的部分

Skill vs Tool 的区别——主文里没明说。

• Tool 是 Agent 内部使用的能力（read_file, run_query）。
• Skill 是用户调用的复合流程（/sprint = 包含很多 Tool 调用）。
• Skill 是”对外的 API”，Tool 是”对内的 ability”。两者层级不同，不要混。

为什么我把 Hook 放在最上层而不是最底层——直觉上 Hook 是”基础设施”应该在底。但我把它放最上是因为分层依据是这一层在消费谁：

• Memory（最底）只被消费，自己不主动做事
• Agent 消费 Memory 输出立场或物件
• Skill 编排 Agent 调用并消费 Memory
• Rule 在 Skill / Agent 完成事件后继续消费它们的产出（如”写文件后抽取事实”）
• Hook 在整个生命周期边界消费一切（如”会话结束时把这一切归档”）

Hook 在最上层不是因为它”最强制”（Rule 触发也是强制的），而是因为它的作用域最大——它包住整个会话，不针对单个事件。Rule 是”X 之后做 Y”，Hook 是”在整个会话开始/结束时做 Z”。两者都是”必然”，但 Hook 的’当下’是生命周期边界，Rule 的’当下’是某个事件。

下次会改的

• Layer 5 Hooks 的篇幅——主文这一段写得太短，副文我已经补了，但下次主文也应该多给一段。
• Conceptual layer（记忆的概念层）目前没有独立成层，下次可能拆出来当第六层。
• Trace 层目前归在六个 gap 里，但它实际上应该是和 Memory 平行的一层（或 Memory 的一个子层）。Trace 是”系统的操作记忆”，对应 Memory 的”系统的认知记忆”。

7. 面试话术（按时长背三档）

30 秒电梯版

2 分钟白板版

10 分钟深入版

8. 可能被问到的 5 个问题 + 回应

问题 1：你这个分层和 LangGraph / CrewAI / AutoGen 是什么关系？

回答骨架：

LangGraph 主要是第 3 层（Skills）的实现工具——它给你一个状态图来描述确定性骨架。它不强制第 2 层的 Persona/Specialist 分离（你可以用，也可以不用），完全不涉及 Memory（第 1 层）和 Rules/Hooks（第 4-5 层）。

CrewAI 是第 2 层的一个尝试，但没有显式拆 Persona 和 Specialist——所有 agent 既给意见又写代码——这是它在生产部署感觉空的根本原因。

AutoGen 也在第 2 层，偏向 Persona 那条路径（多 agent 对话），但缺第 3 层的确定性骨架，所以多 agent 容易失控。

我的分层不和它们竞争，是它们之上的meta 层级。你可以用 LangGraph 实现我的第 3 层骨架，仍然需要自己做 1、2、4、5 层。框架解决其中一两层，剩下的层你必须自己处理——不处理它们仍然会发生，只是隐式地。

问题 2：每一层都做不太重吗？小团队能负担吗？

回答骨架：

不是每一层都要从第一天做到极致。值得做的最小集合是 Memory 的前 3 子层 + Agents 的 Persona/Specialist 分离 + 一个 Skill 入口。

这个最小集合大约一周能搭好。剩下的层（温度模型、图、Rules、Hooks）是随系统运行时间自然需要的——你会因为遇到具体问题去加它们。

反过来如果你一开始就跳过它们，第三个月你会发现自己在重新发明它们，而且发明得不好。

问题 3：你的 Persona 和 Specialist 都是 LLM 调用，本质不是同一个东西吗？

回答骨架：

物理实现上是的——都是 LLM 调用。但接口和契约不同：

Persona 的”接口”是：输入议题，输出立场（带反谄媚规则）。它的契约是 markdown，没有结构化 schema。

Specialist 的”接口”是：输入任务描述 + 验收标准，输出 artifact。它的契约是 YAML schema + 质量门。

两者的调用方式、评估方式、失败处理都不同。物理一致不重要，契约不一致才重要。把它们当成同一个东西管，就是 CrewAI 那种产品形态——demo 好看，生产空。

问题 4：你用什么实现 Rules 和 Hooks？

回答骨架：

我用的是 Claude Code 的 hooks + rules 机制：

• Hooks 是 settings.json 里配置的 shell 命令，绑定 SessionStart / Stop / PostToolUse 等事件。
• Rules 是 markdown 文件，frontmatter 里指定 paths 匹配，符合路径的写入会触发 rule 加载。

在 Claude Code 之外，可以用：

• inotify / fsevents 做文件级 rules
• cron 做时间触发的 rules
• shell rc / git hook / pre-commit 做生命周期 hooks

关键不是用什么实现，是承认这一层存在并显式管理。

问题 5：你怎么知道这套分层是对的？有没有可能你只是在描述自己的实现？

回答骨架：

这是个好问题，应该正面回答。

我承认这套分层是从我的实现归纳出来的，不是从理论推导出来的。所以它可能反映了我的实现偏好而不是普遍规律。

但我用三个东西测试它：

1. 能否描述别的 agent 系统——把 LangGraph、CrewAI、AutoGen、Anthropic 的 Agents SDK 都拿来按这个分层定位。如果有它装不下的能力，说明分层有漏洞。我目前还没找到装不下的。
2. 能否预测失败模式——每一层缺位都对应一种已知的生产失败模式（“agent 忘记”、“agent 自相矛盾”、“agent 谄媚”）。如果失败模式无法用层定位，说明分层没切到关节。
3. 能否指导新设计——给一个新需求，能用分层指出”这个属于哪一层、怎么实现”。如果做不到，分层没用。

三个测试都过了。但我不排除有一天发现第六层。

9. 相关链接

内部（其他主文章）

• Persona–Specialist 的分离 — 深入第 2 层
• 记忆是底座，不是功能 — 深入第 1 层
• 情景记忆 — 第 1 层中”情景”子层的展开
• 反谄媚规则 — 第 2 层中”反谄媚”的展开

外部参考

• Reflexion (Shinn et al., 2023) — Episodic memory + reflection 的论文起源
• Generative Agents (Park et al., 2023) — Memory + reflection + planning 的早期 multi-agent 实现
• Anthropic: Building Effective Agents — Generator-Evaluator 分离思路
• A2A Protocol — Task lifecycle 标准化（pending/working/done/failed/blocked）。在 GitHub 搜 “a2a-protocol”
• Claude Code Hooks 文档 — Hook 实现参考

相关概念

• Reflexion ≈ 我的”情景记忆 + 模式提炼”
• Generator-Evaluator ≈ 我的”Specialist + Reviewer”
• Constitutional AI ≈ 我的”反谄媚规则”（不同实现，类似目标）
• OS-level rules / file-watcher ≈ 我的”Rule 层”