一个参数的变化，可能比换模型更影响你的Agent账单
10月12日，OpenAI的Codex负责人Tibo在X上宣布：GPT-6.1 Sol在Codex和Work环境的默认上下文窗口，从27.2万token提到50万token，涨幅约八成。订阅用户不再为长上下文单独付费，手动配置最高可以开到约100万token。同一周的Codex更新日志还写着，GPT-5.5将在10月14日从ChatGPT和Codex全计划下线，只在API保留。
上周我们刚拆过模型路由，讲的是”不同任务配不同档位的模型”。这周这个变化是另一个维度：同一个模型，一次能记住和处理的信息量，几乎翻倍了。对正在搭企业Agent的老板来说，这件事直接关系到三个问题：哪些业务突然能做了、钱会不会多花、选供应商该多问什么。今天一次拆清楚。
先搞懂：上下文窗口到底是什么，50万token是个什么概念
上下文窗口就是模型一次对话能同时看到的全部信息，包括你发给它的资料、历史对话和它输出的内容。超出这个量，系统就会把前面的内容压缩成摘要，细节开始丢失，这个动作叫自动压缩（compaction）。Tibo这次调大默认值，官方给的理由就是减少长任务里的压缩次数。
50万token的直观体量：
1. 中文大约相当于35万到45万字，接近一套中型合同库或一整本技术手册
2. 代码上能装下一个中型项目的完整代码库，不用拆模块喂
3. 业务上能把一个客户几年的沟通记录、订单、售后工单一次读全
4. API侧GPT-6.1 Sol的窗口上限是105万token，单次最大输出12.8万token
以前要靠”检索一部分、喂一部分”才能勉强做的任务，现在可以整份塞进去，Agent处理多文档、长周期任务时的”断片”明显减少。
产品拆解：免费和收费的边界，老板必须看清
这次变化最容易被误读成”长上下文全面免费了”。不是。免费和收费是按使用方式分的。
| 使用方式 | 上下文规则 | 费用规则 |
|---|---|---|
| ChatGPT订阅内的Codex/Work | 默认50万，手动最高约100万 | 订阅用量不收长上下文附加费 |
| API接入（企业自研/供应商集成） | 上限105万，默认27.2万以内为常规价 | 输入超27.2万的部分按2倍计，输出超量按1.5倍计 |
| 缓存命中的重复内容 | 与窗口无关，单独计费 | 缓存输入价低至每百万token 0.1美元 |
GPT-6.1 Sol的API常规价格是每百万token输入2美元、输出10美元。翻译成老板听得懂的话：员工在订阅产品里处理长文档，确实不额外加钱；但企业通过API把它接进自己的业务系统，一旦单次喂进去的资料超过27.2万token，超出的部分输入成本翻倍。窗口大了，不代表可以不计成本地往里塞东西。
哪些业务场景真的值：4类任务吃长上下文，3类任务纯属浪费
值得用的4类场景：
1. 长合同和标书审查：几百页的采购合同、招投标文件一次读完，跨章节追同一个条款，不用人工拆文件，这是最典型的受益场景
2. 客户全景服务：把一个大客户的历史沟通、订单、投诉、合同一次加载，客服或销售Agent回答”我去年买的那个型号现在怎么升级”不再断片
3. 代码和技术文档维护：整个代码库加文档一起进窗口，Agent改一处能看到全局关联，Codex这次优先升级就是为这个
4. 尽调和多资料综合：外贸客户背调、供应商资质审核，几十份网页和PDF一次性交叉核对
不值得用长窗口的3类任务：
1. 翻译、摘要、分类这类单次短任务，输入几千字顶天了，开50万窗口没有任何质量收益
2. 每天重复处理同一批手册的场景，正确做法是用检索加缓存，而不是每次全量重发，重复发送长文本等于反复付邮费
3. 高并发的客服问答，每个会话都挂上几十万token背景，响应变慢、成本翻倍，体验和账单双输
还有一个技术现实要提前知道：窗口大不等于答案自动变好。行业测试反复出现过”中间遗忘”现象，信息塞在长文最中间，模型的关注度会下降。所以长文档照样要讲结构，关键信息放在开头和结尾附近，重要约束在任务指令里重申一遍。
企业搭Agent：长上下文怎么落地，给3步实操
第一步：先盘点任务的”资料体量”，再决定架构。把业务里需要AI读资料的任务列出来，记录每次实际要喂多少字。单次稳定超过20万字的任务，才值得为长上下文做设计；10万字以内的，传统的检索增强方案（先检索相关段落再喂给模型）又便宜又准。很多供应商一听你要做知识库，就鼓动你把全量资料塞进窗口，先拿这道题验一验它的专业度。
第二步：长文档加检索混合用，别二选一。成熟的企业打法是”检索定范围、长窗口读全文”：先用检索从几千份文档里圈出最相关的20份，再让模型在长窗口里完整读这20份。既控制了输入量，又保证单份资料不被掐头去尾。重复使用的固定资料走缓存，缓存命中部分价格是常规输入的二十分之一，这一项在高频场景能省一大块。
第三步：设上下文预算和人工复核点。给每类任务设一个token预算上限，让技术人员在配置里打开自动压缩阈值的监控，接近上限时告警而不是静默压缩。合同审查、报价、客户承诺这类高风险输出，保留人工复核，长窗口降低了断片率，但没消除幻觉，尤其涉及数字和条款的引用，必须能回溯到原文页码。
选供应商，这周起多加这4个问题
第一问：我们的业务资料，你是建议全量进上下文还是检索加窗口混合？凭什么这么建议？答不出任务体量分析、只会说”我们支持超长上下文”的，淘汰。
第二问：API调用超过27.2万token之后怎么计费？能不能给出我们预估用量下，27.2万以内和超出部分的分开测算？注意订阅免附加费只限官方订阅用量，集成到企业系统里走API是另一套价。
第三问：重复资料用不用缓存？缓存命中率能做到多少？这直接决定高频场景的账单。
第四问：上下文压缩发生时，我们怎么知道、怎么控制？关键信息被压缩丢失后，输出错误谁来兜底？有没有原文溯源和人工复核环节？
本周就能做的3件事
1. 让团队列出所有”要读资料”的AI任务，标注单次资料的实际字数，分出长文档任务和短任务两档
2. 选一个最痛的长文档场景（合同审查或客户历史最合适），用订阅版产品跑10份真实资料，记录一次通过率和还需要人工补看的地方
3. 拿着上面4个问题找现有供应商或集成方要书面答复，重点要一张分档成本测算表
模型的记性越来越好，但企业用AI的核心功夫没变：搞清楚哪些任务真的需要这么好的记性，然后为需要的部分付钱、为不需要的部分设边界。窗口翻一倍是工具的进步，把工具用出多少回报，考验的还是业务账算得清不清楚。
扫码添加企业微信客服
华企手记
这周帮一个做外贸的客户重新设计客户资料Agent，他之前的方案是技术供应商报的：把十年的客户资料、产品手册、来往邮件全量塞进模型上下文，说现在窗口大了，一次搞定。我让他们先拉了两周的真实任务数据，结果八成请求只涉及单个客户最近半年的记录，全量加载纯属浪费，按API超量计费算下来，一年要多掏好几万。后来改成检索加窗口混合，先按客户号圈定资料，再让模型完整读这一小批，重复手册走缓存，单次成本降到原来的零头，回答还更准了。这个老板有句话说得挺好：以前以为用AI就是追最新的模型，现在发现真正值钱的是有人帮他算清楚什么任务该用多少能力。OpenAI把窗口做大是好事，但好刀用在不用切菜的地方，照样是浪费。我们做服务的本分，就是站在客户的业务这一侧，把这些参数一个个翻译成钱和效果。
微信搜华企在线，获取更多AI智能体实操干货。
想了解我们的AI智能体服务，访问 /services 页面。
