1. 为什么“记忆”和“工具”是 Agent 落地的两道坎
做 Agent 开发的人，迟早会撞上同一堵墙：模型本身很聪明，但一放到真实任务里就变得又健忘又笨拙。健忘是因为上下文窗口有限，聊到第十轮，前三轮的关键信息已经被挤出去了；笨拙是因为它只能“说”，不能“做”，没法查数据库、调接口、读文件。这两个问题不解决，Agent 永远只能停留在演示视频里。
我最初做 Agent 的时候，天真地以为把对话历史全部塞进 prompt 就行了。结果 token 消耗飞涨，响应越来越慢，而且模型在超长上下文里反而抓不住重点，开始胡编。后来才明白，记忆不是把什么都记住，而是知道该记什么、该忘什么、什么时候把什么捞回来。这跟人脑的工作方式其实很像——你不会记得今天早上刷牙用了几毫升水，但你会记得下午三点要开会。
工具这一侧同样有坑。早期大家各写各的 function calling，格式五花八门，换个模型就得重写一遍。直到 MCP（Model Context Protocol）这类协议出现，才把“工具怎么描述、怎么调用、怎么返回”这件事标准化了。它解决的核心问题是：让 Agent 和外部能力之间的接口从“私有方言”变成“普通话”。
这篇文章我想把这两条线捋清楚：一条是记忆的演进路径，从最朴素的上下文窗口，到外部存储，再到检索增强；另一条是工具的演进路径，从硬编码 function calling 到 MCP 协议。两条线最终会交汇——因为记忆本身也可以被抽象成一种工具，而工具调用的结果又需要被记忆管理。理解这个交汇点，才算真正摸到了 Agent 工程的门道。
适合读这篇的人：正在做 Agent 应用、被上下文长度折磨过、或者对 MCP 好奇但还没搞明白它到底解决什么问题的开发者。我会尽量少讲空话，多讲我实际踩过的坑和验证过的做法。
2. 上下文窗口：Agent 记忆的起点，也是第一个瓶颈
2.1 上下文窗口到底装了什么
先把概念对齐。上下文窗口就是模型一次能“看到”的 token 总量，包括系统提示、对话历史、工具定义、工具返回结果、当前用户输入，全部算在内。比如一个 128K 窗口的模型，理论上能装下大约十万个汉字量级的内容，听起来很多，但实际用起来消耗极快。
我做过一个粗略的统计：一个中等复杂度的 Agent 系统提示加工具定义，轻松吃掉 3000 到 8000 token；每轮对话加上工具返回，平均 1000 到 3000 token。也就是说，128K 窗口在真实任务里可能撑不过三四十轮。如果任务涉及读长文档、查大量数据，几轮就爆了。
更麻烦的是，窗口没满不代表没问题。业界有个说法叫“lost in the middle”——模型对上下文中间部分的信息召回率明显低于开头和结尾。你把关键信息塞在第 50K token 的位置，模型很可能视而不见。这不是玄学，是注意力机制在长序列上的固有特性。
2.2 全量塞入为什么行不通
新手最容易犯的错就是“全量塞入”。逻辑很直觉：信息越多，模型判断越准。但实测下来有三个致命问题。
第一是成本。token 是按量计费的，全量塞入意味着每一轮都要为所有历史付费。一个跑几十轮的任务，成本可能是精简方案的十倍以上。
第二是延迟。上下文越长，首 token 延迟越高。用户等三秒和等十秒，体验是天壤之别。
第三是质量下降。这点最反直觉。信息过载会让模型分心，它可能抓住一个无关的细节大做文章，反而忽略了真正的任务目标。我遇到过模型因为历史里提过一句“用户喜欢蓝色”，就在生成报告时硬塞蓝色主题，完全跑偏。
所以正确的思路不是“塞更多”，而是“管得更聪明”。这就引出了记忆管理的核心问题：什么信息值得留在窗口里，什么应该挪到外部，什么时候再捞回来。
2.3 滑动窗口与摘要压缩的取舍
最朴素的记忆管理是滑动窗口：只保留最近 N 轮对话，更早的直接丢弃。实现简单，成本可控，但代价是丢失长期信息。用户第一轮说的偏好，到第二十轮就没了。
稍微进阶一点的是摘要压缩：把早期对话用模型总结成一段简短摘要，替换掉原始内容。这样能保留要点，又省 token。但摘要本身有信息损失，而且摘要质量依赖模型能力，总结得不好反而误导后续推理。
我的经验是，滑动窗口加摘要的组合拳在多数场景够用：最近 5 到 10 轮保留原文，更早的压缩成结构化摘要（比如按“用户偏好”“已确认事实”“待办事项”分类）。关键是摘要要结构化，不能是一段流水账，否则模型还是抓不住重点。
但这两招都治标不治本。真正的长期记忆，得靠外部存储。
3. 从窗口到外部存储：Agent 长期记忆的几种实现路径
3.1 向量数据库：语义检索的主力
外部记忆最主流的方案是向量数据库。原理不复杂：把每段记忆转成 embedding 向量存起来，需要的时候用当前查询去检索最相似的若干条，塞回上下文。这样记忆容量理论上无限，检索也快。
我实际用下来，向量检索的效果高度依赖几个细节。分块策略是第一道关。把一段对话按固定长度切，还是按语义边界切，结果差别很大。我倾向于按“一个完整的事件或结论”切块，而不是机械按字数。比如“用户确认预算上限是五万”这种完整信息，不该被切成两半。
embedding 模型的选择也很关键。通用 embedding 在专业领域（比如医疗、法律、代码）表现会打折，有条件的话用领域数据微调一下，召回率能提升不少。
还有个容易被忽略的点：元数据过滤。光靠语义相似度检索，经常捞回一堆“看起来像但实际无关”的记忆。加上时间、类型、来源等元数据过滤，精度会好很多。比如检索“用户上次提到的预算”，可以限定只搜“用户偏好”类型的记忆，而不是全库乱搜。
3.2 结构化记忆：把关键事实单独存
向量检索擅长模糊匹配，但对精确事实的存储和更新不友好。用户说“我预算五万”，后来又改成“八万”，向量库里两条都存着，检索时可能捞回旧的那条。
所以我会把关键事实单独抽出来，存成结构化的键值对或小表。比如用户画像、任务状态、已确认约束，这些用结构化存储，更新时直接覆盖，检索时精确命中。向量库负责“模糊的、叙述性的”记忆，结构化存储负责“精确的、状态性的”记忆，两者分工明确。
这个思路其实借鉴了传统软件工程里“缓存加数据库”的分层思想。热数据、精确数据放结构化层，冷数据、叙述数据放向量层。
3.3 记忆的写入、检索与遗忘策略
记忆管理最难的不是存，而是决定什么时候写、什么时候读、什么时候删。
写入时机上，我一般设几个触发点：用户明确表达偏好或约束时、任务状态发生变更时、一轮子任务完成时。不是每句话都值得记，记太多反而稀释了有效信息。
检索时机上，不是每轮都检索。我的做法是在任务开始、话题切换、或者模型主动表示“需要回忆”时才触发检索。频繁检索既费钱又容易引入噪声。
遗忘策略最容易被忽视。记忆库无限膨胀，检索精度会下降，成本会上升。我会给记忆设过期时间，或者按访问频率做衰减——长期没被检索到的记忆，降低权重甚至归档。这跟人脑的记忆衰减机制异曲同工。
提示：记忆系统的评估不能只看“检索准不准”，还要看“该记的有没有记、该忘的有没有忘”。我建议单独建一个测试集，模拟多轮任务，检查关键信息在长对话后是否还能被正确召回。
4. 工具调用：Agent 从“会说”到“会做”的关键一跃
4.1 Function Calling 的工作机制
工具调用的本质，是让模型输出一个结构化的“调用意图”，由外部代码执行，再把结果喂回模型。早期各家实现不同，但核心流程一致：在 prompt 里描述有哪些工具、每个工具接受什么参数，模型判断需要调用时，输出一个 JSON 描述调用哪个工具、传什么参数。
这里有个关键认知：模型本身不执行任何工具，它只是生成调用参数。真正执行的是你的代码。理解这一点，就不会对“模型怎么知道数据库密码”这类问题感到困惑——密码在你的执行代码里，模型根本接触不到。
参数生成的准确性是第一个难点。模型可能传错类型、漏传必填项、或者编造不存在的参数值。我的做法是在工具描述里把参数约束写清楚，包括类型、范围、示例，并且在执行层做严格校验，校验失败就把错误信息返回给模型让它重试。
4.2 工具描述写得好，调用成功率翻倍
我踩过最大的坑，就是工具描述写得太随意。一开始我觉得描述就是给人看的注释，随便写写。结果模型频繁误用工具，或者该调用时不调用。
后来我总结了几条经验。描述要写“什么时候用”，而不只是“这是什么”。比如一个查询订单的工具，光写“查询订单信息”不够，要写“当用户询问订单状态、物流进度、或需要根据订单号获取详情时使用”。这样模型才知道触发条件。
参数描述要给例子。模型对抽象描述的理解不如对具体例子敏感。与其写“日期参数”，不如写“日期参数，格式 YYYY-MM-DD，例如 2024-01-15”。
工具数量要克制。我见过有人一口气塞几十个工具，结果模型选择困难，调用准确率暴跌。经验值是单次暴露给模型的工具不超过 10 到 15 个，多了就分组或者按场景动态加载。
4.3 多工具编排与错误处理
真实任务往往需要多个工具配合。比如“帮我查一下上周的销售数据并生成报告”，可能涉及查数据库、调分析接口、生成文档三个工具。模型需要自己规划调用顺序，处理中间结果。
这里最容易出问题的是错误处理。工具调用失败时，如果直接把原始错误抛给模型，它可能一脸懵。更好的做法是把错误转成模型能理解的描述，比如“查询失败，原因是订单号格式不正确，请确认后重试”。模型看到这种信息，才知道怎么调整。
还有一个坑是循环调用。模型可能陷入“调用工具、结果不满意、再调用、还不满意”的死循环。我会设一个最大调用轮次，超过就强制中断，返回当前最优结果并说明情况。
5. MCP 协议：工具生态从“私有方言”走向“普通话”
5.1 MCP 到底解决了什么问题
在 MCP 出现之前，每个模型厂商、每个 Agent 框架都有自己的工具定义格式。你为一个模型写的工具，换个模型就得重写。这就像每个城市都有自己的电源插头标准，出差得带一堆转换头。
MCP 的思路是定义一套标准协议，把“工具提供方”和“工具使用方”解耦。工具提供方按 MCP 规范暴露能力，任何支持 MCP 的客户端都能调用，不用关心底层是哪个模型。这跟 USB 接口的意义是一样的——统一标准，即插即用。
它的架构是客户端-服务端模式。MCP 服务端暴露三类能力：工具（可执行的操作）、资源（可读取的数据）、提示（预设的模板）。客户端（也就是 Agent 运行时）连接服务端，动态发现有哪些能力可用，然后按需调用。
5.2 MCP 的三类原语：工具、资源与提示
工具是最常用的，对应可执行的操作，比如查数据库、发请求、算数据。每个工具有名字、描述、参数 schema，跟 function calling 的定义类似，但格式标准化了。
资源对应可读取的数据，比如文件内容、数据库记录、API 返回。它和工具的区别在于：工具是“做一件事”，资源是“读一份数据”。这个区分让 Agent 能更清晰地表达意图。
提示是预设的模板，服务端可以提供一些常用的提示词模板，客户端直接调用。这个原语用得相对少，但在标准化场景下很有价值。
我实际用下来，MCP 最大的好处是工具可以跨项目复用。以前每个项目都要重新写一遍数据库查询工具，现在写一个 MCP 服务端，所有项目都能连。维护成本大幅下降。
5.3 自己动手写一个 MCP 服务端的要点
写 MCP 服务端不复杂，但有几个细节容易踩坑。
第一是能力声明的粒度。不要把一个大功能拆成几十个细碎工具，也不要一个工具包揽所有事。我的经验是按“用户意图”划分，一个工具对应一类明确的操作。
第二是错误返回的规范性。MCP 对错误有标准格式，要按规范返回，客户端才能正确处理。我见过有人直接抛异常，导致客户端解析失败。
第三是鉴权和权限。MCP 服务端可能暴露敏感操作，必须做好鉴权。别以为本地运行就安全，Agent 可能被诱导调用不该调用的工具。
第四是性能。MCP 服务端如果响应慢，整个 Agent 链路都会卡。我一般会给耗时操作加超时和缓存。
注意：MCP 服务端的工具描述同样要遵循“什么时候用”的原则。协议标准化了格式，但描述质量还是靠人来保证。
6. 记忆与工具的交汇：把记忆本身抽象成一种能力
6.1 记忆即工具的设计思路
想通一件事之后，整个架构会清爽很多：记忆操作本身就可以抽象成工具。存记忆是一个工具，检索记忆是一个工具，遗忘也是一个工具。这样 Agent 就能像调用其他工具一样管理自己的记忆，而不是把记忆逻辑硬编码在框架里。
这个思路的好处是灵活。Agent 可以根据任务需要，主动决定“这条信息值得记”“我需要回忆一下之前的约定”。它把记忆的主动权交给了模型，而不是由外部规则强制管理。
当然，这也有风险。模型可能滥用记忆工具，什么都记，或者频繁检索。所以我会在工具描述里加约束，比如“只在信息具有长期价值时调用存储”“检索前先判断是否真的需要”。
6.2 用 MCP 统一记忆服务的接口
既然记忆是工具，那它天然适合用 MCP 来标准化。我可以写一个 MCP 记忆服务端，暴露 store、retrieve、forget 三个工具，任何支持 MCP 的 Agent 都能连上使用。
这样做的好处是记忆服务独立于 Agent 框架。换框架、换模型，记忆服务不用动。而且多个 Agent 可以共享同一个记忆服务，实现跨会话、跨应用的记忆互通。
我实际搭过一套，结构大概是：底层是向量库加结构化存储，中间是记忆管理逻辑（分块、去重、衰减），上层是 MCP 接口。Agent 通过 MCP 调用，完全不用关心底层实现。
6.3 一个可落地的组合架构
把前面的东西串起来，我常用的架构是这样的：
- 上下文层：滑动窗口加结构化摘要，管理当前会话的短期记忆。
- 记忆服务层：MCP 服务端，提供 store、retrieve、forget 工具，底层接向量库和结构化存储。
- 工具层：业务工具通过 MCP 暴露，和记忆服务并列。
- 编排层：Agent 运行时，负责规划、调用工具、管理上下文。
这个架构的关键是分层清晰、接口标准。每层只关心自己的事，通过标准协议通信。这样任何一层都可以独立替换或升级，不会牵一发动全身。
我踩过的坑是早期把记忆逻辑和业务逻辑混在一起，代码越写越乱，改一处崩三处。分层之后，维护成本直线下降。
7. 实测中的几个坑与应对经验
7.1 记忆检索的“相似但不相关”问题
向量检索最烦人的是捞回一堆语义相似但实际无关的记忆。比如用户问“上次那个方案”，检索可能捞回所有带“方案”二字的记忆，但用户指的是哪一个，模型得自己猜。
我的应对是加时间衰减和类型过滤。近期记忆权重更高，同类型的记忆优先。另外在检索结果里带上时间戳和来源，让模型有更多线索判断。
还有一个技巧是让模型先澄清再检索。如果查询太模糊，与其瞎猜，不如让模型先问用户“您指的是哪个方案”。这比检索一堆无关记忆再让模型纠结要好。
7.2 工具调用的参数幻觉
模型编造参数值是常见问题。比如调用查询工具时，编一个不存在的订单号。这在演示时看不出来，上线后就是灾难。
我的做法是执行层严格校验加友好报错。参数格式不对、值不在范围内、必填项缺失，都在执行层拦住，返回明确的错误描述。模型看到具体错误，通常能自我修正。
另外，关键参数不要让模型自由生成。比如用户 ID、订单号这类，能从上下文或用户输入里提取的就提取，提取不到就让模型问用户，而不是让它编。
7.3 长任务中的记忆一致性
长任务里，记忆可能前后矛盾。用户早期说预算五万，后期说八万，如果两条都存着，模型可能用错。
我的方案是结构化记忆做版本管理。同一类事实只保留最新版本，旧版本归档。检索时默认只取最新，需要历史对比时才取旧版本。这样保证模型看到的是当前有效的信息。
还有个细节是记忆的时效标注。每条记忆带上“有效期”或“最后确认时间”，模型可以据此判断信息是否还可靠。
8. 我个人的一些实践体会
做了这么多 Agent 项目，我最大的体会是：记忆和工具不是两个独立模块，而是一体两面。记忆是 Agent 对内的能力，工具是 Agent 对外的能力，两者都需要标准化的接口和清晰的分层。
另一个体会是不要过度设计。我见过有人一上来就搞复杂的记忆图谱、多级缓存，结果维护成本高得吓人，效果还不如简单的滑动窗口加向量检索。先从简单方案做起，遇到瓶颈再升级，这是更务实的路径。
MCP 这类协议的价值会越来越明显。当工具生态标准化之后，Agent 的能力边界就不再取决于你写了多少代码，而取决于你能连上多少服务。这跟当年 App 生态的爆发是一个逻辑——基础设施标准化了，上层应用才能百花齐放。
最后分享一个小技巧：给记忆和工具都加日志。每次检索、每次调用，都记下来。出问题时，日志是唯一的真相来源。我靠日志定位过好几次“模型为什么突然变傻”的问题，最后发现都是记忆检索捞回了错误信息，或者工具返回了意外格式。没有日志，这些坑能查一整天。
