DeepSeek Harness 新增 Creator Mode，让用户靠对话就能搭建实时运行的 AI 插件

DeepSeek 的开源智能体运行时 Harness，是这家公司历史上增长最快的开发者工具，不到三个月就拿下大约 26.9 万个 GitHub star。2026 年 11 月 2 日，它迎来了一次质的能力跃升。团队在 X 上宣布了 Creator Mode，同时发布了七条中英双语的演示提示词，展示用户如何只靠用大白话（英文或中文）描述一个插件，就能生成一个真正可用、可安装的插件。不需要任何事先的插件开发经验。智能体读取描述后，会在内存中构建出一个 Cordis 插件，并通过现有的插件管理器界面，把它安装进当前运行的会话里。

这次公告的意义，超出了「用自然语言创建工具」这件事本身的便利性。Creator Mode 是一个被理论探讨了多年的能力，在一个生产级质量的智能体运行时里，第一个真正跑起来的参考实现：一套软件系统能够检查自己的插件图谱并对其进行扩展，而不需要暂停运行，也不需要打开代码编辑器。DeepSeek 把底层框架称为 Cordis，而让这一切成为可能的架构，并不是 Harness 的一个附带特性——它本身就是 Harness。

DeepSeek 在 11 月 2 日发布的东西，更准确地说，是给一个已有能力新增了一个入口；这项能力最早是以预发布形态，在 10 月 3 日随 Harness 0.2.1-alpha.1 版本出现的，当时在插件管理器里新增了一个「让智能体创建插件」的选项。Creator Mode 把那条实验性路径，正式确立为一个一等运行模式，增加了一套预设的创作工作流，并公开了一批任何用户都可以直接复制修改的演示提示词。这次发布的时间点，也延续了一次更大的战略推进：10 月 31 日，DeepSeek 发表了一篇技术文章，描述了一套「超级智能体」架构，建立在与 Harness 相同的双层、事件驱动、异步多通道设计之上。Creator Mode，正是这套架构「自我扩展」能力在用户端的体现。

Creator Mode：11 月 2 日到底改变了什么

此前，Harness 提供三种命名的运行模式。标准模式运行完整的编程智能体体验——模型、工具、会话管理、文件读写和界面全部激活。代码模式（也叫 PTC 模式，即「提示词、工具、补全」）调整了模型接收工具调用结果的方式，用一部分交互性换取多步编程任务里的精确度。最小模式把 Harness 精简到核心部分，用于基准测试、CI 流水线，以及那些完整插件栈会带来干扰的可复现评测场景。

Creator Mode 是第四种模式。它激活了三项在其他模式里都不可用的新增能力：运行时检查工具，让智能体能查询自己当前加载的插件列表；内存中的插件实验能力，让智能体能构建出一个 Cordis 插件对象，而不必把它写入磁盘；以及一套预设创作工作流，把一个经过测试的插件打包成一个可分享的配置文件，其他用户可以一条命令直接加载。

运行时检查能力，是 Creator Mode 在架构上区别于其他所有模式的关键。当用户要求智能体「创建一个能做 X 的插件」时，智能体会先调用检查 API，读取当前 Cordis 插件图谱的状态——哪些插件已加载，它们声明了哪些依赖，它们向哪些事件通道发布消息、又从哪些通道订阅消息。它会用这个实时状态来指导新插件的设计，避免命名冲突，重用已有的事件基础设施，并继承那些已经在作用域内的认证或存储插件。最终得到的新插件，对自己将要进入的运行环境有结构性的感知，而不是照着一个静态模板写出来的。

在 Creator Mode 里构建的插件，会在同一个会话里以内存方式进行测试。如果插件出错——输出格式不对、缺少依赖、事件通道冲突——智能体可以在同一个会话里继续迭代，不需要重启 Harness。一旦插件跑通了，用户有两条路可走：通过插件管理器一键在本地安装，或者把它导出成一个预设配置文件，通过 dsh-plugin 这个 GitHub 话题生态分享出去——截至 2026 年 8 月 26 日，这个生态里大约有 11944 个被标记为 dsh-plugin 的仓库——这是一个原始的 GitHub 话题计数，其中包含一些并不含有真正可用插件的仓库。

Cordis 微内核：为什么自我修改在这里是可能的

Creator Mode 的本质，并不主要是一个「自然语言转代码」的功能。它是 Cordis 这个运行在 Harness 底层的微内核能力的一种体现，而要理解 Creator Mode 为什么能跑起来，需要先理解 Cordis 是什么、它当初是为了解决什么问题而设计的。

Cordis 在一篇研究论文《一种面向时空可组合性的编程范式》（arXiv: 2608.25512）中有详细描述。这篇论文提出了一种编程模型，在这个模型里，服务、工具和应用组件被当作可以独立加载和卸载的单元——即插件——由一个可逆的依赖图连接在一起。这里的「可逆」有一个具体的技术含义：当一个插件被卸载时，Cordis 会回滚它造成的副作用。数据库连接会关闭。事件订阅会取消。文件句柄会释放。这个插件加载之前的运行时状态，会被尽可能精确地恢复。

正是这种可逆性，让 Creator Mode 能够安全地在一个实时会话里运行。当智能体以实验性的方式构建一个新插件时，Cordis 可以安装它、测试它、再卸载它，而不会破坏其他已经在运行的插件的状态。如果这个实验性插件崩溃了，整个会话不会崩溃。依赖图会吸收这次失败，出问题的插件会被卸载，智能体可以带着修改后的实现重新尝试。如果没有这种回滚保证，在会话内创建插件对用户来说风险太大——毕竟用户可能一不小心就描述出了一个格式有问题的插件。

这套Cordis 架构，也定义了 Harness 里「万物皆插件」这句话到底意味着什么。DeepSeek 把这句话当作一条设计原则，而不是营销话术。模型本身是作为一个 Cordis 插件加载的。工具调用系统，也是作为一个 Cordis 插件加载的。会话管理、网页界面、存储、智能体循环，以及沙箱机制，全都是作为 Cordis 插件加载的。这意味着它们当中没有一个是硬编码进 Harness 核心的。用户可以替换模型插件——用 Claude、GPT-5.6 或一个本地量化模型，取代 DeepSeek V4.1-Flash——而不需要修改源代码，只需要编辑一个声明要加载哪些插件的配置文件。对那些关心数据管辖权的用户来说，这种与模型无关的设计意味着，Harness 可以完全针对本地托管的模型，或 DeepSeek 基础设施之外的服务商来运行。Creator Mode 把这套架构推向了它逻辑上的终点：现在用户本身也成了一个插件作者，而智能体是他们的创作工具。

支撑这套设计的依赖图，在正常运行时是无环的，但支持条件加载。一个插件可以声明自己依赖另一个插件，如果那个依赖还没加载，Cordis 会先把它加载出来。这正是 Creator Mode 能够在用户要求一个需要持久化数据的插件时，自动提议安装一个存储插件的原理——智能体在新插件的清单里声明这个依赖，Cordis 负责解析它。

七条演示提示词：文字转插件在实践中是怎么运作的

DeepSeek 发布了七条示例提示词，中英文都有，与 Creator Mode 的公告一同放出。这些提示词覆盖了一定的复杂度范围和插件类型，也揭示出一些从头条式的宣称里看不出来的系统特性。

最简单的演示创建了一个会话统计工具——一个实时面板，显示词元用量、会话数量、成本预算和 CPU 利用率。这条提示词不到两百个词。生成的插件用到了 Harness 自带的存储和界面插件，没有引入任何新依赖，也没有修改任何现有行为。这条提示词很可能只需要一轮生成就能稳定复现。

更复杂的演示覆盖了更广的插件类型。一个海报设计工作台，让用户能在一个实时 Harness 面板里自定义标题、正文文字和背景着色器颜色。一个交互式的 Transformer 三维可视化，把一次 Transformer 计算的每一步，都渲染成一个三维模型逐步展示出来，说明自注意力层和前馈层如何处理词元。一个三维地标展览厅，把埃菲尔铁塔、中国长城和故宫，作为可交互的三维地标放进了 Harness 界面里。一个像素风应用界面生成器，能用一个开关，在五种不同的视觉风格之间循环切换整个 Harness 界面。一个视频编辑工作台，提供多视频上传、预览、时间轴视图和导出控制，整体采用深色主题布局。还有一个论文阅读器，保留了原始文档的排版、字体和嵌入图片，同时加上了注释工具，以及一个会话内实时问答面板。这些提示词明显更长，并且引用了具体的 Harness API、事件通道和渲染能力。DeepSeek 在公告里明确提到，有些插件需要经过多轮打磨，才能达到演示展示出来的效果——单条提示词并不保证能精确复现出展示的结果。

这条限定说明在技术上是有意义的。Creator Mode 不是一个一次成型的代码生成器。它是一套迭代式的工作流，智能体和用户通过对话协作，不断打磨一个插件，直到它按预期工作。初次生成提供的是一个脚手架；后续的几轮，会根据用户反馈添加功能、修正错误，或改变行为。这种交互模式，对 Claude Code 或 GitHub Copilot 的用户来说很熟悉，但对 Harness 来说是新的——此前，Harness 一直要求用户针对 Cordis API，用 JavaScript 或 TypeScript 手写插件。

用双语发布这些提示词是刻意为之的。Harness 的国际用户群集中在中国、日本、韩国和东南亚，DeepSeek 也一直坚持把文档同时用中文和英文发布。dsh-plugin 这个 GitHub 生态反映了这一点——相当一部分社区插件仓库的文档是中文的，这说明很多 Harness 用户主要用中文工作。Creator Mode 的自然语言路径，对这些用户降低门槛的程度，比对以英文为主的开发者更大，因为他们现在可以用自己的主要语言来描述插件，不必再把自己的意图翻译成英文文档。

四种运行模式，以及它们在架构上意味着什么

要理解 Creator Mode 在 Harness 里处于什么位置，需要先清楚四种模式各自做什么、各自关闭了什么。

标准模式是默认模式。所有插件都会加载：模型、工具、会话管理，默认在本地 127.0.0.1:3080 上提供服务的网页界面（在运行npx @deepseek-ai/dsh web之后）、存储，以及智能体循环。这是大多数用户会接触到的模式。也正是在这个模式下，Harness 执行各种智能体编程任务——写代码、运行测试、编辑文件、浏览文档，以及管理长的多步骤工作流。

代码模式调整的是模型和工具之间的通信路径。在标准模式下，工具调用的结果会直接返回给对话上下文里的模型。代码模式对这些结果做不同的批处理，为那些模型需要在生成用户可见的回复之前，先处理大量工具输出的任务做优化。它主要适用于那些针对复杂多文件代码库运行 Harness 的用户——在这类场景下，中间的工具结果否则会让上下文用量迅速膨胀。

最小模式关闭了界面插件、完整的智能体循环，以及可选的诊断工具。它暴露出一个适合基准测试工具、CI/CD 流水线和集成测试的最小化接口。这正是针对DeepSWE v1.1运行 Harness 时所用的模式——这是一个智能体编程基准，按 DeepSeek 自报的数字，DeepSeek V4.1-Flash-1017 目前在这项基准上得分 77.0，高于 Claude Opus 5 的 74.0 和 GPT-5.6 Solution 的 73.0。值得指出的是，Claude Opus 5 和 GPT-5.6 Solution 的分数来自 Datacurve 的标准化评测榜单，而 DeepSeek 的 77.0 分用的是一套名为 Mini-SWE-V2 的不同评测配置；DeepSeek V4.1-Flash-1017 并没有出现在 Datacurve 榜单上，这让跨方法论的直接比较变得不精确。目前还没有发布对 DeepSeek 这个数字的独立验证。

Creator Mode 增加了前面几节描述过的检查、实验和预设创作工具。它是叠加在标准模式之上运行的——所有标准模式的插件仍然保持激活，Creator Mode 在完整的智能体环境之上叠加了自我修改能力。这种叠加方式意味着，Creator Mode 是唯一一种能让用户在不离开当前工作会话的情况下，构建、测试并安装一个新插件的模式。

DeepSeek V4.1-Flash-1017：一个为 Harness 量身定制的模型

默认驱动 Harness 的那个模型，在 2026 年 10 月 17 日经历了一次重大更新。DeepSeek发布了它称之为 DeepSeek V4.1-Flash-1017 的版本，这是其 V4.1 Flash 模型专门为 Harness 环境优化出来的一个检查点。公司建议使用 Harness 0.2.1-rc.1 或更新版本来配合这个更新后的检查点，并指出更早的版本在搭配这个新模型时，工具使用性能可能会下降。

V4.1-Flash 的架构是一种混合专家设计。在一个混合专家模型里，完整模型包含大量的参数模块——专家——但在推理时，每个词元只会激活其中的一个子集。这意味着模型的总参数量可以非常高，而每个词元的推理计算量，仍受限于被激活那部分子集的大小。对 Harness 来说，这个设计特别重要，因为工具调用这类负载涉及大量短小、结构化的生成步骤——解析工具调用语法、格式化参数、处理结果——而不是对话模型里常见的那种长篇自由生成。一个混合专家模型，可以在这类结构化短序列任务上保持快速，同时维持较大的整体知识容量。

10 月 17 日的这次发布，看起来专门针对模型的工具调用可靠性，以及它与 Cordis 插件 API 交互的能力做了优化。DeepSeek 没有就这个检查点发表技术报告，所以后训练具体做了哪些改动，目前并不公开。公开记录在案的，是基准测试结果：DeepSeek 自报的 DeepSWE v1.1 得分为 77.0，公司称这代表它在智能体编程任务上领先于 Claude Opus 5 和 GPT-5.6 Solution。由于 DeepSeek 是用自己的运行时跑的这项基准测试，也没有公开其测试配置，这个分数应该被当作一个公司自报的数字，等待独立评估。

Harness 0.2.1-rc.1 版本，也是第一个把 Creator Mode 明确列为稳定功能（而非实验性功能）的候选发布版本，这说明 V4.1-Flash-1017 的更新和 Creator Mode 是协同开发出来的。这次模型更新，可能包括了针对 Cordis API 使用模式的微调，让它更擅长从自然语言描述里生成有效的插件代码。

竞争格局：Claude Code、Codex，以及其他开放方案

DeepSeek Harness 所竞争的这个市场，在十八个月前根本不存在。这个品类——专为模型无关插件系统打造的开源智能体编程环境——有三个重要的竞争对手，以及几个规模更小的，而 Creator Mode 把 Harness 在这个竞争格局里的位置，推向了一个特定的方向。

Claude Code，Anthropic 的智能体编程工具，在开发者心智份额上是 Harness 最直接的同行。Claude Code 不是开源的；它是一个闭源的 CLI 工具，背后由 Anthropic 的模型 API 支撑。它的插件系统存在，但不像 Harness 那样能被用户以同样的方式扩展——它的 hooks 机制（hooks.json，Harness 把它作为一个兼容性桥接来支持）允许用户运行由特定智能体事件触发的脚本，但用户没法给 Claude Code 的运行时添加新的一等插件。Claude Code 的模型固定为 Claude；而 Harness 在设计上与模型无关，它的模型插件可以替换成任何兼容 OpenAI 接口的 API 端点。Creator Mode 让这个差距进一步拉大：Harness 用户现在能以 Claude Code 用户做不到的方式，扩展这个工具的能力，不需要提交功能请求，也不需要等 Anthropic 发版。

这场竞争还有一个企业层面的维度。企业在为内部部署评估智能体编程工具时，通常面临一个「自建还是采购」的决策：采用像 Claude Code 或 Codex 这样有商业支持的工具，还是投入资源去定制一个开源方案。Creator Mode 改变了这道算术题。因为现在 Harness 插件可以通过对话来创作，内部工具团队可以构建公司专属的集成——把 Harness 接到内部代码评审系统、文档平台或部署流水线上——而不需要深厚的 Cordis 专业知识。预设文件格式，让这些集成能在团队成员之间便携流转，并通过配置而不是代码来部署。对那些想让智能体行为贴合自己特定工作流、但缺乏从零编写生产级 Cordis 插件的工程能力的企业来说，Creator Mode 提供了一条中间道路。这解决了企业场景里对开源智能体工具最常见的一条质疑：定制能力理论上存在，但实际使用需要专业知识。

OpenAI 的 Codex（这里指智能体，不是最初的代码模型）同样是闭源的，且只能用 OpenAI 的模型。它的工具系统与 OpenAI 的函数调用接口紧密绑定，并没有暴露出类似 Creator Mode 这样的运行时扩展机制。

Pi是一个独立于 DeepSeek 开发的开源智能体运行时，在架构上是最接近的同行。Pi 同样把自己的核心组件当作可加载模块来处理，但它的扩展系统需要手动编写插件——用户必须通过实现一个定义好的 TypeScript 接口来编写插件，而不是用自然语言描述出来。Pi 的插件生态规模更小（社区贡献只有几百个，相比 Harness 接近一万两千个仓库），而且 Pi 没有一个与 Harness 的检查 API 对等的能力。

OpenHands（原名 OpenDevin）和 opencode 是另外两个重要的开源玩家。OpenHands 专注于具备强大多文件编辑能力的自主软件开发智能体；它没有一等的运行时插件系统。opencode 优先考虑本地执行和隐私，针对本地大语言模型推理运行，但它的扩展模型基于配置文件，而不是可在运行时修改的插件图谱。

竞争格局小结：Harness 是唯一一个智能体能够描述、构建并安装一个新工具——不暂停运行、不修改源代码、也完全不需要开发者写任何代码——的开源智能体运行时。这正是 Creator Mode 最核心的技术差异化所在。

平台飞轮：Creator Mode 作为一种跑马圈地战略

Creator Mode 最重大的意义，不在技术层面，而在战略层面。

在 Creator Mode 之前，DeepSeek 和那支打造出 Harness 的小规模贡献者团队，是 Harness 插件生态的主要作者——这支团队构建了最初那套模型、工具、存储和界面插件。社区则在这个基础之上构建扩展。进入门槛是真实存在的：编写一个 Cordis 插件，需要理解 Cordis API、TypeScript 插件接口、Harness 的事件系统，以及依赖是如何声明和解析的。

Creator Mode 把这道门槛拆掉了。现在任何 Harness 用户都可以描述出一个工具，让智能体把它构建出来，再把生成的预设发布成一个 dsh-plugin 仓库。截至 2026 年 8 月 26 日存在的那大约 11944 个社区仓库，是由开发者写出来的。下一波——至少最初阶段——可能会是由智能体自己创作出来的，用户的角色从编码者变成了需求描述者和测试者。

这形成了一个平台飞轮。更多用户意味着更多 Creator Mode 会话。更多 Creator Mode 会话，意味着 dsh-plugin 生态里更多的社区插件。更多的生态插件，会吸引更多开发者。更多开发者的采用，会推动更多GitHub star——截至 2026 年 11 月 2 日，Harness 的增长速度大约是每天 3300 个 star，比 Claude Code 和 OpenAI Codex 在各自生命周期可比阶段的增长速度加起来还快。

这个飞轮，还捕捉到了「谁在为这个平台付出劳动」这一点上一次具有经济意义的转变。为一个软件生态开发插件，通常需要付费的工程时间——无论是来自平台公司本身，还是来自那些有强烈财务动机去做集成的公司。Creator Mode 把插件开发变成了一种用户行为，把这份劳动分散到数百万人身上，他们为自己使用而构建插件，然后再分享出来。DeepSeek 从每一个被发布的预设中获益，却不需要亲自去写它。

这种模式是有先例的。WordPress 当年部分正是靠用户生成的插件——如今数量已达数万个——建立起了自己的市场主导地位。App Store 靠第三方开发者实现了规模化。Creator Mode 让 Harness 有机会跑出同一套打法的一个版本，只不过这次，贡献的初始门槛从编程经验变成了自然语言。真正的问题是，AI 生成的 Cordis 插件质量是否足够可靠，能让这些社区预设成为一种真正的资源，而不是一堆半成品实验的堆积。这还需要在规模化之后才能检验。

局限性、失效模式，以及目前还做不到的事

DeepSeek 的公告材料，语气是带有宣传色彩的，其中几个重大局限值得关注。

迭代打磨的必要性，是最现实的制约。DeepSeek 自己也承认，一些演示插件需要经过多轮对话才能正常工作。对简单插件——一个统计小组件、一个笔记面板——一两轮大概就够了。而对涉及自定义渲染、外部 API 调用，或复杂事件接线的复杂插件而言，需要多少轮是无法预判的，而用户可能需要理解 Cordis 内部机制，才能诊断出那些智能体自己无法自主修复的问题。

AI 生成代码中的插件质量，也是一个已知的隐患。关于大语言模型生成代码的研究一致发现，模型产出的代码看起来能用，却可能带有细微的安全漏洞、不正确的错误处理，或者对外部服务行为脆弱的假设。一个调用外部 API、处理用户认证，或存储持久化数据的 Cordis 插件，完全可能带着这类问题，而用户却毫无察觉。预设分享生态里，并不存在类似代码评审或安全审计那样的内置审核流程。

运行时检查能力本身也有范围限制。智能体可以读取哪些插件已被加载，并查询它们声明的接口，但它无法检查一个已有插件的内部实现，去理解它为什么表现出某种特定行为。如果用户要求 Creator Mode 去扩展一个已有插件——比方说给存储插件加一个功能——智能体只能依据它声明的 API 来工作，而不是源代码。这意味着 Creator Mode 能够有效地组合和配置已有插件，但不能安全地修改它们。

DeepSWE v1.1 的基准分数（DeepSeek V4.1-Flash-1017 为 77.0，Claude Opus 5 为 74.0，GPT-5.6 Sol 为 73.0）还没有经过独立复现。DeepSeek 是用自己的 Mini-SWE-V2 运行时进行测试并自行上报的；而作为对比的 Claude Opus 5 和 GPT-5.6 Solution 的分数，来自 Datacurve 标准化榜单，用的是另一套不同的运行时配置。这些并不是可以直接比较的测量结果。DeepSWE v1.1 是一个相对较新的基准测试，复现历史有限。在第三方评测方用相同的运行时配置和完全一致的测试条件发布结果之前，把这些分数当作确定性的性能排名还为时过早。

三个将决定 Creator Mode 能不能真正兑现的里程碑

三件事将决定 Creator Mode 最终会成为一项持久的竞争优势，还是一个在规模化面前力不从心的精彩演示。

第一，社区插件质量信号。dsh-plugin 这个 GitHub 话题提供了一个天然的实验场：随着 Creator Mode 生成的预设，在未来六十到九十天里在社区仓库里不断累积，开发者会逐渐形成自己的判断——AI 创作的 Cordis 插件到底是生产级可靠，还是停留在概念验证的水平。即便使用量在增长，一波有问题或不安全的预设，也会拖慢专业用户的采用速度。

第二，独立的基准复现。DeepSeek 的 DeepSWE v1.1 得分 77.0，是公司主张「V4.1-Flash-1017 是智能体编程任务上最强模型」最核心的论据。如果第三方评测方复现出这个区间的分数，会大幅强化 Harness 相对 Claude Code 和 Codex 的地位。如果独立评估显示差距比报告的更小，围绕 Harness 的叙事，就会从「同类最强模型」转变为「最好的开源替代方案」。

第三，Anthropic 和 OpenAI 的回应。Claude Code 和 Codex 都选择了不构建开放、用户可扩展的插件系统，而是选用与自家模型紧密绑定的专有扩展机制。Creator Mode 让这个选择背后的取舍变得更加显眼：Anthropic 和 OpenAI 的用户，没法靠对话来扩展自己的编程工具。如果 Creator Mode 能在专业开发者当中带来可衡量的 Harness 采用增长，就会增加压力，迫使这些闭源竞品开放自己的扩展 API，或者自己做出一套对等的自然语言创作工具。

Harness 于 2026 年 8 月 13 日发布。Creator Mode 在八十一天后到来。架构基础——Cordis 的可逆插件图谱、运行时检查 API、与模型无关的设计——从一开始就已经存在。真正花了八十一天去打造的，是那套面向用户的工作流，它让这套架构变得可用，而不要求用户去理解它。这种模式在平台发展史上并不陌生：先有基础设施，然后才有让大众真正用上它的工具。这种「大众化」能走多远，取决于生成出来的插件是否足够好、值得在其上继续构建，也取决于更广泛的开发者社区，是把 Harness 当作一个基础，还是仅仅当作一件方便的工具。