Ai-Agent学习历程------ Agent认知框架
- 文章介绍
- 一、Agent认知框架的概念
-
- [1.1 什么是Agent认知框架](#1.1 什么是Agent认知框架)
- [1.2. 核心组件](#1.2. 核心组件)
-
- [A. 记忆模块 (Memory) - "经验的积累"](#A. 记忆模块 (Memory) - “经验的积累”)
- [B. 规划模块 (Planning) - "三思而后行"](#B. 规划模块 (Planning) - “三思而后行”)
- [C. 工具使用 (Tools / Action) - "手和脚"](#C. 工具使用 (Tools / Action) - “手和脚”)
- [D. 角色画像 (Profile / Persona) - "我是谁"](#D. 角色画像 (Profile / Persona) - “我是谁”)
- [3. 主流的`认知运行模式`](#3. 主流的
认知运行模式) -
- [① CoT (Chain of Thought,思维链)](#① CoT (Chain of Thought,思维链))
- [② ReAct (Reason + Act,推理与行动)](#② ReAct (Reason + Act,推理与行动))
- [③ TOT / GOT (Tree/Graph of Thoughts,思维树/图)](#③ TOT / GOT (Tree/Graph of Thoughts,思维树/图))
- 二、所有的Agent认知框架
-
- [2.1 基础推理与行动模式](#2.1 基础推理与行动模式)
-
- [(1)COT------Chain of Thought:思维链](#(1)COT——Chain of Thought:思维链)
- [(2)ReAct------Reasoning + Acting:推理+行动](#(2)ReAct——Reasoning + Acting:推理+行动)
- (3)Self-Ask:自问自答
- [(4)COC------Chain Of Code:代码链](#(4)COC——Chain Of Code:代码链)
- (5)Step-Back
- 各个认知模型的对比
- [2.2 规划与执行优化模式](#2.2 规划与执行优化模式)
-
- [(1) Plan-and-Execute: 计划与执行](#(1) Plan-and-Execute: 计划与执行)
- [(2) ReWOO------Reason without Observation:无观察推理](#(2) ReWOO——Reason without Observation:无观察推理)
- [(3) LLMCompiler: 并行执行编译器](#(3) LLMCompiler: 并行执行编译器)
- [(4) BabyAGI: 任务循环机制](#(4) BabyAGI: 任务循环机制)
- [(5) HuggingGPT: 模型控制器(必须了解,没必要上手实践)](#(5) HuggingGPT: 模型控制器(必须了解,没必要上手实践))
- [(6) AgentExecutor: 运行时执行器](#(6) AgentExecutor: 运行时执行器)
- [2.3 高级搜索与决策模式](#2.3 高级搜索与决策模式)
-
- [(1) ToT ------Tree of Thoughts: 思维树](#(1) ToT ——Tree of Thoughts: 思维树)
- [(2) GoT ------Graph of Thoughts: 思维图](#(2) GoT ——Graph of Thoughts: 思维图)
- [(3) LATS------Language Agent Tree Search: 树搜索代理](#(3) LATS——Language Agent Tree Search: 树搜索代理)
- [(4) SwiftSage: 双系统思考](#(4) SwiftSage: 双系统思考)
- [2.4 反思与修正模式 (Reflection & Correction)](#2.4 反思与修正模式 (Reflection & Correction))
-
- [(1) Reflexion: 语言反馈强化](#(1) Reflexion: 语言反馈强化)
- [(2) Self-RAG: 自我检索增强](#(2) Self-RAG: 自我检索增强)
- [(3) CRITIC: 外部验证](#(3) CRITIC: 外部验证)
- [(4) Thinking & Reflection: 基础反思](#(4) Thinking & Reflection: 基础反思)
- 对比
- [2.5 记忆与社会化协作模式](#2.5 记忆与社会化协作模式)
-
- [(1) Generative Agents: 生成式智能体](#(1) Generative Agents: 生成式智能体)
- [(2) MetaGPT: 多智能体 SOP](#(2) MetaGPT: 多智能体 SOP)
- [(3) Voyager: 终身学习者](#(3) Voyager: 终身学习者)
- [(4) MemGPT: 操作系统式记忆](#(4) MemGPT: 操作系统式记忆)
- 三、Agent认知框架总结(重点!!!)
-
- 一、不同框架的实用性
- 二、应用范围与未来趋势
- 三、不同Agent是否可以互相配合
- [四、LangChain/LangGraph 是否可以达到企业级需求](#四、LangChain/LangGraph 是否可以达到企业级需求)
- [五、市面上的 Agent 底层](#五、市面上的 Agent 底层)
文章介绍
上一章节我们初步认识了Agent构建的过程,运行基本原理等,要想深度学习Agent,我们得对Agent的整体发展方向有个基本的人认识,不然光学习技术,没有系统的认知架构是不行的,所以这一章节我们将针对Agent的认知框架展开来讲讲,之后就可以正式的步入Agent的代码学习世界了。
你可以理解为你现在初入大宗门 ,拥有一腔热血和所谓的真本事,虽然要大展拳脚,但在这之前还是得了解一下宗门的发展史 ,现在主要的功法都有哪些,你好方便战斗和学习啊。所以我选择去荒殿,因为那里有:"大荒芜经"。
一、Agent认知框架的概念
💡 思考:在最开始人工智能发展的时候都是LLM模型为主 ,但无论怎么发展,它所输出的结果无非就是文字,更厉害点的就是图片,在厉害点的就是视频,总的来说就只是一个大脑,没有手脚和身体。所以后面衍生出了Agent这个概念,给LLM模型加上了手脚身体,可以像人一样独立思考和办事儿。
那你说认知框架又该怎么理解呢?
你这么想,人的职业是不是分为很多种,每一个职业是不是都有它擅长的方向,干不同职业的人是不是都有其独立或者特殊的思考方式和处理事情的习惯,而Agent的认知框架就完美的对应了这个点,人的职业可以分为老师、医生、消防员,那Agent也可以分为很多种。
1.1 什么是Agent认知框架
核心定义 :Agent认知框架是一种系统架构,它赋予了大模型(LLM)类似于人的认知能力,通过编排提示词(prompt)、记忆存储、工具调用和流程控制,让LLM模型能够完成复杂的、多步骤的任务,在过程中还可以自行调整。
公式化理解 :
A g e n t = L L M (大脑) + M e m o r y (记忆) + P l a n n i n g (规划) + T o o l s (工具 / 行动) Agent = LLM(大脑) + Memory(记忆) + Planning(规划) + Tools(工具/行动) Agent=LLM(大脑)+Memory(记忆)+Planning(规划)+Tools(工具/行动)
1.2. 核心组件
一个完整的 Agent 认知框架通常包含以下四个关键模块,它们共同构成了 Agent 的"心智":
A. 记忆模块 (Memory) - "经验的积累"
Agent 需要记住之前发生的事情,就像人有短期记忆和长期记忆。
- 短期记忆 (Short-term Memory): 利用 LLM 的上下文窗口 (Context Window),记住当前的对话历史和即时指令。
- 长期记忆 (Long-term Memory): 类似于人的海马体。通常使用向量数据库 (Vector Database) 实现。Agent 可以将过去的经验、文档、知识库存储起来,在需要时通过检索 (RAG) 调取,从而跨越漫长的时间线保持"连贯性"。
B. 规划模块 (Planning) - "三思而后行"
面对复杂任务(例如"帮我写一份市场调研并生成PPT"),Agent 不能直接瞎干,需要规划。
- 任务拆解 (Decomposition): 将大目标拆解为一个个可执行的小步骤(Sub-goals)。例如:上网搜索 -> 阅读数据 -> 总结要点 -> 生成大纲 -> 制作PPT。
- 反思与修正 (Reflection & Self-Correction): Agent 在执行过程中会"自我反省"。如果第一步搜索结果不理想,它会思考"我是不是关键词错了?",然后尝试修正计划。
C. 工具使用 (Tools / Action) - "手和脚"
LLM 只是一个文本生成器,无法直接联网或操作电脑。工具模块赋予了它行动力。
- Function Calling / Plugins: 让 Agent 可以调用外部 API(如谷歌搜索、计算器、天气接口、Jupyter 代码解释器)。
- 操作环境: 甚至可以直接控制浏览器、操作 Excel 或读写文件。
D. 角色画像 (Profile / Persona) - "我是谁"
定义 Agent 的身份、性格、职业背景和行为准则。
- 例如:"你是一个资深的 Python 工程师,性格严谨,只输出代码,不废话。"这
决定了 Agent 的认知基调。
3. 主流的认知运行模式
为了让 Agent 思考得更像人,业界发展出了几种经典的思维框架(提示词工程策略):
① CoT (Chain of Thought,思维链)
- 原理: 强迫模型在给出答案前,先展示推理步骤。
- 例子: 不直接问"这个数学题答案是多少",而是说"请一步步推理并计算"。这显著提高了复杂逻辑的准确率。
② ReAct (Reason + Act,推理与行动)
- 原理: 这是目前最主流的框架。Agent 按照 "观察 (Observation) -> 思考 (Thought) -> 行动 (Action)" 的循环来工作。
- 流程:
- 用户指令:"查一下今天谁是NBA得分王。"
- 思考: 我需要查即时体育新闻。
- 行动: 调用 Google Search API。
- 观察: 收到搜索结果。
- 思考: 结果显示是库里,得到40分。
- 回答: 输出最终答案。
③ TOT / GOT (Tree/Graph of Thoughts,思维树/图)
- 原理: 让 Agent 同时发散出多种解决路径,自行评估哪条路径最好,类似人类的"头脑风暴"和"决策树"。
二、所有的Agent认知框架
💡 先来整体看一下目前所有的Agent认知模型,之后我们根据分类详细讲解。
| 序号 | 框架名称 | 核心分类 | 一句话逻辑 | 典型应用场景 |
|---|---|---|---|---|
| 1 | ReAct | 推理与行动 | 思考-行动-观察 的单步循环 | 通用助手、API调用 |
| 2 | AgentExecutor | 推理与行动 | ReAct 的工程化运行时(带日志/容错) | 生产环境标准 Bot |
| 3 | Plan-and-Execute | 规划与执行 | 先列出所有计划,再逐个执行 | 长任务、复杂流程处理 |
| 4 | Self-Ask | 基础推理 | 把大问题拆成子问题,自问自答 | 多跳问答(谁是XX的母亲) |
| 5 | Thinking & Reflection | 反思与修正 | 简单的"生成后检查"步骤 | 提高回答准确度的基础手段 |
| 6 | CoT (Chain of Thought) | 基础推理 | 强制输出"让我们一步步思考" | 数学题、逻辑推理 |
| 7 | ReWOO | 规划与执行 | 规划与执行分离,填空式调用 | 追求极速、省 Token |
| 8 | LLMCompiler | 规划与执行 | 像编译器一样并行处理任务 | 高并发工具调用、实时系统 |
| 9 | BabyAGI | 规划与执行 | 任务列表的无限生成与优先级排序 | 开放式目标探索、自主调研 |
| 10 | ToT (Tree of Thoughts) | 搜索与决策 | 生成多条路径,树状搜索最优解 | 创意写作、数独、复杂策略 |
| 11 | GoT (Graph of Thoughts) | 搜索与决策 | 思维节点可合并、循环的网状结构 | 极其复杂的头脑风暴、逻辑网 |
| 12 | LATS | 搜索与决策 | 思维树 + 蒙特卡洛搜索 + 反思 | 目前最强推理、代码生成 |
| 13 | Reflexion | 反思与修正 | 失败 -> 生成教训 -> 存入记忆 -> 复用 | 刷题 Bot、代码自动修复 |
| 14 | Self-RAG | 反思与修正 | 生成时自我打分(相关性/有用性) | 严谨知识库问答、减少幻觉 |
| 15 | CRITIC | 反思与修正 | 调用工具(如谷歌)验证自己的话 | 新闻核查、事实验证 |
| 16 | Generative Agents | 记忆与社会 | 记忆流:检索+反思+规划 | 拟人 NPC、社会模拟 |
| 17 | MemGPT | 记忆与社会 | 像操作系统一样管理上下文分页 | 无限长文档阅读、长期伴侣 |
| 18 | MetaGPT (SOP) | 记忆与社会 | 角色扮演 + 标准作业程序 (SOP) | 软件工程、自动化产研 |
| 19 | Voyager | 记忆与社会 | 自动写代码作为技能并存入库 | 游戏通关、持续学习 Agent |
| 20 | Chain of Code | 基础推理 | 遇事不决写代码,用代码代替推理 | 数学计算、逻辑模拟 |
| 21 | SwiftSage | 搜索与决策 | 快思考(直觉) + 慢思考(规划) 双系统 | 既要反应快又要逻辑深的任务 |
| 22 | HuggingGPT | 规划与执行 | LLM作控制器,分发任务给小模型 | 多模态任务(处理图/文/音) |
2.1 基础推理与行动模式
💡 这部分是 Agent 最底层的思维方式,记着,这些都是祖师爷。
(1)COT------Chain of Thought:思维链
🔍 定义 :CoT 是 Google 团队在 2022 年提出的概念,被视为大模型涌现能力的"解锁键 "。它的核心在于打破了模型"输入 -> 直接输出"的黑盒模式,强制要求模型将推理过程显性化。
🔍 机制:
- System 1 vs System 2 : 借用心理学《思考,快与慢》的概念,普通的 LLM 回答是"快思考"(直觉),CoT 强迫 LLM 进入"慢思考"(逻辑)。
- 中间推理步骤 : 它通过在提示词中加入示例(Few-Shot)或简单的一句 Let's think step by step(Zero-Shot),诱导模型生成一系列逻辑环节,从而大幅降低计算错误和逻辑谬误。

应用现状与场景:
- 核心场景: 数学应用题、常识推理、符号操作、复杂逻辑判断。
- 现有产品/应用
- 所有主流 LLM 基座: GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro。现在这些模型内部已内化了 CoT,即使你不提示,它们也会倾向于解释。
- Prompt Engineering 基础: 它是所有提示词工程的必修课。
- 扩展 :
CoT 的变体 CoT-SC (Self-Consistency) 更加强大,即让模型进行多次 CoT 推理 ,然后取出现频率最高的答案(类似于"三个臭皮匠顶个诸葛亮"),这在数学竞赛级题目中是标配。 - 思考 :在最开始我们使用LLM模型的时候(如Deepseek),都有一个
深度思考的选项,其实这个深度思考选项就是COT的最佳应用,摆脱了直接预测的模式,我们可以在页面上清晰的看出模型思考的过程,当然肯定不只是COT,大概率是COT-SC或者TOT又或者是多种类似认知框架的结合,给出我们最佳的答案。
(2)ReAct------Reasoning + Acting:推理+行动
🔍 定义 :普林斯顿大学与 Google 提出的框架。CoT 只是在脑子里想,ReAct 则是脑手结合 。它是 Agent 能够使用工具的理论基础。
🔍 机制:
ReAct引入了一个循环闭环,打破了LLM静态认知限制:
- Input(输入):用户输入需求
- Thought(思考):面对目标或需求,应该干什么
- Action / Final Answer (行动):
- 调用具体的工具和API
- 如果已经有答案了则生成Final Answer(用于已经多次循环的场景)
- Observation(观察):查看工具返回的结果并评估
- Repeat(重复):根据观察的结果评判是否需要再次进行循环或者下一步

应用现状与场景:
-
场景:这是一个通用的Agent解决框架,很多领域中都有涉及,毕竟是大哥中的大哥,尤其是要利用工具获取实时的外部信息或者需要操作外部的软件,读取外部的文件信息等场景。
-
现有产品/应用:
- LangChain: ReAct 是 LangChain 中 AgentType.REACT_DOCSTORE 或 ZERO_SHOT_REACT_DESCRIPTION 的核心逻辑。
- ChatGPT (Plus/Team): 当你使用"浏览"或"DALL-E 3"功能时,系统内部就在运行 ReAct 循环(思考->生成Python代码/搜索->执行->反馈)。
- AutoGPT / BabyAGI :
早期的自主 Agent 明星项目,本质上是无限循环的 ReAct。
-
思考 :如果用过Cursor或者类似的
编程Ai IDE的同学或许能发现,在它们的处理过程中你会发现在不断的进行修正,有时候过程中就会蹦出来"我似乎误解了用户的意思 "或者说"我感觉这里不对"的提示器,这本质上就是ReAct的循环。当然,类似这种高级的Agent不可能只是用ReAct框架,只是说核心是它。
(3)Self-Ask:自问自答
🔍 定义 : 针对"多跳问题"(Multi-hop Questions)设计的策略。很多复杂问题无法一次搜索得到答案,必须拆解。
🔍 机制:
模型明确地问自己:"为了回答这个问题,我需要先知道什么?"
- 它不直接回答最终问题,而是生成一个Follow-up Question(追问)。
- 搜索这个追问的答案。
- 利用这个中间答案,继续追问或回答原问题。
- 核心差异: 相比于
CoT 的隐式推理,Self-Ask 是显式的信息检索策略。
基于上述的官方回答,我提出了四点问题,帮助我们更好的理解Self-ask模型。
问题1:什么是"多跳问题"?
多跳问题是指
无法通过一次查询直接得到答案,必须经过"A 推导出 B,再由 B 推导出 C"的中间步骤才能解决的问题。就像跳石过河一样,你不能一步跳到对岸,必须踩着中间的石头(中间答案)过去。
- 单跳问题 (Single-hop):
- 问题:"周杰伦的妻子是谁?"
- 动作:直接搜"周杰伦 妻子"。
- 答案:昆凌。
- (只需要一步,直接命中)
- 多跳问题 (Multi-hop):
- 问题:"周杰伦妻子的出生地现在的市长是谁?"
- 动作 :
- 第一跳: 先查"周杰伦的妻子是谁?" -> 得到中间答案:昆凌。
- 第二跳: 再查"昆凌的出生地是哪里?" -> 得到中间答案:台北市。
问题2:为什么说 CoT 是"隐式推理"?
这里的"隐式"和"显式"是相对于"外部世界"而言的,外部世界就是排除Agent都算外部。
- CoT (思维链) 的逻辑 :
- 场景: 考试时,你闭着眼睛,仅凭脑子里的记忆进行推导。
- 过程: 模型利用训练时学到的内部权重(内部知识库),在生成的文本中一步步写出逻辑。
- 为什么叫"隐式"? 因为这种推理完全
发生在模型内部(Context 窗口内)。它没有与外界交互,没有去查证。如果模型脑子里记错了(比如它记错昆凌出生在高雄),它的推理逻辑再完美,结果也是错的(幻觉)。它的推理过程是对外部不可见的黑盒知识的调用。
- Self-Ask 的逻辑 :
- 场景: 考试时,你允许使用搜索引擎。
- 过程: 模型明确地列出"我下一步要去查什么",然后真的去查,拿到结果后再进行下一步。
- 显式 : 它的推理步骤转化为了
可见的、可执行的搜索动作。
问题3:什么是信息检索策略?
"信息检索策略"就是**把一个模糊的大问题,翻译成搜索引擎能听懂的、精确的关键词序列"**的能力。
- 没有策略 (普通用户):
- 直接把整个长难句扔给百度/Google:"周杰伦妻子的出生地现在的市长是谁"
- 结果: 搜索引擎可能会懵,或者返回一堆乱七八糟的新闻,准确率低。
- Self-Ask 策略 (Agent):它会生成一个结构化的Follow-up (追问) 序列:
- Follow-up: Who is Jay Chou's wife? (检索策略:实体识别)
- Intermediate Answer: Hannah Quinlivan (昆凌)
- Follow-up: Where was Hannah Quinlivan born? (检索策略:属性提取)
- Intermediate Answer: Taipei, Taiwan
- Follow-up: Who is the current mayor of Taipei? (检索策略:时效性查询)
- Final Answer: Chiang Wan-an
💡 从上述的观察我们可以清晰的发现,Agent的出现彻底颠覆了正常的搜索策略,之前我们是在一堆数据汪洋中寻找我们需要的答案,而Agent则是直接把桌子掀了,精准定位出具体答案,虽然可能不是100%准确,但比起传统的方式已经节省了大部分的时间了。
问题4:Self-ask是不是应用于理解长难句的场景较多?
很遗憾答案为:半对半错,有一部分情况下可以是上述场景。
对的地方 :由于其自问自答的特性,它能将用户所提出的长难句分解为小问题,能更加精确的理解用户复杂的需求。
错的地方 :它的设计之初不是为了拆解问题的,而是为了"事实核查"和"填补知识空缺",也就是寻找一个问题的答案,而上面的场景更多是工具性质的拆解。
假设我们的提问中没有关于任何事实的查询和知识的询问,只是一些个人情感的描述和一些场景的描述,那COT无疑是最好的选择,如果类似于上面的知识问答(杰伦),那Self-ask就占优势了。
再思考 :如果我的提问是上面场景中的一半一半呢?那这时候就轮到ReAct喽,ReAct本质上就是COT和Self-ask的结合体,所以呢,这也是ReAct能站在世界之巅的原因之一。
| 维度 | CoT (思维链) | Self-Ask (自问自答) |
|---|---|---|
| 面对复杂问题时 | 闭眼思考,调用脑子里的记忆 | 拿起手机,打开 Google/百度 |
| 推理方式 | 隐式推理 (Internal Reasoning) | 显式检索 (Explicit Retrieval) |
| 解决什么痛点 | 解决逻辑差的问题 (数学/常识) | 解决不知道、多跳逻辑的问题 |
| 是否联网 | 通常不需要 (纯 LLM) | 必须联网 (LLM + Search Tool) |

(4)COC------Chain Of Code:代码链
🔍 定义 : 由 Google DeepMind 提出。其核心洞察是:大语言模型在模拟"代码解释器"时的逻辑能力,强于纯文本推理能力。
🔍 机制 :当遇到逻辑 、数学 或算法问题时,Agent 不再用自然语言写"因为...所以...",而是:
- 编写
伪代码或可执行代码(Python) 来描述问题。 - 模拟执行(让 LLM 脑补代码运行结果)或
物理执行(真的在解释器里跑)。 - 利用代码的
结构化特性,规避语言逻辑陷阱。
应用现状与场景
- 场景:复杂的数学计算、逻辑谜题、字符串处理、模拟仿真
- 应用 :主流应用还是编程Agent例如
Cursor等。 - 思考 :COC的出现证明了
编程语言是更加严格的思维载体。

(5)Step-Back
🔍 定义 :由 Google DeepMind 提出。灵感来源于人类解决难题时的直觉------"退一步海阔天空"。
🔍 机制 :LLM 在回答具体细节问题时容易钻牛角尖或产生幻觉。Step-Back 要求模型:
- Abstraction (抽象): 先不看具体问题,而是提取出问题背后的
高层概念、物理定律或历史背景。 - Reasoning (推理): 基于这个高层原理进行思考。
- Application (应用): 将原理应用回具体问题,得出答案。
应用现状与场景:
- 场景:物理/化学/生物题(STEM 教育)、法律咨询(寻找法条依据)、避免特定细节的幻觉。
- 应用:
- 教育类 AI Agent (如 Khan Academy 的 Khanmigo): 在辅导学生时,不会直接给答案,而是先
引导学生思考"这属于哪个公式?",这运用了 Step-Back 的思想。 - 高级 RAG 系统: 在检索文档前,先生成一个"高层上下文",用这个高层概念去检索,往往能召回更准确的文档(HyDE 本质上也类似这种思路)。
- 教育类 AI Agent (如 Khan Academy 的 Khanmigo): 在辅导学生时,不会直接给答案,而是先

扩展一下"
只见树不见森林"的概念
- "树木" (Trees) = 题目中具体的、细碎的细节(具体的数字、特定的人物、复杂的条件限制)。
- "森林" (Forest) = 支配这些细节背后的"底层原理"、"通用公式"或"宏观背景"。
当你给大模型一个很具体的难题时,模型的第一反应往往是直接拿题目里的关键词去匹配答案。它会试图直接把题面里的 A、B、C 拼凑出一个结果。
这时候,模型就像一个为了做题而做题的学生:
- 它盯着题目里的数字(树木),拼命想用加减乘除把它们连起来。
- 它忘记了这道题其实是在考一个物理定律,或者一段历史背景(森林)。
- 结果: 它的逻辑就在细节里打转,很容易掉进"逻辑陷阱"或者产生幻觉。
Step-Back Prompting 的核心机制是强制模型在回答问题之前,先"后退一步"(Step Back) ,去问一个更宏观、更抽象的问题。
具体的执行逻辑:
- 原始问题(看树木): "如果把 50 度的水倒进 20 度的水里,体积是通过什么公式变化的?"(注:这是一个误导性的细节问题)
- 后退一步(看森林): 哪怕不看这道具体的题,涉及到的物理原理是什么? (Step-Back Question)
- 模型回答: "涉及热力学原理和理想液体混合的体积变化特性。"
- 再看原题(带着森林看树木): 基于这个原理,再来回答刚才的问题。
直观案例对比
案例一:物理/数学题(最典型)
题目:
"在一个标准大气压下,如果我把温度从 1 0 ∘ C 10^\circ\text{C} 10∘C 升高到 2 0 ∘ C 20^\circ\text{C} 20∘C,气体的体积会变成原来的 2 倍吗?"
-
❌ 只见树木(普通思维):
- 模型盯着数字: 10 10 10 和 20 20 20。
- 线性直觉: 20 20 20 是 10 10 10 的 2 2 2 倍。
- 错误推理: "是的,因为温度翻倍了,所以体积也翻倍。"
- (模型迷失在了具体的数字"树木"里,忘记了背后的物理定律。)
-
✅ 见森林(Step-Back 思维):
- Step 1 (后退): 先别管 10 10 10 度还是 20 20 20 度。这就题涉及什么物理定律?
- Abstraction (抽象原理): 涉及"查理定律"(理想气体定律)。公式是 V 1 / T 1 = V 2 / T 2 V_1/T_1 = V_2/T_2 V1/T1=V2/T2。注意:这里的 T T T 必须是绝对温标(开尔文),而不是摄氏度。
- Step 2 (推理): 现在把数字代进去。
- 1 0 ∘ C = 283 K 10^\circ\text{C} = 283\text{K} 10∘C=283K
- 2 0 ∘ C = 293 K 20^\circ\text{C} = 293\text{K} 20∘C=293K
- 293 / 283 ≈ 1.035 293 / 283 \approx 1.035 293/283≈1.035 倍。
- 正确答案: "不会变成 2 倍,只会增加一点点。"
总结: 如果不后退一步去思考"绝对温标"这个森林(原理) ,就会被"10和20"这两个树木(细节) 骗得团团转。
案例二:历史/事实核查
题目:
"Estella Leopold(一位古生物学家)在 1995 年 8 月至 1999 年 11 月期间去过哪所学校?"
-
❌ 只见树木(普通思维):
- 模型开始在大脑里搜索"Estella Leopold"和"1995-1999"这两个关键词的交集。
- 如果在训练数据里找到一些类似的碎片,它可能会幻觉编造一个学校名字,因为它觉得"必须要回答一个学校"。
-
✅ 见森林(Step-Back 思维):
- Step 1 (后退): 先别管这个具体的时间段。Estella Leopold 的教育背景和生平简历是怎样的?
- Abstraction (宏观背景): 她出生于 1927 年,1955 年就在耶鲁拿到了博士学位,之后一直在大学任教,并没有在 90 年代去上学。
- Step 2 (推理): 基于这个简历(森林),她在 1995 年已经是快 70 岁的老教授了。
- 正确答案: "这个问题的前提可能错了,她在那个时间段并没有'去上学',而是在任教或已退休。"
| 维度 | 普通 Prompt (只见树木) | Step-Back Prompt (先见森林) |
|---|---|---|
| 关注点 | 具体的数字、特定的人名、细节条件 | 背后的公理、物理定律、历史大背景 |
| 思维路径 | 细节 -> 细节 (容易跑偏) | 抽象原理 -> 细节 (高维打低维) |
| 你的困惑 | 为什么做不对?因为陷入了细节的陷阱 | 跳出来,找到"说明书"再回来解题 |
| 应用口诀 | "请直接回答..." | "涉及什么原理?" -> "基于该原理..." |
所以,Step-Back 中的"只见树不见森林",指的就是模型容易被 Prompt 中的具体细节(树)带偏节奏,而忘记了应用通用的逻辑法则(森林)来约束推理过程。
各个认知模型的对比
| 模式 | 核心隐喻 | 解决什么痛点? | 典型台词 |
|---|---|---|---|
| CoT | 慢思考 | 解决模型"凭直觉瞎猜"导致的逻辑跳跃。 | "Let's think step by step." |
| ReAct | 手眼协调 | 解决模型"纸上谈兵"无法与世界交互的问题。 | "I need to use a tool." |
| Self-Ask | 拆解师 | 解决模型面对复杂大问题"无从下手"的情况。 | "What follow-up questions do I need?" |
| CoC | 程序员思维 | 解决模型数学太差、逻辑不严谨的问题。 | "Let me write some code to solve this." |
| Step-Back | 哲学家思维 | 解决模型"只见树木不见森林"导致的错误。 | "What is the underlying principle here?" |
2.2 规划与执行优化模式
💡 这部分致力于解决"如何高效、正确地处理复杂长任务"的问题,侧重于流程的编排与效率。
在上面的基础模式中我们能发现一点,虽然它的原理和方式能帮我们解决大部分的问题,而且效率也是不错的,可是和
工业级别的模式来说略有不足,比如:稳定性、速度、任务编排、容错管理、场景兼容等等,所以"规划和执行优化"侧重的就是工业级别的流程编排和效率。
(1) Plan-and-Execute: 计划与执行
🔍 定义:这是一种将 大脑(规划)和手脚(执行) 解耦的模式
🔍 解决痛点 :标准的 ReAct 模式在执行长任务时,容易在第 5 步忘了第 1 步的目标(Context Window 限制或注意力发散)。
🔍 机制:
Planner(规划器): 不执行任何操作,只负责看清目标,生成一个包含步骤 1、2、3...N 的完整清单。Executor(执行器): 拿到清单,像傻瓜一样逐条执行,不需要思考大方向。Replanner(重规划器): (高级版特性) 如果第 3 步执行结果和预期不符,重新激活规划器,更新剩余的步骤。
如果用过Cursor的同学对这个模式可就太熟悉了,如果我们有一个非常复杂的需求,仅仅使用Agent模式是完全不够的,很容易出现结果不准或者脱离方向的情况,这就是上面所说的主要痛点,而Cursor中有一个plan模式完美的对应了这个认知框架,我们可以不断的修改计划,如果你的指令足够详细,可以让它在执行的过程中,每一步结束之后校验结果,如果不对及时更新计划或者终止。
应用现状与场景:
- 场景 :需要多步操作且步骤之间逻辑清晰的任务(如"帮我制定一个去日本的7天旅行计划并预定酒店")、深度调研报告
- 现有产品/应用:
- LangGraph (Plan-and-Execute Agent): LangChain 的新一代图编排框架,这是官方推荐的标准范式。
- AutoGPT (后期版本): 引入了明确的 plan 指令来锁定任务流。

(2) ReWOO------Reason without Observation:无观察推理
💡 规划时只生成占位符,执行时统一填空。以忽略中间观察为代价,换取极致的并行速度和 Token 节省。
🔍 定义: 一种追求极致速度和成本的规划模式。
🔍 机制:
- Planner: 一次性生成完整的推理蓝图(Blueprint)。对于还没查到的数据,使用变量占位符(如 , )代替。
- Worker: 平行地去执行所有工具调用,填充变量。
- Solver: 将填充好的数据代入蓝图,生成最终答案。
极大地节省了 Token(不需要反复把
中间结果喂给 LLM)和时间(工具并行)

应用现状与场景:
- 场景: 对实时性要求极高、步骤之间依赖性较弱的信息检索任务。
- 现有产品/应用 :
- LangChain (ReWOO Agent): 官方库中作为一种节省 Token 的策略存在。
- 企业级 RAG 系统: 为了降低 LLM 调用成本和延迟,后台常用类似 ReWOO 的逻辑预取数据。
🐛 看到这儿我们先思考两个问题:
📝 现有一个问题:查百度的股价和阿里的股价
问题1:什么是中间观察?
答案:"中间观察 " 是指 Agent 在执行任务过程中,每调用一次外部工具(如搜索、代码解释器、API),工具返回给 Agent 的那段具体内容/结果。
- 动作 1: Agent 决定去搜索"2023 US GDP"。
- 中间观察 1: 谷歌返回的文本段落:"According to the BEA, U.S. GDP in 2023 was $27.36 trillion..."
- 动作 2: Agent 决定去搜索"2023 China GDP"。
- 中间观察 2: 谷歌返回的文本段落:"China's GDP for 2023 was reported as 126 trillion yuan (approx $17.7 trillion)..."
为什么叫"中间"?
- 因为这些信息本身不是最终答案,只是通往答案路上的线索片段。在 ReWOO 中,规划阶段(Planner)是看不到这些具体数字的,它只能预测这里会有一个结果。
问题2:中间结果为什么要"反复喂给 AI"?
⚠️ 这是传统 ReAct 模式(即 ReWOO 的对立面)最大的痛点。
核心原因 :LLM 是"无状态"且"线性"的
大模型(LLM)像一条金鱼,它记不住上一轮对话发生了什么,除非你把之前的对话记录全部打包,重新发给它 。而且,在 ReAct 逻辑中,第 2 步怎么走,完全取决于第 1 步看到了什么。是不是学到了一个省Token的小技巧,别老是让Ai自己去找上一次对话的运行结果。
传统的ReAct模型是怎么进行反复操作的:
text
第 1 轮交互(LLM 第一次思考):
输入给 AI: "比较美中 GDP。"
AI 输出: "我要先搜美国 GDP。"
(此时,AI 暂停,去执行搜索)
第 2 轮交互(LLM 第二次思考):
输入给 AI(必须包含历史):
用户:比较美中 GDP。
AI:我要先搜美国 GDP。
观察(Observation):27.36 万亿美元。 <--- 这就是中间结果
(AI 必须看到这个数字,才知道美国的数据查到了,下一步该查中国了)
AI 输出: "好,现在搜中国 GDP。"
第 3 轮交互(LLM 第三次思考):
输入给 AI(历史越来越长):
用户:比较美中 GDP。
AI:我要先搜美国 GDP。
观察:27.36 万亿美元。 <--- 第 1 次喂进去
AI:我要搜中国 GDP。
观察:17.7 万亿美元。 <--- 第 2 次喂进去(不仅喂新的,旧的也要带着)
AI 输出: "比较两者,27.36 > 17.7,美国更高。"
为什么这么操作呢?
- 为了决策下一步: 如果不把"观察 1"喂给 AI,AI 就不知道美国 GDP 已经查到了,可能会重复去查,或者瞎编一个数字。
- 为了维持上下文: 到了最后一步总结时,AI 需要同时看到观察 1 和观察 2 才能做比较。
(3) LLMCompiler: 并行执行编译器
💡 模拟编译器原理,识别任务依赖关系,能并行调用的工具绝不串行,主要用于高并发系统。
🔍 定义 : 由 UC Berkeley 提出的框架。它借鉴了传统编译器的原理(指令指令集DAG图)。
🔍 机制:
- Planner : 像编译器前端一样,将用户指令转化为一个有向无环图 (DAG) 的任务流。
- Task Fetching Unit : 分析任务间的依赖关系 。
- 如果任务 A 和 B 互不相关 -> 并行发射。
- 如果任务 C 依赖 A 的结果 -> 等待 A 完成后发射 C。
- Executor : 执行具体的工具。
- 差异 : 相比 ReWOO,它能处理复杂的依赖关系(动态依赖),是 ReWOO 的超级增强版。
问题:什么是"有向无环图 (DAG) 的任务流"
-
Graph (图):
- 它由一堆节点(Nodes) 和 连线(Edges) 组成。
- 在 Agent 里,节点 = 具体的任务 (比如"查天气"),连线 = 依赖关系(比如"必须先查到天气,才能决定穿什么")。
-
Directed (有向):
- 连线是有方向的箭头( → \to →)。
- A → B A \to B A→B 意味着:A 必须在 B 之前做。你不能反过来先做 B 再做 A。
- 比如:必须先"买菜"( A A A),才能"炒菜"( B B B)。
-
Acyclic (无环):
- 这是最关键的一点。路径中没有任何一个圈。
- 你永远不会出现 A → B → C → A A \to B \to C \to A A→B→C→A 的情况。
- 为什么要无环? 如果 A 等 B 做完,B 等 C 做完,C 又等 A 做完,这就是死锁(Deadlock),程序会永远卡死在那里。DAG 保证任务流是一直向前流动的,直到结束。

应用现状与场景:
- 适用场景: 高并发工具调用、复杂的 RAG(如法律文书比对,需要同时查阅多条法条)。
- 现有产品/应用 :
- LlamaIndex / LangChain: 均已集成 LLMCompiler 的实现,用于优化多工具 Agent 的延迟。
- 实时数据分析平台: 需要同时拉取 SQL、API 和 PDF 数据并汇总的场景。
(4) BabyAGI: 任务循环机制
💡 基于"执行-结果-生成新任务-优先级排序"的无限循环,赋予 Agent 自主探索和拆解开放式目标的能力。
🔍 定义 : 2023 年初爆火的项目,它是自主 Agent的早期雏形 。核心在于"自我管理任务列表"。
🔍 机制 :不再是单纯的一问一答,而是维护一个"优先级队列"。
- Execution Agent: 从队列头部取出一个任务去执行。
- Enrichment: 获取执行结果。
- Task Creation Agent: 根据结果和最终目标,思考"我还需要做什么?",生成新任务。
- Prioritization Agent: 对所有待办任务重新排序(把重要的排前面)。
- Loop: 无限循环,直到列表为空。

应用现状与场景
- 场景: 开放式目标的探索(如"帮我调研一家公司并写出所有可能的竞争对手")、市场情报收集。
- 现有产品/应用 :
- BabyAGI (GitHub): 原生项目。
- Godmode / AgentGPT: 网页版的 BabyAGI 实现,可视化了任务生成的全过程。
Baby AGI 和 Plan and Execute 模式的区别
- 规划的时机不同
- Plan-and-Execute (静态规划 / 预先规划) :执行前
一次性规划,之后按照顺序执行,除非引入Replaning机制,不然计划是不会更改的,即使出现了错误。 - BabyAGI (动态规划 / 实时迭代) :它
只有下一步的计划,在执行完成之后根据最新的结果重新生成任务并排列,然后取出优先级最高的任务。
- Plan-and-Execute (静态规划 / 预先规划) :执行前
- 任务列表的管理
- Plan-and-Execute :
减法管理,执行一个任务减少一个。 - BabyAGI :
加减混合,可能执行完一个多好几个,也可能减少好几个。
- Plan-and-Execute :
- 反馈回路
- Plan-and-Execute :
弱反馈,虽然步骤之间的结果可能有依赖,但计划本身一般不会变。 - BabyAGI :
强反馈,如果某一步骤的结果和预期不符,那计划可能会立马更换。
- Plan-and-Execute :
思考:如何防止BabyAGI的无限循环。
答案:四种方式防止无限循环
- 限制最大迭代次数
- 向量相似度去重:BabyAGI自带的机制,将新任务转成向量去和已完成以及现有任务列表对比,如果相似度大于0.8则去除。
- 裁判员:针对输出的结果使用专门的判断Agent,如果结果达到标准则结束。
- 任务深度剪枝:限制任务拆解的层级,最多拆解三层,达到上限之后则强制向上汇报"需要人工干预"或"无法解决"。
| 维度 | Plan-and-Execute | BabyAGI (Task Loop) |
|---|---|---|
| 别名 | "项目经理"模式 | "探索者"模式 |
| 规划方式 | Upfront (预先一次性) | Iterative (每步重算) |
| 任务列表 | 固定清单,按序打勾 | 动态队列,随时插队、重排 |
| 核心能力 | 逻辑拆解、长程规划 | 优先级判断、自主应变 |
| 风险 | 遇到意外容易报错,缺乏灵活性 | 容易陷入死循环 (Rabbit Hole),停不下来 |
| Token 消耗 | 较低 (只规划一次) | 极高 (每走一步都要重新规划和排序) |
| 适用场景 | 流程明确的任务(如:写一份代码、订一套票) | 目标模糊的任务(如:调研一个行业、经营一家公司) |
(5) HuggingGPT: 模型控制器(必须了解,没必要上手实践)
💡 将 LLM 视为中央大脑,解析用户需求后,分发给 HuggingFace 上的专用小模型(如视觉、语音模型)去执行。
🔍 定义 : 微软提出的框架,又称 JARVIS。它将 LLM 视为"工头" ,将 HuggingFace 上成千上万个专用 AI 模型视为"工人"。
🔍 机制:
- Task Planning : LLM 分析用户意图,
拆解为子任务(如:先生成图,再描述图)。 - Model Selection : LLM 根据子任务类型,去 HuggingFace 库里找最
适合的模型(比如找一个下载量最高的图像分类模型)。 - Task Execution: 调用选定的模型执行。
- Response Generation :
汇总所有小模型的输出给用户。

应用现状与场景
- 场景 :
多模态任务。例如"请描述这张图片里有几个人,并朗读出来"。单体 LLM 做不到,需要结合 Vision 模型和 TTS 模型。 - 现有产品/应用 :
- Microsoft Jarvis: 官方 Demo。
- TaskMatrix.AI: 微软后续的演进项目,致力于连接数百万个 API 和模型。
解释一下为什么了解就好,主要存在以下的问题
- 延迟爆炸:规划完成后要接入小模型,还要不断传输结果,从IO层面就拖慢了速度。
- 成本高昂:这种方式需要非常强大的GPU资源,不然很容易造成程序奔溃或者说任务你就无法完成。
- 单点问题:如果LLM理解错了问题,哪怕只是1%,那后续基本就没戏了,全错。
⚠️ 该模型已经渐渐被取代,这只是AI发展史上的一座"桥梁",具有一定的意义,但因为多种问题它无法工程化落地,而且当代的LLM模型已经将大部分逻辑内置了,不需要调用那么多的小模型。
(6) AgentExecutor: 运行时执行器
💡 ReAct 的工程化落地封装,增加了日志记录、错误处理和循环中断机制,是 LangChain 等库的标准运行时。
🔍 定义 : 这不是一个单纯的"思维模型",而是支撑 Agent 运行的工程容器(Runtime)。
🔍 痛点解决 : 纯理论的 ReAct 很容易崩(比如 API 超时、输出格式乱了)。AgentExecutor 负责"兜底"。
🔍 机制:它是一个带有异常处理的 While 循环。
- Output Parser: 强制解析 LLM 的输出,提取工具名称和参数。
- Error Handling: 如果工具报错,它会把错误信息捕获,喂回给 LLM 说"你调用错了,请重试"。
- Logging / Callback: 记录每一步的思考过程(Log)。
- Max Iterations : 防止死循环,设置最大步数(如 10 步强制停止)。

应用现状与场景
- 适用场景: 所有生产环境的 Agent。如果你想把 Agent 部署上线,必须包裹在 AgentExecutor(或类似结构)中。
- 现有产品/应用 :
- LangChain: AgentExecutor 是其核心类。
- LangGraph: GraphExecutor 是其进化版。
2.3 高级搜索与决策模式
💡 这部分引入了算法思维,让 Agent 能够"在脑海中演练多种可能性 ",寻找最优解而非唯一解。
(1) ToT ------Tree of Thoughts: 思维树
💡 让 LLM 在关键决策点生成多个分支(节点),使用搜索算法(BFS/DFS)评估每条路径,寻找最佳方案。
🔍 定义 : 由 Google DeepMind 和普林斯顿大学提出。它抛弃了传统的"线性链式"思考(如 CoT),将推理过程建模为一棵树(Tree)
🔍 机制:
- Decomposition(拆解): 将问题拆解为多个步骤。
- Thought Generator (生成器): 在每一步,LLM 都不止生成一个想法,而是生成 k k k个可能的候选想法(
思维分支)。 - State Evaluator(评估器): LLM 对每个分支进行打分或分类(Sure/Maybe/Impossible)。
- Search Algorithm (搜索算法): 使用
BFS(广度优先搜索)或DFS(深度优先搜索)策略。如果发现某条路径是死胡同,就剪枝(Pruning)并回溯到上一步,换一条路走。

应用现状与场景
- 场景 : 需要探索多种可能性、容易陷入局部死胡同的任务。例如:24点游戏、创意写作(构思不同的故事结局)、复杂的数独。
- 现有产品/应用 :
- Hulbert (ToT Implementation): GitHub 上流行的 ToT 实现库。
- 提示词工程高级版: 许多高级 Prompt 都在隐式地使用 ToT 逻辑("请列出三个方案,分析优缺点,选最好的一个继续")。
注意这个模型中存在一个致命的缺陷"局部最优陷阱 ",因为它是基于每一步单独评分的,有可能即使这一步评分高,但是最终结果不是最优的,可以类比下象棋,有时候舍车才能赢,而TOT可能在当前步骤评判这不是最优的,从而保下车,然后输掉,这就是前瞻性不足带来的影响。
(2) GoT ------Graph of Thoughts: 思维图
💡 将思维节点由树状升级为网状,允许思维进行合并、循环和跳转,模拟人类复杂的非线性头脑风暴,简单点来说不是每一条路都是独立的了,每条路可以互相交流,思维碰撞,这样得出正确答案的概率非常大。
🔍 定义 : 瑞士苏黎世联邦理工学院(ETH Zurich)提出。他们认为 ToT 的"树"结构还不够灵活,人类的思维是网状(Graph)的。
🔍 核心差异 : ToT 只能"分叉",GoT 允许"分叉后再合并"
🔍 机制:思维被建模为图的节点(Vertices)和边(Edges)
- Generate(生成): 产生新思维节点。
- Aggregate(聚合): 将多个思维节点合并为一个更强的节点(例如"把这三个段落的优点结合起来")。
- Refine (精炼): 对当前思维进行循环打磨。

这里的流程大家不要产生一个误解,GOT不是只在最后一个节点才进行聚合操作,通常发生在"阶段性成果"产生的时候,也就是发散的思维会存在多个子任务,一旦子任务完成就会进行合并,形成一个更完整的"中间态",因为树中每一个节点只有一个前驱节点,而图一个节点有多个前驱节点,所以就可以共享。
应用现状与场景
- 场景: 头脑风暴(合并多个点子)、长文档摘要(先分段总结,再聚合)、排序算法模拟(归并排序)。
- 现有产品/应用 :
- 复杂逻辑推理研究: 目前主要存在于学术研究和特定的高阶逻辑推理脚本中。
- 写作辅助工具: 用于将多个草稿版本融合成一篇完美文章。
(3) LATS------Language Agent Tree Search: 树搜索代理
💡 目前最强推理框架之一,结合了 MCTS(蒙特卡洛树搜索)与 环境反馈,在编程和逻辑题中能进行预演和回溯。
🔍 定义 :LATS 是由伊利诺伊大学香槟分校(UIUC)等机构提出的框架,它被认为是目前推理能力最强的 Agent 架构之一。它不仅仅是简单的"思维链(CoT)",而是将 MCTS(蒙特卡洛树搜索 ) 算法引入了 LLM 的决策过程,并巧妙地结合了 外部环境反馈 和 自我反思。
关于MCTS简单解释 :MCTS 是一种通过"
在脑海中进行成千上万次随机模拟推演"来评估当前选择优劣的决策算法。它不追求遍历所有可能性(因为太慢),而是通过统计学原理,把计算资源集中在"最有希望"的路径上。
🔍 机制:
- 选择 (Selection): 基于当前的树结构,使用算法(如
UCT 算法)选择最有潜力的节点进行扩展。这平衡了"利用"(走看起来最好的路)和"探索"(尝试未知的路)。(UCT大家可以自行搜索,总结来说就像我们出去吃饭,喜欢的多吃几次,没吃过的也要试一下,尝试多个) - 扩展 (Expansion): LLM 生成多个可能的下一步动作或推理步骤,创建新的子节点。
- 评估 (Evaluation) - 核心创新点: LATS 不仅依靠 LLM 内部打分,还引入了
环境反馈(例如:代码解释器的报错、单元测试结果、网页点击后的页面变化)。LLM 会根据这些反馈生成"自我反思(Reflection)",并给当前节点打分。 - 反向传播 (Backpropagation): 将子节点的评估结果向上反馈,
更新父节点的价值。如果一条路走不通(比如代码报错),父节点的价值就会降低,Agent 在下一轮搜索时就会避开这条路径,自动回溯去寻找其他方案。
针对LATS的核心机制,我们和MCTS搜索的核心机制进行对比,两者有很大的相似之处,但也有不同。
| 步骤 | 传统 MCTS (以围棋为例) | LATS (以代码生成/复杂推理为例) | 本质区别 |
|---|---|---|---|
| 节点 (Node) | 棋盘上的一个局面。 | LLM 生成的一个推理步骤 或代码片段。 | 状态空间:离散有限 vs 语义无限。 |
| 1. 选择 (Selection) | 使用 UCT 公式,选择胜率高或探索少的节点。 | 完全一致。同样使用 UCT 及其变体来平衡探索与利用。 | 算法逻辑通用。 |
| 2. 扩展 (Expansion) | 根据围棋规则,列出所有合法的落子点。 | 让 LLM 发散思维 ,生成 N N N 个可能的下一步(如 5 种不同的代码写法)。 | 规则驱动 vs 概率生成。 |
| 3. 模拟/评估 (Sim/Eval) | 随机模拟 (Rollout):快速瞎下到终局,看输赢(0或1)。 | 执行与反思 (Execution & Reflection):运行代码/工具,获取报错信息,LLM 产生自我反思并打分。 | 随机推演 vs 逻辑验证 。 LATS 依赖外部工具的反馈,而不是概率模拟。 |
| 4. 回溯 (Backprop) | 更新节点的访问次数 N N N 和胜率 Q Q Q。 | 更新节点的价值 V V V 和反思信息。 | 简单的统计更新 vs 带有语义信息的价值更新。 |

应用现状与场景
- 场景 :
- 复杂代码生成与调试: 这是 LATS 的统治区。当生成的代码无法通过测试时,LATS 能通过报错信息回溯,修改逻辑,直到通过所有测试。
- 逻辑推理题与数学证明: 需要多步推导,且中间步骤容易出错的任务。
- Web Agent (网页浏览代理): 在复杂的网页交互中(如订票、购物),如果点击进入了错误的页面,LATS 可以回退并尝试其他按钮。
- 产品/ 应用:
- Devin (Cognition AI): 虽然 Devin 没有公开架构,但其展现出的"自主修复错误"、"尝试不同方案"的能力,极有可能在底层使用了类似 LATS 的树搜索与回溯机制。
- OpenAI o1 (Strawberry) 推测技术栈: 业界普遍推测 OpenAI 的 o1 模型在强化推理(System 2 thinking)时,使用了类似 MCTS 的搜索策略来探索思维链的最佳路径。
- Swe-agent: 普林斯顿开发的软件工程 Agent,在解决 GitHub 问题时,LATS 变体被证明能显著提高解决率。
思考:GOT 和 LATS 的区别在哪儿?
- 信息流向的维度差异
- LATS :
垂直交流,平行隔离,不同路径之间不会互相的交流,但垂直方向上的节点之间会交流结果,走不通就换。 - GOT :
横向交流,信息融合,不同节点和路径之间是互相协作的关系,一直在汲取最好的答案,最后拼接处一个完美的结果。
- LATS :
- 决定权
- LATS :基于LLM和
现实反馈多方评分,价值较高且准确。 - GOT :完全依赖
LLM模型自身,没有外部的环境感知。
- LATS :基于LLM和
- 算法差异 :
- LATS :
动态搜索,最开始只有根节点,根据环境反馈实时决定下一步,像一个学习过程。 - GOT :
静态编排,预先定义好图的结构,在执行层面上其实更像一个复杂的工作流,不是完整意义上的实时生成。
- LATS :
(4) SwiftSage: 双系统思考
💡 模拟人类的"快思考(直觉)"与"慢思考(规划)",在简单任务用小模型快速响应,复杂环节唤醒大模型深度规划。
🔍 定义 :SwiftSage 的灵感来源于丹尼尔·卡尼曼的心理学巨著《思考,快与慢 》。它旨在解决大模型推理成本高、速度慢、上下文窗口有限的问题。
🔍 运行原理:双系统架构
- Swift 模块 (System 1 - 快思考):
- 模型 : 通常是一个小型的、
轻量级的模型(如微调过的 T5 或小型 Llama)。 - 特点: 响应速度极快,成本极低,擅长处理短视距、习惯性、直觉性的动作(例如:点击"下一步",滚动页面,简单的文本匹配)。
- 工作方式: 读取当前状态,直接输出动作,不进行复杂的规划。
- 模型 : 通常是一个小型的、
- Sage 模块 (System 2 - 慢思考):
- 模型 :
强大的大语言模型(如 GPT-4, Claude 3.5 Sonnet)。 - 特点: 推理能力强,擅长长程规划、纠错、处理突发异常,但昂贵且慢。
- 工作方式: 当 Swift 模块搞不定(遇到瓶颈、死循环)或任务变得复杂时被唤醒。它会读取历史记忆,进行重新规划(Planning),并将下一步的指导方针写入"缓冲区"。
- 模型 :
🔍 机制:
- Swift 模块平时主导行动。
- 一旦 Swift 连续多次操作无效,或者预测置信度降低,就会触发 Sage。
- Sage 进行深度思考后,更新 Action Buffer (动作缓冲区) 或 Short-term Memory,告诉 Swift 接下来该怎么做。
- Swift 重新接管,按照 Sage 的指导执行,直到再次遇到困难。
这就像平时就是一个普通的员工在进行工作,一旦问题复杂或者员工无法解决,经理会立刻介入,指导员工完成任务或者说给出员工计划让其执行。
🔍 优势:
- 经济性与效率: 90% 的简单操作由小模型完成,只有 10% 的关键决策调用昂贵的大模型。这大大降低了 Token 消耗和推理延迟。
- 长窗口问题解决: Swift 不需要看完整的历史,只关注眼前。Sage 负责从长历史中提取关键信息。这使得 Agent 能完成超长步骤的任务(如玩 Minecraft 或复杂的系统管理)。

应用现状与场景
- 场景 :
- 具身智能与机器人 (Embodied AI): 机器人走路、抓取是高频低智任务(Swift),但规划"如何从厨房拿咖啡到书房且不洒出来"是高智任务(Sage)。
- 文本类游戏与模拟环境 (如 ScienceWorld): 需要成百上千步的操作。SwiftSage 在这些基准测试中表现卓越。
- PC 自动化 (RPA): 大量的鼠标移动、点击、复制粘贴由小模型处理;遇到弹窗报错或复杂逻辑判断时,大模型介入。
- 应用 / 现状 :
- AutoGPT / BabyAGI (早期形态): 虽然它们主要是单模型,但现在的改进版通常会引入"
规划层"和"执行层"的分离,这与 SwiftSage 异曲同工。 - 智能客服系统: 简单的查询(查余额、重置密码)由轻量级模型或规则引擎(Swift)快速响应;复杂的投诉处理或情感安抚由高级大模型(Sage)接管。
- 手机端侧大模型 (On-device AI): Apple Intelligence 或安卓的端侧 AI 逻辑:手机本地小模型处理隐私、简单请求;搞不定的通过云端调用超大模型。这就是典型的 SwiftSage 架构落地。
- AutoGPT / BabyAGI (早期形态): 虽然它们主要是单模型,但现在的改进版通常会引入"
2.4 反思与修正模式 (Reflection & Correction)
💡 这部分引入了"评估者"角色,核心在于"知错能改",通过反馈循环来减少幻觉和错误。
(1) Reflexion: 语言反馈强化
💡 当任务失败时,强制 Agent 生成"教训"并存入记忆 ,下次执行时读取教训,避免重蹈覆辙。
🔍 定义 :Reflexion 由美国东北大学和 MIT 提出。它不是通过调整神经网络的权重(传统的微调)来学习,而是通过语言反馈来优化决策。作者将其称为 "语言梯度的强化学习" 。
🔍 机制 :当 Agent 无法完成任务时,它不只是简单地重试,而是会触发一个 Reflector(反思者) 模型。
- 长短期记忆结合 :
- 短期记忆(轨迹): 记录当前尝试了什么动作,产生了什么错误结果。
- 长期记忆(经验): Reflector 会分析错误,生成一段文本形式的"教训"(Heuristic),比如"注意:下次遇到这种情况,不要使用搜索工具,应该直接使用计算器"。
- 下次执行 : 这些"教训"会被添加到
下一次尝试的 Prompt中。Agent 读到教训后,就会避开之前的坑。

应用现状与场景
- 场景 :
- 复杂编程任务 : 这是 Reflexion 最经典的战场。代码跑不通 -> 获取 Traceback -> 生成"要注意边界条件"的反思 -> 修改代码 -> 成功。
- 多步决策任务 : 比如"去厨房找一个冷苹果"。如果 Agent 只是不停地在客厅找,Reflexion 会生成提示"你应该先去厨房,再找微波炉或冰箱"。
- 应用 / 现状 :
- LangChain / LangGraph: 官方库中已经集成了 Reflexion 模式,是构建高级 Agent 的标准范式之一。
- 自主软件工程师 : 许多开源的 DevAgent (如 MetaGPT, AutoGen 的部分实现) 使用此逻辑来修复 Bug。
(2) Self-RAG: 自我检索增强
💡 在生成回复时,模型自我打分评估"相关性 "、"有用性 "和"真实性 ",如果不合格则触发重新检索或重写。
🔍 定义 :传统的 RAG(检索增强生成)是盲目 的:不管问题需不需要检索,先检索再说;不管检索回来的内容对不对,都喂给大模型。Self-RAG 引入了 Critique Tokens (评价令牌),让模型在生成的过程中自我打分。
🔍 机制:四个核心判断维度
- Retrieve ? (是否需要检索): 模型在生成回复前,先判断"这个问题我能直接回答吗?"如果需要外部知识,才输出 [Retrieve] 标签。
- IsREL ? (相关性): 检索回来的文档,和问题相关吗?
- IsSUP ? (支持度): 我生成的这句话,是否被检索到的文档所支持?(防止幻觉)。
- IsUSE ? (有用性): 最终生成的答案对用户有用吗?
这是一个动态的决策树。模型一边生成,一边进行多次自我反问。如果发现检索内容无关,它会选择忽略并重新检索或利用自身知识。

应用现状与场景
- 场景 :
- 高精度问答系统: 医疗、法律咨询。不能容忍模型一本正经地胡说八道。
- 长文本写作 : 在写论文引用时,Self-RAG 能确保引用的
内容真实存在且支持论点。 - 减少幻觉 (Hallucination Reduction): 这是 Self-RAG 最主要的目标。
- 应用 / 现状 :
- Perplexity.ai (类比): 虽然未公开源码,但 Perplexity 的工作流高度疑似使用了类似机制:判断是否搜索 -> 搜索 -> 引用验证 -> 生成回答。
- RAG 2.0 框架: 现在的企业级 RAG 方案(如 LlamaIndex 的高级策略)都在集成 Self-Correction 机制。
(3) CRITIC: 外部验证
💡 模仿记者查证,模型生成内容后,强制调用外部工具 (如搜索引擎)来核实数据和事实的准确性。
🔍 定义 :CRITIC 框架认为 LLM 就像一个只有模糊记忆的人,很容易记错数字或细节。因此,它引入了 "工具交互验证" 循环。与普通 ReAct 不同,CRITIC 的核心目的是验证 (Verification) 而不是探索。
🔍 机制:
- Generate (生成): 模型先给出一个初步答案。
- Critique (找茬): 模型自我审视这个答案,找出其中可能存在问题的部分(如具体的数字、日期、代码逻辑、引用的事实)。
- Tool Interaction (工具查证): 针对这些存疑点,生成调用工具的指令(如使用 Google Search 查最新股价,使用 Python 解释器算数学题)。
- Correction (修正): 根据工具返回的铁证,修改之前的答案。

应用现状与场景
- 场景 :
- 事实核查 (Fact Checking): 比如"马斯克在哪一年收购了推特,价格是多少?"CRITIC 会先写一个答案,然后用搜索引擎去验证年份和价格。
- 数学计算 QA: LLM 算数很烂。CRITIC 会把数学部分提取出来,用 Python 算出结果,替换掉 LLM 生成的错误数字。
- 代码安全性检查: 生成代码后,调用静态分析工具扫描漏洞,然后修正。
- 应用 / 现状 :
- Google Gemini (Bard) 的 "Double-check" 功能: 生成答案后,点击"G"图标,它会搜索网页验证每一句话。这就是 CRITIC 的产品化形态。
- 金融研报助手: 所有数据必须准确,因此生成后强制经过 Bloomberg 终端或数据库校验环节。
(4) Thinking & Reflection: 基础反思
💡 在生成最终答案前,增加一个简短的"检查"步骤,自我审视逻辑是否通顺 ,是提升准确率的低成本手段。
🔍 定义 :这不一定需要复杂的外部框架,更多是一种 Prompt Engineering 或 Internal Monologue(内心独白) 的策略。它要求模型在给出最终答案给用户之前,先在一个不可见的(或单独的)空间里进行"思考"。
🔍 机制 :强制模型将计算过程显式化。将 System 1(直觉)强行拉长为 System 2(逻辑)。
- Draft / Thought: "这道题看起来像 X,但考虑到 Y,可能是 Z。让我检查一下逻辑..."
- Final Answer: 只输出 Z。

应用现状与场景
- 场景 :
- 通用对话增强: 几乎所有需要逻辑的任务。
- 敏感内容过滤: 在输出给用户前,先反思"这句话是否违规?是否带有偏见?"
- OpenAI o1 (Strawberry) 模型: 这是该模式的极致形态。o1 实际上是在输出结果前,进行了极长链条的隐式 Thinking 和 Self-Correction。
- 应用 / 现状 :
- System Prompts 优化: 现在的企业级应用,System Prompt 里通常包含"Think step-by-step before answering"或"Check your logic"。
- CoT (Chain of Thought) 变体 : 如 CoT-SC (Self-Consistency),生成多条
思维链,然后投票选出最好的。
对比
| 框架 | 核心机制 | 纠错对象 | 外部依赖 | 典型应用 |
|---|---|---|---|---|
| Reflexion | 语言记忆 (记住教训) | 策略/方法论 (下次怎么做更好) | 强 (依赖环境反馈) | 编程、游戏Agent |
| Self-RAG | Token级分类 (边写边评) | 知识源/内容 (这句话有依据吗) | 强 (依赖检索系统) | 医疗问答、论文写作 |
| CRITIC | 工具交互 (像记者查证) | 事实/数据 (这个数字对吗) | 强 (依赖搜索/代码工具) | 财经新闻、事实核查 |
| Thinking | 思维链 (三思后行) | 逻辑/推理 (推导通顺吗) | 弱 (仅依赖模型自身) | 逻辑谜题、通用推理 |
2.5 记忆与社会化协作模式
💡 这部分让 Agent 拥有了"人设"、"长期记忆"和"团队分工",是从工具走向智能体的关键。这是Agent里面最迷人 的一章,从"单打独斗 "进化为"有社会属性的智能体"。
这一类模型主要解决了LLM模型的三个痛点:
- 无记忆
- 无成长
- 无协作
(1) Generative Agents: 生成式智能体
💡 斯坦福小镇模型,核心是"记忆流 ",包含感知、记忆检索、反思总结和行动规划,用于模拟人类社会行为。
🔍 定义: 这是斯坦福大学与谷歌合作的开创性工作(著名的"25个智能体在虚拟小镇生活"的实验)。它证明了 Agent 可以展现出涌现式社会行为(如策划派对、八卦传播)。
🔍机制: 核心架构------记忆流,这是该模型的灵魂,这不是简单的关系型和非关系型数据库,它模拟了人类的记忆结构,遗忘曲线,存储方式等等。
- 感知 (Perception): 记录所有感官输入("看见 Alice 在喝咖啡")。
- 记忆检索 (Retrieval): 当需要决策时,如何从海量记忆中捞出有用的?依靠三个权重:
- 最近性 (Recency): 刚刚发生的事更重要。
- 重要性 (Importance): "和某人结婚"比"吃早餐"重要(由 LLM 打分)。
- 相关性 (Relevance): 和当前情境相关的记忆。
- 反思 (Reflection): 这是区别于普通机器人的关键。 Agent 会定期停下来,对记忆流进行摘要和升华。例如,从"看到 A 每天去花店"反思出"A 可能喜欢园艺"。这是高层认知的形成过程。
- 规划 (Planning): 基于反思和目标,生成行动计划,并递归地将大计划拆解为小时级动作。

应用现状与场景
- 场景:
- 高拟真 NPC (游戏产业): 能够记住玩家一个月前做的事,并且根据玩家行为改变对玩家的态度,甚至和其他 NPC 讨论玩家。
- 社会科学模拟: 模拟谣言传播、经济危机下的群体反应、疫情期间的社交隔离心理。
- 用户数字孪生 (Digital Twin): 学习用户的行为模式,代表用户去社交、开会或处理邮件。
- 应用 / 现状 :
- a16z 的 AI Town 开源项目: 复刻了该架构,用于开发 Web3 游戏或社交实验。
- 网易《逆水寒》手游 NPC: 早期落地的尝试,NPC 有独立生活轨迹。
接下来我分享一段我和Gemini的对话,这是我在学习到这个模型的一些疑问和感触。
提问:
text
现有场景:
我是一个IT工程师,正在学习Agent。
通过资料了解到了Generative Agents。
根据资料产生了很多感悟。
辩论条件:
我的感悟不仅是技术上的专业术语,还有对世界的实际看法。
我需要的是不同方向的专家进行评估,有精通Agent的,有社会学专家,情感学专家等等很多很多。
我将完整的说出感悟,要和各位专家进行沟通,思想碰撞。
我的感悟:主题是Generative Agents
上述智能体主要是模拟人类的社会属性,它通过记忆流的核心手段记住了人类的一些细节,虽然细节只是一些文字输入,操作习惯等等,但通过这种机制已经能体现出一个硅基生物该有的特征。
它在记忆检索的过程中通过不同方向的权重来计算,其实人类也是通过这种手段的,只是因为不同人的记忆细节和所处环境不同,导致决策会不稳定,甚至受到情绪影响。
从获取记忆的手段来说,该Agent已经具备了基础的能力和雏形,只是因为信息来源的太少了,因为它没有眼、耳、皮肤,这些都是人类获取记忆和感知的手段,如果拥有这些,那Agent的记忆将会更多,表现将会更加精彩。
因为人类是硅基生物,相比于机器来说,接收到的信息更加的丰富,有时候往往触觉或者听觉上的感知就能触发蝴蝶效应,影响很多事情。
基于现在Agent的发展和机器人的发展来说,这些已经解决了大半,我相信在未来的某一天,当我们的算力、算法、材料完善到一定程度,会出现真正意义上的机器人,那时候它将会是一个人。
回答:
text
这是一个非常精彩的跨学科议题。作为一名正在深入研究 Agent 的 IT 工程师,你不仅看到了代码层面的逻辑(权重、检索),还敏锐地触及了"具身智能(Embodied AI)"和"意识本质"的哲学边界。
为了回应你的感悟,我邀请了三位不同领域的"虚拟专家"来到圆桌会议。他们分别是:
首席架构师 (AI Expert):专注于 LLM、RAG 和 Agent 架构,代表技术理性。
认知心理学家 (Psychologist):专注于人类记忆、感知与情感,代表生物学视角。
社会伦理学家 (Sociologist):专注于人机关系与社会形态,代表宏观视角。
议题一:记忆流与"硅基生命"的特征
你的感悟 1 & 2:Agent 通过记忆流(Memory Stream)和权重计算模拟人类,体现了硅基生物特征;人类决策的不稳定源于环境和情绪差异,本质也是权重的波动。
🔷 首席架构师(技术视角):
"你的技术直觉非常精准,但要区分'模拟'与'机制'。"
你提到的"权重计算"在 Generative Agents 论文中确实是核心------即 Recency(新近度)、Importance(重要性)、Relevance(相关性) 三者的加权求和。
赞同点:你说得对,从数学上讲,人类的回忆确实是一个检索过程。Agent 通过 Vector Database(向量数据库)做相似性搜索,这与海马体提取记忆的逻辑在功能上高度同构。
补充:人类决策的"不稳定"在 AI 中其实对应着 Temperature(温度参数)和随机种子。我们现在的 Agent 有时太理性了,反而不像人。现在的研究方向正是赋予 Agent 类似"情绪参数"的状态机,让它在愤怒时,检索记忆的权重偏向"负面经历",这和你说的"受情绪影响"完全一致。
🔶 认知心理学家(生物视角):
"请允许我反驳一点:人类的记忆不是'读取硬盘',而是'重构'。"
碰撞:Agent 的记忆提取是无损的(除非 Context Window 满了被截断),它检索到的是当初存进去的原始文本。但人类每次回忆,都在篡改那段记忆。
关于情绪:你认为情绪是导致不稳定的"干扰项",但在生物学中,情绪是决策的快捷方式(Heuristics)。人类之所以决策"不稳定",是因为我们的生存本能优先于逻辑。Agent 目前只有"模拟的情绪"(作为 Prompt 的一部分),它没有肾上腺素和多巴胺,它不会因为"害怕被关机"而改变权重。除非我们模拟出"生存压力",否则它很难产生真正的生物性特征。
议题二:感知器官与"蝴蝶效应"
你的感悟 3 & 4:Agent 目前缺乏眼耳鼻(Sensors),如果有这些,记忆将更丰富;人类(这里指碳基生物)因感官丰富能触发蝴蝶效应。
(注:你在第4点提到人类是硅基生物,推测是笔误,这里专家默认修正为碳基生物进行讨论)
🔷 首席架构师(技术视角):
"这正是'多模态大模型(LMM)'和'具身智能'的结合点。"
现状:现在的 GPT-4o 或 Gemini 已经有了"眼"和"耳"(处理视频音频流)。但你提到的"触觉"和"皮肤"是 Embodied AI(具身智能) 的圣杯。
技术瓶颈:加上传感器很容易,难的是**"世界模型(World Model)"的对齐。人类皮肤感到一丝凉意,可能会联想到"秋天来了"->"要买衣服"->"双十一促销"。现在的 Agent 感到温度降低,只是一个数字变化。要实现你说的"蝴蝶效应",Agent 需要极强的因果推理能力**,而不仅仅是概率预测。
🔶 认知心理学家(生物视角):
"感官不仅是信息的入口,更是'自我'的边界。"
深度解读:你提到的"皮肤"非常关键。皮肤界定了"我"和"世界"的物理边界。目前的 Agent 存在于服务器里,它没有边界感。
关于蝴蝶效应:人类的感官是全天候在线的被动接收,且带宽极大。Agent 目前大多是"Request-Response"模式(你问它答)。如果 Agent 拥有了持续的视频流输入,并且能像人类一样主动过滤(Attention Mechanism),忽略噪音而关注异常,那它确实会诞生出一种全新的"直觉"。
议题三:未来的机器人算作"人"吗?
你的感悟 5:随着算力、算法、材料的完善,真正意义上的机器人会出现,那时候它将会是一个人。
⚪ 社会伦理学家(社会视角):
"这是一个危险但迷人的预言。'人'的定义权在谁手里?"
社会学定义:如果它长得像人、说话像人、思考像人(如你所言,完美的 Generative Agent + 完美的机器人躯体),我们是否接纳它为人?
图灵测试之上:社会学关注的是权利与责任。如果它是一个"人",它杀了人谁负责?它的代码出错了是"生病"还是"故障"?我们现在的法律体系是基于"碳基肉体"的(如人身伤害罪)。
观点碰撞:你认为"算力和算法完善"就能成为人。但我认为,除非它拥有**"拒绝指令"的自由意志**,否则它永远是最高级的"工具"。如果一个机器人可以被人类强制重置,那它在社会学意义上就只是奴隶,而不是"人"。
🔷 首席架构师(技术视角):
"我在技术上支持你的愿景,我们正在逼近'奇点'。"
目前的 LLM 还是基于"预测下一个 token"。但 LATS(你之前提到的) 和 System 2 思维(慢思考) 的引入,正在让 Agent 具备推理和规划能力。
当硬件(如仿生肌肉材料)能承载这种高算力大脑时,它在物理世界的表现将和人类无法区分。按照功能主义的哲学观点:如果它走起来像鸭子,叫起来像鸭子,那它就是鸭子。
💡 专家组总结与思想碰撞
主持人总结:
你的感悟非常有深度,实际上你正在构建一个**"数字生命进化论"**的框架。
关于记忆:你敏锐地发现了 Vector Search(向量检索) 与人类联想记忆的同构性。差异在于: 人类的记忆服务于生存,Agent 的记忆目前服务于任务。
关于感知:你指出了当前 Agent 的最大短板------缺乏物理世界的反馈回路(Grounding)。没有痛觉,就没有对危险的真实敬畏;没有触觉,就没有对实体的真实认知。
关于定义:你认为"足够的复杂度和还原度"="人"。这触及了**"涌现(Emergence)"**理论。
最后留给你的思考(来自社会学家):
如果未来那个"完美的机器人"站在你面前,拥有你所有的记忆、习惯和思考方式,而且比你更理智、更强壮。你会把它当作你的"同事",还是你的"替代品"?
这就是 Generative Agents 最终极的哲学拷问。
(2) MetaGPT: 多智能体 SOP
💡 将现实世界的"标准作业程序 (SOP)"引入 Agent 团队,通过产品经理、架构师、工程师的角色分工来开发软件。
🔍 定义: 单个 Agent 写代码容易错,但一家软件公司(包含产品经理、架构师、工程师、测试)不仅能写出代码,还能保证质量。MetaGPT 的核心思想是将现实世界的 SOP (标准作业程序) 引入 Agent 协作。
🔍 机制:
- 角色分工 (Role Playing):
- Product Manager: 分析用户需求,输出 PRD (需求文档)。
- Architect: 基于 PRD 设计系统架构,输出 API 接口文档 和 UML 图。
- Project Manager: 分配任务。
- Engineer: 只看设计文档写代码,不直接看模糊的用户需求。
- QA: 编写测试用例,运行代码并报错。
- 结构化通信 (Structured Communication): Agent 之间不是像聊天群一样闲聊,而是通过文档和图表交流。上游的输出(如 PRD)是下游的输入。
- 发布-订阅机制: 类似于消息队列,Agent 监听自己感兴趣的文档更新,一旦上游发布文档,下游自动开始工作。

应用现状与场景
- 场景:
- 全自动软件开发: 输入一句话"写一个贪吃蛇游戏",MetaGPT 会自动生成代码文件、依赖库、设计文档。
- 复杂调研任务: 这是一个调研团队。Agent A 搜集资料,Agent B 整理大纲,Agent C 撰写报告,Agent D 查重润色。
- 自动化运维 (AIOps): 监控 Agent 发现警报 -> 诊断 Agent 分析日志 -> 修复 Agent 执行脚本。
- 应用 / 现状 :
- MetaGPT (开源框架): 极其火爆的 GitHub 项目,是目前 Multi-Agent 开发的首选框架之一。
- ChatDev: 清华大学推出的类似项目,模拟软件开发公司的虚拟聊天室。
- 企业内部研发提效: 许多大厂正在用此类架构辅助生成样板代码或进行代码审查。
在我看来这个认知框架更多的表现像是一个工具,它拥有我们人类在工作中的SOP机制,这是最大的核心,其中的内置模型可能有其它的能力,更多的表现还是辅助能力或者是标准化作业,创造性欠佳。
(3) Voyager: 终身学习者
💡 结合了技能库机制,Agent 在探索(如玩 Minecraft)中学会的代码会被封装成技能存入向量库,实现能力的持续积累。
🔍 定义: Voyager 是 NVIDIA 提出的首个具身终身学习 (Embodied Lifelong Learning) Agent。之前的 Agent 玩游戏是每一局重新开始,而 Voyager 能积累技能。
🔍 机制:
- 自动课程 (Automatic Curriculum): Agent
自己决定下一步学什么。由易到难,先学"砍树",再学"做工作台",最后学"挖铁矿"。 - 技能库 (Skill Library) - 核心创新:
- 当 Agent 成功完成一个动作(例如做了一把石镐),它会将这段代码(JavaScript API 调用)
封装成一个函数。 - 这段代码被存入 向量数据库。
- 下次遇到类似任务时,
直接检索并调用这个技能,而不需要重新思考如何写代码。这是能力的固化。
- 当 Agent 成功完成一个动作(例如做了一把石镐),它会将这段代码(JavaScript API 调用)
- 迭代提示机制 (Iterative Prompting): 写代码 -> 运行 -> 报错 -> 把错误信息喂回给 LLM -> 修正代码。

应用现状与场景
-
场景:
- 开放世界游戏 (Open-ended Games): Minecraft, Roblox 等没有固定通关路径的游戏。
- 机器人控制 (Robotics): 机器人通过模拟环境训练,学会"抓取"、"开门"等技能,并将这些动作封装成库,遇到新任务时组合旧技能。
- 自动化办公/RPA: 学会"登录SAP系统"、"导出Excel"等技能,并随着时间推移积累越来越多的自动化脚本库。
-
应用 / 现状:
- NVIDIA 具身智能研究: Voyager 是具身智能(Embodied AI)的重要基石。
- 通用控制代理: 类似架构正在被尝试用于操作操作系统(Computer Use)。
(4) MemGPT: 操作系统式记忆
💡 通过分页机制管理上下文,区分"主存"和"外存",让 Agent 能够处理无限长度的文档或进行永不遗忘的对话。
🔍 定义: 随着对话变长,LLM 很快会忘记前面的内容(超出 Context Window)。MemGPT 创造性地将 LLM 视为 CPU,将上下文窗口视为 RAM(主存),将外部数据库视为 Disk(外存)。
🔍 机制:
- 分层记忆架构 :
- Main Context (主存): 当前 LLM 能直接看到的 Prompt 窗口(昂贵、有限)。
- External Context (外存 ):
- Recall Memory: 历史对话记录(数据库)。
- Archival Memory: 大量文档、用户画像(向量数据库)。
- 系统调用 (Function Calls): LLM 可以自主决定"我要记住这个"或"我要查一下那个"。它通过生成特殊的函数调用来管理记忆:
- core_memory_append: 把关键信息写入主存(如用户的名字)。
- archival_memory_search: 去外存里翻阅旧资料。
- send_message: 回复用户。
- 自我编辑: 当主存快满时,MemGPT 会自动触发整理,把不重要的挪到外存,把重要的留在主存。
这种机制有点类似于人类的记忆处理机制,我们的大脑也会进行类似的整理,将大部分无用的记忆进行主动遗忘,重要的信息进行存储,随着时间的流逝,我们也会渐渐的忘记一些不是那么重要的。

应用现状与场景
- 场景:
- 长期伴侣/心理咨询: 用户聊了一年,Agent 依然记得你半年前提到的童年阴影(因为存入了 Archival Memory)。
- 超长文档分析: 上传几百兆的技术手册,MemGPT 可以通过分页读取和检索,回答关于手册任何细节的问题。
- 无限对话: 永远不需要"清空上下文"。
- 应用 / 现状 :
- MemGPT.ai: 已经商业化,提供 API。
- LangChain (Memory模块): 借鉴了类似思想,提供 SummaryBufferMemory 等机制。
- 所有下一代 Personal AI: 如 Apple Intelligence 或高级助手,必须具备这种"分级存储"能力才能真正实用。
三、Agent认知框架总结(重点!!!)
一、不同框架的实用性
💡 首先我们要清楚商用框架的一个最核心要求"性价比",即使你的框架能完美的完成任务,但是消耗的Token太多,这就导致你的成本太高,也就意味着用户量很少,挣不到钱。所以说在上面的这么多框架中,有一部分实际上不会使用,我们进行简单的区分。
-
第一梯队:工程化落地标准(基石)
- ReAct : 这是目前 90% 的 Agent 的底座。它是最符合直觉的"思考-干活"循环。
- Plan-and-Execute : 处理复杂任务的标配。必选。
- RAG 变体 (Self-RAG): 企业知识库必用,必须要控制幻觉。
- MetaGPT/SOP : 在企业内部流程自动化(如自动化运维、周报生成)中非常成熟。
-
第二梯队:特定场景的高级组件(即插即用)
- Reflexion : 非常适合代码生成场景,成本可控,效果显著。
- LLMCompiler / ReWOO : 追求速度和并发时的优化手段,不算独立架构,更像优化补丁。
-
第三梯队:
概念性/已逐渐被融合(不再单独提及)- BabyAGI : 它是"自主Agent"的鼻祖,但原始代码太简陋,容易死循环。现在的 Agent 借鉴了它的"自动拆解任务"思想,但不再直接使用那个框架。
- HuggingGPT : 这是一个 Demo 级别的项目,太慢了。现在的 Function Calling (Tool Use) 已经完全替代了它的核心逻辑。
- CoT / Self-Ask: 这现在是 Prompt Engineering 的一部分,不再被视为独立的 Agent 架构。现在的模型(如 GPT-4)默认就在做 CoT。
补充:
虽然 GoT ** 和 ToT ** 很强,但在实时对话中几乎不可用(太慢)。但在离线数据处理(比如医药研发、数学证明辅助)中,它们依然是核心算法。
二、应用范围与未来趋势
从市场趋势来看,未来属于 快慢结合 和 多智能体协作。
-
应用最多的(当下):ReAct + RAG
- 这是客服机器人、办公助手、文档问答的标准解法。
-
应用最多的(未来 1-2 年):LATS / SwiftSage
- 理由: 用户不再满足于"聊几句",而是需要 Agent 真正解决复杂问题(如写一个完整的 App)。这就需要 LATS 的回溯能力 (写错了自己改)和 SwiftSage 的成本控制(简单的不花大钱,难的深度思考)。
- OpenAI o1 模型 的出现证明了 System 2 (慢思考/LATS 逻辑) 是提升推理能力的必经之路。
-
企业级爆发点:MetaGPT / Multi-Agent
- 单打独斗的 Agent 也就是个实习生水平。能通过 SOP 把多个 Agent 串起来干活,才是企业愿意买单的方案。
三、不同Agent是否可以互相配合
场景模拟:构建一个"超级编程助手"
如果只用 ReAct,它写错代码就卡住了;如果只用 Plan-and-Execute,它无法应对执行中的突发变故。
最佳实践是组合:
- 顶层指挥: 使用 Plan-and-Execute (#3)。用户输入需求后,先生成一个宏观计划(1. 建环境,2. 写后端,3. 写前端)。
- 执行层: 每一个子任务(如"写后端")分配给一个 LATS (#12) Agent。因为它在写代码时需要极强的回溯和纠错能力。
- 记忆层: 整个系统挂载一个 MemGPT (#17) 风格的共享记忆库,存储用户偏好和项目文档。
- 质量控制: 在交付前,引入 CRITIC (#15) 角色,运行单元测试并进行代码审计。
结论: 框架不是互斥的,它们是不同层面的组件。
- 认知层: CoT, Reflexion
- 调度层: ReAct, Plan-and-Execute
- 架构层: MetaGPT, SwiftSage
四、LangChain/LangGraph 是否可以达到企业级需求
- LangChain (旧时代): 早期的
AgentExecutor是写死的 ReAct 循环,想魔改很难。 - LangGraph (新时代): 它是基于图(Graph)的状态机。
实操演示:如何在 LangGraph 中实现 ReAct + LATS?
可以定义一个图,其中包含不同的节点(Node):
-
Node A (Router): 这是一个轻量级分类器(SwiftSage 的 System 1)。
- 如果是简单打招呼 -> 走 Node B (直接回复)。
- 如果是写代码 -> 走 Node C (进入复杂推理)。
-
Node C (LATS Sub-graph): 这里可以手写 LATS 的逻辑。
- 在 LangGraph 中,可以保存 State(状态),包含当前的树结构。
- 可以定义一个循环:
Generate->Reflect->Backtrack。 - 这完全是可编程的 python 函数。
-
Node D (Tools): 传统的 ReAct 工具调用。
结论: 在 ReAct 的基础上增加 LATS 的优势,在 LangGraph 里就是:在 ReAct 的 Loop 里,当遇到特定类型的错误或任务时,挂载一个 LATS 的子图进行深度搜索。 这完全可行,也是目前高端 Agent 开发的标准姿势。
五、市面上的 Agent 底层
它们通常是:基础框架的深度魔改 + 业务逻辑的堆叠。
-
Devin (最强程序员 Agent):
- 它肯定不是单纯的 LATS。它极有可能结合了:
- Plan-and-Execute: 维护一个动态的任务列表。
- Voyager (#19): 拥有一个庞大的代码库/技能库,遇到问题先查库。
- Browser环境: 类似于 Sandbox。
- LATS/Reflexion: 在写代码这一具体动作上,使用了多步推演和自我修正。
- 它肯定不是单纯的 LATS。它极有可能结合了:
-
ChatGPT (Browse with Bing):
- 它是典型的 CRITIC (#15) + ReAct。
- 生成搜索词 -> 搜索 -> 阅读 -> 引用 -> 自我检查相关性 -> 生成回答。
-
- 它是 LLMCompiler (#8) + Self-RAG (#14) 的极致优化。
- 并发搜索多个源(速度快),然后对搜索结果进行严格的自我评判(质量高)。
总结:
商业产品是在基础框架之上,增加了大量的 Heuristics(启发式规则) 和 Guardrails(护栏)。他们会吸取 LATS 的"树搜索"思想,但为了省钱和速度,可能会把树的深度限制在 2 层;他们会吸取 Reflexion 的思想,但最多只允许重试 3 次。
一句话总结:Agent 的未来不在于单一算法的胜出,而在于针对场景的精妙编排 (Orchestration)。