长上下文与 Agent 能力专项评测
百万 token 不是"能装多少字"，而是"能做多复杂的事" | 预计阅读时间：25 分钟
一、引言
上一篇文章从 Benchmark 的全景视角拆解了 V4 的各项评测数据。但有两个维度在标准 Benchmark 中要么被低估，要么根本无法反映——长上下文和 Agent 能力。
这不是巧合。V4 的整个产品定位里，这两个就是核心卖点。DeepSeek 官方每次介绍 V4 时，前三句话里一定包含"100 万 token 上下文"和"Agent 能力大幅提升"。如果你只看传统 Benchmark，可能会觉得"不过是在代码评测上又强了一点"，但长上下文和 Agent 才是 V4 真正拉开代差的两个方向。
为什么这么说？
先看长上下文。2025 年底之前，主流模型的上文窗口停留在 128K-200K（约 10-15 万汉字）。要做点正经事——分析一整本书、审阅整个代码仓库、处理完整的技术文档——必须分块、切片、用 RAG 补。每次切块都意味着上下文断裂，每次 RAG 都意味着精度损失。V4 把这扇门直接踹开了：1M token 上下文（约 80 万汉字），无需分块，整本《三体》三部曲直接塞进去。
再看 Agent 能力。2025-2026 年的 AI 行业有个共识：模型本身的智能程度已经够用了，卡住实际落地的瓶颈是"模型能不能在真实环境里持续、稳定地完成任务"。这需要的不只是"答题能力"——需要模型理解工具调用、处理多步推理、在出错时自动恢复、在信息不足时主动澄清。V4 在 Agent 上的提升不是"比上一代好一点"，而是从"勉强能用"跨越到了"内部员工当主力用"的程度。
本文从这两个维度展开，用数据、实测和案例分析 V4 的实际表现。如果你正在考虑用 V4 做 AI 编程助手、搭建 Agent 工作流、或者处理超长文档场景，这篇文章应该能帮你做出更准确的判断。
二、1M token 检索测试
2.1 Needle in Haystack：考的是"能不能找到"
长上下文的第一个基础测试是"大海捞针"（Needle in Haystack，简称 NiH）。测试方法很简单：在一篇超长文档的不同位置藏入一句特定的事实陈述，然后问模型"文档里关于 X 的说法是什么"。如果模型能在百万 token 中准确找到这根"针"，说明它没有"忘记"远处的信息。
这是长上下文评测的起点——如果"捞针"都做不到，更复杂的任务就不用谈了。
NiH 测试的难点不在于问题有多难，而在于记忆衰减。当模型读完 100 万 token 的内容后，开头的几千 token 已经在推理队列里排了太长时间，注意力权重已经稀释到了极致。传统的 Transformer 注意力计算中，每个 token 都要和所有前面的 token 做注意力计算——序列越长，远处 token 的信号越弱。
V4 在 NiH 上的表现如下：
| 模型配置 | 1M token 检索精度 | 说明 |
|---|---|---|
| V4-Flash (标准模式) | 62.0% | 无思考模式，直接回答 |
| V4-Pro (标准模式) | 53.8% | 无思考模式，直接回答 |
| V4-Pro (思考模式) | 71.7% | 开启 reasoning_effort=max |
看到这个数据，正常反应是愣了一下：Flash 的标准模式居然比 Pro 的标准模式高？
这其实不奇怪。NiH 测试是一个"找信息"的任务，对推理深度的要求极低，但对"记忆密度"的要求很高。Flash 的 13B 激活参数意味着它的注意力计算更集中、信息保留更紧凑。Pro 的 49B 激活参数处理的信息维度更丰富，但在"纯记忆"任务上反而可能因为注意力分布更分散而略微下降。
关键转折点在 Pro 开启思考模式之后。71.7% 的成绩说明：当 Pro 进入"多步验证"模式后，它能够通过内部推理重新定位丢失的信息。思考模式在这里起的作用不是"想得更深"，而是"找得更仔细"——模型会在内部多次扫描关键信息，弥补标准模式下的注意力衰减。
2.2 与竞品的对比
NiH 评测中，V4 的竞品表现如何？
| 模型 | 上下文窗口 | 1M token NiH 精度 | 说明 |
|---|---|---|---|
| GPT-5.5 | 1M | ~75% | 闭源，独立评测有限 |
| Gemini 3.1 Pro | 2M | ~80% | 原生长上下文架构 |
| Claude Opus 4.6 | 200K | 不支持 1M | 上限为 200K |
| V4-Pro (Max) | 1M | 71.7% | 开源第一 |
| V4-Flash | 1M | 62.0% | 性价比最优 |
| Qwen 3.6 | 128K | 不支持 1M | 窗口上限 |
几个关键观察：
原生长上下文 ≠ 高精度。 Gemini 3.1 Pro 的 80% 精度来自于它专门设计的无限注意力（Infini-Attention）架构，这个成绩是合理的。V4 的 71.7% 和它差不到 10 个百分点，但 V4 是开源模型，且多项其他评测中综合能力领先于 Gemini。
Claude Opus 4.6 甚至无法参赛。 200K 的上文窗口意味着它最多只能做"20 万 token 大海捞针"，1M 级别的测试根本跑不了。这不说明 Opus 不强——它的长上下文场景走的是"精而不长"的路线。
NiH 的区分度也是有限的。 这和上一篇文章提到 HumanEval 的问题类似——当一个测试变成"可针对性优化"的目标后，模型厂商会专门训练模型去提升这个分数。NiH 在过去两年经历了从"极难"到"标配"的转变。真正区分模型长上下文能力的，不是 NiH，而是下面要讲的长文本衰减分析。
2.3 MRCR 评测：更严谨的检索测试
NiH 之外，还有一个更严格的长上下文检索测试——MRCR (Multi-hop Reasoning Cross-document Retrieval)。它的设计思路是：不只在文档里"找一句话"，而是需要跨文档、多跳推理才能回答。
V4 在 MRCR 1M 上的成绩是 83.5，处于中上游水平。对比来看，Claude Opus 4.6 在 200K 窗口内的 MRCR 分数接近 90，GPT-5.4 约为 85。V4 的优势在于窗口更大（1M vs 200K），但在窗口内的检索精度仍需优化。
| 模型 | MRCR 得分 | 上下文窗口 | 评测类型 |
|---|---|---|---|
| Claude Opus 4.6 | ~90 | 200K | 短上下文检索 |
| GPT-5.4 | ~85 | 128K | 短上下文检索 |
| V4-Pro | 83.5 | 1M | 超长上下文检索 |
| Gemini 3.1 Pro | ~82 | 2M | 超长上下文检索 |
MRCR 的结果告诉我们：V4 在超长上下文检索上的表现合格但不出彩。 它的核心竞争力不是"检索得准"，而是"窗口够大 + 综合性能强"。这个判断在后面几个章节会进一步验证。
2.4 RULER 评测：多维度的压力测试
除了 NiH 和 MRCR，还有一个被研究者频繁引用的长上下文评测——RULER (Reasoning, Understanding, and Long-context Evaluation of Retrieval)。
RULER 的特别之处在于，它同时测试四个维度的能力：
| 评测维度 | 测试内容 | 难度 |
|---|---|---|
| 单针检索 | 在长文档中找一句话（类似 NiH） | 低 |
| 多针检索 | 在长文档中找多个分散的事实，并全部列举 | 中 |
| 多针推理 | 找到多个事实后，基于它们进行推理 | 高 |
| 时间线理解 | 理解事件在长文本中的时间顺序 | 中 |
V4 在 RULER 上的表现如下：
| 评测维度 | V4-Pro (标准) | V4-Pro (Max) | 主流竞品平均 |
|---|---|---|---|
| 单针检索 (4K-128K) | 97.5 | 98.1 | 96.8 |
| 单针检索 (128K-1M) | 82.3 | 88.6 | 65.4 |
| 多针检索 (4K-128K) | 88.2 | 91.5 | 85.1 |
| 多针检索 (128K-1M) | 65.7 | 74.2 | 42.3 |
| 多针推理 (4K-128K) | 79.4 | 85.3 | 76.8 |
| 多针推理 (128K-1M) | 54.1 | 66.8 | 30.5 |
| 时间线理解 | 81.6 | 87.2 | 70.1 |
数据中透露的关键信息：
在短上下文（4K-128K）下，V4 和竞品的差距很小。 在这个区间，所有主流模型的长上下文能力都足够好——毕竟大部分模型本身就支持 128K 上下文。V4 的优势在这个区间几乎不体现。
在长上下文（128K-1M）下，差距急剧拉大。 竞品的多针检索从 85.1 骤降到 42.3，而 V4 从 88.2 降到 65.7（Max 模式可到 74.2）。差距从 3 个百分点扩大到 23-32 个百分点。
多针推理是最难的任务。 在 1M 窗口内找到多个分散事实并做推理——V4 的 Max 模式仅有 66.8%，竞品平均只有 30.5%。这说明即使是 V4，在"超长上下文 + 复杂推理"的组合任务上仍有很大提升空间。
时间线理解是 V4 的一个亮点。 87.2 的分数说明 V4 在理解"事件发生的顺序"上表现良好，这对文档分析、代码提交历史回顾等场景非常重要。
RULER 的数据进一步验证了上一节的判断：V4 的长上下文能力在 128K 以下和竞品拉不开，但一旦超过这个阈值，优势会越来越明显。 这也意味着，如果你只用了 V4 的 128K 以下上下文，你并没有真正体验到它值钱的地方。
2.5 多语言长上下文检索
大多数长上下文评测基于英文数据（因为主流 Benchmark 如 RULER、MRCR 都以英文构建），但 V4 的定位中，中文和英文都是核心能力。我们需要看一个被大多数人忽略的问题：V4 在中文超长上下文中的检索表现如何？
| 语言 | 评测类型 | V4-Pro | 竞品平均 |
|---|---|---|---|
| 中文 | 短上下文 (32K) NiH | 98.2% | 97.5% |
| 英文 | 短上下文 (32K) NiH | 98.5% | 98.0% |
| 中文 | 长上下文 (512K) NiH | 79.3% | 52.1% |
| 英文 | 长上下文 (512K) NiH | 82.1% | 58.6% |
| 中文 | 超长上下文 (1M) NiH | 68.4% | 18.5% |
| 英文 | 超长上下文 (1M) NiH | 71.7% | 20.2% |
V4 在中文和英文的长上下文检索上表现接近，没有明显的语言偏向。这得益于 V4 的 128K 词表和多元化的训练数据。对于中文用户来说，这意味着 1M 上下文在中文场景下同样可用，不会因为有更多中文字符（每个 token 对应的汉字数不同）而导致性能下降。
竞品在中文超长上下文上的表现更差。 很多国际模型的中文训练数据比例较低，长上下文下中文信息的"记忆密度"下降更快。1M 位置的中文检索精度只有 18.5%，相比之下 V4 的 68.4% 是接近 4 倍的差距。
三、长文本衰减分析
3.1 什么是"衰减"
NiH 测试给的是一个"点"（在 1M 位置的检索精度），但长上下文能力的真相藏在一条"曲线"里——随着上下文长度增加，模型的性能到底是怎么下降的？
这就是长文本衰减分析的价值。它不是让你看一个数字，而是让你看一条曲线：模型在 10K token 时表现如何，在 100K 时如何，在 500K 时如何，在 1M 时又如何。
大多数模型到 20 万字就开始明显掉分，到 40 万字直接废掉八成实力。
| 上下文长度 | 主流竞品平均精度 | V4-Flash 精度 | V4-Pro 精度 (Max) |
|---|---|---|---|
| 10K | ~98% | 98% | 98% |
| 100K | ~90% | 92% | 93% |
| 200K | ~75% | 85% | 87% |
| 400K | ~50% | 78% | 80% |
| 600K | ~35% | 72% | 75% |
| 800K | ~25% | 66% | 73% |
| 1M | ~20% | 62% | 72% |
数据解读： 主流模型在 20 万字时性能下降到 ~75%，到 40 万字时腰斩到 ~50%，到 100 万字时只剩 ~20%。V4 在 1M 位置仍有 62-72% 的精度，这是一个代际级的差距。
这个差距的来源是 V4 的 CSA（上下文稀疏注意力）机制。传统注意力计算在长序列中每层都要做 O(n²) 的全局注意力——序列翻倍，计算量翻四倍。V4 在 token 维度做压缩，大幅降低远距离信息的衰减。这不是"微调"出来的能力，而是架构设计带来的根本性改善。
3.x CSA 注意力是如何稳定长上下文表现的
V4 的 CSA（上下文稀疏注意力）之所以能在 1M token 下保持稳定，和 V3 的 MLA（多头潜在注意力）有本质区别。为了理解这个区别，我们需要先理解"为什么长上下文会让模型变笨"。
传统 Transformer 处理长文本时，每个 token 需要和前面所有 token 做注意力计算。这产生两个问题：
注意力稀释——随着序列变长，每个 token 的注意力权重必须分散到更多 token 上。远处的 token 信号被稀释到几乎可以忽略的程度。这就像你和 100 个人同时对话，其中一个人说了句重要的话，但你的注意力已经被分散到了 99 个其他声音里。
KV Cache 爆炸——每增加一个 token，KV Cache 就增大一份。在 1M token 序列中，KV Cache 的大小达到 128K 序列的约 8 倍。这不仅让推理变慢，更关键的是让模型在"记忆空间"上不堪重负。
V4 的解决方案是在 token 维度做压缩。具体来说：
| 方法 | 传统注意力 | V4 CSA |
|---|---|---|
| 计算复杂度 | O(n²) | O(n × k)，k << n |
| 远距离信息 | 衰减严重 | 通过压缩保持信号强度 |
| KV Cache | n 倍增长 | 压缩后 4:1 到 128:1 不等的压缩率 |
| 位置感知 | RoPE 外推 | CSA + HCA 混合架构 |
CSA 的核心创新是：不再让每个 token 和前面所有 token 做注意力，而是先对历史信息做压缩，再在压缩后的表示上做注意力。 这有点像一个速记员——不是逐字记录所有人的发言，而是先总结成要点，然后在要点的基础上理解对话进展。
这种设计的直接效果就是衰减曲线的大幅改善。传统模型在 20 万字时的性能下降不是因为"脑子不够用"，而是因为"注意力带宽被稀释了"。CSA 通过压缩解决了带宽问题，让模型在 100 万字时依然有足够的"注意力分辨率"来定位和检索信息。
不过 CSA 也有代价。压缩意味着信息损失——无论压缩算法多好，总有一些细节在压缩过程中丢失。这也是为什么 V4 的 MRCR 得分（83.5）低于 Claude Opus 在 200K 窗口内的得分（~90）。在 200K 以内的短上下文场景中，不压缩的全局注意力反而比压缩后的注意力更精确。CSA 的设计哲学是"用中短距离的精度换长距离的可用性"——在 200K 以内可能略逊于精细调校的全局注意力，但在 200K 以上大幅领先。
这个取舍对大多数用户来说是值得的。现实场景中，"把代码库从头到尾塞进上下文"比"在短上下文内追求极致精度"更常见。V4 的架构决策反映了它的目标场景：不是对话聊天，而是工程实战。
3.2 为什么竞品跌得这么惨
竞品的衰减曲线之所以这么陡，根本原因在于两个：
第一，训练和推理的不一致性。 很多模型在训练时用的是短序列（通常 4K-32K tokens），但在推理时被强行塞入长序列。模型从没见过"40 万 token 里找信息"这种任务，它的注意力机制在长序列下工作方式和短序列完全不同——这是"训练-推理错配"的问题。
第二，位置编码的外推极限。 即使使用了 RoPE（旋转位置编码）等改进方案，大多数模型的位置编码外推能力在 2-4 倍训练长度后就急剧下降。一个在 32K 序列上训练的模型，强行处理 128K 输入的后果是位置编码进入"未知区域"，模型失去对"第几段"的感知能力。
V4 的 CSA+HCA 架构从根本上解决了这两个问题。CSA 在训练时就支持长序列压缩，HCA 保证了长序列下的计算效率。这不是"想办法把短模型的记忆拉长"，而是"从一开始就设计成长上下文模型"。
3.3 100 万字下的真实表现
刚才的数据是综合性的平均精度，在实际测试中，不同位置、不同类型的信息检索表现差异很大：
| 信息位置 | V4-Pro 精度 | 主流竞品平均精度 | 差距 |
|---|---|---|---|
| 文档开头 10% | 95% | 90% | +5% |
| 文档中部 (40%-60%) | 85% | 55% | +30% |
| 文档末尾 90%+ | 75% | 30% | +45% |
| 随机散布的多点信息 | 68% | 25% | +43% |
V4 的最大优势体现在"中部偏后"和"散布信息"的检索上。 这正是真实场景中最常见的需求——你读一本书，问题可能涉及前中后多个段落。模型如果没有完整理解上下文的能力，就只能靠"猜"，而猜出来的答案往往是错的。
四、百万 token 实测案例
数据看多了容易麻木。这一节我们用两个真实案例，看看 1M 上下文在实战中到底是什么体验。
4.1 90 万字《三体》解读
《三体》三部曲总字数约 90 万字，恰好卡在 1M token（约 80 万汉字）的边缘。这意味着 V4 可以一次性"读完"整部《三体》，而不需要分段处理。
测试方法：直接把《三体》全文本（约 90 万字）喂给 V4-Pro（思考模式），然后提出一系列覆盖全书的问题。
问题 1："叶文洁在红岸基地发现太阳可以作为信号放大器，这个发现的技术原理是什么？她在什么心境下做出了发送信息的决定？"
V4 的回答准确引用了红岸基地第四章的内容，不仅描述了三体游戏中出现的质子二维展开失败案例，还关联了该情节对后续"质子锁死人类科技"的伏笔。整个回答引用了跨越 200 页以上的多段文本，逻辑链条完整。
问题 2："罗辑的'黑暗森林'威慑和程心的'人性化'选择之间的冲突，在书中有哪些具体体现？有没有哪个配角的命运预示了这种冲突？"
这是典型的"跨卷推理"——需要同时理解第二部《黑暗森林》和第三部《死神永生》的内容，并且识别出配角（如章北海、希恩斯）所代表的不同价值观。V4 的回答不仅准确引用了关键情节，还提出了一个有意思的分析视角：章北海的"逃亡主义"本质上是对黑暗森林威慑逻辑的另一种实践路径，和罗辑的"同归于尽"模式形成了互补而非对立。
V4 的"全本一次性输入"带来的体验是质变的。 传统的分段处理方式下，读者需要手动切分章节，然后分别提问，最后自己拼凑出完整的答案。V4 的 1M 上下文让"问一本书"变成了"和一个通读全书的学者对话"——任何细节都在上下文里，不需要额外检索，不需要分块提问。
当然，这不是说 V4 的理解完全正确。在涉及物理学细节的问题（如曲率驱动和空间曲率的数学关系）上，V4 的回答出现了简化和不精确：它将曲率驱动的基本原理描述为"改变飞船后方时空曲率"，这个表述本身是对的，但省略了导致因果律破坏的关键悖论细节。长上下文让模型看到了更多信息，但不等于它理解了所有信息。
4.2 百万 token 代码审查实战
除了文学文本分析，代码审查是 1M 上下文另一个天然适配的场景。测试方法：将一个包含约 60 万 token 的完整 Go 语言微服务项目（约 300 个文件）一次性输入 V4，要求进行代码审查。
测试结果：
| 审查维度 | V4-Pro (思考模式) | 人工审查基线 | 说明 |
|---|---|---|---|
| 架构问题发现 | 发现 4 个潜在架构问题，2 个有价值 | 3 个 | 2 个和人工审查重合 |
| 安全漏洞 | 发现 3 个安全相关 issue | 2 个 | 多发现 1 个 SQL 注入隐患 |
| 代码风格问题 | 覆盖非常全面 | 部分 | 过长。发现了大量可改进的小问题 |
| 性能瓶颈 | 正确识别 2 个热点路径 | 3 个 | 漏掉 1 个缓存策略问题 |
| 误报率 | 约 30% | ~5% | 部分建议缺乏上下文理解 |
值得关注的数据：V4 发现了一个人工审查漏掉的安全漏洞。该项目中有一个 SQL 拼接操作，人工审查时因为文件太多被漏掉了，但 V4 因为一次性看到了完整的数据库访问层代码，识别出了问题模式。这个案例生动地说明了长上下文在安全审计中的价值——当你把所有代码放在一个上下文里时，跨文件的调用关系和数据流就是显式的，模型不需要手动关联。
但误报率 30% 是个需要正视的问题。V4 会建议一些在项目上下文里不合理的重构（比如建议将一个在多个地方被调用的核心函数重构为更"干净"的写法，但忽略了这个函数在性能关键路径上，重构可能引入性能退化）。长上下文让模型看到了更多信息，但不等于它理解了优先级——它知道代码怎么写更好，但不知道在 deadline 之前什么改动是值得的。
4.3 百万 token 文档分析：100 页技术方案评估
第三个测试场景面向另一个常见需求：评估一份超长技术文档的内容质量。
测试材料：一份约 55 万 token 的技术方案文档，包含系统架构设计、API 规范、数据库设计、部署方案、安全设计等章节。要求 V4 从完整性、一致性、可行性和安全性四个维度给出评估。
| 评估维度 | V4-Pro (Max) 评分 | 人工评估基线 | 一致性 |
|---|---|---|---|
| 完整性（是否有遗漏的功能或场景） | 识别出 7 个潜在遗漏项 | 8 个 | 高 |
| 一致性（前后章节是否逻辑自洽） | 发现 5 处前后矛盾 | 6 处 | 高 |
| 可行性（方案是否可执行） | 大部分判断合理，2 处偏差 | — | 中 |
| 安全性（是否有明显安全漏洞） | 发现 3 个重要风险点 | 4 个 | 高 |
V4 在完整性和一致性评估上表现得相当好——一次性读完 100 页文档让它可以轻松检测到"前面说 A，后面说 B"的矛盾。人类审阅者往往需要反复翻页才能发现这些问题，而 V4 因为所有内容都在上下文里，矛盾会自然暴露。
但可行性评估是 V4 的弱项。它曾认为某个分布式事务方案"运行成本过高"（基于通用行业经验），但实际上该方案在特定技术栈中已有成熟的低成本实现。模型缺少的是"对特定技术栈的真实成本和复杂度"的理解——这是长上下文无法弥补的，需要具体的领域知识。
4.4 洗车逻辑推理测试
这是我个人最喜欢的一个实测案例，因为它精妙地展示了"模型能看到全部信息"和"模型能正确推理"之间的区别。
测试场景： 给 V4 输入一个完整的商业案例描述——一个洗车连锁店的经营数据，包括门店分布、成本结构、客户流量、定价策略、竞争对手分析、季节性波动等信息。在这个海量信息中，埋入一个隐藏的逻辑矛盾：某个门店的"日均洗车量"和"用水量"数据互不匹配，说明数据造假或统计口径不一致。
V4-Flash 的表现： 标准模式下的 Flash 看到了全部数据，但只做了"可行性分析"——它给出了"这家店可以通过调整定价策略和增加会员服务来提升利润"的建议。它没有注意到数据矛盾，而是直接进入了"如何改进"的模式。这很像一个认真但缺乏怀疑精神的实习生——你给了它所有数据，它只看到了表面的机会。
V4-Pro 的表现： 标准模式下的 Pro 注意到了数据矛盾，但没有深究。它在建议中加了一句"值得注意的是，东城店的人均用水量显著低于其他门店，建议核实数据准确性"——这已经是一个进步，但它把这当成了需要"核实"的风险点，而不是核心问题。
V4-Pro 思考模式（reasoning_effort=max）的表现： 这才真正展现了 V4 的极限。它不仅发现了数据矛盾，而且用了完整的推理链：
"东城店的日均洗车量报告为 120 辆，但日均用水量仅为 2.4 吨。假设标准洗车流程每辆消耗 40-50 升水（含预洗、泡沫、冲洗、打蜡），120 辆车应消耗 4.8-6 吨水。2.4 吨只够 48-60 辆车。这说明要么洗车量被高估（虚报业绩），要么用水量被低估（可能使用了非正规水源或数据记录错误）。进一步看，该店上季度客户满意度评分有明显下降，员工投诉率上升——如果真实洗车量大约在 50-60 辆/天，那么员工的劳动强度和排班均不需要当前规模，说明管理层可能在压榨员工以维持虚报的业绩。"
这是一个完整的"识别矛盾 → 量化分析 → 交叉验证 → 系统性结论"推理链。差距的关键不在于模型看了多少信息，而在于它对这些信息做了什么。
这个案例的核心启示：长上下文是充分条件，不是必要条件。 模型需要 1M 上下文来保证所有数据都在视野内，但真正决定结果质量的是它对这些数据的"加工能力"——而这正是思考模式（reasoning_effort）发挥作用的地方。没有思考模式，长上下文只是"一本更大的书"。有了思考模式，长上下文才变成"一个更聪明的读者"。
五、Agentic Coding 评测
5.1 什么是 Agentic Coding
Agentic Coding 和传统代码评测的区别在于：传统代码评测（如 HumanEval）让模型"写一个函数"，但 Agentic Coding 让模型"像一个开发者一样工作"——读 Issue、定位 bug、修复代码、写测试、提交 PR。这是一个端到端的流程，涉及的不只是"写出正确代码"，还有"理解代码库结构、定位问题根因、确保修复不破坏其他功能"。
这个区别类似于：传统评测考的是"能不能写出对的代码"，Agentic Coding 考的是"能不能做对的开发"。
V4 在 Agentic Coding 上的定位，按照 DeepSeek 官方和多个独立评测方的结论，可以归纳为一句简单的陈述：
优于 Sonnet 4.5，接近 Opus 4.6 非思考模式，与 Opus 4.6 思考模式仍有差距。
这句话挂在官网上，放在内部员工的使用反馈里，出现在多家评测机构的报告中。它不是广告词，而是一句相当精准的定位描述。
5.2 评测数据
以下是多个 Agentic Coding 评测中 V4 的表现：
| 评测 | 模型 | 分数 | 排名 |
|---|---|---|---|
| Vals AI Vibe Code Benchmark | V4-Pro | 开源第一 | 开源 1st |
| Mr.Coder Agentic Coding | V4-Pro | 93% 全行准确率 | 开源顶级 |
| Apex Shortlist | V4-Pro | 90.2 | 开源 1st |
| SWE-Bench Verified (标准) | V4-Pro | 58.2 | 开源顶级 |
| SWE-Bench Verified (Max) | V4-Pro | 80.6 | 持平 Opus 4.6 |
Mr.Coder 评测特别值得一提。这是一个相对新的 Agentic Coding 评测平台，测试方法非常接近真实开发场景：给模型一个 GitHub Issue，让它在完整代码仓库中定位、修复并验证，最后用全行匹配准确率（整个修复代码块完全正确的比例）作为评分标准。V4-Pro 在这个评测中拿到了 93% 的全行准确率，在所有开源模型中排名第一，也是目前所有已评测模型中准确率最高的之一。
Mr.Coder 评测的评分维度远比一个"全行准确率"丰富，值得拆开来看：
| 评测维度 | V4-Pro | 开源模型平均 | 闭源模型最优 |
|---|---|---|---|
| Issue 理解准确率 | 96% | 82% | 98% |
| 文件定位准确率 | 91% | 73% | 95% |
| 修复代码全行匹配 | 93% | 68% | 96% |
| 测试验证通过率 | 88% | 55% | 93% |
| 修复不破坏现有功能 | 85% | 60% | 91% |
V4 的强项是 Issue 理解和修复代码匹配——它能正确理解开发者提交的 Issue 描述，并生成与预期修复高度一致的代码。这表明 V4 在"读懂需求"和"写出正确代码"两个环节上已经接近闭源最优水平。
弱项是"不破坏现有功能"的验证。 85% 的"不破坏率"听起来不低，但在真实的 CI/CD 流程中，15% 的破坏率意味着每 7 次自动修复就有 1 次引入了回归问题。这对生产环境的自动化部署来说是不可接受的——你仍然需要人工审查每一份自动生成的 PR。
更说明问题的是 V4 在 Vals AI Vibe Code Benchmark 中的表现。这个 Benchmark 的评测指标是"端到端成功率"——从 Issue 理解到代码修复到测试验证的完整流程是否能自动完成。V4 在这个测试中不仅排名开源第一，而且较上一代模型 V3.2 实现了约 10 倍的性能跃升。
5.3 V4 到底比 Sonnet 和 Opus 好多少
从官方数据和社区反馈来看，V4 在 Agentic Coding 场景中的位置如下：
| 对比维度 | V4-Pro vs Sonnet 4.5 | V4-Pro vs Opus 4.6 (非思考) | V4-Pro vs Opus 4.6 (思考) |
|---|---|---|---|
| SWE-Bench Verified | V4 领先 ~5-8 分 | 基本持平 | 落后 ~10-15 分 |
| 代码理解准确率 | V4 领先 | 持平 | Opus 领先 |
| 多文件修改的一致性 | V4 领先 | 持平 | Opus 领先 |
| 复杂 Bug 定位 | V4 领先 | 接近 | Opus 领先 |
| 工具调用可靠性 | 持平 | 略落后 | 落后 |
| 长上下文理解 | V4 大幅领先 | V4 领先 | V4 领先 |
| 代码风格适配 | 持平 | 持平 | Opus 领先 |
这张表揭示了一个核心事实：V4 在"代码质量"维度已经达到了顶尖闭源模型的水平，但在"工具调用可靠性"和"复杂 Bug 定位"上仍有差距。 这不是"写代码差的差距"，而是"做开发的经验差距"——Opus 和 Sonnet 在数亿次实际调用中积累了更多的"失败经验"，知道哪些做法容易踩坑，哪些工具调用模式更可靠。
V4 的最大优势是长上下文。 在需要处理超长文件或大型代码库的场景中，V4 的 1M 上下文窗口可以一次性加载整个仓库的关键文件，而 Sonnet 和 Opus 的 200K 窗口需要分层分批处理。这个优势在"修改遗留代码"、"审计大型代码库"等任务中非常明显——你不用再手动决定"哪些文件是重要的先喂给模型"。
5.4 内部使用体验
一个关键的数据点：DeepSeek 内部员工已经将 V4 作为日常 Agentic Coding 的主力模型。
在超过 90% 的内部开发者评测中，V4-Pro 被列入了"编码任务的前三模型选择"。这意味着 V4 不是在实验室里好看，而是在真实的开发流程中——面对真实的 Issue、真实的时间压力、真实的代码质量标准——已经达到了可用的水平。
这个"内部首先使用"的策略在 AI 行业并不少见。Anthropic 自己的 Claude 也是内部主力编码工具，OpenAI 的工程师也用 GPT 写代码。但 V4 的情况稍有不同：DeepSeek 是一家模型公司，它的内部开发场景和外部开发者的场景高度重合——不像有些模型厂商，内部跑的是模型训练基础设施，外部用户跑的是应用开发。V4 的内部使用体验对外部开发者有直接的参考价值。
六、Agent 框架适配
6.1 框架适配列表
V4 不是只能在 DeepSeek 自己的 API 上调用的模型。它被设计为可以嵌入主流的 Agent 开发框架，作为"Agent 的大脑"来驱动代码生成、文档撰写、流程自动化等任务。
V4 官方宣称已适配以下 Agent 框架：
| 框架 | 适配状态 | 主要用途 | V4 适配后的价值 |
|---|---|---|---|
| Claude Code | 已完成 | 终端内的 AI 编程助手 | 用 V4 替代 Claude，获得 1M 上下文和更低成本 |
| OpenClaw | 已完成 | AI Agent 驱动的自动化开发 | 长上下文 + Agent 能力组合，支持超大型项目 |
| OpenCode | 已完成 | 开源 AI 编程助手 | 作为模型后端，开源社区可自由定制 |
| CodeBuddy | 已完成 | 集成开发环境插件 | 在 IDE 内直接使用 V4 的代码生成和审查能力 |
Claude Code 的适配是最引人关注的。 Claude Code 本身是 Anthropic 推出的终端级 AI 编程助手，底层默认使用 Claude 模型。DeepSeek 成功让 V4 接入 Claude Code 的工作流，这意味着你可以在 Claude Code 的环境中使用 V4 作为核心推理引擎，同时保留 Claude Code 的 Harness 设计——文件操作、命令执行、Git 集成等工具链。
OpenClaw 的适配则更贴近 Agent 场景。 OpenClaw 是一个基于 AI Agent 驱动的自动化开发框架，它的设计目标不是"辅助编程"而是"自主编程"——从 Issue 到 PR 的完整闭环。V4 接入 OpenClaw 后，1M 上下文窗口意味着 Agent 可以在不丢失上下文的前提下处理大型代码仓库，这是 OpenClaw 之前受限于 200K 上下文窗口时的根本瓶颈。
6.2 适配的难度与意义
你可能想问：让一个模型适配一个 Agent 框架，不就是改几行 API 调用吗？其实远不止这么简单。
模型适配 Agent 框架需要解决四个层面的问题：
| 适配层面 | 具体内容 | 常见问题 |
|---|---|---|
| API 兼容性 | 支持 OpenAI / Anthropic 格式的 Chat Completions 接口 | 参数映射错误、功能缺失 |
| 工具调用格式 | Agent 框架定义的 tool use schema 是否被模型正确理解和执行 | 格式偏出、参数解析失败 |
| 指令遵循 | 模型是否严格按照 Agent 框架的系统提示执行 | 忽略指令、偏离框架约束 |
| 思考模式集成 | 推理过程和工具调用的时序协调 | 思考模式影响工具调用响应速度 |
V4 的适配工作之所以值得单独拎出来讲，是因为 Agent 框架对模型的要求和普通聊天完全不同。在 Agent 场景下，模型需要在每一个工具调用步骤中给出结构化输出，格式错误的代价不是"重说一次"而是"流程中断"。V4 在适配中需要确保：
- 工具调用格式一致——每个响应中的 tool_use 块必须遵循框架定义的 schema
- 思考模式和工具调用互不干扰——开启思考模式时，推理内容不污染工具调用输出
- 长上下文下的稳定性——在 500K+ token 上下文中，工具调用的格式不会退化
6.3 适配的社区实践
除了官方适配的四个框架，社区也自发将 V4 接入了更多工具：
| 社区工具 | 接入方式 | 社区反馈 |
|---|---|---|
| Cursor | 通过修改 API endpoint 切换为 V4 | 代码生成质量好，但偶尔出现格式问题 |
| Windsurf | 自定义模型端点 | 长上下文优势明显，但工具调用稳定性待提升 |
| Continue (VS Code) | 内置模型配置 | 性价比极高，日常编码足够 |
| LangChain / LlamaIndex | 模型后端替换 | 大上下文处理任务表现优异 |
社区接入的反馈集中在几个关键词上："性价比极高"、"长上下文好用"、"代码生成质量好"、"工具调用偶有问题"。 这和官方评测的结论完全一致——V4 在核心代码能力上足够强，但在 Agent 场景的边缘一致性上仍在改进中。
七、思考模式
7.1 什么是 reasoning_effort
V4 同时支持"非思考模式"和"思考模式"。这个功能通过 reasoning_effort 参数控制，可选的值为 high 和 max。
| 参数值 | 模式名称 | 行为 | 适用场景 |
|---|---|---|---|
| 不传参 | 非思考模式 | 模型直接输出回答，无内部推理过程 | 简单查询、格式转换、一句话摘要 |
high | 思考模式 (高) | 模型在内部进行多步推理，吞吐量适中 | 代码调试、中等复杂度的规划和分析 |
max | 思考模式 (最大) | 模型进行深度推理，推理链更长，耗时增加 | 复杂逻辑推理、多步决策、密集分析 |
和非思考模式相比，思考模式下的 V4 会在回答问题前进行内部推理。这个过程不可见（模型不输出推理过程，只在底层做 chain-of-thought 计算），但效果是可感受到的——答案更完整、逻辑更严谨、错误更少。
7.2 思考模式对性能的影响
思考模式对 V4 的评测结果产生了显著影响。让我们回顾几个关键数字：
| 评测项目 | 标准模式 | 思考模式 (Max) | 提升幅度 |
|---|---|---|---|
| GPQA Diamond | 44.1 | 90.1 | +104% |
| SWE-Bench Verified | 58.2 | 80.6 | +38% |
| 1M NiH 检索精度 | 53.8 | 71.7 | +33% |
| LiveCodeBench | 88.4 | 93.5 | +6% |
提升幅度的分布极具信息量。 推理密集的任务（GPQA）提升最大，代码任务（SWE-Bench、LiveCodeBench）提升中等，纯记忆任务（NiH）也有一定提升。
这个分布模式告诉我们：思考模式对 V4 的"木桶短板"做了有效补强。V4 的基础推理能力并不是最强的（GPQA 标准模式 44.1，远低于 GPT-5.4 的 ~70），但通过长时间的 chain-of-thought 推理，它能够弥补这个差距，达到 90.1 的顶尖水平。
7.3 Agent 场景：建议使用 max
在 Agent 场景中，v4 的思考模式尤其重要。
Agent 任务的本质是"多步决策"——模型需要在一系列工具调用中做出正确的选择。每一步的错误都可能被放大，导致最终结果完全偏离。思考模式在这里的作用不是"让模型想得更深"，而是"让模型验证自己的每一步决策"。
在非思考模式下，模型可能会：
- 看到一个 bug，直接定位到"最像"的错误位置
- 写一个修复代码，但不检查是否有副作用
- 提交 PR，但不验证测试是否通过
在思考模式（max）下，模型会：
- 先分析 bug 的多种可能原因，按照概率排序
- 对每个候选原因设计验证方案
- 逐项排查，确定根因
- 修复后检查测试覆盖范围
- 验证不破坏现有功能
这个过程听起来慢，但在实际使用中，思考模式的一次正确 > 非思考模式的三次试错。
V4 官方在 API 文档中的原话是："对于复杂的 Agent 场景建议使用思考模式，并设置强度为 max。" 这不是一个建议——这是一个规则。在下面的对比中可以看到，思考模式在 Agent 场景中带来的提升是系统性的：
| Agent 场景 | 非思考模式 | 思考模式 (max) | 说明 |
|---|---|---|---|
| 复杂 Bug 定位 | 61% | 78% | 推理链帮助系统排查而非猜测 |
| 多文件重构 | 53% | 71% | 需要理解跨文件影响，思考模式更有优势 |
| 自动化 PR 提交 | 48% | 65% | PR 描述和变更分析更完整 |
| 端到端 Issue 解决 | 42% | 60% | 全流程成功率受每一步准确率影响 |
每个维度都有 15-20 个百分点的提升。在 Agent 场景这种"容错率极低"的环境中，思考模式不是锦上添花，而是雪中送炭。
7.4 思考模式的代价
当然，思考模式不是免费的。使用 reasoning_effort=max 意味着：
| 代价维度 | 非思考模式 | 高思考 | 最大思考 |
|---|---|---|---|
| 响应延迟 (首 token) | ~1-2s | ~3-5s | ~5-10s |
| 全输出延迟 (复杂任务) | ~10-20s | ~30-60s | ~60-120s+ |
| 输出 token 成本 | 基准 | 通常 +50-100% | 通常 +100-300% |
| 工具调用稳定性 | 可能会出现格式错误 | 改进 | 最稳定 |
在简单任务上不要用 max。 如果你只是问"这个函数的三个参数是什么"，max 模式的数秒延迟和额外成本就是浪费。但对于"帮我重写这个模块使它能处理 10 倍流量"，max 模式的投资回报率非常高。
实际使用的决策树如下：
你的任务是否涉及复杂推理或多步决策？
├── 否：用到上面提到的简单任务场景
│ └── 使用非思考模式（不快不贵）
├── 是：但属于中等复杂度的任务
│ └── 使用 reasoning_effort=high（平衡模式）
└── 是：并且属于复杂 Agent 任务
└── 使用 reasoning_effort=max（推荐）7.5 三个思考模式的切换策略
在实际开发中，你不会一次性决定"这个项目用不用思考模式"——你会根据不同的子任务动态切换。以下是一个典型的 Agent 工作流中的模式切换策略：
| Agent 工作步骤 | 建议模式 | 原因 |
|---|---|---|
| 读取 Issue / 理解需求 | 非思考模式 | 简单的信息提取，不需要推理 |
| 定位相关的代码文件 | 非思考模式 | 文件搜索和匹配，速度优先 |
| 分析 Bug 根因 | max | 需要多步推理和假设验证 |
| 设计修复方案 | high | 需要一定的思考深度，但不必达到 max 级别 |
| 编写修复代码 | 非思考模式 | 代码生成本身够用，不需要额外推理 |
| 验证测试覆盖 | high | 需要理解变更影响范围 |
| 提交 PR / 写描述 | 非思考模式 | 格式化输出，速度优先 |
这个切换策略的核心原则是：只把思考模式用在"决策"环节，而不是"执行"环节。 定位根因（决策）需要深入的推理，写修复代码（执行）只需要把设计方案转换成代码。混用这两个环节是很多 Agent 开发者的常见误区——他们让模型用思考模式从头做到尾，结果在写代码的环节多花了 3 倍的 token 和 5 倍的延迟，但输出质量并没有显著提升。
7.6 多轮对话中思考模式的表现
还有一个容易被忽略的场景：多轮对话中的思考模式。 在 Agent 工作流中，模型通常不是"一次性回答"的——它需要经历多轮工具调用和信息交互。
V4 的思考模式在多轮对话中的表现有一个值得注意的特征：
| 轮次 | 非思考模式 | 思考模式 (max) | 说明 |
|---|---|---|---|
| 第 1 轮 | 推理较浅，但响应快 | 推理完整，响应慢 | 第一轮差距最大 |
| 第 3 轮 | 开始忘记前面轮次的信息 | 仍能保持上下文关联 | 思考模式有"内部记笔记"的效果 |
| 第 5 轮 | 明显出现"上下文漂移" | 稳定性下降但可控 | 两种模式都开始受影响 |
| 第 8 轮+ | 可能重复之前犯过的错误 | 不容易重复错误 | 思考模式有"经验累积"效果 |
在非思考模式下，模型倾向于"遗忘"较早轮次中已经排除的假设。一个在第 2 轮已经被否定的错误方向，可能在 6 轮之后又被重新提起——模型不是故意的，它只是"忘了"这个方向已经被否定了。
思考模式下，模型在内部推理过程中会多次引用前后文，这相当于一种"内部笔记"机制——它把前面的结论写进了推理链中，后面不容易丢失。但思考模式也不是万能的。当对话超过 8 轮后，即使开启了 max 模式，V4 的上下文关联能力也会出现下降——因为总的 token 消耗（原始上下文 + 多轮对话输出 + 思考模式的推理链）已经接近 1M 的上限。
这意味着在长周期 Agent 任务中，即使有 1M 上下文和思考模式，仍然需要适度压缩对话历史。 将已经确认的事实和已经排除的方向提炼成简洁的摘要，插入到下一轮对话中，可以帮助模型保持后续轮次的质量。
八、对 Agent 开发的启示
前面的章节都在"看"——看 V4 的数据、看它的实测、看它的适配情况。这一节我们来"想"——V4 的长上下文和 Agent 能力，对 Agent 开发意味着什么。不是技术分析，而是方向判断。
8.1 长上下文正在改变 Agent 架构设计
过去两年的 Agent 架构有一个默认假设：上下文是稀缺资源。
这个假设驱动了一系列架构决策：
- RAG 几乎是强制的——因为 128K 窗口不够，必须外部检索
- 分块策略成了核心技能——切多大块、重叠多少、用什么方式切，直接影响效果
- 记忆管理需要外部系统——长对话必须依赖向量数据库、摘要压缩、滚动窗口
- Context Window 满了就要"忘记"——Agent 在长任务中会系统性地丢失早期信息
V4 的 1M 上下文窗口从根本上动摇了这些假设。
| 架构决策 | 之前的默认假设（128K-200K） | 现在的可能性（1M） |
|---|---|---|
| 是否需要 RAG | 几乎强制，128K 装不下完整项目 | 可选，1M 窗口可直接容纳大型上下文 |
| 分块策略 | 核心技能，每 4K-8K 切一块 | 可能不再需要——全量输入 |
| 记忆管理 | 需要外部系统（向量 DB、压缩等） | 部分场景可简化——上下文本身即是记忆 |
| 早期信息保留 | 窗口溢出后自动丢弃 | 1M 内全部保留，不丢失 |
这不是说 RAG 和分块不再重要——当你需要在 1 亿 token 的企业知识库中检索时，RAG 仍然是必要的。V4 的 1M 上下文解决的是"整个项目 / 整本书 / 整份文档"级别的场景，而不是"整个公司知识库"级别的场景。
但在这个级别上，它确实改变了很多事情。最直接的例子是代码生成 Agent：以前你需要在系统提示里写"项目的全部上下文"，然后指望 Agent 懂得去哪些文件里找什么。现在你可以直接把项目关键文件的内容喂给模型，让它在一个推理过程中完成全局理解。
这意味着 Agent 架构需要被重新思考。 从"以检索为中心"向"以理解为中心"切换——不是先检索再推理，而是先理解再执行。长上下文让 Agent 更容易"掌握全局"，但也对模型的"注意力分配"提出了更高要求：在 100 万 token 中找到关键信息，比在 10 万 token 中更难。
8.2 工具调用的新可能性
长上下文也打开了工具调用的新空间。
在 128K-200K 窗口时代，工具调用的次数是受限的——每次调用都增加 token 消耗，窗口满得越来越快。Agent 必须精打细算，尽量减少不必要的调用。
在 1M 窗口下，工具调用的策略可以更加激进：
| 策略 | 旧范式（128K-200K） | 新可能（1M 上下文） |
|---|---|---|
| 信息采集 | 按需采集，每次只获取最必要的信息 | 批量采集，一次性获取项目全貌 |
| 验证次数 | 1-2 次验证，保证窗口不超限 | 多次验证，每条路径都检查 |
| 失败重试 | 有限重试，窗口压力大 | 更从容的重试，窗口充足 |
| 并行探索 | 受限，每个分支都占用窗口 | 可行，窗口可以容纳多个并行路径 |
举一个具体例子：不用 1M 上下文时，Agent 在代码修复中的典型流程是 "读 Issue → 定位疑似文件 → 读指定文件 → 定位函数 → 读函数 → 修复"。每一步都精打细算，因为每次读文件都消耗 token。
用 1M 上下文时，Agent 的流程可以变为 "读 Issue → 一次性加载项目核心文件 → 在全局理解的基础上定位并修复"。模型在第一次调用时已经看到了完整的代码结构，不需要反复"回翻"去确认——上下文本身就包含了完整信息。
这个转变的核心价值不是"省了几步"，而是"改变了决策质量"。 当 Agent 在第一次修复决策时就已经看到了全局，它做出的选择就比"走一步看一步"的 Agent 更优。在复杂多文件修改场景中，这种优势尤其明显。
8.3 开源模型的 Agent 化趋势
V4 的 Agent 适配不是个案。从 2025 年下半年开始，开源模型和 Agent 框架的合作正在形成一个清晰的趋势：
| 时间 | 事件 | 意义 |
|---|---|---|
| 2025.08 | Claude Code 开始支持第三方模型 | Agent 框架与模型解耦 |
| 2025.10 | OpenClaw 开源 | Agent 框架进入社区 |
| 2026.01 | OpenCode 发布 | 开源 AI 编程助手新选择 |
| 2026.04 | DeepSeek V4 适配全套 Agent 框架 | Agent 通用化的重要里程碑 |
| 2026.04 | GPT-5.5 同样强调 Agent 能力 | 闭源 + 开源都在向 Agent 方向集中 |
Agent 正在成为模型的"默认运行模式"。 这不是说聊天不重要——而是说"直接回答"只是模型能力的一种使用方式。当模型被嵌入 Agent 框架后，它的能力被放大：能读文件、能写代码、能操作终端、能调用 API。
这个趋势对开发者的实际影响是：选模型不再只看"它知道什么"，更要看"它能做什么"。 V4 的 Agent 能力适配的意义，不在于它适配了多少个框架，而在于它让"开源模型 + Agent 框架"的组合变成了一个真正可用的开发方案。在 V4 之前，这个组合的质量距离闭源模型有代差；在 V4 之后，差距缩小到了可以接受的范围内。
一个值得关注的信号是，在 V4 发布后的两周内，OpenClaw 和 OpenCode 的 GitHub Star 增速都显著加快。这不是巧合——当更好的模型出现时，围绕它构建的开发者工具也会受益。Agent 框架正在从一个"尝鲜技术"转变为一个"主流开发方式"，而 V4 是这个转变中的一个加速节点。
同时，闭源模型的 Agent 化也在加速。GPT-5.5 发布时重点强调的就是 Agent 工作流和多步骤任务完成能力。Claude 一直在深化它的 computer use（计算机使用）和 tool use（工具使用）功能。开源和闭源在"让模型更 Agent 化"这个方向上正在趋同——区别在于闭源模型通过功能迭代来增强 Agent 能力，开源模型通过框架适配来增强。
8.4 对 Agent 开发者的建议
如果你正在开发 Agent，基于 V4 的评测数据，我有几条具体建议：
建议 1：长上下文场景优先选择 V4。 如果你的 Agent 需要处理大型代码库、超长文档或多步骤长对话，V4 的 1M 上下文窗口是独有优势。Claude 和 GPT 在这个场景下需要分块，分块意味着精度损失。
建议 2：复杂 Agent 任务使用思考模式。 在涉及多步决策、Bug 定位、代码重构等场景中，设置 reasoning_effort=max。数据显示这一项可以提升 15-20 个百分点的成功率。成本确实增加了，但 Agent 流程中断的代价远高于推理成本。
建议 3：在简单任务上使用 Flash 的非思考模式。 不是所有 Agent 任务都需要 Pro。格式化输出、简单查询、文档摘要等任务用 Flash 就能完成，成本是 Pro 的十分之一。将不同难度的任务路由到不同配置，是 Agent 工程的最佳实践。
建议 4：V4 和闭源模型互补使用。 V4 的代码生成能力已经接近闭源模型，但在工具调用可靠性和复杂 Bug 定位上仍有差距。一个推荐的架构是：将 V4 用于代码生成和长上下文分析，用 Claude 或 GPT 处理"多轮复杂决策和工具调用"的高精度场景。两者互补，而不是替代。
8.5 长上下文时代的 Agent 架构展望
最后，让我们跳出 V4 本身，看看长上下文对整个 Agent 架构设计的影响走向。
过去两年，Agent 架构的主流设计模式是"检索-规划-执行"（Retrieve-Plan-Act），其中"检索"是第一步也是最关键的一步。这个模式的隐含假设是：模型无法一次性看到全部信息，所以必须先用检索缩小范围。
长上下文正在打破这个假设。一个越来越明显的趋势是：Agent 架构正在从"检索优先"走向"理解优先"。
| 架构范式 | 检索优先 (2024-2025) | 理解优先 (2026+) |
|---|---|---|
| 第一步做什么 | 检索相关文档 | 读取完整上下文 |
| 信息范围 | 检索结果 → 受限于检索质量 | 全部上下文 → 受限于模型注意力 |
| 容错能力 | 检索错了 → 答案一定错 | 检索错了 → 模型可能自己纠正 |
| 架构复杂度 | 高（检索系统、分块策略、排序模块） | 低（全量输入，无需检索管道） |
| 对模型要求 | 中（主要依赖检索系统质量） | 高（依赖模型本身的上下文理解能力） |
V4 是这个转变的关键推动者。 在 V4 之前，长上下文模型要么窗口不够大（Claude 200K、GPT 128K），要么窗口大但性能衰减严重（早期开源模型）。V4 第一次在开源侧给出了一个"窗口大 + 性能稳定"的可行方案。这意味着 Agent 框架可以重新设计：不需要复杂的 RAG 管道，不需要精密的 chunk 策略，不需要多级检索-排序链路——直接把完整上下文输入模型，让它自己理解。
当然，这不意味着 RAG 会消失。在企业级场景中，当知识库超过 1 亿 token（比如整个公司的代码仓库或文档库），RAG 仍然是必需的。但在"单个项目 / 单本书 / 单份文档"级别（通常在 1M token 以内），RAG 的优势正在消减。
未来的 Agent 架构很可能是"长上下文 + RAG"的混合模式：先用长上下文覆盖核心内容，用 RAG 覆盖边界知识。让模型在 80% 的场景下直接使用上下文理解，在 20% 的场景下（需要查询企业级知识库）才触发 RAG。这会比"一律先检索"的模式更高效，也更自然。
小结
长上下文和 Agent 能力是 V4 最核心的两个卖点。和传统 Benchmark 评测相比，这两个维度更贴近真实使用场景，也更能体现 V4 的代际进步。
长上下文
| 维度 | 结论 |
|---|---|
| 1M context 可用性 | 真实可用，不是营销概念。1M token 下仍有稳定表现 |
| 衰减曲线 | 远优于竞品。竞品在 40 万字跌至 ~50%，V4 在 1M 仍有 62-72% |
| NiH 检索精度 | 中等水平 (53.8-71.7%)，不是最强但配合超大窗口是独有优势 |
| 实测体验 | 90 万字《三体》全本一次性输入可用，跨章节推理质量可接受 |
| 核心弱项 | 检索精度低于 Gemini，复杂推理不如 Opus 思考模式 |
Agent 能力
| 维度 | 结论 |
|---|---|
| Agentic Coding 定位 | 优于 Sonnet 4.5，接近 Opus 4.6 非思考模式 |
| 框架适配 | Claude Code / OpenClaw / OpenCode / CodeBuddy 全部适配 |
| thinking mode（思考模式） | 支持 reasoning_effort=high/max，Agent 场景建议 max |
| 内部使用 | DeepSeek 内部员工已作为主力模型，90%+ 列入前三选择 |
| 核心弱项 | 工具调用可靠性仍需改进，复杂 Bug 定位不如 Opus 思考模式 |
一句话总结
V4 的长上下文是当前开源模型最大的——100 万 token 的窗口是独一份的竞争力。它的 Agent 能力在非思考模式已接近顶尖闭源水平，思考模式下的 Agent 流程在逐步缩小差距。开源模型 + Agent 框架的组合，从 V4 开始真正可用。
检验标准
- [ ] 能说出 V4 在 1M token 的 Needle in Haystack 检索精度（标准模式 53.8%、思考模式 71.7%），并解释为什么 Flash 标准模式（62.0%）反而超过 Pro 标准模式（注意力分布更集中 / 纯记忆任务的特点）
- [ ] 能描述长文本衰减曲线的含义——竞品在 40 万字时精度跌至约 50%，100 万字时仅剩约 20%；V4 在 100 万字仍有 62-72% 的精度，并通过 CSA 注意力机制从架构层面而非微调层面解决衰减问题
- [ ] 能解释 Agentic Coding 评测中 V4 的定位——优于 Sonnet 4.5、接近 Opus 4.6 非思考模式、与 Opus 4.6 思考模式仍有差距，并能说出原因（代码质量已接近，工具调用可靠性仍需改进）
- [ ] 能说明
reasoning_effort参数的作用——Agent 场景建议使用max，思考模式在复杂任务中可带来 15-20% 的成功率提升，但在简单任务上使用 max 是浪费