LLM应用基础设施：Memory、Context持久化与多模型路由实战

Reddit上一条帖子引爆讨论：做AI产品的开发者70%时间在写Memory、Context Persistence和多模型路由的胶水代码。这层"基础设施"正在成为2026年AI应用真正的护城河。

一条Reddit帖子，戳中了所有AI开发者的痛点

7月初，r/MachineLearning上一条题为《Developers building with LLMs, how are you actually handling memory, context persistence, and multi-model routing?》的帖子火了。发帖人自述"做AI产品几个月，花在实际产品上的时间不到三成，剩下的全在跟context management、memory persistence和多个LLM provider较劲"。

评论区超过800条回复，几乎每个做过LLM应用的开发者都在同一句话里投了赞成票：大家都在独立地重复造同一套轮子。

这不是新问题，但2026年了，它仍然没有一个公认的解法。GPT-5.1、Claude Opus 4.8、Gemini 3 Pro，模型层的军备竞赛打得如火如荼，可轮到应用层，工程师们还在为"怎么让Agent记住上周的对话"、"context超了怎么办"、"这个任务该路由到哪个模型"这些看似基础的问题手写胶水代码。

我们把这场讨论、以及最近半年围绕它的行业动作梳理了一遍，发现一件事：LLM应用的"基础设施层"（Infra Layer）正在快速定型，但仍处于非常早期的Wild West阶段。

一张示意图，展示LLM应用的分层架构——最下面是模型API层，中间是Memory/Context/Routing的基础设施层，最上面是应用逻辑层

Memory：从"塞进prompt"到"外化状态"的范式迁移

先说Memory。这个词现在被用得很泛，需要拆开看。

开发者说的"memory"至少包含三种东西：

Session memory：一次对话内的短期上下文，本质是context window的管理
Long-term memory：跨session的持久化记忆，用户上周说了什么、这个客户的偏好是什么
Semantic memory：结构化的知识库，通常用RAG实现

2024年到2025年上半年，大家的主流方案是"塞RAG"——把向量数据库当成万能药，Pinecone、Weaviate、Chroma、Qdrant轮流上，检索top-k扔进prompt。但半年下来，问题暴露得很彻底：

检索精度撑不住复杂场景。语义相似不等于相关，用户问"上次那个bug我们是怎么解决的"，向量检索大概率给你返回一堆包含"bug"和"解决"关键词的无关片段。

上下文膨胀失控。为了保险起见把top-20都塞进去，一次调用几万token，成本和延迟同时爆炸。

Memory之间的冲突没人管。用户三个月前说"我喜欢简洁的回复"，一个月前说"给我更详细的解释"，检索时两条都命中，模型该听谁的？

有意思的是，最近半年出现了一个明显的转向：从"检索式Memory"到"编辑式Memory"。

一些团队开始把Memory当成一份"活文档"来维护——Agent每次交互后，让一个后台的小模型（通常是Haiku 4.5或DeepSeek V3.2这种便宜快的）去更新一份结构化的user profile和session summary，而不是无脑往向量库里塞新的embedding。这个思路在7月初开源的memory-bank-mcp-server里体现得很清楚：上下文持久化不是记住所有东西，而是维护一份可以被"记起"的结构化状态。

知乎上有篇《LLM智体中的外化：记忆、技能、协议和框架工程的统一综述》讲得挺到位——LLM Agent的构建方式正在从"改模型权重"转向"重构运行时环境"，Memory从模型内部功能被显式地externalize出来。这是一个方向性的判断，值得记住。

Context Persistence：Claude Code和ChatGPT Agent教会我们的事

如果说Memory是"你记住了什么"，那Context Persistence就是"你怎么把状态穿过时间"。这两个概念常被混用，但工程上完全不是一回事。

Context Persistence的核心挑战是：一个Agent任务可能跑几分钟、几小时甚至几天，中间可能重启、可能切换设备、可能被中断——怎么让它接着干下去，而不是从头再来？

Anthropic的Claude Code今年初推出的Sub-agents和Session Resume机制，是一个被广泛参考的范本。它把每个session的完整状态（对话历史、工具调用记录、文件修改、待办任务）序列化到磁盘，任何时候都可以resume。开发者可以退出终端、重启电脑，第二天回来输入claude --continue，Agent接着上次的地方干活。

这看起来简单，但工程上很讲究：

什么状态需要持久化，什么不需要？工具调用的中间结果要不要存？如果存，磁盘占用会爆炸；如果不存，resume之后可能得重跑
状态怎么压缩？长会话的对话历史动辄几十万token，直接存下来resume时又得全部加载进context
并发session怎么处理？用户在手机上开了一个session，桌面上又开一个，Memory要不要同步？

最近几个月，业界基本形成了一个共识方案：分层持久化 + 增量快照。热数据（当前活跃的context）放内存，温数据（最近几次交互的摘要）放Redis之类的KV存储，冷数据（历史session、结构化知识）放对象存储或向量库。快照采用增量方式，只保存变更部分。

AWS在6月发布的Agentic AI基础设施白皮书里，直接把这套机制类比成"虚拟机的快照恢复"——通过状态快照实现亚秒级的Agent恢复，比重新启动一个Agent快10-100倍。这个类比很贴切，因为Agent本质上就是一个长时间运行的进程，进程管理那套东西早就被操作系统解决过一遍，现在轮到LLM应用重新发明一遍。

多模型路由：从"选一个"到"混着用"

然后是多模型路由——这一块的分歧最大，也最有意思。

2024年大家还在讨论"该选GPT还是Claude"，2025年下半年开始，问题变成了"什么任务用什么模型"，到了2026年，一个新的共识开始形成：任何非玩具级的LLM应用，都必然是多模型的。

原因也很朴素：没有一个模型在所有维度上都是最优的。

复杂推理和长上下文，Claude Opus 4.8和GPT-5.1是第一档，但贵、慢
代码生成，Claude在软件工程任务上仍然领先半个身位
中文场景，DeepSeek V3.2和Qwen3-Max性价比压倒性优势
高并发的简单分类、抽取任务，Haiku 4.5和Gemini 3 Flash便宜到可以忽略成本
多模态特别是视频理解，Gemini家族仍然是唯一选择

一张多模型路由的决策流程图，展示任务如何根据复杂度、成本、延迟、能力等维度被路由到不同模型

路由策略上，开发者们的做法可以分成几派：

规则派：写一堆if-else，按任务类型硬编码。简单粗暴，但维护成本高，模型一更新就得重写规则。

级联派：先用便宜模型试一遍，输出置信度低或者用户不满意，再升级到贵模型。省钱，但延迟不可控，用户体验飘忽。

分类器派：训练一个小模型（或用LLM+few-shot）做路由决策。这是目前生产环境用得最多的方案，Martian、RouteLLM这些开源项目走的都是这条路。

并行派：同一个请求同时打给多个模型，用一个judge模型选最好的答案。质量高，但成本翻倍，只适合关键任务。

真正落地的时候，痛点其实不在路由算法，而在基础设施：

不同provider的API格式不一样，得写一堆adapter
每个provider的rate limit、error code、retry策略都不同
国内直连OpenAI、Anthropic受限，得走代理，稳定性和延迟都是问题
计费和用量监控得自己实现，不然月底账单能吓死人

这也是为什么最近半年，API聚合类的服务在开发者圈子里越来越有市场。像OpenAI Hub这类平台的思路是把常用的主流模型（GPT-5.1、Claude Opus 4.8、Gemini 3 Pro、DeepSeek V3.2等）统一到一个OpenAI兼容的接口下，一个Key调所有模型，国内直连，把adapter、rate limit、故障切换这些脏活干掉。对于不想在这层花时间的团队，确实省事——但也要提醒一句，如果你的应用对模型细粒度控制（比如特定的system prompt格式、tool use的具体行为）有强依赖，聚合层可能会屏蔽掉一些细节，需要自己权衡。

一个残酷的现实：这层基础设施还没有Rails

讨论到这里，绕不开一个问题：为什么2026年了，LLM应用层还没有一个像Rails、Django、Spring那样的"事实标准"框架？

LangChain、LlamaIndex这些老玩家在过去一年里评价明显下滑，社区抱怨"抽象层太多，出问题时根本不知道该改哪里"。新兴的Vercel AI SDK、Mastra、Inngest的Agent Kit定位更垂直，但也没有一个能覆盖Memory+Context+Routing的完整方案。

有个观点最近在开发者圈里被反复引用：LLM应用还处于"每个团队都在写自己的runtime"的阶段。这跟2005年前后每个Web公司都自己写MVC框架的情况非常像。要出现真正的Rails级别抽象，前提是社区对"什么是好的Agent架构"达成共识——而现在，共识远未形成。

一个乐观的信号是，最近半年MCP（Model Context Protocol）的采用率明显上升，Anthropic、OpenAI、Google都在往这个方向靠。如果MCP能真的成为跨厂商的"USB-C接口"，那么Memory和工具调用的标准化就有了根基，上面才有可能长出真正好用的框架。

给正在构建LLM应用的开发者几点实际建议

结合Reddit那场讨论和最近的行业动向，我们提炼几条相对没有争议的建议：

别急着上向量数据库。80%的Memory场景，一个结构化的user profile文档 + session summary就够用。上向量库之前先问自己：我到底要检索什么？
Context持久化用增量快照。全量存历史对话是最贵、最慢、最没扩展性的方案。学Claude Code那套：分层存储，增量更新。
多模型路由从简单规则开始。别一上来就训分类器。先用if-else跑通业务，等有了足够的日志数据再考虑ML路由。
在API聚合层做抽象。不管是自建还是用OpenAI Hub这类服务，业务代码里不要直接写死某个provider的调用方式，未来切模型的成本会低很多。
给Memory加TTL。人的记忆会遗忘，Agent的记忆也应该。给不同类型的记忆设置不同的过期策略，比你想象的重要。
观测比什么都重要。每次模型调用的prompt、response、latency、cost、路由决策都要记下来。没有观测，调优就是玄学。