过去半年，智能体的工程讨论重心正在从「提示词怎么写」转向「运行时怎么设计」。9 月 10 日，DeepSeek 发布 Harness v0.1.5，同日正式发布 V4.1 Flash 模型（据公开信息为 552B 参数的 MoE 架构，原生支持多模态视觉理解）。这版更新最值得技术团队关注的地方，不是新增了几个界面功能，而是模型与 Harness 之间出现了训练级的耦合。
先说 Harness 是什么
Harness 在智能体语境里指的是「模型之外、业务之内」的运行框架：它负责组织上下文、调度工具、管理循环、处理异常，并决定模型在每一步看到什么、能做什么。同一个模型放进不同的 Harness，实际表现可能差别很大——这也是为什么近一年「harness 工程」会成为独立话题。
据公开描述，v0.1.5 与 V4.1 Flash 模型的训练深度结合，模型针对 Harness 的三种运行模式做了专项训练与优化。这三套模式分别面向不同的任务形态：标准模式面向通用的多步任务；程序化工具调用（PTC）模式面向需要结构化调用外部能力的场景；极简模式面向延迟敏感或任务简单的场景。同时，新版 Harness 增加了文件上传与侧边栏文件预览，并优化了界面性能与交互。
三种模式的意义：把「形态选择」从提示词搬到框架里
在早期的实践中，切换任务形态往往靠提示词里的几句说明——「请一步一步思考」「请直接调用工具」「请简短回答」。这种做法的问题是可预期性差：同一段提示词，在不同模型、不同上下文长度下的效果并不稳定。
把形态做成模型被专项训练过的运行模式，等于把这种「软切换」变成了「硬接口」。对工程团队而言，收益有三点：其一，模式切换的边界更清晰，团队可以在框架层决定何时用哪套模式，而不是把判断留给模型；其二，模式既然经过专项训练，行为的一致性会好于纯提示词引导；其三，多模式并存让「用合适的成本做合适的事」成为可配置项——简单任务走极简模式，复杂任务才进入完整循环。
对 PTC（程序化工具调用）模式需要多说一句。工具调用是智能体最容易出问题的环节：参数格式错误、调用顺序颠倒、返回值被误读，都会让任务在中间失败。把程序化调用单独训练成一种模式，本质上是在承认「工具调用是一个独立的能力项」，而不是语言生成的自然延伸。这个判断与业界近来的共识一致——工具调用的可靠性，往往比模型的推理能力更能决定智能体的实际可用性。
「保留 KV Cache 更新系统提示词」为什么是个硬需求
这版更新里技术含量最高的一条，是支持在保留已有 KV Cache 的情况下更新系统提示词。要理解它的价值，需要先理解 KV Cache 的机制：在自回归生成中，模型会把已处理 token 的键值缓存下来以复用计算，从而避免每次重新处理整段上下文。缓存一旦建立，改变前面的内容通常会导致缓存失效，需要重新计算。
而系统提示词恰恰位于上下文的最前面。在智能体场景里，系统提示词又是最需要频繁更新的部分——权限范围变了要改、可用工具变了要改、当前任务阶段变了也要改。如果每次修改都导致整段缓存失效，代价会非常直接：延迟上升、算力浪费，长上下文任务的经济性显著变差。
允许在保留缓存的前提下更新系统提示词，等于给智能体运行时开了一条低成本的状态更新通道。它的意义不在于「省了一点算力」，而在于让「频繁调整运行约束」变得可行——这是长时任务、多阶段任务能够稳定运行的前提之一。对成本敏感的生产环境来说，这类优化带来的收益往往比模型参数提升更直接。
把它放进行业脉络里看
这并非孤立动作。此前该系列已把 Harness 开源，本次 v0.1.5 则进一步把模型与 Harness 做联合训练。这条路径与业界另一个方向形成了对照：一边是让模型尽量通用，靠外部框架适配；另一边是让模型针对特定运行时形态做专项优化，换取更高的可靠性与更低的单位成本。前者灵活，后者高效，实际选择取决于团队对确定性的需求程度。
需要指出的是，本轮的更新建立在既有开源版本之上，其模型侧能力（V4.1 Flash 的多模态与参数规模）此前已有公开信息，本轮的增量主要在运行时的适配与效率上。
中立思辨
保持中立地说，这组改动也有需要观察的地方。其一，模型针对特定 Harness 形态做专项训练，会带来一定程度的绑定效应——在自有框架上表现良好的模式，迁移到其他运行时未必同样有效，团队在选择时需要权衡效率与可移植性。其二，三种模式的划分是否覆盖了真实任务分布，取决于任务形态的实际分布情况；边界任务（既不算简单也不够复杂）的归属策略，往往比模式本身更影响体验。其三，「保留缓存更新系统提示词」在长上下文下的稳定性、以及对不同推理后端与部署形态的支持范围，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。其四，模型能力与运行时效率的提升，都不能替代权限与安全边界的设计——系统提示词能低成本更新，也意味着它更容易被误改，变更管理与审计同样重要。
趋势研判
短期，围绕缓存复用、上下文压缩与工具调用可靠性的优化，会成为智能体工程竞争的主战场，因为这些指标直接决定单位任务成本；中期，模型与运行时联合训练可能成为一种常规做法，「通用模型 + 通用框架」的组合会被「针对特定运行时优化的模型」部分替代；长期，智能体的性能评价会从「单次回答质量」转向「单位成本下的任务完成率」，而这恰恰需要模型侧与框架侧协同设计才能优化。
对开发团队的务实建议是：先量化自己的任务分布，再决定是否需要多模式；在接入任何运行时优化前，先把单位任务的 token 消耗与延迟做成可观测指标，否则无法判断优化是否真的生效；同时保留一条「不依赖特定运行时优化」的降级路径，以免在框架迭代时被动。工程上的效率，永远建立在可测量之上。