DeepSeek Harness 2.0实测：原生图像、提示缓存与可控子代理

DeepSeek针对其V4.1 Flash模型（视频中称为YE Flash/V1 E-Flash）更新了配套编程框架Harness。这次升级并非简单在菜单里添加一个新模型，而是围绕原生图像输入、提示缓存处理、文件工作流和子代理控制等多个维度展开。截至视频拍摄的9月10日，最新版本为0.1.5-rc1候选发布版，仍属于开发者预览阶段。本文基于B站UP主的实测演示，梳理这次更新的核心变化与真实体验。

框架的定位：模型之外的那层软件

要理解这次升级的意义，先要搞清楚"框架"是什么。模型负责做决策，而框架是模型周边的软件层——它决定模型能调用哪些工具、文件如何被编辑、对话如何延续，以及多个智能体之间如何通信。简单说，模型给出判断，框架把这些判断转化为你电脑上的实际操作。

DeepSeek^广告的这套框架基于MIT许可证开源，设计上把各项能力都做成了插件。开发者可以替换系统的某个组件——包括模型连接、工具、存储甚至界面——而无需重建整个应用。这种模块化思路让框架既能快速集成新模型，也便于社区扩展。

值得关注的一点是，模型训练与框架之间存在真实联系。根据DeepSeek发布的技术报告，其强化学习训练跨越了多个框架环境，包括自有的开源代码路径以及各版本的Claude Code，而非专门针对单一应用优化。在DeepSeek给出的对比中，使用相同检查点并以最大努力运行时，其最小框架在测试中得分72.6，而开源代码得分为65.5。这组数据说明了"周边软件"为何重要——不过UP主也明确指出，这些是官方发布的研究结果，并非他对当前候选版本的实测数据。

强化学习（RL）训练跨框架环境这一细节值得展开说明。传统上，代码智能体的训练往往在单一、固定的工具环境中进行，这导致模型对特定框架的API和工具调用方式产生过拟合，换到其他框架时性能会明显下降。DeepSeek的做法是让模型在多种框架环境中交替接受训练——包括自有开源路径和Claude Code的不同版本——目的是让模型学到更泛化的"如何使用工具完成任务"的能力，而非记忆某个框架的具体调用格式。这也是为什么同一个模型检查点配合不同框架会产生不同分数：框架的工具设计、上下文组织方式和错误处理逻辑，会直接影响模型能否把自身推理能力转化为正确的操作序列。

提示缓存：长任务中的成本优化

这次更新中最有意思的改进之一是缓存处理机制。在长时间运行的任务里，框架有时需要更改其系统指令。以往，改动对话开头可能导致模型无法复用其后的缓存历史，意味着整段上下文要重新计算。

现在，Flash配合框架可以在现有历史之后追加更新后的系统指令。模型会采用最新的系统消息，而较早的对话仍可复用缓存。当智能体在长任务中携带大量上下文时，这项改进对效率和成本都有实际帮助。

需要注意的是，这并不意味着每个请求都会命中缓存——更改工具或较早请求的其他部分仍可能影响复用。但在指令变化时还能保持长对话的可复用性，确实是一项务实的改进。实测数据显示，累计输入缓存命中率在修复任务中约为92.5%，网页任务中约为97.8%。不过UP主提醒，这些数字反映的是重复发送上下文的请求，并不直接等同于最终账单节省的百分比。

提示缓存（Prompt Caching）是大语言模型API中的一种计费优化机制。由于模型每次调用都需要对输入的所有Token进行前向计算，当多个请求共享相同的前缀内容（如系统指令、工具定义或长篇对话历史）时，重复计算会造成大量不必要的Token消耗和延迟。提示缓存允许API服务商将这部分共享前缀的计算结果存储在服务器端，后续命中相同前缀的请求可以直接复用，通常按较低费率（如原价的10%-20%）收费。关键约束在于：缓存以精确的Token序列匹配为前提——只要前缀中任何位置发生改变，缓存就会失效，从该改动位置起的所有Token都需要重新计算。这正是本次框架改进要解决的问题：把变化的系统指令追加到历史末尾，而非插入到中间，以尽量保留可复用的前缀长度。

原生图像输入：截图进入编码工作流

Flash通过官方适配器支持图像输入，这让截图真正进入了编码工作流。模型可以结合你的指令检查设计稿、错误对话框或图表——这是图像理解能力的体现。输出仍以文本、代码和工具操作的形式呈现。

UP主的第二个演示很好地展示了这一点：他上传了一个销售CSV和一张显示所需报告布局的图片，CSV提供数据，图片提供视觉方向，要求生成HTML报告和一份独立的计算说明。框架生成了index.html和calculations.md两个文件，页面自包含，总计正确（净收入165美元、净单位18个、产品3个），布局遵循了参考图，计算说明也解释了数字来源。整个网页流程不到6分钟完成，中途浏览器验证一度卡住但在结束前恢复——用他的话说，"有用的结果伴随着一些波折"。

文件工作流与侧边栏预览

文件处理环节也有明显改进。9月4日的更新增加了对任意文件类型的上传，带进度指示器和取消功能，上传进行时还能切换对话。上传的文件通过保存的路径供代理使用——这个区别很重要：上传电子表格或文档并不意味着模型能神奇地理解每种格式，代理需要用可用工具去读取和处理文件，而图像则走独立的视觉输入通道。

新的侧边栏让输出更易查看。你可以在应用内预览Markdown、代码、HTML、PDF和图片，还支持标签页、分屏和全屏，查看产出时能让对话保持可见。对编码任务来说，这意味着不用再翻文件夹找刚生成的页面或报告。不过UP主也发现了一个问题：Markdown和图片预览正常，但HTML预览在应用内浏览器中一直空白——同样的HTML在Chrome里能正常渲染。这是候选版本需要打磨的地方。

可控子代理与运行模式

另一项重大改进是对子智能体的控制。你可以排队另一条指令，在发送前编辑、删除它，或在智能体工作时引导方向。一旦队列消息开始发送，它会暂停控制直到本次发送完成。当任务进行到一半发生变化时，这种能力很实用——比如一个智能体处理界面、另一个调查bug，你能单独纠正某个智能体的方向，而不必等所有事情都完成。

框架还提供可安装的"智能体团队包"，但这些仍是实验性的，需要显式启用。UP主强调，更多智能体意味着更多API请求，并行工作是否值得额外消耗仍需验证。

可用模式方面：标准模式提供常规编码工具；创建模式支持检查运行时并组合自定义智能体配置。解模式在当前版本中默认提供一个持久化Shell，而独立的文件编辑器变成了需手动启用的选项。由于部分旧说明仍提到两个默认工具，配置时建议以当前版本的发布说明为准。

子智能体（Sub-agent）架构是指在一个主协调智能体之下，同时运行多个专职智能体分别处理不同子任务的设计模式。与单一智能体顺序执行所有步骤相比，多智能体并行可以缩短总体完成时间，但代价是每个并行分支都会独立消耗API调用和Token配额。在实践中，"智能体团队"的真实收益取决于任务的可并行程度：如果子任务之间存在强依赖（如A的输出是B的输入），并行带来的好处很有限；若子任务相互独立（如同时处理前端界面和后端逻辑），并行才能显著提速。此外，多个智能体同时运行还会增加协调复杂度——主智能体需要合并各子智能体的结果并处理冲突，这本身也是额外的开销。因此框架将智能体团队包设计为需要显式启用的实验性功能，而非默认开启，是比较谨慎的做法。

可靠性改进与升级注意事项

底层还有一些实用的稳定性修复。一个流式修复能在后续响应块包含空字段时保留工具调用的名称和标识符——没有这个处理，一个本来有效的请求可能变成失败的工具调用，或留下无法重新打开的对话。近期更新还解决了断线重连问题，并减少了打开或继续长对话时的界面卡顿。

界面现在把统计数据分组为轮次、速度摘要以及详细的Token用量和消费，这些是判断实际运行表现时该看的数字。UP主根据两次演示的客户端观测估算：编码修复平均每秒约242个Token，网页任务约269个，加权平均约262个（含推理Token）；若再加上每次模型请求的等待时间，综合速率约每秒136个Token。他特别声明这些仅为两次运行的客户端数据，不能据此断定相对其他框架有普遍速度优势。

现有用户需注意一个迁移细节：日志（绘画）格式升级到了版本3，受支持的旧日志会迁移到新文件，原始文件保留但旧版应用无法读取升级后的记录。插件作者也需应对API变更。

小结

对于"Claude Code谁？"这个略带调侃的标题，更务实的答案是：DeepSeek Harness的价值在于拥有一个开源应用，能利用Flash的特定能力，同时让生成的工作成果更易检查。你仍然需要为模型使用付费——最大思考、重复工具调用和多智能体都会推高费用，而可复用上下文有助于降低输入成本。

在两次演示中，框架修复了计算逻辑并生成了数字正确的报告，对一个候选版本来说是不错的开端。UP主也坦言，在更广泛比较之前，还需要在更大的项目上继续测试。安装该版本需要受支持的Node环境（22.1、19以上或24级以上），通过官方NPM包安装后运行Web界面即可配置官方Provider、填入API密钥并选择工作区。