Agents 与系统

大多数人忽略的 Agent 系统的五层结构

人人都把"LLM 加几个工具"叫做 agent。这个词背后藏了太多东西。我把它拆成 五层，每层缺位时的症状写在旁边，结尾给一个 30 秒电梯版。

📝 读书笔记 · 完整版

30 秒电梯版

今天大多数所谓的 “agent”，是一层在假装成五层。这五层从下到上是 记忆、Agent、Skill、Rule、Hook —— 底座是基建，往上是行为。 如果你的系统只有其中一两层，剩下的事情仍然在发生，只是隐式地、糟糕地 发生。真正有意思的设计问题不是”用哪个框架”，而是”每件事属于哪一层”。

这就是全文。剩下都是我把推理过程铺开。

“Agent” 这个词承担了太多

每次有人告诉我”我做了一个 agent”，我学会了先问一句：你说的是哪一种？

  • 一个能调工具的 prompt？
  • 一个跑在 LLM 上的状态机？
  • 一个多角色圆桌？
  • 一个专家团队？
  • 一个把以上全部包进去的可自我修改的运行时？

这是五种不同的东西。大多数论文和框架挑其中一种，然后宣称它就是架构。 而真实的生产系统，几乎都需要不止一层。

下面这套分层是我用一个多智能体系统跑了大约一年之后收敛出来的。我不 是说这套分层对所有人都对——我是说，如果你的系统只有一两层，剩下 那几层仍然在发生，只是隐式地、糟糕地发生。

五层结构

┌─────────────────────────────────────────────┐
│ 5 · Hooks       生命周期触发的自动行为        │
├─────────────────────────────────────────────┤
│ 4 · Rules       路径/条件触发的自动行为       │
├─────────────────────────────────────────────┤
│ 3 · Skills      用户可调用的复合操作          │
├─────────────────────────────────────────────┤
│ 2 · Agents      Persona（思考）+ 专家（执行）│
├─────────────────────────────────────────────┤
│ 1 · Memory      所有人共享的认知底座          │
└─────────────────────────────────────────────┘

顺序很重要：下面是基建，上面是行为。你可以替换一个 Agent 而不动记忆； 你不能换记忆而不重新审视上面所有 Agent。

1 · Memory —— 底座

它是什么。 让其他每一层都不再”金鱼记忆”的共享认知层。

人们通常做的。 一个向量库 + 检索增强，叫它 “memory” 因为听上去 更高级。

它真正需要的。

  • 语义记忆 —— 事实、决策、模式
  • 情景记忆 —— 发生过什么，结果如何，为什么
  • 程序记忆 —— 这个用户喜欢被怎么对话
  • 温度模型（hot/warm/cool/frozen）—— 让旧记忆优雅衰减而不是 突然消失
  • 原子事实 从对话中抽取出来，让你能在单条命题的粒度上检索， 而不是只能在整个文档的粒度上检索

具体例子。 在我的系统里，每场圆桌会议结束都会被打上 decision、finding、pattern 或 constraint 的标签。当我问”我们 当时关于 X 是怎么决定的”时，系统会取回那条 decision 事实，加上周围的 episodic 记录解释为什么这么定。单纯的 RAG 给你文档。分层记忆给你”为什么”。

缺位时的症状。 系统像金鱼。每次会话从零开始。用户必须不停重复自己 说过的话，这是流失用户最快的方式，没有之一。

2 · Agents —— 必须拆成两个角色

这正是整个术语崩溃的地方，所以我把它显式拆成两种：

  • Persona Agent 是视角。它存在的目的是争论。架构师、产品经理、 未来学家、务实工程师。你在需要多个视角才能做决策时召集他们。他们 产出立场，不产出物件。
  • Specialist Agent 是执行者。它存在的目的是交付。前端工程师、 QA、部署工程师。你在需要把事情做完时派遣他们。他们产出物件， 不产出立场。

为什么这个分离很重要。 大多数多智能体论文把两者混为一谈，结果是 agent 既不擅长思考也不擅长执行。CrewAI 尤其如此。我找到的最干净的 分离方式：

  • Persona 是 markdown 文件，带反谄媚规则（“你必须表态；你必须说 明什么证据会让你改变立场”）
  • Specialist 是带输入输出 schema 和质量门的有类型契约

缺位时的症状。 只有 Persona，你交付出来的东西没人想要（缺执行者）。 只有 Specialist，你做得很快但方向是错的（缺批评者）。让一个 agent 同时干两件事，你得到一个困惑的中层管理者。

3 · Skills —— 用户可调用的复合操作

它是什么。 /recall、/sprint、/roundtable 这种命令——一个 确定性脚本，把一系列 agent 调用、记忆查询、副作用打包成一个用户 可见的入口。

我看到的错误。 人们把这些逻辑塞进 agent 的 prompt 里： “当用户问 X 时，先做 Y，再做 Z”。这非常脆弱，因为你让 LLM 同时负责 做什么和怎么做。把”怎么做”提到一个确定性的 skill 里——这个 skill 恰好会调 agent——你就在不损失灵活性的前提下拿回了可靠性。

快速判断。 如果你的流程因为模型版本变了而崩溃，那个流程本来就 应该在 skill 里，不应该在 prompt 里。

缺位时的症状。 你发现自己在写”先做 A，再做 B，然后做 C，但只在 D 的情况下”这样的 system prompt。趁它还小，把它挪到 skill 里。

4 · Rules —— 上下文触发的行为

它是什么。 由上下文触发的条件行为，不是由用户触发。比如： “当 ideas/ 下写入文件时，提取原子事实。""当圆桌结束时，归档结果 并更新索引。”

为什么重要。 Rules 是 agent 系统里最接近操作系统级行为的东西， 也是最被低估的一层。大多数团队的反应是”让 agent 记得做 X”——这相当于 让 LLM 当 cron job。它会忘。LLM 就是这样。

具体例子。 我的系统里，每次有 markdown 文件写到 parties/*/ roundtables/ 下，一条 rule 就会触发提取原子事实并更新索引。我不需要 记得。如果我把这件事改成”在 system prompt 里提醒 agent”，它大约会有 四分之一的次数忘掉。

缺位时的症状。 你不停发现系统本应做但没做的事。你写更严格的 system prompt。没用。挪到 rule 层。

5 · Hooks —— 生命周期绑定

它是什么。 绑定到生命周期事件的行为：会话开始、会话结束、写入 之后、部署之前。Rule 的最后保险——那些必须发生的事情，你不能 信任 agent 或 rule 去记得做的事。

具体例子。 我的会话结束 hook 会自动更新记忆并追加会话日志。无论 模型是否”记得”，它都会跑。没有它，每次长会话结束我都会想”它存了 吗？“现在我不再担心。

缺位时的症状。 你最后会给自己发各种 Slack 提醒”记得在这之后更新 文档”。这又是 cron job 陷阱，只是高了一层。

六个你不痛不会注意到的 gap

只要前两层有了，系统就能跑。问题会在它跑了足够久、开始有自己的 “性格”之后冒出来。

  1. 术语漂移。 “Agent” 在不同层意思不一样。早点定一套词。我用 persona、specialist、skill、rule、hook —— 五个词，五个 含义，互不重叠。症状：你和合作者对一个东西是什么意见不同，但 双方都没意识到。
  2. agent 定义不统一。 有的 agent 是 markdown，有的是 YAML，有的 是 TypeScript class——你就没法把它们当成一个集合来推理。症状： 你没法不 grep 就列出”所有 agent”。 每一层选一种描述格式，坚持。
  3. 没有 runtime 概念。 人们把”agent 定义”和”agent 执行”混为一谈。 agent 怎么被调度的？状态怎么持久化？trace 在哪？症状：出问题 时你不知道往哪看。 如果你的答案是”我就是把它粘进 Claude”，那 你没有 runtime，你只有一个 prompt。
  4. 没有 DAG。 顺序链条好用，直到不好用。当你开始需要并行 reviewer、 条件分支、重试语义时，你就在重新发明状态图。症状：你有一个 200 行的 shell 脚本在把 agent 粘起来。 早点用状态图。
  5. 没有 trace。 Episodic memory 不等于 trace。记忆告诉你发生了 什么。trace 告诉你什么调用了什么，用了多少 token，按什么顺序。 症状：你回答不了”为什么那个工具被调用了”。 你两个都需要。把它 们混在一起，第一次出现 4 层深的 bug 时会让你损失一周。
  6. 跨产品没有复用。 每个产品都重新实现自己的 agent loop、自己的 重试逻辑、自己的 tool-call 解析器。症状：你第三次写同一个 agent loop。 第二次的时候就该建框架。第三次，你已经晚了。

为什么这套分层不停消失

框架天然有动机把图压扁。LangGraph 是 agent。 CrewAI 是 agent。 AutoGen 是 agent。 每一个其实都只是其中一两层，被当作整个 stack 卖。

如果你只懂一层，你就会把所有事情都塞进那一层。记忆变成一个加了 prompt 的向量库。Persona 变成 tool。Rule 变成 prompt 里的 if 语句。 Hook 变成”记得调这个”。系统能跑，直到不能跑，那时的失败模式是 agent 忘了——这是无法修复的，因为你在让 LLM 做 LLM 做不到的事。

这五层不是架构占星术。它们是对大多数 agent 框架已经压扁的概念的 恢复。你用什么框架实现都可以。你只需要知道它们在那里。

我会怎么在面试里讲这套

如果有人让我”设计一个多智能体系统”，我会先画出五层栈。然后我走一遍 每个需求属于哪一层。答案几乎不会是”一层”。

完整版大概五分钟：

  1. 画出栈（30 秒）。
  2. 解释记忆：不是 RAG，而是带温度模型的 episodic + semantic + procedural （60 秒）。
  3. 解释 persona/specialist 分离，每个给一个具体例子（60 秒）。
  4. 解释 skill 是非确定性 agent 周围的确定性脚手架（60 秒）。
  5. 解释 rule 和 hook 不是可选的——它们是你停止让 LLM 当 cron job 的 方式（60 秒）。

最后用六个 gap 收尾，作为诊断：“如果我加入一个已经有 agent 系统的 团队，我会去看这些。“这表明你不只能建一个，还能评估一个。

大多数候选人只用过框架。门槛不高。