如果你刚装上 DeepSeek Harness，大概率会在界面上和这四个 Preset 打个照面：极简、标准、PTC、创造。我最初以为这跟很多工具里的"风格模板"差不多，无非是换个提示词或者换个语气，直到我拿同一段需求分别跑了四个模式，输出内容从"一句结论"到"分步执行加验证报告"都有，差异大得完全不是"风格"两个字能概括的。这篇文章我会把这四种 Preset 的底层逻辑、适用场景、参数影响和我在实际部署及日常使用中踩过的坑一次讲清楚，帮你判断到底该选哪个，以及怎么在日常会话里灵活切换它们。
先说清楚一个核心观点：Preset 不是给你换肤用的，它决定的是模型在本次会话里的"推理链路"。选错了，不是输出风格不合口味的问题，而是任务能不能完成、完成到什么程度的问题。
1. Preset 的本质：它到底改了什么参数，又是怎么影响输出的
1.1 从"同一个模型"到"不同的行为模式"
DeepSeek Harness 本身是一个模型调用和任务编排工具，底层模型可以是大模型服务，也可以是本地部署的开源权重。Preset 的设计思路，是在不换模型的前提下，通过一组预设的采样参数、上下文管理策略、工具调用权限和规划能力，把模型的"性格"临时塑造成四种形态。
打个比方：同一个厨师，你给他一张"五分钟出餐"的指令，他会做一碗快速面；你给他"米其林晚宴"的指令，他会先列菜单、备菜、按顺序出餐。模型没变，变的是约束条件和执行流程。Preset 就是这套约束条件和流程的组合包。
具体来说，Preset 主要控制四类东西：
- 采样参数：温度（temperature）、top_p、频率惩罚等，决定输出的确定性与发散程度。
- 上下文处理：如何压缩历史对话、保留多少关键信息，影响长对话中的记忆能力。
- 工具调用策略：是否允许模型调用插件、读文件、执行代码，以及调用的开放程度。
- 规划与执行：是否强制模型先拆解步骤再执行，以及完成后是否要做校验。
这四个维度一组合，就产生了四种差异化的行为模式。如果你把这些参数看成一把螺丝刀，Preset 就是按不同场景拧好扭矩的电动批头，换批头不换机器。
1.2 四种 Preset 的定位总览
我先给一张速览表，把四种 Preset 的核心差异摆出来，下面几节再逐个剖析。
| 维度 | 极简 Minimal | 标准 Standard | PTC | 创造 Creative |
|---|---|---|---|---|
| 温度 | 低（0.1 左右） | 中（0.7 左右） | 中低（0.3 左右） | 高（1.0 以上） |
| 输出确定性 | 高 | 中 | 高 | 低 |
| 长文本倾向 | 低 | 中 | 中高 | 高 |
| 工具调用 | 默认关闭或只读 | 常用工具按需 | 全量工具+强制规划 | 仅检索/引用类 |
| 上下文保留 | 激进压缩 | 动态裁剪 | 按任务阶段保留 | 宽松保留 |
| 典型场景 | 快速问答、接口调试、格式转换 | 日常对话、代码编写、文档总结 | 多步骤工程任务、自动化流程、复杂分析 | 文案写作、头脑风暴、创意发散 |
看这张表你会发现，极简和创造几乎在每一个维度上都是对立的，而标准是中间态的均衡配置，PTC 则走的是"高结构化执行"这条独立路线。
2. 极简与标准：日常最常用的两个模式，差异比想象中大
2.1 极简模式：什么时候"少即是多"
极简模式的核心是追求最少的 token 开销和最快的响应速度。它会把温度压到很低，几乎关闭了工具调用能力，同时启用激进的上下文压缩策略，只保留对话中最核心的几轮信息。这样一来，模型在回答时会倾向于给出最直接、最保守的答案——不多解释，不主动扩展，不尝试调用外部工具。
我最初觉得这个模式"没什么用"，直到我拿它跑了几类任务才意识到它的价值：
- 格式转换类任务：比如把一段 JSON 转成 YAML，或者把 Markdown 表格转成 CSV。这种任务不需要解释，只需要精确的结果。极简模式给出的输出干净到可以直接拿去用。
- 快速验证类需求：你想确认某个函数名是不是这么写，某个配置项有没有拼错，丢给极简模式，它只回"是/否"或修正后的内容，不带任何废话。
- API 调试助手：在 Harness 里接入 API 时，极简模式特别适合做短平快的参数调试。
当然它的短板也很明显：模型不会主动告知潜在问题，不会补充边界条件。你问"这段代码有 bug 吗"，它可能只回一句"第 7 行少了个括号"，而标准模式会顺带告诉你为什么少括号会导致解析失败。如果你需要的是"带解释的完整答案"，极简模式会让你觉得太干瘪。
2.2 标准模式：多数人的默认推荐，但不是万能解
标准模式是 Harness 的出厂默认，也是最像"正常对话"的一种预设。它在采样参数上取了一个比较均衡的中值，温度大概在 0.7 左右，既保留一定的多样性，又不会离谱；工具调用策略是"按需开启"，模型判断需要读文件、查资料时会主动调用相关插件；上下文管理采用动态裁剪，保留对当前任务最相关的历史信息。
这个模式最典型的适用场景是：
- 日常代码生成与解释：让它写一个函数，它会给你完整实现，顺带说明思路，还会提醒你注意边界情况。
- 文档总结与信息提取：给它一篇长文，它能提炼出关键信息，并在回答末尾附上来源段落索引。
- 常规方案咨询：问你一个技术选型问题，它会给出对比、推荐和理由，结构清晰，不过度发散。
但标准模式的"均衡"也意味着它没有特别突出的长板。遇到复杂多步骤的工程任务，它经常会"做到一半停下来等你确认下一步"，不会主动规划完整的执行链路。遇到需要大量发散创意的写作任务，它又显得有点克制，放不开。
我在日常使用中的建议是：如果你刚上手 Harness 不知道选哪个，先用标准模式跑一周。多数任务它都能应付，只有在它明显让位的时候，再往极简、PTC 或创造方向切换。
3. PTC 模式：复杂任务的执行引擎，不是给所有人准备的
3.1 PTC 到底全称是什么，又改了什么
PTC 在标题里直接用了缩写，很多第一次看到这个模式的用户会一头雾水。按 Harness 的设计文档，PTC 全称是 Plan-Task-Control，翻译过来是"计划-任务-控制"。它和标准模式最大的区别，不是采样参数的高低，而是引入了一条强制的执行链路：
- 规划阶段：模型会先拆解用户请求，生成一个分步骤的执行计划。
- 任务阶段：按计划逐项执行，每一步都可以调用工具、读取文件、执行代码或发起检索。
- 控制阶段：全部步骤执行完后，模型会回到初始目标做一次校验，检查结果是否完整覆盖需求，有遗漏会补救。
为了支撑这条链路，PTC 模式下的工具调用权限被放到最大，同时上下文保留策略变成"按任务阶段保留"——每一阶段的关键输入输出都留在上下文里，方便后续步骤引用。温度压到 0.3 左右，确保规划链条不跑偏。
3.2 用 PTC 跑通一个多步骤任务的实操示例
我举个实际例子：有一次我需要让 Harness 从一份接口文档里提取所有 API 端点，并生成一个带参数的 Python 调用脚本，最后还要校验脚本能否通过语法检查。
标准模式下，模型给我写了一个脚本框架，但遇到文档里字段缺失的参数直接跳过了，也没有主动校验语法。PTC 模式下，它的执行过程是这样的：
- 第一步，它先把接口文档读进来，列出所有端点，形成一张表格，标注每个端点的请求方法、路径和必选参数。
- 第二步，它对缺失参数的情况做了标注，并在生成脚本时先用 mock 值填充，同时在注释里写明哪些位置需要替换。
- 第三步，它主动调用代码解释器做了一次语法编译，发现一处逗号错误后，重新修正了脚本并再次校验通过。
整个过程几乎不需要我介入，最后的输出里还附带了一份"参数核对表"，告诉我哪些参数来自文档、哪些是占位值。这种体验在标准模式下是拿不到的。
3.3 PTC 的代价与使用边界
PTC 并不是"万能增强器"，它有明显的代价：
- Token 消耗高：强制规划、分步执行、末尾校验，都会产生大量额外输出。同样一个问题，标准模式可能消耗 2000 个 token，PTC 模式可能要 8000 个以上。如果你用的是付费 API，这个差别直接体现在账单上。
- 响应慢：步骤多了，总耗时自然拉长。如果你只是问一个常识问题，用 PTC 反而会觉得"杀鸡用牛刀"。
- 不适合发散类任务：PTC 的高确定性结构对于创意写作是种束缚，让它写一首诗，它会先列一个"诗的创作计划"，读起来非常机械。
所以我的使用原则是：只有任务具备"多步骤、可拆解、需要工具支撑"这三个特征时，才切换到 PTC。例如数据管道编排、批量文件处理、多接口联调、长文档的深度分析。简单问答请回到极简或标准。
4. 创造模式：内容生产的加速器，但别让它单飞
4.1 创造模式改了什么，为什么输出明显"放飞"
创造模式在采样参数上走的是完全相反的方向：温度通常调到 1.0 以上，top_p 放宽，允许模型在词汇选择上有更高的随机性；上下文策略也更宽松，不做激进压缩，这样模型可以引用更早的创意线索。同时，工具调用被限制在检索和引用类插件，避免模型在发散过程中突然去执行代码打断思路。
效果就是，模型会更愿意给出多个可选方案、更丰富的比喻和更长的篇幅。比如让标准模式写一段产品介绍，它会给你三句话的中规中矩版本；让创造模式写，它可能会给你三个风格完全不同的版本，其中一个还会带着一个出人意料的切入点。
4.2 创造模式在实战中的表现与注意事项
我自己用得比较多的场景是：
- 文案起稿：给一个主题，让它生成标题候选、开场白、正文框架。
- 头脑风暴：让模型列出尽可能多的解决思路，不需要立刻评估可行性。
- 角色扮演与故事创作：需要模型跳出常规表达模式时，创造模式表现明显更好。
但有两个注意事项我得重点说。
第一，创造模式输出的正确性不能直接信任。它为了表达上的顺畅，偶尔会编造一些不存在的细节，尤其在涉及数据、历史、技术规范时。用创造模式生成的营销文案，里面的数字和事实必须人工核对。我有一条铁律：事实性内容用标准或 PTC 模式生成，表达性内容用创造模式润色，两者结合而不是只靠后者。
第二，创造模式在长对话中容易"跑偏"。因为上下文保留宽松，模型可能会在第五轮对话时，还在回应第三轮里的一个比喻，导致话题越飘越远。如果你发现它开始离题，最简单的做法是把对话分支重置，或者切回标准模式继续。
4.3 创造模式也能用来调试代码？反向用法更香
这里分享一个反向用法。虽然创造模式不适合精确编程，但它非常适合做"测试用例生成"。让它在高随机性的状态下读一段核心函数，再生成各种奇怪的边界输入，往往能找出标准模式下想不到的边界场景。我曾在一次会话里，让创造模式给一个日期解析函数生成 20 个刁钻输入，结果它给出了包含闰秒、时区偏移、农历日期在内的测试用例，其中两个真的触发了解析异常。这个用法比直接用标准模式写测试用例更有价值。
5. 四种 Preset 怎么选：给不同场景的决策建议
5.1 一张选型参考表
如果你不想读原理，直接按这张表对号入座：
| 你的需求 | 推荐 Preset | 原因 |
|---|---|---|
| 快速问答、格式转换、配置查询 | 极简 | 输出最短，开销最低 |
| 日常编程、文档总结、一般咨询 | 标准 | 均衡稳健，工具按需启用 |
| 多步骤工程任务、数据管道、自动化流程 | PTC | 强制规划与校验，完成度高 |
| 文案创作、头脑风暴、测试用例生成 | 创造 | 高随机性，发散能力强 |
| 先用着再说 | 标准 | 出错率最低，覆盖最广 |
5.2 会话中动态切换：Preset 不是一次性绑定
一个容易被忽略的点是：Preset 是会话级的，不是全局锁定的。也就是说你完全可以在同一个任务中，阶段性地切换不同预设。
比如我做一个"写代码 + 写文档"的综合任务时，会这样切换：
- 先用 PTC 模式让模型拆解任务，生成代码实现并完成自测。
- 切换回标准模式，让模型把代码的关键逻辑逐段解释出来。
- 最后切换到创造模式，让模型根据前面的解释，生成一段面向新手的教程文案。
三个阶段各用各的模式，比死守一个模式效果要好得多。Harness 的会话上下文在同一会话内是共享的，切换预设不会清空之前的对话历史，所以你可以放心切。
5.3 如果你有特殊需求：自定义 Preset 的调整思路
Harness 支持在配置文件中自定义 Preset，很多人不知道这点。常见的自定义入口是配置目录下的 preset 文件（JSON/YAML 格式），里面可以覆盖默认参数。我的建议是不要随意大改，而是基于现有的四个模式微调。
举几个常见微调方向：
- 如果你觉得标准模式太长，把 temperature 从 0.7 降到 0.5，再把 max_tokens 上限调低，就能得到一个"简洁标准"模式。
- 如果你觉得创造模式太不稳定，把 top_p 从 0.95 降到 0.85，它会在"有创意但不过度放飞"之间取得平衡。
- 如果 PTC 模式的 token 消耗让你吃不消，可以把强制规划缩小到"只对超过三个步骤的任务启用"，而不是所有任务都走完整链路。
修改完配置文件后，重启 Harness 就能在预设列表里看到新的自定义项。这个操作的门槛不高，建议试几次找到适合自己的组合。
5.4 一个容易踩的误区：把"标准模式结果不满意"归咎于模型
我见过不少用户，在标准模式下得到不如意的结果后，直接判定"模型不行"，然后开始怀疑本地部署失败或者 API 配置有问题。但实际上，问题可能只是预设选错了。同样一个需求，丢给 PTC 模式可能因为多了规划与校验而顺利完成；丢给创造模式可能因为发散而答非所问。在切换预设、调整参数之前，不要急着给模型下结论。
建议的排查顺序是：先问自己这个任务的类型是什么，再对照表格选择 Preset，如果效果还是不行，再去看模型版本、上下文长度、工具插件是否正常。大部分问题出在前两步。
6. 部署与使用中的几个实战细节（结合的安装和配置经验）
6.1 安装后的第一件事：确认 Preset 文件路径
很多人在安装 Harness 后，找不到配置文件在哪，导致自定义 Preset 无从下手。Windows 环境下配置文件一般在用户目录下的.harness或AppData对应目录里，Linux 下通常在用户主目录的隐藏文件夹下，比如~/.harness/config.yaml。装完先用dir（Windows）或ls -a ~（Linux）看一下隐藏目录，找到 preset 相关文件再动手改。
Ubuntu 服务器无桌面环境下部署时，不少人会忽略一点：Harness 的配置文件编码必须是 UTF-8，用 Windows 记事本改过配置再传上去，经常出现中文乱码或解析失败。我建议在 Linux 下直接用nano或vim改，不要跨平台反复拷贝文件。
6.2 局域网访问与多端共用时 Preset 的注意点
如果你把 Harness 部署在服务器上，通过局域网其他设备访问，注意每个客户端看到的 Preset 列表是读取服务端配置的。也就是说，你在服务端自定义的 Preset，局域网内所有访问者都能看到。测试阶段建议先建一个专用测试账号或独立端口，避免把半成品配置暴露给其他人。
多端共用还有一个隐藏问题：不同设备上创建会话时，Preset 是按会话创建时选定的配置执行的，不会因为后来改了全局配置而自动更新。比如你在手机端创建了一个极简模式的会话，回到桌面端修改了极简模式的参数，这个已有会话仍然沿用旧的参数。需要新建会话才能应用新配置。这一点不熟悉的话很容易造成"明明改了配置却没生效"的困惑。
6.3 插件和模型免费版下的 Preset 表现差异
接入本地免费模型和接入云端付费 API，同一个 Preset 的表现会有差异，尤其是在 PTC 模式上。本地小参数模型（比如 7B、14B 级别）在 PTC 模式下的规划能力明显弱于大模型，经常出现"计划列得漂亮但执行时丢步骤"的情况。如果你用的是小参数模型，建议优先用标准模式，不要在 PTC 上过多期待；PTC 模式的完整能力建议配合大模型使用。
大模型目前有免费使用的渠道，这个要注意甄别：一个是官方限时免费额度，另一个是社区镜像或中转服务。我的经验是：跑普通对话用免费额度没关系，但跑 PTC 这种长链路任务，免费接口的稳定性和速率限制可能成为瓶颈，关键任务建议使用付费 API 或者本地具备足够显存的部署方案。
6.4 更新后 Preset 被重置的问题
Harness 在更新版本后，偶尔会出现自定义 Preset 被重置回默认的情况。这不是你操作失误，而是新版覆盖了旧的配置模板。解决思路很简单：把自定义的配置单独备份，更新后重新导入或手动合并。我在实际使用中养成了一个习惯，每次调整完配置都复制一份到备份目录，文件名里带上日期，例如preset_20250114.yaml。这样即使更新重置了，也能最快的速度恢复。
另外，新版本引入的 Preset 参数可能比旧版多，合并配置时如果发现旧模板里没有的字段，不要删掉，保留默认值即可。强行删掉可能导致配置解析器报错。
7. 一次实际任务的四种 Preset 对比复盘
为了让你更直观地感受差异，我拿一个实际任务做了四连测。任务描述是："请帮我检查下面这段 Python 代码的性能瓶颈，并给出优化建议"，后面跟了一段包含循环嵌套和多次数据库查询的代码。
四种 Preset 的输出差异非常明显：
- 极简模式直接回答了最核心的一个瓶颈："第 45 行的数据库查询在循环内，应移到循环外。"没有多余解释，没有重构代码。对老手来说，这个答案足够了，效率极高。
- 标准模式不仅指出了瓶颈，还给出了一份优化后的代码，包含使用批量查询、添加索引、改用生成器处理大数据集等建议，每一条都带着理由。
- PTC 模式先列出了分析计划：先读取代码、定位热点、分析复杂度、给出优化方案、验证优化后代码。它真的跑了一轮静态检查，还生成了一段性能基准测试脚本，并对比了优化前后的耗时，最后输出一份完整报告。信息量最大，但耗时也最长。
- 创造模式给出的回答从一个"数据库查询是程序的心脏跳动，每分钟都在做大量低效的泵血"的比喻开始，然后以故事化的方式描述了性能问题，提出的优化方案包含了一些非常规的想法（例如预计算结果缓存、采用异步并发模型）。有启发，但实际落地需要消化。
这个复盘说明：四种模式没有绝对优劣，只有匹配不匹配。把同样的任务丢给四个模式做横向对比，是理解预设性格最快的方式。我建议你也可以拿一个自己最常做的任务，在四种预设下各跑一遍，记录输出长度、耗时和可用性，形成你自己的选型经验表。
8. 关于 Preset，我的几条经验原则
最后分享几条实践原则，算是给这篇长文的落点。
第一条：预设只是起点，不是终点。选定一个 Preset 之后，你仍然可以通过追加指令微调模型行为。如果不想改配置，直接在对话里加一句"尽量简短回答"或"请给出三步执行计划"，比切换预设更轻量。
第二条：注意观察 token 消耗。如果你经常在 PTC 模式下跑任务，建议设置上下文长度和输出上限，避免一次长任务耗尽上下文窗口。尤其是用免费的云端渠道时，上下文溢出会导致之前的规划内容被截断，影响后续执行。
第三条：善用会话分支。Harness 支持在会话中间切换预设，如果你在标准模式的对话中发现需要更强的结构执行能力，切换到 PTC 模式通常能挽回一个跑偏的任务，而不需要重新开一个会话。
第四条，也是最重要的：不要神化任何模式。极简会遗漏细节，PTC 会拖慢节奏，创造会编造事实，标准会趋于平庸。只有当你清楚知道每一种模式的局限，才能真正用好它们。这也是我从 Harness 的这四种 Preset 设计里学到的最有价值的东西。
