DeepSeek Harness 开发者预览版发布：把 Agent 运行时做成可组合插件
DeepSeek 于 2026 年 8 月 13 日开放 DeepSeek Harness v0.1 开发者预览版并采用 MIT 许可证。它把模型、工具、会话、沙箱、Agent Loop 与 UI 都做成可替换插件，为开发者提供可组合、可追溯的 Agent 运行时。
2026 年 8 月 13 日，DeepSeek 开放 DeepSeek Harness（dsh）v0.1 开发者预览版，并以 MIT 许可证公开代码。开发者安装 Node.js 后，可通过 npx @deepseek-ai/dsh web 在本机 3080 端口启动 Web UI。
这次发布补上了 DeepSeek 模型与真实工作环境之间的一层基础设施。DeepSeek Harness 负责组织上下文、工具、文件系统、终端、会话、权限和 Agent Loop，让模型能够持续执行多步骤任务。它也可以直接承担编码 Agent 的工作，但官方给出的产品定位更接近一套可改造的 Agent 运行时，而非已经定型的终端应用。
更重要的变化是架构。DeepSeek 把“模型之上的执行层”完整开放出来，并用“一切皆插件”作为核心原则。对于正在自建 Agent、代码助手或内部自动化系统的团队，这比再增加一个固定工作流的聊天工具更有参考价值。
“一切皆插件”具体开放了什么
DeepSeek Harness 基于 Cordis 插件系统构建。模型适配器、工具注册表、Skills、会话日志、沙箱、文件系统、存储、Agent Loop、调度和 UI 都由插件提供，通过服务与类型化事件协作。
这套设计把常见 Agent 框架里的扩展边界向下移动。开发者不只可以添加一个 MCP 工具或一项 Skill，还可以替换模型适配器、执行环境、会话存储，甚至重新组合 Agent Loop。官方架构文档将一个运行中的 dsh 描述为启动时按层组合的插件树：Profile 定义一套命名组合，Bundle 负责分发可被上层配置覆盖的插件集合。
对工程团队来说，这种拆分主要带来两项实际价值。
- 可替换性：本地文件系统可以换成远程沙箱，模型供应商可以替换，工具和子 Agent 的实现也能独立调整，不必为每种部署方式复制整套 Agent。
- 可审计性：能力边界落在明确的插件、服务和事件上，团队更容易追踪某一步由哪个组件提供，也更方便做权限、日志和测试隔离。
代价同样明显。Profile、Bundle、配置覆盖与 Cordis 生命周期增加了学习成本。只想找一个成熟代码助手的个人用户，未必会立即从这种底层可组合性中获益；需要自定义运行环境或构建 Agent 产品的开发者，才是现阶段更直接的受众。
四种模式对应四类测试需求
开发者预览版提供四种预设模式，每种模式加载不同的插件组合。
模式 | 主要用途 | 适合先验证的场景 |
|---|---|---|
标准模式 | 完整的通用 Agent 工具集 | 仓库阅读、修改代码、运行命令和多步骤任务 |
PTC 模式 | 让模型用代码组织多次工具调用 | 需要减少工具往返、批量处理或组合操作的任务 |
极简模式 | 只保留少量 Shell 与编辑能力 | 控制变量做模型评测，观察 Harness 对结果的影响 |
创造模式 | 检查运行时并试验插件组合 | 开发插件、调试能力边界和制作自定义 Profile |
其中，极简模式和创造模式最能说明 DeepSeek Harness 的定位。前者把运行时收缩到接近评测底座，便于比较模型本身；后者让开发者直接观察并重组插件树。标准模式更像已经组装好的 Agent，而整个项目的重点是这些模式背后的组合机制。
PTC 模式也值得单独观察。传统 Agent 往往由模型逐次发出工具调用，每一步都要等待结果再继续。PTC 允许模型生成代码来编排多个工具操作，理论上能减少往返并表达更复杂的控制逻辑。它是否在真实仓库里更稳定，仍需要用失败恢复、权限审批和长任务完成率来验证，不能只看演示中的步骤数量。
会话日志让 Agent 的执行过程可回放
DeepSeek Harness 将会话事件写入仅追加日志。用户消息、模型输出、工具调用与结果、上下文注入以及执行状态都沿同一事件流记录；恢复会话、分叉、转录、持久化和遥测也从这份日志派生。
这解决了 Agent 开发中的一个常见难题：任务失败后，团队需要知道模型在某一步究竟看到了什么。只保存最终回答无法解释上下文是否被压缩、工具结果是否完整返回，或权限策略是否改变了执行路径。统一事件流让这些问题有机会被复现，而不是依靠零散的前端状态和日志猜测。
不过，“记录得更多”也带来新的治理要求。真实项目的会话日志可能包含代码、命令输出、目录结构和运行时上下文。团队在接入内部仓库前，应先确认凭证处理、日志保存位置、清理策略和访问权限，而不是因为项目本地运行就默认数据风险已经消失。
DeepSeek 开始争夺模型之上的开发者入口
今年 5 月，DeepSeek 组建 Harness 团队的招聘信息已经显示，公司准备从模型供应方进入代码智能体产品层。此次开源让方向变得具体：DeepSeek 不只希望模型被接入第三方工具，也开始提供自己的 Agent 运行时、交互入口和插件规范。
这会影响围绕 DeepSeek 构建产品的小团队。过去常见做法是选用通用 Harness，再把 DeepSeek 作为模型后端。现在开发者多了一个第一方选项，并且可以在 MIT 许可证下研究、修改和二次开发。围绕模型适配、远程沙箱、企业权限、会话审计、行业工具与中文开发流程的插件，也可能形成新的生态位置。
短期内，DeepSeek Harness 还不能按成熟生产基础设施来评估。官方明确说明项目正在快速迭代，未来会出现破坏兼容性的变更。对依赖稳定接口的小团队来说，这一句警告比功能清单更重要：实验可以积极，生产集成应固定版本并保留迁移预算。
小团队可以先做一次受控试验
最合适的起点不是立刻替换现有代码助手，而是选一个可回滚的小仓库做对照测试。
- 使用标准模式完成一个边界清晰的任务，例如补充单元测试、修复类型错误或同步文档。
- 记录任务用时、人工干预次数、失败恢复情况和 API 消耗，不只评价最终代码看起来是否正确。
- 在极简模式下重复相近任务，观察工具数量和系统提示变化是否显著影响结果。
- 检查会话回放是否足以解释关键修改，并确认日志中没有不应长期保留的敏感信息。
- 如果确实需要特殊沙箱、内部工具或审批流程，再进入创造模式试做插件；不要一开始就维护大规模自定义配置。
现阶段最值得关注的后续信号，是核心接口何时趋于稳定、插件发现与分发机制如何完善，以及社区能否沉淀出可复现的评测和生产案例。在这些条件成熟之前，DeepSeek Harness 更适合作为 Agent 架构试验场和开发底座候选，而不是现有工具链的无条件替代品。
