DeepSeek V4.1 Flash 深度拆解：552B 新架构、缓存成本大降与 Agent Teams 实操全指南

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

2026 年 9 月 10 日，DeepSeek 正式发布 V4.1 Flash：552B 参数的 MoE 模型，采用全新的 Causal-Encoder-Decoder 非对称架构，读输入时只激活 8B 参数、写输出时激活 16B 参数；KV 缓存占用降至上一代 Flash 的四分之一，峰谷定价后空闲时段缓存命中输入低至每百万 token 两分钱；模型权重与完整技术报告同步以 MIT 许可开源，DeepSeek Harness v0.1.5 深度适配并上线实验性的 Agent Teams 多智能体协作。更关键的是，官方宣布 9 月 14 日 12:00 之后，V4 Pro 的 API 请求全部路由到 V4.1 Flash 计费——这意味着 Flash 这一档正式从"轻量备选"变成了"主力干活"的角色。

如果你只想知道结论：这是一次"换基座 + 换计价方式 + 换工作流入口"的三连更新，对正在用 API 写代码、跑 Agent 任务、做多模态内容处理的人影响最直接。本文会从架构原理一路讲到 API 接入、Harness 上手、多智能体协作与本地部署门槛，能落地的部分我都尽量给到可复制的代码和步骤。

想看完整拆解，往下翻。

我大概是在 9 月 8 日前后注意到 V4.1 Flash 内测消息的。当时内测模型名里带着 expires-on-0910 这样的字样，社区里讨论最集中的问题就一个：V4 Pro 才上线不到一个月，Flash 这档到底想干什么？

等到 9 月 10 日正式发布，答案摊开在官方公告和技术报告里。我把发布信息、官方 API 文档更新日志、技术报告阅读笔记，加上自己这两天用 API 和 Harness 跑的一些任务整理下来，形成这篇长文。和单纯转发发布稿不同，我更想回答三类问题：这次架构改动的原理到底在哪；对普通开发者的接口调用和成本投入有什么直接影响；手上真实的工作流该不该切过去、怎么切。

先把这次发布在整个 V4 系列里的位置理清楚。

一、发布坐标：为什么说这次是换了基座的一代

先把这次发布的几个硬信息摆出来。DeepSeek V4.1 Flash 总参数 552B，是混合专家（MoE）结构，把它归入"全新模型结构系列"，并且明确说这是该系列里尺寸最小的一款。它支持多达一百万 token 的上下文，原生支持图片输入，模型权重同步开放。这三条单独看都不算爆炸性，但合在一起，再叠加官方的两个动作，性质就不一样了。

那两个动作是：第一，V4.1 Flash 直接接替旧 Flash 的位置，旧的 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 两个模型名暂时都会被路由到新模型；第二，官方计划有序下线 V4 Pro——从 9 月 14 日 12:00 之后，直到未来 V4.1 Pro 上线之前，所有发往 deepseek-v4-pro 的请求都会自动转发给 V4.1 Flash，并按 Flash 的单价计费。

一个被官方定位成"最小尺寸"的模型，要去接住此前旗舰 Pro 的全部 API 流量。这个安排本身就说明了很多问题。

把时间线拉直之后，能看得更清楚：

从表里能看出一个节奏：4 月到 8 月，DeepSeek 是在同一套基座上反复打磨，7 月底那次 Flash 正式版甚至明确说明"架构和规模没变，只重做后训练"；而到了 9 月这次，官方口径变成了"新的预训练方式"——言下之意，V4.1 Flash 不是 V4 Flash 的补丁，而是一个从头训练的新底座。

这一点很重要，我展开说说。判断一次模型更新是"小版本迭代"还是"换基座"，有个很朴素的检验方法：看它和后训练（post-training）的关系。V4-Flash-0731 那次升级（0731 是社区按日期惯用的叫法，官方更新日志里这次升级对应的是 2026 年 7 月 31 日的 V4-Flash 条目，正式模型名仍是 deepseek-v4-flash），官方讲得很清楚，模型结构、尺寸和预览版保持一致，重新做的只是后训练，也就是在同一个底座上重新教它"怎么回答问题、怎么调工具"。这种升级成本低、见效快，但能力的天花板基本被底座锁死了。

V4.1 Flash 走的是另一条路：先是新架构（Causal-Encoder-Decoder，后文细讲），再是新的预训练方式，然后才是更大规模的强化学习后训练。三层全换。所以官方敢在公告里写"在多项基准测试中超过包括 V4 Pro 在内的一众旗舰模型"——超越的底气不是提示词工程，是新底座本身的能力密度变了。

三个关键词，提前认识这位新选手

为了后面几章讨论方便，我先把这次更新最核心的三个变化浓缩成三个词，后面会逐一拆开：

1. 非对称：V4.1 Flash 读输入和写输出时"用脑量"不同：处理输入阶段每个 token 只激活约 8B 参数，生成阶段激活约 16B 参数。一个 552B 总参数的模型，干活时只动用百分之一到百分之三的算力，这是 MoE 稀疏激活配合新架构的结果。
2. 瘦缓存：模型处理过的上下文会以 KV 缓存的形式保留下来，供后续生成复用。新一代模型的全局 KV 缓存约为上一代 Flash 的四分之一，持久化存储约为八分之一。如果把参照系一路拉到初代模型，缓存规模累计压缩了约 437 倍——这里的 437 倍是"新一代相对初代"的口径，和上文"相对上一代 V4 Flash 的 1/4"是两个不同的对比对象，说的是同一套机制在不同时间尺度上的累积效果，别混着读。对动辄跑几十轮的 Agent 任务来说，缓存账单本身就是从这里省出来的。
3. 原生多模态：这次图片理解能力是长在基础模型里的，不是外挂一个视觉模块。之前的 Vision Exp 是在文本模型旁边补视觉能力，这次是新预训练阶段就"图文一起学"。

我在源码七号站写东西这段时间，一个很深的感受是：看模型发布会，最容易犯的错是盯着跑分看高低，忽略了跑分背后"成本结构"和"工作流接口"的变化。V4.1 Flash 这次真正有意思的地方，恰恰在后两者，而这两样东西的根，都埋在架构里。

二、CED 非对称架构拆解：读得快与写得稳为什么必须分开

要理解这次的架构改动，得先理解一个 Agent 任务在模型内部到底是什么样子。

大家平时用聊天框，体感是"我问一句、它答一句"。但真正吃算力的场景是让模型持续干活：读需求、翻文件、跑命令、看结果、再调整。这一圈下来，模型每一轮要消化的输入越滚越大，最后交付可能就几个文件，中间却处理了几十万 token 的上下文。

这里涉及两个性质完全不同的计算阶段：

• Prefill（预填充）阶段：模型把这一轮的输入（系统提示词、历史对话、工具返回结果等）一次性读进去，建立内部表示。这个阶段的特点是输入量大、可以分块并行处理，对吞吐量敏感。
• Decode（解码）阶段：模型一个 token 一个 token 往外生成内容。这个阶段每个新 token 都要参考前面所有内容，显存访问密集，对延迟敏感。

传统 Transformer 的做法是"一套人马干两种活"——读和写用同样的参数结构。问题在于：读的时候其实不需要模型那么"聪明"，它主要是在理解和索引信息，8B 参数级别的计算容量已经能扛住；而写的时候，输出质量直接决定任务成败，这里才值得堆算力。

V4.1 Flash 的解法就是把这两件事拆开。官方叫它 Causal-Encoder-Decoder（因果编码器—解码器，简称 CED） 结构。具体到层数，技术报告给出的分配是把原本 40 层 Transformer 拆成 20 层因果编码器加 20 层解码器：前一半专职读输入、建表示，后一半专职生成输出，所谓"读写分离"在网络结构上被切成了实打实的两截，而不只是在计算分配上做区分。

编码器为什么是"因果"的

做 NLP 的人听到 Encoder-Decoder 可能会条件反射想到翻译模型那套老架构，先别急。传统 Encoder 一般用双向注意力，能看到整段文本的全部位置；但 V4.1 Flash 的编码器是因果的，也就是每个位置只能看到自己之前的内容——和生成式模型的自回归逻辑一致。

这个细节很关键。因果编码器意味着它仍然是一个"从左到右读"的结构，长文本进来可以流式处理、可以缓存中间状态，而不是像双向编码器那样必须等全文到齐才能开工。对百万级上下文来说，这决定了它能不能边读边存、读完就能用。

配合另一个发现看会更清楚。社区里有技术分析指出，V4.1 Flash 在长上下文处理上做了大量"共享"设计：跨层共享主 KV、索引器 Key 跨层共享、部分层连 Top-K 检索都可以直接复用上一层的候选集。说白了，上一代每层都要"重新扫描一遍百万 token 的历史"，这一代变成了"几层扫一次、层层复用结果"。扫描次数降下来，长上下文的计算量自然跟着降。

一组直观的数字：8B 与 16B

官方给的两组数字最能说明这套设计的取向：

• 读输入：每个 token 约激活 8B 参数；
• 写输出：每个 token 约激活 16B 参数。

对比上一代 V4 Flash 统一的约 13B 激活，很有意思：读的阶段更省了（13B 到 8B），写的阶段更贵了（13B 到 16B）。这不是拍脑袋，而是一个明确的取舍——把省下来的算力预算，加到了真正影响输出质量的环节上。

我画一张 Agent 任务循环的伪代码示意，帮大家看清这两个阶段在真实任务里各自的占比：

任务：修复一个项目里的分页 Bug

第 1 轮  [prefill: 8K tokens]  读系统提示 + 需求描述        → [decode: 0.5K] 规划步骤
第 2 轮  [prefill: 45K tokens] 读 6 个源码文件 + 检索结果    → [decode: 0.8K] 定位可疑函数
第 3 轮  [prefill: 80K tokens] 读报错日志 + 相关模块代码     → [decode: 1.2K] 输出修改方案
第 4 轮  [prefill: 120K tokens] 带上全部历史 + 用户补充说明  → [decode: 2K]   输出补丁 + 测试用例
……

观察：
- prefill 累计输入 >> decode 累计输出（常常是几十比一）
- 每一轮的输入里，绝大部分是"上一轮见过的内容"（前缀重复）
- 输入侧省 1 块钱的边际收益，远大于输出侧省 1 块钱

这张伪代码里藏着两个结论。第一，Agent 任务的重心在输入侧，输入侧的效率决定任务能不能跑得久、跑得便宜；第二，每轮新增的新信息其实很少，"重复读旧内容"才是常态。于是有了第二个核心改动——缓存。

KV 缓存：从四分之一到四百三十七分之一

模型读过的内容不是读完就扔。为了后续生成时不用重新计算，中间状态会以 KV 缓存（Key-Value Cache）的形式保留：一部分在高速显存（HBM）里伺候正在进行的任务，另一部分可以持久化到固态硬盘（SSD）上跨会话复用。

V4.1 Flash 在这块的压缩幅度是官方数字里最扎眼的：

表格里的 437 倍是"初代模型 → V4.1 Flash"的累计结果，官方口径和媒体转述时偶尔会省略参照系，读到这个数字时留意一下它对标的到底是哪一代——它不等于"比上一代 Flash 省了 437 倍"。

这些压缩是怎么做到的？这里要补上缓存侧的另一半拼图：CSA2（Compressed Sparse Attention 2，压缩稀疏注意力2）。它取代了 V4 时代 CSA 与 HCA 的混合注意力，是 V4.1 Flash 在注意力机制层面的核心改动。如果说 CED 是主干架构、解决的是"怎么算"，CSA2 就是缓存侧的配合设计、解决的是"怎么存"——两者合在一起，才是这次成本压缩的完整逻辑。

技术报告把 CSA2 的压缩拆成三个维度：条目大小、序列维度、层维度——前文说的"几层扫一次、层层复用结果"，就属于层维度上的动作：跨层复用全局 KV 和 Top-K 索引，让大多数层不必重算。

层维度到底怎么压：CSA2 给每层分配的三种模式

前面"几层扫一次"这句话说得太略了，这里把 CSA2 最核心的机制补上。技术报告披露，CSA2 会给网络中的每一层静态分配三种运行模式之一，不同层承担不同量级的活。这三种模式的命名和划分出自官方技术报告的架构章节，官方模型卡与开源仓库里的推理参考实现也有对应说明；想看一手材料的话，建议直接检索技术报告中 CSA2 一节核对，下面是我对该部分的整理：

1. Full（全量模式）：这一层通读全部上下文，重新计算并保存完整的 KV 缓存与索引，再从里面筛出 Top-K 的重点条目。它是真正"从头扫一遍"的那一层，能力最强、开销也最大。
2. Reindex（重索引模式）：不再自己存一份完整 KV，而是直接取用上层 Full 模式算好的完整 KV 缓存，但按自己的判断重新筛选关注位置——KV 复用，索引重选。
3. Reuse（复用模式）：连索引都省了，直接继承上层给出的 Top-K 结果开工，完全跳过索引计算这一段开销。

关键在于这三种模式是静态分配的：整个网络里只有极少数层跑在 Full 上，绝大多数层处于 Reindex 或 Reuse 状态。作为交叉核对的参考，社区里有技术解读把这套分配概括为"38 个具备全局注意力的层共用 4 组全局 KV"——这个数字来自第三方解读、不是官方原文口径，但可以用来对照技术报告里的层配置表（该表就在 CSA2 那一节）。上一代的 CSA+HCA 混合结构，每一层都要各自保留一套完整 KV 和索引，40 层就是 40 份副本，同一份上下文被反复存、反复扫；CSA2 把"扫描—索引"这件事摊到全网络只做少数几遍，重复存储和重复索引计算同时被削掉，这才是显存需求降到上一代四分之一的直接来源。

遇到超长上下文，这套机制还会再叠一层"分层稀疏索引器"：Full 模式扫完上下文后先把重点圈出来、构建一个浓缩的索引池，后面那些 Reindex 层只在这个小池子里做二次检索和打分。也就是说，上下文继续膨胀，检索环节面对的候选集规模并不跟着水涨船高。

把视角拉回压缩本身。压缩器和索引器也做了简化：去掉相邻压缩条目之间的重叠和绝对位置嵌入，索引器 K 改为从主 KV 条目投射得到，不再单独从隐藏状态压缩。精度侧再加一记重手：主 KV 缓存从 FP8 进一步压到 FP4 格式（具体量化方案以技术报告为准），对量化更敏感的滑动窗口缓存（SWA-KV）保留 FP8 兜底。跨层共享叠加 FP4 之后，全局 KV 降到约 890 bytes/token——按 100 万 token 粗算约 0.89 GB。前面那组"四分之一、八分之一、437 倍"的数字，正是 CED 与 CSA2 两套机制叠加出来的结果。

这组压缩数字带来的三层影响

怎么看这几组数字？我拆成三层来解读：

1. 对硬件成本：1/4 的显存占用意味着同卡能同时伺候更多请求，或者跑更长上下文——这对提供 API 服务的厂商是直接的产能提升。
2. 对单次任务成本：1/8 的持久缓存意味着跨会话的任务状态变"轻"了，恢复长任务更便宜。
3. 对计价方式：这才是最狠的一刀。API 计费里，输入 token 分"缓存命中"和"缓存未命中"两档价格，命中档便宜一个数量级。缓存越能压、命中越普遍，Agent 任务的账单就越往命中价那一档滑。

我做个简化账，感受一下量级（以下为假设示例，用官方空闲时段单价演示，实际以账单为准）：

假设一次长程 Agent 会话：
  累计输入 100 万 token，其中 95 万命中缓存、5 万未命中
  累计输出 5 万 token

空闲时段成本 ≈ 0.02 × 0.95 + 1 × 0.05 + 4 × 0.05
             ≈ 0.019 + 0.05 + 0.2
             ≈ 0.27 元

一个折腾了一百万 token 输入的活儿，账面上不到三毛。其中输出部分占了七成——这也印证了前面说的：新架构把算力从"读"挪到"写"，但计价体系里贵的仍然是"写"。所以设计的逻辑非常自洽：输入侧玩命压缩成本，输出侧保证质量，让长任务的费用曲线尽量平缓。

一代人的架构取向：省钱省在看不见的地方

我自己对这次架构改动的总结是：它不像参数翻倍那样有视觉冲击力，改的全是"看不见的地方"——读和写怎么分家、长历史怎么少扫几遍、缓存怎么往小里压。但这些恰恰是 Agent 时代最要命的工程问题。

模型聊天慢一拍没人计较，可一旦让它连续干活八小时、翻几百个文件、跑几十轮工具调用，输入侧的每一个百分点都会放大成账单上的真金白银。CED 这套非对称结构，本质上是把"长任务经济学"做进了架构里。

原理部分先讲到这里。非对称和瘦缓存构成了它“便宜”的底色，也让长任务的经济账彻底变了样。至于能力上限到底涨了多少，官方这次把基准测试的明细全部公开，数据本身就说明了取向。

三、能力全景：跑分、工具任务与原生多模态的真实水平

跑分这东西，我一向的态度是"看结构，不看绝对值"。同样一个 90 分，在不同评测里含义差着十万八千里，何况各家发布会挑的都是对自己有利的场子。但这次 DeepSeek 把明细放得很全，倒是值得逐项过一遍——因为从这些数字里，能读出新架构的"性格"。

先明确一下基准测试的参照系，把所有数据摊在一张表里（数据来自官方更新日志与发布公告，均为公布口径）：

先把几个评测的全称和作用说清楚，不熟悉的朋友可以照着看：

• Terminal-Bench：让模型在终端环境里真实敲命令完成任务，考的是"会不会用命令行干活"；
• DeepSWE：SWE 是软件工程（Software Engineering）的缩写，这类测试把模型丢进真实代码库，要求它理解项目、定位问题并完成修改；
• NL2Repo：自然语言到仓库，给一段需求描述，看模型能否在仓库级别完成实现；
• CyberGym / SEC-Bench Pro：安全方向的能力测试，涉及漏洞分析与修复场景；
• GPQA Diamond：研究生级别的硬核科学问答，考的是知识深度而不是记忆；
• Agents' Last Exam：一整套面向智能体的高难度综合任务集。

这张表里最值得咂摸的，是 DeepSWE 那一行：从 54.4 到 74.2，V4.1 Flash 比上一代 Flash 提高了 19.8 个百分点。同时，它也反超了 V4 Pro 的 62.7——比 Pro 高出 11.5 个百分点。官方口径里，这是"全面超越 Pro"最硬的一条证据。

我一直觉得"代码库级别的任务"是检验模型成色的最佳场景。原因很朴素：单轮问答可以靠知识检索撑场子，但改代码库不行——模型得看懂目录结构、顺着调用链找线索、考虑改动会不会破坏别的模块，最后还要让测试跑通。每一步都骗不了人。19.8 个百分点的提升意味着，同一个任务丢给上一代 Flash，五次里可能失败两三次；给 V4.1 Flash，成功率会上一个台阶。这种"台阶式"的变化在开发工作流里体感非常明显，因为失败一次的代价不只是重试——你要重新读一遍它改乱的代码。

再看多模态那几个数字。官方这次公布的视觉类评测里，有两类特别有意思：

Chartography 这项值得单独说。它考的不是"看图说话"，而是"看着图干活"：给一张图表，模型要能读出坐标轴、数据系列、异常点，然后调用工具去验证或计算，最后给出结论。这个能力落在真实工作上，对应的就是"把财报截图丢给它、让它顺手把趋势算出来"这类操作。

原生多模态：这次和前两次的视觉尝试不是一回事

熟悉 V4 系列的老读者可能有印象：8 月先来了个 Vision Exp 实验版，走的还是"给文本模型加装视觉模块"的路线；而 V4.1 Flash 官方用的是"原生多模态"的说法——图片理解从预训练阶段就跟文本一起学，视觉不是外挂。

这两种路线有什么区别？打个比方：外挂视觉像给一个只读过文字的人配了台相机，他得一边看照片一边翻译成文字思考；原生多模态则是从小图文一起看长大的人，看图和读字用的是同一套"语言"。落到任务里，前者的信息损耗发生在"图转文"这一步，后者的图像信息能直接参与推理。

具体能干什么，官方给出的场景包括：识别截图里的界面布局和文字、阅读项目文件结合代码工作、把图表数据纳入分析。配合 Harness 使用的话，工作流大概是这个样子（伪代码示意）：

[截图：某个报错弹窗] + [项目代码库] + [用户备注：修好它]

第 1 步  视觉理解：读出弹窗里的错误类型与堆栈线索
第 2 步  代码检索：定位相关模块
第 3 步  修改 + 运行测试
第 4 步  回归检查：把结果和原始截图里的现象对照

有一件事要提前说清楚，免得大家产生误会：V4.1 Flash 支持图片输入，但不支持图片生成。它是"能看图"，不是"能画图"。要做图像生成，还得配专门的生成模型。

上下文和输出长度：百万进、三十八万出

长上下文这块的参数是：一百万个 token 的输入上下文，最大输出 384K token。换算成中文大概是什么量级？一百万 token 约对应百万级汉字，一整套产品技术文档、一个中型代码库、一年的项目记录，理论上都能一次性装进去。

384K 的输出上限在同级模型里算是相当能打的配置。多数模型的输出上限在 8K 到 32K token 之间，输出一份几万字的完整报告得分七八次调用去拼，每次还要重复带上下文，费钱不说，拼接处还容易出现风格断裂。一次输出全稿的能力，把"长文档生成"这件事的工程复杂度直接砍掉了一大截。

我自己的使用体感是：输入上限决定"能喂多少料"，输出上限决定"能不能一次干完"。两个数字都比别人大一圈的时候，变化的不是参数表，是你能设计什么样的任务流。

数字看完了，还有一个绕不开的问题——贵不贵。跑分反超 Pro 只是能力层面的事，真正决定工作流能不能长期跑下去的，是计价方式。这方面这次调整的力度，说实话比模型本身更让我意外。

四、价格与接口：新定价怎么算、API 怎么接、任务怎么排

先把这次调价的账目摆清楚。北京时间 2026 年 9 月 10 日 12:00 起，Flash 系列执行新价格，改完之后的效果是：空闲时段的缓存命中输入回到每百万 token 两分钱，其余各项也跟着下调。

高峰时段的定义是北京时间 周一至周五的 09:00 到 12:00、14:00 到 18:00，其余所有时间都按空闲价计费。也就是说，工作日的午休时段、傍晚以后、整个夜间和周末，全都享受半价。

我算过一笔粗账：如果你的任务可以自由安排时间，把批量处理、代码审计、文档整理这类不着急的活儿放到晚上跑，账单直接对半砍。这个"把任务挪到空闲时段"的习惯，比绞尽脑汁优化提示词来得实在多了。

价格这种东西变动快，写稿时的数字到你读到的时候可能又有微调，最终以 DeepSeek 开放平台定价页面的实时数据为准，下面的成本演示只是按当前单价做的示例运算。

缓存命中：省钱的真正阀门

三档价格里，最值得研究的是"缓存命中输入"。这个概念用大白话讲并不复杂：模型处理过的内容，在服务端会留下计算痕迹；下一次请求如果开头部分和之前一模一样，服务端就不用重算，直接复用，这一段就按"命中价"收费。没被复用的部分按"未命中价"收费，也就是常说的全价。

对于聊天场景，这件事意义一般，因为每轮对话内容都在变。但对于 Agent 场景，它是命门。设想一个任务跑了三十轮，每轮都要把前面积累的几万字上下文重新带进去——这些内容绝大部分与上一轮完全相同，天然就是缓存命中的材料。命中价只要两分钱（0.02 元/百万 token），而未命中价是它的 50 倍。同一份上下文，走不走缓存，成本能差出几十倍。

再看一遍那张价格表，藏着一个明显的设计意图：命中价格的降幅（60%）远大于未命中（33%）和输出（11%）。官方在引导的用法很清楚——把长任务的上下文管理做好，让重复内容尽量命中缓存，你省下的钱比什么都多。

用纯文本式子感受一下两档价差（假设示例，实际以账单为准）：

同样处理 100 万 token 的重复上下文：

走缓存命中：0.02 × 1 = 0.02 元
未命中全价：1.00 × 1 = 1.00 元

价差：50 倍

还有一个细节值得提：V4.1 Flash 把持久化缓存压缩到了上一代的约八分之一。这使得长任务的状态更"轻"，无论是服务端跨会话恢复任务，还是开发者自己设计多天跨度的流水线，存储层面的负担都在变小。

接口怎么接：好消息是几乎不用改

对已经在用 DeepSeek API 的开发者，这次迁移的成本低到可以忽略——把模型名换掉就行。

# Python 示例：用 OpenAI 兼容 SDK 调用 V4.1 Flash
from openai import OpenAI

client = OpenAI(
    api_key="你的 API Key",          # 建议用环境变量管理，别硬编码
    base_url="https://api.deepseek.com"  # 沿用原有地址，不用改
)

resp = client.chat.completions.create(
    model="deepseek-flash",          # 关键变更：V4.1 Flash 的正式模型名
    messages=[
        {"role": "system", "content": "你是一个严谨的代码助手，回答前先核对事实。"},
        {"role": "user", "content": "把这段脚本里的重复逻辑抽成函数，并给出修改说明。"}
    ]
)

print(resp.choices[0].message.content)

习惯用命令行调试的朋友，可以直接用 curl 先跑通：

# 最小可用的调试请求
curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-flash",
    "messages": [
      {"role": "user", "content": "用三句话说明什么是 MoE 架构"}
    ]
  }'

图片输入怎么给？官方文档里图像理解的使用方式是标准的多模态消息格式，把图片内容跟文本放在同一条消息里即可（支持的图片格式包括 JPEG、PNG、GIF、WebP）。具体字段名建议直接照官方"图像理解"文档来写，我在这里就不猜参数了——各家 SDK 封装不一，照官方示例最稳。

迁移时有两个注意事项，记下来能少踩坑：

1. 旧模型名会自动路由：deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 这两个名字目前仍然可用，但请求实际由 V4.1 Flash 处理。如果你的旧代码里写的是这两个名字，行为上"悄悄升级"了，性能会变好，但也要留意输出风格的细微变化，跑过回归测试再全量切过去。
2. deepseek-v4-pro 将按 Flash 计价：9 月 14 日 12:00 之后，发往 Pro 的请求会转发给 V4.1 Flash 并按 Flash 单价计费，直到 V4.1 Pro 上线。换句话说，短期内你不用改代码也不会多花钱，但预期要调整——如果你依赖 Pro 某些独特的输出特性，建议在切换前用自有任务集做一次对照。

任务排期：把便宜落到日常

价格表是静态的，省钱是动态的。我自己梳理了一套排期思路，按任务急迫程度分三档：

• 随到随跑（高峰时段也值）：交互式编程助手、实时客服、需要立刻看结果的调试任务。这些场景人的时间比 token 值钱，别为了省几毛钱在那儿干等。
• 尽量挪到空闲时段：批量代码审查、文档批量生成、数据清洗流水线、模型的定期回归测试。这类任务晚几个小时拿到结果完全不影响事，安排在晚上和周末，成本直接减半。
• 深夜大批量跑：定时巡检、索引重建、离线评测这类纯机器任务，全部降到空闲时段不心疼。

如果你是在自己的产品里集成 API，第二、三档的逻辑可以产品化：在后台加一个"低优先级队列"，把非实时请求攒着，到空闲时段批量发。这件事在代码上就是一个调度器的事，但对长期运行的成本结构影响不小。

价格和接口讲完了，但省下来的每一分钱，都要建立在任务真能跑起来的前提上。账算得再漂亮，也替代不了工作流本身。

五、DeepSeek Harness 上手：从安装到跑通第一个任务

先解释一下 Harness 是个什么东西。用一句话说：它是 DeepSeek 官方给的 Agent 运行环境，让模型能接触文件、调用工具、根据执行结果继续调整，直到把任务做完。

这个词是"马具、挽具"的意思，在 AI 圈被用来指代模型外面那层"把能力用起来"的框架。同样的模型，配不同的框架，干活效果能差出好几条街。DeepSeek 这次的思路很有意思——不是让社区自己去折腾框架，而是官方下场做了 Harness，还让 V4.1 Flash 在训练阶段就和它深度绑定：官方明确说了，新模型针对 Harness 的标准模式、程序化工具调用（PTC）模式和极简模式都做了专项训练和优化。

这意味着什么？意味着模型"出厂"时就带着对自家工具的肌肉记忆。你把它接进 Harness，它的表现是训练时校准过的；你把它接进别的框架，虽然也能用，但那套配合是没练过的。这种"模型加环境"打包优化的路线，正在成为 Agent 时代的主流打法。

装起来：一行命令的事

Harness 发布在 npm 上，前提条件只有一个——机器上装了 Node.js（建议用当前的 LTS 版本）。装好 Node.js 之后，启动命令是：

# 启动 DeepSeek Harness 的 Web 界面
npx @deepseek-ai/dsh web

npx 会自动拉取最新的包并执行，Web 服务默认在本机起一个端口，浏览器打开就能看到操作界面。第一次启动要做两件事：

1. 在设置里填入 DeepSeek API Key（就是在开放平台申请的那个）；
2. 选择要用的模型和工作区目录——工作区很重要，Harness 的文件操作都限定在这个目录里，别一上来就指着系统盘根目录。

然后就能开任务了。整个过程没什么仪式感，这也是我做技术内容一直欣赏 DeepSeek 的地方：官方工具的安装流程始终轻，不搞一大堆前置配置。

需要提醒一句：Harness 目前仍处于开发者预览（Developer Preview）阶段，迭代很快，界面和命令细节可能随时变化。下面写的东西是我基于当前版本（v0.1.5）的整理，具体操作请以官方仓库的 README 和发布说明为准。

三种模式：干活方式决定效率

v0.1.5 里模型针对三种运行模式都做了专项训练，这是很多教程里没讲透的点。三种模式的区别在于"模型怎么调工具"：

PTC 这个模式值得多说两句。传统工具调用是一问一答式的：模型说"我要读这个文件"，框架读了给它，它再说"我要跑这条命令"。任务步骤一多，来回的通信开销就上去了。PTC 模式允许模型把多步工具操作写进一段程序里批量执行——比如"列出所有改了配置的模块、逐个打开、提取相关行"，模型直接编排好一次交给执行器，中间不用停。复杂任务上，这个模式的效率优势很直观。

极简模式则是官方评测基准里用的配置，如果你要自己做模型对比测试，用它等于站在官方的起跑线上，变量对齐。

v0.1.5 这批更新里最实用的几项

这版 Harness 的更新清单不短，我挑几个我认为最影响日常使用的：

文件上传与预览。Web 界面现在支持直接上传图片、PDF 等文件，模型通过文件工具按需读取。右侧栏可以浏览工作区文件树，Markdown、HTML、PDF、代码、图片都能直接预览，模型生成的文件也能直接查看或用系统默认应用打开。做过 Agent 工作流的人知道，这个改动有多舒服——以前文件交付是"黑洞"，模型说改了，你得切到终端自己找；现在生成物当场可见。

保留 KV 缓存更新系统提示词。这是个不起眼但很内行的优化。系统提示词（System Prompt）是所有请求的开头部分，传统上一改它，整个前缀缓存就失效了，后续请求全部按未命中价重算。新版支持在保留已有 KV 缓存的情况下更新系统提示词，等于改了提示词还不怎么影响账单。结合