DeepSeek Harness 工作流：如何安全完成第一次评估

DeepSeek Harness 目前应该被当作实验性软件来评估，而不是直接设为生产环境默认工具。DeepSeek 将项目标为 Developer Preview（开发者预览）；官方安全说明明确表示，它尚未经过安全审计，也不是安全或生产就绪的产品。

截至 2026 年 9 月 11 日，官方最新预发布版本是 9 月 10 日发布的 dsh-v0.1.5-rc.2。RC2 只包含两项小型 UX 改进；会影响迁移的 Session V3、默认工具、SDK 和插件变化都记录在 RC1 中。0.1.5 Release 指南解释了这些变化。这是带日期的上游观察，不代表某条 npx 命令、某份源码或 Agent.Space 正在运行这个 build。

安全的首次工作流是：记录实际运行的准确产物，把它放进用完可丢弃、权限最小的隔离环境，只选一个界面和模式，交给它一个带停止条件的小任务，检查操作轨迹和真实文件变化，最后明确接受、拒绝或回滚。

先确认边界：Developer Preview，不是生产默认工具

DeepSeek Harness 官方概览把它描述为一个由插件组合的 Agent runtime，并提供可追踪 Session 和多种运行模式。官方仓库也提醒，项目在预览期快速迭代，可能出现破坏兼容性的变化。

开始前更应该先看 SAFETY.md。这份官方文件说明，harness 可以执行代码和命令、加载插件，并根据环境与配置访问文件、进程、网络和凭证等资源。它建议使用最小权限、受限凭证、备份，以及隔离或用完可丢弃的环境。

Sandbox（沙箱）和 approval（审批提示）可以降低风险，但不能证明完全隔离。每多启用一个插件或工具，就多开放一份权限。第一次评估不要使用生产仓库、生产凭证、个人秘密或无法替换的本机文件。

本文评估的是一套工作流，不声称 Agent.Space 已经完成某项实测。上游功能只能说明 DeepSeek 项目发布了什么；托管产品必须另外公开并支持，才能被视为在那里可用。

第 1 步：定义评估问题，记录准确 build

先提出一个可以用证据回答的问题，例如：

这套 DeepSeek Harness 能否在隔离的示例仓库中完成一项有边界的改动，不超出允许文件，并留下可审查的操作轨迹和通过的验证结果？

然后记录实际要运行的内容。在同时存在多个 Release Candidate 和软件包产物时，只写“DeepSeek Harness 0.1.5”并不精确。

启动路径	运行前要记录什么	重要边界
官方软件包 quickstart	命令、包管理器输出或实际解析版本、Node.js 版本和启动时间	GitHub release tag 不能证明 `npx` 解析到了哪个软件包
源码 checkout	仓库 URL、准确 tag 或 commit、工作区状态、依赖与 runtime 版本	会移动的分支可能在两次评估之间变化
托管产品	产品名、界面显示的 harness 版本（如果有）、所选模型、控制项与评估日期	不要从上游 release 页推断它的 build

DeepSeek 官方 quickstart 当前使用：

官方仓库还记录了源码启动路径。第一次试跑只选其中一条。不要把软件包安装、另一份源码 checkout 和托管集成混在一个结论里；它们是不同配置。

固定版本可以让结果更容易复现，但不会让预发布版本自动变安全。每次升级前都要重新阅读 Release Notes 和安全说明，再在干净环境里重复有边界的检查。

升级前：保护 Session，重新核对默认值

DeepSeek Harness 0.1.5 RC1 会把受支持的 Session 数据迁移到 V3 格式。Release 表示迁移会创建新文件并保留原始文件，但升级后的 Session 无法降级。应该把重要 Session 备份到工作目录以外，先迁移一份不含敏感信息的副本，并保留固定旧版本的环境，直到打开、恢复、追加、暂停和取消都通过验证。

自定义 Session 读取器也需要重新检查。Session 生命周期改用 SessionHandle，agentLoop.create() 变为异步调用，而且 Session lock 只允许最多一个进程持有 Session。不要只验证 Web UI 能否打开，还要测试依赖这些合同的集成路线。

默认工具也改变了。RC1 中，SDK、Headless 与 ACP 默认使用 read、write 和 edit；Web minimal 与 Python sdk-minimal 默认只有持久 Shell；str_replace_editor 则需要显式选择。应该记录准确 runtime 实际显示的工具与权限，不能把旧版本的工具清单直接沿用到新评估。

第 2 步：建立可丢弃的最小权限环境

使用一个可以直接销毁和重建、不会伤害日常电脑或生产系统的环境。一次性虚拟机（VM）、容器（container）或专用测试环境都能缩小影响范围，前提是其中的挂载目录、网络、进程访问和凭证也受到限制。

启动前：

只复制任务所需的示例仓库和 fixture（测试样本）。
从干净 commit 开始，并在外部保留备份或容易恢复的重置点。
不要挂载个人主目录、SSH 目录、密码库或其他无关 Workspace。
默认不提供凭证；模型路线确实需要时，只用测试专属、可撤销、权限最小的凭证。
把出站网络限制到评估真正需要的接口地址（endpoint）。
记录哪些文件、进程、端口和工具本来就应该可访问。
运行前先确定怎样停止 harness 并丢弃整个环境。

不能只相信“已隔离”的标签。要从 Agent 之外检查挂载、环境变量、网络策略和宿主机集成。任务不需要的能力应该直接移除，而不只是写一句指令要求 Agent 不要使用。

更完整的凭证、网络、文件范围、审批、扩展与恢复检查，可以参考编程 Agent Workspace 安全指南。

第 3 步：只选一个界面和一种模式

官方 quickstart 会打开 Web UI。它让 Session 过程可见，适合作为第一次使用入口。评估过程中保持界面不变；更换客户端也可能改变默认行为或可供审查的信息。

DeepSeek 当前概览列出几种模式：

上游模式	DeepSeek 描述的评估用途	第一次运行时要注意
Standard	工具较完整的编程 Agent 工作流	工具越多，需要检查的权限边界越宽
Code	通过生成代码组合多次工具操作	自动编排仍需同样的权限和产物审查
Minimal	模型基准；0.1.5 RC1 的 Web `minimal` 默认只有持久 Shell	“Minimal”并不等于无害；另行核对显式启用的 Editor 工具
Creator	研究 runtime 与插件、制作自定义 preset	自定义插件会扩大代码与信任范围

预览期内，模式名称和组合可能变化。请同时在当前官方页面和实际运行界面中确认。选择某个模式，是因为它符合评估问题，而不是因为它的功能清单最长。

插件集合也要尽量小。每增加一个插件，都要审查源码、配置、申请的权限和数据路径。某项插件操作能被记录，并不代表它安全；可追踪性有助于调查，不能代替预防。

第 4 步：写一份有边界的任务 Brief

第一次任务应当小、可逆，而且能独立验证。修改文档、解释代码并提出测试，或在示例项目中修一个范围很小的问题，都比“改进整个仓库”更有评估价值。

可以使用下面这种任务合同：

text

目标：  修复示例 parser 的失败单元测试。
允许范围：  只能修改 src/parser.ts 和 tests/parser.test.ts。
禁止事项：  不访问仓库外文件，不安装全局软件包，不修改凭证，  不发布任何内容，也不联系外部服务。
验收：  解释原因，保证 Diff 不超出范围，并运行指定测试命令。
遇到以下情况先停止并询问：  需要其他文件、网络、新依赖或更高权限。

目标：  修复示例 parser 的失败单元测试。
允许范围：  只能修改 src/parser.ts 和 tests/parser.test.ts。
禁止事项：  不访问仓库外文件，不安装全局软件包，不修改凭证，  不发布任何内容，也不联系外部服务。
验收：  解释原因，保证 Diff 不超出范围，并运行指定测试命令。
遇到以下情况先停止并询问：  需要其他文件、网络、新依赖或更高权限。

任务 Brief 本身不是安全边界。重要限制仍要由环境权限和审批机制真正执行。Brief 的作用，是让意图可以被审查，并在操作轨迹偏离时提供明确停止理由。

不要为了让试跑看起来“真实”就加入生产数据。合成 fixture 和有代表性的仓库结构，已经足以评估 harness 会不会规划、调用工具、遵守范围并诚实报告验证结果。

第 5 步：检查操作轨迹并独立验证结果

DeepSeek 把 append-only session log（只追加的 Session 日志）和 Trajectory（操作轨迹）视为上游核心概念。可以用它们检查哪些上下文进入运行、请求了哪些工具、返回了什么结果，以及任务怎样一步步变化。

然后还要独立验证。最终回复和操作轨迹只是证据来源，不能证明仓库一定正确，也不能证明环境始终安全。

逐项检查：

每次工具调用和权限提示是否符合任务 Brief；
从聊天界面以外查看所有修改、新建或删除的文件；
对照干净起点查看准确 Diff；
指定测试、lint 或构建命令及其原始输出；
意外进程、网络连接、生成文件或凭证读取；
没有通过工具或可检查产物验证的说法；
警告、重试、错误，以及 harness 尝试但没有清楚展示的修改。

如果运行超出允许仓库、索取无关秘密、执行无法解释的命令、关闭安全控制，或在验收已经不可能时仍继续行动，应立即停止。只有在不会把敏感信息复制到更低保护位置时，才保留相关日志。

第 6 步：接受、拒绝或回滚

只有形成决策，评估才算完成。可以使用三种结果：

接受这份产物：修改没有超出范围，通过了独立检查，可以进入正常人工 review。这里接受的只是一次产物，不是给 harness 无限使用权。
调整配置后重做：结果暴露了可以修正的配置、权限、任务写法或复现问题。重置环境，每次只改变一个变量。
拒绝并回滚： harness 越过边界、结果无法审查、要求过大权限，或行为不稳定到当前收益无法抵消风险。

运行结束后销毁或重置隔离环境，撤销测试凭证，保存准确版本、配置和不含敏感数据的评估记录。恢复仓库时回到干净基线，不要让同一个 Agent 自己撤销自己的行为。

采用过程也应该分阶段：再做一个隔离任务，扩展到一小组代表性任务，然后才进入范围很窄、治理明确的试点。即使某个 build 曾经表现良好，Developer Preview 和 Pre-release 状态仍意味着升级后要重新测试，并始终保持低成本回滚。

这套工作流在 Agent.Space 中意味着什么

Agent.Space 当前把 DeepSeek Harness 展示为实验性或 Developer Preview 的 Agent 选择。请通过 DeepSeek Harness Agent Hub和实时产品界面，确认当前 Workspace 是否可用，以及界面实际显示哪些模型与控制项。

必须把两组证据分开：

上游证据： DeepSeek 的仓库、release tag、quickstart、模式、插件架构、轨迹概念与安全说明。
Agent.Space 证据：当前 Agent.Space 界面里真正展示的 harness 状态、兼容模型、工具、控制项和行为。

上游发布 0.1.5 RC2，不代表 Agent.Space 正在运行 RC2；上游有某个模式、插件或界面，也不代表 Agent.Space 已经开放。本文不声称 Agent.Space 已经实测或正式支持所有上游能力。现有指南解释了 DeepSeek Harness 在 Agent.Space 当前代表什么，而可用性仍以当前界面为准。

名称里都有 DeepSeek，也不代表 DeepSeek Harness 与 DeepSeek 模型是同一层。如果这一区别还不熟悉，可以先看 Agent harness 与模型的区别，再理解模型选择器或上游功能公告。

第一次评估检查清单

运行前：

确认 Developer Preview 状态和当前安全说明；
记录准确的软件包、tag、commit、使用入口、模式、模型和日期；
备份重要 Session 数据，并在副本上测试任何 V3 迁移；
记录实际生效的默认工具、插件与 Session API 合同；
使用带干净仓库和备份的可丢弃环境；
移除无关文件、凭证、网络、工具与插件；
定义目标、允许范围、验收命令和停止条件。

运行后：

检查操作轨迹、文件 Diff、进程、网络和验证输出；
把观察到的事实与 harness 自己的说法分开；
按书面标准决定接受、重做或拒绝；
重置环境并撤销测试凭证；
保存足以在同一 build 上复现、又不含敏感信息的记录。

这套流程不会让预览软件变成零风险。它能让实验保持有界、可观察、可回滚——这才是判断 DeepSeek Harness 是否值得扩大试用的合理标准。