长上下文军备竞赛打完了吗：Kimi 100 万、Flash 降价 70%，你的 Agent 该怎么配模型

【摘要】10 月底的这周，Kimi K3.1 Pro 把开源模型的上下文推到 100 万 token，MiniMax M3.1 Flash 把 Agent 任务成本压下约 70%。上下文长度和价格同时被刷新，但真正的问题变了：当你手上有 30 多个模型、还有不同档位可以调，"该用哪个"已经不再是一个能力问题，而是一个配置问题。这篇讲我实际怎么配，以及为什么"按任务分档"比"按分数选型"靠谱。

目录

一、这周的两个数字
二、上下文长度：从卖点变成基线
三、价格：降的是 Agent 任务这一档
四、真正的问题：模型多了，档位怎么分
五、我的配置长什么样
六、三条分配原则
七、边界：这套方法什么时候不适用

一、这周的两个数字

Kimi K3.1 Pro（10 月 26 日前后） —— K3 的后训练升级版，参数规模 3 万亿级，支持 100 万 token 上下文。官方称 Terminal-Bench 4.0 得分 65.7%，接近 Claude Opus 5.5 的 66.4%。另提供输出速度约 2～3 倍的 Highspeed 版。完整权重承诺 11 月 4 日前发布。

MiniMax M3.1 Flash（10 月 26 日） —— 重点升级 Agent、Coding 和 Computer Use。官方称线上推理速度较前代提升近 3 倍，日常输出可达 200+ token/s，DeepSWE v1.1 得分 73.7%。价格：API 输入 1 元 / 百万 Token、输出 4 元 / 百万 Token，Agent 任务综合成本较前代降低约 70%。

两个数字放一起看，方向很清楚：上下文继续往上堆，而 Agent 任务的单位成本在往下掉。

这条曲线对做 Agent 的人是好事。但它也把一个老问题推到了台前——

当"能不能装下"不再是瓶颈，"该用哪个模型"就从一个技术问题变成了一个配置问题。

二、上下文长度：从卖点变成基线

先把上下文这件事说清楚。

Kimi 的 100 万不是新东西。Claude Code 在 2.1.287 就把 Opus 4.7+ 在多个托管 gateway 上的默认上下文提到 1M token，Nanbeige4.3-33B 是 512K，OpenClaw 的 Claude Code spawn 那条链路也在跟进。

1M 上下文在 2026 年下半年已经从"某家的特色"变成了"基本配置"。

这带来的实际变化，比宣传里说的"能读更多文档"要微妙得多。

第一，长上下文的成本曲线不是线性的。 上下文 10 万和 100 万，计费差距是 10 倍，但注意力质量不是。塞进去 100 万 token 里只有 1 万相关，你的检索和排序压力反而更大。所以"能装下"从来不是"能用好"。

第二，长上下文改变了"该不该摘要"这个问题。 过去 Agent 到一定长度就压缩，压缩必然丢信息。现在能装下了，很多原本要压缩的会话可以不压缩——但这要求你自己管理上下文边界，而不是依赖自动压缩兜底。

第三，也是最实际的：长上下文的门槛不在模型，在你的接口层。 我自己踩过——接一个新模型，网关给的默认上下文长度是 128K，而模型实际支持 100 万。不显式覆写，任务照样能跑，但跑的是被截断的版本，而且不报错。

这件事值得单独强调：

上下文长度设小了，Agent 不会报错。它会安静地在一个更小的窗口里工作，直到某次任务失败时你才可能怀疑它。

我现在的配置里，有两个模型显式写了 context_length: 1000000 就是为了防这个。

三、价格：降的是 Agent 任务这一档

MiniMax 那 70% 的降幅，值得细看。

它不是全面降价，是针对 Agent 任务场景的降本。同期 DeepSeek、腾讯混元也都在密集升级 Agent 能力。

这个方向说明行业共识变了：国产大模型的竞争焦点，正从参数规模和榜单排名，转向智能体任务的实际交付。

榜单分数高，不代表能干活。真正决定 Agent 能不能用的，是这几项：

• 工具调用的准确率（调对了没有）
• 多轮工具调用的稳定性（调十次会不会跑偏）
• 长任务不跑题（三十轮之后还记得最初的目标吗）
• Computer Use 的操作精度

而这些，恰好都是降本空间最大的地方——因为它们靠的是后训练和工程优化，不是堆参数。

对使用者的影响是：你可以在 Agent 任务上放心用便宜档了。

以前我的习惯是"能便宜就不用贵的"，但准确率不够时只能硬上贵的。现在便宜档的能力上来了，分配策略就该变。

四、真正的问题：模型多了，档位怎么分

我这边的实际情况：

6 个 provider，34 个模型
  provider A   17 个   claude-opus-4-6-thinking / gpt-5.6-luna / gemini-3.8-flash ...
  provider B   13 个   deepseek-v4-pro / glm-5.3 / kimi-k3 / qwen3.8-max ...
  provider C    2 个   deepseek-v3.2 / bge-m3 (embedding)
  provider D    2 个   MiniMax-M2.7

34 个模型，如果一个个试过去，一天就过去了。但实际上我常用的就那么几个。

（provider 名字我打了码——不是矫情，是因为自建中转的名字本身就会暴露你的上游结构，这东西没必要写进公开文章。）

原因在于：我的配置里有一条全局档位 + 一张按模型覆写的表。

reasoning_effort: max          # 全局默认
reasoning_overrides:
  glm-5.1: high
  glm-5.3: high
  glm-5.3-flash: high          # flash 模型降档，因为它们不靠推理深度取胜

还有一个独立段：

auxiliary:
  compression: { model: ..., provider: ... }   # 上下文压缩用
  approval:    { model: ..., provider: ... }   # 审批判断用

这三层加起来，就是我的"档位系统"：全局默认、按模型覆写、辅助任务单独指定。

有意思的是，这个结构跟 Google 那个 accidental-data-loss-prevention skill 的思路是一致的——危险或关键的判断单独走一条路径，不跟主流程共用。

五、我的配置长什么样

先说结论：我按任务类型分档，不按模型强弱分档。

大致是这样：

"上下文压缩用便宜档"这一条，是我觉得最值的。

压缩的本质是"把长对话总结成短的"，它是个重写任务——不需要推理深度，需要的是便宜、快、格式稳定。用最高档跑压缩，是在为一件不需要脑力的活付最贵的钱。

同理，审批判断也不需要最高档。它要的是"稳"和"不乱来"，不是"聪明"。

六、三条分配原则

总结一下我实际在用的三条：

原则一：按"错一次的代价"分档，不是按"任务的难度"分档。

这是最关键的一条。

改一个文档格式，错了改回来就行，用便宜档。改一批共享配置，错了整条链路断掉——那个任务我用最高档，哪怕它"看起来只是改配置"。

按难度分档会出错，因为难度不等于风险。一个看起来简单的配置改动，影响面可能极大。

原则二：把"重写型"和"判断型"任务降档。

不依赖推理深度的活儿——压缩、摘要、分类、格式化、翻译——用便宜档不会有质量损失。反而用贵档可能带来副作用：模型倾向于"改进"你的内容，把原意改掉。

原则三：显式声明上下文长度，不要信默认值。

这条是踩过坑才说的。网关的默认上下文长度和模型的实际能力是两回事。 接新模型第一件事就是查清楚它支持多少，然后显式写死。

不写死不会报错，只会安静地降级。

一个可以传播的观点句：模型选型的单位不是"模型"，是"模型 × 档位 × 任务类型"这个组合。同一个模型配不同档位，是两种完全不同的能力。榜单上只有一个数字，工作流里有一整张表。

七、边界：这套方法什么时候不适用

有几个场景，这套"按任务分档"的思路不成立，或者说会误导：

第一，一次性任务没有分档的必要。 如果你一天只用模型写一封邮件，选哪个都行，先把模型接通比优化档位重要得多。

第二，能力差距大到降档不可接受时，别降。 便宜档如果准确率掉到不能接受，降下来只是把成本问题换成质量问题。先测，再降。 我自己的做法是拿一批真实任务对比高低档的输出，差得多就保持高档。

第三，团队协作场景里，过度自定义会变成维护负担。 个人按任务分档很爽，但 34 个模型 × 3 个档位的组合要跟团队共享，光"这个任务该用哪档"就能吵半天。团队里更适合收敛到少数几个固定组合，而不是追求最优。

第四，也是最重要的一条：这套方法解决的是成本，不是可靠性。 如果任务失败一次的代价是不可逆的（比如涉及生产数据、涉及对外发布），那么无论哪个档位都不够——你需要的是人在环内的确认流程，不是更聪明的模型。

顺便说一下我为什么愿意在 Agent 任务上多花时间配这些：这周 MiniMax 降价 70% 之后，"用哪个模型"的成本压力小了很多，但"怎么分配"的思考没变。 便宜的模型让"每个任务都配一个够用的档位"变得可行，这本身就是一种能力升级。

你的模型配置里，有没有按任务类型分过档？ 还是一直一个档位走天下？我自己是踩过"上下文被静默截断"的坑才开始认真配的，评论区想听听你们踩过什么。