DeepSeek Harness 终于发布了。
这次发布的是面向 agent harness 开发者的 developer preview，源码也已经放出。2026 年 8 月 14 日的 HN 上，DeepSeek Harness developer preview 有 639 分、264 条评论。它进入的是一个已经很热的赛道：Claude Code、Codex、Cline、OpenCode、Pi 等工具已经让很多开发者熟悉了 agent harness。DeepSeek Harness 这次更具体地回答了几个工程问题：能力如何组合，过程如何追踪，运行环境如何切换和实验。
DeepSeek 原文里有一句话很直接：模型是 agent 的灵魂，而 Harness 让 agent 理解环境、使用工具，并在真实环境里持续工作。换句话说，模型负责生成，Harness 负责把模型接入真实环境：工具怎么调用，上下文怎么注入，会话怎么保存，沙箱怎么隔离，任务循环怎么推进，子代理怎么调度，UI 怎么呈现，出错以后又怎么回看。
第一条设计是 插件化运行时。DeepSeek Harness 把 models、tools、skills、sessions、sandboxes、storage、loops、scheduling 和 UI 都放进插件系统里。它们不是写死在一个固定工具里的功能，而是可以在配置中替换、重组和扩展的运行能力。DeepSeek Harness 底层使用 Cordis；在这套机制里，插件不仅要能加载，还要能启用、停用、热加载、卸载，并在退出时清理自己带来的事件监听、连接、服务注册和其他副作用。
第二条设计是 可追踪运行轨迹。DeepSeek Harness 会把模型看到的内容写进追加式会话日志：system prompt、reasoning、tool calls、tool results、subagent scheduling、context injection，以及每一次上下文从哪里来。Trajectory view 的价值不只是把过程展示得更漂亮，而是让查看、恢复、分叉、搜索和回放都建立在同一条事件流上。
这对应的是 agent 调试里的具体问题：结果错了以后，人常常不知道它究竟在哪一步偏了。是系统提示不合适，工具返回误导了它，上下文注入错了，子代理调度出了问题，还是某个中间结果被带进了后面的决策？如果运行轨迹不完整，恢复、分叉、审计和调试都只能靠事后猜。可追踪性要解决的，就是让 agent 的过程不只剩一个最终回答。
第三条设计是 多种 runtime mode。Standard mode 提供完整工具集；Code mode 让模型生成代码来组织多轮工具调用；Minimal mode 只保留 shell 和文件编辑器，方便在极简环境里测试模型；Creator mode 则允许检查当前运行时、在内存中测试插件，并组合出新的模式。它们放在一起看，DeepSeek Harness 提供的不是单一界面，而是一套可以切换、裁剪和实验的 agent 运行环境。
HN 评论区讨论的也是这些工程边界。有人把可追踪轨迹称为 killer feature，因为它能把模型看到的东西、工具调用和上下文注入摊开；也有人提醒，“一切皆插件”很容易走向 plugin fatigue：插件生态一开始灵活，后来可能变成兼容性、废弃插件和治理问题。围绕 Node.js、TypeScript 和 npm 的争论也是同一类担心：agent harness 本身会不会越来越重、依赖越来越多、供应链越来越难管。
评论里还反复出现两个问题。一是第一方 harness 和第三方 harness 的取舍：模型厂商自己做 harness，可能更了解自家模型和工具调用格式，但很多开发者仍然希望保留一个能跨模型使用的稳定工作界面。二是确定性工具和 LLM 的边界：如果 pre-commit checks 这种事情已经有可靠脚本，就不应该只是让模型读一段 skill 再去执行。Harness 真正有价值的地方，不是让 LLM 替代所有工具，而是把可靠工具和会处理变化的模型组织到同一个运行过程中。
DeepSeek Harness 的技术取向由此变得很明确：能力要能组合，过程要能追踪，运行环境要能切换和实验。插件化处理的是 agent 能力不断变化的问题；可追踪性处理的是 agent 行为难以复盘的问题；多种 runtime mode 则把这些能力放进可测试、可裁剪的运行环境里。
这也是 DeepSeek Harness 这次发布留下的核心印象：当模型之外的运行时越来越复杂，开发者需要的不只是更多工具，而是一套能被重组、能被观察、也能被调试的 harness。
🔗 HN 原帖 · DeepSeek Harness · GitHub