云喵盒子

AI产品实际测评

Tue, 28 Apr 2026 00:00:00 +0000

AI产品领域

命令行窗口(CLI)，面向对象为程序员，通常用于开发代码项目。因为不存在界面需求，因此增改功能变得非常简单。

早期产品： Cursor，仅依赖于VS CODE插件的Roo code。

首先是该领域的御三家的作品：Claude Code， Code X， Gemini CLI，

可视化界面 Claude Cowork

NoteBook LM以及AI Studio

Agent必学：agent架构的演变历程

Fri, 10 Apr 2026 00:00:00 +0000

Agent 系统架构演变完整调研

一、总览：三代范式跃迁

Agent 系统架构的演变可归纳为三条并行的技术主线，历经约 70 年的迭代。按照核心驱动力，可划分为符号主义时代 → 强化学习时代 → LLM 原生时代三大范式。当前正处于第三次范式的高潮期，且呈现出多范式融合的趋势。

二、第一阶段：符号主义 / 经典 Agent 架构（1950s–1990s）

Agent理论的发展比深度学习还要早。在ChatGPT这种能够真正回答人类问题的AI出现之前，就已经开始思考“一个完全由人工定义的智能会是什么样子”这一问题。这点来讲，哲学理论走得要远远超前。

2.1 规则系统（Rule-Based Systems）

最早的 AI Agent 以 专家系统（Expert Systems） 为代表。架构核心是：

知识库（Knowledge Base） + 推理引擎（Inference Engine）

知识以 if-then 规则 显式编码
推理引擎执行前向/后向链式推理
典型代表：MYCIN（1976，医疗诊断）、DENDRAL（1965，化学分析）

局限：规则数量爆炸、无法处理模糊/未知场景、完全不具备学习能力。

我甚至不认为规则系统该作为Agent理论的一部分，它用众多规则堆砌出决策，似乎跟智能毫无关系。

但是目前的智能体有个说法：与其要求ai按照严格语法编写代码，不如让它编写完后执行一遍检查。规则系统适合ai与严谨的外部环境交互时使用。

2.2 BDI 架构（Belief-Desire-Intention）

这个理论是来自哲学界的产物，研究的是人类的行为。

早期的哲学中认为欲望驱动理性。Hume 的核心论证极其著名，就一句话：

| “Reason is, and ought only to be the slave of the passions.” |（理性是，也只应当是激情的奴隶。——《人性论》2.3.3）

这一观点不依赖任何实验，仅仅通过内省和推理便收获了人们的认可。

转换到Agent理论中，可以想象，如果让当时的人们设计一个智能体，他们设想的架构会是：给agent设定一个目标(Desire)，agent用它的知识(Belief，指ai相信的世界知识)完成目标。

即使放到今天，这个想法也不能说是错，但它很粗糙，表达起来很主观，比如Desire跟Belief是什么，都没有明确的定义。只是一种感觉上的描述。

Dennett(1971)将它更具体一些，让这个理论更像是科学里的描述了：当我们说一个人有 belief 和 desire，不是说我们真的在他的大脑里找到了这些实体——而是说，用这组概念来预测他的行为，是最有效的策略。

当理解物理系统时，我们依靠精确但复杂的物理规律去了解；当理解人造物时，我们可以从它的设计目的去了解；当想要了解人类、动物、AI时，我们用belief和desire理论去了解。

当我们想要科学地研究agent(或人)时，我们

假设agent是理性的
根据它的处境和目的，赋予它应有的belief和desire
预测理性系统会作出的最符合这些belief和desire的事

从此时开始，Belief-Desire理论听上去很像是严谨的科学了。它像是在强调，心理学其实是一种概率学，一种工具；也可以反过来理解，借助生成最高概率的做法，就能模拟出一个理性系统。

Michael Bratman（1987）的哲学理论，则认为Belief-Desire理论在解释瞬时行动的时候是合理的，但对于跨时间的计划行为，它的解释力不足。

想要的未必真的就去做。例如用户可能希望去巴黎旅行，但这并不意味着会立刻触发“订机票、办签证、订住宿”这一系列流程。Desire List不会立刻触发行动。
想要的东西之间存在矛盾。例如用户想吃蛋糕，以及希望减肥。如果Desire List以同等的地位进入执行阶段，便发生了冲突。但它们在Desire阶段是完全能够共存的。这也说明Desire到执行这一步之间，还存在一些步骤。

他引入了Intention(意图)，即决定要去做的事。Desire经过“作出承诺要做这件事”这一步骤后，才进入到执行阶段。

这一理念将 Agent 建模为三种心理状态：

组件	含义	类比
Belief（信念）	对环境状态的认知	数据库/知识图谱
Desire（愿望）	目标状态/偏好	目标队列
Intention（意图）	已承诺执行的计划	执行栈

仅仅有Desire不代表真正去做，Intention，也就是下决心真的要去做的时候，才真正开始做。执行阶段不属于心理状态，因此不在表中。

Intention这一阶段的引入提供了三种作用：

用Intention作为推理与执行的起点，而不是以Desire作为起点。同时想要减肥与吃蛋糕，欲望是同时存在的，但下决心，到了真正要指导行动的时候，只会留下一个Intention。
Intention可以实现跨时间协调，也就是对人的“惯性心理”的刻画。人并不会时时刻刻对所有Desire进行评估并重新规划。而是延续之前的“决定”，完成之前心中的承诺。例如在已经决定减肥后，默认的Intention依然是减肥，而不是再次比较一番所有Desire，完全独立的重新构建新的Intention。它不是不可改变，但它会抵抗改变，人们借此得以执行跨越时间的计划。
在公共关系中同样需要“决定”这一步骤。“我想帮你”与“我会帮你”是存在不同的，在多agent系统中，就可能有必要区分清楚。

代表性框架：AgentSpeak(L)、Jason、PRS（Procedural Reasoning System）。BDI 至今仍在 MAS（Multi-Agent Systems）研究中有影响力——它将"计划选择"和"目标承诺"显式分离，是 Agent 架构中"认知层"概念的原型。

这些理论都是基于自省、思维实验构建的。跟工科认知中的科学相差甚远。这种理论通常需要依赖反证法：当缺失这一概念时，理论会怎样的不完善。从而使新理论得到认可。

2.3 SOAR 认知架构（1987）

SOAR（State, Operator And Result ）是Allen Newell、John Laird 等人提出的通用认知架构，目标是实现通用人工智能。

这是一个宏大的命题：既然人类能在所有认知领域表现出智能，那么一定存在一套固定的、通用的底层机制——这个机制就是认知架构（cognitive architecture）。SOAR 是这一机制的一种实现。

SOAR 不是"一个 AI 程序"，而是一套关于智能是什么的理论——它说：任何表现出通用智能的系统，都得有某种固定的结构，这个结构包含什么记忆系统、什么决策流程、什么学习机制。

核心机制：

短期记忆（STM） ↔ 决策周期 ↔ 长期记忆（生产规则 + 语义 + 情节）
 ↕
 意向栈（Goal Stack）

决策周期（Decision Cycle）：感知 → 匹配规则 → 冲突消解 → 执行 → 学习（Chunking）
通用子目标（Universal Subgoaling）：遇到困境自动创建子目标
学习机制 Chunking：将解决方案编译为新的规则

SOAR 在 AI Agent 架构史上有着里程碑地位——它首次完整定义了 感知 - 推理 - 执行 - 学习的闭环架构，影响了后续几乎所有 Agent 架构的设计。

要我说，ReAct循环完全跟这个一样，所以算不上什么新东西。只不过SOAR提出的时间太久远了，人们又只关注近期的知识。这恐怕是人类在知识继承里的常态。

| 任何需要“在环境中持续行动的智能系统”，都需要有类似这样的闭环，这不能说是发明，而是一种工程约束。

顺便一提，SOAR可以称得上是早期的“终身学习系统”了，跟现在agent常见的宣传一样，都号称越用越聪明。

外部输入
思考
1. 根据外部输入匹配规则
2. 消解冲突规则，选择其中的规则
执行
1. 成功则输出
2. 不成功则拆解任务为子目标
  1. 重复循环直到问题解决
  2. Chunking 将解决问题的方案编译为规则，下次遇到同样问题能够快速处理。

这其中的Chunking能力就跟Hermes Agent完成任务后编写SKILL的做法一样，并因此号称终身学习。

SOAR的认知架构（对应Agent记忆系统）同样是类似如今的多层架构，一共有9个记忆系统

工作记忆。这是SOAR管理全局的记忆，所有输入，中间推理，决策状态都在这里，并用栈结构分层表示目标与状态，子目标与子状态。相当于主Agent。

SOAR架构没有死，甚至还活跃着。

2.4 ACT-R 架构

Anderson 等人开发的认知架构，专注于模拟人类认知过程。相比 SOAR 的全符号主义，ACT-R 引入了亚符号层（subsymbolic），包括：

扩散激活（Spreading Activation）：记忆检索的基础
效用学习（Utility Learning）：规则选择的最优化

ACT-R 是将"计算精度"与"认知真实性"结合的典范，后来被部分 LLM Agent 的记忆设计参考。

三、第二阶段：强化学习 Agent 架构（1990s–2010s）

3.1 经典 RL Agent（Q-Learning, SARSA）

RL 将 Agent 定义为 MDP（马尔可夫决策过程） 中的决策者：

状态(State) → 动作(Action) → 奖励(Reward) → 新状态(State')

架构特征：

Value-based：Q-Learning，维护 Q(s,a) 表
Policy-based：REINFORCE，直接学习策略 π(a|s)
局限：状态空间受限，难以应对高维感知

3.2 深度 RL Agent（DQN, 2013）

DeepMind 的 DQN（Deep Q-Network） 引发 RL 革命，关键架构创新：

CNN（视觉编码器）→ Q(s,a) Value Network → ε-greedy 策略
 ↕
 经验回放缓冲区（Experience Replay）
 ↕
 Target Network（稳定目标分布）

经验回放（Experience Replay）：打破时序相关性
两阶段目标网络（Double DQN）：减少价值过估计

3.3 Actor-Critic 架构（PPO, SAC）

现代 RL Agent 的主流架构。分离 策略网络（Actor） 与 价值评估网络（Critic）：

┌─────────────┐ ┌──────────────┐
│ Actor │ │ Critic │
│ π(a|s) │←───│ V(s) / Q(s,a)│
│ 生成动作 │ │ 评估动作质量 │
└──────┬───────┘ └──────┬────────┘
 │ │
 └─────────┬─────────┘
 ▼
 环境交互 → 奖励信号

PPO（Proximal Policy Optimization, 2017） 使用 Clip 机制限制策略更新范围，成为 RL Agent 的事实标准。SAC（Soft Actor-Critic） 通过最大熵强化学习增强了探索能力。

RL Agent 的架构范式（感知 → 决策 → 执行 → 学习循环）为后来的 LLM Agent 提供了循环结构的设计母板。

3.4 多智能体 RL（MADDPG, 2017）

Lowe 等人提出 MADDPG（Multi-Agent DDPG），架构核心：每个 Agent 的 Critic 可以观察所有 Agent 的动作（CTDE: Centralized Training, Decentralized Execution）。

Agent 1: Actor(s₁) → a₁ │ Critic(s₁, s₂, a₁, a₂) → Q₁
Agent 2: Actor(s₂) → a₂ │ Critic(s₂, s₁, a₂, a₁) → Q₂

这在多 Agent 协作/竞争的架构设计上提供了基础范式，后来被 LLM Agent 框架（AutoGen、CrewAI）在概念层借鉴。

四、Pre-LLM 混合架构与过渡期

4.1 RLL（Reinforcement Learning with Language）

在 LLM 大爆发前，研究者试图将自然语言引入 Agent 架构。典型代表：

Embodied Agents (ALFRED, 2020)：通过指令->子任务分解->RL策略
Interactive Fiction Agents (Jericho, 2019)：自然语言文本界面 + RL

4.2 基于 LSTM/Transformer 的命令理解 Agent

WebGPT（OpenAI, 2021）：用 GPT-3 + 模仿学习操作浏览器，首次展示了"语言模型 + 工具 + 搜索"的 Agent 雏形
架构：Behavior Cloning on human demonstrations + RL fine-tuning

这些系统虽然性能有限，但建立了语言模型作为 Agent 控制器的架构原型，是通往 LLM Agent 的关键桥梁。

五、第三阶段：LLM Agent 革命（2023–至今）

5.1 分水岭事件：GPT-4 Function Calling（2023-06）

2023年6月，OpenAI 发布 GPT-4 的 function calling 能力。这是 Agent 架构史上的分水岭。

架构变革：

之前: User → LLM → Text Output → 手动解析 → 调用API
之后: User → LLM → JSON tool_call → 自动执行 → 结果反馈 → LLM

Function Calling 使得 LLM 可以：

结构化输出函数参数（不再是自由文本）
多轮工具调用（chain of tool calls）
自动反馈循环（工具结果作为上下文回注）

这标志着 LLM-based Agent 时代正式开启。

5.2 ReAct 范式的崛起（Yao et al., 2023）

ReAct（Reasoning + Acting）是 LLM Agent 最核心的架构范式，由 Yao 等人在 2023 年提出。

Thought: 我需要查找当前的天气数据
Action: search_weather(location="Beijing")
Observation: {"temp": 28, "humidity": 65%}
Thought: 气温 28°C，湿度 65%，建议穿短袖
Action: complete

架构循环：

┌─────────────────────────────────────┐
│ LLM (核心推理引擎) │
│ │
│ 思考(Thought) → 动作(Action) │
│ ↑ ↓ │
│ 观察(Observation) ← 工具执行结果 │
│ ↑ │
│ Scratchpad (上下文缓冲区) │
└─────────────────────────────────────┘

ReAct 的关键设计要素：

Scratchpad：作为 Agent 的"工作记忆"，存储推理链
Thought-Action-Observation 三元组：可解释的决策轨迹
动态停止条件：Agent 自行判断任务是否完成

5.3 第一代自主 Agent 框架（2023 年中）

AutoGPT（2023-03） 和 BabyAGI（2023-04） 引爆了 Agent 概念。

AutoGPT 架构：

┌─────────────────────────────────────────┐
│ Goal → 任务队列(Task Queue) │
│ ↓ │
│ LLM 推理 → 执行动作 → 存储结果 │
│ ↓ │
│ 优先队列(优先级排序 → 再次执行) │
│ ↓ │
│ 向量数据库(长期记忆检索) │
└─────────────────────────────────────────┘

BabyAGI 架构创新：引入了任务分解（task decomposition） 与记忆优先级（memory prioritization），但其无限制的自我循环也引发了"Agent 失控"的讨论。

5.4 主流框架生态成型（2023 年底–2024 年）

框架	发布时间	架构特色	核心理念
LangChain	2023-01	链式组合（Chain）+ 工具抽象	可组合的 LLM 应用框架
LangGraph	2023-中	有向图状态机 + 循环节点	细粒度控制 Agent 流程
AutoGen	2023-10	多 Agent 对话 + 角色分离	Agent 即消息参与者
CrewAI	2023-12	角色 + 任务 + 团队（Crew）	模拟人类团队协作
Semantic Kernel	2023-05	编排层 + 插件 + 记忆	企业级 Agent 架构
LlamaIndex	2023-01	数据索引（Index）+ RAG	Agent 检索增强架构

LangChain → LangGraph 的架构进化

LangChain 最初使用 Sequential Chain（线性管道），架构为：

Input → PromptTemplate → LLM → OutputParser → NextChain → ...

问题：线性链条无法处理条件分支、循环、多工具调用。

LangGraph 的革命性升级：

StateGraph:
 Node(agent) → Edge(router) → Node(tools)
 ↑ │
 └─────────────────────────────┘
 (循环，直到 agent 决定停止)

LangGraph 引入了：

Stateful Graph：节点间通过共享状态通信
Conditional Edges：根据条件动态路由
Persistence：内置的持久化/中断/恢复机制

AutoGen 的对话式架构

Microsoft AutoGen 的架构核心是 Agent-Centric 的消息驱动模型：

┌─────────────────────────────────────────────┐
│ UserProxyAgent AssistantAgent │
│ (人类代理) (LLM代理) │
│ │ │ │
│ └─────── 对话循环 ──────┘ │
│ │ │
│ Tool/Function │
│ (代码/API执行) │
└─────────────────────────────────────────────┘

关键创新：多 Agent 通过自然语言对话完成协作，而非硬编码的流程控制。

CrewAI 的角色化架构

CrewAI 引入了组织隐喻（Organizational Metaphor）：

Crew (团队)
├── Agent: 研究员（角色: 研究者, 目标: 收集信息, 工具: web_search）
├── Agent: 分析师（角色: 分析师, 目标: 分析数据, 工具: code_exec)
├── Task: 收集数据（分配给 研究员 Agent）
└── Task: 生成报告（分配给 分析师 Agent, 依赖 Task1）

设计理念：将 Agent 组织视为虚拟公司，通过角色、职责、任务的显式分配来解耦复杂系统。

5.5 Prompt Agent → 工具 Agent 的架构转变

2024 年的关键趋势是从提示代理（Prompt Agent） 向工具代理（Tool Agent） 的演变：

Prompt Agent:
 单一 LLM 调用 → 文本输出
 无外部反馈循环
 依赖模型能力

Tool Agent:
 LLM(工具描述 + 上下文) → tool_call → 执行结果 → LLM(结果)
 结构化工具接口
 持续交互闭环

Function Calling / Tool Use 成为 Agent 架构的标准层：

Agent
├── Orchestrator（编排器：决定调用哪个工具、何时停止）
├── Tool Registry（工具注册表：名称+描述+参数Schema）
│ ├── search | code | calculator | file_ops | ...
│ └── MCP Tool（通过 Model Context Protocol 发现）
├── Memory（记忆系统）
│ ├── Working Memory（Scratchpad）
│ ├── Short-term（对话历史）
│ └── Long-term（向量检索 + 持久化）
└── Safety Layer（安全层：输入过滤 + 输出审核）

六、多 Agent 系统架构成熟期（2024–2025）

6.1 主流多 Agent 架构模式

模式 1：中心化编排器（Orchestrator）

┌──────────────┐
│ Orchestrator │ ← 单一决策点
├──────┬───────┤
│ │ │
 ↓ ↓ ↓
Agent1 Agent2 Agent3

代表：LangGraph（Supervisor Pattern）
优点：全局可控、确定性高
局限：单点瓶颈、编排器可能成为性能瓶颈

模式 2：对话式协作（Conversational）

Agent1 ←→ Agent2 ←→ Agent3
 ↕ ↕ ↕
 Tool Tool Tool

代表：AutoGen
优点：自然协作、灵活性高
局限：对话开销、可能陷入循环

模式 3：分层管理（Hierarchical）

Manager Agent
├── Researcher Agent
│ ├── Web Searcher
│ └── Paper Analyzer
├── Writer Agent
└── Reviewer Agent

代表：Anthropic Multi-Agent Research System
优点：任务分解自然、各层职责清晰
局限：层级间通信延迟

模式 4：群体智能（Swarm）

 Agent1 → Agent2 → Agent3
 ↑ Agent4 → Agent5 ↕
 Agent6 ← Agent7 ← Agent8

代表：OpenAI Swarm、MADDPG 精神延续
优点：容错、可扩展
局限：协调复杂、调试困难

6.2 关键研究成果

研究	年份	架构贡献
ReAct (Yao et al.)	2023	Thought-Action-Observation 循环
Reflexion (Shinn et al.)	2023	语言反馈 + 自我反思 + 经验回放
Tree-of-Thoughts (Yao et al.)	2023	多路径探索 + BFS/DFS
Self-Refine (Madaan et al.)	2023	Agent 自我生成 → 自我反馈 → 自我改进
ReWOO (Xu et al.)	2023	规划与执行分离（Plan-then-Execute）
AgentTuning (Zeng et al.)	2023	从 Agent 轨迹中微调 LLM
GPT-4 Function Calling	2023-06	原生工具调用接口
MCP (Model Context Protocol)	2024-11	标准化工具/数据协议
A2A (Agent-to-Agent)	2025-04	Agent 间通信协议
Deep Research (OpenAI)	2025-02	多层搜索 + 规划 + 报告合成
Anthropic MCP	2024-11	Function Calling 的协议级标准化

6.3 Reflexion 架构：Agent 的自我改进

Reflexion（Shinn et al., 2023）在 ReAct 基础上引入评估-反思闭环：

┌─────────────────────────────────────┐
│ Actor (ReAct Loop) │
│ Thought → Action → Observation │
└─────────────┬───────────────────────┘
 │ 完成/失败
 ▼
┌─────────────────────────────────────┐
│ Evaluator │
│ 评估任务完成质量 → 生成反馈 │
└─────────────┬───────────────────────┘
 │ 结构化反馈
 ▼
┌─────────────────────────────────────┐
│ Memory │
│ 经验回放缓冲区（失败的决策 + 原因） │
└─────────────┬───────────────────────┘
 │ 提取经验
 ▼
 回到 Actor 重新执行

核心创新：Agent 通过自然语言反思自己的失败并将经验存入记忆，而非通过权重更新。

七、协议标准化时代（2024 年底–2026）

7.1 MCP（Model Context Protocol）

Anthropic 于 2024 年 11 月推出的开放协议，定位在 Agent 与工具/数据源之间的标准化接口。2025 年 12 月，Anthropic 将其捐赠给 Linux 基金会下的 Agentic AI Foundation。

┌─────────┐ MCP 协议 ┌──────────┐
│ Agent │ ◄──────────► │ MCP Server │
│ (Host) │ │ │
│ │ │ ├── Database│
│ │ │ ├── Files │
│ │ │ ├── API │
│ │ │ └── Search │
└─────────┘ └──────────┘

架构意义：MCP 将工具接口从"厂商锁定"推向标准化，使任何 MCP-compatible 的 Agent 都能自动发现和调用工具。

7.2 A2A（Agent-to-Agent Protocol）

Google 于 2025 年 4 月发布，定位在 Agent 与 Agent 之间的通信协议。2025 年 6 月贡献给 Linux 基金会。

 ┌──────────────┐
 │ Orchestrator │
 │ Agent │
 └──────┬───────┘
 A2A ┌───────┴────────┐
 ┌──────▼────┐ ┌──────▼────┐
 │ Agent A │ │ Agent B │
 │ (MCP工具) │ │ (MCP工具) │
 └───────────┘ └───────────┘

MCP vs A2A 的关系：

协议	解决的问题	方向
MCP	Agent 如何访问工具和数据	上下层连接
A2A	Agent 之间如何协作通信	平行连接

7.3 协议栈全景（2025–2026）

Agent-to-Agent (A2A) ← Agent 间协作层
 ↕
 Agent 核心（推理+规划+执行）
 ↕
Model Context Protocol (MCP) ← 工具/数据接入层
 ↕
 数据库 | 文件 | API | 搜索 | 代码

八、2025–2026 架构前沿

8.1 深度推理 Agent（Deep Research）

OpenAI 的 Deep Research 和类似的深度研究 Agent 架构：

User Query → [Search Loop]
 ├── 规划搜索策略
 ├── 并行多源搜索（Web + Academic + Code）
 ├── 阅读 + 提取关键信息
 ├── 交叉验证冲突信息
 └── 是否足够？→ 是 → 合成报告
 ↓
 报告生成（带引用）

核心架构特征：

多层搜索规划：BFS 式探索
信息到报告的直接转换：减少中间损耗
引用锚定（Citation Anchoring）：免幻觉的可溯源设计

8.2 Agentic RAG（检索增强生成 + Agent 决策）

Agentic RAG 将传统 RAG 的"一阶段检索+生成"升级为多策略决策：

Query
 ↓
Router（路由决策）
├──→ Vector Search（语义检索）
├──→ Web Search（实时网络搜索）
├──→ SQL Query（结构化数据）
└──→ Agent Loop（复杂查询：分解→检索→合成）

8.3 Hermes Agent 自身的架构（Mirror of the Trend）

你正在对话的 Hermes Agent 本身也体现了当前架构设计的最新趋势：

工具中心：所有工具（web_search, browser, terminal, execute_code 等）通过工具注册表暴露
ReAct Loop：Thought（推理）→ Action（工具调用）→ Observation（结果回注）的自然循环
Skills = 过程记忆：将可复用的工作流编码为 skill（类似 SOAR 的 Chunking）
Memory 系统：持久记忆（跨 session）+ 会话搜索（短时上下文检索）
MCP 原生支持：通过 Native MCP 技能连接标准协议工具
Subagent 架构：delegate_task 实现多 Agent 并行协作（类似 AutoGen 模式）
Cron Job：事件驱动的自主执行

九、架构演变总览图

1950s──┐
 ├── 专家系统（规则引擎）
1960s──┘
 │
1980s ├── BDI（信念-愿望-意图）
 ├── SOAR（通用认知架构 / 决策周期 + Chunking）
 └── ACT-R（认知建模 + 亚符号层）
 │
1990s ├── MDP + Q-Learning（经典RL）
 ├── 多Agent系统理论
2000s──┘
 │
2013 ├── DQN（深度RL / 经验回放）
2016 ├── PPO（Actor-Critic / 策略优化）
2017───┴── MADDPG（CTDE / 多Agent协作）
 │
2021 ├── WebGPT（语言模型 + 浏览器）
2022───┴── ChatGPT + 第三方插件
 │
2023-03├── AutoGPT / BabyAGI（任务分解 + 循环）
2023-06├── GPT-4 Function Calling（工具调用原生化）
2023-10├── ReAct（推理-行动闭环）
2023-12├── LangChain / LangGraph（链→图 / 状态机）
2024 ├── AutoGen / CrewAI（多Agent编排）
 ├── Reflexion（自我反思 + 经验回放）
2024-11 ├── MCP（工具/数据协议标准化）
2025-04 ├── A2A（Agent间通信协议）
2025-06 ├── Deep Research（深度推理检索）
2025-12 ├── MCP捐赠至Agentic AI Foundation
2026 └── 多范式融合：符号规则 + LLM 推理 + RL 反馈

十、核心洞察与结论

从封闭到开放：Agent 架构从封闭的符号规则系统，演化为通过协议（MCP/A2A）开放互联的生态系统。
从单一体到协作体：单一 LLM Agent → 多 Agent 编排（Orchestration）→ Agent 联邦（Federation）。
循环结构是永恒模式：从 SOAR 的决策周期到 ReAct 的 Thought-Action-Observation，循环感知-推理-执行架构是所有 Agent 系统的基础。
记忆系统分层化：Working Memory（Scratchpad）→ Short-term（对话历史）→ Long-term（向量数据库）的三层架构成为事实标准。
编排粒度的细化：从 Sequential Chain → State Graph → Multi-Agent Conversation → Role-based Team，编排抽象层次不断上升。
“大脑"与"四肢"分离：LLM 作为推理核心 → 工具作为执行层 → 协议作为连接层，三者走向解耦与标准化。
评估-反馈-学习闭环：Reflexion、RLHF、SFT from Agent Trajectory… Agent 正在从"一次执行"走向"自我进化”。
当前的瓶颈：Agent 可靠性（一致性幻觉）、成本控制（token 堆积）、安全边界（工具调用权限）、调试/可观测性——这些是 2025–2026 年的核心工程挑战。

写作方案规划：围绕Agent技术的梳理文章

Fri, 10 Apr 2026 00:00:00 +0000

以Agent开发岗位所需的知识为参考，编写博客

Agent系统架构的演进历程

多智能体协作

记忆与上下文管理

知识库/工具集/MCP/Skill

Agent框架：OpenCode, ClaudeCode, LangGraph

研发效能 / DevOps 平台经验优先（CICD / WebIDE / 工程效能度量）

意图识别

Go / Python + LangChain / LangGraph
Coze / Dify 等低代码平台经验
RAG 深入理解 + 向量数据库实践经验
Prompt Engineering（问题拆解 / 规划 / 执行）
多 Agent 协作架构 + 任务调度逻辑

SOAR 的记忆蓝图：30 年前的架构，今天的营销话术

Fri, 01 May 2026 00:00:00 +0000

写上一篇 Agent 架构演变史的时候，有一个时刻让我愣住。

写到 SOAR（1987）的 Chunking 机制时，我意识到它和今天 Hermes Agent 的 SKILL 系统几乎做的是同一件事：把成功的经验编译成可复用的规则，下次直接调用。 我当时的原话是——

要我说，ReAct 循环完全跟这个一样，所以算不上什么新东西。

这不是故作惊人之语。顺着这个思路往下挖，我发现 SOAR 的整个记忆架构在今天看都不过时。不仅不过时，它还比大部分号称有"记忆系统"的产品更完整。

但这引出一个让我不太舒服的问题：

一个 1987 年的架构就已经想清楚的事，为什么 2026 年还在被当作创新来营销？

或者说更尖锐一点：记忆系统，真的是 Agent 性能的关键瓶颈吗？

一、SOAR 的记忆蓝图

SOAR（State, Operator And Result）由 Allen Newell、John Laird 等人在 1987 年提出。它的目标是实现通用人工智能——用的还是符号主义那套方法。

SOAR 不是"一个 AI 程序"，它是一套关于智能的理论：任何表现出通用智能的系统，都得有某种固定的结构，包含什么记忆系统、什么决策流程、什么学习机制。

在这个框架里，记忆不是附加功能，是核心架构。SOAR 一共定义了 9 个记忆系统，分三层：

工作记忆（Working Memory）

这是 SOAR 的全局工作空间。所有感知输入、中间推理状态、决策状态都在这里，用栈结构分层表示目标与子目标。相当于今天 Agent 的 Scratchpad + 对话历史。

长期记忆（Long-term Memory）

长期记忆又细分为三个独立系统：

记忆类型	内容	今天的对应物
程序性记忆（Production Rules）	if-then 规则，决定怎么做	LLM 的权重 + 推理策略
语义记忆（Semantic Memory）	事实性知识，知道是什么	RAG 知识库 / 向量数据库
情节记忆（Episodic Memory）	过去的经验，经历过什么	对话历史 / 记忆流

意向记忆（Intention Memory）

SOAR 还有一个 Goal Stack（目标栈），管理当前正在追求的子目标及其优先级。这对应今天 Agent 的任务队列和规划器。

决策周期

SOAR 的核心循环是：

感知 → 匹配规则 → 冲突消解 → 执行 → 学习（Chunking）

遇到无法解决的问题时，自动创建子目标去解决。解决后，Chunking 机制把整个推导过程编译成一条新的生产规则。

每一次循环可以改变行为。每一次 Chunking 可以永久提升效率。

二、今天的"记忆营销"

现在回过头看 2023-2026 年的 Agent 产品，你会发现一个有趣的现象：几乎每个产品都在卖"记忆系统"。

产品/框架	记忆卖点	实际实现
MemGPT/Letta	操作系统级分层记忆	存档存储 → 向量检索 → 注入上下文
Hermes Agent	终身学习、三层记忆	MEMORY.md(2200字符) + USER.md + FTS5 全文搜索
ChatGPT Memory	跨会话记住用户偏好	LLM 提取事实 → 结构化摘要 → 下次注入
Claude 项目记忆	记住项目上下文	单个 LLM 生成的项目摘要
Zep	自动实体提取和记忆管理	实体图谱 + 时间衰减 + 重要性评分
Kimi	手动保存到 AGENTS.md	纯文本文件读写

把这张表和 SOAR 的 9 层记忆系统放在一起看，你会发现一件尴尬的事：

今天的"记忆系统"并没有比 SOAR 更丰富，反而更简陋。

SOAR 有程序性记忆（改变了决策逻辑）、语义记忆（知识库）、情节记忆（经验）、目标栈（任务管理）。今天的产品基本上只实现了"存文本→检索→注入上下文"这一个模式，管它叫"记忆"。

更关键的区别在后面。

三、检索式记忆的理论天花板

抛开营销回到技术层面：今天的"记忆系统"本质上都是检索式记忆——你存一段文本，下次用向量搜索找到它，再塞回上下文。

这个范式有一个数学层面无法规避的问题。

3.1 高维诅咒

你能想到的几乎所有嵌入模型都在用 768d 或 1024d 的向量。

Aggarwal 等人在 2001 年就证明了一个令人不安的事实：当维度超过 ~25 时，高维空间中所有点的距离趋向均匀。最近邻和最远邻的距离比值趋近于 1。

这意味着：你的向量索引本质上是一个随机排序器， 只是被嵌入模型的"语义压缩"勉强维持着秩序。两个文档余弦相似度 0.85 可能语义无关，另外两个 0.80 可能是同义改写。你的 ANN 索引分辨不了这个区别。

你提高召回率=扩大检索范围，必然引入噪声——因为决策边界一定包含边界线不相关的文档。

3.2 Lost in the Middle

Liu 等人（2023）发现 LLM 在长上下文上的表现呈 U 型曲线：相关信息在开头和结尾时性能最好，在中间时下降 20-40%。

这意味着什么？你为了提高召回率多检索几个文档进去，这些文档恰好被塞进了模型最不会利用的位置。

你在主动伤害自己。

更糟糕的是，这个 U 型是因果注意力（Causal Attention）的结构性属性。长上下文模型（128K、200K、甚至 1M）都没有消除它。它是一个 architectural 问题，不是一个参数能调好的。

3.3 LLM 对噪声的极度敏感

Shi 等人（2023）在 GSM-IC 基准上发现：一个无关句子就让 GPT-3 的准确率从 80% 掉到 55-65%。 一个句子。

Cuconasu 等人（2024）进一步揭示：主题相关但实际无关的文档比明显无关的文档更有害——因为 LLM 分不清"看起来相关但没用"和"真正有用"。

把这三个事实串起来：

事实	含义
高维诅咒	提高召回率不可避免引入噪声
Lost in the Middle	多塞的文档在模型最不擅长的位置
噪声敏感	少量噪声就显著降低输出质量

这就是 Precision-Recall 矛盾的完整图景。它不是工程问题，是结构性问题。

3.4 实证：记忆增益的边际递减

我不是在说记忆系统没用。它确实有效。Hindsight（2025）把 20B 模型在 LongMemEval 上从 39% 提升到 83.6%。CorpGen（2026）把多任务完成率从 8.7% 提升到 15.2%（3.5x）。

但同一批论文也揭示了一个天花板：

Zep 在 MemGPT 自己的基准上只领先 1.4 个百分点
Lian 等人（2024）发现记忆超过 500 个事件的 Agent 产生矛盾计划的概率是小于 50 个事件的 2 倍
学术界开始承认：当前 RAG 范式的记忆系统正在逼近收益天花板

四、SOAR Chunking vs 现代 Agent 的"学习"

回到 SOAR。它的 Chunking 和今天的"记忆"有一个本质性的区别：

维度	SOAR Chunking	现代 Agent 记忆
改变了什么	新增生产式规则到架构中	存一段文本到数据库
持久性	永久的行为改变	依赖上下文窗口（滚出去就没了）
机制	条件-动作规则编译	文本注入到 prompt
泛化	规则自动匹配任何符合条件的状态	只有文本重新注入才生效
重量级	轻量（一条规则）	重量级（每次检索 + 上下文消耗）

SOAR 的 Chunking 是真正的程序性学习：系统的决策逻辑被永久修改了。下次遇到同样的情况，它不需要思考，直接反应。

现代 Agent 的"记忆"是外部文本存储：每次使用都需要重新检索、重新注入、让模型重新处理。你记了 100 件事，每次对话开始，你要检索一次，消耗一次上下文。

这不是同一个量级的东西。

Hermes Agent 的 SKILL 系统是最接近 Chunking 的——它在完成任务后自动创建 SKILL 文件——但它依然只是存了一段文本，下次读取这段文本。模型权重从未被修改过。

所有号称"终身学习"的产品都得打上问号。

五、Harness 工程：被忽视的真正杠杆

如果记忆不是 Agent 性能的关键瓶颈，那什么是？

越来越多的证据指向另一个方向：Agent 与环境的接口质量——工具设计、反馈信号、错误处理、状态控制。 我称之为 Harness 工程。

Andrew Ng 的数据

2024 年 3 月，Andrew Ng 在 Agentic Design Patterns 系列中公布了一个令人震惊的对比：

配置	HumanEval 准确率
GPT-4 零样本	67.0%
GPT-3.5 零样本	48.1%
GPT-3.5 + Agent 循环	95.1%

GPT-3.5（弱模型）+ 良好的 Agent 流水线（工具使用、反思、规划）大幅超越了 GPT-4（强模型）零样本。

这意味着你可以花精力优化模型内部的记忆系统，也可以花精力优化 Agent 外部的工具和流程。后者的收益可能更高。

Anthropic 的 ACI 概念

Anthropic 在 2024 年 12 月的《Building Effective Agents》中提出了 ACI（Agent-Computer Interface） 的概念——Agent 与计算机之间的接口质量和 HCI 一样值得精心设计。

他们报告：

“在 SWE-bench 的 Agent 上，优化工具所花的时间比优化整体提示词还要多。”

一个具体的案例：把工具参数从相对路径改成绝对路径（简单的防错设计），就消除了一整类错误。不需要更好的记忆，不需要更强的模型，只需要想清楚工具该怎么暴露。

这就是 Harness 工程的威力。

MCP 和 A2A 的标准化信号

2024-2025 年，两个协议的出现标志着产业界意识到 Harness 层的重要性：

MCP（Model Context Protocol）：标准化 Agent 如何访问工具和数据
A2A（Agent-to-Agent Protocol）：标准化 Agent 之间如何通信

这两个协议不是在解决"模型怎么更聪明"，而是在解决"Agent 如何更好地与环境互动"。它们本质上都是 Harness 工程的标准化工件。

六、结论：先修路，再建博物馆

我不是在否定记忆系统。记忆是必要的。SOAR 说得对，任何通用智能系统都需要记忆。今天的产品也确实从记忆中受益。

我想说的是两件事：

第一，记忆的收益正在递减。 检索式记忆有坚实的理论天花板。你可以继续优化你的 RAG 管道、调参 HNSW、尝试不同的 chunk 策略——但 PR 矛盾不是"优化参数就能解决"的工程问题，是结构性的约束。

第二，Harness 工程是被忽视的更大杠杆。 好的工具设计、清晰的反馈信号、可靠的状态控制——这些给 Agent 带来的增益可能远大于更好的记忆。Andrew Ng 的 95.1% 和 Anthropic 的 ACI 实践都在指向这个方向。

如果要用一个比喻来总结：

记忆是博物馆的展品。Harness 是通往博物馆的路。大部分人都在争论展品怎么摆放更漂亮，但真正决定你能看多少展品的，是那条路修得好不好。

SOAR 在 1987 年就看懂了这件事。它的 9 层记忆系统很漂亮，但真正让它"至今不过时"的，是那个将记忆、决策、执行、学习整合在一起的闭环架构——也就是它对自己的"环境"（包括记忆环境）的完整管理。

30 年过去了，我们还在卖"记忆系统"这个概念。也许该往前看了。

生产环境 RAG 的七步流水线：PR 矛盾没被解决，只是被管理了

Fri, 01 May 2026 00:00:00 +0000

在上一篇（《SOAR 的记忆蓝图》）里，我拆解了检索式记忆系统的 Precision-Recall 矛盾：

提高召回率 → 必然引入噪声 → LLM 被无关信息干扰
提高精度 → 降低召回率 → 遗漏相关信息
加 Reranker/CRAG → 延迟和复杂度上升 → 本身也会失败

这不是"优化几个参数就能解决"的工程问题，这是高维空间的几何学、Transformer 的注意力机制、以及 LLM 的噪声敏感性共同决定的结构性约束。

但有一个问题还没回答：如果这个矛盾没法解决，那在实际干活的人是怎么做的？

答案是：他们不解决矛盾，他们管理矛盾。

经过 2023-2026 年的快速迭代，工业界已经收敛到一个标准的"七步流水线"。每一步都在做不同的权衡，每一步都承认矛盾没有被消除。但这个管道叠加起来，把 PR 矛盾压到了一个可接受的范围。

第一步：查询变换（Query Transformation）

原始的用户查询很少适合直接检索。

用户说"帮我看看那个张三上次提到的项目进度"，直接拿去向量检索，八成找不到对应的文档。需要先把查询转换成更适合检索的形式。

常用方案

方法	做法	效果
Multi-Query	用 LLM 把一个问题改写为 3-5 个不同角度的检索词	增加召回率，减少遗漏
HyDE (Gao, 2022)	先生成一个"假设的理想文档"，用它的嵌入去检索	对需要精确匹配的场景效果好
Step-back Prompting	先生成一个更抽象的宽泛问题，从宽到窄检索	适合需要先理解上下文再找细节的场景
查询分解	把复杂问题拆成多个子问题，分别检索	适合多跳问题

这一步的权衡

查询变换提高了召回率（覆盖了查询的不同侧面），但代价是：

可能偏离原始意图——改写后的查询抓住了相关的 false positive，漏掉了真正的目标
LLM 调用成本——每次查询变换都多了一次 LLM 调用
延迟增加——Multi-Query 让一次检索变成 3-5 次

这是 PR 矛盾的第一层应对：用算力换召回率。

第二步：元数据预过滤（Metadata Pre-filtering）

纯向量检索在生产环境中已经没人用了。

你的知识库有各种属性——时间范围、文档来源、领域、权限级别。如果不在向量检索之前用这些属性做预过滤，你的向量搜索就会在一个巨大的、大部分不相关的空间里找相似度。

Pinecone、Weaviate、Qdrant 的生产指南里有一条共识：先过元数据，再过向量。

典型实现

查询: "2026年Q1的项目报告"
过滤: date >= 2026-01-01 AND date <= 2026-03-31
 AND type = "project_report"
向量检索: 在过滤后的子集里做 top-k

这一步的权衡

预过滤大幅提高精度（把搜索空间缩小到真正相关的子集），但代价是：

如果过滤条件太激进，召回率会骤降——你过滤掉了你以为是无关、但实际上相关的内容
预过滤 vs 后过滤的永恒争议：先过滤再向量搜索（丢失潜在匹配）vs 先向量搜索再过滤（浪费算力在不相关的结果上）
两个过滤器之间的：元数据过滤掉的文档，向量搜索不会看到

这是 PR 矛盾的第二层应对：用先验知识减少搜索空间。

第三步：混合检索 + RRF（Hybrid Search + Reciprocal Rank Fusion）

纯稠密检索（Dense Retrieval）和纯稀疏检索（BM25）各有缺陷：

检索方式	强项	弱项
稠密检索（Embedding）	语义匹配	丢失精确关键词匹配，受嵌入质量影响
稀疏检索（BM25）	精确关键词匹配	无法处理同义、近义表达

工业界的答案是：两个都做，然后把结果融合。

Reciprocal Rank Fusion（RRF）

RRF 的公式极其简单：

score(d) = Σ 1 / (k + rank(d))

对每个文档，取它在两种检索方式中的排名，加起来算一个综合分数。k 是一个平滑常数，通常取 60。

这一步的权衡

混合检索在召回率上有明显的提升（5-15% 的 recall@10 改善），但代价是：

两个索引都要维护——稠密索引 + 稀疏索引，存储翻倍
RRF 权重难调——k 值、稠密 vs 稀疏的权重比例，对不同的领域和查询类型有不同的最优值
两个引擎都可能出问题——一个引擎的失败结果会通过 RRF 污染最终排名

这是 PR 矛盾的第三层应对：用多个正交的检索信号互相补充。

第四步：小 Chunk 检索（Small Chunk Retrieval）

这是整个流水线里最微妙的一步。

你面临一个根本性的矛盾：

Chunk 大小	嵌入精度	上下文完整性
小（~200 tokens）	高——每段聚焦一个主题，嵌入向量干净	低——切碎了语义边界
大（~1000 tokens）	低——一段包含多个主题，嵌入向量的平均化稀释了语义	高——保留了上下文

Anyscale 在 2023 年做了一个有影响力的实验：把 chunk_size 从 100 逐步增加到 900，观察检索分数和生成质量的变化。

结果是两条方向相反的曲线：

检索分数单调递增——更大的 chunk 更容易被命中（里面有更多关键词）
生成质量先升后降——在 300-500 tokens 达到峰值，之后更多的上下文开始引入噪声

工业界的共识

小 chunk 用于检索，大 chunk 用于阅读。

具体来说：嵌入和检索用 256-512 tokens 的小 chunk（保证精度），检索到之后把整个 parent document 或相邻 chunk 一起拉上来送给 LLM。

这被称为 “small-to-retrieve, big-to-read” 模式。

这一步的权衡

小 chunk 让检索精度大幅提升，但引入了一个新的复杂度：你需要额外维护 chunk ↔ parent 的映射关系，且 chunk 边界的切割永远会破坏一些语义边界。

这是 PR 矛盾的第四层应对：把"检索"和"阅读"解耦，让它们用不同的粒度。

第五步：上下文展开（Context Expansion）

第四步检索到的是小 chunk。但单独把小 chunk 扔给 LLM 是不够的——它只看到了切片，看不到上下文。

上下文展开的做法是：拿到命中的小 chunk 后，把它的邻居 chunk 或 parent 文档一起带上来。

实现方式

SentenceWindowRetrieval：命中一个句子，拉它前后 N 个句子作为上下文窗口
ParentDocumentRetriever：命中一个子 chunk，拉对应的父文档
Sliding Window：把 chunk 边界滑动一下，重新拼接上下文

这一步的权衡

展开把精度↔完整性的天平往回拉了拉——你放弃了部分精度，换回了上下文。但展开范围越大，你重新引入了多少噪声就越不可控：

chunk 精度: 高
展开后: 上下文完整了，但噪声回来了

这是 PR 矛盾的第五层应对：用"检索精度换阅读完整性".

第六步：重排序（Re-ranking）

前五步产出的结果是一堆"roughly 相关"的候选。它们之间的相关性差异很小，而向量相似度在这个阶段已经丧失了分辨力。

Reranker（通常是一个交叉编码器）把 query 和每个候选文档配对，算一个精确的相关性分数。

效果

方案	精度提升
不加 Reranker	基线
加 Cross-encoder Reranker	+5-15pp nDCG（在 BEIR 基准上）

Cohere Rerank、BGE-Reranker 是生产中最常用的选择。

这一步的权衡

Reranker 是目前最有效的精度提升手段，但它有一个你不能忽视的限制：

它不能挽救没有被前面步骤命中到的文档。

Reranker 做的是"从候选里挑出最相关的"，候选名单在上一步就已经定了。如果前面六步都没有命中那个真正相关的文档，Reranker 也帮不了你。

Reranker 提高精度，召回率天花板由前序步骤设定。

另外，交叉编码器比双编码器慢 2-5x。

这是 PR 矛盾的第六层应对：用更多的算力（交叉编码）换取精度，但承认召回率的天花板已经定了。

第七步：LLM 生成

最后一步，把前六步精挑细选出来的上下文送给 LLM，让它生成答案。

这一步本身也能做一些事情来管理 PR 矛盾：

系统提示约束：明确告诉 LLM"如果检索到的内容不足以回答，请说不知道"
引用锚定（Citation Anchoring）：要求 LLM 在回答的每个关键事实后面注明来源 chunk
置信度声明：如果模型的回答基于不充分的检索结果，要求它声明不确定性

这一步的权衡

这一步的约束越严格，精度越高（更少幻觉），但用户可能得到更多"我不知道"的回复——这是用用户满意度换精度。

这是 PR 矛盾的第七层应对：用生成时的约束来兜底。

全景：七步的得失

把七步串起来，每一层的权衡一目了然：

步骤	主要 tradeoff	状态
查询变换	召回率 ↑ / 意图偏离风险 ↑	生产标配
元数据过滤	精度 ↑ / 过滤过头则召回率骤降	生产标配
混合检索 + RRF	召回率 ↑ / 维护成本 ↑ / 权重难调	生产标配
小 chunk 检索	精度 ↑ / 上下文完整性 ↓	生产标配
上下文展开	完整性 ↑ / 噪声回归	生产标配
重排序	精度 ↑ / 延迟 ↑ / 召回率天花板已定	生产标配
LLM 生成约束	精度 ↑ / 用户满意度 ↓	按需采用

每一个步骤都引入了一个新的 tradeoff，下一个步骤又来部分弥补这个 tradeoff。整个流水线不是在解决问题，而是在不断转移问题。

局限：七步之后，矛盾仍在

必须坦诚地说：即使走了七步，PR 矛盾也没有被消灭。

Query 理解是根本瓶颈——如果你的查询本身就是模糊的，整个管道的上限就定死了
Chunk 边界永远在丢失信息——无论切多小，信息的连续性都会在切割点中断
递归检索没有好的停止条件——搜了一次觉得不够，再搜一次，什么时候该停？
新鲜度检测没人做好——系统无法可靠判断检索到的信息是否已经过时

工业界的七步流水线是一个"足够好"的方案，不是一个"解决了问题"的方案。

结论：管理矛盾，而不是解决矛盾

Precision-Recall 矛盾不是一个 bug，是一个 feature——它是检索式记忆系统在数学层面的固有属性。你不可能消除它，就像不可能消除重力。

但你可以在重力存在的情况下建房子。七步流水线就是那个房子。

每一步都在做权衡，每一步都在承认矛盾没有被消除。但这个管道叠加起来，把 PR 矛盾压到了一个工程上可接受的范围内，让生产系统能够稳定运行。

如果你在做 RAG 或 Agent 记忆系统，我的建议是：

先走完前六步，看看效果。大部分人走到第三步就觉得够了。
在每一步记录你的权衡。 清楚你在哪里丢了精度、哪里丢了召回率。
接受’足够好’。 追求完美的 PR 平衡会让你走进死胡同。

回到上一篇的核心论点：记忆系统有用，但它有天花板。七步流水线就是工业界在天花板之下能找到的最佳实践。

理解了这个框架，你就理解了为什么 Harness 工程（工具设计、反馈质量、状态控制）可能是比记忆系统更大的杠杆——因为你在七步之内能做的最大的改变，往往不在检索这一步。