DeepSeek-V4-Flash 公测：后训练如何把 Agent 能力推上一个台阶

DeepSeek-V4-Flash 正式版现已上线 API 公测。它的变化并不在模型结构或参数规模：仍然是 MoE 284B、激活参数 13B，并支持约 100 万 token 的上下文窗口。真正发生变化的是后训练，而这次调整直接反映在 Agent 任务表现上。

根据来源信息，正式版在九项 Agent 基准测试中全部超过了 DeepSeek 自家 4 月发布的 Pro Preview。Terminal Bench 2.1 从 61.8 提升到 82.7，DeepSWE 从 7.3 提升到 54.4。这样的涨幅说明，Agent 能力并不只取决于基础模型规模，工具调用、任务拆解、错误恢复和长流程执行同样需要针对性训练。

模型没有变，使用方式正在变

这次发布最值得关注的地方，是“参数规模不变但 Agent 结果明显提升”。对于开发者来说，这意味着升级模型时不一定需要重新设计整个系统，也不应只用参数量或上下文长度判断模型是否适合 Agent 工作流。

后训练可能改善多个实际环节：

• 更准确地理解工具描述和调用约束；
• 更稳定地拆解多步骤任务；
• 在命令执行失败后重新规划，而不是重复同一个错误；
• 在长上下文中保留任务目标、文件状态和中间结果；
• 生成更适合终端、代码仓库和自动化环境的操作序列。

这些能力会直接影响 Agent 的完成率。一个模型即使能写出不错的单段代码，如果不会检查执行结果、读取错误信息并继续修复，放进真实开发环境后仍然可能频繁中断。

基准测试的信号：从“会回答”到“能完成”

Terminal Bench 2.1 的分数从 61.8 上升到 82.7，说明终端环境中的综合任务执行能力有明显改善。终端任务通常要求模型浏览目录、修改文件、运行测试、分析输出，并根据反馈继续行动，单次生成质量只是其中一部分。

DeepSWE 从 7.3 提升到 54.4，则显示软件工程类 Agent 的收益更加突出。软件工程任务往往具有较长的反馈链条：模型需要定位问题、理解现有代码、选择修改位置、运行验证命令，并处理测试失败。后训练如果能让模型更好地利用这些反馈，最终分数可能会出现大幅变化。

不过，基准测试不能替代应用内评估。不同项目的代码规模、依赖安装方式、权限模型、测试覆盖率和失败成本都不同。接入正式版前，建议使用自己的任务集记录以下指标：

• 一次完成率；
• 工具调用成功率；
• 平均任务步数；
• 重复错误比例；
• 最终修改通过测试的比例；
• 单个任务的 token 和 API 成本。

一个可直接改造的 API 调用示例

下面的示例假设官方 API 使用 OpenAI 兼容接口。请将 DEEPSEEK_API_KEY 设置为你的 API 密钥，并根据控制台实际提供的模型名替换 model 字段。示例让模型读取一个任务说明，并通过工具获取项目状态；真实系统中还需要由你的程序执行工具并把结果回传给模型。

export DEEPSEEK_API_KEY="your-api-key"

curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {
        "role": "system",
        "content": "你是软件工程 Agent。先检查项目状态，再提出最小修改，并在修改后运行相关测试。"
      },
      {
        "role": "user",
        "content": "检查当前项目的测试失败原因，并给出修复方案。"
      }
    ],
    "tools": [
      {
        "type": "function",
        "function": {
          "name": "get_project_status",
          "description": "获取当前项目的文件变更、依赖和测试状态",
          "parameters": {
            "type": "object",
            "properties": {},
            "additionalProperties": false
          }
        }
      }
    ],
    "tool_choice": "auto",
    "temperature": 0.2
  }'

生产环境不要只把模型输出直接交给 Shell。更稳妥的流程是：限制工作目录，校验工具参数，记录每次调用，并对高风险命令增加人工确认。例如，删除文件、修改生产配置、推送代码和执行网络请求，都应该通过权限层或审批层控制。

如果需要在 Python 服务中接入，可以保留相同的消息和工具协议，再增加超时、重试与日志：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {
            "role": "system",
            "content": "你是一个谨慎的软件工程 Agent。每次修改后都要说明验证方式。",
        },
        {
            "role": "user",
            "content": "分析当前任务，先列出需要检查的项目状态。",
        },
    ],
    temperature=0.2,
    timeout=60,
)

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

模型名、API 路径和工具调用字段应以正式 API 文档为准；上面的代码展示的是可改造的 OpenAI 兼容调用形态。

上线前的工程检查

V4-Flash 的 Agent 基准提升适合拿来验证复杂自动化任务，但不要把“基准分数提升”直接等同于“所有任务都更可靠”。建议按渐进方式接入：

1. 先用离线任务集对比旧模型和新模型，固定提示词、工具集合和执行环境。
2. 对工具调用、文件修改和命令执行建立审计日志。
3. 为长任务设置最大步数、单次调用预算和全局超时。
4. 让模型在每个关键阶段输出结构化状态，而不是只返回自然语言总结。
5. 对通过测试的修改做人工抽样，检查是否引入隐藏回归。
6. 逐步扩大到真实流量，并持续监控完成率、成本和失败类型。

这次发布传递出的重要信号是：Agent 能力可以通过后训练获得大幅改善，模型升级评估也应从“回答是否正确”扩展到“任务是否完成”。对于终端操作、代码修复和长上下文工作流，V4-Flash 值得进入开发者自己的对比测试，但生产采用仍应建立在权限隔离、可观测性和可回滚机制之上。