DeepSeek Harness：Creator 与 PTC，两种拆开 agent 的方式
1. DeepSeek Harness：Creator 与 PTC，两种拆开 agent 的方式
[!info] 文章信息
- 原文地址：https://u1-lab.xiaoxia.io/deepseek-harness-modes/
- 来源：Tony’s Lab
- 版本：v0.1 · dev preview（发布于 2026-08-14）
- 协议：MIT
- 阅读时长：约 9 分钟
Creator 改运行时，PTC 改调用方式。 一个让 agent 动手重写自己的工具与界面，一个把几十轮工具调用压成一段程序。它们都建立在同一个前提上：模型、工具、界面，全是可替换的插件。
1.1. 目录
- [[#00 先说清楚：Harness 是什么]]
- [[#01 Creator：把运行时本身交出去]]
- [[#02 PTC：把 N 次调用压成一个程序]]
- [[#03 怎么选]]
- [[#04 判断]]
1.2. 先说清楚：Harness 是什么
The Host
DeepSeek Harness（命令行 dsh）是 DeepSeek 在 2026 年 8 月 14 日开源的 agent 运行宿主，MIT 协议。它不是又一个聊天客户端，而是一套"把模型接进真实工作环境"的骨架：文件、终端、搜索、子 agent、定时任务、MCP，全部以插件形式挂上去。
底层是 Cordis 的**“一切皆插件”**架构。模型是插件，工具是插件，界面也是插件；插件可以组合、替换、在运行时装卸。这个设计带来一个直接后果：
[!quote] 核心论断
"agent 能做什么"不是写死的，而是这次会话装载了什么决定的。
所以它才有四种模式。它们回答的不是"模型多聪明"，而是同一个问题：这一次，把多少运行时能力摆到模型面前？
1.2.1. RUNTIME：Cordis 插件树
模型、工具、界面、服务都挂在同一棵树上。
插件挂载状态：
| 模块 | 状态 |
|---|---|
llmtools / fs / ui / mcp / jobs |
常驻 |
| native tools | ✅ ON |
| run_code | ⛔ OFF |
| SDK bindings | ⛔ OFF |
| cordis inspect | ⛔ OFF |
| plugin manager | ✅ ON |
| ui / skills | ⛔ OFF |
MODEL 可见面 — 全量常用工具：
- 常用工具
read/write/bash/grep… plugin_manageronrun_code- 运行时检查
[!tip] 关键概念
STANDARD 是日常默认。完整常用工具摆上桌，插件管理可用，但不暴露运行时检查和创作接口。四种模式不是能力高低，而是"这次会话向模型暴露多少运行时"。切换只改变可见面，不改变插件树本身。
1.2.2. RELEASE
- 发布于：2026-08-14 · v0.1 开发者预览
- 协议：MIT，完全开源
- 内核：Cordis 插件运行时
1.2.3. RUN
npx @deepseek-ai/dsh web
启动只需要 Node，默认在 127.0.0.1:3080 开一个本地界面。桌面版、Web 版、SDK 共用同一套运行时。
1.3. Creator：把运行时本身交出去
Reshape the Host
Creator 不是"更强的 Standard"。它多给的是一组指向运行时自己的工具：agent 能看见自己由什么组成，然后当场改。
1.3.1. 它具体多了什么
- 只读运行时检查：
cordis_inspect_list、cordis_inspect_query。查插件树、服务、事件、工具注册项——“这个工具是谁提供的”“为什么它没出现”，可以直接问。 - Plugin Manager：Standard 也有，但 Creator 里它是创作闭环的一部分。写一个配置 bundle，
plugin_manager install_bundle装进去。 - 热加载：开启 HMR 时，装完立刻在当前会话生效，不用重启进程。
- 预设创作：让 agent 创建或修改 preset，再起一个新的 agent 去测这套配置，构建、试用、迭代全在对话里完成。
- 插件市场：打开实验性的自定义索引后，多一个只读的
plugin_market，可以搜现成插件。 - 造工具、技能、界面：官方原话是 “Install plugins, or create them through chat in Creator mode, to extend tools, skills, and the interface.”
1.3.2. 一次完整的工作流
官方文档给的例子很能说明问题：让 agent 把一个 MCP server 配成当前 profile 的 demo。它会写一个只含配置的 bundle patch，插入 @deepseek-ai/dsh-mcp-client，用 plugin_manager 安装；HMR 生效后，在同一个会话里直接调用 mcp__demo__ping 验证。整个过程不需要你打开编辑器。
| 步骤 | 做什么 | 要点 |
|---|---|---|
| STEP 01 描述 | “把这个 MCP server 配成 demo，然后 ping 一下。” | 不需要知道包名和配置格式 |
| STEP 02 生成 | agent 生成一个 bundle patch | 改的是配置，不是运行中的内存；持久化，重启后仍在 |
| STEP 03 生效 | install_bundle 安装，HMR 把新工具接进当前会话 |
立刻调用验证，失败就改配置重来 |
| STEP 04 复用 | 绑定当前 profile | 该 profile 的所有会话都能用；也可打成 preset，做成专用 agent |
1.3.3. 真正的价值
它把"造工具"的门槛从写一个 Cordis 插件，降到了说清楚你要什么。对愿意读代码的人，这是效率工具；对完全不懂插件机制的人，这是危险品——因为你把修改自身运行环境的权限交给了模型。
[!warning] 四条边界，用之前先记住
- 仍是开发者预览，官方明确说会有破坏性变更。
- 插件代码跑在宿主进程里，权限等同你的本机。agent 自己写的插件，本质是供应链风险；装之前看一遍 bundle patch。
- Creator 的检查是只读的；持久修改必须走 “bundle + install_bundle”，不是随手改内存。
- 配置绑定当前 profile，影响该 profile 的所有会话，重启后仍在。别拿生产 profile 做实验。
1.4. PTC：把 N 次调用压成一个程序
Programmatic Tool Calling
PTC 全称 Programmatic Tool Calling。它把"模型点一下工具、结果塞回上下文、再点一下"的循环，换成"模型写一段程序，运行时替它跑完，只把结果带回来"。
1.4.1. 机制
- 模型手里只剩一个可直接调用的工具：
run_code。 - 其他所有工具变成生成式 SDK 的绑定：
tools.bash(...)、tools.read_file(...)、tools.grep(...)。 - 模型提交
code（async TypeScript 函数体，类型标注会被剥离）和一句description，这就是一次工具调用。 - 参数与返回值必须是 lossless JSON；单个调用失败会 reject 成
ToolCallError，带toolName和可读 message，可以try/catch后继续。 - 只有
console.log和return的内容回到对话；所有中间结果留在程序内部，不进上下文。
// 一次 run_code：读目录、找 TODO、只返回统计
const files = await tools.glob({ pattern: "src/**/*.ts" });
const hits = [];
for (const f of files.slice(0, 80)) {
const text = await tools.read({ path: f });
if (text.includes("TODO")) hits.push(f);
}
return { scanned: files.length, todo: hits.length, files: hits.slice(0, 10) };
1.4.2. 它省掉了什么
| 维度 | 传统 tool calling | PTC |
|---|---|---|
| 上下文 | 读 50 个文件 = 50 轮，结果都留在上下文 | 只回来一个统计对象 |
| 控制流 | 循环/条件/重试/聚合/排序只能靠多轮"演"出来 | 代码里是真的 |
| 并发 | — | 独立只读调用可 Promise.all，默认最多 10 路；写操作独占执行 |
| 确定性 | 靠模型手抄数字 | 筛选和计算在代码里跑，错得少 |
| 失败处理 | 单个失败易中断 | 可 catch 住降级，不中断任务 |
| 可审计 | — | 源码整段进 session log；子调用有 <parent>:ptc:<n> 的 id |
1.4.3. 默认参数
- 超时默认 120 秒，上限 600 秒，包含嵌套工具调用与审批等待。
- 顶层多个
run_code之间串行；并发只发生在单个程序内部，默认上限 10。 - 沙箱提权按"单次执行"授予，需要写
justification并等批准，不改变会话常驻策略。
[!caution] 代价也很实在
- 小任务不划算。生成 SDK 说明加写代码，比直接调一个工具贵。
- 中间值不落盘，不能从 session 回放重建；量大了可能吃爆内存。只有最外层输出有硬性上限。
- 调试更绕：内部出错只能看捕获输出和
Error: code run failed (<kind>)。- 它不是绕过权限：所有子调用照样走同一条策略与审批流水线。
1.5. 怎么选
Decision
把四种模式放在一张表里，差别其实很清楚：Standard 是默认，Minimal 是减法，PTC 是换执行方式，Creator 是换运行环境。
| 模式 | 模型看见什么 | 适合 | 主要代价 |
|---|---|---|---|
| Minimal | 最少的一组核心工具 | 纯问答、单步任务、省 token | 干不了复杂活 |
| Standard | 完整常用工具 + 插件管理 | 日常编码、研究、文件处理 | 工具 schema 占上下文 |
| PTC | 只有 run_code + 生成的 SDK |
批量操作、循环重试、多工具编排 | 写代码成本、调试更绕 |
| Creator | Standard + 运行时检查 + 创作能力 | 造插件、调预设、改界面 | 权限大、风险高 |
选型速查：
- ✅ 批量改代码 / 抓取 / 清洗 → 选 PTC。一次程序跑完，上下文只回结论，通常更稳也更便宜。
- ✅ 需要新工具 / 新界面 / 新预设 → 选 Creator。描述需求，让它生成插件并热加载；装之前读一遍 bundle patch。
- ✅ 只是问问题、改一两个文件 → 留在 Standard。切 PTC 反而多花生成代码的成本。
1.6. 判断
Take
这两个模式看起来都在"给 agent 更多权力"，但方向相反。
- Creator 扩展的是边界：agent 能给自己造工具，运行时长什么样由它参与决定。
- PTC 压缩的是成本：同一批工具，用程序调度，轮次和 token 都降下来。
真正跑生产任务时，PTC 往往比多轮对话更可靠，前提是模型代码写得对；而 Creator 更像一把改装工具，适合愿意读代码、能承担后果的人。两者都不适合"先开了再说"。
还有一点值得记住：它们能做到这些，不是因为模型变强了，而是因为宿主把运行时拆成了插件，并且愿意把拆开的接口交出来。
[!quote] 核心结论
能力来自架构，不来自提示词。先想清楚你要改的是"怎么干"，还是"能干什么"。前者用 PTC，后者用 Creator。—— 选型只需要这一句
1.7. 参考
- deepseek-ai/deepseek-harness
- 官方 Harness 页面
- 官方文档
docs/subsystems/ptc-runtime.md、docs/tool-catalog.md
[!note] 时效声明
内容基于 2026-11-02 的开发者预览，后续版本可能变化。