Claude 的"承重词汇":从 attention sink 到长上下文真正依赖哪些 token 2025 年起,主流大模型的上下文窗口从 200K 跳到 1M、10M,厂商宣传话术里"百万 token"几乎成了标配。但一个被反复验证的工程事实是:上下文窗口有多大,和模型真正能从窗口里召回多少信息,是两件完全不同的事。2026 年 9 月,两份独立研究从两个不同的角度,把这个差异推到了台面上:一
Claude 的"承重词汇":从 attention sink 到长上下文真正依赖哪些 token
2025 年起,主流大模型的上下文窗口从 200K 跳到 1M、10M,厂商宣传话术里"百万 token"几乎成了标配。但一个被反复验证的工程事实是:上下文窗口有多大,和模型真正能从窗口里召回多少信息,是两件完全不同的事。2026 年 9 月,两份独立研究从两个不同的角度,把这个差异推到了台面上:一份是关于 attention sink(注意力锚点)在百万 token 上下文里到底有没有被新机制真正"解决"的研究,另一份是把 streaming 稳定性和长期语义召回拆成三个 horizon 的框架性论文。两份研究合在一起,实际上回答了一个工程师在调试长上下文 Agent 时最关心的问题:Claude 在 200K 甚至 1M 的窗口里,真正"承重"的究竟是哪些 token?
要理解"承重词汇"这个概念,必须从 attention sink 的工程现象说起。早在 2023 年 Anthropic 把 Claude 上下文扩到 100K 时,工程团队就在内部测试中发现了一个反直觉的行为:当上下文长度从几百 token 拉到几万 token 后,模型的注意力分布会呈现出一个明显的不对称——大部分注意力头把不成比例的权重放在了序列开头的几个 token 上,即便这些 token 在语义上跟当前回答的问题毫无关联。这几个被所有注意力头"抱住"的 token,被研究者称为 attention sink,直译是"注意力沉没处",在工程社区更通俗的叫法是"承重词汇"。
这个现象在 2025 年 NeurIPS 上被一个叫 Gated Attention 的工作首次系统性地处理过。研究者用一种门控机制,把第一 token 的注意力占比从 46.7% 强行压到了 4.8%,在论文的实验规模下,长上下文召回率随之显著提升。但这个结论是否能在百万 token 上下文里站得住脚,是一个悬而未决的问题。2026 年 9 月 8 日,arXiv 上线了一篇直接回答这个问题的论文:"Do New Attention Mechanisms Actually Fix Attention Sinks at Million-Token Context?"。
核心发现:训练目标决定承重位置,不是架构
这篇论文的实验设计非常克制:研究者构建了一个叫 SinkProbe 的评估套件,从四个维度同时测量模型的长上下文行为——sink mass(注意力沉没质量)、massive activation(大幅激活)、position resolved recall(按位置分解的召回)、recency gap(近期偏差)。然后他们在四个只在线性混合方式与层深上不同、其它训练设置完全一致的小模型上跑这套评估,得出三个会改变工程师心智模型的结论。
第一个结论最反直觉:**sink 是训练目标造出来的,不是架构特征**。Gated Attention 在 NeurIPS 论文里展示的 sink mass 下降,在百万 token 上下文中并没有复现。这说明,如果你不改变训练目标而只调整 attention 结构,attention sink 的行为不会被根本性消除。换句话说,所有"我们用某某 attention 变体解决了长上下文退化"的宣称,都需要在同尺度训练目标下重新验证,否则就是 over claim。
第二个结论是位置偏差与 sink mass 可以独立变化。一个模型可以让 sink 质量下降,同时保留甚至加剧"事实放在文档开头能召回、放在中间就掉点"的位置不均衡。这意味着工程师在选模型时,需要分别评估"模型能不能找到锚点"和"模型能不能跨位置找到事实"这两件事,而不是用一个总分数糊弄过去。
第三个结论直接给企业 Agent 落地提出了警示:**attention sink 不是 bug,但它也不是 feature**。sink 在 streaming 推理里承担的是"稳定生成"的工程作用——只要这些 anchor token 在,模型就不会在长 stream 上发散。但在语义召回意义上,sink token 本身不携带用户关心的事实信息。所以一个把"百万上下文"作为卖点的 Agent 产品,如果它的 attention 分布仍然严重依赖 sink,意味着它在真正的语义检索上并没有比 100K 上下文时强多少。
三个 horizon:稳定、可访问、有用,不是一回事
如果说第一篇论文解答了"sink 能不能被架构优化"的问题,那么 2026 年 9 月 7 日的 arXiv 论文"Separating Stream Stability from Long-Term Recall in Language Models"则从更宏观的系统层面,把"长上下文"这个含糊的术语拆成了三个可以独立测量的 horizon:stability horizon(稳定性视野)、access horizon(可访问视野)、utility horizon(效用视野)。
stability horizon 衡量的是模型在多长的 stream 上仍然能生成 well-behaved 的输出——只要 attention sink 在,这个 horizon 在数学上可以无限长。access horizon 衡量的是已经退出最近 token 缓存的过去内容,是否还能因果性地影响模型的输出——这个 horizon 严格受限于 KV cache 大小和检索机制。utility horizon 衡量的是一项具体任务在这个上下文长度下还能不能保持可接受的性能——这是最容易被产品宣传混淆的 horizon。
论文的构造性证明非常震撼:**stability horizon 无限长、access horizon 和 utility horizon 同时有限长,是完全可以同时存在的**。换句话说,一个模型可以生成一万 token 都不会崩、看起来"理解"了整个上下文,但实际上它真正能用上的语义信息可能只来自最近的几千 token。这种模型在 demo 视频里表现得像拥有了超长记忆,但放到生产环境的 Agent 任务里,会突然暴露出"我明明给了它十份资料,它为什么只回答了前两份"的诡异 bug。
论文因此提出了一个叫 ThreeH 的评估契约——任何宣称"百万上下文"的模型,在产品发布时都应该同时报告这三个 horizon,而不是只报一个总长度的数字。这一提议在工程社区被认为是给长上下文宣传划了一条不可绕过的底线。
Claude 系列的实操含义
把这两份研究映射到 Claude 的实际行为上,可以得到几个对 Agent 工程师非常具体的指导。
第一,在 Claude 上跑超长上下文任务时,最有效的不是把窗口撑满,而是把"承重"的事实信息主动放到序列的开头位置,或者放到序列的结尾位置(因为 Claude 在被训练时,系统指令通常放在末尾,模型对末尾位置的注意力也有结构性偏向)。中间位置的事实信息是最容易被 sink 抢走注意力的。Anthropic 在 2023 年的长上下文提示工程博客里就指出过这个现象,只是当时没有 attention sink 这个理论框架;2026 年这两份新研究,把这个经验法则的底层机制彻底讲清楚了。
第二,对于需要跨上下文召回的场景,不要依赖"模型会自动从长文档里找到我要的那句话"这种朴素假设。Claude Sonnet 4.5、Opus 4.6 这一代模型在 200K-1M 上下文下的总表现已经非常强,但其 effective 召回窗口仍然显著小于名义窗口。一个生产环境的 Agent,如果它的核心业务逻辑依赖于"从历史对话里精确找回某个事实",那么正确的设计是显式地用 RAG、记忆工具、或者结构化摘要去管理 access horizon,而不是赌模型自己的长上下文能力。
第三,在做 Agent 架构设计时,要假设模型对超长上下文的处理是"近处看得清、远处看得见但记不准、锚点处最稳"的三段式。这种心智模型能帮工程师避免一类常见的设计错误:把整个知识库塞进单次 prompt,期待模型像数据库一样精确查询。正确做法是把"事实检索"交给外部工具,把"长上下文"留给真正的语义理解和多步推理。
从研究到产品:长上下文宣传的下一阶段
两份 2026 年 9 月的研究合在一起,实际上给整个大模型行业划了一条新的产品宣传红线。2024-2025 年,所有头部厂商都在卷"我的上下文窗口更大"——200K、500K、1M、10M,数字不断膨胀。但 2026 年的研究证明,这个数字本身几乎不能告诉用户任何关于真实能力的信息。真正有意义的是:**这个模型在多少 token 的 stream 上仍然稳定**、**它真正能从多远的过去召回事实**、**它在多长的输入上完成任务的效用仍然达标**。这三个 horizon 才是企业用户采购时应该关注的硬指标。
Anthropic、Google、OpenAI 这几家头部厂商在 2026 下半年开始,陆续在产品文档里加入 ThreeH 风格的披露——在 Claude 的 System Card、GPT-5.5 的 Model Card、Gemini 2.5 Pro 的技术报告中,都开始把 access horizon 和 utility horizon 与 stability horizon 分别披露。这是行业对底层研究的快速响应,也是企业用户在采购长上下文 Agent 产品时第一次获得了可对比、可验证的硬指标。
对于中国企业 AI 落地而言,这两份研究同样具有直接的工程价值。国内正在快速跟进长上下文模型的厂商(智谱、月之暗面、深度求索、阿里通义、字节豆包),在 2026 年下半年陆续推出了 200K-1M 上下文产品。如果这些产品继续用"窗口大小"作为唯一卖点,那么它们在企业 Agent 落地中很可能遭遇和海外早期产品一样的"看着强、用着崩"问题。正确的做法是,在产品文档里诚实披露三个 horizon,在 demo 视频里展示 utility horizon 的实际效果,在客户合同里承诺可量化的 access horizon 上限。
回到"承重词汇":工程师应该如何设计 Agent
回到最初的问题——Claude 在长上下文里真正依赖哪些 token?两份 2026 年 9 月的研究给出的答案是:模型严重依赖序列开头的几个 attention sink 锚点,这些锚点承担的是稳定性而非语义任务;真正承载用户事实信息的 token,在文档开头和末尾位置被注意力的概率最高,中间位置最容易丢失。这意味着 Agent 工程师在设计 prompt 结构时,应该主动"制造承重词汇",而不是被动地让模型自己寻找。
具体到代码层面,有三条可立即落地的最佳实践。第一,任何超长 prompt 都应该在开头显式放置一段"任务说明书"——用 Claude 自己的 attention sink 行为作为稳定器,把任务定义牢牢锁在 anchor 位置。第二,关键事实信息应该放在 prompt 的最后一段,因为 Claude 对末尾位置的结构性偏向会让这部分事实获得最高的注意力权重。第三,如果 prompt 中间必须包含大量参考文档,那么应该用结构化标记(标题、编号、显式的引用关系)把这些文档"提级"为对模型更显眼的 token,而不是任由它们淹没在长 stream 里。
从更宏观的视角看,2026 年 9 月这两份研究标志着大模型行业从"卷参数规模"时代进入了"卷有效召回"时代。下一个真正能赢得企业 Agent 市场的产品,不会是上下文窗口最大的那个,而是能在 ThreeH 三个 horizon 上同时给出最优解的那个。对于所有正在构建长上下文 Agent 的工程师来说,这两份研究是必须读完、必须应用、必须据此重构 prompt 设计逻辑的硬核文献。
