2026 DeepSeek Harness Agent Preset 放系统级还是用户级？

症状：你明明创建了同名 Agent Preset，却无法确认到底是系统级、用户级还是旧副本生效。
最快解法：个人试验放用户级，团队交付放系统级；共享 Mac 采用“系统级只读基线＋用户级有限扩展”，并用同名测试确认真实加载来源。

SECTION 01谁应该看这篇

如果你只想保存自己的 Agent 组合，又不希望影响同一台 Mac 上的其他账户，本文适合你。
如果你负责团队标准化、远程 Mac 初始化或配置审计，也可以直接按后文的决策分支和验收步骤执行。

这里讨论的是 DeepSeek Harness Agent Preset 的配置所有权与分发责任，不是权限预设、Plan Mode 或 Skills 的放置策略。Agent Preset 负责组合和选择工作流；权限边界、执行模式与 Skill 发现机制应分别验收，不能因为名称相近就合并判断。

SECTION 02先看配置责任，而不是先找目录

系统级与用户级 Preset 的核心差异，不在于哪个目录更“方便”，而在于谁能够写入、谁负责审核、谁能解释一次变更，以及事故发生后谁必须回退。

用户级内容可能由个人开发者、自动化脚本，甚至 Agent 在实验过程中生成。它能够成功加载，只能说明当前进程看到了这份配置，不能证明内容已经经过团队审核，也不能证明其中引用的工具、环境变量或外部来源值得信任。Harness 类配置通常会影响插件、工具、环境变量和治理策略，官方 Harness Protocol 也把这些内容视为完整运行上下文，并强调敏感变量不得写入默认配置或日志。(Harness Protocol 入门文档)

系统级 Preset 更适合成为团队基线，因为它可以与安装包、配置管理或初始化脚本绑定，形成可审计的来源记录。但“系统级”本身不等于安全：如果管理员手工复制未知目录，未记录提交版本，也没有保留上一个可用版本，那么它只是一个权限更高、却更难追责的副本。

用户级适合什么

✅ 个人实验工作流、临时工具组合、个人提示偏好。
✅ 需要频繁改动、快速比较多个 Agent Preset 的开发阶段。
✅ 不应影响其他账户，也不要求每台 Mac 完全一致的本地试验。

系统级适合什么

✅ 团队必须统一的交付流程和默认 Agent 组合。
✅ 新建远程 Mac、系统重装、团队扩容时需要重复部署的配置。
✅ 需要只读保护、变更审核、版本来源和回退证据的受控环境。

❌ 不要把 API 密钥、客户项目边界或“必须所有人一致”的安全要求仅放在用户级 Preset 中。
❌ 不要因为一个用户级 Preset 在你的账户里正常运行，就把它直接复制到共享 Mac 的系统根。

SECTION 03DeepSeek Harness Agent Preset 的加载边界

截至 2026 年 8 月 19 日，任务所依据的官方配置目录与源码声明已经确认：Agent Preset 可以使用多个扫描根，并区分默认 Preset、用户根开关以及 system 与 user 信任标记。可是，实际内置目录、界面入口、扫描顺序和同名处理行为仍应以写作当日使用的 Release、官方配置声明和源码为准；不要把其他版本、社区文章或截图中的目录当成固定接口。

公开的 Harness 规范也提醒你，配置“被发现”与配置“被应用”不是同一件事：应用过程可能还涉及来源解析、继承、环境变量替换、权限合并和最终有效配置生成。(Harness Protocol 应用规范) 因此，确认 DeepSeek Harness 自定义 Preset 的存放位置时，你需要先确认三个事实：

1. 当前版本扫描哪些根目录，以及扫描顺序是什么。
2. 用户根是否可以关闭，system 与 user 信任标记如何参与判断。
3. 重复 ID 的 Preset 是前者优先、后者覆盖，还是直接报冲突。

如果官方文档没有把其中一项写清楚，就把它列为待核对行为，而不是在团队文档里写成确定规则。

SECTION 04同名优先级的最小验证

界面通常只显示 Preset 名称或当前选择项，未必显示完整来源路径。你需要用最小同名测试确认生效来源，避免凭显示名称猜测。

操作时按以下顺序执行：

1. 固定版本。 记录 DeepSeek Harness 的 Release、提交标识或安装包校验信息；不要在自动更新状态下做优先级判断。
2. 准备两个同名副本。 两个 Preset 使用相同 ID，但在无敏感内容的描述字段中写入不同标记，例如 SYSTEM_TEST 与 USER_TEST。
3. 分别放入候选根。 只启用一个扫描根，启动一次；再启用另一个根，重新启动一次，避免旧进程缓存影响结果。
4. 逐步叠加。 两个根同时启用后，记录最终显示内容、启动日志或有效配置输出，并把结果与官方源码中的扫描顺序对照。
5. 形成证据。 保存版本、根目录开关、两个文件的校验值、最终生效标记和回退操作结果。不要保存真实用户名、客户路径或内部 Preset 内容。
6. 测试关闭用户根。 如果系统级基线在关闭用户根后仍然生效，说明你的交付可以减少用户覆盖风险；如果关闭后无法启动，则需要把该依赖写进部署前检查。

在 Harness Protocol 的应用语义中，最终有效配置是应用时生成的快照，父级配置或环境变化不会自动改写已经运行的会话。(Harness Protocol 配置应用说明) 这意味着你不能只测试“文件是否存在”，还要测试“重新启动后实际生成了什么”。

SECTION 05系统级与用户级的交付取舍

表格之外还要注意一个常被忽略的成本：系统级方案的维护成本集中在平台团队，用户级方案的维护成本则分散到每个账户。对于只有一台个人 Mac 的试验，这种分散通常可以接受；对于共享 Mac 或批量远程环境，分散维护会让同名覆盖、版本漂移和事故回收变得很难追踪。

SECTION 06共享 Mac 的双层治理

共享 Mac 最稳妥的默认方案不是“所有人都能改系统 Preset”，也不是“彻底禁止用户扩展”，而是三层选择中的第二种：

方案一：系统级只读基线

适合客户项目边界严格、执行工具固定、需要统一审计的环境。

• 管理员部署系统级 Preset。
• 普通账户只能读取，不能修改系统根。
• 用户级只允许临时实验，且启动前明确显示其来源。
• 出现异常时，删除用户级扩展即可回到系统基线。

优点是回收路径清楚，缺点是个人试验需要额外目录和审批。

方案二：系统级只读基线＋用户级有限扩展

这是共享远程 Mac 的推荐方案。

系统级只放经过审核的默认 Agent Preset；用户级只允许新增个人 ID，不允许覆盖团队基线的同名 ID。用户可以迭代自己的 Agent 组合，但不能把未经审核的工具、外部 MCP 来源或凭据配置注入所有账户。

如果当前版本无法阻止用户级同名覆盖，就必须在启动检查中执行同名扫描，并在检测到重复 ID 时拒绝运行，而不是依赖“通常会优先加载系统级”的经验判断。外部 Harness 配置可能声明远程 MCP 端点，官方规范也将其视为需要额外信任审查的来源。(Harness Protocol MCP 声明规范)

方案三：完全分环境

当以下任一条件成立时，不要继续共用同一 Preset 根：

• 不同客户项目之间不能共享工具发现结果或环境变量。
• 事故发生后无法迅速撤销某个用户的 Preset。
• 多个账户需要不同的网络、文件系统或外部服务边界。
• 你无法确认用户级副本不会覆盖系统级默认值。

这时应改用独立账户、独立工作目录，必要时使用不同的远程 Mac 实例。共享硬件不等于必须共享配置所有权；如果配置边界已经无法解释，继续共用只是在推迟隔离成本。

SECTION 07可复制交付与回退证据

团队分发只读 Preset 时，不要让运维人员登录每台 Mac 后手工复制一个未知目录。至少要把以下内容纳入交付记录：

1. DeepSeek Harness Release 与配置声明核对日期。
2. 系统级和用户级扫描根的版本化记录。
3. Preset 来源提交、归档校验值和变更审批编号。
4. 普通账户对系统根的权限结果。
5. 同名 Preset 的隔离验证记录。
6. 上一个可用版本的保存位置与回退命令。
7. 新建远程 Mac、重装和扩容后的复验结果。

你可以把 Preset 文件作为配置制品交付，但不要把凭据直接嵌入其中。Harness 规范明确要求敏感环境变量不得设置明文默认值，也不得写入状态、会话日志或调试输出。(Harness Protocol 环境变量规范) DeepSeek 官方集成文档同样提醒，相关 Agent 集成由第三方提供，使用前应自行评估安全性与有效性。(DeepSeek Agent 集成文档)

决策条件列表

• 若 Preset 只由你个人试验，且失败后不会影响其他账户，则选用户级。
• 若 Preset 是团队必须一致的交付标准，则选系统级只读。
• 若共享 Mac 既要保留个人迭代，又要维持团队基线，则选系统级只读基线＋用户级有限扩展。
• 若用户级同名覆盖无法被检测或阻止，则回退到完全分环境。
• 若无法保存来源、版本和回退证据，则不要把该 Preset 宣称为团队标准。

SECTION 08FAQ：目录、信任与共享账户

如何确认 DeepSeek Harness 自定义 Preset 的实际存放位置？

不要直接套用其他版本的目录示例。先在当前 Release 的官方配置声明或源码中确认 Preset 扫描根、系统根和用户根，再记录你实际部署的绝对路径。目录确认后，用一个不含敏感内容的同名 Preset 做隔离测试，验证加载来源，而不是只看界面显示名称。

系统级和用户级 Agent Preset 的核心区别是什么？

系统级 Preset 由平台或管理员维护，适合团队基线、只读交付和统一回退；用户级 Preset 由个人账户控制，适合实验、临时工具组合和偏好设置。用户级文件即使成功加载，也不能自动视为受信任配置，尤其不能承载团队安全边界或共享凭据。

同名 Agent Preset 最后会加载哪一个？

不能凭名称推断结果。多个扫描根同时存在时，实际行为取决于当前版本声明的扫描顺序、重复 ID 处理规则和开关状态。最稳妥的做法是在隔离目录放置两个内容明显不同但 ID 相同的 Preset，逐个启用根目录并记录最终生效内容。

团队怎样分发只读 Preset？

把团队基线放在系统级根目录，由安装或配置管理流程写入，并限制普通账户写权限；版本文件、来源提交、校验结果和回退版本一起保存。用户级只允许追加个人 Preset，不允许覆盖团队同名 ID，或者通过审核流程才能升级系统基线。

共享 Mac 上是否应让普通账户改动默认配置？

可以允许用户在用户级新增或覆盖个人实验 Preset，但不建议让普通账户直接修改系统级默认 Preset。共享 Mac 应至少把系统级基线设为只读，并将个人扩展限制在独立账户和独立目录内；如果客户项目、凭据或事故回收无法隔离，就不应继续共用同一 Preset 根。

如果你正在把这套规则落到远程 Mac 上，先从 MACNOX 的 Mac 远程使用入口确认账户与环境边界，再根据团队规模查看 Mac 方案与计费说明。平台团队还可以把本文的同名验证、权限检查和回退记录并入自己的标准化交付清单。

真正需要你做的判断只有一个：先确认 Preset 的来源信任和变更责任，再决定放用户级、系统级还是双层。个人试验用用户级最快；团队标准用系统级最容易复制；共享 Mac 则应优先采用系统级只读基线加用户级有限扩展。若你需要临时的隔离测试环境或多账户远程验证，可以通过 MACNOX 的 Mac 申请页面准备一台独立环境，避免在生产共享 Mac 上直接试探未知的加载优先级。