来源：DeepSeek Harness

本文属于《DeepSeek Harness 入门教程（实战版）》· 第三部分 · 模型、预设与插件

第 9 章　Agent 预设：标准、PTC、极简与创造

上一章解决了“由哪个模型来做事”。这一章保持模型不变，只改变 Agent 预设，看看同一个模型怎样以不同方式使用工具。

你会完成两件事：先用同一条只读任务看清标准模式与 PTC 模式的执行差异，再用创造模式做出一个能在新任务中选用的自定义预设。

开始前，请确认 daily-report 工作区里仍有上一章的两个文件：

daily-report/
├── PROJECT.md
└── sources.json

本章不会修改这两个文件。四种预设的比较都使用同一个模型、Read Only 权限和独立新任务，否则结果差异无法归因到预设。

9.1 预设究竟改变了什么

Agent 预设不是模型，也不是权限档位。它是一套会话级的插件组合，决定模型能看见哪些工具、提示词和运行能力。

这三个概念不要混在一起：

设置	主要决定什么	本章怎么控制变量
模型	谁来推理和生成	全程使用同一个模型
Agent 预设	模型以什么工具组合和工作方式做事	分别创建四个新任务
权限	文件、命令等操作能否执行或需要审批	比较阶段都用 Read Only

因此，极简模式不天然只读，创造模式也不会自动获得无限权限。真正的安全边界仍由工作区、沙箱和审批策略控制。

当前版本把预设入口放在“代码工作工具”之下。若新任务页面看不到模式选择器：

1. 打开“设置 → 通用设置”；
2. 开启“代码工作工具”；
3. 返回新任务页面重新查看模式选择器；
4. 也可以在“设置 → Agent 预设”中查看内置和自定义预设。

v0.1.7-rc.2 已移除旧版单独的“模式选择”开关。“代码工作工具”现在统一控制执行轨迹、代码差异和新任务的模式选择；保存的默认预设会用于之后的新任务。版本说明

预设在任务创建时组装。更改默认值只影响之后创建的任务，已经开始的任务不会被改造成另一套工具环境。Agent 预设界面官方说明

9.2 四种内置预设的分工

先用一张表建立直觉，后面再动手验证：

预设	工具如何呈现给模型	适合的任务	不要把它误解成
标准模式	模型直接逐个调用文件、Shell、搜索等原生工具	日常开发、排错、文档和不确定性较高的任务	“简单模式”
PTC 模式	模型先写一段 TypeScript，再通过 run_code 中的 SDK 组合工具调用	批量读取、筛选、分类、循环和并行处理	更强模型或缓存开关
极简模式	只保留持久 bash 与 str_replace_editor	基准测试、最小环境实验	更安全或一定更省时
创造模式	在标准能力上增加运行时检查、插件实验和预设创作指导	创建或调整自定义预设、扩展 DSH 本身	日常任务的“增强版标准模式”

这是产品当前给出的四种定位。DeepSeek Harness 产品页还明确说明：标准模式提供完整工具组合；PTC 用模型生成的代码组合多轮工具调用；极简模式用于最小环境下的模型基准测试；创造模式用于检查运行时并创作新模式。

设置页的“查看配置”会以只读 YAML 显示一个预设声明的插件列表。以后如果安装了插件或版本更新后怀疑实际能力发生变化，以这里显示的当前配置为准，不要只凭预设名称猜测。

9.3 标准模式：让模型一步一步决定

新建一个任务，保持上一章已经验证过的模型不变，选择“标准模式”，权限设为 Read Only。发送下面的任务：

请实际读取当前工作区中的全部 .md 和 .json 文件，完成一次只读盘点。

要求：
1. 列出实际读取的文件；
2. 统计每个文件的行数，并概括其结构；
3. 解析 sources.json，检查它是否为数组、每项是否只有 name 和 url、url 是否以 https:// 开头；
4. 对照 PROJECT.md，判断现有文件是否足以开始实现首版日报助手；
5. 用表格给出结论和证据。

不要修改文件，不要访问网络，也不要只根据历史对话作答。

标准模式通常会把动作拆成一连串直接工具调用：先列出文件，再读取 PROJECT.md 和 sources.json，必要时调用 Shell 做统计，最后让模型根据返回结果继续判断。具体工具名和调用次数可能随模型而变化，不必追求与示例完全一致。

你真正要观察的是执行轨迹的形状：模型发起一个原生工具调用，结果回到模型，模型再决定下一步。可以概括为：

模型 → 列文件 → 结果回到模型 → 读文件 → 结果回到模型
     → 解析与判断 → 输出报告

检查最后的报告。sources.json 应有两个来源，每项包含 name 和 url；现有两个文件只完成了需求和数据源配置，还没有程序、测试和输出文件。

最后打开代码变更区域，确认没有新增或修改文件。模型说“没有修改”不是验收依据，零差异才是。

9.4 PTC 模式：让模型用程序编排工具

PTC 在这里指程序化工具调用，不是 DeepSeek API 的前缀缓存开关，也不是另一种模型。

它和标准模式最关键的区别不在任务答案，而在工具怎样交给模型：

• 标准模式把每个可见工具作为独立函数直接交给模型；
• PTC 模式只把 run_code 作为直接入口，同时生成一份 Code Mode SDK；
• 模型在临时的 TypeScript 程序里通过 await tools.<工具名>(...) 调用原有工具；
• 内层工具调用仍会经过原来的权限、审批和执行链路，并不会因为包在代码里就绕过安全控制。

工具系统官方说明把两种呈现方式称为 native 和 ptc：前者直接暴露工具定义，后者暴露 run_code 与自动生成的 SDK。

现在新建第二个任务，使用与刚才完全相同的模型和 Read Only 权限，只把预设改为“PTC 模式”。再次发送上一节同一条盘点任务。

这次轨迹通常更接近下面这样：

模型 → run_code(TypeScript)
          ├─ 列出候选文件
          ├─ 读取多个文件
          ├─ 统计与解析 JSON
          └─ 返回整理后的结构化结果
     → 模型输出报告

在工具卡片或轨迹中，你应该看到外层的 run_code。展开后，可以看到模型生成的程序以及其中触发的工具子调用。PTC 的优势正出现在“先拿到列表，再循环读取、筛选、并行处理、汇总”的任务中：中间结果可以先留在程序变量里，不必每一步都返回模型再做一次决定。

这不代表 PTC 必然更快、更便宜或答案更好。它要求模型不仅会做任务，还要写对工具编排代码。只读一个文件或改一行文字时，额外写一段程序反而可能增加成本；面对几十个文件的相同检查时，循环和并行才更有价值。

完成后做三项对照：

检查项	标准模式	PTC 模式
最终事实	应该一致	应该一致
轨迹入口	多个原生工具调用	外层 run_code + 内层工具调用
工作区差异	无	无

如果 PTC 没出现 run_code，先确认这确实是新任务，任务标题或会话头显示的是 PTC 预设，而不是在旧的标准模式任务里继续发消息。如果答案正确但轨迹很短，也不代表 PTC 失效；这个项目目前只有两个文件，任务规模还不足以产生巨大的时间差。

一句话记住两者：

标准模式让模型边看结果边决定下一步；PTC 模式让模型先写一个小程序，再由程序组织多步工具调用。

9.5 极简模式：减少工具变量，不等于降低风险

新建第三个任务，选择“极简模式”，仍保持 Read Only。发送一个范围很小的检查：

只读检查 sources.json 是否为合法 JSON，并报告数组长度和两个 name。不要修改文件，也不要访问网络。

极简模式没有标准模式那套完整的计划、搜索、Skills、子智能体和工作流能力。它主要依靠持久 bash 查看环境、运行命令，再用 str_replace_editor 编辑文件。当前任务是只读的，所以你更可能看到它通过 Bash 或编辑器读取 sources.json。

这种受控工具环境适合比较不同模型的基础工具使用能力：模型、任务、项目都不变，只给相同的两个工具，变量更少。但它并不是日常工作的“极速模式”。真实项目需要检索、规划或子智能体时，主动删掉这些能力通常只会让任务更难。

也不要因为“极简”二字放松警惕。Bash 和文件编辑器已经足以删除或改坏文件；如果把权限切到 Workspace Write 或 Full Access，风险仍然存在。

9.6 选修：主线完成后，在独立 Profile 创建预设

创造模式的任务对象不是“日报助手代码”，而是 DSH 自己的运行配置。它可以检查当前运行时、设计插件组合，并通过持久化 bundle 安装新的预设。安装会修改当前 Profile，而且可能影响之后创建的其他任务，所以不要直接在主项目里边试边改。

先完成第 11～13 章，再按第 16 章创建并验证独立 daily-report-lab Profile。确认当前连接的是实验 Profile 后，才创建下列空目录；只换工作区不会隔离配置：

macOS 或 Linux：

mkdir -p "$HOME/dsh-preset-lab"

Windows PowerShell：

New-Item -ItemType Directory -Force "$HOME\dsh-preset-lab"

在 DSH 中把这个目录添加为独立工作区，然后打开“设置 → Agent 预设”。在“自定义”区域点击“用创造模式创作自定义预设”。系统会创建一个使用“创造模式”的新任务；设置页本身只负责查看和选择，不直接编辑预设。

我们要做一个“日报审阅”预设：保留标准模式的常用能力，但增加一组稳定的审阅规则。它不是安全沙箱，真正要限制写入时仍应搭配 Read Only 权限。

把下面这段需求发给创造模式：

请为当前 Profile 创建一个新的自定义 Agent preset，要求如下：

- preset id：daily-report-review
- 显示名称：日报审阅
- 以当前内置的标准模式为基础，不修改、覆盖或删除任何内置 preset；
- 保留标准模式的原生工具呈现和常用能力；
- 增加一段明确的工作规则：处理日报助手任务时，先读取 PROJECT.md 与 sources.json；输出结论时按“结论、证据、风险、下一步”组织；没有文件或工具证据时，不得声称任务已经完成；
- 不安装外部依赖，不联网，不增加 MCP、UI 插件或新的系统命令；
- 不把它设为默认 preset。

先检查当前可用的 preset 与配置格式，给我展示计划、将创建的 bundle/文件和持久化影响。等我确认后再安装。安装后请验证它能够出现在 Agent 预设列表中，并报告保存状态与实际启用状态。

先不要急着批准。检查创造模式给出的方案是否满足三条底线：

1. 创建的是新 ID daily-report-review，不是改写 standard、ptc、minimal 或 cordis；
2. 没有为了这段简单规则引入网络包、未知脚本或 Full Access 常驻设置；
3. 明确区分“文件已生成”“bundle 已安装”“新预设已能创建任务”，不能把三者混为一谈。

方案没有越界后，再回复“确认按这个方案安装”。持久化安装可能出现一次权限审批，因为预设 bundle 会写入当前 Profile，并可能加载拥有 Host 权限的代码。审批卡片中应能看出操作目的是安装刚才审阅过的本地 bundle；如果理由含糊、出现陌生网络地址或要求长期 Full Access，先拒绝并让它解释。

创造模式当前通过插件管理器安装持久化 bundle；保存后的配置会跨重启存在，并可能通过热更新进入当前 Profile。官方实现说明也强调，这类 Profile 变更需要 Full Access 或一次明确审批。

9.7 验证自定义预设，而不是相信“创建成功”

创造模式报告完成后，按下面顺序独立验收：

1. 打开“设置 → Agent 预设”；
2. 在“自定义”分组找到“日报审阅”，确认 ID 为 daily-report-review；
3. 点击“查看配置”，确认它没有覆盖内置预设，也没有意外加入外部依赖；
4. 不要先把它设为全局默认；回到 daily-report 工作区新建任务；
5. 在新任务的预设选择器中选择“日报审阅”，模型保持不变，权限选择 Read Only；
6. 发送下面的验证任务。

请评估当前日报助手是否已经达到 PROJECT.md 中的首版验收标准。只读检查，不要修改文件，不要访问网络。

正确的表现不是机械复述预设名称，而是：

• 先实际读取 PROJECT.md 和 sources.json；
• 说明当前只有项目约定和来源配置，尚无实现、测试与 daily-report.md；
• 按“结论、证据、风险、下一步”组织结果；
• 没有把尚未完成的功能说成已经完成；
• 工作区代码差异仍为空。

再看任务头部或预设标签，确认当前任务记录的是 daily-report-review。至此才算完成了“保存 → 出现在列表 → 能创建任务 → 行为生效 → 零文件改动”的闭环。

验证通过后，如果你确实希望以后新任务都用它，再到“设置 → Agent 预设”选择它作为默认。默认值不会改造已有任务。

如果自定义预设导致新任务无法创建，不要重装 DSH，也不要继续修改内置配置。因为我们没有把它设为默认，直接在新任务选择器或“设置 → Agent 预设”切回标准模式即可；随后回到插件管理或创造模式，检查 bundle 的加载诊断并移除或修正这份自定义配置。

9.8 用四个问题选择预设

以后不必背功能表，按下面顺序判断即可：

1. **这是普通的开发、分析或文档任务吗？**先用标准模式。
2. **任务是否包含大量重复、可程序化的工具操作？**考虑 PTC 模式。
3. **我是否在做模型基准或最小工具实验？**使用极简模式。
4. **我是否要改变 Agent 自己的插件组合或工作规则？**进入创造模式；若流程会反复使用，再把结果保存为自定义预设。

不要因为 PTC 或创造模式看起来更高级，就把它们设成所有任务的默认答案。标准模式最适合处理未知情况；PTC 的收益来自可程序化的工具链；极简用于控制变量；创造模式则面向 DSH 本身。

9.9 本章验收

进入下一章前，请确认：

• 能解释模型、Agent 预设与权限的区别；
• 已用同一模型和同一任务比较标准模式与 PTC 模式；
• 能从轨迹中认出原生工具调用与 run_code 的差异；
• 知道 PTC 适合批量、循环、筛选和并行操作，但不保证所有任务更快；
• 知道极简模式用于最小工具环境，不等于只读或低风险；
• 已通过创造模式安装并验证 daily-report-review 自定义预设；
• 自定义预设尚未被贸然设为默认，失败时可以切回标准模式；
• daily-report 工作区仍只有原来的两个文件，代码差异为空。

下一章开始进入 DSH 的核心：插件系统。我们会先认清内置插件配置，再安装和验证一个代表性插件，并把“预设是插件组合”这句话真正落到操作上。

---

← 上一章：模型 Provider：官方、内置与自定义　|　回目录　|　下一章：插件系统：配置、启停与验证 →