上周一个读者私信我说他的客服 Agent 上线第二周就有用户跑来质问“我昨天刚跟你确认过售后政策今天你怎么又要我复述一遍”这个现象太典型了——Agent 的上下文窗口一关记忆全没了。这不是某个框架的 Bug而是整个 Agent 工程化绕不开的核心问题记忆怎么管、工具怎么用。我做了几年 Agent 相关开发把“上下文窗口不够用”、“工具调用混乱”、“换设备记忆丢失”这类问题挨个捋了一遍发现答案最终都会指向同一个方向从单纯依赖上下文窗口到分层记忆存储再到 MCP 这套统一工具协议。这篇文章就把这条路径完整拆开适合正在做 Agent 产品、或者准备把 Demo 变成生产力的朋友。1. 上下文窗口的本质为什么 Agent 总是“没记性”1.1 上下文窗口不是越大越好先说一个反常识的结论大模型上下文窗口的增大并不能直接解决 Agent 的记忆问题。前几年 4K、8K 的上下文是常态现在各家都做到 128K、200K甚至上百万 Token但做过工程的人都知道窗口只是“能放进去”不代表“用得好”。原因在于推理成本。Transformer 的注意力机制对历史 Token 的计算量是接近线性的而 KV Cache 对显存的占用会随序列长度快速增长。我实测过同样一个模型把上下文从 8K 拉到 32K单次推理的显存占用能翻两三倍响应延迟也跟着上去。这意味着你不可能让每个用户的每次对话都装满几十万 Token——成本上直接崩掉体验上也会因为排队变慢。更麻烦的是长上下文会稀释注意力。模型在处理超长输入时对中间部分的关注度明显下降学术界把这叫“Lost in the Middle”现象。简单说你把一条关键信息藏在第 50K Token 的位置模型很可能压根没看到。这就像一个人被塞了一屋子资料你问他三个月前那条政策在哪他得先翻半天还未必翻对。所以做 Agent 记忆的第一课就是上下文窗口属于“工作台面”不是“仓库”。它适合放当前任务需要的临时信息不适合当成长期记忆的存储介质。1.2 长上下文不等于记得住很多人有个误区既然模型支持 200K 上下文那把用户的历史聊天记录全部塞进去不就行了我早期也这么干过结果线上问题一堆。首先是“记了等于没记”的问题。用户第 1 天聊的内容到第 7 天还在窗口里但模型回答时大概率只参考最近几轮的内容早期的关键信息——比如用户的职业、偏好、之前约定的规则——会被实际忽略。你可以做个简单测试和同一个 Agent 连续对话在第 10 轮提到一个关键限定条件然后隔 20 轮再问它观察它是否还记得。实测下来大多数模型只能稳定记住最近几分钟或几轮的内容再早一点就全靠运气。其次是“记混”的风险。窗口里的信息没有分类、没有优先级用户说过的话、Agent 自己生成的回复、系统提示词、工具返回的结果全部混在一起。模型分不清哪条是事实、哪条是猜测极端情况下会把 Agent 自己刚才编错的回答当成真理。我见过一个案例Agent 在某个环节算错了价格之后几轮对话里它一直基于这个错误价格继续推理因为错误的中间结果就在上下文里模型默认它是对的。这就引出一个关键认知记忆必须结构化不能靠上下文窗口的自然堆叠。谁说了什么、什么时候说的、来自哪个渠道、可信度如何这些元信息必须单独管理。1.3 把记忆拆成三层工作记忆、长期记忆、工具记忆我在做 Agent 架构时习惯把记忆拆成三个层级类比人的认知系统第一层是工作记忆对应上下文窗口。只保留当前任务相关的最近几轮交互典型容量在 4K 到 16K Token。它的作用是让 Agent 理解“现在正在发生什么”处理完一批任务后就应该被压缩或丢弃。第二层是长期记忆对应外部存储。包括用户画像、历史偏好、业务规则、之前处理过的案例等。这一层用向量数据库、关系型数据库或 KV 存储实现通过检索把最相关的部分注入上下文。它的作用是让 Agent 理解“这个用户是谁、以前发生过什么”。第三层是工具记忆对应 Agent 可调用的工具及其状态。比如用户是否已经完成了身份验证、当前订单处于什么流程节点、上一个操作的结果是什么。这一层以前散落在各个服务里没有统一入口MCP 出现之后才被正式纳入 Agent 的认知范围。这三层之间有明确的流动方向工作记忆满了就沉淀到长期记忆工具调用的结果反馈回工作记忆长期记忆被检索后注入工作记忆。理解了这个流动模型你才算真正明白 Agent 记忆该怎么做。2. 记忆落地怎么做从会话摘要到向量库的选型路径2.1 短期记忆滑动窗口和递归摘要短期记忆的目标是解决“上下文窗口满了怎么办”。我跟团队在实践中用的组合是滑动窗口 递归摘要。滑动窗口的原理很简单只把最近 N 轮对话放进上下文更早的内容全部移除。N 的选择要看业务类型——客服场景 5 到 10 轮就够代码生成场景可能要把更早期的需求描述保留更久调研分析类任务则需要较长时间内保持上下文连续。我见过一个比较实用的配置近 3 轮完整保留3 轮之前到 20 轮之间做摘要20 轮之前的详细内容写入长期记忆库。递归摘要是一个值得细说的方案。它的做法是每当对话累积到一定量比如 3000 Token就调用模型把前面的内容压缩成一段摘要然后带着摘要继续后面的对话。后面再累积到阈值后再把“旧摘要 新内容”合并压缩成新的摘要。这种像叠罗汉一样逐层压缩的方式信息损耗比一次性压完整场对话小得多因为每一层只损失局部细节不至于把开头的重要设定全丢掉。我踩过的坑是摘要动作不能太频繁否则摘要本身的生成成本会吃掉额度而且摘要里可能引入幻觉。我们最终定的策略是“按 Token 阈值触发 按轮次兜底”——对话累计超过 4000 Token 且距离上次摘要超过 3 轮才做一次压缩。2.2 长期记忆向量检索与结构化存储如何配合长期记忆不是简单地把文本塞进数据库就完事需要考虑怎么写、怎么存、怎么取。写入侧我倾向于把记忆分成两类事实型记忆和语义型记忆。事实型记忆比如“用户公司 50 人规模”“用户偏好微信沟通”这种结构明确、字段固定的信息应该存到关系型数据库里用字段直接索引。语义型记忆比如“用户上次抱怨过物流太慢”“用户希望方案里突出性价比”这种模糊、无法简单字段化的信息才需要向量化和语义检索。很多人一开始就把所有东西都向量化这是个误区。向量检索擅长“模糊找相似”但在精确条件过滤上远不如数据库。比如你要找“所有 VIP 用户的最近一条投诉”用 SQL 一条语句就出来了用向量检索反而要先把 VIP 过滤再做相似度流程别扭还容易漏。衰减机制是另一个容易被忽略的点。用户的偏好会变三个月前的兴趣点现在可能不重要了。我通常给每条记忆加一个置信度字段和最近访问时间定期把低置信度且长期未命中的记忆降权或清理。这借鉴了长短期记忆网络里“遗忘门”的思路——不是所有记忆都该永久保存学会遗忘是长期记忆系统能持续可用的前提。2.3 跨设备与换账号记忆的序列化与迁移有个热搜问题问得很实际“WorkBuddy 换账号怎么获得原来账号的记忆”这其实是 Agent 记忆系统的账号体系设计问题。答案的核心是记忆必须可序列化、可迁移、可重建。我给出的标准做法分三步。第一步把记忆导出为一份结构化的 JSON 快照——包括用户画像字段、向量化的语义记忆、以及每条记忆的时间戳和来源。第二步在新账号下导入这份快照重建向量索引和数据库记录。第三步在导入后做一次“记忆校验”让 Agent 主动引用几条关键记忆向用户确认避免迁移过程中出现字段错位。这里有一个很多人没注意到的细节向量化的记忆不能直接跨模型迁移。你在 A 模型环境下用 Embedding 模型 E1 生成的向量换到 B 环境如果 Embedding 模型变成了 E2原来那批向量就全都失效了。因为不同 Embedding 模型的向量空间不一致余弦相似度完全没有可比性。所以导出记忆时要么附带原始文本要么锁定 Embedding 模型版本否则迁过去就是一堆乱码。我自己经历过的现实是凡是做了迁移功能的项目必须同时做“重新向量化”的后台任务否则用户只会看到一串“导入成功”但实际全部检索不到。3. 工具调用的进化为什么最后都会走到 MCP3.1 Function Calling 的混乱年代Agent 光有记忆不够还得会用工具。早些年做工具调用最大的感受就是“乱”。每个大模型厂商都有自己的 Function Calling 格式OpenAI 是一套 JSON Schema 描述谷歌的 Gemini 又有自己的 FunctionDeclaration开源模型则五花八门。你的业务系统每接一个新的模型供应商就得重写一遍工具适配层痛苦指数极高。更痛苦的是工具服务端的接入方式。有的提供 REST API有的用 WebSocket有的走 gRPC。每个工具都要单独写对接代码、单独处理鉴权、单独处理超时和重试。我见过一个团队给一个 Agent 接了 15 个内部工具代码里光工具客户端就写了 2000 多行每个工具的入参出参格式全靠人肉维护文档。当时业内流行的折中方案是做一个统一的工具网关把所有工具包成内部标准的 HTTP 接口然后让模型用函数调用请求网关。这能解决一部分问题但每个 Agent 框架还是要自己定义一套工具协议而且框架和框架之间完全不互通。你在 LangChain 里写好的工具搬到 Semantic Kernel 里基本要重写。这个阶段我称之为“工具调用的战国时代”——每种框架都有一套自己的方言。3.2 MCP 在做什么给工具定一套“USB-C”MCPModel Context Protocol的价值一句话概括把工具调用做成了 USB-C 接口。它由 Anthropic 提出现在已经成了 AI 社区事实上的工具互操作标准。底层用 JSON-RPC 2.0 做消息协议传输层支持 stdio本地进程间通信和 SSE流式服务端推送核心概念分三层Host 是运行 Agent 的主程序Client 连接外部工具服务Tool 是被调用的具体能力。这套协议合了所有工具服务的抽象一个 MCP Server 通过 JSON-RPC 暴露一组工具Agent 侧只需要实现一次 MCP Client就能调用任何遵循协议的服务。工具开发者也只需要实现一次 MCP Server就能被所有支持 MCP 的 Agent 框架调用。生态扩张的速度相当快——文件系统、数据库、浏览器、Git、Slack、Notion甚至电路设计工具和调试器都有对应的 MCP Server 出现。为什么说 MCP 与记忆是天生一对因为记忆本质上也是一个“工具”把“写入记忆”和“检索记忆”暴露成 MCP 工具Agent 就能在需要时主动调用——比如记住用户刚才提到的新偏好比如在回答前先检索这个人过往的两条相关记录。这样一来记忆不再是被动塞进上下文的文本碎片而是 Agent 手里一个随时可用、权限可控的外部服务。3.3 用 FastMCP 十分钟写一个记忆工具理论讲多了容易飘直接给一个能跑的示例。我用 Python 生态里比较成熟的 FastMCP 库写一个最简的“记忆读写”工具from fastmcp import FastMCP # 初始化 MCP Server mcp FastMCP(memory-agent) # 内存里的简单记忆库真实项目可以替换成向量库SQLite notes [] mcp.tool def add_note(user_id: str, content: str, tags: str ) - str: 写入一条用户记忆。user_id 是用户标识content 是记忆内容tags 是可选标签。 notes.append({ user_id: user_id, content: content, tags: tags, }) return f已保存{content} mcp.tool def recall(user_id: str, keyword: str ) - list[str]: 按用户 ID 检索相关记忆支持关键词过滤。 result [] for note in notes: if note[user_id] user_id: if keyword and keyword not in note[content]: continue result.append(note[content]) return result if __name__ __main__: mcp.run(transportstdio)这段代码用 stdio 传输启动服务Agent 侧只要能调用 MCP Client就能发现add_note和recall两个工具并根据描述自动生成调用参数。我个人的经验是给工具写描述时一定要写清楚“什么时候该调、参数是什么含义”模型的工具选择准确率会显著提高。真实项目里我把recall里的keyword改成了向量检索——用 Embedding 模型把记忆内容向量化然后用余弦相似度召回相关记录。MCP 层不用变变的只是工具内部的实现细节。4. 实战搭一套“记忆 MCP 工具箱”的 Agent 底座4.1 整体架构对话、记忆、工具怎么串先看一张我常用的架构脉络。用户消息进入 Agent 主流程后模型先判断是否需要调用工具。需要查历史偏好时调用 MCP Memory 的recall工具需要执行外部操作时调用对应业务的 MCP 工具工具返回结果会重新回到模型上下文里最终生成回答。这个结构的核心优势在于分层清晰。记忆服务和工具服务都是通过 MCP 注册的外部组件Agent 主程序不需要关心它们内部怎么实现。今天你的记忆库用的是 SQLite明天想换成向量数据库MCP 的接口描述不变Agent 侧零改动。我建议新上手的项目不要一上来就铺全 Azure OpenAI 那套重型方案先用 FastMCP 写一个 Memory Server 和少量业务工具把“记忆—检索—工具调用”的闭环跑通。等确认流程没问题再逐步增加工具数量和存储层级。4.2 上下文快满时的处理流程这个流程我在多个项目里验证过直接照搬即可。当检测到上下文 Token 占用超过阈值的 70% 时触发压缩流程第一步调用模型的摘要能力把当前对话的前半段压成一段 200 到 400 Token 的摘要重点提取用户需求、已确定的事实、未完成的事项。第二步调用add_note把摘要内容写入长期记忆附上用户 ID 和时间戳。第三步把上下文里被摘要覆盖的部分裁掉只保留摘要 最近几轮完整对话。第四步继续对话流程模型在回答时会自动基于摘要提供的信息衔接上下文。这里有一个容易踩坑的细节摘要写入记忆后原来的原始对话不应立即删除。我给用户的建议是保留至少 24 小时的原始日志以防摘要过程中模型漏掉关键信息方便事后人工纠偏。压缩操作本身是有损的每次压缩都会损失少量细节所以设计时要有“摘要丢了能回查”的兜底机制。4.3 并发与一致性Agent 上线后的“扛并发”问题上了生产环境才知道Agent 的记忆系统不只是“存取”那么简单还要处理并发。同一个用户可能在手机上开一个会话、在电脑上开另一个会话两个会话同时写入记忆后写的可能会覆盖先写的导致信息丢失。我的方案是给每条记忆增加版本号采用乐观锁机制写入时携带读取到的版本号服务器发现版本号不一致就拒绝写入回包提示“该记忆已被更新请刷新后重试”。这个方案比数据库行级锁轻量得多对记忆这种读多写少的场景很合适。更重的场景下可以给记忆写入加一个串行化队列。同一个用户 ID 的记忆操作进入同一个队列保证不并发写入不同用户之间仍然并行处理。实际压测中这个方案能把记忆写入的冲突率降到千分之一以下。核心思路和数据库里按分片键路由是同一个逻辑。4.4 Agent 安全记忆隐私与工具权限的最小化Agent 的记忆是真正的敏感数据里面存的是用户身份、偏好、历史交互内容。我通常要求三个原则存储加密、访问隔离、最小采集。存储层用 AES 加密静态数据网络传输走 TLS记忆检索接口必须有用户级权限校验——User A 的会话绝不能查到 User B 的记忆。工具权限方面MCP 给了一个天然的机会不要暴露全量的工具集合每个 Agent 实例只挂载当前任务必要的 MCP Server。高危操作发消息、转账、删数据必须经过人工确认模型只能发起请求不能直接执行。我把这个约束写在系统提示词里同时在 MCP 服务端做二次校验双保险。5. 常见问题与排查技巧实录我整理了这段时间在 Agent 记忆与 MCP 落地中大家问得最多的问题直接给排查表和相应解法。症状可能原因解决方案对话时间越长反应越慢上下文窗口塞满KV Cache 膨胀开启滑动窗口 递归摘要压缩设置 70% Token 阈值触发检索记忆时召回结果不对Embedding 模型换了版本或只有关键词匹配锁定 Embedding 模型版本必要时增加重排序 Rerank 步骤Agent 突然“失忆”说完全不记得用户session_id 传错切换了新的会话上下文检查会话 ID 绑定逻辑记忆写入时强制带 user_idMCP 工具调用后无响应stdio 进程崩溃、SSE 超时、或地址配置错误检查 MCP Server 进程状态统一设置 10 秒调用超时记忆库内容越来越“脏”把模型幻觉内容也写进了记忆记忆来源分级只允许“用户明确的表述”为高置信度优先写入Agent 乱调工具频繁做无意义的查询工具描述写得模糊权限边界过大精简工具列表每个工具描述开头写清“何时不要调用”关于记忆污染的排查我想多说一句。有一类问题是模型在推理过程中生成了错误结论随后这个结论被当成事实写入记忆库后续对话就在错误基础上越走越远。我们也讨论过“创伤记忆”的类比——一次错误写入如果不加干预会持续影响后续所有判断。我的对策是给每条记忆标记来源类型来自用户直接表述的记忆是最高可信度来自模型总结的记忆必须附带“需要用户确认”标记且设置较低置信度。每次记忆被检索到时Agent 可以根据置信度决定是直接引用还是先向用户验证一次。另一个排查经验是关于 context 泄压的。有同事问“上下文窗口用完了没到触发阈值就已经卡死怎么办”。这种情况多半是测试会话里积压了大量工具返回结果尤其是那些返回 JSON 的接口一个完整的工具结果动不动就占 1500 到 3000 Token。我建议工具返回侧做瘦身MCP 服务端不返回全量数据只返回结构化的摘要和必要字段详细内容留待用户下一步点击查看。这个优化做完上下文占用直接降了 45%。最后分享一些个人习惯。第一每次发版前我会专门跑一遍“记忆回放”测试用同一批用户操作脚本连续跑三轮确认第二轮、第三轮的回答能正确引用第一轮留下的记忆这比任何单轮测试都能暴露问题。第二向量库不是越大越好我会定期给记忆做一次“遗忘演练”——筛选超过 90 天未命中、置信度低于 0.5 的记忆人工或自动清理一遍让检索质量始终保持在比较好的水平。第三MCP 工具体系刚引入时我有段时间把能接的都接上了结果模型频繁在工具之间“迷路”后来砍到只剩 5 个核心工具准确率反而大幅回升。工具这东西够用就好不是越多越强。