我是安徽最忧郁程序员无隅
同一个模型、同一段需求，仅仅换一种运行模式，完成时间就能缩短十几甚至二十分钟。乍一看，这像是模型能力突然“解锁”了。
但从 Agent 工程的角度看，更准确的解释是：模型没有换，Harness 改变了模型看到的上下文、可以选择的动作，以及完成任务时能够调用的外部能力。
本文根据程序员鱼皮发布的 DeepSeek Harness 模式对比视频及用户提供的字幕整理。文中的耗时、步数和产品表现来自视频里的单次实验，不代表官方基准，也不足以证明某种模式在所有任务上都更优。
一、先说结论：这不是模型能力暴增，而是 Harness 改变了能力释放方式
先用一句话理解 Harness：它是包在大模型外面的执行环境，负责把系统提示、工具、文件系统、终端、权限、会话和工作流组织起来，让模型不只会回答问题，还能持续操作真实环境。
DeepSeek 官方把这个关系概括为 Agent = Model + Harness。模型负责理解与决策，Harness 负责向模型提供环境和能力。官方页面同时说明，DeepSeek Harness 仍处于开发者预览阶段，其能力通过插件组合；不同模式本质上是不同的能力组合。DeepSeek Harness 官方介绍
这也是理解“极简模式性能暴增”的关键：
- 模型能力：模型能否理解需求、规划步骤、生成代码和修复问题。
- 执行性能：完成任务花多少时间、多少轮调用、多少 Token。
- 工具能力：是否具备搜索、浏览器、图片理解、规划、技能和子 Agent 等接口。
- 交付质量：最终产品是否完整、好用、可验证，是否需要人工补步骤。
这四项会互相影响，却不能画等号。执行更快，不等于模型变聪明；功能能跑，也不等于产品已经完成交付。
官方对两种模式的定位其实很清楚：Standard 模式包含完整工具集，而 Minimal 模式只保留持久终端和 str_replace_editor 文件编辑器，用于让模型在最小环境里接受基准测试。换句话说，极简模式首先是一间“考场”，不是默认面向复杂生产任务的“全能办公室”。DeepSeek Harness 模式说明｜官方 CLI 参考
二、两轮实验说明了什么：速度、能力与可交付性是三套指标
视频使用相同模型和同一套提示词，分别运行 Standard 与 Minimal 模式。两轮任务都出现了一个有意思的现象：极简模式调用步数更多，但总耗时更短。
| 实验任务 | Standard 模式 | Minimal 模式 | 直接观察 |
|---|---|---|---|
| 3D 第一人称射击游戏 | 50 步，约 33 分钟 | 77 步，约 23 分钟 | Minimal 快约 10 分钟，但输入 Token 多约 70 万 |
| AI 宠物领养系统 | 59 步，约 49 分钟 | 87 步，不到 28 分钟 | Minimal 快约 21 分钟，Token 消耗接近 |
如果只看墙钟时间，Minimal 连赢两局；如果看最终产品，结论就没有这么简单了。
第一轮：速度占优，成品各有缺口。
Standard 版本的移动、跳跃、疾跑、射击和倒地视角完成得更细，但敌人不能射击，还出现了追逐一段时间后主动跑开的异常行为。Minimal 版本界面更简洁，敌人能够射击，战斗压迫感更强；不过玩家倒地后身体仍保持站立，细节不如 Standard。
因此第一轮更合理的结论是：Minimal 在这次任务里更快，两个版本的产品质量各有优缺，不能据此得出“极简模式全面更强”。
第二轮：速度继续占优，复杂工具依赖暴露了短板。
AI 宠物领养系统不仅要写前后端，还涉及联网获取图片、调用模型和读取运行凭据。Standard 版本完成了图片获取、AI 文案、领养状态和筛选功能；Minimal 版本需要人工补充模型密钥，没有筛选能力，卡片信息和面向用户的文案也更简陋。
这里有一个容易被忽略的安全问题：视频把“自动找到电脑上的模型密钥”当成交付能力，但在真实工程里，Agent 能读取凭据不天然是一件好事。正确做法应当是显式授权、限定路径、最小权限，并通过环境变量或专用凭据服务注入，而不是鼓励 Agent 扫描本机寻找 API Key。
因此，第二轮真正测出的不是“Standard 更聪明”，而是：当任务强依赖搜索、凭据、外部资源和产品工作流时，完整 Harness 能减少人工接管，提高端到端可交付性。
视频还报告 Minimal 模式的缓存命中率接近 100%，因此额外输入 Token 的费用影响很小。这个结果只能说明当次运行的缓存表现，不能直接推广到其他模型、供应商、提示词结构或定价规则。缓存是否命中取决于请求前缀是否稳定，也不意味着更多输入 Token 永远没有成本。
三、极简模式为什么会更快：工具越多，模型的决策空间越大
一次 Agent 循环，并不是模型“想完以后随便挑个工具”。在常见的 Tool Calling 链路里，模型每一轮都要处理下面这条链：
系统提示与工具定义 → 判断下一步动作 → 选择工具 → 组织参数 → 接收工具结果 → 进入下一轮
工具通常以 Tool Schema 的形式交给模型，其中包含工具名称、用途、参数字段和约束。DeepSeek Harness 的官方工具文档也明确描述了 bash、pwsh 和 str_replace_editor 暴露给模型的结构及其 Token 影响。DeepSeek Harness Tool Catalog
当 Standard 模式一次提供搜索、浏览器、规划、技能、子 Agent 和工作流等完整能力时，模型获得了更大的行动空间，同时也要承担三类额外负担。
第一类是固定上下文负担。 每个可见工具都要把名称、描述和参数结构放进请求。工具越多，请求头部通常越长。若这些内容在多轮调用中保持不变，缓存可以降低重复计算或计费压力，但它们仍然构成模型需要处理的接口表面。
第二类是工具选择负担。 面对同一个目标，模型需要判断是直接编辑文件、先搜索资料、调用浏览器，还是拆给子 Agent。候选动作越多，选择空间越大，也越容易发生工具误选、重复规划或参数组织失败。
第三类是 Harness 编排负担。 完整模式往往包含权限检查、日志、规划、进度汇报和结果转换。这些能力提高了透明度和可控性，却也会增加部分调用与输出时间。
Minimal 模式把模型面对的接口压缩为终端和文件编辑器。模型不需要在二十多个专用工具之间反复权衡，可以围绕“读文件、执行命令、修改文件”形成更短的决策路径。这能解释为什么视频里 Minimal 虽然走了更多步，却更早结束：步数变多不代表每一步更重，Standard 的单步可能包含更大的工具选择和交互开销。
但这里必须保留证据边界。视频中“工具少让注意力更集中”的说法，是一种合理的工程解释，不是对模型内部注意力分配的直接测量。要证明具体因果关系，还需要固定模型版本、提示词、权限、缓存、网络和任务快照，只改变工具表面，并进行多次重复实验。
工具减少还会带来确定的代价：没有搜索工具，不等于不能联网，但模型只能尝试通过终端脚本绕路；没有图片理解工具，就很难靠文本终端补齐视觉能力；没有规划与进度能力，用户也更难知道 Agent 正在做什么。极简模式优化的是接口规模，不是凭空创造缺失能力。
四、真正值得研究的是渐进式工具释放
视频后半段提到了一种更有价值的社区玩法：首轮沿用极简系统提示，只向模型提供终端和文件编辑器；模型完成第一次工具调用后，再恢复完整工具集。
这个思路可以概括为：
极简冷启动 → 建立第一段执行轨迹 → 恢复完整 Harness → 完成复杂交付
它试图同时获得两种模式的优点：启动阶段减少提示词和工具表面，进入执行状态后再提供搜索、浏览器、技能和工作流。DeepSeek 官方仓库中的社区讨论把原始方案记录为 Minimal → promotion → Full Harness，并进一步实验了“按需请求能力、使用后释放”的变体。值得注意的是，作者明确将其标注为非官方社区实验，也反复强调这些现象只是轨迹特征和实验假设，不是模型更聪明或推理更强的证据。社区实验记录：按需能力释放
从 Harness 设计角度看，这比“工具越少越好”更接近一个可用方向：工具不必在启动时一次全部暴露，也不必永久删掉，而可以随着任务阶段动态装载。
不过，动态工具释放会引入新的工程问题：
- 能力应该在第一次调用后统一恢复，还是由模型按需申请？
- 工具集合变化后，请求前缀和缓存命中率如何变化？
- 模型不知道某项隐藏能力存在时，如何主动申请它？
- 能力切换失败或工具执行报错时，如何降级和恢复？
- 新增工具是否扩大了文件、网络和凭据访问权限？
所以，“先极简后完整”目前更适合作为 Harness 实验策略，而不是无需验证就复制到生产环境的最佳实践。
实际选择时，可以按任务依赖做判断：
| 任务场景 | 更合适的选择 | 原因 |
|---|---|---|
| 封闭代码仓库、依赖已经安装、验收命令明确 | Minimal 值得尝试 | 终端和编辑器可能足够，接口更小 |
| 需要联网、图片理解、浏览器或外部系统 | Standard 更稳妥 | 专用工具直接决定任务能否端到端完成 |
| 强调过程透明、权限审批和人工协作 | Standard 更合适 | 完整日志、工作流和交互能力更重要 |
| 研究 Harness 对模型行为的影响 | 渐进式释放值得实验 | 可以比较启动表面与后续能力的组合效果 |
如果要认真复现实验，至少应固定模型与版本、推理强度、初始提示词、代码快照、依赖缓存、权限、网络条件和人工干预；每种模式重复运行多次，并同时记录墙钟时间、步数、缓存命中与未命中 Token、测试通过率、功能验收率、工具错误和人工接管次数。
最终比较的对象也不该只有“跑得快不快”，而应该是：在相同任务和权限边界下，哪种 Harness 用更可控的成本，交付了更完整、可验证的结果。
五、总结：优化 Harness，本质上是在优化模型与环境的接口
DeepSeek Harness 的极简模式确实展示了一个重要事实：Agent 的表现不仅由模型参数决定，还会受到系统提示、工具结构、执行循环和权限环境的显著影响。
视频中的两轮实验支持一个有限但有价值的结论：在给定任务和单次运行中，Minimal 模式显著缩短了完成时间；与此同时，依赖外部工具的复杂任务出现了更明显的交付缺口。
因此，真正值得带走的不是“以后全部切到极简模式”，而是下面三点：
- 速度、模型能力和产品完成度必须分开评价。
- 工具越多并非永远越好，工具应该围绕任务阶段和能力依赖来暴露。
- 渐进式或按需能力释放可能是下一类 Harness 优化方向，但需要可复现的对照实验。
模型决定了能力上限，Harness 决定了这些能力以什么接口、权限和节奏被释放。对 Agent 开发者来说，后者已经不是外围包装，而是系统性能与交付质量的一部分。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2301_80956187/article/details/164885052
