过去，AI 的 Scaling 主要依赖模型参数和预训练数据的 Scaling。进入 Harness 专项训练阶段后，Agent 的 Scaling 重心正由模型参数与数据配比本身转向系统环境与反馈效率。这一变化主要体现在四方面：一是从 Scaling 模型参数转向提升围绕模型的 Harness 运行框架智能化水平；二是从增加原始 Token 计算量转向增大有效反馈算力（Effective Feedback Compute，简称 EFC）；三是从依赖静态数据转向规模化合成 Agent 任务与环境；四是验证（Verification）正成为一条独立的 Scaling 曲线。
引言
2026 年 8 月 13 日傍晚，DeepSeek 发布 V4-Pro 正式版。没过俩小时，其内部跑榜使用的 Agent 脚手架 DeepSeek Harness 公开开源，采用 MIT 协议，跑分配置一并放出。一个值得关注的信号由此出现：模型成绩与产生成绩的运行环境，被同时公开。
一个月后的 9 月 10 日，V4.1 Flash 与 Harness v0.1.5 同日发布。官方明确写道：
"新版本与 DeepSeek V4.1 Flash 模型训练深度结合，模型在 DeepSeek Harness 的不同配置中都进行了专项训练和优化。"
这些配置包括标准模式、程序化工具调用（Programmatic Tool Calling，简称 PTC）和极简模式。DeepSeek 一直将 Agent 概括为 "Agent = Model + Harness"：模型负责智能，Harness 负责理解环境、上下文、调用工具和持续运行。此次变化在于，模型优化开始显式考虑其实际运行的 Harness 环境，模型与 Harness 不再只是先训练、后适配。
AI 的 Scaling 重心转移：从模型参数与数据 → 系统与反馈效率
边界也需要说明：官方尚未披露训练数据、训练配方，以及三种模式具体采用的后训练方法，因此 "使用了哪些训练轨迹"、"具体提升多少" 目前无法确认。能够确认的是，Harness 环境已被纳入模型专项训练与优化。
DeepSeek Harness Trajectory 视图如下所示：
本文由此追问：当 "适应环境" 进入训练阶段，Agent 的 Scaling 对象发生了什么变化？
补充说明一点，社区已有初步复现 DeepSeek V4.1 Flash 训练的开源代码：https://github.com/NVIDIA-NeMo/Automodel/pull/3855
一、旧分工为什么失灵
理解 v0.1.5，关键不在于罗列新功能，而在于看清旧分工为何开始失效。
过去做 Agent，路径很清楚：模型团队先训练模型，Agent 团队再把它规模化部署，以便接入真实环境。工具调用不稳，就改工具定义；上下文过长，就加记忆和压缩；任务无法一次完成，就补工作流和子 Agents。模型先定型，Harness 再把它装配成一个能够持续工作 Agent 系统。
在模型能力有限的阶段，Harness 既是护栏，也是装配层：提供上下文、工具和文件系统，管理权限与会话，驱动执行 Agent Loop，让模型从 "会回答" 走向 "能完成任务 / 达成目标"。问题不在这套机制本身，而在于系统不断演化后，越来越多能力被塞进同一条主循环：上下文压缩、审批、沙箱、重试、完成检查、续跑、子任务分发、后台唤醒，以及针对不同界面、模型和部署方式的条件分支。结果是，每增加一项能力都可能改动主循环，而主循环一变，又容易牵动工具、会话、安全和恢复等环节。
模型较弱时，这些规则是必要护栏；模型变强后，矛盾开始反转。主循环对 "模型下一步该做什么" 预设得越多，新能力越可能被旧流程限制。
因此，Agent 表现不佳，也不能再简单归因于 "模型不够强"。模型可能并不熟悉现有工具和协议，Harness 提供给模型的信息、接口和动作方式，也可能并不合适。
前 OpenAI 研究与安全副总裁 Lilian Weng 在 2026 年 7 月的综述《Harness Engineering for Self-Improvement》中提出过相近判断：位于原始大模型与真实世界之间的部署系统层，其重要性超过模型本身的智能水平。她进一步推测，许多 Harness 能力最终会被模型吸收，但连接外部环境和工具的接口仍会保留。提示词工程就是一个先例：随着指令微调和推理能力提升，大量 Prompt 技巧逐渐失去价值，但对目标、约束、上下文和评测的明确规定并没有消失。
因此，真正的问题不是 "Harness 会不会过时"，而是 "哪些能力会被模型内化，哪些能力仍应留在环境中"。
v0.1.5 的专项训练声明，正触及这条边界：当训练开始把环境本身纳入考虑，模型与 Harness 的分工也开始重新划定。
二、三种模式，三种分工答案
官方所说的 "不同配置"，究竟指什么？能确认到什么程度？这一节只回答这两个问题。
DeepSeek V4.1 Flash 完整 Benchmark 表如下所示：
ToolRuntime 官方文档将工具呈现方式分为三类：native、ptc 和 both。native 模式下，模型直接看到当前工具的名称、说明和参数 Schema，再自行选择工具、填写参数；ptc 模式则只保留 run_code 入口，并根据当前工具动态生成 SDK，由模型用 TypeScript 或 Python 编排多步调用。两者的区别，不只是调用方式不同，而是模型面对的操作界面已经变了。
极简模式（Minimal Profile）进一步收缩运行时能力：工具面只保留两个固定工具------持久 Shell 和字符串替换编辑器 str_replace_editor。Web、settings、telemetry、上下文压缩、workspace instructions、skills、jobs、Sub-Agents 均不再直接提供。官方跑榜采用的正是这套配置。
三种模式，本质上是在回答同一个问题：哪些能力交给模型，哪些责任留给 Harness。
标准模式强调在丰富工具中稳定选择和填参；PTC 用程序承接多步编排，减少工具调用往返；极简模式则尽量撤去运行时辅助，检验模型独立完成任务的能力。它们并非彼此替代，而是三种不同的责任划分。
过去，这种适配主要发生在模型训练完成之后：开发者通过提示词、工具 Schema 和流程规则，让模型熟悉具体系统。可以理解为先招到一个能力足够强的人，再通过入职培训适应公司的工作方式。
v0.1.5 的声明表明，部分适配开始前移到训练阶段。但边界必须说清：官方没有披露训练数据和训练配方，因此不能据此推断 Harness 反馈被写入强化学习奖励，也不能延伸出更具体的训练机制。"专项训练和优化"目前只能理解为：模型针对特定 Harness 配置进行了专门训练和优化，具体方法未知。
第三方小样本测试提供了一个直观参照。雷峰网作者 Rhea 使用两道自造题，在模型不变、仅调整工具呈现方式的条件下进行对照。
多文件重构任务中，标准模式用 42 步完成，极简模式用 65 步，多约 55%；终端排障任务则为 20 步对 27 步，多约 35%。两道题中，极简模式都完成了任务，但在改动更密集的重构题上，成本高出 58%，累计缓存命中量达到标准模式的 2.4 倍。由于没有上下文压缩，65 步全部累积在同一条执行链上。
这说明一个很直接的问题：工具更少，不等于成本更低，有时只是用更多步骤换取更少的运行时能力。
PTC 相对标准模式也没有稳定优势。重构题中，PTC 的 Token 消耗高 22%、耗时高 34%；排障题中，却又节省 23% Token、缩短 38% 时间。仓库文档本身也明确保留了这一边界：Code Mode 并不承诺普遍减少 Token。
这些测试样本很小，且题目由测试者自行设计，只能说明不同模式会改变任务的步数、耗时和成本结构，不能证明哪一种模式普遍更优。官方目前也没有公布三种模式的系统对照。
但至少可以确认一点：模式不是外层包装，而是会实质改变模型工作方式和成本曲线的系统变量。
三、KV Cache：推理成本进入设计图纸
v0.1.5-alpha.1（GitHub Release，2026 年 9 月 8 日）有一项不起眼却很关键的更新：在模型明确支持的前提下，系统提示词可以动态更新，同时尽量保留已有 KV Cache。它直接揭示了 Agent Scaling 对象的变化 ------ 推理成本开始反向约束系统设计。
矛盾来自两端。长程 Agent 要求 Persona、提示词、工具集合和运行时上下文随任务变化；推理系统却偏好稳定前缀，因为前缀越稳定，已计算的注意力缓存越容易复用。前者要 "变"，后者要 "稳"，v0.1.5 做的正是在二者之间寻找平衡。
官方 System Prompt 文档对 "稳定" 定义得很严格：身份、Persona、变量、提示词片段及顺序均不变，前缀才可稳定复用。若模型不支持 systemPromptUpdate，非空系统提示词一旦变化，就需并入历史系统节点，缓存从首个变化 Token 起失效。工具 Schema 也是如此：渲染方式、可见工具或顺序变化，都会破坏后续前缀缓存。相比之下，只在历史末尾追加消息，对既有缓存影响最小。
这一原则已进入仓库规范。面向模型的包，其文档都需说明三件事："模型看到什么"、"Token 影响"、"KV Cache 影响"，并由脚本校验完整性。Rhea 的仓库统计显示，219 个包中有 215 个 README 都必须回答同一问题：该包会如何影响 KV Cache 的前缀稳定性。
出厂配置更能说明问题。plan 模式只允许规划，通常可以直接移除具有写操作的工具，但系统仍保留这些工具，并在提示词中明确说明原因：for request-cache stability。也就是说，宁可承担误调用禁用工具的风险，也尽量保持请求结构不变。类似设计还有：工具结果超过 8,192 字符即裁剪，只保留前 4,096 和后 1,024；超过 50,000 字节则写盘，不再进入上下文；自动生成会话标题的输出上限也只有 64 Token。共同目标都是减少上下文膨胀和前缀扰动。
缓存为何值得如此精细管理？第三方实测给出了一组直观数据：同一份约 92 万 Token 的输入，首次提问约 ¥9.00，随后四次合计约 ¥0.28；五次请求中，每次均有 923,776 个 Token 命中缓存，新增部分仅 143~151 个 Token。另四次编码任务的缓存命中率约为 93%--98%。同一来源抓取的官方定价页还显示，2026 年 8 月 17 日生效的新高峰价中，缓存命中与未命中的输入价格相差约 30 倍。可以粗略理解为：第一次熬底料，后续只需加新菜；但前缀一旦被改动，后面的缓存就可能重新计算。
因此，Harness 工程关注的已不只是 "功能能否运行"，还包括：一个组件占多少 Token、是否每轮重复出现、是否改变前缀结构。长程任务的成本不仅来自新增 Token，也来自本可复用却因前缀变化而被迫重算的历史计算。Agent 优化也因此从提示词和工具调用，进一步延伸到上下文布局、缓存边界和推理接口。
模型侧也在持续优化。与 v0.1.5 同日发布的 V4.1 Flash，通过缩小 KV Cache 规模降低资源消耗。官方数据显示，相较上一代模型，其 HBM 需求降至 1/4，SSD 需求降至 1/8。在 Agent 场景中，缓存成本占比较高，KV Cache 压缩显著降低了任务使用成本。如图所示，DeepSeek 持续优化上下文存储效率，KV Cache 相较初代模型已缩小 437 倍。
由此看，KV Cache 已不只是推理服务内部的局部优化，而是 Harness 设计阶段必须考虑的系统约束。
四、运行状态的接管：Agent Teams 之下的结构变化
Agent Teams 不只是 "多开几个 Agents"。结合 Sub-Agent、Inbox、Session 等改动，更值得关注的是：Harness 正在接管更多运行时职责。
官方文档显示，Agent Teams 已开始系统管理五类状态：身份、消息、依赖、恢复和协作。Session ID 用于维持 teammate 的长期身份；团队拥有可恢复的 mailbox；共享任务记录 revision、owner、blockedBy、writeScopes 等字段。其中，blockedBy 描述任务依赖并保证 DAG 无环；writeScopes 仅提示潜在写冲突，并非文件锁。消息发送后仍可持续生效：运行中的成员可在后续执行边界接收，idle 或 inactive 成员也可重新唤醒。主 Agent 还能在 Sub-Agent 执行期间补充上下文、调整方向，用户可排队发送消息或直接 Steer 当前执行，主 Agent 也可分别配置各 Sub-Agent 的模型与推理强度。
与此同时，"是否继续执行" 也从单一循环变成多层运行机制：Step 是一次模型请求及工具执行，Turn 是围绕一次意图展开的若干 Step，Round 用于 Agent 空闲后继续推进长期目标；Sub-Agent 拥有独立循环，Workflow 显式编排多个 Sub-Agent，Jobs 则承担另一类后台续跑。Inbox 进一步区分三种输入：followup 进入下一 Turn 并唤醒空闲 Agent，steer 进入下一 Step 并干预当前处理，inject 进入下一 Step 但不主动唤醒。各层分别管理状态、唤醒、持久化、预算和取消。因此，"是否继续" 已不再只由模型是否产生工具调用决定。
这意味着，长程 Agent 的表现正越来越取决于整个运行系统 ，而不只是模型本身。模型能力仍是基础，但任务能否持续完成，还取决于调度、上下文管理、工具稳定性和故障恢复能力。
边界也要明确：Agent Teams 目前默认关闭，位于 packages/experimental，官方仍将其标为实验性功能。它足以说明系统架构正在变化，但尚不能据此判断 "多 Agent 已成为默认答案"。
五、组合层：为什么 "Everything is a Plugin" 与专项训练有关
专项训练要适配具体环境，前提是环境本身可配置、可固定、可复现。Harness 的插件化架构，正是为训练提供这样一个稳定的对齐对象，这也是 "Everything is a Plugin" 与专项训练的核心联系。
官方架构中，Cordis 是 Harness 内置的插件框架。模型 Adapter、工具注册、会话日志乃至 Agent Loop 都可通过配置替换。其六个原语分别负责共享能力、服务暴露、依赖声明、实例生命周期、资源获取与释放，以及类型化事件；Profile 则决定一次运行实际启用哪些能力，是系统组合的边界。
因此，逻辑很直接：训练要针对特定配置优化，环境就必须先被结构化定义。插件化的意义不只是工程解耦，更在于把运行环境变成可描述、可复现的训练目标，为模型与 Harness 的专项耦合提供基础。
这套架构还允许模型在运行时修改 Harness。通过 cordis_define、cordis_inspect_list、cordis_inspect_query、cordis_inspect_self、cordis_run、cordis_stop、cordis_undefine 等 Cordis 工具，模型可在进程内编写、挂载、运行和停止插件。但官方同时明确警告：其沙箱只隔离全局变量，并非安全边界；宿主辅助函数可能带来逃逸风险，应按 bash 权限管理。所谓 "可撤销" 也仅限于运行时登记的组件贡献，已发送的消息、完成的付款或写入远程系统的数据，不会因插件卸载而自动回滚。
Lilian Weng 对 "Agent 修改自身 Harness" 类研究也提出过类似判断：一旦允许程序编辑系统，原有抽象边界就会被打破，因此可编辑范围必须受控，权限与安全机制应独立于自我演化循环。它与官方 "按 bash 权限对待" 的提醒指向同一原则：系统可以进化，但安全边界不能随之进化。
代价同样明确。组合自由度越高，排障、审计和测试成本越高；相比固定调用链，插件体系更依赖清晰的不变量、配置审计和生命周期测试。当前版本仍标注为 developer preview，README 已预告后续存在破坏性变更；仓库关闭 Issues，第三方于 2026 年 8 月中旬抓取时外部 PR 为零，官方反馈主要经 Discussions。它们反映的是现阶段的成熟度与生态约束，应如实记录，不宜直接等同于项目质量问题。
六、三条轴：模型分数与 Agent 分数开始分离
上述变化可归纳为三条轴。这里仅作为本文的分析框架，并非官方分类：
- 模型能力轴：预训练和后训练形成的基础能力；
- 环境适配轴：模型与工具协议、提示词和运行模式的匹配程度；
- 运行系统轴：缓存、调度、恢复与成本控制能力。
过去的评测主要关注模型能力；v0.1.5 则将环境适配和运行系统纳入显式管理。三条轴均有相应证据。
第一，跑分开始与 Harness 配置绑定。
官方公布 V4-Pro-0813 的 Code Agent 成绩时，明确注明测试环境为 "DeepSeek Harness 极简模式 + max 思考档"（top_p=0.95，temperature=1.0），并提示其他框架下结果可能略有不同。对应配置也直接公开：仅保留两个工具、关闭上下文压缩、系统提示词只有一句话，并将流空闲超时设为 48 小时，显然面向超长任务。结合引言所述相隔 76 分钟的两次发布，可以看到：厂商展示的已不只是 "模型分数"，而是 "模型 × Harness" 的组合表现。第三方 Rhea 按同类配置复测自造题，结果方向一致，也说明这一组合具备一定复现性。由此，分数与环境配置的绑定首次被厂商主动写入公告。
第二，环境错配确实可能表现为"降智"。
第三方兼容性测试发现，为适配 Claude 生态，官方 API 在模型名映射中将 claude-opus 指向 Pro，而 claude-sonnet、claude-haiku 以及部分旧版名称如 claude-3-opus 会落到 Flash。测试中，23 个落到 Flash 的请求共生成约 10.3 万输出 Token，账户扣费 ¥1.00，与四种价格假设中的 Flash 计价最接近。也就是说，账单并未多收，但模型能力可能在无提示的情况下被降档。开发者若直接沿用旧脚本，可能以为调用的是旗舰模型，实际部分任务由 Flash 执行。这只是特定兼容层的个例，足以证明 "环境错配可能造成能力下降"，但不能反推所有 "降智" 都源于环境错配。
第三，扩大模型本身的边际收益可能正在下降。
第三方整理的官方自测表显示，Flash-0731 与 Pro-0813 使用同一内部测试集和同一 Harness，可直接比较：Pro 总参数量约为 Flash 的 5.6 倍、激活参数约为 3.8 倍，但九项同口径指标仅领先个位数；最难的 Agents' Last Exam 几乎持平，为 25.7 对 25.2。该拆解还指出，Harness 默认模型及第三方评测榜单中的 DeepSeek 配置均使用 Flash。由于这属于官方自测，且部分对照模型的成绩来源未充分说明，因此它只能提示 "模型轴可能存在边际收益递减"，尚不足以下定论。
三条轴也并非彼此独立。Lilian Weng 综述转引的 Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents 将 "改进 Harness 的能力" 和 "从 Harness 改进中获益的能力" 分开测量。其结果显示，在 Qwen2-32B 至 Opus 4.6 的范围内，不同模型编写 Harness 改进方案的能力差异不大，但实际获益并不随模型能力单调增加，中档模型反而受益最多。
这说明，模型能力决定环境优化能走多远，环境又决定模型能力能兑现多少，两者相互制约，而非简单相加。运行系统同样如此：KV Cache 等设计只有在长任务中才会显著影响成本和效率，短任务中的权重则有限。
因此，Agent 性能没有固定的单一瓶颈。决定表现的，不只是模型有多强，而是哪条轴在当前任务中先成为约束。
七、还没有答案的五个问题
现有证据足以判断方向，但不足以判断程度。至少还有五个问题没有答案。
第一，专项训练效果尚无法量化。
官方未公布训练配方和消融实验，也缺少第三方大规模复现。因此，"专项训练" 究竟在多大程度上改变模型行为、付出了什么代价的定量结果，目前仍不清楚。
第二，模型与 Harness 可能出现版本错配。
这是一个推断：模型适应的是训练时的 Harness。若模型升级而 Harness 未同步，或 Harness 发生破坏性变更而模型未重新训练，原有环境假设就可能失效。这与过拟合类似，只是对象从数据分布变成了运行时配置。官方提示 "其他框架下结果可能略有不同"，也侧面说明模型与环境存在绑定。
第三，跨 Harness 的可移植性和评测标准仍待建立。
如果专项训练成为普遍做法，就必须回答三个问题：模型换一个 Harness 后还能保持多少能力；评测是否应同时公布环境配置；不同厂商的成绩在什么条件下才可比较。正如 Lilian Weng 对人类数据质量的讨论所指出，分歧本身未必是问题，关键是区分它来自错误、流程缺陷，还是真实差异。Agent 跑分同样如此。能否分清这些来源，决定 "组合成绩可复现" 能否真正成为标准。
第四，训练信号与运行环境可能相互塑造。
如果模型以 "在 Harness 中完成任务的轨迹" 作为训练信号，环境本身就会影响模型学到什么。Lilian Weng 在奖励 Hacking 综述中指出，一些由系统设计引发的问题可以通过环境约束规避，例如用沙箱隔离 Agent 行为与奖励信号。前文所述运行时自写插件也被官方明确标注为 "不是安全边界"，权限控制应置于这一循环之外。实际设计能否始终守住这条边界，仍需持续核验。
第五，人的否决权应放在哪里。
Lilian Weng 对未来挑战的一项判断是：人应沿技术栈上移，而不是退出循环。在哪个抽象层、什么时机保留人工介入，本身就是系统设计。当 Harness 接管更多调度、恢复和运行秩序后，谁在什么层级拥有最终否决权，可能比具体架构更值得先回答。
结语
回到开头的问题：Agent 的 Scaling 对象正在从 "模型有多强"，扩展到 "模型、Harness 与推理系统如何协同"。
现有证据能够支持 "对象正在变化"：训练开始适应环境，Harness 开始考虑缓存，运行时开始承担调度与状态恢复；但还不能说明新的 Scaling 范式已经定型，因为训练配方仍不透明、收益尚未量化，部分能力也仍处于实验阶段。
因此，面对任何 Agent 性能数字，至少要追问三件事：
- 分数来自哪里？ 是模型能力、环境适配，还是运行系统；
- 在什么环境下测得？ Harness 配置是什么，能否复现；
- 能力由谁提供？ 多少来自模型学习，多少由 Harness 补足，多少由推理系统承担。
三个问题对应三条轴，也对应三类优化预算。
最终的矛盾同样清楚：模型与环境结合越紧，匹配时收益越高，错配时风险也越大。
如何获得环境适配的收益，又不牺牲模型的可移植性，或许正是 Agent Scaling 对象变了后，第一个真正尚未解决的问题。