Claude Opus 5.5 上线，Anthropic 给它的默认上下文窗口是 1M token。定位写得直白：长时间运行的智能体编码，以及知识工作。版本说明也没藏着，新模型的默认参数、价格、API 行为变化一次列全——这份清单比发布博客更值得逐行读完。
默认 1M 上下文，改的是任务切法
从按需申请到推门就有
长上下文这件事，过去一年一直当稀缺资源来管理。切片、检索、摘要接力、多轮压缩，工程师花了大量精力在“怎么把信息塞进窗口”上。1M token 成为默认值，意味着这套手艺的优先级得往后挪。一个中等规模的代码仓库、一整季的会议记录、几十份合同，可以一次性放进同一次调用。省下来的不是 token，是架构复杂度。
长任务翻车，常常死在记忆断层
智能体跑偏，多数时候不是推理本身出错。上下文被截断，中间结论悄悄丢了，工具返回值被压缩成一行摘要——然后模型在第 40 步开始基于错误记忆做决策。窗口变大能缓解这类问题，但不等于注意力在 1M 范围内均匀分布。“中间遗忘”是模型结构层面的老毛病，参数从 200K 涨到 1M，它不会自动消失。关键信息前置、显式状态摘要，一个都省不掉。
窗口越大，账单和延迟越难看
上下文越长，预填充成本越高，首 token 延迟越难压。默认给 1M，不代表每次请求都该塞满 1M。缓存命中率、分段预填充、按任务裁剪历史，这些活依然是工程纪律的一部分。把 1M 当成免费容量，第一个月的心跳报表就会教你做人。
智能体编码，拼的是耐力不是爆发力
跑八小时的 Agent，最怕什么
怕状态丢失，怕工具调用序列错乱，怕预算中途失控。编码任务恰好是这三件事最容易被验证的场景：反馈密集、结果可执行、出错可回滚。写错一个函数，测试会告诉你；跑偏一整轮，git 会告诉你。Anthropic 把 Opus 5.5 的首发定位压在 agentic coding 上，逻辑不复杂——这是当下最容易被量化、也最容易产生付费意愿的方向。
知识工作被装进同一辆车
尽调、法务审阅、行业研究，这些任务有个共同点：输入极长、输出结构松散、验收标准模糊。长上下文在这里的收益甚至比写代码更大，因为信息本身就是任务的全部原料。风险同样明显，模型在长文档里的引用准确性没有硬保证，页码、条款号、数字对不上的情况必然出现。人工复核这一环，短期内删不掉。
评测方式也得换一套
单轮问答的评分卡，测不出一个智能体连续跑两百步的稳定性。要看的指标变成：任务收敛率、工具调用失败后的自恢复能力、单位任务成本。这些数字没有公开榜单，只能在自家业务里跑出来。模型选型这件事，正在从看分数变成看耐力测试。
升级之前，先算清这几笔账
默认参数是暗礁
版本说明里提到默认参数有变化，这句话的分量比看上去重。max_tokens、采样温度、思考预算这类默认值一旦不同，同一段 prompt 在新旧模型上会跑出不同结果。依赖固定输出格式的流水线最危险——JSON 解析失败、字段缺失，往往在线上才暴露。回归测试别挑着跑，全量重来一遍。
价格、API 行为，用影子流量验
迁移成本分三块：token 单价、缓存命中规则、行为差异带来的返工。前两块看文档就能算清，第三块只能实测。把同一批真实请求同时打到 Opus 5.5 和现有模型，比对延迟、成本、成功率、输出合格率，跑够一周再决定切多少流量。这一步没有捷径，也没必要省。
回滚通道要提前留好
新模型上线初期，性能波动是常态。把模型 ID 做成配置项，别硬编码在业务代码里；保留旧版本的调用路径，至少留到新版本稳定跑满两个迭代周期。真出问题时，一条配置切回去的团队和需要发版回滚的团队，损失差着一个数量级。
计分板换了，谁该现在动手
榜单分数正在贬值
基准测试还能做初筛，但它越来越难预测生产表现。决定体验的是那些没有排行榜的数字：连续跑两百步之后还能不能收敛，工具报错之后恢复得多快，一个任务摊下来多少钱。这些只能自己跑。选模型的逻辑，从“谁分高”转向“谁扛得住长跑”。
本地与离线路线，是另一条岔路
并不是所有智能体工作负载都需要前沿大模型。数据敏感、要求完全离线的场景里，本地模型加一套能跑智能体的运行时，反而是更现实的选择。前端能力的天花板在抬升，同时边缘侧的可用性也在抬升，中间那批“既要长上下文又要合规”的需求，最终会分裂成两条技术路线。
两类团队，两种节奏
产品已经建立在长链路智能体上、上下文长度是当前主要瓶颈的团队，值得立刻开影子流量验证 Opus 5.5——收益直接，路径清晰。只做单轮问答或短链路调用的，1M 上下文的边际价值有限，为了它去承担价格与默认行为变化带来的返工，投入产出比不划算。等一两个版本，看社区踩出来的坑，也不迟。
