DeepSeek Harness 开发者预览版已经公开源代码。
它不是又一个带工具的 Agent。
更准确地说，它把 Agent 的运行结构拆开，交给开发者重新组合。
过去，软件先确定产品，再增加插件。
剪辑软件有时间轴，办公软件有文档，代码编辑器有文件树和终端。插件可以加功能，但产品的主要边界已经定了。
Harness 反过来：模型、工具、任务循环、会话、权限、执行环境和界面，都可以成为组合的一部分。
它开源的不是一个 Agent 成品，而是一套可以继续装配的 Agent 运行底座。
一、Harness 到底负责什么
大模型负责理解、推理和生成。
要让它完成真实任务，还需要上下文、工具、任务状态、执行环境、权限和反馈。
这层工作就是 Harness。
大模型：理解和推理
Harness：任务循环、工具、状态和权限
业务层：数据、界面和具体流程普通 Agent 产品通常把这层封装起来，用户拿到的是一个已经装好的应用。
DeepSeek Harness 则把它拆成了可以继续组合的部分。
官方架构把模型适配器、工具注册表、会话日志和 Agent Loop 放进插件体系，并用 Cordis 管理插件、服务、事件和依赖关系。
源码里对应的能力包括 Agent、工具、会话、模型、沙箱、MCP、Skill、子 Agent 和工作流。
这些模块的价值不在于数量多，而在于运行时的若干组成部分和接入点被拆了出来。
开发者可以在现有接口和配置范围内替换模型、工具或执行环境，任务状态和界面也能按业务接入；实际迁移成本仍取决于接口和业务集成。
二、它开放的是 Agent 的组成层
Skills、MCP、Hooks 和自定义工具，解决的是“给现有 Agent 增加能力”。
DeepSeek Harness 进一步开放的是“这个 Agent 由什么组成、怎样运行”。
Agent Preset（预设）是一个很直观的例子。
普通自定义 Agent 可能只是换一段 Prompt：
你是一名专业的市场分析师……Preset 改的是 Agent 的装配清单：
- 使用什么模型；
- 能调用哪些工具；
- 是否启用计划、目标和子 Agent；
- 能访问哪些文件和执行环境；
- 使用哪些技能和提示词；
- 采用什么权限和会话方式。
当前安装包里已经有四种 Agent 预设，还附带插件开发和组合配置指导，展示了 Agent 检查当前运行时、辅助创建另一套 Preset 的实验性路径。
- 标准模式提供完整工具，
- PTC 是
codepreset 中的程序化工具调用组合， - 极简模式只保留 Shell 和文件编辑，
- 创造模式用于检查和实验当前运行时。
它们说明，Harness 不只允许添加能力，也提供了针对任务裁剪 Agent 能力边界的预置方式。
这不是成熟的“自我进化”。
但它说明了一件事：自定义 Agent 不再只是改 Prompt，也可以改工具、权限和运行方式。
Prompt：改变 Agent 怎么说话
工具：增加 Agent 能做什么
Preset：重新决定 Agent 由什么组成这也是 Harness 和普通插件系统的差别。插件不只是挂在产品外面的功能包，它可以参与组成 Agent 本身。
这也和最近讨论的 Agent Plugins 1.0 形成了呼应。
Agent Plugins 1.0 解决的是 Skills 和 MCP 如何统一打包、发现和分发；DeepSeek Harness 进一步推进，能力进入 Agent 之后，能不能参与模型、工具、会话和运行流程的重新组合。
前者统一的是能力的交付格式，后者开放的是运行时的装配方式。两者共同指向一个变化：插件不再只是成品软件外面的外挂，也开始成为 Agent 的组成单元。
三、同一套运行结构，可以接不同入口和界面
DeepSeek Harness 目前提供 Web UI，也提供命令行一次性运行器。
Web UI 是交互版本：有工作区、会话、模型选择、权限设置、工具调用和任务轨迹。
它目前通过 Web 技术运行，开发者预览版还没有进一步打包成独立桌面 App，但这不影响它已经是一个带图形界面的 Agent 软件。
命令行入口的官方用法是：
dsh --profile headless "run the tests"它接收一项任务，调用模型和工具，完成后把最后一条非空回答打印到终端并退出。
它不是完整后台服务或定时任务平台；要接入这些场景，还需要开发者自己补上调用、数据和调度层。
两种入口共享基础层和同一套 profile/patch 组装机制，但 Web 和 Headless 仍分别叠加各自的运行 bundle。
这说明运行能力在设计上没有完全绑定某一个交互入口。
官方教程用一个名为 Review Job 的业务示例，演示如何在 Web Client 内定义三类事件：
review/start
review/progress
review/end插件用同一个任务 ID 关联事件，逐步构建业务状态，再用 React 组件显示在 Web Client 里。
官方还提供 Trajectory 视图，可以按 turn 或 step 查看用户、助手、工具和嵌套子工具记录；具体能展示哪些字段，取决于当前版本记录的事件和界面实现。
任务开始
↓
事件写入会话日志
↓
状态持续更新
↓
业务组件刷新
↓
任务结束，状态可回放所以，在 Web Client 内，业务组件不必只显示最后答案，也可以显示任务步骤、工具调用、审批、错误和重试。
追加式事件记录为任务过程的观察和状态呈现提供了基础；至于恢复、分叉和完整回放能做到什么程度，还要以当前版本的具体实现为准。
这个教程证明的是一种宿主内的扩展方式，不等于 Harness 已经提供了任意业务前端或完整 UI 框架。
结尾
模块化、插件化、事件系统和可组合架构都不是 DeepSeek 发明的。
DeepSeek 做得有意思的地方，是把这些思想收束进 Agent 运行时：稳定的运行结构下沉，变化的业务形态上浮。
以后判断一个 Agent 框架，不能只看它能不能接入工具和 Skill，还要看开发者能不能重新决定：
- Agent 由什么组成；
- 它怎样执行任务；
- 状态和权限如何管理；
- 业务界面怎样接入。
这比“DeepSeek 又做了一个 Agent”更重要。
当然，当前版本仍是开发者预览，能否在真实业务中稳定支撑复杂状态、权限和交付，还需要继续验证。
现在更值得关注的，不是它已经替代了多少现有产品，而是它把一条不同的路径公开出来了：先搭可组合的智能运行结构，再围绕具体业务装入工具、数据、权限和界面。
资料与代码
