1M 上下文已经可用: Claude、Gemini 与编程 Agent 怎么选

有人在搜索框里反复打”1m 上下文已经全量可用”。这背后不是想读一篇科普，而是一个很具体的工程疑问：我现在用的模型，到底是不是已经能吃下 100 万 token 的上下文？如果能，我该不该把整个仓库、整本手册、整批日志一股脑塞进去？

先把结论给你：1M（100 万 token）上下文确实已经在主流前沿模型上”可用”，但”可用”不等于”该这么用”。 它真正改变的不是某个跑分，而是一类原本做不到的任务现在能一次性做完了——比如让一个 Agent 同时看懂跨十几个文件的调用链。代价同样真实：费用随 token 几乎线性上涨、首字延迟变长、还有一个工程师最容易踩的坑——长上下文衰减（模型在超长上下文里”中间遗忘”、检索质量下降）。

这篇从工程师视角，把 1M 上下文在 Claude、Gemini、编程 Agent 三条线的可用性、成本和适用场景一次盘清楚。

一、TL;DR：1M 上下文到底意味着什么

100 万 token 大概是多少

token 不等于字。粗略地说，1M token 对应的量级是：几十万到上百万字的中文文本，或者一个中等规模代码仓库的绝大部分源码，或者几百页 PDF 的全文。换句话说，你第一次可以把”整本书 / 整个项目”作为一个整体喂给模型，而不是切片喂。

这就是它的核心价值：从”分块处理 + 人工拼接”变成”一次性全局理解”。在它之前，处理长文档要靠分段摘要、向量检索、滑动窗口这些工程手段绕；现在某些任务可以直接绕过这些中间层。

一句话工程判断

• 能用：截至目前，几家头部模型（Claude、Gemini 的部分版本）都提供了接近或达到 1M token 的上下文窗口，部分以 beta / 特定方案的形式开放。
• 别滥用：窗口大小是”上限”，不是”建议值”。把 100 万 token 全填满，意味着每次请求都在为可能用不到的内容付费，同时把模型推向它检索能力最弱的区间。
• 真正的工程问题：不是”能塞多少”，而是”该塞哪些、怎么组织、什么时候换成检索”。

如果你正在为”用哪个模型 / Agent”纠结，可以先看这两篇横评打底：Claude Code vs Codex vs WorkBuddy vs Zcode: AI 编程 Agent 怎么选 和 GLM-5.2 vs GPT-5.5: 架构、Agent 与部署取舍对比，里面对各家的定位有更细的拆解。

二、各家可用性盘点（定性，不报精确数字）

先声明：各家官方上限、单价、beta 政策一直在变，下面只做定性取舍，不把精确数值当权威事实，确切数字请以你下单时的控制台为准。

Claude：长上下文检索质量是强项

Claude 这条线最被工程师认可的，是它在长上下文里的指令遵循和检索稳定性——把关键信息埋在很长的上下文中段，它相对不容易”漏读”。它的 1M 级窗口目前更多以特定层级 / beta 通道开放，定位偏向”需要一次性吃下大量代码或文档、且对准确度敏感”的场景。

实际体感上，很多人是冲着 Claude Code 的工程闭环来的。关于它和 Codex 的对比体验，开发者实测：Claude Code 效率超越 Codex，AI编程迈向”零门槛”自然交互 和 遭遇GPT降智后转向Claude：开发者实测MCP协议打造”自举”式开发闭环 都有第一手记录。

Gemini：超长窗口铺得最早、最广

Gemini 系列是较早把”百万级上下文”作为主打卖点推开的，部分版本对外宣称的上限甚至更高。它的优势在于长文档、长视频、多模态混合的大批量摄入——一次塞进海量原始资料，让模型自己提取结构化信息。社区里有个很典型的用法：HN热帖：利用 Gemini 提取数据，绘制 Mini PC 性价比”帕累托前沿”，本质就是把成千上万条杂乱规格喂进大窗口做一次性归纳。

编程 Agent / Codex：窗口大小≠Agent 好用

这一层最容易被误解。编程 Agent 的实际”可用上下文”，往往不等于底层模型的窗口上限。 Codex、Cursor、Claude Code 这类工具会在你和模型之间做一层上下文管理：它们不会傻乎乎把整库代码塞满窗口，而是按需读文件、做摘要、压缩历史。

所以横向选 Agent 时，窗口大小只是其中一个变量，更关键的是它的上下文调度策略、额度和稳定性。这几篇可以连起来看：Codex vs Cursor 额度对比: 价格、限制与选型建议、深度解析 Cursor Composer 2.5：从”套壳”争议到拥有工作流数据的巨头护城河，以及 开发者吐槽Claude Code配置混乱：pi的模块化管理被指更胜一筹——最后这篇讨论的”配置/上下文怎么模块化管理”，恰恰是大窗口时代的核心工程问题。

定性对比一张表

注：表中均为定性判断。涉及具体跑分时，社区/公开讨论里说法不一，请按你自己的真实任务做小样本实测，不要照搬别人的 benchmark 结论。

三、真实成本与”长上下文衰减”陷阱

这一节是全文重点，也是”1m 已经可用”这条搜索词背后最该被回答的部分——因为很多人以为可用就等于免费午餐。

成本：token 几乎是线性涨的

绝大多数 API 按输入 + 输出 token 计费。这意味着：你往上下文里多塞一倍内容，输入成本大致就翻一倍。 把窗口从几万 token 拉到接近 1M，单次请求成本可能是几十倍的差距。如果这是一个高频调用的 Agent 循环，账单会非常吓人。

关于成本如何反过来决定架构选型，LLM时代的软件生存法则：SaaS自建与购买的成本临界点分析 把成本临界点量化得很清楚；订阅额度层面的真实痛点可以看 开发者热议AI订阅痛点：对比GPT Pro与Claude的额度与安全性。如果你在用中转 / 聚合方案压成本，AnyRouter 实测：模型路由、API 兼容与价格稳定性 也值得参考。

延迟：窗口越满，首字越慢

上下文越长，模型预填充（prefill）要处理的 token 越多，首字延迟会明显上升。对交互式编程 Agent 来说，每次都灌满窗口，体感就是”问一句要等很久”，开发循环被拖垮。

缓解手段是 prompt caching（提示缓存）：把不变的大块前缀（如系统提示、整库代码）缓存住，后续请求复用，既省钱又省延迟。这是用好大窗口的关键工程技巧——不是少塞，而是让重复部分不重复计费。

衰减：lost in the middle，长上下文的”中间遗忘”

这是最隐蔽的坑。研究和大量实践都观察到一个现象：当关键信息位于超长上下文的中间位置时，模型的检索准确率会下降，业内常称为 “lost in the middle”（中间遗忘）。也就是说，你把 100 万 token 填满，模型未必真的”看清”了每一个角落——开头和结尾它记得牢，中段容易糊。

这带来一个反直觉的结论：有时候塞得更多，效果反而更差。 因为你引入了大量噪声，稀释了真正相关的信号，还把关键内容推到了模型最不擅长的检索区间。

举个具体的例子。假设你要让模型基于一份内部规范回答问题，规范一共三十页。做法一：把三十页全文连同其它二十份无关文档一起塞进窗口，凑到几十万 token；做法二：只把这三十页规范放进去，其它不放。直觉上做法一”信息更全”，但实际上做法一往往更差——真正相关的三十页被淹没在无关内容里，又恰好落在容易被忽略的中段，模型抓不住重点；而做法二上下文干净、相关密度高，答得反而更准、更便宜、也更快。这就是”精确投喂”为什么经常打败”应塞尽塞”。同样的道理放到代码上也成立：与其把整个 monorepo 灌进去，不如先定位到真正相关的那几个模块再交给模型。

经验法则（按你的任务实测校准，不是绝对值）：
  上下文长度 ↑  →  单次成本 ↑（近线性）
                →  首字延迟 ↑
                →  中段检索准确率 ↓（lost in the middle）

结论：上下文是有成本的资源，要"精确投喂"，不是"能塞就塞"。

本地小模型在这点上更敏感——窗口、量化精度、显存三者互相挤压。想看这层取舍，Qwen3.6 27B vs Step3.7 IQ4_XS: 本地大模型量化精度实测 给了一张很实在的选型矩阵。

四、什么场景该用大窗口、什么场景用 RAG 更划算

把上面的成本和衰减放在一起，决策其实就清晰了：大窗口和 RAG（检索增强）不是二选一的对立，而是按任务形态分工。

适合直接用大窗口

• 需要全局连贯理解：跨多文件的代码重构、读懂一份逻辑环环相扣的长合同、分析一份首尾呼应的研究报告。这类任务一旦切片就丢失全局关系，大窗口是刚需。
• 一次性、低频的大批量摄入：把一整批原始资料喂进去做一次归纳总结，跑完就走，不进入高频循环。
• 多文件 Agent 任务：让 Agent 同时持有十几个相关文件，理解它们之间的调用关系再动手改。十年代码荒后的技术重构：创业老兵实测 Claude 与国产模型的多 Agent 协同差异 就是这种”多文件 + 多 Agent 协同”的实战样本。

适合用 RAG / 检索

• 海量、低相关密度的知识库：你有几百万字文档，但每次查询只用到其中很小一部分。把全部塞进窗口，等于为 99% 用不到的内容付费，还触发中间遗忘。这时候先检索召回相关片段、再喂给模型才是对的。
• 高频、对成本敏感的循环：客服、问答这类每天上万次调用的场景，必须把每次请求的 token 压到最小。
• 需要可溯源、可更新的事实：RAG 能给出引用来源，知识更新只要更新检索库，不用重灌上下文。

决策表

实务里最常见的其实是混合：用 RAG 把候选范围缩到几万 token，再交给具备大窗口的模型做精读和综合。两边的长处都要。

五、对编程 Agent / Claude Code / Codex 的影响

对写代码的人来说，1M 上下文最大的意义不是”能读完整库”，而是改变了 Agent 维持项目记忆的方式。

整库理解成为可能，但 Agent 仍在做减法

理论上大窗口能让 Agent 一次看懂整个仓库。但前面说过，真把整库塞满既贵又触发衰减。所以成熟的编程 Agent 走的是“大窗口能力 + 智能上下文管理”的组合：底层有大窗口托底，上层仍然按需读文件、做摘要、压缩历史对话。窗口大小给了它”必要时能展开”的余地，而不是”每次都展开”的负担。

上下文管理 = 长项目的真正分水岭

长项目里，模型每次重新打开仓库都要”恢复现场”。从哪里恢复、恢复多少，决定了它还认不认得这套代码。Claude Code 长项目踩坑: vibe coding 与 spec coding 何时切换 把这个问题讲透了：原型阶段可以”想到哪写到哪”，但项目一长，必须靠规格（spec）和结构化的上下文来锚定，光靠塞大窗口救不回来。

配置和上下文怎么模块化组织，也直接影响 Agent 的可维护性——开发者吐槽Claude Code配置混乱：pi的模块化管理被指更胜一筹 讨论的就是这件事。而当 Agent 的会话状态丢失时会有多痛，Codex CLI MCP 服务器 logout 吞 session: 复现与修复 是一个具体到根因的案例。

多 Agent 协同会放大上下文成本

当你从单 Agent 走向多 Agent，每个 Agent 都持有自己的上下文，总 token 消耗是叠加的。企业实战案例：多Agent系统重构人力资源招聘流程 能看到：Agent 越多、文档越复杂，上下文管理越是成败关键。任务对齐和拆解做得好，才不会让每个 Agent 都去灌满窗口，清华博士开源 COMPASS 司南生态更新：Task-Clarifier 升级，强化 Agent 任务对齐能力 走的就是这个方向。

给工程师的落地建议

# 用大窗口前，先问自己三个问题：
# 1. 这些内容真的都"强相关"吗？还是能先检索缩范围？
# 2. 这是单次任务，还是会进高频循环？（循环就别灌满）
# 3. 不变的大前缀，有没有用上 prompt caching 复用？

# 实操顺序建议：
#   RAG 召回  →  组织成最小必要上下文  →  缓存稳定前缀  →  交给大窗口模型精读

六、相关阅读

• Claude Code vs Codex vs WorkBuddy vs Zcode: AI 编程 Agent 怎么选：选 Agent 的横评底盘，窗口只是其中一维。
• GLM-5.2 vs GPT-5.5: 架构、Agent 与部署取舍对比：架构层面的取舍，理解各家定位差异。
• 豆包 AI 优缺点实测: 对比 ChatGPT、Claude 与 Kimi：同一批任务横评四家，看长文本处理差异。
• LLM时代的软件生存法则：SaaS自建与购买的成本临界点分析：成本临界点量化，决定你该不该上大窗口。
• Codex macOS code_sign_clone 占几十 GB 磁盘: 真相与清理：用 Codex 时另一个容易被忽略的工程坑。

七、FAQ

Q1：1M 上下文现在是不是所有人都能用上？
要分清”模型支持”和”你的账号 / 套餐能用”。前沿模型在技术上已经提供接近或达到 1M 的窗口，但是否对你开放，取决于你用的版本、层级、是否在 beta 名单内。最稳妥的办法是去你下单的控制台看当前上限，别照搬别人的截图。

Q2：把整个项目塞进 1M 窗口，模型就能完全读懂吗？
不能想当然。受 “lost in the middle”（中间遗忘）影响，塞得越满，中段信息越容易被忽略。整库代码更推荐交给具备上下文调度的编程 Agent，由它按需读取，而不是你手动一次性灌满。

Q3：大窗口和 RAG 到底选哪个？
看任务。内容强相关、需全局理解、单次低频 → 大窗口；知识库巨大但单次只用一小部分、高频、成本敏感 → RAG。现实里最常见的是两者混合：先检索缩范围，再用大窗口精读。

Q4：用 1M 上下文会不会很贵？
会。token 近似线性计费，灌满窗口的单次成本可能是常规请求的几十倍，进入高频循环后账单很可观。务必用 prompt caching 复用稳定前缀，并只投喂强相关内容。

Q5：长上下文会让回答变慢吗？
会。上下文越长，预填充处理的 token 越多，首字延迟上升。交互式编程场景尤其敏感，缓存 + 精确投喂是必要的优化。

八、结语

1M 上下文确实已经可用，但它是一种有成本的资源，不是免费容量。真正的工程能力，体现在你知道什么时候该展开整库、什么时候该退回 RAG 检索——精确投喂，而不是能塞就塞。