# 通过一次完整操作理解 DeepSeek Harness 的设计

前两篇文章先后讨论了两个问题：DeepSeek Harness 为什么主动选择了一套更复杂的架构，这些概念又怎样从插件装配一直连接到 Session Log。其实大部分用户也不一定关注这些内容，但我认为把设计原则和基本概念搞清楚会对使用DeepSeek Harness有所帮助。

于是我从实际操作的角度，来看看这些概念是如何体现在界面当中，它会给用户带来什么样的感受。我从安装开始完成一项带有测试失败的代码任务，观察每个步骤DeepSeek Harness最重视的可插拔性和可观测性是如何体现的。第一次打开它时，我的感受其实并不强烈：界面简洁，交互方式也很接近 Codex。差异出现在任务运行之后。DeepSeek Harness 会持续显示任务经过了几轮、几步，模型何时发出请求，工具收到什么参数，执行结果是什么，这是它的可观测性的最直观体现，而我认为这是需要复杂调度的AI创作工具应该重点投入的产品功能。

本文既是一个简单的使用教程，也会回顾和验证一下之前所提过的设计思路。

## 安装

我的Macbook上的环境是 Node.js `v25.3.0`。安装 DeepSeek Harness 的命令只有一行（以后启动这是这条命令）：

```
npx @deepseek-ai/dsh web
```

`npx` 完成下载以后，终端给出本地地址 `http://127.0.0.1:3080`，浏览器打开以后就能进入主界面。上一篇介绍过的很多术语都藏在这条命令背后：`dsh web` 启动 `web` Profile，Profile 选择本次进程采用的 Bundle，Host 能力与 Web 应用由此被装配起来。除了web，也可以通过 --profile 指定 headless 的 profile，或者通过 --patch 参数来实现指定配置的覆盖。

命令行启动加浏览器操作带着明显的开发者工具气质，对于习惯桌面应用的人会稍显陌生，这可能也是很多对DeepSeek Harness批评的原因之一。不过Web 界面的优势也很直接，它不用单独维护桌面客户端，并且天然适合从不同终端访问，也许这里预留了未来的多终端协作的空间，我所设想的“云端统一开发机”的理念也容易匹配上这个方向。

在尝试理解了DeepSeek Harness的宏大愿景之后，它的初始页面比我预想得简单。左边是新会话、Workspace 和设置，中间只有工作目录、工作模式和输入框。我需要先把工作目录加入 Workspace，选中以后才能发送任务。

## 配置

左下角的设置页分成通用设置、模型、插件和 Agent 预设。我先把语言切换成中文，界面立即生效。权限、外观和繁忙时 Enter 键行为基本上与常见的Agent相同，比较容易理解。

模型配置也采用了常见开源工具的做法。填入 DeepSeek API Key 以后，界面可以选择 DeepSeek-V4-Flash 和 DeepSeek-V4-Pro。自定义提供方需要填写 Provider ID、API 地址、协议和密钥，内置模型与兼容接口由同一张配置页管理。本次操作选择 DeepSeek-V4-Flash High，主要考虑是响应速度。

插件页更能说明上一篇所说的插件树。界面把日常配置收拢成终端、Agent 循环和网页搜索等几组项目，插件列表显示当前部署已经安装了 133个插件。日常任务只呈现预设装配后的能力，设置页负责观察和调整底层组合。`Everything is a Plugin` 到这里已经影响了产品怎样组织配置。

Agent 预设页面提供标准模式、PTC 模式、极简模式和创造模式。这里解释一下Profile和Agent预设（Agent Preset）的区别：预设作用于单个 Session，决定 Agent 收到的提示、工具和能力组合；Profile 作用于整个进程，决定 DeepSeek Harness 以 Web、Headless （以后还会有TUI）等哪种形态启动。

标准模式是一套功能完整的 Coding Agent，常见的文件、Shell 与搜索能力都已经装好，并支持 Skills、计划和子代理。

PTC 模式保留这套能力，通过 Code Mode SDK 把工具呈现给模型，模型可以写一段 TypeScript 程序组合多步操作。我以前经常用一个 Claude Code 会话向 tmux里的另一个Claude Code 发送指令，以便自动化地驱动实际编码工作继续执行；PTC 把这类程序化编排放进 Agent 的工具调用方式中，进一步中和了人与AI之间的责任对立。

极简模式只提供持久 Bash 与 `str_replace_editor`，提示和工具目录都更短。它适合测试模型在有限 Context 下怎样工作，熟悉系统的人也可以从很小的组合开始搭建能力，如果用户有能力自己精准Context，模型会显得智能更多，我在X上看到有人声称在极简模式跑DeepSeek V4 Pro，获得了与Claude Fable 5差不多的跑分结果。

创造模式面向 Agent 预设本身，提供运行时检查、插件实验和预设创作指导。第一篇文章推测 DeepSeek Harness 的设计范围会走出代码工作，创造模式已经给这条路径提供了产品入口。

这次操作的目标是观察一次完整任务怎样被记录，所以我选择标准模式，权限保持 `Workspace Write`。

## 运行

为了让每一步都能独立核对，我准备了一个很小的 Python 项目。它读取一份云服务事件 CSV，按照严重程度统计数量，并输出 JSON。`README.md` 规定统计规则，`incident_summary.py` 是实现文件，`data/incidents.csv` 保存五条样例数据，`tests/test_incident_summary.py` 包含两项测试。

样例数据故意混入了 `critical`、`CRITICAL`、`Critical` 和 `Warning` 等写法。README 要求统计时忽略大小写和两侧空格，初始实现却直接拿原始字符串计数。第一项测试只检查是否读到五条事件，可以通过；第二项测试要求归一化以后得到 `{"critical": 3, "warning": 2}`，因此会失败。项目只使用 Python 标准库，Agent 必须对照说明、实现、数据和测试才能找到原因，使用者也能逐项验证它的判断。

我新建一个名为 `dsh` 的 Workspace，把项目文件复制进去，然后发送第一条任务：

> 先不要修改任何文件。请说明这个项目做什么、主要文件之间是什么关系，并运行全部测试。测试失败后，请依据代码与测试定位原因，先停下来汇报，不要修复。

Agent 从目录检查开始，读取 README、实现、测试和数据。第一次运行 `python -m unittest discover -s tests -v` 时，系统找不到 `python` 命令并返回 `exit code 127`。它检查环境后发现 `/usr/bin/python3`，改用 Python 3 执行测试，得到一项通过、一项失败。最终汇报把失败定位在 `incident_summary.py`：统计 `severity` 时缺少 `.strip().lower()`，代码、CSV 和测试断言能够互相印证。

底栏显示 `1 轮 · 7 步`，轨迹（上一篇文章中用的英文术语 Trajectory）中可以数出 `10` 次工具调用。这里的 Turn 从一条用户输入开始，到这一轮任务结束；Step 对应一次模型请求及其触发的工具调用。Agent 读取工具结果以后需要重新请求模型，于是一个 Turn 里形成了多个 Step。

第二轮才允许修复：

> 现在用最小改动修复这个问题。只允许修改实现文件，不要修改 README、测试文件和数据文件。修复以后运行完整测试，并说明修改了哪段逻辑、为什么符合 README 中的统计规则。测试全部通过以后停止，不要进行其他重构。

Agent 使用 `edit` 工具修改 `incident_summary.py`，把 `item["severity"]` 换成 `item["severity"].strip().lower()`。修改范围只落在这一行，界面直接展示前后的代码。完整测试随后两项通过，Session 累计为 `2 轮 · 11 步`。

第三轮只做会话回顾。我要求 Agent 依据当前历史，按照发生顺序列出前两轮的每一次工具调用，并禁止重新读取文件和合并同类调用。它准确列出第一轮的十次调用和第二轮的三次调用，其中包括最初失败的 `python` 命令、环境探测、文件编辑、完整测试，以及测试通过以后追加的一次 CLI 验证。第三轮的工具调用数为零，底栏变成 `3 轮 · 12 步`，总调用数维持在 `13` 次。

## 分析

对话页面已经把读取、编辑和 Bash 调用插入回复中，它和常见的 Coding Agent 差别不大。DeepSeek Harness 的特点从底栏和“轨迹”页签开始出现。底栏持续显示 Turn、Step、模型耗时、工具耗时、token、缓存命中率与吞吐率；轨迹则按发生顺序展开用户输入、Context、模型响应和工具调用，并用 Input、Model、Tools 三条时间轨道表示它们的先后关系。

轨迹中的每一项都可以点开。模型调用会显示所属 Turn 和 Step，以及 token、延迟和吞吐率；工具调用提供 Payload、Result、Schema 和 Timing。比如第一次 Bash 调用的 Payload 是 `pwd && ls -la`，右侧可以看到完整结果与 `68 ms` 耗时。环境中缺少 `python` 的报错始终停留在原来的 Step，后续测试成功也不会改写这条记录。

第二轮提供了更有意思的观察。Agent 完成修改并运行完整测试，在模型消息中写下 “All tests pass”，接着发起一次 Bash 调用，用样例数据运行 CLI，工具描述是 `Sanity-check CLI output on sample data`。这项检查其实违背了用户的明确要求“测试全部通过以后停止”，只是它并没有带来除了消耗少量token以外的负作用。

这个案例恰好说明：轨迹不仅用于定位失败，也能帮助用户更直接地发现模型每一步的具体判断和执行情况。在这个案例中即使追加验证的风险很低，甚至让结果更扎实，它依然偏离了停止条件。而这种情况其实一直以来都在agent之中隐式发生。当用户看到具体 Step 以后，可以决定这种行为是否应该保留，并修改提示、权限或工作流。优秀的可观测性无法替人判断，它让偏离在积累之前就有机会被发现。

Session 右上角提供 Session Log 下载。导出的 ZIP 中包含 `session.jsonl`，第一轮文件共有 `256` 行，其中可以统计到 `1` 组 Turn 边界、`7` 组 Step 边界、`7` 条 Assistant Message，以及 `10` 次工具调用和对应结果。第三轮结束后的日志增长到 `513` 行。用户消息、运行时 Context、权限策略和 Session 标题都作为事件保存在同一份历史中。

对话、轨迹和 Session Log 对应三种阅读方式。对话适合跟随任务并阅读结论；轨迹适合按 Turn 和 Step 检查模型与工具；Session Log 适合精确统计、程序分析和故障留档。日志范围止于 Runtime 能够观察的输入、输出、工具调用与状态变化，模型服务内部的私有推理不在其中。

第三轮的复述刚好提供了一次交叉检查。Agent 的自述与 Session Log 完全一致，说明当前会话历史足以支持它回顾前两轮。独立记录的作用与本次回答是否准确无关：模型汇报可以与事件记录核对，遗漏会形成可以定位的差异。AI Workflow Owner 无需把最终总结当作唯一事实来源。

任务结束后，我刷新浏览器，Workspace、Session、对话和 `3 轮 · 12 步` 的轨迹都能继续打开。停止 Web 进程并重新执行启动命令以后，中文设置、模型配置、Workspace、Session 和 Session Log 入口也被恢复。这个结果确认了同一台机器、同一用户配置下的持久化行为，恢复过程非常顺滑。

如果把上一篇的概念放回这次操作，它们已经串成了一条具体路径。启动命令通过 Profile 与 Bundle 形成 Web 应用；Agent 预设为 Session 选择提示和工具；用户输入开启 Turn，模型请求与工具调用构成 Step；轨迹把运行过程展开放在界面上，Session Log 把事件保存下来。Cordis、Capability Seam 和 Reversible Effect 处在更深的实现层，后面的代码走读会沿插件依赖、能力替换与卸载清理逐项检查。

## 结论

这次操作给我的整体感觉是，DeepSeek Harness 已经把“完成一次代码任务”和“检查这次任务怎样完成”做成了两个连在一起的层次。前一层我们早已很熟悉：选择 Workspace，发送任务，观察文件读取和命令执行，检查修改，最后运行测试。后一层提供了 Turn、Step、轨迹、工具详情和 Session Log，让使用者从不同深度复核同一段过程。

它的复杂性也因此有了更准确的位置。初始页面隐藏了一百多个插件和运行时概念，普通的代码任务可以直接开始。配置页与轨迹页承担了更多信息，它们服务的是准备改变 Agent 组合、追查异常或维护工作流的人。最终使用者可以停留在对话界面，AI Workflow Owner 会进入轨迹和日志，找到应当修改的提示、权限、工具或停止条件。

这次只是一个很小的对于操作使用的测试，三轮下来token总共花了0.09元。但可以确认的是，DeepSeek Harness 所说的可观察运行过程已经进入产品，测试失败、环境适配、文件修改和额外命令都会落到具体的 Turn、Step 和工具结果上，这已经是一个完整可用，而且还充满想象力的产品了。

我之前喜欢 DeepSeek Harness 把 Session Log 放在显眼位置，原因正是在这里。Agent 很容易给出一份听起来完整的汇报，长期工作流却不能只靠这份汇报维持信任。能看清它做过什么，才有机会判断它为什么偏离，以及下一次应该改变哪个控制位置。这次操作强化了我对 DeepSeek Harness 的判断：它首先是一套可以完成任务的工具，也在认真建设一套让人能够检查和维护 Agent 的运行系统。