[{"content":"AI产品领域 命令行窗口(CLI)，面向对象为程序员，通常用于开发代码项目。因为不存在界面需求，因此增改功能变得非常简单。\n早期产品： Cursor， 仅依赖于VS CODE插件的Roo code。\n首先是该领域的御三家的作品：Claude Code， Code X， Gemini CLI，\n可视化界面 Claude Cowork\nNoteBook LM以及AI Studio\n","date":"2026-04-28T00:00:00Z","permalink":"/post/agent-product/","title":"AI产品实际测评"},{"content":"Agent 系统架构演变完整调研\n一、总览：三代范式跃迁 Agent 系统架构的演变可归纳为三条并行的技术主线，历经约 70 年的迭代。按照核心驱动力，可划分为符号主义时代 → 强化学习时代 → LLM 原生时代三大范式。当前正处于第三次范式的高潮期，且呈现出多范式融合的趋势。\n二、第一阶段：符号主义 / 经典 Agent 架构（1950s–1990s） Agent理论的发展比深度学习还要早。 在ChatGPT这种能够真正回答人类问题的AI出现之前，就已经开始思考“一个完全由人工定义的智能会是什么样子”这一问题。 这点来讲，哲学理论走得要远远超前。\n2.1 规则系统（Rule-Based Systems） 最早的 AI Agent 以 专家系统（Expert Systems） 为代表。架构核心是：\n知识库（Knowledge Base） + 推理引擎（Inference Engine） 知识以 if-then 规则 显式编码 推理引擎执行前向/后向链式推理 典型代表：MYCIN（1976，医疗诊断）、DENDRAL（1965，化学分析） 局限：规则数量爆炸、无法处理模糊/未知场景、完全不具备学习能力。\n我甚至不认为规则系统该作为Agent理论的一部分，它用众多规则堆砌出决策，似乎跟智能毫无关系。\n但是目前的智能体有个说法：与其要求ai按照严格语法编写代码，不如让它编写完后执行一遍检查。规则系统适合ai与严谨的外部环境交互时使用。\n2.2 BDI 架构（Belief-Desire-Intention） 这个理论是来自哲学界的产物，研究的是人类的行为。\n早期的哲学中认为欲望驱动理性。Hume 的核心论证极其著名，就一句话：\n| \u0026ldquo;Reason is, and ought only to be the slave of the passions.\u0026rdquo; |（理性是，也只应当是激情的奴隶。——《人性论》2.3.3）\n这一观点不依赖任何实验，仅仅通过内省和推理便收获了人们的认可。\n转换到Agent理论中，可以想象，如果让当时的人们设计一个智能体，他们设想的架构会是：给agent设定一个目标(Desire)，agent用它的知识(Belief，指ai相信的世界知识)完成目标。\n即使放到今天，这个想法也不能说是错，但它很粗糙，表达起来很主观，比如Desire跟Belief是什么，都没有明确的定义。只是一种感觉上的描述。\nDennett(1971)将它更具体一些，让这个理论更像是科学里的描述了： 当我们说一个人有 belief 和 desire，不是说我们真的在他的大脑里找到了这些实体——而是说，用这组概念来预测他的行为，是最有效的策略。\n当理解物理系统时，我们依靠精确但复杂的物理规律去了解；当理解人造物时，我们可以从它的设计目的去了解；当想要了解人类、动物、AI时，我们用belief和desire理论去了解。\n当我们想要科学地研究agent(或人)时，我们\n假设agent是理性的 根据它的处境和目的，赋予它应有的belief和desire 预测理性系统会作出的最符合这些belief和desire的事 从此时开始，Belief-Desire理论听上去很像是严谨的科学了。它像是在强调，心理学其实是一种概率学，一种工具；也可以反过来理解，借助生成最高概率的做法，就能模拟出一个理性系统。\nMichael Bratman（1987）的哲学理论，则认为Belief-Desire理论在解释瞬时行动的时候是合理的，但对于跨时间的计划行为，它的解释力不足。\n想要的未必真的就去做。例如用户可能希望去巴黎旅行，但这并不意味着会立刻触发“订机票、办签证、订住宿”这一系列流程。Desire List不会立刻触发行动。 想要的东西之间存在矛盾。例如用户想吃蛋糕，以及希望减肥。如果Desire List以同等的地位进入执行阶段，便发生了冲突。但它们在Desire阶段是完全能够共存的。这也说明Desire到执行这一步之间，还存在一些步骤。 他引入了Intention(意图)，即决定要去做的事。Desire经过“作出承诺要做这件事”这一步骤后，才进入到执行阶段。\n这一理念将 Agent 建模为三种心理状态：\n组件 含义 类比 Belief（信念） 对环境状态的认知 数据库/知识图谱 Desire（愿望） 目标状态/偏好 目标队列 Intention（意图） 已承诺执行的计划 执行栈 仅仅有Desire不代表真正去做，Intention，也就是下决心真的要去做的时候，才真正开始做。执行阶段不属于心理状态，因此不在表中。\nIntention这一阶段的引入提供了三种作用：\n用Intention作为推理与执行的起点，而不是以Desire作为起点。同时想要减肥与吃蛋糕，欲望是同时存在的，但下决心，到了真正要指导行动的时候，只会留下一个Intention。 Intention可以实现跨时间协调，也就是对人的“惯性心理”的刻画。人并不会时时刻刻对所有Desire进行评估并重新规划。而是延续之前的“决定”，完成之前心中的承诺。例如在已经决定减肥后，默认的Intention依然是减肥，而不是再次比较一番所有Desire，完全独立的重新构建新的Intention。它不是不可改变，但它会抵抗改变，人们借此得以执行跨越时间的计划。 在公共关系中同样需要“决定”这一步骤。“我想帮你”与“我会帮你”是存在不同的，在多agent系统中，就可能有必要区分清楚。 代表性框架：AgentSpeak(L)、Jason、PRS（Procedural Reasoning System）。BDI 至今仍在 MAS（Multi-Agent Systems）研究中有影响力——它将\u0026quot;计划选择\u0026quot;和\u0026quot;目标承诺\u0026quot;显式分离，是 Agent 架构中\u0026quot;认知层\u0026quot;概念的原型。\n这些理论都是基于自省、思维实验构建的。跟工科认知中的科学相差甚远。这种理论通常需要依赖反证法：当缺失这一概念时，理论会怎样的不完善。从而使新理论得到认可。\n2.3 SOAR 认知架构（1987） SOAR（State, Operator And Result ）是Allen Newell、John Laird 等人提出的通用认知架构，目标是实现通用人工智能。\n这是一个宏大的命题： 既然人类能在所有认知领域表现出智能，那么一定存在一套固定的、通用的底层机制——这个机制就是认知架构（cognitive architecture）。SOAR 是这一机制的一种实现。\nSOAR 不是\u0026quot;一个 AI 程序\u0026quot;，而是一套关于智能是什么的理论——它说：任何表现出通用智能的系统，都得有某种固定的结构，这个结构包含什么记忆系统、什么决策流程、什么学习机制。\n核心机制：\n短期记忆（STM） ↔ 决策周期 ↔ 长期记忆（生产规则 + 语义 + 情节） ↕ 意向栈（Goal Stack） 决策周期（Decision Cycle）：感知 → 匹配规则 → 冲突消解 → 执行 → 学习（Chunking） 通用子目标（Universal Subgoaling）：遇到困境自动创建子目标 学习机制 Chunking：将解决方案编译为新的规则 SOAR 在 AI Agent 架构史上有着里程碑地位——它首次完整定义了 感知 - 推理 - 执行 - 学习的闭环架构，影响了后续几乎所有 Agent 架构的设计。\n要我说，ReAct循环完全跟这个一样，所以算不上什么新东西。只不过SOAR提出的时间太久远了，人们又只关注近期的知识。这恐怕是人类在知识继承里的常态。\n| 任何需要“在环境中持续行动的智能系统”，都需要有类似这样的闭环，这不能说是发明，而是一种工程约束。\n顺便一提，SOAR可以称得上是早期的“终身学习系统”了，跟现在agent常见的宣传一样，都号称越用越聪明。\n外部输入 思考 根据外部输入匹配规则 消解冲突规则，选择其中的规则 执行 成功则输出 不成功则拆解任务为子目标 重复循环直到问题解决 Chunking 将解决问题的方案编译为规则，下次遇到同样问题能够快速处理。 这其中的Chunking能力就跟Hermes Agent完成任务后编写SKILL的做法一样，并因此号称终身学习。\nSOAR的认知架构（对应Agent记忆系统）同样是类似如今的多层架构，一共有9个记忆系统\n工作记忆。这是SOAR管理全局的记忆，所有输入，中间推理，决策状态都在这里，并用栈结构分层表示目标与状态，子目标与子状态。相当于主Agent。 SOAR架构没有死，甚至还活跃着。\n2.4 ACT-R 架构 Anderson 等人开发的认知架构，专注于模拟人类认知过程。相比 SOAR 的全符号主义，ACT-R 引入了亚符号层（subsymbolic），包括：\n扩散激活（Spreading Activation）：记忆检索的基础 效用学习（Utility Learning）：规则选择的最优化 ACT-R 是将\u0026quot;计算精度\u0026quot;与\u0026quot;认知真实性\u0026quot;结合的典范，后来被部分 LLM Agent 的记忆设计参考。\n三、第二阶段：强化学习 Agent 架构（1990s–2010s） 3.1 经典 RL Agent（Q-Learning, SARSA） RL 将 Agent 定义为 MDP（马尔可夫决策过程） 中的决策者：\n状态(State) → 动作(Action) → 奖励(Reward) → 新状态(State\u0026#39;) 架构特征：\nValue-based：Q-Learning，维护 Q(s,a) 表 Policy-based：REINFORCE，直接学习策略 π(a|s) 局限：状态空间受限，难以应对高维感知 3.2 深度 RL Agent（DQN, 2013） DeepMind 的 DQN（Deep Q-Network） 引发 RL 革命，关键架构创新：\nCNN（视觉编码器）→ Q(s,a) Value Network → ε-greedy 策略 ↕ 经验回放缓冲区（Experience Replay） ↕ Target Network（稳定目标分布） 经验回放（Experience Replay）：打破时序相关性 两阶段目标网络（Double DQN）：减少价值过估计 3.3 Actor-Critic 架构（PPO, SAC） 现代 RL Agent 的主流架构。分离 策略网络（Actor） 与 价值评估网络（Critic）：\n┌─────────────┐ ┌──────────────┐ │ Actor │ │ Critic │ │ π(a|s) │←───│ V(s) / Q(s,a)│ │ 生成动作 │ │ 评估动作质量 │ └──────┬───────┘ └──────┬────────┘ │ │ └─────────┬─────────┘ ▼ 环境交互 → 奖励信号 PPO（Proximal Policy Optimization, 2017） 使用 Clip 机制限制策略更新范围，成为 RL Agent 的事实标准。SAC（Soft Actor-Critic） 通过最大熵强化学习增强了探索能力。\nRL Agent 的架构范式（感知 → 决策 → 执行 → 学习循环）为后来的 LLM Agent 提供了循环结构的设计母板。\n3.4 多智能体 RL（MADDPG, 2017） Lowe 等人提出 MADDPG（Multi-Agent DDPG），架构核心：每个 Agent 的 Critic 可以观察所有 Agent 的动作（CTDE: Centralized Training, Decentralized Execution）。\nAgent 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）在概念层借鉴。\n四、Pre-LLM 混合架构与过渡期 4.1 RLL（Reinforcement Learning with Language） 在 LLM 大爆发前，研究者试图将自然语言引入 Agent 架构。典型代表：\nEmbodied Agents (ALFRED, 2020)：通过指令-\u0026gt;子任务分解-\u0026gt;RL策略 Interactive Fiction Agents (Jericho, 2019)：自然语言文本界面 + RL 4.2 基于 LSTM/Transformer 的命令理解 Agent WebGPT（OpenAI, 2021）：用 GPT-3 + 模仿学习操作浏览器，首次展示了\u0026quot;语言模型 + 工具 + 搜索\u0026quot;的 Agent 雏形 架构：Behavior Cloning on human demonstrations + RL fine-tuning 这些系统虽然性能有限，但建立了语言模型作为 Agent 控制器的架构原型，是通往 LLM Agent 的关键桥梁。\n五、第三阶段：LLM Agent 革命（2023–至今） 5.1 分水岭事件：GPT-4 Function Calling（2023-06） 2023年6月，OpenAI 发布 GPT-4 的 function calling 能力。这是 Agent 架构史上的分水岭。\n架构变革：\n之前: User → LLM → Text Output → 手动解析 → 调用API 之后: User → LLM → JSON tool_call → 自动执行 → 结果反馈 → LLM Function Calling 使得 LLM 可以：\n结构化输出函数参数（不再是自由文本） 多轮工具调用（chain of tool calls） 自动反馈循环（工具结果作为上下文回注） 这标志着 LLM-based Agent 时代正式开启。\n5.2 ReAct 范式的崛起（Yao et al., 2023） ReAct（Reasoning + Acting）是 LLM Agent 最核心的架构范式，由 Yao 等人在 2023 年提出。\nThought: 我需要查找当前的天气数据 Action: search_weather(location=\u0026#34;Beijing\u0026#34;) Observation: {\u0026#34;temp\u0026#34;: 28, \u0026#34;humidity\u0026#34;: 65%} Thought: 气温 28°C，湿度 65%，建议穿短袖 Action: complete 架构循环：\n┌─────────────────────────────────────┐ │ LLM (核心推理引擎) │ │ │ │ 思考(Thought) → 动作(Action) │ │ ↑ ↓ │ │ 观察(Observation) ← 工具执行结果 │ │ ↑ │ │ Scratchpad (上下文缓冲区) │ └─────────────────────────────────────┘ ReAct 的关键设计要素：\nScratchpad：作为 Agent 的\u0026quot;工作记忆\u0026quot;，存储推理链 Thought-Action-Observation 三元组：可解释的决策轨迹 动态停止条件：Agent 自行判断任务是否完成 5.3 第一代自主 Agent 框架（2023 年中） AutoGPT（2023-03） 和 BabyAGI（2023-04） 引爆了 Agent 概念。\nAutoGPT 架构：\n┌─────────────────────────────────────────┐ │ Goal → 任务队列(Task Queue) │ │ ↓ │ │ LLM 推理 → 执行动作 → 存储结果 │ │ ↓ │ │ 优先队列(优先级排序 → 再次执行) │ │ ↓ │ │ 向量数据库(长期记忆检索) │ └─────────────────────────────────────────┘ BabyAGI 架构创新：引入了任务分解（task decomposition） 与记忆优先级（memory prioritization），但其无限制的自我循环也引发了\u0026quot;Agent 失控\u0026quot;的讨论。\n5.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（线性管道），架构为：\nInput → PromptTemplate → LLM → OutputParser → NextChain → ... 问题：线性链条无法处理条件分支、循环、多工具调用。\nLangGraph 的革命性升级：\nStateGraph: Node(agent) → Edge(router) → Node(tools) ↑ │ └─────────────────────────────┘ (循环，直到 agent 决定停止) LangGraph 引入了：\nStateful Graph：节点间通过共享状态通信 Conditional Edges：根据条件动态路由 Persistence：内置的持久化/中断/恢复机制 AutoGen 的对话式架构 Microsoft AutoGen 的架构核心是 Agent-Centric 的消息驱动模型：\n┌─────────────────────────────────────────────┐ │ UserProxyAgent AssistantAgent │ │ (人类代理) (LLM代理) │ │ │ │ │ │ └─────── 对话循环 ──────┘ │ │ │ │ │ Tool/Function │ │ (代码/API执行) │ └─────────────────────────────────────────────┘ 关键创新：多 Agent 通过自然语言对话完成协作，而非硬编码的流程控制。\nCrewAI 的角色化架构 CrewAI 引入了组织隐喻（Organizational Metaphor）：\nCrew (团队) ├── Agent: 研究员（角色: 研究者, 目标: 收集信息, 工具: web_search） ├── Agent: 分析师（角色: 分析师, 目标: 分析数据, 工具: code_exec) ├── Task: 收集数据（分配给 研究员 Agent） └── Task: 生成报告（分配给 分析师 Agent, 依赖 Task1） 设计理念：将 Agent 组织视为虚拟公司，通过角色、职责、任务的显式分配来解耦复杂系统。\n5.5 Prompt Agent → 工具 Agent 的架构转变 2024 年的关键趋势是从提示代理（Prompt Agent） 向工具代理（Tool Agent） 的演变：\nPrompt Agent: 单一 LLM 调用 → 文本输出 无外部反馈循环 依赖模型能力 Tool Agent: LLM(工具描述 + 上下文) → tool_call → 执行结果 → LLM(结果) 结构化工具接口 持续交互闭环 Function Calling / Tool Use 成为 Agent 架构的标准层：\nAgent ├── 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 基础上引入评估-反思闭环：\n┌─────────────────────────────────────┐ │ Actor (ReAct Loop) │ │ Thought → Action → Observation │ └─────────────┬───────────────────────┘ │ 完成/失败 ▼ ┌─────────────────────────────────────┐ │ Evaluator │ │ 评估任务完成质量 → 生成反馈 │ └─────────────┬───────────────────────┘ │ 结构化反馈 ▼ ┌─────────────────────────────────────┐ │ Memory │ │ 经验回放缓冲区（失败的决策 + 原因） │ └─────────────┬───────────────────────┘ │ 提取经验 ▼ 回到 Actor 重新执行 核心创新：Agent 通过自然语言反思自己的失败并将经验存入记忆，而非通过权重更新。\n七、协议标准化时代（2024 年底–2026） 7.1 MCP（Model Context Protocol） Anthropic 于 2024 年 11 月推出的开放协议，定位在 Agent 与工具/数据源之间的标准化接口。2025 年 12 月，Anthropic 将其捐赠给 Linux 基金会下的 Agentic AI Foundation。\n┌─────────┐ MCP 协议 ┌──────────┐ │ Agent │ ◄──────────► │ MCP Server │ │ (Host) │ │ │ │ │ │ ├── Database│ │ │ │ ├── Files │ │ │ │ ├── API │ │ │ │ └── Search │ └─────────┘ └──────────┘ 架构意义：MCP 将工具接口从\u0026quot;厂商锁定\u0026quot;推向标准化，使任何 MCP-compatible 的 Agent 都能自动发现和调用工具。\n7.2 A2A（Agent-to-Agent Protocol） Google 于 2025 年 4 月发布，定位在 Agent 与 Agent 之间的通信协议。2025 年 6 月贡献给 Linux 基金会。\n┌──────────────┐ │ Orchestrator │ │ Agent │ └──────┬───────┘ A2A ┌───────┴────────┐ ┌──────▼────┐ ┌──────▼────┐ │ Agent A │ │ Agent B │ │ (MCP工具) │ │ (MCP工具) │ └───────────┘ └───────────┘ MCP vs A2A 的关系：\n协议 解决的问题 方向 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 架构：\nUser Query → [Search Loop] ├── 规划搜索策略 ├── 并行多源搜索（Web + Academic + Code） ├── 阅读 + 提取关键信息 ├── 交叉验证冲突信息 └── 是否足够？→ 是 → 合成报告 ↓ 报告生成（带引用） 核心架构特征：\n多层搜索规划：BFS 式探索 信息到报告的直接转换：减少中间损耗 引用锚定（Citation Anchoring）：免幻觉的可溯源设计 8.2 Agentic RAG（检索增强生成 + Agent 决策） Agentic RAG 将传统 RAG 的\u0026quot;一阶段检索+生成\u0026quot;升级为多策略决策：\nQuery ↓ Router（路由决策） ├──→ Vector Search（语义检索） ├──→ Web Search（实时网络搜索） ├──→ SQL Query（结构化数据） └──→ Agent Loop（复杂查询：分解→检索→合成） 8.3 Hermes Agent 自身的架构（Mirror of the Trend） 你正在对话的 Hermes Agent 本身也体现了当前架构设计的最新趋势：\n工具中心：所有工具（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）开放互联的生态系统。\n从单一体到协作体：单一 LLM Agent → 多 Agent 编排（Orchestration）→ Agent 联邦（Federation）。\n循环结构是永恒模式：从 SOAR 的决策周期到 ReAct 的 Thought-Action-Observation，循环感知-推理-执行架构是所有 Agent 系统的基础。\n记忆系统分层化：Working Memory（Scratchpad）→ Short-term（对话历史）→ Long-term（向量数据库）的三层架构成为事实标准。\n编排粒度的细化：从 Sequential Chain → State Graph → Multi-Agent Conversation → Role-based Team，编排抽象层次不断上升。\n\u0026ldquo;大脑\u0026quot;与\u0026quot;四肢\u0026quot;分离：LLM 作为推理核心 → 工具作为执行层 → 协议作为连接层，三者走向解耦与标准化。\n评估-反馈-学习闭环：Reflexion、RLHF、SFT from Agent Trajectory… Agent 正在从\u0026quot;一次执行\u0026quot;走向\u0026quot;自我进化\u0026rdquo;。\n当前的瓶颈：Agent 可靠性（一致性幻觉）、成本控制（token 堆积）、安全边界（工具调用权限）、调试/可观测性——这些是 2025–2026 年的核心工程挑战。\n","date":"2026-04-10T00:00:00Z","permalink":"/post/agent-history/","title":"Agent必学：agent架构的演变历程"},{"content":"以Agent开发岗位所需的知识为参考，编写博客\nAgent系统架构的演进历程 多智能体协作\n记忆与上下文管理\n知识库/工具集/MCP/Skill\nAgent框架：OpenCode, ClaudeCode, LangGraph\n研发效能 / DevOps 平台经验优先（CICD / WebIDE / 工程效能度量）\n意图识别\nGo / Python + LangChain / LangGraph Coze / Dify 等低代码平台经验 RAG 深入理解 + 向量数据库实践经验 Prompt Engineering（问题拆解 / 规划 / 执行） 多 Agent 协作架构 + 任务调度逻辑 ","date":"2026-04-10T00:00:00Z","permalink":"/post/write-plan/","title":"写作方案规划：围绕Agent技术的梳理文章"},{"content":"写上一篇 Agent 架构演变史的时候，有一个时刻让我愣住。\n写到 SOAR（1987）的 Chunking 机制时，我意识到它和今天 Hermes Agent 的 SKILL 系统几乎做的是同一件事：把成功的经验编译成可复用的规则，下次直接调用。 我当时的原话是——\n要我说，ReAct 循环完全跟这个一样，所以算不上什么新东西。\n这不是故作惊人之语。顺着这个思路往下挖，我发现 SOAR 的整个记忆架构在今天看都不过时。不仅不过时，它还比大部分号称有\u0026quot;记忆系统\u0026quot;的产品更完整。\n但这引出一个让我不太舒服的问题：\n一个 1987 年的架构就已经想清楚的事，为什么 2026 年还在被当作创新来营销？\n或者说更尖锐一点：记忆系统，真的是 Agent 性能的关键瓶颈吗？\n一、SOAR 的记忆蓝图 SOAR（State, Operator And Result）由 Allen Newell、John Laird 等人在 1987 年提出。它的目标是实现通用人工智能——用的还是符号主义那套方法。\nSOAR 不是\u0026quot;一个 AI 程序\u0026quot;，它是一套关于智能的理论：任何表现出通用智能的系统，都得有某种固定的结构，包含什么记忆系统、什么决策流程、什么学习机制。\n在这个框架里，记忆不是附加功能，是核心架构。SOAR 一共定义了 9 个记忆系统，分三层：\n工作记忆（Working Memory） 这是 SOAR 的全局工作空间。所有感知输入、中间推理状态、决策状态都在这里，用栈结构分层表示目标与子目标。相当于今天 Agent 的 Scratchpad + 对话历史。\n长期记忆（Long-term Memory） 长期记忆又细分为三个独立系统：\n记忆类型 内容 今天的对应物 程序性记忆（Production Rules） if-then 规则，决定怎么做 LLM 的权重 + 推理策略 语义记忆（Semantic Memory） 事实性知识，知道是什么 RAG 知识库 / 向量数据库 情节记忆（Episodic Memory） 过去的经验，经历过什么 对话历史 / 记忆流 意向记忆（Intention Memory） SOAR 还有一个 Goal Stack（目标栈），管理当前正在追求的子目标及其优先级。这对应今天 Agent 的任务队列和规划器。\n决策周期 SOAR 的核心循环是：\n感知 → 匹配规则 → 冲突消解 → 执行 → 学习（Chunking） 遇到无法解决的问题时，自动创建子目标去解决。解决后，Chunking 机制把整个推导过程编译成一条新的生产规则。\n每一次循环可以改变行为。每一次 Chunking 可以永久提升效率。\n二、今天的\u0026quot;记忆营销\u0026quot; 现在回过头看 2023-2026 年的 Agent 产品，你会发现一个有趣的现象：几乎每个产品都在卖\u0026quot;记忆系统\u0026quot;。\n产品/框架 记忆卖点 实际实现 MemGPT/Letta 操作系统级分层记忆 存档存储 → 向量检索 → 注入上下文 Hermes Agent 终身学习、三层记忆 MEMORY.md(2200字符) + USER.md + FTS5 全文搜索 ChatGPT Memory 跨会话记住用户偏好 LLM 提取事实 → 结构化摘要 → 下次注入 Claude 项目记忆 记住项目上下文 单个 LLM 生成的项目摘要 Zep 自动实体提取和记忆管理 实体图谱 + 时间衰减 + 重要性评分 Kimi 手动保存到 AGENTS.md 纯文本文件读写 把这张表和 SOAR 的 9 层记忆系统放在一起看，你会发现一件尴尬的事：\n今天的\u0026quot;记忆系统\u0026quot;并没有比 SOAR 更丰富，反而更简陋。\nSOAR 有程序性记忆（改变了决策逻辑）、语义记忆（知识库）、情节记忆（经验）、目标栈（任务管理）。今天的产品基本上只实现了\u0026quot;存文本→检索→注入上下文\u0026quot;这一个模式，管它叫\u0026quot;记忆\u0026quot;。\n更关键的区别在后面。\n三、检索式记忆的理论天花板 抛开营销回到技术层面：今天的\u0026quot;记忆系统\u0026quot;本质上都是检索式记忆——你存一段文本，下次用向量搜索找到它，再塞回上下文。\n这个范式有一个数学层面无法规避的问题。\n3.1 高维诅咒 你能想到的几乎所有嵌入模型都在用 768d 或 1024d 的向量。\nAggarwal 等人在 2001 年就证明了一个令人不安的事实：当维度超过 ~25 时，高维空间中所有点的距离趋向均匀。最近邻和最远邻的距离比值趋近于 1。\n这意味着：你的向量索引本质上是一个随机排序器， 只是被嵌入模型的\u0026quot;语义压缩\u0026quot;勉强维持着秩序。两个文档余弦相似度 0.85 可能语义无关，另外两个 0.80 可能是同义改写。你的 ANN 索引分辨不了这个区别。\n你提高召回率=扩大检索范围，必然引入噪声——因为决策边界一定包含边界线不相关的文档。\n3.2 Lost in the Middle Liu 等人（2023）发现 LLM 在长上下文上的表现呈 U 型曲线：相关信息在开头和结尾时性能最好，在中间时下降 20-40%。\n这意味着什么？你为了提高召回率多检索几个文档进去，这些文档恰好被塞进了模型最不会利用的位置。\n你在主动伤害自己。\n更糟糕的是，这个 U 型是因果注意力（Causal Attention）的结构性属性。长上下文模型（128K、200K、甚至 1M）都没有消除它。它是一个 architectural 问题，不是一个参数能调好的。\n3.3 LLM 对噪声的极度敏感 Shi 等人（2023）在 GSM-IC 基准上发现：一个无关句子就让 GPT-3 的准确率从 80% 掉到 55-65%。 一个句子。\nCuconasu 等人（2024）进一步揭示：主题相关但实际无关的文档比明显无关的文档更有害——因为 LLM 分不清\u0026quot;看起来相关但没用\u0026quot;和\u0026quot;真正有用\u0026quot;。\n把这三个事实串起来：\n事实 含义 高维诅咒 提高召回率不可避免引入噪声 Lost in the Middle 多塞的文档在模型最不擅长的位置 噪声敏感 少量噪声就显著降低输出质量 这就是 Precision-Recall 矛盾的完整图景。它不是工程问题，是结构性问题。\n3.4 实证：记忆增益的边际递减 我不是在说记忆系统没用。它确实有效。Hindsight（2025）把 20B 模型在 LongMemEval 上从 39% 提升到 83.6%。CorpGen（2026）把多任务完成率从 8.7% 提升到 15.2%（3.5x）。\n但同一批论文也揭示了一个天花板：\nZep 在 MemGPT 自己的基准上只领先 1.4 个百分点 Lian 等人（2024）发现记忆超过 500 个事件的 Agent 产生矛盾计划的概率是小于 50 个事件的 2 倍 学术界开始承认：当前 RAG 范式的记忆系统正在逼近收益天花板 四、SOAR Chunking vs 现代 Agent 的\u0026quot;学习\u0026quot; 回到 SOAR。它的 Chunking 和今天的\u0026quot;记忆\u0026quot;有一个本质性的区别：\n维度 SOAR Chunking 现代 Agent 记忆 改变了什么 新增生产式规则到架构中 存一段文本到数据库 持久性 永久的行为改变 依赖上下文窗口（滚出去就没了） 机制 条件-动作规则编译 文本注入到 prompt 泛化 规则自动匹配任何符合条件的状态 只有文本重新注入才生效 重量级 轻量（一条规则） 重量级（每次检索 + 上下文消耗） SOAR 的 Chunking 是真正的程序性学习：系统的决策逻辑被永久修改了。下次遇到同样的情况，它不需要思考，直接反应。\n现代 Agent 的\u0026quot;记忆\u0026quot;是外部文本存储：每次使用都需要重新检索、重新注入、让模型重新处理。你记了 100 件事，每次对话开始，你要检索一次，消耗一次上下文。\n这不是同一个量级的东西。\nHermes Agent 的 SKILL 系统是最接近 Chunking 的——它在完成任务后自动创建 SKILL 文件——但它依然只是存了一段文本，下次读取这段文本。模型权重从未被修改过。\n所有号称\u0026quot;终身学习\u0026quot;的产品都得打上问号。\n五、Harness 工程：被忽视的真正杠杆 如果记忆不是 Agent 性能的关键瓶颈，那什么是？\n越来越多的证据指向另一个方向：Agent 与环境的接口质量——工具设计、反馈信号、错误处理、状态控制。 我称之为 Harness 工程。\nAndrew Ng 的数据 2024 年 3 月，Andrew Ng 在 Agentic Design Patterns 系列中公布了一个令人震惊的对比：\n配置 HumanEval 准确率 GPT-4 零样本 67.0% GPT-3.5 零样本 48.1% GPT-3.5 + Agent 循环 95.1% GPT-3.5（弱模型）+ 良好的 Agent 流水线（工具使用、反思、规划）大幅超越了 GPT-4（强模型）零样本。\n这意味着你可以花精力优化模型内部的记忆系统，也可以花精力优化 Agent 外部的工具和流程。后者的收益可能更高。\nAnthropic 的 ACI 概念 Anthropic 在 2024 年 12 月的《Building Effective Agents》中提出了 ACI（Agent-Computer Interface） 的概念——Agent 与计算机之间的接口质量和 HCI 一样值得精心设计。\n他们报告：\n\u0026ldquo;在 SWE-bench 的 Agent 上，优化工具所花的时间比优化整体提示词还要多。\u0026rdquo;\n一个具体的案例：把工具参数从相对路径改成绝对路径（简单的防错设计），就消除了一整类错误。不需要更好的记忆，不需要更强的模型，只需要想清楚工具该怎么暴露。\n这就是 Harness 工程的威力。\nMCP 和 A2A 的标准化信号 2024-2025 年，两个协议的出现标志着产业界意识到 Harness 层的重要性：\nMCP（Model Context Protocol）：标准化 Agent 如何访问工具和数据 A2A（Agent-to-Agent Protocol）：标准化 Agent 之间如何通信 这两个协议不是在解决\u0026quot;模型怎么更聪明\u0026quot;，而是在解决\u0026quot;Agent 如何更好地与环境互动\u0026quot;。它们本质上都是 Harness 工程的标准化工件。\n六、结论：先修路，再建博物馆 我不是在否定记忆系统。记忆是必要的。SOAR 说得对，任何通用智能系统都需要记忆。今天的产品也确实从记忆中受益。\n我想说的是两件事：\n第一，记忆的收益正在递减。 检索式记忆有坚实的理论天花板。你可以继续优化你的 RAG 管道、调参 HNSW、尝试不同的 chunk 策略——但 PR 矛盾不是\u0026quot;优化参数就能解决\u0026quot;的工程问题，是结构性的约束。\n第二，Harness 工程是被忽视的更大杠杆。 好的工具设计、清晰的反馈信号、可靠的状态控制——这些给 Agent 带来的增益可能远大于更好的记忆。Andrew Ng 的 95.1% 和 Anthropic 的 ACI 实践都在指向这个方向。\n如果要用一个比喻来总结：\n记忆是博物馆的展品。Harness 是通往博物馆的路。大部分人都在争论展品怎么摆放更漂亮，但真正决定你能看多少展品的，是那条路修得好不好。\nSOAR 在 1987 年就看懂了这件事。它的 9 层记忆系统很漂亮，但真正让它\u0026quot;至今不过时\u0026quot;的，是那个将记忆、决策、执行、学习整合在一起的闭环架构——也就是它对自己的\u0026quot;环境\u0026quot;（包括记忆环境）的完整管理。\n30 年过去了，我们还在卖\u0026quot;记忆系统\u0026quot;这个概念。也许该往前看了。\n","date":"2026-05-01T00:00:00Z","permalink":"/post/soar-memory-blueprint/","title":"SOAR 的记忆蓝图：30 年前的架构，今天的营销话术"},{"content":"在上一篇（《SOAR 的记忆蓝图》）里，我拆解了检索式记忆系统的 Precision-Recall 矛盾：\n提高召回率 → 必然引入噪声 → LLM 被无关信息干扰 提高精度 → 降低召回率 → 遗漏相关信息 加 Reranker/CRAG → 延迟和复杂度上升 → 本身也会失败 这不是\u0026quot;优化几个参数就能解决\u0026quot;的工程问题，这是高维空间的几何学、Transformer 的注意力机制、以及 LLM 的噪声敏感性共同决定的结构性约束。\n但有一个问题还没回答：如果这个矛盾没法解决，那在实际干活的人是怎么做的？\n答案是：他们不解决矛盾，他们管理矛盾。\n经过 2023-2026 年的快速迭代，工业界已经收敛到一个标准的\u0026quot;七步流水线\u0026quot;。每一步都在做不同的权衡，每一步都承认矛盾没有被消除。但这个管道叠加起来，把 PR 矛盾压到了一个可接受的范围。\n第一步：查询变换（Query Transformation） 原始的用户查询很少适合直接检索。\n用户说\u0026quot;帮我看看那个张三上次提到的项目进度\u0026quot;，直接拿去向量检索，八成找不到对应的文档。需要先把查询转换成更适合检索的形式。\n常用方案 方法 做法 效果 Multi-Query 用 LLM 把一个问题改写为 3-5 个不同角度的检索词 增加召回率，减少遗漏 HyDE (Gao, 2022) 先生成一个\u0026quot;假设的理想文档\u0026quot;，用它的嵌入去检索 对需要精确匹配的场景效果好 Step-back Prompting 先生成一个更抽象的宽泛问题，从宽到窄检索 适合需要先理解上下文再找细节的场景 查询分解 把复杂问题拆成多个子问题，分别检索 适合多跳问题 这一步的权衡 查询变换提高了召回率（覆盖了查询的不同侧面），但代价是：\n可能偏离原始意图——改写后的查询抓住了相关的 false positive，漏掉了真正的目标 LLM 调用成本——每次查询变换都多了一次 LLM 调用 延迟增加——Multi-Query 让一次检索变成 3-5 次 这是 PR 矛盾的第一层应对：用算力换召回率。\n第二步：元数据预过滤（Metadata Pre-filtering） 纯向量检索在生产环境中已经没人用了。\n你的知识库有各种属性——时间范围、文档来源、领域、权限级别。如果不在向量检索之前用这些属性做预过滤，你的向量搜索就会在一个巨大的、大部分不相关的空间里找相似度。\nPinecone、Weaviate、Qdrant 的生产指南里有一条共识：先过元数据，再过向量。\n典型实现 查询: \u0026#34;2026年Q1的项目报告\u0026#34; 过滤: date \u0026gt;= 2026-01-01 AND date \u0026lt;= 2026-03-31 AND type = \u0026#34;project_report\u0026#34; 向量检索: 在过滤后的子集里做 top-k 这一步的权衡 预过滤大幅提高精度（把搜索空间缩小到真正相关的子集），但代价是：\n如果过滤条件太激进，召回率会骤降——你过滤掉了你以为是无关、但实际上相关的内容 预过滤 vs 后过滤的永恒争议：先过滤再向量搜索（丢失潜在匹配）vs 先向量搜索再过滤（浪费算力在不相关的结果上） 两个过滤器之间的：元数据过滤掉的文档，向量搜索不会看到 这是 PR 矛盾的第二层应对：用先验知识减少搜索空间。\n第三步：混合检索 + RRF（Hybrid Search + Reciprocal Rank Fusion） 纯稠密检索（Dense Retrieval）和纯稀疏检索（BM25）各有缺陷：\n检索方式 强项 弱项 稠密检索（Embedding） 语义匹配 丢失精确关键词匹配，受嵌入质量影响 稀疏检索（BM25） 精确关键词匹配 无法处理同义、近义表达 工业界的答案是：两个都做，然后把结果融合。\nReciprocal Rank Fusion（RRF） RRF 的公式极其简单：\nscore(d) = Σ 1 / (k + rank(d)) 对每个文档，取它在两种检索方式中的排名，加起来算一个综合分数。k 是一个平滑常数，通常取 60。\n这一步的权衡 混合检索在召回率上有明显的提升（5-15% 的 recall@10 改善），但代价是：\n两个索引都要维护——稠密索引 + 稀疏索引，存储翻倍 RRF 权重难调——k 值、稠密 vs 稀疏的权重比例，对不同的领域和查询类型有不同的最优值 两个引擎都可能出问题——一个引擎的失败结果会通过 RRF 污染最终排名 这是 PR 矛盾的第三层应对：用多个正交的检索信号互相补充。\n第四步：小 Chunk 检索（Small Chunk Retrieval） 这是整个流水线里最微妙的一步。\n你面临一个根本性的矛盾：\nChunk 大小 嵌入精度 上下文完整性 小（~200 tokens） 高——每段聚焦一个主题，嵌入向量干净 低——切碎了语义边界 大（~1000 tokens） 低——一段包含多个主题，嵌入向量的平均化稀释了语义 高——保留了上下文 Anyscale 在 2023 年做了一个有影响力的实验：把 chunk_size 从 100 逐步增加到 900，观察检索分数和生成质量的变化。\n结果是两条方向相反的曲线：\n检索分数单调递增——更大的 chunk 更容易被命中（里面有更多关键词） 生成质量先升后降——在 300-500 tokens 达到峰值，之后更多的上下文开始引入噪声 工业界的共识 小 chunk 用于检索，大 chunk 用于阅读。\n具体来说：嵌入和检索用 256-512 tokens 的小 chunk（保证精度），检索到之后把整个 parent document 或相邻 chunk 一起拉上来送给 LLM。\n这被称为 \u0026ldquo;small-to-retrieve, big-to-read\u0026rdquo; 模式。\n这一步的权衡 小 chunk 让检索精度大幅提升，但引入了一个新的复杂度：你需要额外维护 chunk ↔ parent 的映射关系，且 chunk 边界的切割永远会破坏一些语义边界。\n这是 PR 矛盾的第四层应对：把\u0026quot;检索\u0026quot;和\u0026quot;阅读\u0026quot;解耦，让它们用不同的粒度。\n第五步：上下文展开（Context Expansion） 第四步检索到的是小 chunk。但单独把小 chunk 扔给 LLM 是不够的——它只看到了切片，看不到上下文。\n上下文展开的做法是：拿到命中的小 chunk 后，把它的邻居 chunk 或 parent 文档一起带上来。\n实现方式 SentenceWindowRetrieval：命中一个句子，拉它前后 N 个句子作为上下文窗口 ParentDocumentRetriever：命中一个子 chunk，拉对应的父文档 Sliding Window：把 chunk 边界滑动一下，重新拼接上下文 这一步的权衡 展开把精度↔完整性的天平往回拉了拉——你放弃了部分精度，换回了上下文。但展开范围越大，你重新引入了多少噪声就越不可控：\nchunk 精度: 高 展开后: 上下文完整了，但噪声回来了 这是 PR 矛盾的第五层应对：用\u0026quot;检索精度换阅读完整性\u0026quot;.\n第六步：重排序（Re-ranking） 前五步产出的结果是一堆\u0026quot;roughly 相关\u0026quot;的候选。它们之间的相关性差异很小，而向量相似度在这个阶段已经丧失了分辨力。\nReranker（通常是一个交叉编码器）把 query 和每个候选文档配对，算一个精确的相关性分数。\n效果 方案 精度提升 不加 Reranker 基线 加 Cross-encoder Reranker +5-15pp nDCG（在 BEIR 基准上） Cohere Rerank、BGE-Reranker 是生产中最常用的选择。\n这一步的权衡 Reranker 是目前最有效的精度提升手段，但它有一个你不能忽视的限制：\n它不能挽救没有被前面步骤命中到的文档。\nReranker 做的是\u0026quot;从候选里挑出最相关的\u0026quot;，候选名单在上一步就已经定了。如果前面六步都没有命中那个真正相关的文档，Reranker 也帮不了你。\nReranker 提高精度，召回率天花板由前序步骤设定。\n另外，交叉编码器比双编码器慢 2-5x。\n这是 PR 矛盾的第六层应对：用更多的算力（交叉编码）换取精度，但承认召回率的天花板已经定了。\n第七步：LLM 生成 最后一步，把前六步精挑细选出来的上下文送给 LLM，让它生成答案。\n这一步本身也能做一些事情来管理 PR 矛盾：\n系统提示约束：明确告诉 LLM\u0026quot;如果检索到的内容不足以回答，请说不知道\u0026quot; 引用锚定（Citation Anchoring）：要求 LLM 在回答的每个关键事实后面注明来源 chunk 置信度声明：如果模型的回答基于不充分的检索结果，要求它声明不确定性 这一步的权衡 这一步的约束越严格，精度越高（更少幻觉），但用户可能得到更多\u0026quot;我不知道\u0026quot;的回复——这是用用户满意度换精度。\n这是 PR 矛盾的第七层应对：用生成时的约束来兜底。\n全景：七步的得失 把七步串起来，每一层的权衡一目了然：\n步骤 主要 tradeoff 状态 查询变换 召回率 ↑ / 意图偏离风险 ↑ 生产标配 元数据过滤 精度 ↑ / 过滤过头则召回率骤降 生产标配 混合检索 + RRF 召回率 ↑ / 维护成本 ↑ / 权重难调 生产标配 小 chunk 检索 精度 ↑ / 上下文完整性 ↓ 生产标配 上下文展开 完整性 ↑ / 噪声回归 生产标配 重排序 精度 ↑ / 延迟 ↑ / 召回率天花板已定 生产标配 LLM 生成约束 精度 ↑ / 用户满意度 ↓ 按需采用 每一个步骤都引入了一个新的 tradeoff，下一个步骤又来部分弥补这个 tradeoff。整个流水线不是在解决问题，而是在不断转移问题。\n局限：七步之后，矛盾仍在 必须坦诚地说：即使走了七步，PR 矛盾也没有被消灭。\nQuery 理解是根本瓶颈——如果你的查询本身就是模糊的，整个管道的上限就定死了 Chunk 边界永远在丢失信息——无论切多小，信息的连续性都会在切割点中断 递归检索没有好的停止条件——搜了一次觉得不够，再搜一次，什么时候该停？ 新鲜度检测没人做好——系统无法可靠判断检索到的信息是否已经过时 工业界的七步流水线是一个\u0026quot;足够好\u0026quot;的方案，不是一个\u0026quot;解决了问题\u0026quot;的方案。\n结论：管理矛盾，而不是解决矛盾 Precision-Recall 矛盾不是一个 bug，是一个 feature——它是检索式记忆系统在数学层面的固有属性。你不可能消除它，就像不可能消除重力。\n但你可以在重力存在的情况下建房子。七步流水线就是那个房子。\n每一步都在做权衡，每一步都在承认矛盾没有被消除。但这个管道叠加起来，把 PR 矛盾压到了一个工程上可接受的范围内，让生产系统能够稳定运行。\n如果你在做 RAG 或 Agent 记忆系统，我的建议是：\n先走完前六步，看看效果。大部分人走到第三步就觉得够了。 在每一步记录你的权衡。 清楚你在哪里丢了精度、哪里丢了召回率。 接受\u0026rsquo;足够好\u0026rsquo;。 追求完美的 PR 平衡会让你走进死胡同。 回到上一篇的核心论点：记忆系统有用，但它有天花板。七步流水线就是工业界在天花板之下能找到的最佳实践。\n理解了这个框架，你就理解了为什么 Harness 工程（工具设计、反馈质量、状态控制）可能是比记忆系统更大的杠杆——因为你在七步之内能做的最大的改变，往往不在检索这一步。\n","date":"2026-05-01T00:00:00Z","permalink":"/post/rag-seven-step-pipeline/","title":"生产环境 RAG 的七步流水线：PR 矛盾没被解决，只是被管理了"}]