一百万 token 不是记忆：长上下文为何仍需要上下文工程

百万 token 上下文给人的直觉是：把所有资料塞进去，模型就拥有了完整记忆。这个比喻很诱人，也很危险。上下文窗口只是本次调用可读取的工作区；请求结束后它不会自行决定什么值得长期保存，也不会辨认新旧事实的冲突，更不会保证每一处信息都得到同等注意。

Gemini 1.5 的研究证明长上下文可以完成跨文档与长序列检索，这是重要进步。但 Lost in the Middle 等研究也显示，信息所在位置会影响模型使用它的能力。容量扩大解决了“放不下”，没有自动解决“找得准、信得过、用得好”。

一套可用的记忆系统通常先把原始对话转成带来源的候选事实，再依据稳定性、敏感度与适用范围决定是否写入。任务开始时，它通过语义相关、时间新鲜度和权限边界召回少量记录，并把冲突显式呈现给模型。任务结束后还要合并、降权或遗忘。这个循环与单纯扩大窗口不同，它在管理信息的生命周期。每个环节都需要独立记录，才能解释某条记忆为何出现。

记忆至少包含四个动作：把事件写成可复用记录，在需要时召回相关片段，合并重复或冲突事实，以及在信息失效时删除或降权。上下文是空间，记忆是策略。一个把全部聊天记录机械拼接进去的助手，可能比只加载五条高相关事实的助手更贵、更慢，也更容易被旧指令带偏。

全量上下文的危险不只在费用。旧指令可能压过当前目标，重复材料会制造虚假的证据密度，来自外部文档的恶意文本也能随历史长期存在。摘要同样不是万能解法：多轮压缩会丢掉条件与例外，使后来模型在看似干净的记忆上做出错误判断。容量越大，未经治理的信息债务反而越不容易被察觉。用户通常要到一次严重误用发生后才发现这笔债务。

产品设计应把记忆分层。短期工作记忆保存当前目标、约束与中间状态；情节记忆记录发生过的任务；语义记忆沉淀稳定偏好与领域事实；外部资料通过检索按需进入。不同层需要不同保留期、权限和证据来源，不能共享一个无限增长的文本桶。

写入往往比召回更难。用户的一句临时要求不一定是长期偏好，一次失败尝试也不该成为永久规则。系统应该记录来源、时间、置信度和适用范围，并让用户看见、修正和删除。未经治理的记忆，会把个性化变成累积误解。

评估记忆产品时，可以设计跨会话任务，观察系统是否在正确时刻使用正确事实，并同时测量不该召回的内容。测试集应包含偏好变化、同名项目、过期截止日期、用户主动删除和不同权限空间。一次命中并不代表成功；系统还应展示依据，让用户能纠正。召回、拒绝召回和纠错成本需要一起进入验收标准。尤其要检查删除之后，摘要与缓存是否仍残留旧信息。

长上下文仍然很有价值，尤其适合需要整体结构的代码库、法律材料和多模态记录。正确用法是把它作为高带宽工作台：先用索引或检索缩小范围，再把足够完整的原文交给模型推理，同时保存引用位置，避免摘要层层压缩后失真。

工程指标也应从窗口大小转向有效上下文。团队要测关键事实召回率、冲突消解、过期信息使用率、提示注入暴露面和每次任务的上下文成本。模型支持一百万 token，并不代表产品应该每次都发送一百万 token。

记忆的本质不是保存过去，而是帮助未来行动，同时不剥夺用户重新定义自己的权利。由此看，遗忘并非存储不足，而是一种产品判断：临时情绪应淡出，已撤销信息应消失，关键承诺则需保留证据。真正成熟的助手会把连续性与可变性同时纳入设计，让历史服务于关系，而不是把关系锁死在历史里。这份克制本身就是长期信任的一部分。

真正有黏性的助手不会因为记住一切而胜出，而会因为知道什么不该记、什么时候该问、怎样让用户纠错而被信任。好的记忆不是更长的历史，而是更好的选择。长上下文是基础设施，连续关系才是产品能力。

在知识工作场景中，长窗口最适合承载一次任务需要整体理解的材料，例如合同全部条款或代码库的跨文件关系；长期记忆则只保存后续仍有价值的结论、偏好与出处。二者之间需要一道显式的提炼门槛。若每份原文都自动变成记忆，项目结束后，大量上下文会继续污染无关任务。提炼时保留原文链接，能让未来使用者回到证据而非只相信摘要。

以《一百万 token 不是记忆：长上下文为何仍需要上下文工程》为例，真正可落地的单位不是一次模型调用，而是一张任务卡：输入来自哪里、允许调用哪些工具、什么证据可以判定成功、超过多长时间或多少成本就必须停止。把这些条件写成运行时契约，团队才能区分“模型给了一个看似合理的答案”和“系统完成了一项可以交付的工作”。

这类系统最值得警惕的不是显眼的答错，而是稳定地在错误目标上表现得很流畅。检索到过期材料、把相关性误作因果、验证器和生成器共享同一盲点，都会让结果看起来更有条理却并不更可靠。因此评测必须保留反事实、冲突证据和拒答样本，专门测试系统何时应该减速或说不知道。

上下文工程还涉及排序与表达，而不仅是检索命中。关键约束应靠近当前指令，原始证据要保留出处，相互矛盾的材料不能先被摘要成一个虚假共识。团队可以查看模型实际接收的上下文包，分析哪些内容从未被使用、哪些内容经常误导。优化目标应是提高有效信息密度，而不是填满可用窗口。相同资料采用不同编排顺序，也应作为评估变量单独测试。

运营层面，应把成功率拆成可观察的漏斗：是否理解任务、是否拿到足够证据、是否完成有效行动、用户是否接受结果，以及失败能否低成本恢复。只报一个最终准确率，会掩盖不同环节的瓶颈。按任务价值和风险分层记录这些事件，才能决定昂贵推理、工具调用和人工复核究竟该投向哪里。

从用户视角看，记忆系统是一种持续替自己作判断的编辑机制。它决定哪些经历代表“我”、哪些要求仍然有效，因此不能完全躲在后台。让用户检查每次召回虽然过重，但在关键建议中标出使用的长期信息，能提供必要的可见性。系统越擅长记忆，就越需要证明它没有擅自定义用户。特别是涉及职业、健康与关系的判断，错误画像会产生持续影响。

组织也需要为模型行为预留版本纪律。提示词、工具描述、检索索引、模型权重和评测集中的任何一项变化，都可能改变结果；没有基线和回放机制，团队无法判断一次升级是在进步还是在转移失败。把运行轨迹与输入版本保存下来，不是为了事后追责，而是为了让改进真正可学习。

长期来看，模型能力会继续变化，难以替代的资产则是对任务的理解：哪些情况可验证、哪些错误代价最高、哪些决策需要人来承担。能把这些判断沉淀为评测、路由和交付边界的产品，才会把通用能力变成持续可靠的服务，而不是把每次模型更新当成一次重新下注。