人人都会AI编程

24.3 Agent 智能体：工具调用、规划、记忆的实现逻辑

更新时间：2026-07-09

在第 24 章的前两节中，我们分别讨论了提示工程（24.1）和 RAG（24.2）。它们各自解决了一部分 LLM 的天然短板：提示工程让模型“按套路出牌”，RAG 给模型接上了“外部知识库”。但真实世界的任务往往既需要查资料，又需要操作外部系统，还需要多步逻辑推理，同时得记住整个过程中的关键信息。这就需要一个更上层的抽象——Agent（智能体）。

你可以把 Agent 理解为：以 LLM 为大脑，以工具为手脚，以记忆为笔记本，以规划为思考路径的自主问题解决系统。本节将拆解这四大核心要素的实现逻辑，帮助你理解如何从单次问答走向真正的“委托式任务执行”。

一、智能体（Agent）的整体范式

传统的 LLM 调用是“一问一答”的静态模式。Agent 将它升级为 “思考-行动-观察-再思考”的循环。其核心架构可以总结为：

Agent = LLM + 记忆 + 工具 + 规划

在这个循环中，LLM 不再是孤立的文本生成器，而是一个能够：

  1. 分析当前状态（包括记忆中的历史信息）；
  2. 决定是否调用工具、调用哪个工具、传什么参数；
  3. 根据工具返回结果调整下一步行动；
  4. 反复迭代直到认为任务完成，产出最终答案。

这与 RAG 的关键区别在于：RAG 通常是一次性的检索增强（先查再答），而 Agent 可以进行多轮、多工具、有状态的闭环操作。

二、工具调用（Tool Use）：让 LLM 长出手脚

工具调用是 Agent 能“做事”的基础，也是 1.3 节提到过的 LLM 核心能力边界扩展。它的实现逻辑分为三步：

1. 定义工具与函数签名

你需要用结构化的方式告诉模型“你能用什么工具”。这通常是一个 JSON Schema 列表，描述每个工具的：

  • 名称（如 search_web、send_email）
  • 功能描述（一句话说明，如“搜索互联网获取最新信息”）
  • 必填/可选参数及类型（query: string、recipient: string）
  • 预期的返回结果格式

2. 让模型输出“工具调用指令”

这是 Function Calling 能力的核心。支持此能力的 LLM（如 GPT-4、Claude 3、Qwen 等）经过专门的指令微调，能够在需要时生成一段特殊的结构化响应，而不是普通文本。例如：

{
  "tool": "search_web",
  "arguments": {
    "query": "2024年诺奖物理学奖得主"
  }
}

实现上，你可以选择原生Function Calling API（OpenAI、Anthropic等均提供），或者基于Prompt的手工解析（对于小开源模型，在系统提示中约定输出特定格式的JSON，然后由程序解析）。

3. 执行、获取结果、回传

程序解析到这个指令后，由你的应用程序（而非模型）去实际调用工具。获取结果后（比如搜索引擎返回的文本片段），将其格式化为“观察结果”重新喂给模型。模型基于这个新信息继续生成下一步思考或最终答案。

生产环境的关键陷阱：

  • 参数幻觉：模型可能编造一个城市名作为 location 参数，而该城市并不存在。必须在接收参数时做业务合法性和类型校验。
  • 危险操作：永远不要让模型直接控制涉及资金、账号删除、物理设备的工具，至少保留“人类确认”或严格的权限白名单。
  • 超时与重试：外部 API 可能超时。你的 Agent 逻辑必须处理失败情况，并决定是重试、降级（换一个工具）还是向用户汇报。

三、规划（Planning）：多步任务的“思考路径”

面对一个复杂任务（比如“帮我做一份竞品分析，包括市场占有率、产品对比，并生成PPT大纲”），模型不可能一次性调用工具就完成。它必须分解任务、编排步骤。

这是目前 Agent 最活跃的研究领域，也是实现最难的部分。业界主流方案有两种：

1. ReAct（Reasoning + Acting）

基本模式是让模型在每一步输出时，先产出思考（Thought），再产出动作（Action），然后进入观察，如此循环。

思考：我需要先了解当前有哪些主要竞品。
动作：search_web("2024 新能源汽车 市场份额")
观察：[搜索结果1]：比亚迪占35%...
思考：知道了前三名是比亚迪、特斯拉、蔚来。接下来我需要比较它们的价格和续航。
动作：product_compare(["比亚迪Model X","特斯拉Model Y","蔚来ET5"])
...
思考：信息足够，我可以开始汇总了。
最终答案：根据分析，市场占有率...

这个循环直接利用了 LLM 自回归生成的特点，每一步预测都基于之前的所有“思考-行动-观察”串联。它无需额外的规划模型，所有逻辑由 LLM 本身承担。

2. Plan-and-Execute（先规划后执行）

让模型先一次性生成完整的计划清单，然后再逐步执行。这可以减少上下文中的频繁交互，但要求模型对任务有较强的整体把控能力。

用户：帮我做一份竞品分析
模型计划：
1. 搜索2024年市场份额数据
2. 列出前三名产品的参数对比
3. 生成PPT大纲
4. 总结分析要点

然后程序逐一执行计划项，每步获取结果后自动填入计划表。

现实中的折中：目前 ReAct 仍是实际应用更可靠的方式，因为它允许动态修正。Plan-and-Execute 在任务比较确定时可以降低延迟，但模型容易“高估”自己的能力，生成无法执行的步骤。

开发中的实操要点：

  • 最大循环次数限制：防止模型陷入死循环或过度思索。一般设置为 8–15 次。
  • 早期终止条件：当模型输出“最终答案”标记或调用一个名为 finish 的工具时，停止循环。
  • 上下文长度管理：多轮调用会堆积大量历史信息，当接近模型上下文窗口上限时，需要自动压缩或摘要历史（见下一节记忆）。

四、记忆（Memory）：超越单次会话的能力

没有记忆的 Agent 就像每天失忆的人，无法完成需要跨时间、跨会话保持状态的任务。记忆系统通常分为三个层次：

1. 短期记忆（Working Memory）

即当前对话的完整历史，包含所有的用户输入、模型输出、工具调用结果。这天然依托于 LLM 的上下文窗口。这是最直接、最可靠的信息来源，也是 Agent 能够“随时知道发生了什么”的根本。

实现细节：你需要在程序中维护一个 messages 列表，严格按照 Role（system/user/assistant/tool）追加消息。每次请求 LLM 时，都将整个消息列表发送过去（或发送滑动窗口内的最近 N 条）。注意：上下文窗口大小（如 128K）是物理上限，成本与延迟也随长度增长，必须配合以下机制。

2. 长期记忆（Long-term Memory）

当对话跨会话（如用户第二天回来）或者需要记住用户的永久性信息（偏好、身份、历史决策）时，必须将信息外存。实现范式非常接近 RAG，但记忆的数据结构更丰富：

  • 存储：将关键信息（用户偏好、重要事件、计划中的中间结果）转化为文本，通过 Embedding 存入向量数据库；也可以存入结构化数据库（如存储user_id: "张三", preferred_language: "中文"）。
  • 检索：在每次新会话或关键步骤时，根据当前问题/用户 ID 从记忆中检索相关条目，作为额外上下文注入系统提示或消息列表。
  • 更新：Agent 发现新信息或用户偏好改变时，主动调用一个“记忆更新”工具，将新信息写入外部存储。

实用实现：MemGPT（现称 Letta）等框架尝试让模型自己管理记忆，即模型可以调用一个 update_memory 函数存储关键信息，并在需要时主动检索。但在初级阶段，你也可以简单地让模型在每次对话结束时输出一段摘要，下次对话开始时作为系统提示的前置信息。

3. 元记忆与反思

更高阶的 Agent 会在后台异步运行“反思”机制：定期回顾近期的交互历史，提取高层次的通用经验或修正自己的行为模式。这类似于对人类“慢思考”的模拟，但实现复杂度极高，目前多见于研究性项目。

对开发者而言：先从“会话级短期记忆 + 跨会话时手动保存关键信息”开始，再逐步引入向量记忆。不要一开始就追求全自主记忆，因为模型对记忆的插入和检索仍然不可靠。

五、一个综合示例：客服 Agent 的全流程

假设你要构建一个电商客服 Agent，它能处理用户的订单查询、退换货、物流咨询。

系统设计：

  • 工具：lookup_order(order_id)、search_knowledge_base(query)、create_return(order_id, reason)、check_logistics(order_id)
  • 记忆：短期对话历史 + 长期存储用户偏好的外部记忆

一次典型交互：

用户：我的订单怎么还没到？
Agent思考：需要先查订单状态，但缺订单号。
Agent回复：请提供您的订单号，我帮您查一下物流。
用户：ORD12345
Agent思考：用 order_id 查询物流。
动作：check_logistics("ORD12345")
观察：已发货，预计明日到达。
Agent思考：直接告知用户即可。
最终答案：您的订单 ORD12345 已经发货，预计明天送达。还有其他需要吗？

若半小时后同用户回来问“帮我退了我上次那个订单”，Agent 可通过长期记忆检索到上次对话中的订单号 ORD12345，直接调用 create_return，无需用户重复。

故障处理：如果 check_logistics 返回 API 超时错误，Agent 应规划重试或告知用户稍后再查，而不是编造一个结果。

六、当前 Agent 的成熟度与实用建议

Agent 并不是银弹。当前的技术成熟度还面临几个真实瓶颈：

  • 多步推理的错误累积：步骤越多，模型在半路陷入混乱的概率越大。
  • 规划与执行的解耦困难：LLM 倾向于“边说边忘”，难以严格执行预设计划。
  • 成本与延迟：一次 agent 任务可能触发 10+ 次 LLM 调用，推理成本是简单问答的数倍到数十倍，且启动到完成的时延对用户可能难以忍受的。

因此，在应用开发时遵循以下原则：

  • 先评估任务是否真的需要 Agent。简单问答用提示工程，需要知识库用 RAG，只有当任务确实需要动态多步调用多个工具时，才引入 Agent。
  • 先做窄领域 Agent，而非通用 Agent。把工具集限定在少数几个，任务范围明确，能大大提升可靠性和性价比。
  • 加一层“护栏”。在 Agent 循环外层放置规则引擎，对于敏感操作必做拦截，对于确定性的业务规则不要交给模型决策。
  • 监控与可解释性。生产环境中一定要记录每一步的思考、动作、观察，方便事后分析“为什么 agent 做出了那个决定”。

从工程视角看，Agent 的本质是用程序逻辑（循环、条件、状态机）把 LLM 的推理能力编织成可执行的工作流。掌握上述工具调用、规划和记忆的实现逻辑，你就拿到了将大模型从“聊天玩具”升级为“数字员工”的施工图。接下来，24.4 节将汇总当前主流的 Agent 开发框架与开源项目，帮助你快速落地。