AI Agent的Function Calling、长短期记忆机制是怎样的，如何控制token成本？

# AI Agent 的 Function Calling、记忆机制与 Token 成本控制 ## 一、核心原理 ### 1. LLM 本质上是无状态的 大模型在单次推理结束后不会自动保存状态。Agent 之所以能表现出连续记忆，是因为系统在模型外部维护了状态，并在每次请求时把必要信息重新放入上下文。 可以用冯·诺依曼架构理解： - **LLM = CPU**：负责推理、规划和生成，不持久保存数据。 - **上下文窗口 = 内存 RAM**：模型只能直接处理当前 Prompt 中的 Token。 - **向量库、图数据库、业务数据库 = 硬盘**：用于长期保存信息，容量大、成本低，但不能被模型直接推理。 - **RAG / Function Calling = I/O 与系统调用**：负责在外部存储和上下文之间读写数据。 ## 二、记忆机制 ### 1. 工作记忆 工作记忆对应当前请求中的上下文，主要包括： - System Prompt； - 当前用户指令； - 当前任务状态； - 临时变量； - 工具调用结果； - 当前推理所需的少量信息。 它容量最小、成本最高，但直接影响模型当前回答质量，因此需要严格控制 Token 预算。 ### 2. 短期记忆 短期记忆通常表现为最近的会话历史，用来保证多轮对话连贯性。常见实现方式包括： - **滑动窗口**：只保留最近若干轮对话； - **动态摘要**：把较早对话压缩成摘要，近期对话保留原文； - **状态摘要**：抽取任务进度、用户偏好、待办事项等结构化信息； - **Prompt Caching**：缓存重复出现的长前缀，例如 System Prompt、长文档和代码库。 短期记忆不能无限增长，否则会导致 Token 成本上升、响应延迟增加，以及“中间遗忘”（Lost in the Middle）问题。 ### 3. 长期记忆 长期记忆存储在模型外部，常见载体包括： - **向量数据库 Vector DB**：保存文本块及向量，用于语义检索； - **图数据库 Graph DB / 知识图谱**：保存实体及实体关系，适合表达因果、归属和关联； - **关系型数据库或 KV 存储**：保存用户资料、订单、配置等结构化数据； - **文件或对象存储**：保存文档、报告、代码、图片等资料。 长期记忆中的内容不会自动进入模型，必须先经过检索或工具调用，再把相关结果写入当前上下文。 ### 4. 记忆的读写流程 典型流程如下： 1. 用户发出请求； 2. Agent 判断当前上下文是否足够； 3. 如果信息不足，就通过 RAG 检索长期记忆，或通过 Function Calling 调用业务系统； 4. 将召回的信息、工具执行结果放入 Prompt； 5. LLM 基于这些信息进行推理和回答； 6. 对重要的新信息进行抽取、去重、摘要，并写入长期记忆； 7. 对过期、错误或无关信息进行更新或删除。 因此，Agent 记忆不是简单保存全部聊天记录，而是一个包含“读、写、改、删”的动态系统。 ## 三、Function Calling 的作用与原理 ### 1. 作用 Function Calling 让 LLM 能够把自然语言意图转换成结构化工具调用，从而连接外部系统。它通常用于： - 查询数据库或知识库； - 调用搜索、计算器、代码执行器、订单系统等工具； - 保存、更新或删除长期记忆； - 执行多步骤任务； - 将模型输出约束为指定 JSON 参数。 例如，模型可以选择调用： - `search_memory(query)`：检索长期记忆； - `save_to_memory(content, type)`：保存重要事实； - `update_memory(id, content)`：更新旧信息； - `delete_memory(id)`：删除过期信息； - `query_order(user_id)`：查询业务数据库。 ### 2. 原理 系统通常会先向模型提供工具描述，包括： - 函数名称； - 函数功能说明； - 参数结构； - 参数类型； - 必填字段； - 枚举值和约束条件。 当用户请求需要外部数据或动作时，模型并不直接编造答案，而是生成结构化调用请求。Agent 框架校验参数后执行函数，再把结果返回给模型，由模型生成最终回答。 在记忆系统中，Function Calling 可以让 Agent 从“被动检索”变成“主动读写”： - 需要历史信息时，主动调用检索函数； - 发现长期偏好或关键事实时，主动写入记忆； - 发现旧记忆冲突时，主动更新或废弃旧内容。 但这种方式依赖模型的工具选择和参数生成准确率，复杂场景下还需要权限控制、参数校验和调用失败重试。 ## 四、如何控制 Token 成本 ### 1. 不把全部历史直接塞入 Prompt 应避免“长上下文万能论”。即使模型支持百万 Token，全量传入历史也会带来： - API 费用增加； - 首字延迟变长； - 注意力成本上升； - 关键信息被淹没； - 事实混淆和中间遗忘。 ### 2. 使用分层记忆 根据信息重要程度和时效性分层： - 当前任务信息放入工作记忆； - 最近几轮对话放入短期记忆； - 稳定事实、用户偏好、历史结论写入长期记忆； - 需要时只召回与当前问题最相关的少量内容。 ### 3. 使用滑动窗口与摘要 常见策略是： - 最近 3～10 轮保留原文； - 更早对话压缩为阶段性摘要； - 抽取用户目标、关键事实、约束条件和待办事项； - 当摘要过长时再次压缩，形成层级摘要。 ### 4. 使用 RAG 精准召回 长期记忆应先切块、索引，再按查询召回相关片段，而不是全量加载。还可以结合： - 向量检索； - 关键词检索； - 元数据过滤； - 重排序 Rerank； - 知识图谱关系查询。 召回后只把 Top-K 的高相关内容提供给模型。 ### 5. 使用 Prompt Caching 对于重复出现且变化较少的长前缀，可以使用 Prompt Caching，例如： - 固定 System Prompt； - 长文档； - 大型代码库； - 工具定义； - 产品规则和业务说明书。 缓存命中后可以减少重复计算，降低延迟和成本，特别适合“同一大段静态文本被反复使用”的场景。 ### 6. 对工具结果进行压缩 Function Calling 返回的数据往往很大，不能原样塞进上下文。应进行： - 字段过滤； - 结果摘要； - 分页加载； - Top-K 截断； - 结构化抽取； - 只返回模型完成任务所需的信息。 ### 7. 控制写入质量 长期记忆不是越多越好，写入前应进行： - 重要性判断； - 去重； - 冲突检测； - 事实过期处理； - 分类和标签化； - 摘要与结构化存储。 ### 8. 建立动态遗忘机制 应及时删除或降权： - 临时闲聊； - 已过期的信息； - 被用户更正的信息； - 重复内容； - 低价值或低置信度内容。 ## 五、总结 生产级 AI Agent 通常采用 **Hybrid Memory 混合记忆架构**： - 用工作记忆保存当前推理上下文； - 用短期记忆保存近期对话和任务状态； - 用向量库、图数据库或业务数据库保存长期记忆； - 用 Function Calling 完成主动检索、写入、更新和外部动作； - 用 RAG、摘要、缓存、动态遗忘和结果压缩控制 Token 成本。 核心不是一味扩大上下文窗口，而是在恰当的时间，把恰当的信息，以恰当的粒度放入模型上下文。

# 作用 ## Function Calling / Tool use - Function Calling 本质上是让 Agent 调用外部工具 API，从而突破 LLM 只能生成文本的限制。 - 常见工具包括： - 计算器 - 搜索工具 - 代码执行器 - 数据库查询工具 - 工具让 Agent 可以与外部系统交互、获取实时信息、执行计算或操作数据。 ## 记忆机制 - **短期记忆**：保存当前任务执行过程中的上下文，在各个子任务执行过程中产生和暂存，任务结束后通常会清空。 - **长期记忆**：长时间保留的信息，一般存放在外部知识库中，通常通过向量数据库进行存储和检索。 # 原理 ## Agent 的基本结构 在 LLM 驱动的 Agent 中，LLM 相当于“大脑”，外部由三个关键部分配合： - **规划 Planning**：把大型任务拆成多个子任务，并规划执行流程；同时在执行中思考和反思，判断是继续执行还是终止任务。 - **记忆 Memory**：通过短期上下文和长期知识库保存任务信息与历史信息。 - **工具使用 Tool use**：由 LLM 选择并调用合适的函数或 API，完成搜索、计算、查库、执行代码等动作。 ## 长短期记忆的工作方式 - 短期记忆主要依赖当前对话和任务上下文，适合保存临时推理状态。 - 长期记忆通常将历史信息写入外部知识库，需要时再检索相关内容，而不是把全部历史都放进模型上下文中。 ## Token 成本控制思路 - 短期上下文只保留当前任务必要信息，任务完成后清理，避免上下文无限膨胀。 - 长期信息存到向量数据库等外部系统，需要时按相关性检索少量内容，避免把全部历史记录传入 LLM。 - 复杂任务先由规划模块拆分为子任务，按需携带上下文并调用工具，减少无关输入。 > 网页主要介绍了 Function Calling、长短期记忆和 Agent 架构；对 token 成本控制没有展开专门说明，以上成本控制方法是依据其短期上下文、外部向量库和按需检索机制整理出的直接推论。