Agent 不只是一个更长的 Prompt——读《LLM Powered Autonomous Agents》

原文：Lilian Weng, LLM Powered Autonomous Agents
链接：https://lilianweng.github.io/posts/2023-06-23-agent/

这篇文章主要是我读完原文之后的整理和理解。

1. 为什么还要读这篇文章？

Lilian Weng 的《LLM Powered Autonomous Agents》写于 2023 年。放在今天看，它当然不算“最新”，但我觉得它仍然值得读。原因不是里面列举的每个案例都还站在前沿，而是它把 Agent 这个当时还很混乱的概念，拆成了一个相对清楚的系统结构。

很多人一开始理解 Agent，会把它理解成“更聪明的聊天机器人”，或者“一个更长、更复杂的 Prompt”。但这篇文章其实在说另一件事：

Agent 不是让模型多说一点，而是让模型开始围绕一个目标持续行动。

普通 ChatBot 更像这样：

用户提问 → 模型回答

而 Agent 更接近这样：

用户给出目标
  ↓
模型理解目标
  ↓
拆成若干步骤
  ↓
调用工具
  ↓
观察结果
  ↓
修正计划
  ↓
继续执行

这个差别非常关键。ChatBot 的重点是“回答”，Agent 的重点则是“推进任务”。它不一定每一步都对，也不一定真的自主，但它已经从单次问答，变成了一个带状态、带工具、带反馈循环的执行系统。

所以这篇文章最有价值的地方，不是给了一个万能定义，而是帮我们看清楚：当我们说 Agent 的时候，到底在说哪些部件、哪些能力，以及这些能力之间怎么配合。

2. Agent 的基本结构

原文把 LLM-powered autonomous agent 拆成几个核心组件：

Agent = LLM as Brain
      + Planning
      + Memory
      + Tool Use

这句话很简洁，但信息量不小。它的意思是：LLM 可以作为“大脑”，负责理解、推理和决策；但光有大脑还不够。一个能做事的 Agent，还需要规划能力、记忆能力，以及接触外部世界的工具。

可以粗略对应成下面这样：

组件	作用
Planning	把复杂目标拆成可执行步骤
Memory	保存上下文、经验和长期信息
Tool Use	调用外部工具，获取信息或执行动作

如果用人的行为来类比，LLM 像大脑，Planning 像思考和安排事情的能力，Memory 像记忆系统，Tool Use 则像眼睛、手和工具箱。

当然，这个类比并不严谨。真实的 Agent 没有人类那种连续意识，它只是一个由模型、工具、状态和控制逻辑组成的软件系统。但作为入门理解，这个框架已经够用了。

我觉得原文最大的贡献之一，就在这里：它没有把 Agent 神秘化，而是把它拆成了可以讨论、可以实现、也可以质疑的几个模块。

3. Planning：先把事情想清楚

Planning 是 Agent 的第一项核心能力。

很多任务不能靠一句回答解决。比如你让模型：

帮我搭建一个可以自动同步照片、备份到外置硬盘、并上传到云端的系统。

如果它只是像普通问答那样直接给建议，很容易变成一堆松散的方案：你可以用 iCloud，也可以用 OneDrive，也可以写脚本，也可以用 NAS。看起来信息很多，但真正要做的时候，反而不知道从哪里开始。

Agent 的处理方式应该更像是在推进一个项目。它至少要先拆任务：

1. 确认照片来源目录
2. 确认本地磁盘和外置硬盘路径
3. 选择同步工具
4. 设计同步方向
5. 确定冲突处理策略
6. 用少量文件测试
7. 设置定时任务或开机自启
8. 检查日志和异常恢复方式

这就是任务分解。它未必很高级，但非常重要。因为只要任务稍微复杂一点，模型就不能只靠“灵感式回答”，而要先把事情拆成可以执行、可以验证、可以回退的小步骤。

3.1 Chain of Thought：一步一步想

Chain of Thought，简称 CoT，是最基础的规划方式。

它的思路很直接：不要让模型马上给结论，而是让它展开中间推理过程。

问题 → 中间步骤 → 结论

CoT 的好处是，它把一个复杂问题拆成多个较小的推理单元，减少“一步到位”时犯错的概率。很多数学题、逻辑题、分析题，都会因为这个过程变得更稳定。

但 CoT 也有明显限制。它本质上还是一条线。如果一开始走错了方向，后面很可能就沿着错误方向一路推下去。模型写出来的推理过程也不一定等于真实推理，有时只是事后补出来的解释。

所以 CoT 有用，但不能迷信。它更像是让模型放慢一点，而不是让模型自动变可靠。

3.2 Tree of Thoughts：多想几条路

Tree of Thoughts，简称 ToT，可以看作对 CoT 的扩展。

CoT 是一条路径：

想法 A → 想法 B → 想法 C

ToT 则更像一棵树：

                 目标
        /         |         \
     方案 A      方案 B      方案 C
      / \         / \         / \
   A1  A2      B1  B2      C1  C2

也就是说，模型不只沿着一条思路往下走，而是在关键节点生成多个候选，再比较哪条路更值得继续。

这点很适合 Agent，因为真实任务往往不是只有一个解法。还是拿文件同步举例，Agent 可以同时考虑：

方案 A：iCloud Drive
方案 B：OneDrive
方案 C：Syncthing
方案 D：rclone
方案 E：NAS 或自建服务

每个方案都有自己的代价。iCloud 简单，但跨平台和高级控制弱一些；Syncthing 灵活，但需要理解设备发现和同步规则；rclone 强大，不过配置门槛更高。

一个好的 Agent 不应该一上来就锁死一个方案。它应该能比较成本、风险、适用场景，然后再决定下一步怎么走。

3.3 ReAct：边想边做

ReAct 是 Reasoning and Acting 的缩写。它把推理和行动放进同一个循环里：

Thought → Action → Observation → Thought → Action → Observation

更具体一点，可以是这样：

Thought: 我需要确认当前资料是否可靠
Action: 调用搜索工具
Observation: 搜索结果返回……

Thought: 这些资料不够权威，应该查官方文档
Action: 打开官方文档
Observation: 找到了版本说明和 API 文档

Thought: 现在可以整理答案了
Action: 生成总结

ReAct 很重要，因为它让模型不再只是一次性输出答案，而是可以根据外部反馈调整下一步。搜索结果不够好，就换搜索词；代码运行失败，就读报错；文件不存在，就检查路径。

这也是 Agent 和普通 ChatBot 的分水岭之一：

ChatBot 主要在语言里生成答案；Agent 则在“思考、行动、观察”的循环中推进任务。

当然，这个循环也会带来新的问题。循环可能跑偏，可能停不下来，也可能把错误观察解释成正确结论。所以 ReAct 不是魔法，它只是把模型接入了一个可以行动、也可能犯错的环境。

3.4 Self-Reflection：失败之后能不能回头看

真实任务里，Agent 不可能每一步都成功。它可能遇到：

工具调用失败
搜索结果不准确
代码运行报错
计划方向错误
任务理解偏差

Self-Reflection 想解决的是：当失败发生时，模型能不能停下来想一想，刚才到底哪里不对。

为什么失败？
是哪一步错了？
要不要换策略？
是否需要重新规划？

比如代码 Agent 修改代码后测试失败，它可以总结：

失败原因：
- 修改了函数签名，但没有同步更新调用方

下一步：
- 搜索所有调用位置
- 统一修改参数
- 重新运行测试

这个能力很实用，但也要谨慎看待。自我反思不等于可靠验证。模型可能会很自信地解释一个错误原因，但那个解释本身也是错的。

所以我更倾向于把 Reflection 看成一种“错误恢复机制”，而不是最终判断标准。它最好和外部验证配合使用，比如测试、编译器、日志、静态检查、人工审核等。能被外部世界验证的反思，才比较有价值。

4. Memory：Agent 为什么需要记忆？

普通 LLM 的“记忆”主要来自当前上下文窗口。上下文里有什么，它就能参考什么；上下文里没有，它就很难稳定记住。

但 Agent 面对的往往不是一次性问答，而是持续任务。它需要知道：

当前任务进行到哪一步
之前尝试过哪些方案
哪些方案失败了
用户有什么偏好
项目有哪些长期约定
工具调用返回过什么结果

没有记忆，Agent 就会像一个每隔几分钟就失忆的助手。它也许每次回答都挺像回事，但很难连续做一件事。

原文借用了人类记忆的分类：

Sensory Memory：感官记忆
Short-term Memory：短期记忆
Long-term Memory：长期记忆

在 LLM Agent 里，可以大致对应为：

人类记忆	Agent 中的对应
感官记忆	原始输入、文本、图片、embedding
短期记忆	当前上下文窗口
长期记忆	外部数据库、向量数据库、文件系统

这个对应关系不必理解得太死。重点是：Agent 要想持续工作，就必须有某种状态保存机制。

4.1 短期记忆：上下文窗口

短期记忆就是模型当前能直接看到的内容，比如：

当前对话
任务要求
工具返回结果
临时计划
中间推理过程

它的优点是直接。只要信息还在上下文里，模型通常就能比较自然地利用。

问题也很明显：上下文窗口是有限的。任务一长，早期信息就会被挤出去；即使没有被挤出去，模型也可能在很长的上下文里漏看关键细节。

所以短期记忆适合保存当前正在处理的信息，却不适合承担所有历史状态。

4.2 长期记忆：外部存储和检索

长期记忆通常要依赖外部存储，最常见的形式是向量数据库。基本流程大概是：

文档切块
  ↓
生成 embedding
  ↓
存入向量数据库
  ↓
用户提问时检索相关片段
  ↓
把检索结果放回上下文
  ↓
模型基于检索结果回答

这就是 RAG 的基本思想。

长期记忆可以保存很多东西：

用户偏好
历史对话
项目文档
业务规则
代码说明
错误日志
长期任务状态

但这里有一个容易被忽略的问题：向量数据库不等于真正可靠的记忆。它主要解决“怎么把相关内容找回来”，却不会自动解决下面这些问题：

记忆是否正确
记忆是否过期
记忆之间是否冲突
错误记忆是否应该删除
哪些信息值得长期保留

所以 Memory 不是“把所有东西都塞进向量库”这么简单。真正难的是信息管理：什么时候写入、怎么更新、如何遗忘、如何处理冲突，以及如何避免把一次性的误解变成长期事实。

5. Tool Use：让模型碰到真实世界

大语言模型本身有很多限制：

不知道最新信息
不能直接执行代码
不能直接访问数据库
不能操作文件系统
不能调用第三方 API
不能检查真实环境状态

这些限制决定了：如果 Agent 想做真实任务，就必须使用工具。

工具可以包括：

搜索引擎
计算器
代码解释器
文件系统
数据库
浏览器
命令行
API
其他模型
企业内部系统

Tool Use 的意义很朴素：让模型不只是“说”，而是能通过外部系统去查、去算、去执行、去验证。

这也是为什么我觉得 Agent 的关键不在于 prompt 写得多长，而在于它有没有被接入一个可控的执行环境。没有工具，模型最多是在语言里模拟行动；有了工具，它才真的开始影响外部状态。

5.1 MRKL：LLM 作为工具路由器

MRKL 是一种典型的工具增强架构。它的流程大致是：

用户问题
  ↓
LLM 判断问题类型
  ↓
选择合适工具
  ↓
工具执行
  ↓
LLM 整合结果

例如：

数学问题 → 计算器
最新新闻 → 搜索引擎
代码问题 → Python 执行器
天气问题 → 天气 API
企业数据 → 内部数据库

在这种架构里，LLM 不一定亲自解决所有问题。它更像一个调度器：判断该找谁、该传什么参数、拿到结果后再怎么组织给用户。

这个思路很自然。我们人类工作时也不是所有事情都靠脑算：要查资料就打开搜索，要算账就用表格，要确认代码就跑测试。Agent 也是一样。

5.2 Toolformer：模型要知道什么时候用工具

Toolformer 关心的问题是：

模型如何学会在合适的时候主动调用工具？

这件事比“有没有工具”更难。一个 Agent 真正需要判断的是：

什么时候该用工具
该用哪个工具
参数怎么填
工具返回后怎么解释
工具失败后怎么恢复

工具多并不等于能力强。一个不会正确调用工具的 Agent，就像桌上摆满设备却不知道先按哪个按钮的人。它可能每一步都在行动，但行动本身没有带来更可靠的结果。

所以 Tool Use 的核心不是“接更多 API”，而是让模型在合适的时机，以合适的方式调用合适的工具。

5.3 HuggingGPT：LLM 作为任务调度器

HuggingGPT 是原文里提到的一个典型案例。它让 ChatGPT 作为控制中心，调用 HuggingFace 上的不同模型来完成任务。

流程大致是：

1. Task Planning：拆解任务
2. Model Selection：选择模型
3. Task Execution：执行模型
4. Response Generation：整合结果

这个案例说明，Agent 不一定由一个模型完成所有事情。LLM 可以扮演调度者，把不同子任务分配给更专门的模型或工具。

这其实也很符合现实工程里的分工方式：一个系统里可以有负责规划的模型、负责视觉识别的模型、负责代码执行的工具、负责检索的数据库。Agent 是把它们组织起来的控制层。

6. Case Studies：几个典型案例

6.1 ChemCrow：专业领域需要专业工具

ChemCrow 是一个面向化学任务的 Agent。它把 LLM 和化学工具结合起来，用于有机合成、药物发现、材料设计等任务。

这个案例给我的提醒是：专业领域不能只靠模型“看起来懂”。在化学、医学、法律、金融这些场景里，一个方案是否正确，不能只靠语言流畅度判断，更不能只靠模型自己说“我觉得没问题”。

所以专业 Agent 的价值，往往不只是回答问题，而是把 LLM 接到专业工具、专业数据库和专业评估流程里。LLM 负责理解任务、组织步骤、解释结果；真正的验证还要交给更可靠的外部机制。

6.2 Generative Agents：带记忆和规划的虚拟角色

Generative Agents 是一个很有意思的实验。研究者构建了一个类似《模拟人生》的沙盒环境，里面有多个由 LLM 驱动的角色。

这些角色可以：

记住过去发生的事
形成对其他角色的印象
安排自己的日程
和其他角色互动
传播信息
组织活动

这个案例说明，如果给 LLM 加上记忆、检索、反思和规划，它确实可以表现出更连续、更像“个体”的行为模式。

但我觉得这里也需要降一点温。它不意味着 Agent 拥有意识，也不意味着它真的在像人一样生活。更准确地说，这是一个由记忆和规划机制驱动出来的行为模拟系统。

这个边界很重要。因为 Agent 的表现可以越来越像人，但它背后的机制仍然是系统设计，而不是自然产生的主体性。

6.3 AutoGPT：概念很强，但工程上很脆

AutoGPT 当年之所以火，是因为它展示了一个特别吸引人的想法：

给 AI 一个目标
让它自己规划
自己搜索
自己执行
自己修正
直到完成任务

这个想法很迷人，因为它几乎就是很多人想象中的“自主 AI 助手”。但真正用过之后也会发现，它暴露了早期 Agent 的一堆问题：

容易跑偏
容易循环
上下文容易爆掉
工具调用不稳定
缺少可靠停止条件
执行成本不可控
结果难以验证

所以 AutoGPT 更像是一个重要的概念验证，而不是成熟的生产系统。它证明了这条路有吸引力，也顺手证明了：只靠一个大 prompt 加一个自动循环，离可靠 Agent 还差得很远。

7. 这篇文章真正想告诉我们什么？

读完整篇文章后，我觉得它真正想讲的不是某个具体框架，而是一种系统观：

Agent 不是一个更长的 prompt，而是一个以 LLM 为核心控制器，结合规划、记忆、工具和反馈循环的系统。

它的基本结构可以总结为：

Agent = LLM as Controller
      + Planner
      + Memory
      + Tools
      + Feedback Loop

其中：

Planner 决定下一步做什么
Memory 决定应该参考什么历史信息
Tools 让模型接触外部世界
Feedback Loop 让模型根据结果修正行动

这几个部分组合在一起，Agent 才从“会回答问题”变成“能推进任务”。也正因为如此，Agent 的难点从来不只是 prompt 技巧，而是系统工程：状态怎么存、工具怎么管、权限怎么控、错误怎么恢复、结果怎么验证。

8. 总结

Lilian Weng 这篇文章之所以经典，是因为它在 Agent 概念还比较混乱的时候，把几个根本问题摆了出来：

如何规划？
如何记忆？
如何调用工具？
如何根据反馈修正？
如何完成长期任务？

它让我们意识到，Agent 不是“更会聊天的模型”，而是围绕 LLM 构建出来的任务执行系统。

如果用一句话概括：

ChatBot 是回答者，Agent 是执行者。

再准确一点：

Agent 是围绕 LLM 构建的规划、记忆、工具调用和反馈修正系统。

这也是我认为这篇文章最值得学习的地方。它没有把 Agent 讲成一个玄学概念，而是把它拉回到可以被设计、实现和验证的系统里。

Agent 不只是一个更长的 Prompt