Agent四大核心组件

把Agent想象成一家公司。LLM就是这家公司的CEO：

• CEO负责听取汇报（理解输入）、分析形势（评估状态）、做出决策（选择行动）、发出指令（调用工具）
• 但CEO不亲自去搬货、不亲自打电话——那些是员工（工具）的工作
• CEO越聪明，公司运转越好；CEO水平不行，再多员工也白搭

LLM在Agent中承担五项核心职责：

LLM能充当Agent大脑，依赖于前面几章介绍的几项基础能力：理解自然语言、进行推理（尤其是大参数模型）、遵循复杂指令、生成结构化输出（如JSON格式的工具调用指令）。这些能力的组合，使它从一个"文字预测器"升级为一个能协调多个组件的"指挥中心"。

但LLM单独并不能成为Agent——它只会"想"，不会"做"。就像CEO只能做决策，不能替代所有员工一样。

"换一个更强的LLM，Agent就一定更好"

这句话只对了一半。LLM的能力确实决定了Agent的上限——大脑不够聪明，规划再好也执行不了。但Agent的表现还取决于记忆设计、工具配置和规划策略。一个用GPT-4但工具配置混乱的Agent，可能不如一个用GPT-3.5但工具精心设计的Agent表现好。

不同LLM作为Agent大脑的能力差异显著：

一个关键认知：Agent的能力上限，很大程度上取决于LLM大脑的能力。选择合适的LLM时，需要权衡任务复杂度、成本和响应速度。

想象一个没有记忆的助手：

• 你刚告诉它"我要去上海"，下一句它就忘了你要去哪
• 每次对话都要重新说一遍你的偏好（靠窗座位、不吃辣）
• 一个复杂任务做到一半，它不记得前面做了什么

这就像一条金鱼——每几秒钟世界都是全新的。这样的助手显然没法用。

Agent的记忆分为两种，各自解决不同的问题。

把Agent的记忆想象成图书馆里的工作场景：

• 短期记忆 = 你书桌上正在看的几本书。容量有限，但随手就能翻到。工作结束后书会放回去。
• 长期记忆 = 图书馆的所有藏书。数量庞大，但你需要去书架上找，或者请图书管理员帮你检索。
• 检索过程 = 图书管理员根据你的需求，从海量藏书中找出最相关的几本，放到你的书桌上。

长期记忆的技术实现依赖一项关键技术——向量数据库。

传统数据库按关键词搜索：搜"苹果"只能找到包含"苹果"两个字的内容，搜不到"iPhone"（虽然语义相关）。

向量数据库按语义搜索：搜"苹果手机"能找到"iPhone"、"iOS设备"等相关内容——因为它们在"意思"上是接近的。

工作原理（简化版）：

1. 把每段文字转换成一串数字（向量）——可以理解为给文字在"意义空间"中标注一个坐标
2. 意思相近的文字，坐标也接近
3. 搜索时，把你的查询也转换成坐标，找距离最近的内容

这就像一个智能图书馆：不是按书名首字母排列，而是按内容主题排列。关于烹饪的书不管书名是什么，都会被放在一起。

两种记忆在实际使用中协同配合：

【新对话开始】

用户：帮我订去上海的机票

Agent内部流程：
1. 检查长期记忆："这个用户之前说过喜欢东航、靠窗座位"
2. 将这些信息加载到短期记忆（书桌上）
3. 结合当前请求，搜索航班
4. 优先推荐东航、靠窗座位的选项

Agent回复：根据您之前的偏好，我为您找到了以下东航航班，
         均有靠窗座位可选...

关键流转：长期记忆存储偏好 → 新对话时检索相关信息到短期记忆 → 短期记忆用于当前任务决策。

回顾前面章节讨论的LLM局限：知识有截止日期、不能上网、不能执行代码、不能操作外部系统。没有工具的Agent就像一个被关在房间里的聪明人——想法很多，但什么也做不了。

Agent的工具按功能分为三大类：

信息获取类——让Agent能"看到"外部信息：

操作执行类——让Agent能"动手"做事：

专业领域类——面向特定场景的能力：

工具调用的背后是一项叫做Function Calling的技术。它的核心思想是：LLM不直接执行操作，而是输出一条结构化指令，由外部系统真正执行。

以"今天北京天气怎么样？"为例：

Step 1: LLM理解请求
  → 用户想知道北京今天的天气

Step 2: LLM决定调用工具，输出结构化指令
  → {
      "tool": "get_weather",
      "parameters": {
        "location": "北京",
        "date": "2025-01-15"
      }
    }

Step 3: 外部系统执行
  → 调用真正的天气API，获得结果：晴，3-12℃

Step 4: 结果返回给LLM
  → LLM看到天气数据

Step 5: LLM生成最终回复
  → "今天北京天气晴朗，气温3到12摄氏度，建议穿外套。"

关键点：LLM只"说"要调用什么工具（输出JSON指令），真正的执行由外部系统完成，结果再返回给LLM处理。

工具就像各种遥控器：

• Agent是使用遥控器的人——它决定什么时候按哪个遥控器上的哪个按钮
• 按下按钮（发出Function Call）= 向外部系统发出指令
• 遥控器控制的设备（API、数据库、邮件系统）才是真正做事的

Agent不需要知道空调内部怎么制冷，它只需要知道"按这个按钮就能制冷"。

让LLM通过中间层调用工具，而不是直接执行操作，是出于安全和可控性的考虑：

• 可以检查LLM的请求是否合理（比如：它是否有权限执行这个操作？）
• 可以限制危险操作（比如：禁止删除重要文件）
• 可以记录所有操作日志（方便追溯和审计）
• 出问题时可以追溯原因

这就像公司的审批流程：员工（LLM）提出请求，审批系统（中间层）检查是否合规，合规则执行，不合规则拒绝。

"工具越多，Agent越强"

不一定。工具太多会带来问题：LLM可能选错工具、决策时间变长、系统复杂度增加。更好的做法是根据任务需要配置合适的工具集，并为每个工具写清晰的描述，让LLM知道什么情况下该用哪个工具。

假设你让Agent"帮我查一下明天北京有没有雨，如果有就提醒我带伞"。Agent需要用到两个工具：

1. 天气查询工具：调用天气API，获取明天北京的天气预报
2. 提醒工具：设置一条明早的提醒消息

没有这两个工具，Agent即使理解了你的意图、制定了完美的计划，也只能回答"我建议你查一下天气预报"——它无法替你做任何事。

没有规划的Agent面对复杂任务会陷入混乱：

• 用户说"帮我组织生日派对"，Agent不知从何下手
• 可能先去订蛋糕，但还没确定日期和人数
• 可能重复做某些事，遗漏另一些事
• 步骤之间缺乏逻辑顺序

有规划的Agent则会先把大任务拆解：确定基本信息 → 场地安排 → 餐饮准备 → 邀请宾客 → 活动策划，然后按依赖关系有序执行。

规划模块就是Agent的"内部项目经理"：

• 接到一个大项目（用户的复杂请求）
• 拆分成若干里程碑和具体任务
• 安排执行顺序（哪些可以并行，哪些有先后依赖）
• 跟踪进度，遇到问题及时调整

规划能力的本质来源于LLM的推理能力。当LLM足够强大时，它能够：

• 预测任务的步骤：基于训练中见过的大量任务处理模式
• 识别步骤间的依赖：知道哪些事情必须先做
• 评估执行结果：判断当前步骤是否成功
• 动态调整计划：根据新信息修改后续步骤

但规划能力直接受限于LLM的推理能力——大脑不够聪明，规划也不会好。

"Agent的规划总是完美的"

现实中，Agent的规划能力有明显的局限：

因此，对于重要任务，人类监督仍然必要。当前阶段，Agent的规划更适合辅助人类，而非完全替代人类的判断。

用户请求："帮我安排一次搬家"

大任务：搬家

分解：
  1. 盘点物品 → 列出需要搬的东西
  2. 准备打包 → 购买纸箱和胶带
  3. 分类打包 → 按房间/类别打包
  4. 联系搬家公司 → 比较报价，预约时间
  5. 搬运执行 → 当天协调搬运
  6. 新家整理 → 拆箱归位

依赖关系：1必须最先完成 → 2和4可以并行
→ 3在2之后 → 5在3和4之后 → 6最后

把四大组件想象成一家运转良好的公司：

CEO不会事必躬亲，而是听取秘书的汇报、让项目经理排计划、派员工去执行。四个角色缺一不可。

四大组件的协同遵循一个循环流程：

感知（接收输入）
  → 规划（拆解任务）
    → 记忆（检索相关信息）
      → 工具（执行操作）
        → 反馈（评估结果）
          → 回到规划（继续下一步或调整）
            → ...直到任务完成
              → 生成最终回复

                    ┌─────────────────┐
                    │    用户输入请求   │
                    └────────┬────────┘
                             ↓
┌────────────────────────────────────────────────┐
│                  大脑（LLM）                     │
│  ┌──────────────────────────────────────────┐  │
│  │ 1. 理解请求                               │  │
│  │ 2. 检索记忆 ←──── 记忆系统                │  │
│  │ 3. 制定规划 ←──── 规划能力                │  │
│  │ 4. 选择工具 ←──── 工具库                  │  │
│  │ 5. 生成回复                               │  │
│  └──────────────────────────────────────────┘  │
└───────────────────────┬────────────────────────┘
                        ↓
          ┌─────────────┴─────────────┐
          ↓                           ↓
    ┌─────────────┐            ┌─────────────┐
    │  执行工具    │            │  更新记忆    │
    └──────┬──────┘            └─────────────┘
           ↓
    ┌─────────────┐
    │  返回结果    │
    └─────────────┘

用户请求："帮我查一下明天北京的天气，如果下雨就提醒我带伞"

【规划阶段】
大脑（LLM）思考：
  1. 查明天北京的天气
  2. 判断是否下雨
  3. 如果下雨，设置提醒

【执行阶段 - 步骤1】
大脑 → 调用天气工具 → 查询API → 返回结果：明天北京，小雨，12-18℃

【记忆更新】
短期记忆：记录天气查询结果

【执行阶段 - 步骤2】
大脑分析："小雨" → 确认需要提醒

【执行阶段 - 步骤3】
大脑 → 调用提醒工具 → 设置明早提醒"记得带伞"

【长期记忆更新】
存储：用户关心北京天气（可能是常住城市）

【生成回复】
大脑综合信息：
"明天北京有小雨，气温12-18℃。我已为您设置了明早的提醒，
 会提醒您带伞。"

在这个过程中，四个组件各司其职：大脑理解意图并做决策，规划拆分出三个步骤，工具查天气和设提醒，记忆保存中间结果和用户偏好。

四大组件架构不是Agent的唯一设计方式，但它是目前最主流的理解框架。在后续章节中会看到具体的实现模式——比如ReAct框架（思考-行动-观察的循环），就是四大组件协同的一种具体表现形式。

如果你要设计一个"个人理财Agent"，它需要哪些工具？请列出至少5个，并说明每个工具的用途。

为什么说"LLM的能力决定了Agent的上限"？试举一个具体例子：一个能力较弱的LLM作为Agent大脑时，在什么场景下会暴露不足？

分析以下任务中四大组件各自的作用："帮我写一封邮件给老板请假"。请分别说明LLM大脑、记忆系统、工具和规划各承担什么职责。

观察你日常使用的AI工具（如ChatGPT的联网搜索、代码解释器功能），思考：它用了哪些"工具"？这些工具属于信息获取类、操作执行类还是专业领域类？