智能体记忆与工具调用底层原理拆解：从上下文伪装到代理编排

一、原理概述：本文讨论的核心问题

大模型本身是一个无状态的函数：给定一段输入（上下文），产出一段输出。它不会自动记住上一轮对话，也无法主动查询外部数据，更不能直接操作外部系统。然而，实际应用中我们却看到模型能“记得”用户偏好、能“查”到知识库内容、能“调用”工具完成任务。这些能力并非模型原生具备，而是通过外围机制在上下文层面构造出来的。

本文要解释的正是这类外围机制的底层原理，围绕四个关键词展开：

• 记忆（Memory）：如何让无状态模型表现出有状态的行为；
• 检索增强生成（RAG）：如何把外部知识按需注入上下文；
• 工具调用（Tool/MCP 类机制）：如何让模型输出结构化的调用意图并由外部程序执行；
• 代理程序（Agent）：如何把上述能力封装成带特定逻辑的程序实体。

理解这些机制的关键在于一个共同前提：模型能“看到”的只有上下文窗口内的内容。所有能力本质上都是“如何构造上下文”以及“如何解析并响应模型输出”的问题。下面逐层展开。

二、背景问题：为什么需要这些机制

直接使用大模型时存在三个硬约束：

1. 无状态性：每次请求相互独立，历史对话不会自动保留。多轮对话的“记忆”必须由调用方重新拼接进上下文。
2. 知识静态性：模型参数在训练后固定，无法感知训练截止之后的事实，也无法访问企业私有数据。涉及时效性或私域知识的问答必须外部补充。
3. 行动缺失：模型只能生成文本，不能执行查询、计算、写入等操作。要完成任务闭环，必须由外部程序代其执行。

这三个约束分别对应记忆机制、检索增强和工具调用机制要解决的问题，而代理程序则是把它们组织起来的容器。

三、核心概念

• 上下文窗口（Context Window）：模型单次推理可接收的Token总量上限，是所有机制的“舞台”。记忆、检索结果、工具返回都必须塞进这个窗口。
• Token：模型处理文本的基本单位，上下文长度与费用通常按Token计量，因此“压缩”是贯穿各机制的核心优化方向。
• 系统提示（System Prompt）：位于上下文前部的指令区域，常用于注入角色设定、工具说明和记忆摘要。
• 结构化输出：模型按约定格式（如JSON）输出内容，使外部程序可以稳定解析，这是工具调用的解析基础。
• 编排（Orchestration）：外部程序根据模型输出决定下一步动作（继续推理、执行工具、结束）的控制逻辑。

四、记忆机制：用上下文伪装实现“有状态”

4.1 机制定义

记忆机制的本质是：将历史对话记录作为上下文的一部分重新送入模型，使模型在当前轮次“看到”过去发生的内容，从而表现出连贯性。模型自身没有任何持久化状态，所谓“记忆”是调用方在每次请求时重建的上下文幻觉。

4.2 实现方式：多人对话伪装

一种常见实现是把历史记录伪装成多角色对话结构，例如：

[系统] 你是助手，需参考以下历史。
[用户] 我住在杭州，偏好简洁回答。
[助手] 好的，已了解。
[用户] 今天适合跑步吗？

模型在生成回复时会把这些历史当作对话的一部分进行条件化，于是“记得”用户所在城市与偏好。这里的要点是：历史不是模型内部存储，而是每次请求时被重新拼接的文本。上下文越长，重建成本越高。

4.3 优化：总结压缩

历史无限累积会迅速耗尽上下文窗口并推高Token成本。常见优化是利用模型自身对记忆内容进行总结压缩：

1. 当历史长度超过阈值时，触发一次总结请求；
2. 模型把多轮对话压缩为要点式摘要（如“用户位于杭州、偏好简洁、已确认日程”）；
3. 用摘要替换原始历史，保留最近若干轮原文以维持细节连贯性。

伪代码示意：

if token_count(history) > threshold:
    summary = model.summarize(history_old)
    context = system_prompt + summary + history_recent + user_input
else:
    context = system_prompt + history + user_input

这种“摘要+近期原文”的分层结构，是在信息保真度与上下文成本之间的折中：摘要丢失细节，近期原文保留细节，二者互补。

4.4 边界与注意点

• 总结是有损压缩，关键细节可能在压缩中丢失，需通过结构化摘要模板（如固定字段：身份、偏好、待办）降低信息损失；
• 摘要本身也消耗Token与调用次数，需权衡触发频率；
• 记忆的“一致性”依赖调用方维护，多端并发时需考虑历史合并与冲突处理。

五、检索增强生成：按需注入外部知识

5.1 机制定义

RAG 的核心是：在生成之前，先从外部知识库检索与问题相关的内容片段，将这些片段作为上下文注入，使模型的回答基于检索到的事实而非仅凭参数记忆。

5.2 处理链路

1. 离线索引：文档经切分（Chunking）后转为向量或关键词索引，写入检索库；
2. 在线检索：用户问题转为查询向量，在索引中做相似度匹配，取回Top-K片段；
3. 上下文拼装：将片段按相关度排序后拼入提示，通常附带“仅依据以下材料回答”的约束；
4. 生成与引用：模型基于注入材料生成答案，可要求输出引用片段编号以便追溯。

伪代码示意：

query_vec = embed(user_question)
chunks = vector_index.search(query_vec, top_k=5)
prompt = system_prompt + format(chunks) + user_question
answer = model.generate(prompt)

5.3 关键机制与边界

• 切分粒度：片段过大会引入噪声并占用上下文，过小则语义不完整，需按语义边界切分并保留重叠；
• 检索质量决定上限：检索不到相关内容时，模型只能凭参数作答，容易产生看似合理但无依据的内容，因此常配合“材料不足则明确说明”的提示约束；
• 上下文预算：Top-K 的K值受上下文窗口限制，需在召回率与成本间平衡；
• 与记忆的区别：记忆面向“对话历史”，RAG面向“外部知识”，二者都通过注入上下文生效，但数据来源与更新周期不同。

六、工具调用类机制：让模型输出可执行的意图

6.1 机制定义

模型不能直接执行操作，但可以输出结构化的调用意图，由外部程序解析后代为执行，再把执行结果作为新上下文送回模型。这类机制（业界常以工具调用、函数调用、协议化上下文等形态出现）的本质是“模型负责决策，程序负责执行”。

6.2 工作流程

1. 工具声明：在上下文中以结构化描述列出可用工具的名称、用途与参数格式；
2. 意图生成：模型判断需要调用工具时，输出符合约定格式的调用请求（如工具名+参数JSON）；
3. 外部执行：编排程序解析请求，完成参数校验、权限检查后执行实际调用；
4. 结果回注：将执行结果（成功数据或错误信息）作为上下文追加，模型据此继续推理或生成最终答复。

伪代码示意：

context = system_prompt + tool_specs + history + user_input
output = model.generate(context)
if is_tool_call(output):
    result = execute(validate(output.call))   # 外部程序执行
    context += format(result)
    output = model.generate(context)
return output

6.3 关键机制与注意点

• 参数校验与权限控制：模型输出不可信，执行前必须做 schema 校验、参数范围检查与权限隔离，避免越权操作；
• 错误处理：工具失败时应把错误信息结构化回注，让模型有机会重试或降级，而非直接中断；
• 幂等与副作用：写操作类工具需考虑重复调用风险，常配合确认机制或幂等键；
• 循环控制：多轮“调用—回注”需设置最大轮次，防止无限循环消耗资源。

七、代理程序：把机制封装为程序实体

7.1 定义与组成

代理程序（Agent）的本质是封装了特定逻辑的程序，它把记忆、检索、工具调用、编排控制组织成一个可复用的执行单元。其典型组成包括：

模块	职责
上下文管理	拼接系统提示、记忆摘要、检索结果与工具返回
决策循环	判断继续推理、调用工具还是结束
工具执行器	校验并执行工具调用，处理错误与超时
状态存储	保存对话历史与摘要，供下次请求重建

7.2 早期实现与演进

早期实现可能仅通过提示扩展完成：用一段较长的系统提示描述角色、可用工具与输出格式，模型按提示输出结构化内容，外部程序做简单解析。这类实现门槛低，但鲁棒性依赖提示质量，复杂任务下容易格式漂移。演进方向是把控制逻辑从提示中逐步外移到程序层：显式的状态机、独立的工具执行层、可观测的调用日志，从而提升稳定性与可调试性。

7.3 边界条件

• 代理程序的“智能”上限受模型决策质量约束，编排逻辑只能约束格式与流程，不能替代推理；
• 多工具组合时，调用顺序与依赖关系需由程序或模型显式规划，否则易出现无效调用；
• 长任务中上下文持续增长，必须结合记忆压缩与结果摘要控制窗口占用。

八、常见误区

1. 误以为模型“真的记住了”：记忆是每次请求重建的上下文，换一个会话或清空历史即失效；
2. 把RAG当成万能补丁：检索不到或检索错误时，生成质量不会提升，反而可能引入干扰材料；
3. 认为工具调用是模型在执行：执行永远发生在外部程序，模型只产出意图，安全校验必须在程序侧完成；
4. 忽视上下文预算：记忆、检索、工具返回共享同一窗口，任一环节膨胀都会挤压其他环节的空间；
5. 把代理等同于提示词：提示只是早期形态，可靠代理需要程序层的校验、循环控制与状态管理。

九、总结

这四类机制的共同底层逻辑可以归纳为一句话：模型只处理上下文，一切能力都通过“构造输入上下文”与“解析输出意图”实现。记忆通过历史回注与摘要压缩维持连贯性，RAG通过检索注入外部事实，工具调用通过结构化输出把决策与执行分离，代理程序则把上述机制封装为带状态管理与编排逻辑的程序实体。理解了这一层，就能明白各项能力的收益来自哪里、边界卡在何处，也就能在实际设计中合理分配上下文预算、做好校验与容错，而不是把工程问题误当成模型能力问题。