DeepSeek Harness 四种模式：Standard、PTC、Minimal、Creator 怎么选
实用对比 DeepSeek Harness Standard、PTC、Minimal、Creator 四种模式：分别改变什么、适合什么任务，以及 PTC 与权限边界真正应该怎么理解。
本页内容
DeepSeek Harness 到底应该选哪个模式？
大多数仓库开发先用 Standard。任务适合把一串工具调用组合进一个 TypeScript 程序时，再考虑 PTC。你明确只想保留 persistent bash + str_replace_editor 时用 Minimal。你要检查运行时、实验插件或创建自己的 Agent Preset 时用 Creator。
本文按 0.1.2-alpha.5（核验于 2026-09-03）编写。当前 Web UI 把这四项称为内置 Agent Preset；切换 Preset 改的是 Session 面向模型的 Agent 组合，不是把底层 DeepSeek 模型换成另一个模型。
四种内置模式怎么区分
真正的问题不是“哪个最强”，而是“这个 Session 应该暴露什么工具面”。工具更多不一定更好；合理的 Preset 应该保留任务需要的能力，同时减少无关工具面。
Standard
适合：普通开发和仓库任务的默认选择
主要变化：完整 Coding Agent：编辑、Shell、文件/网页搜索、Skills、Planning、Goals、Subagents、Workflows
不优先选：你明确需要更窄或代码编排式的工具面
PTC
适合：多步骤、机械性强、适合组合多次工具调用的任务
主要变化：完整 Coding Agent，但不提供 workflow 工具；其他工具通过 PTC SDK 暴露，可由模型写成一个 TypeScript 程序组合执行
不优先选：任务很短、需要频繁判断，或你不希望执行模型生成代码
Minimal
适合：Benchmark、受控实验、刻意缩小工具面的场景
主要变化：只保留 persistent bash 与 str_replace_editor
不优先选：需要搜索、Subagent、Planning、Workflow 等 richer tools
Creator
适合：制作或测试自定义 Agent Preset
主要变化：Standard 能力 + 运行时检查 + 插件实验 + Preset 编写指导
不优先选：只是正常改代码，没有要改 Agent 组合
最快决策法
- 01
你是在创建/修改 Agent Preset 吗？
用 Creator。
- 02
你就是想只留 bash + str_replace_editor 吗？
用 Minimal。
- 03
任务能否把多次工具调用打包进一个 TypeScript 程序？
考虑 PTC。
- 04
其他情况
用 Standard。
同一个任务，Standard 和 PTC 会怎么做
假设你让 DSH 找出仓库里全部 API endpoint，读取相关文件、按 endpoint 分类，最后给一份压缩报告。两种模式都能完成，但模型看到的执行过程可能不同。
Standard — 工具调用保持显式
搜索仓库
→ 模型读取搜索结果
→ 读取相关文件
→ 模型检查文件内容
→ 继续搜索/读取
→ 汇总
→ 回答PTC — 编排可以进入 run_code
模型生成 TypeScript
→ run_code({ 搜索 → 读取 → 过滤 → 汇总 })
→ 返回压缩后的外层结果
→ 回答PTC 不保证每个任务都更省 Token 或更快。它真正的架构优势是：中间 binding 调用和中间值可以留在执行内部，模型主要接收外层 run_code 结果。短任务、需要频繁人工判断的任务，Standard 往往更简单、更容易审查。
四种模式分别是干什么的
Standard：正常使用就先选它
Standard 是日常 Coding 最不容易出错的起点。当前 UI 把它描述成完整 Coding Agent，包括文件编辑、Shell、文件与网页搜索、Skills、Planning、Goals、Subagents 和 Workflows。没有明确理由缩小或重新包装工具面时，优先 Standard。
PTC：让代码来编排工具调用
PTC 仍然是 Coding Agent Preset，但工具呈现方式不同。当前 UI 明确说它不暴露 workflow 工具，其他工具通过 PTC Mode SDK 提供，让模型能把多步骤操作组合成一个 TypeScript 程序。当前实现需要 code runtime，并通过 run_code 承接这种模型侧编排。
不要把当前 TypeScript worker 当成安全沙箱。官方 alpha.5 runtime 文档明确写的是 containment，不是 security boundary，信任级别接近 bash。它确实使用独立 Node worker、空环境、内存/输出/时间预算和硬终止，但模型生成的代码可以访问 Node API，而且它拉起的 OS process 甚至可能在 worker terminate 后继续存在。DSH 工具 binding 有自己的工具语义，但 run_code runtime 本身仍是另一层信任问题。
Minimal：刻意缩小，不是“轻量 Standard”
Minimal 只组合 persistent bash 与 str_replace_editor。官方实现说明特别强调：Browser UI、Workspace Attachment、Persistence、Subprocess、Sandbox、Permission、Model Routing 等跨 Session 服务仍由 Host 管理。也就是说，Minimal 缩小的是一个 Agent 面向模型的组合，并不是把整个 DSH 进程换成另一套产品。
Creator：目的就是制作另一个 Preset
Creator 的目标不是日常 Coding，而是 Preset Authoring。当前 UI 描述的是 Standard 能力再加运行时检查、插件实验和 Preset 编写指导。更合理的理解是：先在运行时实验组合、检查挂载内容，再把真正要长期使用的结果落到自己的 Preset 文件里，而不是把一次内存实验当成最终配置。
Mode、Model、Profile、Permission 不是一层东西
把这几层分清楚，很多配置问题会直接消失。Mode 本质是 Agent Preset，决定一个 Session 给模型看到的 Agent 组合；它不会自动替你换 LLM。Provider 和 Host 服务在其他组合层管理，Permission/Sandbox 也不能仅凭 Standard、Minimal、Creator 这些名字判断。Minimal 的官方说明就是最直接的证据：Agent 工具面变小后，Model Routing、Sandbox、Permission 仍然由 Host 持有。
Mode / Preset
这个 Session 有哪些工具和 Agent 组合。
Model
这个 Session 实际把请求路由到哪个 LLM。
Profile / Host 组合
进程级安装了哪些 Package、Provider 和 Host 服务。
Permission / Sandbox
哪些操作需要批准或受到 Host/Tool 层约束；它不等同于选择某个 Preset。
四个内置模式都不够时怎么办
当前 Web UI 已经区分 Built-in 与 Custom Preset。DSH 可以把一个 Preset 完整复制到本机；identifier 会成为 Preset 目录名，之后不能再改，但复制后的文件可以继续编辑。已经运行的 Session 会继续使用启动时的 Preset，因此修改后应该新开 Session 测试。Creator 也能辅助起草 Custom Preset，但生成结果仍应该按代码/配置审查。
大多数用户建议这样走
第一次真实任务先用 Standard。理解正常工具流之后，再拿一个可重复的多步骤任务测试 PTC；明确需要受控工具面时再用 Minimal；只有当你愿意维护自己的 Agent 组合时再进入 Creator。这样切换模式是因为工作流提出了明确需求，而不是凭感觉认为“另一个模式更强”。
DeepSeek Harness 模式常见问题
PTC 一定比 Standard 更好吗？
不是。PTC 适合用代码紧凑编排多次工具操作；普通交互式 Coding 用 Standard 通常更透明。
切换模式会换 DeepSeek 模型吗？
不会。Mode 是 Agent Preset/工具组合，Model Routing 是另一层。
Minimal 工具少，所以一定更安全吗？
它确实缩小模型可以直接调用的工具面，但 Host 的 Sandbox、Permission 等仍然独立存在。工具少不等于完整安全边界。
PTC 的 run_code 是沙箱吗？
当前官方文档明确说不是安全边界。Worker 提供隔离式 containment 和资源限制，但模型代码按 bash-equivalent trust 看待。
正在运行的 Session 能从 Standard 切到 Creator 吗？
Preset 变化作用于新 Session；已经运行的 Session 继续使用启动时的 Preset。
应该直接改 Built-in Preset 吗？
更稳妥的做法是复制成 Custom Preset，再修改并测试副本，让内置版本保持干净参照。