DeepSeek Harness 是面向编码 Agent 与工具调用实验的开发者预览版运行环境。它将模型、工具、运行时能力和交互界面拆分为可组合的插件，并用 preset（预设）定义一组可直接运行的配置。选择运行模式，本质上是在选择 Agent 可见的工具范围、工具调用的编排方式，以及是否需要扩展或检查底层运行时。
四种官方模式并不是从“功能强”到“功能弱”的简单分级。标准模式关注完整的编码工作流；PTC 模式关注由模型编写 TypeScript 来组织多步工具调用；极简模式刻意压缩工具面；创造模式则面向插件、Cordis 运行时和自定义预设的开发。应先按任务目标选择模式，再决定是否增加插件或调整 preset。
Harness、preset 与插件的关系
- Harness：承载模型交互、工具执行和会话流程的运行环境。
- 插件：以模块方式提供具体能力，例如工具、运行时支持或交互能力。开发者可通过插件组合能力，而不是将所有功能固定在核心程序中。
- Preset：一份可复用的运行配置，用于选择和组织插件，从而形成某一种 Agent 工作方式。
因此，“切换模式”可理解为切换官方提供的 preset。对于自定义 Agent，不应假设某个模式天然包含所有工具；应以所选 preset 及其安装版本实际暴露的能力为准。
四种模式的能力边界
- 标准模式：面向完整编码 Agent 工作流。适合让 Agent 在常规软件开发任务中分析代码、修改文件、执行命令并迭代处理结果。它是需要综合编码能力时的默认选择。
- PTC 模式：通过 Code Mode SDK，使模型能够使用 TypeScript 编排多步工具调用。其重点不只是“调用一个工具”，而是让模型将条件、顺序、数据传递等流程写入代码式编排，适合工具链较长或需要明确中间控制逻辑的任务。
- 极简模式：仅保留持久 Bash 与
str_replace_editor。持久 Bash 适合在同一会话中保留命令行上下文；str_replace_editor用于基于字符串替换的文件编辑。该模式适合最小工具集实验和基准评测，不应把它当作完整开发环境的等价替代。 - 创造模式：用于检查运行时、试验 Cordis 插件和制作自定义 preset。它面向需要理解或扩展 Harness 组合机制的开发者，而不是只希望完成一次普通编码任务的终端用户。
按需求选择模式
- 编码开发：选择标准模式。适用于仓库级修改、调试、命令执行与代码编辑需要相互配合的任务。若任务并不需要改变插件构成，先从标准模式开始，能减少因工具面过窄或实验性配置带来的额外变量。
- 工具编排：选择 PTC 模式。适用于一个目标需要连续查询、处理结果、再调用后续工具的情况，例如根据前一步输出决定下一步操作。使用前要确认团队能够审阅模型生成的 TypeScript 编排逻辑，并对工具权限、输入和异常路径设置边界。
- 模型评测：选择极简模式。当目的是比较模型在受限工具环境中的命令执行、上下文保持和局部文件修改能力时，较小的工具集合更利于控制变量。评测记录应固定任务、仓库状态、模型参数和 Harness 版本；否则结果不能简单归因于模型或模式本身。
- 自定义 Agent：选择创造模式。它适合检查运行时行为、验证 Cordis 插件的组合效果，以及沉淀团队自己的 preset。建议先在隔离项目中验证插件加载、工具注册和会话行为，再将 preset 用于真实代码库。
能力对照与取舍
- 需要完整编码闭环：标准模式优先；重点是通用开发流程。
- 需要用代码表达工具调用流程：PTC 模式优先；重点是 TypeScript 与 Code Mode SDK 编排。
- 需要最少工具来做可控对比：极简模式优先；工具限定为持久 Bash 和
str_replace_editor。 - 需要研究或扩展运行时：创造模式优先；重点是 Cordis 插件与自定义 preset。
启动本地 Web UI
官方页面给出的快速启动方式是安装 Node.js 后，通过 npx 执行 Harness 的 Web 命令。开始前应确认命令行中可用的 Node.js 与 npm，并在希望作为当前工作目录的项目位置执行命令。
node --version
npm --version
npx @deepseek-ai/dsh web执行后，终端会输出本地 Web UI 的访问地址和运行日志；应以终端实际输出为准。首次使用 npx 时，包解析与下载可能需要网络访问。若命令无法运行，先检查 Node.js 是否正确安装、npm 是否可用、网络或企业代理是否允许获取所需包，再检查当前终端是否有项目目录的读写权限。
使用与升级注意事项
- 开发者预览版不等于稳定 API：Harness 仍处于开发者预览阶段，插件接口、preset 结构、默认行为或命令参数可能发生兼容性破坏变更。不要把未固定的默认行为直接作为长期生产依赖。
- 升级前保留可复现信息：记录当前使用的包版本、Node.js 版本、preset 配置、插件组合和测试任务。升级后先在副本或隔离环境运行同一组任务，再迁移到日常项目。
- 审查 PTC 生成的编排代码：TypeScript 编排会放大工具调用链的影响范围。对涉及删除文件、修改配置、访问凭据或执行高风险命令的工具，应通过权限控制、隔离目录和人工审阅降低风险。
- 不要误读极简模式的结果：极简模式缺少标准模式中的完整工具组合。其结果适合说明模型在给定最小工具集下的表现，不足以单独证明模型在完整编码工作流中的总体能力。
- 自定义 preset 要明确依赖：创造模式中制作的 preset 应显式记录依赖的插件和版本。仅依赖隐式默认项，升级后更容易出现加载失败或行为变化。
常见误区
- 把 PTC 当作标准模式的性能开关：PTC 改变的是工具调用的编排范式。只有在多步骤流程确实需要代码化控制时，额外复杂度才有意义。
- 把极简模式用于复杂工程代理：它只提供持久 Bash 与
str_replace_editor，适合受控实验或小范围任务。需要丰富工作流时应改用标准模式，或在创造模式中构建明确的自定义组合。 - 跳过版本验证直接升级：预览版的破坏性变更会使旧 preset 或插件假设失效。升级应视为一次兼容性验证，而非无风险的软件更新。
- 把创造模式当作普通用户入口：创造模式的价值在于运行时检查和扩展开发。若目标只是完成代码任务，它通常会增加不必要的配置与排错成本。
结论
希望获得完整编码 Agent 体验时选标准模式；要让模型用 TypeScript 组织多步工具调用时选 PTC；要在严格受限的工具面下做测试时选极简模式；要探索 Cordis 插件、运行时和自定义 preset 时选创造模式。开发者预览版尤其需要将版本、插件和配置纳入测试记录，避免把临时默认行为当成稳定契约。