最近跟几个做 Agent 的朋友聊了一圈发现大家几乎都在同一个地方卡住上下文窗口。很多人刚开始都觉得8k、32k、甚至 128k 的上下文已经很宽裕了可一旦真正跑长期对话、接上三五个工具、还要记住用户偏好窗口里的东西马上就会失控。问题不是“不够长”而是“塞不下了、分不清了、忘了该保留什么了”。今天这篇文章我想好好聊聊我在这段时间里对 Agent 记忆与工具的思考从最朴素的上下文窗口一路讲到 MCP把里面涉及的分类、设计思路和实操踩坑都捋清楚。1. 上下文窗口不是记忆是工作台1.1 工作台越小越考验整理能力我一开始也犯过这个错误以为上下文窗口就是 Agent 的记忆对话长了就往里塞。后来发现上下文窗口更像一个物理工作台你能在这个台面上铺开东西但同时摊在上面的东西越多真正有用的东西反而越难找。假设工作台上能摊 128 张纸看起来很多。但系统提示词要占十张对话历史占二十张两个工具返回的数据各占二十张检索回来的文档又占二十张。真正留给 Agent 做决策的空间可能就剩下十来张。这些纸堆在一起模型处理时会一视同仁地去“翻阅”很难保证它永远把注意力放在最关键的那几张上。更麻烦的是工具返回结果往往是结构化的 JSON。有一次我的 Agent 调用一个搜索工具返回了几百行 JSON里面九成都是无关字段最后模型不仅没找到答案还被里面某个奇怪的错误码带偏了思路。那一刻我才反应过来上下文窗口是稀缺资源如何组织、筛选、压缩里面的内容才是真正的工程问题。1.2 注意力稀释是隐性杀手这里有一个常见误解既然上下文窗口支持 128k那我就把全部历史、全部文档都丢进去反正模型能处理。实际上很多主流模型使用的是类似检索式注意力机制一个 token 是否被重视取决于 Attention 得分。当相关信息和大量无关内容混在一起时相关信息的注意力权重会被稀释模型表现反而明显下降。打个比方你在一间满是杂音的房间里找一个人说话如果房间里只有你俩声音很清楚。如果旁边多了二十个人同时说话就算那个人嗓门再大你也容易听漏关键内容。上下文窗口越大这个问题越突出不是线性的“越大越好”。我自己的实测是同样的任务上下文占用 30% 时正确率明显高于占用 90% 时。尤其是在涉及多步工具调用、需要记忆早期用户偏好的场景里塞满的历史会让 Agent “忘掉”最初的指令。1.3 一条典型的失败链路举个实战中的例子。我做一个客服 Agent用户在第一轮说“我叫小李喜欢简洁的回答风格。”对话进行到第 40 轮中途用户问了十几次商品库存Agent 也调用了几十次库存工具。此时模型在回答末尾的问题时已经完全不记得“简洁风格”这个偏好了开始输出一大段泛泛的总结。原因就是早期会话被挤到很靠前的位置工具调用记录占据了大量注意力。这不是模型“笨”而是我设计上的错。我根本没给 Agent 一个机制去记住这个偏好而是指望它一直盯着一堆历史文本这是不现实的。也正因为这个失败我开始把“记忆”跟“上下文窗口”分开处理才有了后面一系列设计。2. Agent 记忆的三种形态短期、长期与结构化2.1 短期记忆一个会滑动的窗口短期记忆本质上就是对话历史本身。它最简单、最容易实现但也最容易失控。常见做法是维护一个滑动窗口只保留最近 N 轮对话再加系统提示词。打开思路的第一步是把不重要的中间过程从窗口里移出去。我通常会在会话开始前写一个“记忆归档逻辑”每轮对话结束先判断这轮是否值得保留。如果只是寒暄或重复内容直接丢掉。如果涉及用户指令、问题解决结果就保留一轮。然后窗口大小控制在一个比较小的范围比如最近 8~12 轮。这里有一个关键细节滑动窗口从末尾往前删会导致最早的关键信息比如用户偏好丢失。所以要在窗口之外做一个持久层把那些重要信息抽出来存在结构化字段里后面再讲。2.2 长期记忆向量库只是一个起点长期记忆是我折腾得最多的一块。主流的做法是把对话记录、文档片段做切分转成向量存入向量数据库等需要时做相似度检索。这个方案本身没毛病但如果只知道“embedding 然后检索”很容易踩坑。我踩过的第一个坑是直接存整个对话文本检索时发现返回的都是“长得很像”但根本不重要的东西。比如用户说“我昨天退了个货”向量上跟“退货政策”高度相似但用户当前的问题其实是“换货流程”。单靠向量相似度很难区分“语义相关”和“任务相关”。后来我的做法是先把原始对话做切分和摘要把切分出来的每个片段提炼成一个带有意图标签的记忆单元。例如user_preference用户说自己喜欢简单回答transaction_info用户退过某件商品原因是不合身task_progress用户正在咨询换货流程已经提交了申请单每个记忆单元包含内容摘要、原始片段、标签、时间戳、会话 ID。做检索时先按意图标签过滤再做向量相似度检索最后还可以用重排序模型把真正用于当前任务的内容提到前面。2.3 结构化记忆最有价值但常被忽略如果说长期记忆是“碎片”那结构化记忆就是“骨架”。我强烈建议每个 Agent 项目都维护一张用户属性表或实体关系表里面存用户偏好、正在进行的任务状态、已经确认的关键事实。举个例子字段值用户IDuser_10086回答风格偏好简洁当前任务状态换货申请已提交等待审核当前商品运动鞋历史问题退货政策、库存查询当 Agent 需要回答“我的换货申请怎么样了”时不必从长对话里去捞直接查结构化记忆就能拿到当前状态。这比任何向量检索都靠谱因为它是确定性数据不是概率相似度。我通常会建立三类表用户偏好表、会话状态表、实体关系表。会话状态表在每次工具调用或关键事件之后更新实体关系表则记录用户提到的商品、订单、地址之类。这套做法在工程上很直观但很多 Agent 项目一开始会忽略结果就是在上下文里堆了一堆历史却连“用户叫什么”都记不准。3. 记忆工程化存储、检索与更新什么时候做3.1 事件流与摘要双轨制刚做完三种记忆形态我脑子里又冒出一个问题怎么组织写入和读取总不能每次对话都把所有记忆重新算一遍。我的解决方案是双轨制原始事件流 定期摘要。事件流就是一条日志表记录每次用户输入、Agent 动作、工具返回的关键字段。它是完整的真相来源source of truth。摘要层则是定期对事件流做聚合和压缩生成带有时间段的摘要比如“第 1~20 轮用户申请退货第 21~40 轮用户改换换货流程”。检索时我先拿摘要做粗筛定位相关时间段再回到事件流里找细节。这样既避免了把整个事件流都塞进上下文又不会丢失关键细节。这个思路很像做日志系统时的冷热数据分离热数据实时处理冷数据归档。3.2 检索策略时间衰减与多路召回检索不能只靠一个向量查询。我现在使用的策略是从结构化记忆里先拿“当前状态”相关字段比如用户当前任务、偏好。从事件流里按时间范围过滤提取最近 N 天或本会话内的相关事件。再做一次向量检索但会加上时间衰减权重。太老的记忆即使语义相关权重也要降一点。最后用一个小型重排模型或者直接让 Agent 从结果里挑相关性最高的几条。时间衰减这一点非常重要。用户的偏好和状态是变化的三个月前的“喜欢便宜耐用”很可能已经不适用了。我在检索结果里会加上时间标签让模型知道这条记忆是什么时候的是否应该被当前事实覆盖。3.3 更新时机别在对话中间频繁写入还有一种常见的坑每轮结束就把整段对话存进向量库。结果库里的记忆碎片爆炸式增长召回时重复、矛盾的内容一堆。更合理的做法是异步批量更新。也就是在一段对话结束或者达到一定轮次之后再对这一段做摘要、提取偏好、更新结构化字段。这样既减少了写入次数也方便做去重和冲突解决。比如用户一开始说“我喜欢简洁回答”过了三轮说“其实详细一点也行”这时候应该以后者为准。异步批处理时我会通过规则或简单判断把最新一次偏好覆盖旧值避免同时存在两条矛盾偏好。4. MCP统一工具与记忆的接入层4.1 为什么需要 MCP 这层“插口”讲完记忆再讲工具。在做 Agent 的时候我经常要接各种服务查订单、搜库存、算价格、读文档。一开始每个服务都有一个自定义接口要么是 HTTP 回调要么是函数调用。做得越多越痛苦每次接一个新工具都得重新写一套参数映射、错误处理、超时逻辑。而且工具返回的数据是随意的有的返回 JSON有的返回纯文本有的直接甩一个大文件路径。MCP模型上下文协议本质上是给 Agent 和外部世界之间定了一套标准插口你可以把它理解成 Agent 的 USB-C 接口。H2 4.1 没有 USB-C 之前你要给电脑接显示器要带几种线接硬盘要带另一种接网线还要再带一个。有了 USB-C大多数设备都能共用。MCP 做的事情类似如果你有一个工具或数据源也照这个协议实现Agent 就能直接用不用为每个工具单独开发一套集成逻辑。4.2 MCP 提供的三类核心能力MCP 的模型里最重要的几个概念是资源Resource、工具Tool和提示词Prompt。资源是一些上下文数据比如用户档案、某个项目的文档工具是可执行的函数比如发送订单、计算价格提示词是一些可复用的指令模板用来规范 Agent 在特定场景下的行为。我更喜欢从工程角度来理解MCP 其实定义了一个标准 JSON-RPC 通道client 和 server 之间按固定格式交互。你可以在同一个 server 里既暴露工具又暴露资源这样记忆和工具就在同一个接入层里了。更重要的是MCP 还考虑了安全控制。某个工具能访问哪些资源、哪些操作需要人工审批都可以在协议层面做约束而不是散落在各个 Agent 的业务逻辑里。当 Agent 接入的第三方服务越来越多时这个统一管控的作用会越来越重要不然整个 Agent 就是一个毫无边界的“全仓库钥匙”。4.3 一个完整的记忆服务 MCP 设计我把我自己的记忆模块做成了一个 MCP server对外暴露三个主要入口search_memory按查询条件检索记忆片段save_memory保存新的记忆get_user_profile获取当前用户的结构化档案下面是一个简化的 TypeScript 示意包名和 SDK 结构不必照搬领会思路即可import { Server } from model-context/protocol/server; const server new Server({ name: memory-server, version: 0.1.0 }); interface MemoryItem { id: string; userId: string; content: string; tags: string[]; timestamp: string; } const db new MemoryStore(); server.registerTool(search_memory, async ({ query, userId }) { const results await db.search({ userId, query }); return { results: results.slice(0, 5) }; }); server.registerTool(save_memory, async ({ userId, content, tags }) { const item: MemoryItem { id: generateUUID(), userId, content, tags, timestamp: new Date().toISOString(), }; await db.store(item); return { id: item.id }; }); server.registerTool(get_user_profile, async ({ userId }) { return db.getProfile(userId); });在这个设计里Agent 主程序根本不需要关心记忆存在哪个数据库、是向量检索还是 SQL 查询它只需要知道“我调 search_memory 能拿到历史片段调 get_user_profile 能拿到用户偏好”。存储细节完全被封装在 MCP server 内部。这带来一个额外好处如果你换了一套数据库或者把记忆存储从单机迁移到云端Agent 主程序的代码几乎不用动。MCP 这一层把“业务算法”和“基础设施”完全解耦维护成本大幅下降。5. 实战排坑上下文污染、检索失效与工具返回垃圾5.1 工具返回内容照样会“污染”对话这是我踩过最深的一个坑。一开始我以为上下文污染只发生在对话历史里后来发现工具返回内容也一样。比如某次 Agent 调用一个天气工具返回的 JSON 里包含了一大串status_code、latitude、longitude、headers之类模型在下一步逻辑里就可能被这些冗余字段干扰。我的解决方案是给工具返回做一次“显示层精简”。工具返回给模型之前先经过一个清理函数只保留真正需要的字段function cleanResult(data: any, keepFields: string[]) { const out: any {}; for (const key of keepFields) { if (data[key] ! undefined) { out[key] data[key]; } } return out; }通常我会保留status、message、result其他一律丢弃。复杂度高的返回我还会加上一层摘要让模型只看到结论和关键数字细节放到有需要时再通过另一个 MCP 工具去查。这本质上也是“按需加载”的思路上下文里的内容越聚焦模型表现越稳。5.2 检索命中率太低时别急着加阈值我最初遇到记忆检索不准时第一反应是调低向量相似度阈值希望多召回一些内容。结果发现阈值越低召回内容越多相关的反而被埋得更深。后来我意识到问题出在查询语句上。记忆检索用的 query 不是用户当下说的话而应该是一个“检索意图”的句子。比如用户说“我那件退货怎么还没退款”直接拿这句话去查记忆效果一般。如果先提炼成“退款进度、退货订单状态”再去查命中率会明显好很多。所以我在 MCP 的search_memory前面加了一步“查询改写”用一小段提示词或规则把用户自然语言转换成检索语句。这一步很便宜收益却很大。如果你也遇到检索失效先检查 Query 本身就问题而不是急着换模型或调参数。5.3 别把所有历史都存成记忆还有一个容易被忽视的问题记忆不是越多越好。跟短期记忆一样长期记忆也需要“遗忘机制”。我最初把几十轮对话全部存进向量库结果就是召回时出现大量高度相似、甚至互相矛盾的记忆。比如用户每轮都问一遍“发货没”如果不加清理向量库里会有七条相似的“发货未到”记录模型检索时可能被重复信息带偏反而错过真正重要的收件地址记录。后来我的过滤策略是两条一是重复内容合并同一天内同类问题只保留最新一条二是对事件流做自动摘要摘要之外的细节在超过一定时间后自动降权。记忆有了“遗忘”反而更精确。5.4 调试 Agent 时最容易被忽视的是日志最后分享一个习惯性问题调试工具调用和记忆检索时很多人只盯最终回复看不到中间过程。我之前也是空对空猜 Agent 为什么答错。后来我开始在记忆检索和工具调用前后加上结构化日志记录每一步的输入与输出。日志多了以后大多数问题都一目了然比如用户问题 - 检索 Query - 召回的几条记忆 - Agent 最后选了哪条调用工具 - 返回内容 - 清理后喂给模型的内容这套日志体系比我后来用的任何重排模型都管用。说起来很简单但也是很多 Agent 项目做得最欠缺的一环。没有这一步谈 Agent 优化基本是盲人摸象。我在实际把记忆和 MCP 跑通之后最大的体会是Agent 不该被当成一个全知全能的怪物它更像一个小管家工作台上的东西要由你来决定放多少、放什么工具要按需调用记忆要有存有取、有更新也有遗忘。上下文窗口只是那张工作台真正的能力来自工作台背后的那套整理术。如果你也在打磨自己的 Agent不妨先从这五个层次梳理一遍会少走很多弯路。