最近看 DeepSeek-V4 技术报告，我最强烈的感觉是：很多人可能看错重点了。

大多数人会盯着几个显眼的指标：1M token 上下文、MoE 架构、Codeforces 分数、SWE 表现、推理成本下降多少、KV cache 压缩多少。

这些当然重要。

但如果只看这些，其实只看到了表层。

DeepSeek-V4 真正值得技术人警惕的地方，不是它某个榜单又高了，而是它透露出一个很明显的趋势：

大模型的竞争，正在从“谁的模型更强”，变成“谁能持续生产高质量智能轨迹”。

这句话听起来有点抽象，我换一种说法。

以前训练大模型，更像是在做一个巨大的知识压缩器：给它海量文本，让它学会语言、知识、推理、代码。

后来进入后训练阶段，大家开始做 SFT、RLHF、RLVR，让模型更会回答问题，更符合人类偏好，更擅长数学和代码。

但到了 Agent 阶段，事情变了。

一个真正有用的 Agent，不是能说几句漂亮话，也不是会输出一个 function call 格式，而是要能在真实任务里连续做事。

它要能读文件、查资料、调用工具、执行命令、看报错、改方案、跑测试、继续修复，最后把任务完成。

这时候，模型能力就不再只是“参数里的能力”，而是变成了一套完整系统能力。

模型只是其中一部分。

沙箱、工具、轨迹日志、自动打分、可复现环境、可恢复 rollout、专家模型、蒸馏系统，全部都成了模型能力的一部分。

这才是 DeepSeek-V4 最值得看的地方。

长上下文不是把窗口拉大，而是重新设计记忆系统

很多人一看到 1M token，就会理解成“上下文窗口更大了”。

这个理解没错，但太浅。

真正的问题不是模型能不能“声明支持 1M”，而是 1M 上下文在实际服务里到底能不能用。

因为上下文越长，KV cache 越大；每生成一个 token，要回看的历史也越长。标准 attention 在这种长度下，计算成本和显存占用都会变得非常夸张。

所以长上下文的核心，根本不是“能塞多少文本”，而是“怎么在超长历史里面低成本找到有用信息”。

DeepSeek-V4 里比较关键的是 CSA 和 HCA。

不用被名字吓住，可以这样理解。

CSA 负责“压缩后精看”。

它先把多个 token 的 KV 压成更少的条目，然后再从压缩后的历史里挑出 top-k 重要内容做 attention。也就是说，它不是把所有历史都完整看一遍，而是先把历史压缩，再挑重点。

HCA 负责“重压缩后粗看”。

它压缩得更狠，把很长的历史变成更少的全局记忆点，再用较低成本做全局 attention。

再加上 SWA 滑窗注意力保留最近局部细节，整个结构就很像人读长文档：

最近发生的事，要精确记住；
关键段落，要能回看；
整篇文章的脉络，要有压缩后的全局印象。

这和普通 RAG 的思路其实也有相通之处。

做企业知识库的时候，最差的做法就是把一堆文档硬塞进上下文，然后期待模型自己找重点。真正可用的方案，一定要分层：

高频状态放短上下文。
长期知识放知识库。
历史对话做摘要。
关键业务字段结构化。
重复使用的前缀尽量缓存。
大段文档不要原样堆进去，而要能检索、压缩、重组。

所以 DeepSeek-V4 的长上下文给我的启发不是“以后 prompt 可以无限长”，而是：

真正的长上下文能力，本质上是记忆管理能力。

谁能把短期记忆、长期记忆、压缩记忆、局部记忆、可复用缓存管理好，谁才能真正把长上下文用起来。

Agent 的关键不是会调用工具，而是能生成高质量轨迹

现在很多人做 Agent，第一反应是做工具调用。

给模型挂几个 tool，写好 JSON schema，再告诉模型什么时候调用哪个函数。

这当然是 Agent 的基础，但远远不够。

因为会调用工具，不等于会完成任务。

一个代码 Agent，真正难的不是输出“我要调用 read_file 工具”，而是它能不能自己判断：

哪个文件最可能有问题；
这个报错是依赖问题还是逻辑问题；
改哪一行风险最小；
测试失败以后下一步怎么排查；
什么时候应该继续尝试，什么时候应该停下来总结。

这些能力不是靠背 function call 格式学出来的，而是靠真实任务轨迹练出来的。

这里的关键词是 trajectory，也就是轨迹。

一个高质量的 Agent 训练样本，不应该只有“用户问题”和“最终答案”。它更应该包含整个过程：

用户给了什么任务；
模型查了哪些文件；
调用了什么工具；
工具返回了什么结果；
模型如何理解结果；
执行命令是否失败；
失败后怎么修复；
最后是否通过验证。

这才是 Agent 真正的训练材料。

DeepSeek-V4 把大量篇幅放在沙箱、trajectory log、deterministic replay、preemptible rollout 上，其实就是在解决这个问题。

没有沙箱，Agent 只能在文本里假装执行。

没有轨迹日志，模型失败以后没人知道它到底错在哪一步。

没有可复现回放，今天失败的任务，明天可能复现不出来。

没有可恢复 rollout，长任务一旦中断，前面生成的过程就可能浪费掉。

所以我现在越来越觉得，Agent 不是 prompt 工程问题，而是训练基础设施问题。

如果一个团队没有能力大规模制造真实任务、真实执行、真实反馈、真实评分的数据闭环，那么它做出来的 Agent 很可能只是一个会调用工具的聊天机器人。

真正能持续进化的 Agent，一定背后有一套“轨迹工厂”。

这个轨迹工厂能不断产生任务，执行任务，记录过程，评估结果，再把这些数据反哺给模型。

这才是 Agent 能力的核心资产。

Specialist + OPD：先训练专家，再融合专家

DeepSeek-V4 后训练里，我觉得最值得学习的是 Specialist + OPD 这个思路。

过去很多模型做后训练，喜欢把各种任务混在一起训。

数学、代码、写作、工具调用、指令遵循、Agent 任务，全放进一个大池子里做 RL。

看起来很统一，但问题也很明显。

不同任务的 reward 逻辑根本不是一回事。

数学题可以用标准答案验证。
代码题可以跑 test case。
工具调用可以看执行结果。
写作任务要看风格、结构、事实、表达。
办公任务还要看格式、约束、业务完整度。

把这些东西强行混在一起 RL，很容易互相干扰。

数学 reward 可能把模型推向长推理。
代码 reward 可能强化试错执行。
写作 reward 可能强调表达质量。
指令遵循又要求模型别擅自发挥。

这些目标不是天然一致的。

所以 Specialist 的思路更像是：先分科。

数学专家就专门练数学。
代码专家就专门练代码。
Agent 专家就放到可执行环境里练多步任务。
指令遵循专家就专门练复杂约束响应。

每个专家在自己的领域里先练强，然后再考虑融合。

这比一开始就训练一个“大杂烩模型”更合理。

那怎么融合？

这里就轮到 OPD。

OPD，全称是 On-Policy Distillation，中文可以叫在线策略蒸馏或者在策略蒸馏。

它最关键的地方不是“蒸馏”，而是 on-policy。

普通蒸馏更像老师把标准答案写好，学生去模仿。

但 OPD 不是这样。

OPD 是学生先按自己的当前能力生成一条轨迹，然后老师在学生自己的轨迹上进行纠偏。

这个差别非常大。

因为模型上线以后，真实输出一定来自它自己的分布。训练时如果只让它模仿标准答案，它学到的是“别人走过的路”。但 OPD 让学生在自己真实会走的路上被老师纠正，这就更接近真实使用场景。

放到多专家融合里，它的意义更明显。

数学任务来了，学生自己的轨迹会更靠近数学场景，数学老师就能给出更有价值的分布反馈。

代码任务来了，代码专家就更重要。

Agent 任务来了，Agent 专家的轨迹经验就发挥作用。

这不是简单把多个专家答案平均，而是在学生自己的生成路径上，让不同专家提供分布级纠偏。

这件事比 mixed RL 更精细。

因为它不是把所有能力混在一个 reward 里搅拌，而是先让每个专家把自己的能力练出来，再通过蒸馏把能力灌回统一模型。

这对企业 AI 项目也很有启发。

不要一上来就做一个万能智能体。

更好的路线是：

先做需求采集专家。
再做报价专家。
再做工艺规则专家。
再做技术文档专家。
再做数据查询专家。
每个专家有自己的任务、数据、评价标准。
最后再用统一入口把这些能力融合起来。

这才是更稳的架构。

GRM 的价值：模型不仅要会生成，还要会判断

DeepSeek-V4 里还有一个值得关注的点：GRM，Generative Reward Model。

传统 reward model 很多时候是给一个分数。

比如这个回答 8 分，那个回答 5 分。

但现实中的复杂任务，不是一个分数就能说清楚的。

比如让模型写一份企业分析报告，什么叫好？

它要事实准确，结构清晰，逻辑完整，引用可靠，结论有价值，还要符合用户的具体约束。

比如让模型生成一份服装报价方案，什么叫好？

它要识别品类，理解尺码，匹配工艺，考虑面辅料，价格区间合理，还要知道哪些信息缺失，需要继续追问。

这种任务如果只给一个标量分数，信息太粗。

GRM 的思路是让模型根据 rubric 做生成式评价。

它不只是说“好”或者“不好”，而是要说清楚：

哪里好；
哪里缺；
为什么扣分；
下一步怎么改。

这其实是模型能力升级里非常关键的一步。

因为一个模型想真正变强，不能只会写答案，还要知道什么是好答案。

很多业务系统做不好，不是因为模型完全不会答，而是因为模型没有稳定的自检标准。

它不知道自己有没有漏字段，不知道引用是否可靠，不知道方案是否能交付，不知道输出是不是符合业务流程。

所以企业级 AI 系统一定要有“生成 + 评判”的闭环。

生成模型负责完成任务，评判模型负责检查质量。评判结果再变成训练数据和优化方向。

不过这里有一点要克制。

技术报告如果没有展开 GRM 的完整训练细节，比如人工标注规模、rubric 构造方式、防止自评偏移的机制，那就不要硬猜。

能学的是方向：让模型具备评判能力。

不能脑补的是未披露的训练配方。

这个边界要分清。

Infra 已经不是配套设施，而是模型能力的一部分

我觉得 DeepSeek-V4 最强烈的信号是：Infra 已经不再是算法后面的部署工作，而是算法本身的一部分。

以前我们喜欢把事情分开。

算法团队负责模型。
工程团队负责部署。
平台团队负责稳定性。

但 Agent 时代，这个边界会越来越模糊。

因为很多算法能力，如果没有对应的基础设施，根本做不出来。

没有沙箱，就没有真实执行轨迹。
没有轨迹日志，就没有训练样本复盘。
没有确定性回放，就没有稳定 debug。
没有 WAL，就很难处理中断后的长任务恢复。
没有高效 KV cache 管理，1M context 就只是纸面能力。
没有高效 teacher logits 计算，full-vocab OPD 就很难规模化。

这些看起来像工程细节，其实都会直接影响模型能力。

举个例子，长任务 rollout 如果经常中断，而系统只能保留短任务，最后训练数据就会天然偏向短回答。

这不是简单的系统故障，这是数据分布被基础设施污染了。

再比如 Agent 任务里，如果命令执行不可复现，模型每次训练看到的反馈都不稳定，那么强化学习就很难收敛到可靠行为。

所以基础设施不是“让模型跑得更快”这么简单。

它是在决定模型能不能获得高质量训练信号。

这也是为什么我认为下一阶段的大模型竞争，不只是模型架构竞争，而是 AI Infra 竞争。

谁有更强的执行环境，谁就能产生更真实的 Agent 数据。

谁有更好的轨迹记录，谁就能更快定位失败模式。

谁有更好的自动评分系统，谁就能更快完成模型迭代。

谁有更稳定的蒸馏和后训练管线，谁就能把多个专家能力融合成统一能力。

对企业 AI 项目的直接启发

如果把 DeepSeek-V4 的思路迁移到企业 AI 项目，我觉得最重要的不是照搬它的模型结构，而是学习它的系统思想。

第一，不要迷信单个大模型。

企业里真正稳定的 AI 系统，往往不是一个模型单打独斗，而是一组专家能力的组合。

需求采集、文档检索、报价、数据分析、流程判断、代码生成，这些任务的评价标准不同，失败模式也不同。硬塞进一个 Agent，很容易变成大而不稳。

第二，先建设轨迹数据。

很多企业做 AI，只保存最终回答，这是很大的浪费。

真正有价值的是过程。

用户怎么问，模型怎么拆，查了什么资料，调用了什么工具，输出了什么结果，人工最后怎么改，这些才是未来训练和优化的燃料。

第三，每个智能体都要有自己的评分标准。

没有评分标准，就没有可持续优化。

文档智能体要看引用准确率。
报价智能体要看价格逻辑和字段完整度。
需求采集智能体要看信息覆盖率。
代码智能体要看测试通过率。
流程智能体要看规则命中和异常处理。

不能所有任务都用一个“回答满意度”糊弄过去。

第四，要把失败案例沉淀下来。

Agent 失败并不可怕，最怕的是失败以后什么都没留下。

一次失败，如果有完整轨迹，就能变成训练样本。

如果没有轨迹，那只是一次无效报错。

第五，统一智能体应该是后期结果，不是一开始的目标。

先把专家做好，再做统一入口。

先把每个任务闭环跑通，再做多智能体编排。

先有可评估的专业能力，再谈融合和自动化。

这条路慢一点，但更稳。

真正的结论

DeepSeek-V4 这类技术报告，表面看是在讲模型，深层看是在讲下一代 AI 系统怎么建设。

我读下来最大的感受是：

模型能力已经不再只存在于参数里。

它存在于长上下文架构里，存在于 KV cache 管理里，存在于沙箱执行环境里，存在于 trajectory log 里，存在于自动评分系统里，存在于 specialist 训练里，也存在于 OPD 这种能力融合机制里。

未来真正强的 Agent，不会只是一个会聊天的大模型，而会是一套能持续执行任务、记录轨迹、判断结果、复盘失败、再训练自己的系统。

所以 DeepSeek-V4 真正可怕的地方，不是它支持了 1M 上下文，也不是它某个 benchmark 高了多少。

真正可怕的是，它把 Agent 训练从“写 prompt 和调模型”，推进到了“建设智能生产基础设施”。

这才是技术人最应该学习的地方。

因为下一代 AI 系统的核心竞争力，可能不再是谁手里有一个更会说话的模型，而是谁能持续生产高质量、可执行、可评分、可复现的智能轨迹。