8月12日深夜到13日凌晨，两件事几乎同时发生：DeepSeek官方API文档悄悄把deepseek-v4-pro指向了新版本DeepSeek-V4-Pro-0813，结束了这个旗舰模型从4月24日开始的预览期；几乎同一时间，xAI也放出了Grok 4.6。媒体给这个巧合起了个挺戏剧化的名字，但抛开话题性，这次同时发布真正值得聊的，是两家给出了两条完全不同的技术路径。
DeepSeek这边：架构一个字没动，分数却大幅跳涨
先说清楚一个容易被忽略的细节：V4-Pro-0813和4月的预览版，用的是同一套架构、同一个参数规模——1.6万亿总参数的MoE模型，每次推理激活约490亿参数。官方也没有暗示底层架构有调整。也就是说，这轮提升完全来自后训练阶段的重做。
跳变的幅度不小。DeepSWE这个内部Agent基准从12.8涨到62.7；Cybergym从52.7涨到83.3；Terminal Bench从72.1涨到87.9。这几项测的都是同一类能力：长链路的代码修改、环境操作、连续工具调用——恰好是预览版最容易出问题的地方。
接口层面，V4-Pro-0813把上下文窗口做到了100万token，输出上限提到38.4万token，同时新增了Responses API和Anthropic API双协议兼容，这意味着Codex、Claude Code这类已经适配了对应协议的编程工具，可以直接切换过来用，不需要额外改造调用层。
跑分对比上，Terminal Bench 2.1这一项，V4-Pro-0813拿到87.9分，和Kimi K3的88.3分只差0.4分；HLE开启工具后的成绩是60.0；CyberGym上的83.3甚至高出Claude Opus 4.8的78.3。单看某一项不算稀奇，难的是同时在终端操作、代码工程、工具调用、安全攻防这几个维度都没有明显短板——这也是官方后训练重做想达到的效果：不是某一项刷高，而是整体拉平。
xAI这边：走的是另一条路——大规模Agent强化学习
Grok 4.6没有靠架构或后训练的针对性调整，而是在Grok 4.5基础上做了更长的补充训练，训练数据包括经过筛选的模型推理轨迹和工程数据，并配合改进后的优化器。真正的重点在后面：模型接受了覆盖知识工作、通用编程、内核优化、Web开发、计算机辅助设计等多个领域的Agent强化学习训练，目标很明确——让模型能独立扛住一个跨越几十步、持续几十分钟的完整任务，而不是把任务拆成一问一答。
上下文窗口方面，Grok 4.6做到了50万token。定价上，输入2美元/百万token、输出6美元/百万token，落在200K以内的请求区间，这个价格只有同级别前沿模型的一半左右。发布信息里还提到一个细节：Grok 4.6已经上线Cursor和Grok Build，首周这两个平台会给到双倍的使用额度——这是一个很明显的信号，xAI想让开发者尽快在真实编程场景里试出模型的实际表现，而不只是看跑分。
两条路径殊途同归的地方
如果只看训练方式，这是两种完全不同的打法：一个是架构冻结、押注后训练精调；一个是延长强化学习、押注跨领域Agent能力泛化。但落到结果上，两者其实在解决同一个问题——模型能不能独立完成一个"目标模糊、步骤很多、中途会遇到意外"的真实任务，而不是只在单轮问答里表现好看。
价格趋势也在往同一个方向收敛。DeepSeek维持了输入3元、输出6元每百万token的定价，同时预告近期会调整；Grok 4.6把价格压到了同类前沿模型的一半。前沿智能这个级别的模型，正在被两条不同的技术路径同时推向"更便宜"这一端，这对做成本敏感型Agent系统的团队是个实打实的利好，但也意味着单纯靠"用得起更贵的模型"建立的竞争壁垒，正在变薄。
对做Agent系统的开发者，这次发布真正该关注的信息是什么
两家都没有公布模型内部机制的全部细节，跑分对比也各有各的口径，直接照抄榜单意义不大。更实际的做法，是把评估这件事拆成和自己业务场景匹配的几个维度去看，而不是只认一个综合分：
from dataclasses import dataclass
@dataclass
class ModelCandidate:
name: str
terminal_bench: float # 终端环境复杂任务执行能力
input_price: float # 每百万token输入价格
output_price: float # 每百万token输出价格
def score_for_scenario(model: ModelCandidate, weight_agent: float, weight_cost: float) -> float:
agent_score = model.terminal_bench weight_agent
cost_score = (1 / (model.input_price + model.output_price)) weight_cost
return agent_score + cost_score
def rank_by_scenario(candidates: list, weight_agent: float, weight_cost: float) -> list:
scored = [(c.name, score_for_scenario(c, weight_agent, weight_cost)) for c in candidates]
return sorted(scored, key=lambda item: item[1], reverse=True)
这段代码本身很简单，重点不在实现，而在思路：终端Agent能力和成本敏感度的权重,应该按自己系统的实际任务类型来设，而不是套用某个通用榜单的排序。一个需要长时间自主跑完整流程的系统,和一个只做单轮工具调用的系统,该看的评测维度完全不一样。
写在最后
架构冻结靠后训练拉分，和延长强化学习靠泛化拉分，是两种不同的工程判断，谁更划算取决于团队当下卡在哪个环节。但两家同一晚交卷，且都把价格往下压，说明这个判断题正在变成整个行业共同要回答的问题：下一阶段的竞争，会更多发生在训练方法论和成本控制上，而不是参数规模的堆叠上。
