做 AI 应用时，为什么上下文管理比模型选型更容易决定成败
去年做一个 AI 写作辅助功能的时候，我们前后换了两次模型。第一次是因为结果不稳，第二次是因为延迟偏高。换完以后效果确实有变化，但那种“有时很好，有时很飘”的感觉一直没有消失。
最开始团队里很自然地把问题归到模型头上。毕竟结果是模型吐出来的，出问题先怀疑模型很正常。可后来排查得越多，我越觉得另一个东西更像根源：上下文。
那个功能的目标并不复杂，用户给一个主题，系统结合历史记录、模板偏好和参考资料，帮他起草一段内容。听上去很像是一个“选模型 + 写 prompt”的问题，实际做下来，最难控的反而是给模型喂什么。
我第一次意识到问题不在模型，是在一次线上回放里
那次用户问的是一个非常具体的问题，理论上系统应该直接围绕当前主题写。结果模型先引用了上一次会话里的偏好，又混进了一段不相干的参考资料，最后写出来的内容语气对、格式也对，但方向完全偏了。
如果只看最终结果，你会觉得是模型在胡说。可把整条输入链路拆开看，其实它只是很认真地在错误材料上做推断。
那一刻我才真正意识到：模型根本不“知道自己在哪个产品里”，它只知道当前这坨上下文长什么样。
你给它干净输入，它就大概率干净输出。
你给它混乱输入，它再强也很难一直稳。
上下文管理最容易出问题的地方，不是少，而是乱
最开始我们总怕模型信息不够，于是策略非常朴素：尽量多给。
历史对话带上。 用户偏好带上。 参考资料多拿几段。 系统规则写长一点。 模板说明也顺手塞进去。
表面上看很周全，实际效果却越来越不稳定。后面回头看，这种“尽量多给”的思路有两个明显问题。
第一，重要信息比例被稀释了。
用户当前真正的问题，可能只占整个上下文的一小截。模型当然能看到它，但也同样看到了很多次要甚至过期的信息。
第二，旧信息会持续污染新任务。
一旦历史里有过错误判断、过时意图或者已经无效的中间结论，它们就可能继续影响当前回答。你以为自己是在做“多轮记忆”，实际上是在把噪声不断续上去。
后来我们做的第一件事，不是换模型，而是拆信息层级
那次改完之后，我们不再把所有信息简单拼成长文本，而是先把上下文按层次拆开。
我现在做 AI 应用时，基本都会先把输入分成这几层：
- 系统规则
- 当前任务目标
- 用户本轮输入
- 历史记忆
- 外部检索或工具结果
这几层最重要的价值，不是格式好看，而是你终于能问自己一句：这个信息到底为什么出现在这里？
比如：
- 系统规则是长期边界，不该混进具体任务噪声
- 当前任务目标应该比历史会话优先级更高
- 历史记忆只保留必要背景，不该变成聊天记录堆积
- 检索结果必须为当前问题服务，而不是“顺手都带上”
一旦这么拆，很多以前糊在一起的问题会立刻显形。
历史记忆不是越长越好，这一点我后来感受很深
做对话型 AI 功能时，最容易陷进去的就是“记忆越多越聪明”。
实际并不是这样。
我们后面专门抽了一批失败样本看，发现最容易出问题的往往不是信息太少，而是带着一堆不该留下来的历史过程：
- 上一轮试错里的错误结论
- 已经被用户否定的方向
- 某次临时偏好
- 中间工具返回的半成品数据
这些东西只要留在上下文里，模型就有可能继续把它们当真。
后来我们把历史记忆改成“只保留长期偏好和关键事实”，效果反而稳了很多。比如保留：
- 用户偏好中文输出
- 用户正在做 React 项目
- 当前会话在写技术博客
而不是把整段过程都背下去。
检索上下文也一样，重点不是多，而是贴题
RAG 场景下这个问题会更明显。
以前我们的做法是召回多一点，觉得总比漏掉好。结果经常出现一种情况：模型拿到了十段资料，里面只有两段真有用，剩下八段只是“看着也有点关系”。这些噪声不会直接报错，但会把注意力拉散。
后来我越来越认可一个更朴素的判断标准：
- 这段内容是不是和当前问题强相关
- 它能不能减少模型猜测
如果答案都是否定的，那它就不该进上下文。
这也是我现在看检索系统时最在意的地方。它不是负责“多给内容”，而是负责“别把不该给的内容也塞进去”。
工具调用结果如果不清洗，也是在制造噪声
另一个很容易被低估的点，是工具结果。
很多 Agent 类应用会把工具输出原样拼回模型，图省事，但这一步经常会埋雷。
例如一个搜索工具可能返回：
- 大量无关字段
- 多个候选结果
- 冗长元数据
- 不统一的格式
模型当然可以继续读，但这等于又把一轮筛选工作丢给它了。这样不只是浪费上下文窗口，更会让后续推理开始飘。
我们后来处理工具结果时，会先做一轮清洗：
- 只保留关键字段
- 统一格式
- 必要时做小摘要
这一步做完之后，模型输出明显稳了一截。不是因为它突然更聪明了，而是因为前面的输入终于更像人给它整理过的材料。
我现在看 AI 应用，越来越像在看一个信息编排系统
以前我会更多地把注意力放在模型本身：哪个版本更强，哪个延迟更低，哪个价格更合适。
现在还是会看这些，但我更先问的是：
- 当前任务到底需要哪些信息
- 这些信息谁先谁后
- 哪些该长期保留，哪些只对本轮有效
- 哪些内容可能污染后续回答
如果这些问题没想清楚，换再好的模型也很难彻底解决“有时很好，有时很怪”的波动。
写在最后
我现在越来越相信，AI 应用里真正难的，不是把模型接上，而是把上下文管住。
模型当然重要，但很多所谓“模型不稳定”的问题，最后都能追溯到输入组织得不够干净。谁能把对的内容、按对的层级、在对的时机交给模型，谁的系统通常就更稳。模型选型会变，上下文治理能力才是更长期的竞争力。