下一代基础模型原生支持长上下文的冲击

结论先行： 当 Gemini 1.5 Pro 把上下文窗口拉高到 100 万 Token，随后又宣布支持 200 万 Token 时，整个智能体（Agent）社区曾短暂陷入一种“资源焦虑终结”的幻觉——仿佛只要能把所有历史对话、文档、工具输出一次性塞进提示，记忆治理就会自然消失。但 2024 年至今的实践表明，容量扩容从未解决过分类问题，长上下文窗口只是把治理的战场从“如何裁剪”转移到了“如何组织”。信息仍然会淹没关键指令，成本仍然会惩罚毫无节制的输入，而安全性风险甚至随着窗口变大而成倍增长。

时间线锚点放在 2024 年 2 月：Google DeepMind 发布 Gemini 1.5 Pro，其上下文窗口达到 1,000,000 Token（约 750,000 个英文单词），足以一次性容纳《战争与和平》全本小说长度的内容。同年 5 月，Google CEO Sundar Pichai 在 I/O 大会上宣布该模型的上下文窗口将进一步扩展至 200 万 Token。这股冲击波促使每个 Agent 系统设计者重新审视上下文治理的底层逻辑——治理并不是因为资源不够才存在，而是因为信息天生需要被诠释、排序和保护。

接下来，我们将从注意力稀释、成本现实和治理范式迁移三个维度，透视长上下文原生支持究竟改变了什么，又留下了哪些无法回避的硬核问题。

大海捞针变得容易，但找对针仍然难

上下文窗口的放大，最直观的受益场景就是“大海捞针”（Needle in a Haystack）式的测试：在数十万 Token 的无关文本中隐藏一条特定事实，看模型能否准确抽取出该信息。Gemini 1.5 Pro 在 100 万 Token 级别的此类测试中表现出近乎完美的检索准确率，这似乎宣告了模型“记忆力”的质变。

然而，真实的 Agent 工作流远不止找出固定“针”那么简单。大量研究（包括 2024 年广受关注的 Lost in the Middle 系列论文）揭示了一个更微妙的注意力陷阱：当上下文长度急剧增加，模型对位于中间部分的信息的注意力会显著衰减，即便它能够回忆起开头和结尾的内容。这意味着，如果一个 Agent 将几天内的完整对话记录、中间步骤的思考链、工具返回的半结构化数据全部铺平塞入上下文，那些被夹在中间的关键决策依据很可能被模型“视而不见”。

表格 1 总结了在长上下文下，不同信息检索策略的有效性差异：

从表 1 可以得出一个清晰的行动结论：长上下文窗口让“大海捞针”的数字表现变得容易，但它并没有改变模型内部注意力分配的动力学。 Agent 仍然需要一个智能的检索和排序层，把“该看的”信息提前，把“可能被忽略但重要”的信息突显出来。治理的重点从“能不能塞进去”转变为“如何让模型真的看到并重视它”。

成本不应成为遗忘的借口，但仍是现实压力

有了百万级 Token 的上下文窗口，开发者很容易产生一种惰性：宁愿付钱买更多 Token，也不愿意花精力去做信息裁剪。 然而，成本账本用现实锤碎了这种幻想。

当前调研资料和公开的云服务定价显示，使用 Gemini 1.5 Pro 处理 1M Token 的输入，单次推理成本相比处理 128K Token 的输入大约提升 5~8 倍（具体数字随厂商定价调整，此处给出数量级关系）。更要命的是，Transformer 架构中自注意力机制的计算复杂度与上下文长度的平方成正比（O(n²)），这意味着上下文长度翻倍，计算量和推理延迟可能翻四倍。当一个 Agent 每天执行数百次推理，持续将全部历史填充到极限窗口，月度成本将从可忽略的小额测试费，暴涨至令企业财务侧目的账单。

此外，还有延迟代价。Agent 的交互讲究“实时感”，尤其是面对终端用户的对话式智能体。上下文从 128K 膨胀到 1M，响应时间可能从 1-2 秒延长至 10 秒以上，这足以瓦解用户体验。

表格 2 列出了一次典型的 Agent 推理调用在三种上下文长度下的硬成本对比（基于 2024 年可观察的市场价格区间估算，仅供参考）：

结论再直白不过：即便模型原生支持百万 Token，将全部历史不加选择地塞入窗口，在经济上属于“自残行为”。主动裁剪和遗忘策略，从“因为塞不下”的被动防御，转变为“因为不想破产”的主动运营决策。成本压力由此内化为上下文治理的刚性约束，时刻提醒架构师：Token 经济学永远不会消失，它只会以另一种形式惩罚浪费。

治理范式从“节省”转向“组织”

前两个小节揭示了一个共同的走向：当空间不再是绝对稀缺品，治理的重心便从“如何节省 Token 预算”转向“如何组织信息、管理优先级”。这是一个根本性的范式迁移。

旧范式下，上下文治理的核心动作是裁剪——用滑动窗口、摘要模型、递归压缩等手段，把历史信息硬性缩减到窗口可容纳的大小。这种“节衣缩食”式的治理，牺牲了大量细节和中间推理步骤，经常导致 Agent 在复杂任务中失去上下文连贯性。

新范式下，“窗口溢出”不再是最紧迫的瓶颈，取而代之的是三个新问题：

1. 信息污染：无关或低质信息过多，稀释了关键指令的权重，也增加了提示注入攻击面（长上下文让攻击者更容易投放大量噪声掩盖恶意指令）。
2. 信息遗忘：即便窗口很大，模型仍然存在“中间失明”效应，自然语言指令和工具输出需要被主动地位置排序。
3. 信息开销：无节制的 Token 堆砌直接转化为可观的财务和延迟成本。

因此，治理手段从“尽可能少记”变成“有选择地记住，并把最相关的放在最显眼的位置”。以下清单总结了新治理范式的几个核心原则：

• 优先级分层：将上下文明确划分为“不可变的核心指令层”（如安全和人格 Prompt）、“动态任务上下文层”（当前任务相关的工具结果）、“参考记忆层”（持久化但可归档的过往信息）。模型在注意力资源分配上自然偏向前者，Agent 通过结构化模板确保每次推理时前三层的信息都能出现在窗口上半区。
• 索引与摘要双轨制：长对话或长文档不再直接全文进入，而是先用轻量级模型生成章节级摘要和关键词索引，并在主干上下文中仅保留索引。当任务需要细节时，再动态从外挂持久化存储中拉取完整内容，组装到当下的注意力焦点区域。
• 动态遗忘策略：根据信息的新鲜度、与当前目标的语义相关度、是否被工具实际引用，动态计算每条记忆的保留优先级。即使窗口尚未填满，低优先级项目也会被主动剔除，以降低开销并防止注意力稀释。
• 安全治理前置：由于大窗口更容易被提示注入利用，输入过滤、角色权限校验和输出守护被提前至 Prompt 构建阶段，杜绝恶意指令混入长上下文的“噪音层”中。

表格 3 直观对比旧范式和新范式的治理要点：

按场景的可行建议

针对不同形态的 Agent 系统，长上下文原生支持下的治理策略应有具体落地路径：

场景一：高频率客户支持对话 Agent

• 核心挑战：会话可能跨越多天，用户问题具有连续性，但单次交互要求低延迟。
• 治理建议：
  1. 保留最近 20 轮对话的全文（约 8K-16K Token），更早的对话仅保留由专用摘要模型生成的“本案重点索引”。
  2. 设立用户身份与历史票据的结构化 JSON 头，固定置于窗口最前部，大小控制在 2K Token 以内。
  3. 使用缓存服务避免每次推理重复计算不变的摘要和索引，降低延迟和成本。

场景二：研究型知识工作者 Agent

• 核心挑战：需要处理超长学术文档、代码库，多次推理之间需维持复杂的信息关联。
• 治理建议：
  1. 文档进入系统时即被拆分为层次化段落，并存储高维向量索引。
  2. 主上下文仅保留当前任务的指令和最近检索组件的返回片段，其余由 Agent 按需动态检索，检索密度根据“中间失明”曲线适当提高对中部区域的召回率。
  3. 引入显式的位置强化提示，例如：“以下是本次决策最关键的三个依据，务必优先依赖：[依据1]、[依据2]、[依据3]。”

场景三：企业级自动化 Agent 集群

• 核心挑战：多 Agent 间传递大量中间结果，上下文易迅速膨胀且安全风险高。
• 治理建议：
  1. 制定严格的“Agent 间消息协议”：每个 Agent 的输出必须包含指定格式的摘要标签和可信签名，接收方优先读取摘要并校验签名，全文只在异常时展开。
  2. 部署中心化的上下文清洗网关，对所有进入模型的消息进行基于规则的预过滤，去除可能被注入的重复指令或越权建议。
  3. 实施 Token 使用配额和预算告警，将治理从“可选项”变为系统级强制策略。

这些建议的共同底色是：承认长上下文是一种强大但盲目的资源，治理是赋予其方向感和经济性的唯一途径。

从 128K 到 1M，再到 2M，上下文窗口的物理边界的延展，像一次技术上的“土地大赦”——但土地增加从不意味着人们不再需要城市规划。下一章《智能体记忆的伦理与隐私边界》将接着这一思路，把视线从“如何组织信息”拉升到“可以记住哪些信息”的红线前：当智能体能够事无巨细地长时记忆用户的每个行为片段，我们如何防止它变成一个无所不在的监控器？数据的产权、遗忘的权利、算法偏见的放大效应，将成为上下文工程必须面对的下一道高墙。