DeepSeek Harness 0.1发布：一切皆插件，连Agent核心循环都能替换

DeepSeek Harness终于发布了。8月13日，DeepSeek面向全球开发者开放DeepSeek Harness开发者预览版，首个版本为v0.1，并同步以MIT协议开放源代码。开发者现在可以通过npx @deepseek-ai/dsh web直接启动Web UI，也可以从GitHub拉取完整项目。 从版本号看，这还远未到成熟产品阶段。DeepSeek也明确表示，当前仍有大量细节需要打磨，核心插件和基础接口将在后续快速迭代。不过，这次发布已经回答了外界最关心的问题：DeepSeek会怎样做自己的Harness？答案就是：一切皆插件，连Agent Loop都能替换。 过去几个月，围绕AI Coding的讨论正在从模型转向Harness。同一个模型被放进不同的Agent系统，最终表现可能相差很大。原因并不复杂：模型只负责预测下一步，Harness决定模型能看到什么、可以调用哪些工具、如何组织上下文、遇到错误怎么重试，以及什么时候判断任务已经完成。 目前主流Coding Agent虽然普遍支持插件、MCP或自定义工具，但可扩展范围通常集中在工具与技能层。DeepSeek Harness把插件边界进一步下沉到了整个运行时：模型、工具、技能、会话、沙箱、存储、Agent Loop、调度和UI，全都由插件组成。这意味着，可替换范围从某个搜索工具或MCP Server，一直延伸到Agent如何循环、如何调度子Agent、如何保存会话，以及最终采用什么交互界面。整个过程无需修改Harness源码。 支撑这套架构的是Cordis插件系统。Cordis元框架本身只处理插件的加载、卸载与依赖关系，具体的Agent能力则由不同插件提供。插件之间通过服务和事件协作，再由配置决定它们如何组合。工具调用也被拆成了一条可扩展流水线：请求执行前会经过Hook、审批、权限检查、沙箱和超时控制，执行后还可进行结果改写、记录和UI渲染。开发者无需修改工具或Agent Loop，就能在各个环节插入插件。 PTC模式中的代码及其子调用同样要经过这套流水线，不能绕过审批与沙箱。普通工具调用和程序化工具调用入口不同，但共享同一套安全与观测机制。因此，DeepSeek Harness的定位更接近一套可组装的Agent运行时底座，与功能固定的Coding Agent有明显区别。DeepSeek此次首先面向的也是Harness开发者，而非只想下载一个客户端直接写代码的普通用户。 基于同一套底座，DeepSeek Harness当前提供四种运行模式。它们没有分别维护四套系统，主要差异来自默认加载的插件集合。标准模式提供完整工具组合，面向常规Agent任务；PTC模式支持程序化工具调用，允许模型生成代码，将多轮工具调用组合起来执行；极简模式只保留shell和文件编辑两个工具，主要用于减少其他组件干扰，在最小环境中测试模型能力；创造模式则允许Agent检查当前运行时，在内存中试验Cordis插件，并据此组合、创作新的运行模式。 其中最值得关注的是创造模式。传统Harness的运行方式通常由产品开发者预先写定，用户只能在既有配置中选择。创造模式试图让Agent直接理解自己所处的运行时，再按任务需要试装插件和组合能力。换句话说，Harness的配置本身也开始成为Agent可以操作的对象。这距离“Agent自己改造自己的Harness”还有多远，需要等代码、示例和真实任务验证。目前能够确认的是，DeepSeek已经把运行时的可组合性同时交给了模型、配置文件和框架开发者。 多Agent方面，DeepSeek Harness已经内置了一套完整的系统。父Agent可以通过Spawn启动拥有全新上下文的子Agent，也可以通过Fork让子Agent继承已有会话；面对更复杂的任务，模型还能通过workflow工具现场编写JavaScript，用parallel()和pipeline()组织并行或流水线任务，并通过Ralph模式让多个全新Agent按轮次接力。如果放进常见的五种编排模式中，DeepSeek Harness最接近层级式Supervisor–Worker：父Agent负责拆解、分配和汇总任务，子Agent负责执行。更准确地说，它是一个以层级式为骨架，同时支持按需Fork、现场workflow编程和Ralph接力的混合体。 整体来看，DeepSeek Harness的发布意味着AI Coding的竞争重心正在从模型能力扩展到运行时架构。它把“Agent如何被组装”这件事开放给了开发者，甚至让Agent自身也能参与改造。至于这是否会催生下一代编码范式，还需要真实任务和社区实践的检验。但至少，DeepSeek已经给出了一个明确的回答：Harness不是固化的产品，而是可插拔的底座。