基于《大规模语言模型：从理论到实践（第2版）》第8章 大模型智能体
爆款小标题：Agent 不是「多调几次 API」：原书第8章架构与工具学习精讲
为什么这一节重要
大模型能生成文本，但若要「查天气、查数据库、发邮件、订机票」，就必须能调用外部工具并在多步中规划、执行、观察、再规划。大模型智能体（Agent）就是把 LLM 作为「大脑」、配合工具集与记忆、通过「感知—规划—行动—记忆」循环完成复杂任务的架构。原书第 8 章系统讲了智能体架构、工具学习（模型如何学会选工具与传参）以及短期/长期记忆的设计。本节把这些概念讲清，并说明工具描述与结果处理对成功率的影响，为后续 LangChain/Coze 实践与 ReAct 打下基础。
学习目标
- 理解大模型智能体的典型架构：感知（理解输入）、规划（拆解/决策）、行动（调用工具）、记忆（短期/长期）（原书第8章）。
- 掌握「工具学习」的含义：模型学会何时调何种工具、如何解析工具结果并继续推理。
- 了解工具描述、参数化与结果处理对成功率的影响。
一、智能体架构：感知—规划—行动—记忆（原书第 8 章）
感知（Perception）：构建「当前状态」，包括：用户消息、上一轮工具返回（Observation）、以及从记忆模块取出的相关信息（如历史对话摘要、之前任务的关键结果）。即把「用户输入 + 工具历史 + 记忆」整合成模型能理解的上下文。原书第 8 章将感知作为智能体循环的起点。
规划（Planning）：根据当前状态，模型决定下一步——是「调用某个工具（及参数）」还是「直接给出最终答案」。大模型通过工具描述（name、description、parameters）与 few-shot 示例，学会在文本中输出结构化动作（如 {"tool": "search", "args": {"query": "..."}} 或 ReAct 格式），由框架解析后执行。规划是智能体「思考」的核心，决定了任务分解与工具选择的合理性。
行动（Action）：执行选中的工具——可能是调用外部 API、查询向量库、执行代码、读写文件等。行动后得到观察（Observation），即工具返回结果，作为下一轮规划的输入。
记忆（Memory）：短期记忆保存当前对话或最近若干轮，供模型在规划时参考，避免重复提问或丢失上下文；长期记忆可把关键信息（如用户偏好、任务中间结果）写入向量库或外部存储，供跨会话或长程任务使用。原书第 8 章对短期与长期记忆的设计、以及如何与规划结合有说明。
循环：将工具返回作为「观察」拼回上下文，再次交给模型，形成「规划→行动→观察→再规划」直到模型输出最终答案或达到步数上限。这与 ReAct（5.3 节）的 Thought–Action–Observation 结构一致。
二、工具学习：含义与实现方式（原书第 8 章）
含义：让模型学会「何时调何种工具、传什么参数、如何解读返回结果并继续推理」。这需要模型理解工具的能力边界、输入输出格式，以及如何把自然语言意图转化为正确的工具调用。
实现方式：Function Calling 由 API 定义工具 schema（名称、描述、参数 JSON Schema），模型输出符合 schema 的结构化调用，便于解析与校验；ReAct 等采用文本式输出，模型在自然语言中输出「调用 tool_x(args)」或类似格式，由框架用正则或规则解析。原书第 8 章与 5.3 节会进一步讲 ReAct 的 Thought–Action–Observation 形式。
三、工具描述、参数与结果处理（原书第 8 章）
工具描述：工具需提供清晰的 name、description（用途、适用场景、何时不该用）、参数类型与示例。描述不清会导致模型选错工具（如该查天气却调了计算器）或传错参数（如日期格式错误）。建议对每个工具写清「何时用、参数含义、返回格式」，并在 prompt 中加 1–2 个调用示例，作为 few-shot 引导。例如：search(query: str) 的描述应写明「用于检索网络或知识库，输入为用户问题或关键词；不适用于计算、日期转换等非检索任务」。
参数与 schema：若使用 Function Calling，参数应定义 JSON Schema，包括类型（string、number、array 等）、是否必填、枚举值（若有）。模型输出会按 schema 解析，错误的 schema 会导致解析失败或语义歧义。日期、地点等有格式要求的参数，建议在描述中给出示例（如 YYYY-MM-DD）。
Function Calling 工具 schema 示例：
{
"name": "get_weather",
"description": "查询指定城市当前天气，输入为城市名（如北京、上海）。不适用于未来天气、历史天气。",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名称"}
},
"required": ["city"]
}
}
name用于解析模型输出；description供模型理解何时调用；parameters符合 JSON Schema，模型会按此生成结构化调用。
结果处理：工具返回可能很长（如整页 HTML、大段 JSON）或含噪声。应做长度截断（如只保留前 N 字符）、格式整理（如提取关键字段、去除冗余），再拼入上下文；否则超长或乱码会挤占上下文、干扰后续推理，甚至触发模型的混乱输出。原书第 8 章强调，工具返回的质量与格式会直接影响智能体的决策质量。对于 API 返回的 JSON，可只保留与当前任务相关的字段；对于网页内容，可先做正文抽取、去除导航与广告，再截断。
四、工程实战要点
1. 工具描述与 schema 要清晰
工具描述要清晰、参数类型与示例完整，便于模型正确选择与调用。建议对每个工具做「人工测试」：用若干典型问题输入模型，观察其是否能正确选择该工具并传入合理参数；若选错或传错，回头优化描述与 few-shot 示例。
2. 工具返回要做长度与格式控制
对工具返回做长度与格式控制，避免超长或噪声破坏后续推理。一般建议单次 Observation 不超过 1K–2K token，超出的部分做截断或摘要；若返回为结构化数据，可提取关键字段并以简洁文本形式拼入上下文。
3. 记忆的容量与更新策略
短期记忆（对话历史）需设定合理容量：过少会丢失关键上下文，过多会挤占 prompt 长度并增加成本。可采取「滑动窗口 + 摘要」：保留最近 N 轮完整对话，更早的轮次用 LLM 做摘要后保留摘要、丢弃原文。长期记忆若用向量库，需设计「写什么、何时写、如何检索」的策略，避免无关信息污染检索结果。
4. 工具调用的权限与审计
生产环境中，工具可能涉及数据库、邮件、支付等敏感操作。必须在架构层做权限控制（如按用户/角色限制可调用的工具）、输入校验（防止注入与越权）、以及审计日志（记录谁在何时调用了何种工具及参数），便于事后追溯与合规。
常见误区 & 避坑指南
- 误区：工具越多越好。避坑：工具过多会增加选择错误与延迟，按场景收敛到必要集合；一般 5–15 个工具已能覆盖大多数场景，超出时考虑按任务分组或拆分 Agent。
- 误区：忽略工具调用的权限与安全。避坑：生产环境必须做权限控制、输入校验与审计；对写操作、支付、发邮件等高风险工具，可加入人工确认或二次校验。
- 误区：认为模型天然会正确选工具。避坑：工具选择依赖描述质量与 few-shot；需用真实用例测试，发现选错时优化描述与示例，而不是默认模型能自动学会。
四、小结与衔接
本节基于原书第 8 章梳理了智能体的「感知—规划—行动—记忆」架构、工具学习的含义与工具描述/结果处理的重要性，以及短期与长期记忆的角色。下一节将讲 LangChain 与 Coze 平台实践：如何用 Chain 与 Agent 实现上述架构，以及何时选代码框架、何时选低代码平台（5.2 节）。
课后思考题
- 用「感知–规划–行动–记忆」各举一个具体例子，说明在「订机票+订酒店」任务中分别对应什么操作。
- 若模型错误地选择了一个工具（如该查天气却调了计算器），在架构上可以通过哪些机制缓解（如重试、约束、人工确认）？
