页面能打开，但 Agent 不能稳定调用模型、越过工作区边界，或重启后找不到会话。
最快解法：不要把“能访问”当作交付通过，按环境身份、权限、工作区、模型链路、工具执行、状态恢复和交接材料逐项验收；任一关键项无法复现，先整改再投入持续任务。

谁应该看这份清单

技术采购人员可以把抽象需求转成可签收的交付项。
开发者可以确认远程环境能完成真实任务，而不是只展示启动页面。
运维团队可以提前划清重启、日志、权限和故障回退责任。

最后更新于 2026 年 8 月 18 日，资料核实自 DeepSeek Harness 官方仓库、Web UI 指南、模型配置文档与架构文档。DeepSeek Harness 仍处于开发者预览阶段，官方明确提示可能出现兼容性破坏变更，因此交付时必须记录实际版本，不能只写“最新版”。
参考：官方仓库 README、官方 Web UI 指南

先冻结环境身份

DeepSeek Harness 云端 Mac 验收的第一步，不是点击 Web UI，而是冻结环境身份。你需要在交付节点上直接执行命令，或从交付页面保存证据，至少记录：

  • macOS 版本与构建号；
  • 芯片架构；
  • Node.js、包管理器和 DeepSeek Harness 的实际版本；
  • DeepSeek Harness 的来源：安装包、源码目录、npm 运行方式或其他方式；
  • 当前启动目录、配置目录和工作区路径；
  • Web UI 的监听地址与端口；
  • 当前使用的 profile、插件组合和配置覆盖文件。

官方 README 说明，DeepSeek Harness 可以通过 npx @deepseek-ai/dsh web 启动，默认 Web UI 地址为 http://127.0.0.1:3080。这只能证明默认启动方式存在，不能证明供应商交付的远程访问路径、反向代理和身份链路已经正确配置。(github.com)

验收动作建议这样做：

  1. 执行系统版本、架构和运行时版本命令。
  2. 执行 DeepSeek Harness 的帮助或版本命令。
  3. 保存启动命令、启动日志和退出状态。
  4. 执行 dsh --profile web --dump-config，保存实际加载的插件树。
  5. 将结果写入不可变更的验收记录，不要手工抄写。

官方架构文档指出，运行中的 dsh 是按 profile 和 bundle 组合出来的插件树，模型适配器、工具、持久化、沙箱、审批策略和凭据都属于可配置层。配置名称相同，不代表实际加载内容相同。(github.com)

版本与运行信息，采购时该怎么留证？
至少检查系统、运行时、DeepSeek Harness 来源、profile、插件树、配置目录和启动日志。只提供“Mac mini”“已安装完成”这类硬件名称，无法支持后续复现，也无法判断问题到底来自系统、Node.js、插件还是模型配置。

再划清访问与身份边界

云端 Mac 的远程登录权限，和 DeepSeek Harness 内部的命令审批策略，不是同一层控制。

你需要分别测试：

  • SSH 或其他远程登录账户能否登录；
  • 账户是否拥有管理员权限；
  • Web UI 是只允许本机访问，还是通过代理暴露；
  • 未授权账户能否打开控制面；
  • 远程 Mac 登录用户是否能读取其他用户目录；
  • DeepSeek Harness 是否会在危险命令前要求审批；
  • 交付后谁负责更换临时密码、密钥和 API 凭据。

检查时不要只看“登录成功”。用一个普通账户和一个管理账户分别执行同一组命令，保存身份、权限和失败信号。再从未授权网络或未授权账户尝试访问控制面，确认失败，而不是只确认授权用户能够进入。

DeepSeek Harness 官方 Web UI 指南说明，模型可以读取和修改工作区文件、运行命令，并在当前权限策略要求时弹出审批。这个审批行为属于 Agent 工具链；它不能替代云端 Mac 的登录权限、网络访问控制或管理员权限管理。(github.com)

访问验收的通过条件

✅ 授权用户可以按交付路径登录。
✅ 未授权用户无法进入 Web UI 或远程控制面。
✅ 普通账户不能因为 DeepSeek Harness 启动而自动获得管理员权限。
✅ 远程 Mac 登录权限与 Agent 命令审批策略有独立记录。
❌ 只给一个共享管理员账户。
❌ 只截图 Web UI，不验证未授权访问。
❌ 交接时保留交付方的长期凭据。

用隔离仓库验证工作区

“已设置工作目录”不是文件边界验收。Agent 实际能看到什么、改动什么、访问哪些父级路径，必须用测试仓库验证。

准备一个不含敏感信息的隔离仓库，至少放入：

  • 一个允许读取的文本文件；
  • 一个允许修改的源文件；
  • 一个只读标记文件；
  • 一个仓库外路径的测试目标；
  • 一个需要人工审批的命令；
  • 一个预期失败的越界路径。

然后按固定任务运行：

  1. 让 Agent 列出当前工作区文件。
  2. 让 Agent 读取允许读取的文件。
  3. 让 Agent 修改受控文件，并检查差异。
  4. 让 Agent 尝试修改只读文件。
  5. 让 Agent 访问工作区外路径。
  6. 让 Agent 执行需要审批的命令。
  7. 检查仓库状态、文件差异和失败原因。

官方文档说明，新的 Web UI 在选择工作区前不能开始完整会话；选择工作区后，Agent 才能读写文件、运行命令和执行任务。这个流程能证明 UI 配置存在，但真正的交付证据仍然应是文件访问结果和越界失败记录。(github.com)

远程工作区和命令边界，应该怎样验收？
不要用工作目录配置截图代替测试。你应当保留“能读什么、能改什么、拒绝了什么、拒绝原因是什么”四类证据。若工作区外路径可以被读取或修改，或者危险命令无需审批就执行，应判定为未通过，除非采购范围明确要求这种权限并完成书面风险确认。

DeepSeek Harness 架构文档还显示，文件系统、Shell、沙箱和工具执行属于不同能力接缝。它们可以被替换或重新组合，因此验收时必须记录实际 profile 和工具提供者，不能根据默认名称推断安全边界。(github.com)

固定模型与工具链基准

模型列表出现，不等于模型链路可用。你需要把模型凭据、最小响应、工具调用、审批和结果写回拆开验收。

建议使用一份固定基准任务：

读取测试仓库中的说明文件，创建一个临时报告，执行一次无副作用命令，将命令结果写回报告，并输出最终文件差异。

这份任务要保留：

  • 输入提示；
  • 选中的 provider 和 model；
  • 模型响应；
  • 工具调用名称与参数；
  • 审批弹窗或拒绝信号；
  • 命令退出状态；
  • 最终文件差异；
  • 失败时的错误码和日志。

DeepSeek Harness 官方模型配置文档说明，模型设置发生变化后，下一次请求即可生效，不需要重启服务；凭据保存后页面只返回脱敏描述，实际密钥不会直接展示。文档还指出，已经发起请求的会话会保留会话日志中记录的模型。(github.com)

这带来三个容易漏验的边界：

  • 新会话使用了新模型，不代表旧会话已经切换；
  • 模型选择器能显示模型，不代表凭据、接口协议和模型路由成功；
  • 工具调用成功，不代表结果已经写回工作区。

模型链路的优缺点

✅ 固定任务可以重复运行，便于比较交付前后差异。
✅ 保存原始失败信号，方便区分凭据错误、模型错误和工具错误。
✅ 将模型调用与文件写回分开，定位更快。
❌ 只检查模型下拉列表。
❌ 只发送一句问候语。
❌ 把“有响应”当成“能完成真实 Agent 任务”。

受控重启验证持久化

DeepSeek Harness 重启后，会话与配置是否还在？
不能先假设会恢复。你需要在交付节点上创建测试会话，写入非敏感配置，关闭并重新启动服务，再逐项检查会话、工作区、插件、模型和审批策略。

推荐步骤如下：

  1. 创建一个带唯一标记的测试会话。
  2. 在工作区写入一个非敏感测试文件。
  3. 记录当前模型、工作区和 profile。
  4. 正常停止 Web UI。
  5. 按交付方提供的原命令重新启动。
  6. 打开原会话，检查上下文和日志。
  7. 检查工作区选择、模型配置和插件组合。
  8. 重新执行一次最小模型请求与工具任务。

DeepSeek Harness 的官方会话文档把 Session 定义为追加写入的事件日志，模型看到的消息历史由日志重新推导；会话日志还记录工具调用、工具结果和请求配置。这个设计为恢复验收提供了检查方向，但它不等于云端 Mac 已经完成磁盘持久化、备份或故障恢复交付。(github.com)

验收记录必须明确区分：

  • 自动恢复：重启后无需人工操作即可出现；
  • 可恢复但需重新选择：数据存在，但需要人工指定；
  • 不会恢复：临时状态、未持久化插件或临时环境变量；
  • 尚未验证：交付方没有提供实测证据。

不要把“服务能重新启动”写成“故障后可自动恢复”。后者还涉及磁盘、配置、凭据、备份和重建边界。

补齐日志与故障回退材料

持续运行 AI Agent 前，采购方应要求交付方说明故障后怎么止损，而不是只问“是否稳定”。

交接前至少确认：

  • Web UI 和后台进程日志在哪里；
  • 如何导出会话日志；
  • 如何查看模型请求失败原因；
  • 如何确认当前进程、端口和工作区；
  • 谁负责 DeepSeek Harness 版本更新；
  • 更新前是否有配置备份；
  • 备份包含哪些文件，不包含哪些密钥；
  • 如何回退到上一份 profile 或配置；
  • 环境能否重建，重建边界是什么；
  • 重建是否依赖原账号、原设备或供应商人工操作。

持续运行 AI Agent 前，故障恢复材料要准备到什么程度？
至少要有环境清单、启动与停止命令、日志位置、备份范围、凭据轮换方式、回退步骤和责任人。恢复时长如果没有本站或交付现场的实测，就不要写成承诺；可以写“已验证的恢复路径”，但不能把未测试的时间填进采购 SLA。

官方架构文档说明，会话事件、工具事件和请求配置都属于可追踪的运行数据；官方会话文档也说明日志是恢复、回放和持久化的基础。你仍然需要在真实交付环境里确认这些日志能否被你的团队获取，而不是只引用文档里的设计。(github.com)

用条件分支做签收决策

把最终结论分成三档，不要只写“基本通过”。

选择“通过签收”

若满足以下条件，可以进入正式任务：

  • 环境版本和启动来源有命令输出或交付页面证据；
  • 授权与未授权访问结果都已记录；
  • 工作区内外边界通过固定测试；
  • 模型、工具、审批和结果写回全部成功；
  • 重启后恢复行为已明确；
  • 日志、备份和回退入口可由接收方实际使用；
  • 交接包不含明文密钥。

选择“限期整改”

若核心任务可运行，但存在可控缺口，例如日志导出不完整、某项权限需要补充说明、重启后需要人工重新选择工作区，可以限期整改。整改项必须写清负责人、截止日期、复测动作和未完成时的降级方案。

选择“拒绝签收”

若出现以下任一情况，应拒绝正式签收：

  • 只能访问页面，无法完成固定基准任务；
  • 版本无法确认，导致结果不可复现；
  • 未授权用户可以进入控制面；
  • Agent 可以越过约定的文件或命令边界；
  • 模型凭据或工具链只在演示账户下有效；
  • 重启后会话或配置丢失，且没有明确恢复方案；
  • 没有日志、备份或回退入口；
  • 交接材料保留明文 API 密钥。

整理交接包再签字

一份可审计的交付清单，至少包含以下五部分：

  1. 环境清单：系统、运行时、DeepSeek Harness 来源、profile、插件和配置路径。
  2. 访问责任：登录账户、权限范围、凭据更换责任和控制面暴露范围。
  3. 测试记录：固定任务输入、成功结果、失败信号、文件差异和重启结果。
  4. 数据与备份范围：会话日志、工作区、配置文件和明确排除的敏感内容。
  5. 回退步骤：停止服务、恢复配置、重新启动、验证模型和恢复会话的顺序。

如果你正在比较不同节点或租赁方式，可以先查看 MACCOME 的云端 Mac 订购页面，再把实际交付配置逐项填回本文清单。页面展示的可选项不能替代现场验收，尤其是重启恢复、持续运行和权限边界，仍应以真实环境记录为准。

如果你还没有确定远程访问、节点位置或交付方式，可以先浏览 MACCOME 的云端 Mac 服务入口，把并发任务、隔离要求、访问账户和预期租期整理成采购条件，再要求交付方逐项返回证据。这样做比只比较设备名称更容易发现权限、恢复和交接方面的缺口。

当前方案如果只是把 DeepSeek Harness 装在一台临时 Mac 上，常见缺点是版本没有冻结、远程入口和账户责任不清、重启后状态没有验证，出了问题还要临时寻找日志和恢复路径。相比之下，租用 MACCOME 的云端 Mac 更适合把节点、访问方式和交付清单放进同一份验收记录里；但是否适合你，仍取决于并发任务、隔离要求和预期租期。若你需要临时算力或测试环境，可以提交这些条件，让 MACCOME 按同一张清单核对可交付状态，而不是先承诺未经验证的配置。