DeepSeek 又更新了一个小版本：改了什么，该怎么看？

DeepSeek V4.1 Flash 又更新了，版本变成了 V4.1-Flash-1017。按发布文的说法，网页端、APP 和 API 已经同步切换到新版。

看版本名，这更像一次沿着现有产品继续打磨的更新。它具体改了什么，为什么值得关注？读完发布文，我认为应该把注意力放在三件事上：同样的任务能否完成得更好、更快、更省；能否少靠用户指挥，把完整项目做出来；搜索工具开放后，使用方式和账单会有什么变化。

这三项变化并不是每位用户都同样有感。只在网页里聊天，可能更在意回答质量和等待时间；用模型做项目，关心的是代码跑不跑得通、要接手几次；自己接 API，则还要看框架适配和完整账单。

本文依据所提供的发布文文字解读。用户提供了发布文里的一张配图，即下面的基准成绩表；性能／成本曲线图和项目演示素材仍未取得。凡这张表里没有的说法，都只是对发布文主张的解释。

先看第一项变化：完成任务的效率。

原文强调，新版在基准测试上取得提升，同时缩短了任务运行时间和输出长度。这比单纯说“分数更高”多了一层意思：它希望证明，成绩提高的同时，用户付出的时间和费用也减少了。

这是一张成绩表，不是费用图。最左一列是基准名称，往右六列依次是新版 V4.1-Flash-1017、上一版 V4.1-Flash，以及 Kimi K3、GLM、GPT、Claude Opus 5 四家对照模型（表头还带了各自的版本号，这里不逐一转录）。

先横着读第一件事：11 个基准里，新版的每个数字都高于上一版。差距最大的三项是 Terminal-Bench 4.0（42.3 对 31.2）、ProgramBench（29.1 对 20.3）和 Apex Bench v1.1（72.1 对 64.6）；差距最小的是 ZeroBench-main，51.0 对 49.0。这一半主张，表是支持的。

再竖着读第二件事：把其他几家也算进来，新版只在 DeepSWE（77.0）、Automation-Bench（60.5）、Agents' Last Exam（35.4）和 Apex Bench v1.1（72.1）四项上排第一。HLE、Terminal-Bench 4.0、ProgramBench、NL2Repo-Bench、Chartography 和 BabyVision 六项的最高分属于 Claude Opus 5，ZeroBench-main 的最高分是 GPT 的 53.0。所以“超过上一版”和“全场第一”是两件事。

读这张表还有几处细节。HLE 那一行的前两列各写了两个数，新版是 42.6 / 44.0，后一个带星号；脚注说带 * 的数字只测了 HLE 的文本子集，所以这一格的分数要看成一个带条件的值，不宜和后续列的单个数直接对比。行标签里的括号也是条件：HLE 标的是“w/o tools”，末尾三行标的是“w/tools”。GLM 的 Chartography、BabyVision、ZeroBench-main 三格里只有一道短横，没有数字就等于没有可比成绩，不能按零分处理。表下的小字另说明：Terminal-Bench 4.0 用的是 Claude Code 框架，DeepSWE 用 Mini-SWE-V2 框架，ZeroBench-main 用 Pass@5 评测。同一张表里混着不同框架、不同工具条件和不同判分方式，跨列比较要带上这些前提。

文章用“性能–费用的帕累托改进”描述这件事。这个术语可以先翻译成一句话：在所比较的指标中，至少一项变好，其他项不变差。

举个假设例子：同样一百个编程任务，旧方案完成七十个，平均每项花一元；新方案完成八十个，平均每项只花七角。效果更好，费用更低，就是帕累托改进。这里的数字只是解释概念，不是 DeepSeek 实测。如果新方案完成八十个，费用却涨到一元五角，那就需要判断多出的效果值不值得这笔钱。

严格来说，同样效果更便宜，或者同样费用效果更好，也属于帕累托改进，不要求两项同时提高。

原文进一步说，在多个 Harness 下达到了新的性能–费用帕累托最优。这里的 Harness 是围绕模型组织工具和任务执行的框架。“最优”是指在给定比较范围内，没有另一个方案能在费用和效果上都不差，并且至少一项更好。这样的方案可以有多个，各自处在不同的价格和效果位置。

所以，这段话值得关注的是它对任务效率的主张。成绩这一半现在有了具体数字，费用那一半还没有：表里只有分数，没有每项任务的耗时和花费，发布文提到的性能／成本曲线图也没有随材料提供。“帕累托最优”必须两项一起看，单凭这张表还不能确认。

对使用者来说，更直接的问题是：原来做不好的任务，现在能不能做好；原来反复修改的任务，现在是否少费一些工夫？ 这是检验这次更新有没有价值的入口。

输出长度缩短，也要放进这个问题里看。编程任务的目标是得到满足要求的结果，短一点但能完成工作，可能比写得很长却需要反复返工更有用。不过，原文没有披露具体过程，不能据此认定新版一定减少了某一类重试。

费用方面尤其要分清：这段发布文没有列出模型输入、输出 token 的新旧价格，因此不能把“任务成本降低”直接读成“token 降价”。Token 是模型处理文本的计量单位；即使单价不变，完成任务所需的生成用量减少，也可能让费用下降。最终仍要合并看输入、输出、工具调用和失败重试的开销。

第二项变化，是把更多完整项目交给模型。

发布文用了“许愿式编程一键成真”这个标题，并列出四个案例：故宫 3D 建模、网页版赛车游戏、基于 Godot 的《传送门2》复刻，以及展现史前到现代发展历程的 Valley of Ages。

这些例子试图展示的是围绕一个目标，把项目各部分组织起来的能力。以赛车游戏为例，用户给出需求后，项目仍需要处理场景、车辆控制、碰撞、界面和运行方式。模型能否把这些部分接起来，比单独生成一段代码更接近实际开发中的问题。

原文强调“较少的提示词与素材参考”和“极短的交互轮次”。我的理解是，这次更新希望减少用户逐步指导的负担：不必每次都告诉模型下一步改哪个文件，而是让它承担更多规划和推进工作。

这里要把两个数量分开：用户说了几轮话，模型内部执行了多少步。一次请求背后仍可能包含多次模型调用、文件操作和运行检查。对人来说省事，并不意味着系统只工作了一次，也不能仅凭交互轮次推算费用。

原文把能力提升归因于“基于自反馈的强化学习”。可以粗略理解为，训练过程利用反馈信号，改善模型处理任务时的行为选择。用“尝试完成任务、获得反馈、调整后续行为”来理解这条链，已经足够帮助阅读发布文。

至于反馈怎样产生、怎样核验、奖励如何设计，所提供文字没有披露；也不能把训练中的改进，理解为用户每次让模型修代码时，模型都会现场更新参数。

这项能力还需要执行环境配合。模型提出修改计划之后，要有程序实际操作文件、运行命令，再把结果交回模型。这就是 Harness 一类框架发挥作用的地方。模型和框架如何配合，会影响最终的开发体验。

因此，原文专门提到针对 DeepSeek Harness、腾讯 CodeBuddy、WorkBuddy 进行优化，并建议把 DeepSeek Harness 升级到 0.2.1-rc.1 及以上版本。使用这个框架的人，应该把适配版本作为体验更新的前提。V4.1-Flash-1017 是模型版本，0.2.1-rc.1 是框架版本，两者各管一部分。

DeepSWE 这一项现在能读到成绩（77.0，对照里最高），但发布文所说的性能／成本图同样没有提供。只有分数没有费用轴，就判断不出它落在那条曲线的什么位置，也推不出换到你自己的项目上要花多少钱。另外，这一行用的是 Mini-SWE-V2 框架，和你本地搭的执行环境不会自动一致。

这些项目展示值得拿来发现新的使用场景，但是否可交付，还需要相应的验收。游戏要检查操作和逻辑，3D 展示要看精度与交互，实际项目还要考虑维护。这里更值得尝试的，是让模型承担一个边界清楚、能够运行检查的小项目，观察它在哪些环节需要人接手。

第三项变化，是搜索能力的开放，以及随之而来的工具费用。

发布文称，DeepSeek 开放了自研搜索的 Search 与 Fetch 接口。可以把两者理解为两个相连的动作：Search 帮助查找信息，Fetch 帮助读取指定网页内容。做开发时，先找官方文档，再读取相关页面，就是一个容易理解的场景。

它们的意义在于，模型执行任务时可以借助外部信息。发布文还介绍了搜索规模及对低质内容的过滤机制，这些属于发布方自述；结果是否可靠，仍要看具体来源与内容，不能仅凭索引规模判断。

对接 API 的开发者，更需要留意计费。按原文给出的价格，Search 和 Fetch 均为 5 元／千次，即各自每次 0.005 元。 假设一项任务调用八次 Search、十二次 Fetch，按该标准计算，工具调用费就是：

（8 + 12）× 0.005 元 = 0.10 元。

这只是计费示例，不包含模型 token 等其他费用。搜索一次后再抓取一个网页，是两项接口操作，需要分别计入调用次数。

原文还指出，在 DeepSeek Harness、Claude Code、Codex 中使用 DeepSeek API 时，已经会通过服务端工具调用访问 Search／Fetch。这部分此前未计费的接口调用，将在 北京时间 2026 年 11 月 1 日 00:00 开始按次收费。

这个范围要读准：此前未计费的是文中指定的 Search／Fetch 调用，不能理解成所有模型调用免费。为项目估算费用时，也要把生效日期之后的工具费用加入预算，实际规则以官方当期文档和账单为准。

这与前面“更省钱”的说法并不必然矛盾：模型生成费用可能减少，工具费用则单独计算。一个真实任务最后省了多少，要把两部分放进同一张账单里比较。

看完这些变化，我对这次小版本更新的判断是：它值得关注的地方，在于能否降低把一个任务做完的代价。代码能力、执行框架和搜索工具，都围绕这件事发生联系。

如果主要使用网页端或 APP，可以继续用熟悉的任务观察回答是否更贴合要求、等待是否缩短，无需因为版本名变化就额外配置开发框架。

如果用它辅助编程，可以选一个已有明确验收标准的小项目，先把相关框架升级到适配版本，再记录完成效果、人工接手次数和实际耗时。对“许愿式编程”的判断，应该落到这些结果上。

如果通过 API 接入，则需要同时检查模型调用、工具使用和账单。尤其是搜索较多的工作流，不能只比较生成文本用了多少 token。

版本名只增加了一个后缀，实际意义却可能体现在每天的等待和返工中。它是否值得切换，最终要看熟悉的工作能不能更顺利地完成。这也是阅读这份更新时，最值得保留的判断标准。