创造模式的设计定位DeepSeek Harness 的四种运行模式里创造模式Creative Mode是最特殊的一个。标准、PTC、极简三种模式都是即用型配置——加载固定插件集合、完成特定任务而创造模式更像是一个模式工厂让你基于现有能力去拼装新的运行模式。官方文档对这个模式的描述很克制运行时检查、内存中试验 Cordis 插件、组合和创作新的模式。这种克制是有原因的——v0.1 版本的创造模式本质上是个实验性功能官方在启动提示里就打过预防针核心插件和基础接口会在未来几个月快速演化。这意味着你在创造模式里写的任何代码都可能因为接口变动而失效。运行时检查摸清 Harness 实例的底细进入创造模式后第一件事通常是搞清楚当前 Harness 实例里有什么。Harness 基于 Cordis 插件框架构建所有能力都以服务Service和事件Event的形式挂载在上下文对象ctx中。通过ctx可以遍历当前已加载的插件和服务。比如查看可用的模型适配器// 在创造模式的 REPL 或脚本中 const llmProviders Object.keys(ctx.llm || {}) .filter(k typeof ctx.llm[k] object); console.log(当前模型适配器:, llmProviders);更深入的检查需要用到 Cordis 的内部 API。每个插件实例带有状态机可以通过ctx.registry或类似入口获取插件生命周期信息。实际输出通常包含插件 ID、加载状态loading/active/disposed、依赖图谱等。这些信息的格式在 v0.1 中尚未完全稳定不同构建版本可能有差异。一个实用的技巧是把当前实例的完整服务树导出为 JSON方便离线分析const inspect () { const services {}; const walk (obj, path) { // 递归遍历 ctx 上的服务挂载点 // 注意避开循环引用 }; return JSON.stringify(services, null, 2); };需要留意的是Cordis 的 Proxy 代理机制会让某些属性访问触发服务查找盲目递归可能导致意外副作用。建议对ctx的遍历加上深度限制和黑名单过滤。内存中试验插件加载与卸载的完整流程创造模式的核心价值在于无需重启进程即可试验插件。Cordis 的时空可组合性设计让这件事成为可能插件卸载时其注册的服务、事件监听和副作用会自动撤销。一个典型的试验流程是这样的第一步准备插件代码。假设我们要试验一个自定义的文件监控插件// my-file-watcher.ts import { Context, Service } from cordis; class FileWatcher extends Service { constructor(ctx) { super(ctx, fileWatcher); this.watcher null; } async start(path) { const { watch } await import(node:fs); this.watcher watch(path, (event, filename) { ctx.emit(file-change, { event, filename }); }); } // 关键dispose 方法确保卸载时清理资源 async dispose() { this.watcher?.close(); } } export default (ctx) { const instance new FileWatcher(ctx); ctx.plugin(instance); };第二步在创造模式中动态加载// 假设插件代码已作为字符串或模块引入 const myPlugin await import(./my-file-watcher.ts); // 通过 Cordis 的插件系统加载 const pluginHandle ctx.plugin(myPlugin.default); // 测试功能 ctx.fileWatcher?.start(./workspace); ctx.on(file-change, (data) { console.log(检测到变更:, data); });第三步观察效果后卸载// 卸载插件观察副作用是否自动清理 pluginHandle.dispose(); // 验证fileWatcher 服务应已不可访问 console.log(ctx.fileWatcher); // undefined 或 Proxy 抛错这个流程里最容易踩坑的是异步初始化的时序问题。Cordis 的插件加载是异步的但服务注册可能在plugin()返回前完成也可能延迟到下一个 tick。v0.1 版本中如果插件内部有异步的setup逻辑直接访问服务可能遇到竞态条件。建议用ctx.before(ready)或轮询等待。另一个细节是错误隔离。创造模式里的插件试验如果抛出未捕获异常可能导致整个 Harness 实例不稳定。建议在试验代码外层包上 try-catch并准备好进程重启的后手。组合新运行模式从试验到可用配置创造模式的终极目标是产出新的运行模式配置。Harness 的运行模式本质上是一组插件的集合声明通常以 JSON 或 YAML 形式描述。假设我们要组合一个带文件监控的标准模式可以从标准模式的插件清单出发{ name: standard-with-watch, extends: standard, plugins: [ { id: my-file-watcher, entry: ./plugins/my-file-watcher.ts, config: { watchPaths: [./src, ./config] } } ], conflicts: { minimal: 当前模式依赖标准模式的完整工具链 } }这个配置文件的extends字段体现了 Harness 模式的继承机制。实际生效时Cordis 会先加载基础模式的插件再叠加自定义插件最后处理依赖冲突。在创造模式里验证这个配置的过程是加载标准模式的插件集合额外加载my-file-watcher检查服务注册是否成功、事件监听是否正常运行一组基准任务确认没有破坏原有功能导出配置供后续通过--mode参数启动这里有个关键限制创造模式本身运行在内存中但新模式的配置需要持久化到文件系统才能被 Harness 的启动器识别。v0.1 版本的配置加载路径是硬编码的通常要放在~/.dsh/modes/或项目内的modes/目录下。如果路径放错命令行指定--mode时会报找不到配置。稳定性差异自定义模式的现实约束创造模式产出的自定义模式与官方预置模式在稳定性支持上有本质区别。官方四种模式标准、PTC、极简、创造由 DeepSeek 团队维护会随版本更新同步调整。比如极简模式已经被用于 Terminal Bench 基准测试其插件组合经过充分验证。而自定义模式完全依赖用户自己的测试覆盖一旦底层接口变动崩溃风险显著更高。v0.1 版本的快速演化承诺加剧了这种不确定性。官方在启动时的提示不是客套——过去两周内模型适配器的接口签名就已经有过调整。这意味着今天能跑的自定义插件下周可能就需要修改基于某个版本 Harness 导出的模式配置无法保证在后续版本直接可用创造模式里的试验代码不建议直接复制到生产环境一个比较务实的做法是把自定义模式当作草稿而非产品。在创造模式里验证想法、快速迭代等接口稳定后再固化配置。同时给每个能工作的配置打标签记录 Harness 版本号方便回溯。上手难度评估创造模式的上手门槛可以概括为懂 Cordis 则易不懂则难。如果你熟悉插件化架构的设计模式理解服务注册、依赖注入、生命周期管理这些概念创造模式会是个高效的试验场。几个小时就能搭出适配自己业务场景的运行模式。但如果对 Cordis 的时空可组合性机制没有概念很容易陷入改一行崩全局的困境——插件卸载不干净导致状态污染、异步时序踩不准、Proxy 代理的行为不符合直觉都是常见的卡点。v0.1 版本的文档和错误提示也还有很大提升空间。很多 Cordis 的内部机制需要读源码才能理解社区生态尚在早期遇到冷门问题很难搜到解决方案。总的来说创造模式适合这类开发者愿意承担接口变动风险、有插件框架使用经验、想把 Harness 改造成贴合自身工作流的形状。如果你只是想要一个稳定的 AI 编程助手标准模式或 PTC 模式会更省心。创造模式的价值在于可塑性而可塑性的代价就是维护负担——这在 v0.1 的实验阶段尤其明显。