DeepSeek V4 Pro 0813 + Harness：前言初稿与 Agent 面试题
DeepSeek V4 Pro 0813 + Harness：前言初稿与 Agent 面试题
数据截止 2026 年 8 月 13 日。有两处数据存在版本冲突，已在第四节标出，发稿前务必确认。
一、先说标题
DeepSeek 员工：DeepSeek V4 Pro 正式发布，Harness 也进入最后一个内测版本（附Agent面试题）这条标题有个问题需要你确认：Harness 进入最后一个内测版本这件事，我在公开渠道查不到。
能查到的公开信息是，8 月初 Harness 启动内测招募，项目负责人在全球范围征集有 Agent Harness 经验的开发者，提交 GitHub ID 和代表作即可申请，这条帖子在社区里引发了大规模投递，你 8 月 6 日那篇写的就是这个。但从招募到最后一个内测版本，中间这段进展没有公开报道。
如果这句是你从内部渠道或者脉脉拿到的一手信息，那没问题，这正是员工系列的价值。如果是推测，建议改成有据可查的说法：
DeepSeek 员工：V4 Pro 正式版今晚发布，Harness 内测名额还在放，这波是真的要收网了（附Agent面试题）另外还有一个细节，DeepSeek 员工这个身份和后半句「Harness 进入最后一个内测版本」是匹配的，但和「V4 Pro 正式发布」不太匹配——正式发布是全网都知道的公开消息，不需要员工爆料。让员工说内部进度、让公开消息做背景，标题会更自洽。
二、前言初稿
按你的风格写的，图片位置我用占位标了出来，你替换成自己的图就行。
大家好，我是二哥呀。
昨天晚上刷 API 文档的时候看到了，DeepSeek-V4-Pro-0813 正式版上线了。
从 4 月 24 日 V4 Pro 预览版发布，到今天正式版落地，中间隔了将近四个月。这四个月里 DeepSeek 干了两件事，一件是 7 月 31 日先把 Flash 的正式版推了出来，另一件就是这次 Pro 正式版收尾。
我在 7 月 31 日那篇里写过，Flash 正式版只改了后训练，模型结构和尺寸一动没动，284B 总参数、13B 激活参数原封不动，Agent 基准却直接超过了激活参数是它四倍的 Pro 预览版。当时我的结论是，在 Agent 场景里，激活参数的边际收益比在问答场景里低得多，真正决定成败的是后训练教出来的行为模式。
现在 Pro 正式版来了，这个结论得补一句：后训练同样能把大模型的上限再抬一截。
官方给出的对比里，DeepSWE 相比预览版提升了近 50 个百分点，Cybergym 提升超过 30 个百分点，多项 Agent 评测已经接近 Fable 5 的水平。这个提升幅度放在同一个模型结构上，说明预览版并不是能力不行，是后训练还没做完。
配合的还有工程侧的补齐。这次 Pro 正式版原生支持 Responses API，也支持 Codex 接入，这是 7 月 31 日 Flash 正式版补上的那一块，现在 Pro 也补齐了。API 调用的模型名不变，还是 deepseek-v4-pro，你什么都不用改，重启一下就是新的。
定价这块也值得说一句。输入缓存命中每百万 tokens 0.025 元，缓存未命中 3 元，输出 6 元。之前业内一直在传 DeepSeek 要因为算力紧张涨价，从目前公布的价格看，这一刀暂时还没落下来。
顺带说一句，缓存命中和未命中之间是 120 倍的价差。这个数字对写 Agent 的人来说非常关键，你的提示词怎么组织、系统提示放不放在最前面、多轮之间要不要保持前缀稳定，直接决定了你的账单是 0.025 还是 3。这也是我后面第 6 道面试题要问的东西。
而比模型更让人期待的，其实是 Harness。
Model + Harness = Agent，这个公式我在上一篇里讲过。模型负责推理，Harness 负责模型之外的一切——工具调用、记忆管理、上下文控制、桌面集成、MCP 协议、Skills 体系。
国内几家大模型厂商基本都有了自己的 Harness，阿里的 Qoder、月之暗面的 Kimi Code、智谱的 Zcode，DeepSeek 是最后一个补上这块拼图的。而它补上的时机，正好是 Pro 正式版把 Agent 能力拉到接近第一梯队的时候。
模型和 Harness 一起到位，这才是这次发布真正的分量。
![](图片占位：Model + Harness = Agent 示意）
对我们做后端的人来说，这件事的信号很明确：Agent 工程化的能力，正在成为大厂招人的硬标准。模型是别人训的，但 Harness 这一层——上下文怎么压、工具怎么编排、记忆怎么持久化、失败怎么恢复、缓存怎么复用——是每个做工程的人都能上手、也躲不掉的东西。
所以今天这篇，我按着 Pro 和 Flash 的区别、正式版和预览版的区别、以及 Harness 这一层的核心设计，整理了 13 道面试题。
（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗发～）
前言到这里。上面这段大概 900 字，符合你一贯的节奏：先讲事实，再接上一篇的结论，再抛出这一篇要解决的问题。
如果你想更短，可以砍掉定价那两段，直接从 Harness 接过去，压到 600 字左右。
三、Agent 面试题（13 道）
按你要的三个方向来：Pro 与 Flash 的区别、正式版与预览版的区别、Harness 相关。
01、同一家的 Pro 和 Flash，你会怎么选？
答题要点：不要回答复杂任务用 Pro、简单任务用 Flash，这是废话。要按三个维度说。第一是任务的知识依赖度，需要大量世界知识和长链条推理的（架构设计、复杂算法、跨领域问题）用 Pro，主要靠读文件和工具返回来干活的（代码修改、日志排查、重构）Flash 往往够用，因为这类任务的信息来源是上下文不是模型内部。第二是延迟，激活参数差几倍，首 token 延迟和吞吐差异很明显，交互式场景对延迟敏感。第三是成本，Agent 是多轮循环，一个任务可能调几十次模型，单价差异会被放大几十倍。成熟的做法是混合路由，规划和难点决策走 Pro，执行和读取走 Flash。
02、Flash 只有 13B 激活，为什么在 Agent 基准上能超过 49B 激活的 Pro 预览版？
答题要点：因为 Agent 任务考的主要不是知识，是行为模式。一个 Agent 任务的循环是：判断该看哪些文件、调工具、从工具返回的一大堆内容里挑出有用的、判断信息够不够、不够继续、够了动手、改完跑测试、测试不过回上一步、过了才停。这一整套流程里需要世界知识的环节很少，真正决定成败的是工具选得对不对、参数填得全不全、能不能从噪声里挑出关键几行、失败后会不会换方式重试、以及知不知道什么时候该停。这些全是后训练教的行为模式，不是预训练存的知识。所以在 Agent 场景里，激活参数的边际收益比在问答场景里低得多。反过来说，一旦 Pro 也把后训练补齐，它的上限还是更高的，这次正式版就验证了这一点。
03、模型结构和尺寸都没变，只重做后训练，为什么基准能提升几十个百分点？
答题要点：先讲清预训练和后训练的分工。预训练决定模型知道多少，后训练决定模型会不会干活。后训练包括监督微调和强化学习，教的是收到任务先干什么、什么时候调工具、工具报错怎么办、什么情况可以宣布完成。Agent 基准测的恰好是这一套，所以后训练的改动能直接反映在分数上。提升幅度大还有一个原因：Agent 任务是多步的，每一步的成功率相乘才是最终成功率，单步从 90% 提到 95%，十步任务的成功率从 35% 提到 60%，翻倍不止。这个乘法效应是理解 Agent 基准大幅波动的关键。
04、预览版和正式版，在工程上应该怎么区别对待？
答题要点：核心区别是稳定性承诺。预览版的模型权重、行为模式、甚至接口都可能变，且通常不保证向后兼容；正式版会给出版本号锁定（比如 0813 这种日期后缀），承诺在一段时间内行为一致。工程上的做法是：预览版只用于评估和尝鲜，绝不进生产；生产环境必须把模型名锁到带日期的具体版本，而不是用会滚动更新的别名，否则某天上游静默更新，你的提示词和解析逻辑可能全部失效。另外预览版通常没有 SLA、限流更严、可能随时下线，做预算和容量规划时不能按它算。还有一点容易忽略：预览版到正式版的行为变化可能让你之前调好的提示词失效，切换时要重跑一遍自己的评测集。
05、上游模型静默更新，你怎么发现自己的 Agent 变差了？
答题要点：靠自建的回归评测集，这是唯一可靠的手段。评测集要包含几十到上百个真实任务，覆盖你的核心场景，每次上游有版本变动就跑一遍，比较成功率、平均步数、Token 消耗、工具调用失败率。除了离线评测，线上还要埋点：工具调用的成功率、任务的平均轮次、用户中途放弃率，这几个指标对模型行为变化很敏感。发现异常后要能快速回滚到上一个锁定版本，所以前提是你从一开始就用了带日期的模型名。补充一个实践细节：评测集要定期更新，否则模型厂商的优化方向和你的评测集重合久了，分数会虚高。
06、输入缓存命中和未命中之间有上百倍的价差，你的 Agent 怎么设计才能吃到这个红利？
答题要点：缓存通常按前缀匹配，所以核心原则是让请求的前缀尽可能稳定。具体做法有几条。系统提示词、工具定义、长期不变的项目上下文放在最前面，且顺序固定，不要每次动态排序工具列表。变化的部分（当前轮的用户输入、最新的工具返回）放在最后。多轮对话中不要在中间插入或修改历史消息，一旦中间变了，后面全部失效。上下文压缩要谨慎，压缩会改写历史，等于主动放弃缓存，所以压缩的时机要选在缓存收益已经很低的时候，而不是每轮都压。工具定义如果需要动态加载，要按稳定分层，常驻工具放前面，按需工具放后面。评估效果要看实际的缓存命中率，很多团队以为自己命中了，实际因为一个时间戳字段导致每次前缀都不同。
07、Model + Harness = Agent，Harness 到底负责哪些事？
答题要点：模型只负责一件事——给定上下文，输出下一步。除此之外全是 Harness 的活。具体包括：会话与上下文管理，决定每一轮把什么放进上下文、什么时候压缩、压缩成什么；工具层，工具的注册、描述生成、参数校验、执行、结果裁剪；记忆，跨会话的持久化和检索；权限与沙箱，限制文件访问范围、命令执行白名单；循环控制，什么时候继续、什么时候停、失败重试几次；可观测，每一步的日志、Token 统计、成本归因；集成层，MCP 协议、Skills 体系、编辑器和终端的对接。判断一个 Harness 好不好，不看它支持多少功能，看它在长任务上能不能不跑偏、能不能在失败后恢复、以及跑完之后你能不能看懂它干了什么。
08、Sub-agent 机制解决什么问题？什么时候不该用？
答题要点：解决的是上下文污染和职责混杂。主 Agent 在做一个长任务时，如果把搜索、读文件、跑测试的所有中间输出都堆进自己的上下文，很快就会被噪声淹没，且成本急剧上升。Sub-agent 的价值是把一个可以独立完成的子任务交出去，子 Agent 在自己的上下文里折腾，只把结论返回给主 Agent，主上下文保持干净。不该用的情况：子任务需要频繁和主任务交互（来回传递中间状态的成本超过收益）；子任务很短（启动开销不划算）；需要严格顺序且有共享状态（拆开反而容易不一致）。设计上要注意子 Agent 的返回必须是结构化的结论而不是原始过程，否则等于没隔离。
09、跨会话的记忆持久化，怎么设计才不会越用越差？
答题要点：最常见的失败是把所有历史都存下来，检索时召回一堆无关内容，反而干扰当前任务。正确的做法是分层加筛选。分层指区分项目级记忆（这个仓库的技术栈、约定、常见坑）、任务级记忆（当前这条任务线的进展）和用户级记忆（偏好、习惯）。筛选指不是所有对话都值得存，要提取出可复用的结论而不是流水账，比如「这个项目的测试要用 make test 而不是 npm test」值得存，「用户今天问了三个问题」不值得。还要有失效机制，代码变了、约定改了，旧记忆要能被覆盖或标记过期。检索时要控制注入量，宁可少给几条高相关的，不要为了全面塞满上下文。最后要给用户可见可编辑的入口，记忆错了得能改。
10、KV Cache 复用在 Harness 这一层可以怎么做？
答题要点：这题问的是工程实现而不是模型内部。Harness 能做的有几件事：请求前缀稳定化，前面第 6 题说的那一套；会话级的缓存复用，同一个会话的多轮请求共享前缀；跨会话的模板复用，不同用户但相同的系统提示和工具定义，前缀部分是可以共享的；预热，在用户开始交互前先发一个只含系统提示的请求把缓存建立起来。要注意的边界是缓存有有效期，长时间空闲后会失效，所以长会话中间的空档期可能导致后续请求成本突然升高，这个在成本监控里表现为无规律的尖刺。另外压缩上下文和复用缓存是天然冲突的，需要权衡：压缩省的是当轮的输入量，缓存省的是单价，要算清楚哪个更划算。
11、Skills 和 MCP 有什么区别？各自适合承载什么？
答题要点：MCP 是协议，解决的是怎么把外部能力标准化地接进来，关注点是接口、传输和权限，它给 Agent 提供的是可调用的工具。Skills 是知识和流程的封装，解决的是让模型知道在什么场景下该怎么做，它给 Agent 提供的是行为指引。区别的判断标准很简单：需要执行副作用、访问外部系统的，用 MCP 做成工具；只是告诉模型某类任务的正确做法、规范和步骤的，用 Skills。两者经常配合，一个 Skill 里可以指导模型该调哪些 MCP 工具、按什么顺序。设计上的常见错误是把大段流程说明硬塞进工具描述里，导致工具定义臃肿且每次请求都要传输，正确做法是工具描述保持精简，流程放 Skills 里按需加载。
12、Harness 怎么控制 Agent 的循环，避免它一直转下去？
答题要点：需要多重约束叠加。硬约束包括最大轮次、最大 Token 预算、最大墙钟时间，任何一个触顶就停，这是兜底。软约束更重要：检测无进展循环，比如连续几轮调用相同工具且参数相同、或者反复在两个状态之间横跳，这类情况要主动打断并换策略；检测无效重试，同一个工具连续失败超过阈值就不要再试，改为向上汇报。还要有明确的完成判据，很多 Agent 停不下来是因为任务本身没有可验证的完成条件，所以设计任务时就要给出验收标准（测试通过、文件存在、返回值符合预期）。最后要有人在回路的中断通道，用户随时能叫停，且叫停后状态可保存可续跑。
13、如果让你从零做一个终端 Agent，你的架构会怎么设计？
答题要点：这题是前面所有题的综合，适合放最后。可以按分层讲：最外层是交互层，负责终端渲染、流式输出、用户中断；中间是循环控制层，负责决定继续还是停止、什么时候压缩上下文、什么时候派生 Sub-agent；再往下是能力层，工具注册与执行、MCP 客户端、Skills 加载；底层是基础设施，模型客户端（要支持多家、支持版本锁定）、持久化（会话、记忆）、可观测（日志、Token 统计）。重点讲三个设计决策：一是执行模式，简单交互用 ReAct，复杂任务用先规划再执行，多角色协作用多 Agent，什么时候用哪种要有判据；二是上下文策略，压缩时机和缓存复用的权衡；三是安全边界，文件访问范围和命令白名单必须是确定性规则，不能交给模型判断。能把这三个决策的取舍讲清楚，比罗列技术栈有价值得多。
四、必须核实的两处数据冲突
这两处不同来源给的数字不一样，直接写进文章会出事，发稿前请以 DeepSeek 官方 API 文档为准。
第一处，V4 Pro 的参数规模。
一部分资料给出的是 1.6 万亿总参数、490 亿激活参数，采用 MoE 架构，混合注意力机制结合了压缩稀疏注意力和重压缩注意力。另一部分报道写的是 2840 亿总参数、130 亿激活参数——但这组数字和你 7 月 31 日那篇里写的 Flash 的规格完全一致，很可能是把 Flash 的参数错抄成了 Pro 的。
从你自己那篇的表述反推，你写的是 Flash 用 13B 激活超过了「激活参数大自己四倍的 Pro 预览版」，13B 的四倍正好是 49B，和第一组数字对得上。所以我倾向于 Pro 是 1.6T 总参数、49B 激活，但这个必须你去官方文档确认，因为整篇文章的第 2 题都建立在这个数字上。
第二处，最大输出长度。
一处写 375K，一处写 384K。上下文窗口两边都是 1M，没有分歧。
另外还有一条要注意：网上流传的那组 benchmark 分数（LiveCodeBench 93.50、SWE-bench Verified 80.60、CodeForces 3206、MMLU Pro 87.50、IMO-AnswerBench 89.80）标注的发布日期是 4 月 24 日，那是预览版的成绩，不是这次 0813 正式版的。如果要在文章里用，必须写清楚是哪个版本的数据，否则会和「正式版比预览版提升几十个百分点」的说法自相矛盾。
五、发布前核验清单
来源
- IT之家 DeepSeek V4 Pro 正式版 API 更新上线：https://www.ithome.com/0/989/000.htm
- 新浪财经 刚刚，DeepSeek V4 Pro 正式版发布：https://finance.sina.cn/2026-08-13/detail-ininavwz3327589.d.html
- EOGEE DeepSeek-V4-Pro-0813 正式发布：https://eogee.com/article/49
- DataLearner DeepSeek-V4-Pro 规格与基准：https://www.datalearner.com/ai-models/pretrained-models/deepseek-v4-pro
- IT之家 DeepSeek-V4-Flash 正式版 API 上线公测：https://www.ithome.com/0/984/116.htm
- 快科技 V4 Pro 正式版黄金搭档，DeepSeek 官方 AI 编程工具 Harness 内测：https://news.mydrivers.com/1/1140/1140784.htm
- 开源中国 DeepSeek Harness 宣布内测邀请：https://www.oschina.net/news/487110
- 腾讯新闻 DeepSeek 一条内测帖变成 Agent 开源大摸底：https://view.inews.qq.com/a/20260804A0BP5100
- DeepSeek API 文档：https://api-docs.deepseek.com/