【AI Agent 实战】养虾系列 · DeepSeek V4 深度拆解
字数：约 4200 字 · 阅读时长：10 分钟
作者：路易乔布斯 · 一深思 AI · 2026-05-06
一、晚上 11 点的小龙虾
上周三晚上 11 点，我的小龙虾跑到第 27 轮的时候，CodeBuddy 弹了一句："上下文已超出限制，请使用 /compact 压缩。"
这是它本周第 11 次失忆。
我盯着屏幕苦笑------这次它正在重构一个跨 8 个文件的服务，刚把前 6 个文件读完、依赖图理清楚、改造方案定好，准备动手。一个 /compact 下去，方案丢了大半，回来之后它一脸懵地问我："您之前说要先改哪一层来着？"
这不是我的 Agent 不聪明。是它的"工作记忆"撑不住一个真实任务。
第二天，DeepSeek V4 发布。1.6T 参数、49B 激活、1M 上下文。所有技术号都在讲它的架构创新有多牛------mHC、CSA、HCA、Muon、TileLang，名词一个比一个吓人。
但我盯着发布页只想到一句话：
这次终于不用让我的虾每三轮就失忆一次了。
1M 上下文，对不养 Agent 的人来说，是个无聊的军备竞赛数字；对养 Agent 的人来说，是从"勉强能用"到"真正能干活"的临界点。
这篇就讲讲------为什么这个数字对我们如此重要，以及 V4 是怎么把这件事做到可执行的。
二、之前：养 Agent 的人，每天都在跟 128k 打架
我先不讲架构，先讲三个场景。每一个都是养虾人天天遇到的真实痛点。
场景 1：30 轮 Coding Agent 任务
你让 Agent 重构一个中等复杂度的服务。它会怎么消耗 token？
| 单轮消耗 | Token 量 |
|---|---|
| 用户指令 | 几百 |
| 读 3-4 个源文件 | 1.2-1.5 万 |
| Shell 命令 + 输出 | 几千 |
| 模型自己的 reasoning trace | 几千 |
| 单轮合计 | 约 1.5 万 |
128k 时代：8 轮就到上限。每 8 轮 /compact 一次，每次丢一波细节，Agent 要么忘了之前为什么改这一行，要么忘了用户最初想要什么。
1M 时代：60+ 轮一气呵成。它记得每一个文件、每一处改动、每一次它自己 reasoning 的来龙去脉。
这中间的差距不是"快了几倍"，是"任务能不能完成"。
场景 2：整仓库代码理解
中型 Python 项目，300 个文件、15 万行代码，整体压进上下文大约 80-120 万 token。
之前怎么做？ RAG。向量化所有文件，按相关性挑出几个塞给 Agent。
问题在哪？ 漏一个调用点就是一个 bug。你让 Agent 改一个公用函数的签名，RAG 给它看了 5 个调用点，但项目里实际有 8 个，剩下的 3 个上线之后炸了。
1M 时代怎么做？ 一口气全塞。Agent 自己看见所有调用关系。V4 在 SWE Verified 上拿到 80.6 分，靠的就是这个能力------它真的在"理解一个项目"，不是在"猜哪几个文件相关"。
场景 3：长文档推理
200 页的法律合同、四个附件的季度财报、一份完整的技术 RFC。
之前怎么做？ 切块、摘要、再合并。前后逻辑断在哪你都不知道，跨段落的矛盾抓不住。
1M 时代怎么做？ 整篇直接推理。MRCR（Multi-Round Conversation Recall）1M 评测里，大部分模型不到 50 分，V4-Pro 拿到 83.5------开源最高。
我把这三个场景拼起来想，就发现一件事------V3.2 在新用户消息进来时丢掉 thinking history，不是它不想留，是留不下。 这不是设计选择，是被迫妥协。
1M 上下文不是 prompt 写更长。它是让 Agent 真正"记得住一个完整任务"。这才是养虾人盼了一年的临界点。
三、然而：以前的 Transformer 为什么撑不到 1M
讲清楚 V4 之前，得先讲清楚------为什么 1M 这么难。
把三个学术瓶颈用养虾人能听懂的语言翻译一遍：
| 学术语言 | 养虾人能听懂的版本 | 比喻 |
|---|---|---|
| Prefill 计算量 O(L²) | 上下文翻 8 倍，算力要 64 倍 | 同事多 8 倍，开会时间多 64 倍 |
| KV Cache 占用 ∝ L | 每生成 1 个 token 都要把过去全翻一遍 | 你每说一句话之前要把过去 1 万次对话都过一遍脑子 |
| 残差通道单一 | 模型加深加宽到一定程度就训不动 | 100 层楼只有一部电梯，所有人挤一起 |
第一个瓶颈让训练成本失控；第二个瓶颈让推理速度雪崩；第三个瓶颈让万亿参数百层网络根本收不住。
任何一个解决不了，1M 都是 PPT 里的数字。
V4 的真本事，是同时解决了这三个。而且解的方式，每一个拆开看都不算颠覆性创新，但组合在一起就是工程级的优雅。
四、V4 的三招组合拳
招式 1：mHC------给 100 层大楼装"多电梯+调度系统"
这是解决第三个瓶颈（深度上限）的核心。
| 残差方式 | 对应建筑 | 问题 |
|---|---|---|
| 标准残差 | 1 部电梯所有人挤 | 浅层信息和深层信息互相踩踏 |
| HC（Hyper-Connections） | 多部电梯但调度无规则 | 数值容易发散，训练不稳定 |
| mHC | 多部电梯 + 调度装运营规范 | 既不撞车也不空载 |
mHC 比 HC 多了一个关键约束------把残差映射矩阵限制在"双随机矩阵"集合里（每行加起来=1、每列加起来=1、非负）。
听起来抽象？换个说法------它强制保证每一层的历史信息贡献系数永远在 0 到 1 之间。这样模型再深、再宽，都不会出现"某一层突然权重爆炸"或者"某一层信号消失"的情况。
更精妙的是它的非对称设计：
- 对连乘的高风险矩阵施加强约束（双随机矩阵）
- 对只参与单层的低风险矩阵保持灵活（sigmoid）
这是工程师的克制------不是越多约束越好，而是该严的地方严，该松的地方松。
养虾人能用上的启示：
Agent 的长期记忆系统也面临同样问题------多种记忆类型（事实记忆、剧情记忆、技能记忆）挤在一条上下文通路里互相踩踏。
mHC 给的解法是：给不同类型的记忆开不同通道，但调度本身要有约束。
这正是 Hermes Agent 的 ContextEngine、Claude Design 的 Memory 分层设计在做的事------只是在 V4 里，这套思想从架构层第一次跑通。
招式 2：CSA + HCA------三层"会议纪要"机制
这是解决第一、第二个瓶颈（计算量和 KV）的核心。
V4 用的不是"线性注意力"那条路（Kimi、Qwen 走的是这条），而是保留 Softmax 精度、靠"压缩+稀疏"降量。
具体怎么做？三层处理：
| 步骤 | 角色 | 在做什么 |
|---|---|---|
| 1. HCA | 速记员 | 每场大会一份速览纪要 → 海选 |
| 2. CSA | 记录员 | 相邻两场小会合并打分纪要 → 精选 |
| 3. 稀疏注意力 | 精读员 | 找最相关的几份逐字精读 |
把 1M 上下文里 6.5 万倍的计算量膨胀压回可执行范围，靠的就是这套"先粗筛、再精筛、再精读"的层级机制。
养虾人能用上的启示：
这不就是我们做 RAG 时的 hierarchical retrieval 吗？
但 V4 把这套机制做进了模型架构本身，而不是外挂在 RAG 层。
这意味着什么？未来 Agent 的检索能力，可能不在 RAG 框架里，而是直接长在模型里。 我们这层做的检索，会越来越像"调度",越来越少做"匹配"。
招式 3：Muon 优化器------让训练更稳定的两个细节
前两招是"能跑起来"，这一招是"能稳定跑下去"。
梯度正交化：让各个方向的更新独立进行，不互相拧魔方。比喻就是------左手画圆右手画方，两只手解耦，就不会互相拽着对方乱动。
Q/K 在 attention 前做 RMSNorm：根除注意力 Logits 爆炸。比喻就是------10 人会议每人定制一只麦克风增益，不让大嗓门的人盖过小声音的人。
这两件事单独看都不大，但放在万亿参数百层模型里，是"训得动"和"训不动"的差别。
养虾人能用上的启示：
不直接用上，但思维可借鉴------所有"加权聚合"场景都要小心权重失衡。
Multi-Agent 投票、Memory 检索打分、Tool 选择评分------任何聚合环节都要问一句：会不会有"大嗓门"？
五、Infra 层："看不见的功夫"才是真本事
讲到这里，故事只讲了一半。架构创新解决"理论上能跑"，但真正能让 V4 在用户手里"快、省、稳"的，是 Infra 层那些看不见的功夫。
四个 Infra 优化，用养虾人能感受到的语言讲：
| Infra 优化 | 你作为用户的体感 | 比喻 |
|---|---|---|
| 细粒度计算通信重叠 | 单卡能跑更长上下文了 | 洗衣机和烘干机同时跑，不再等空转 |
| TileLang | 跨硬件部署变容易 | 同一份菜谱川菜厨师和粤菜厨师都能做 |
| 批无关性 + 计算确定性 | 同样的 prompt 多次跑结果一致 | 每杯奶茶都是 50% 糖，不能因为忙就走捷径 |
| FP4 量化感知训练 | 推理速度更快、显存更省 | 搬家时被子能抽真空压缩，衣服只能叠 |
这里我特别想拎出来讲两个。
TileLang------它把"算法逻辑"和"硬件调度"解耦了。开发者写算法时不用管 GPU 是 H100 还是国产芯片，编译器自己生成对应硬件的最优 kernel。性能对齐甚至超过手写的 CUTLASS/cuBLAS。
这意味着什么？V4 不是只能跑在 NVIDIA 上的模型。 它从架构设计的第一天，就是为"多厂商硬件"准备的。这是中国大模型公司面对芯片限制时，最 elegant 的回答。
批无关性------这个特性最容易被忽略，但对养虾人来说是个奇迹。
之前用 LLM API 的人都遇到过------同样的 prompt，跑两次结果不一样。原因是 LLM 推理服务为了吞吐，会把不同用户的请求批在一起，不同的 batch 切分会导致 bit 级输出不一致。
V4 强行解决了这个问题------Attention kernel 顺序对齐 + DeepGEMM 替换 cuBLAS + 反向传播三大累加场景固定累加顺序。结果就是------同样的 prompt 跑 100 次，输出 100% 一致。
对养虾人来说这是什么？这是Agent 行为可重现性的基石。你测试通过的 prompt，明天还能跑出同样的结果；你给客户演示的 demo，下次演示不会突然失败。
六、V4 没发明新轮子，它教会我们怎么"组合"
这是这篇文章我最想讲的部分，也是 V4 给养虾人的真正启示。
mHC、CSA、HCA、Muon、TileLang、QAT------每一块拆开看原理，都似曾相识。
- mHC 的多流残差思想，Kimi 的 Attn-Res 也在做
- 稀疏注意力，Longformer / BigBird 几年前就有
- 梯度正交化，Shampoo 优化器早就提过
- 量化感知训练，BERT 时代就在用
- 算子编译解耦，TVM、Triton 都是先行者
那 V4 凭什么牛？
凭它把这些"似曾相识"的东西逐一重新雕琢一次 ------mHC 加了双随机矩阵约束、CSA 加了三层处理、Muon 加了 RMSNorm、TileLang 性能对齐手写 kernel。然后组织在一起，完成从架构到工程的一次系统级闭环。
DeepSeek 官方技术博客结尾引了八个字------"率道而行，端然正己"。
我盯着这八个字想了很久。它不是诗，是工程师的座右铭：
- 不诱于誉------不为追逐 SOTA 而堆参数
- 不恐于诽------不为规避复杂度而走捷径
- 率道而行------从问题本质出发选解法
- 端然正己------严格自约束（mHC 双随机矩阵、批无关性、分模块量化，每一个都是"自约束"）
这其实是工程版的第一性原理。
而我们这些养 Agent 的人，做的不也是同一件事吗？
七、给养虾人的三个具体行动
讲这么多 V4 的牛，最后落到------你今天能做什么？
行动 1：重新审视你 Agent 的"工作记忆"
打开你正在用的 Agent，问自己三个问题：
- 它现在用的是哪一档上下文？128k？200k？还是已经能上 1M？
- 它的任务是不是经常被 /compact 切断？
- 如果切换到 1M 模型，能否重新设计任务粒度------把现在拆成 3 个子任务的事，合并成 1 个完整任务做？
很多养虾人现在的"任务拆分"，本质上是在适应小上下文的妥协。等你换上 1M 模型，发现根本不用拆，体验会有质变。
行动 2：从"挑 SOTA 模型"转向"挑组合最优的模型"
V4 强在系统级闭环，不在单点 SOTA。
你的 Agent 系统也是一样------单点 Skill 升级换不来体验飞跃，组合优化才会。
下一次你想给 Agent 升级，先别问"哪个模型更强"。先问------
- 我的 Memory 系统跟模型的上下文规模匹配吗？
- 我的 Tool 调用方式跟模型的并发能力匹配吗？
- 我的 Skill 拆分粒度跟模型的推理深度匹配吗？
这三个问题答完，你会发现------升级模型只是 1/4 的事，剩下 3/4 是匹配整个系统。
行动 3：沉淀你自己的"系统级闭环"
不要每次都从零拼。
把验证过的"Skill + Memory + Tool + Context 组合"沉淀为可复用模板。这不是为了偷懒，是为了------每一次新需求来的时候，你能站在上一次的肩膀上。
这正是 OpenClaw Skills 体系在解决的事。也是养虾系列从开篇到现在一直在讲的主线------
做 Agent 不是发明新算法，是把现成的 Skill / Memory / Tool / Context 像积木一样组合起来。组合本身，就是核心能力。
V4 在大模型层面证明了这条路。我们在 Agent 层面，要做的事是一样的。
八、回到那个晚上 11 点
V4 发布之后，我用 1M 上下文重跑了那个跨 8 文件的重构任务。
从开始到提交 PR，44 轮。全程未触发 /compact。它记得每一个文件、每一处改动、每一次它自己的 reasoning。
我突然理解了那八个字------
不诱于誉，不恐于诽，率道而行，端然正己。
这不是诗，是工程师的座右铭。我们这些养 Agent 的人，做的也是同一件事------
不为追逐风口而堆模型，不为规避麻烦而走捷径，从用户真实任务出发选方案，对每一处实现严格自约束。
1M 上下文不是终点。它只是让我们的小龙虾，终于有了一个能装下完整任务的"工作记忆"。
接下来，看我们怎么用好它。
写在最后
如果你也在养 Agent，欢迎留言告诉我------
- 你目前的 Agent 跑到第几轮才会被 /compact？
- 你最希望 1M 上下文能让你做什么之前做不到的事？
下一篇，我会拆解一个具体案例------用 1M 上下文重新设计 Agent 任务粒度，从"任务拆分思维"切换到"长任务一气呵成思维" 的全过程。
养虾路上，慢慢见真章。
路易乔布斯 · 一深思 AI · 2026-05-06
本文首发于「一深思 AI」，转载请注明出处