来源：DeepSeek Harness

本文属于《DeepSeek Harness 入门教程（实战版）》· 第五部分 · 排错与进阶

第 18 章　进阶学习路线：从“跟着做”到独立完成任务

走到这里，你不需要再用“看过多少菜单”衡量自己。更有意义的问题是：离开教程以后，你能不能把同一套方法迁移到自己的项目，并用证据说明任务真的完成了？

这一章先验收主线，再把后续学习分成几条路线。你不必把所有高级能力都学一遍；先选眼前任务真正需要的一条，通常进步更快，也更安全。

18.1 先做一次主线验收

打开本教程使用的 daily-report 工作区，分别从 DSH 和系统终端检查结果。

在 DSH 中确认四件事

1. 新建一个标准模式、Read Only任务，只让模型读取 PROJECT.md 并概括项目边界；
2. 打开模型选择器，能指出当前任务走的是账号模型还是某个 API Provider；
3. 打开任务的执行轨迹，能分辨模型回复、文件工具、Shell、审批和子智能体记录；
4. 打开“设置 → 插件”，能说明一个插件属于哪个 Profile、是否启用、是否成功加载。

这四项证明的是模型、工作区、Agent 和插件四层都能被你独立辨认，而不是某次对话碰巧成功。

在系统终端确认项目状态

进入 daily-report 目录，运行：

npm run check
npm test

两条命令都应以退出码 0 结束。然后检查下列成果仍然存在：

PROJECT.md
sources.json
src/
test/
AUDIT.md
.dsh/skills/daily-report-maintainer/SKILL.md

如果还保留了定时任务，再到 Schedule 列表确认它的启用状态、下一次执行时间和时区；不准备继续运行，就应停用或删除练习任务，避免以后产生意外网络请求。

只有 DSH 说“已完成”而终端检查失败，不能算通过；项目检查通过，但你不知道任务用了哪个模型、权限和工具，也还不能算真正掌握 Harness。

18.2 已经掌握什么，哪些只是见过

完成前面的实操后，你已经亲手用过这些主线能力：

• Desktop 或 CLI/Web 的安装、启动与工作区选择；
• 账号模型、官方 API Key、内置 Provider 和自定义模型 API；
• 标准、PTC、极简模式的任务选择，以及自定义 Agent 预设；
• 插件的配置、发现、启停、加载检查与 Profile 隔离；
• 文件修改、Shell、计划、审批、差异审查和独立测试；
• 项目级 Skill、MCP、子智能体、Goal、Schedule 与 Headless；
• 按应用、模型、工具、权限和项目五层排错。

下面这些能力在课程里只做了定位或边界说明，不等于你已经会用：

进阶方向	适合解决什么问题	目前应保持的认识
Browser Use	让 Agent 检查、操作网页	当前后端仍属实验性能力；网页状态、登录态和已发生的操作不一定能撤销
Computer Use	操作本机桌面应用并获取截图	需要图形会话、系统权限和支持图像的模型；属于高权限实验能力
Agent Team	让具名成员用持久消息和共享任务板持续协作	当前仍以实验性插件发布；本教程只实操了 Subagent，没有启用 Team
SSH 远程工作区	DSH 留在本地，文件和命令在远端执行	当前版本发布说明已列出这项能力；远端路径、凭证、Shell 和网络边界都要重新验收
Office	创建或修改 DOCX、PPTX、XLSX	Desktop 已带相关 Skill 和运行时，但仍需结构检查与必要的视觉检查
Python SDK	由 Python 程序启动并驱动 Harness	面向程序化集成，不是更方便的聊天入口
ACP	让受信任的外部控制器管理 Agent Session	是自动化协议面，刻意不提供完整 DSH 界面能力
自定义插件	新增服务、工具、界面或替换实现	需要理解 Cordis、Profile、bundle、生命周期和发布安全

这些方向都值得学，但不应该因为“看起来高级”就一起开启。尤其是 Browser Use 和 Computer Use：取消一次调用，并不能撤回已经送到网页或桌面应用的点击、输入和提交。

18.3 先迁移到一个真实的小项目

最好的下一步不是继续装插件，而是把日报助手的工作方法搬到你真正在维护的项目。项目可以是一段脚本、个人网站、笔记整理工具，甚至是一个只有十几个文件的小仓库。

第一次迁移时，仍按同一个顺序：

只读盘点 → 写清目标和边界 → 计划一次小改动
→ 审查差异 → 运行项目自己的检查 → 记录结论

建议选择能在一两个小时内验收的任务，例如“给个人脚本增加一种输出格式”，而不是“重构整个项目”。先让标准模式完成只读盘点，再切到 Workspace Write 实现；只有当任务确实需要大量结构化查询或批处理时，再拿同一任务与 PTC 对照。

完成后至少留下三样东西：

• 一段准确的项目说明，写清入口、边界和验证命令；
• 一项小而完整的改动，以及你审查过的实际差异；
• 一条绕过 Agent 也能重复运行的验收命令。

如果这三样都没有，换了项目也只是重新聊了一次天。

18.4 定制时遵循“够用就停”

遇到重复工作时，从最轻的机制开始，而不是直接写插件：

1. 项目文档与测试：所有协作者都应遵守、并且能用代码验证的规则，先留在项目里；
2. Skill：需要 Agent 按固定流程工作，但不需要新增底层能力时，用项目级 Skill；
3. Agent 预设：需要固定系统指令、工具组合和行为方式时，再创建自定义预设；
4. Profile：需要隔离插件、Provider、服务组合或运行入口时，创建独立 Profile；
5. MCP：需要连接已有外部服务，并能把授权范围限制清楚时，再接 MCP Server；
6. 插件：只有现有服务和工具表达不了能力，或你要替换 Harness 的某个实现时，才进入插件开发。

每增加一层，都问三个问题：它解决了哪个已发生的重复问题？如何证明它加载并生效？如何一键停用或回退？答不上来，就暂时不要增加。

官方架构说明把 Harness 描述为由 Cordis 插件、Profile 和 bundle 组合而成；这解释了它为什么容易扩展，也解释了为什么配置错误会跨越多个层次。官方架构说明

18.5 接入外部能力时，先做正反两次验收

网页搜索、MCP、Schedule、浏览器和远程工作区都会把任务带到项目目录之外。接入时不要只验证“能访问”，还要验证“不该访问的地方确实访问不到”。

一项外部能力至少要完成下面的闭环：

明确授权对象和范围
→ 在隔离 Profile 或练习目录中启用
→ 完成一个最小正向任务
→ 尝试一个范围外的无敏感反向任务
→ 查看轨迹和真实结果
→ 停用后再验证能力已经消失

例如 MCP 文件服务的正向检查是读取授权练习目录，反向检查是读取该目录外的无敏感测试路径并确认被拒绝。浏览器任务则应先在测试账号或可丢弃页面中验证，不要把“第一次点击”安排在付款、发布、删除或发送消息上。

官方 Browser Use 文档目前把 Playwright MCP、Chrome DevTools MCP 和 Stagehand 后端标为需要显式启用的实验性包；会话释放后，浏览器状态也不会从 Session 日志自动恢复。Browser Use 官方说明 Computer Use 的原生驱动同样标为实验性，并明确要求桌面权限和图形会话。Computer Use 原生驱动说明

18.6 想做程序化集成，再选 SDK 或 ACP

如果你的目标是“定时运行一条提示词”，第 15 章的 Schedule 或 Headless 已经够用。只有外部程序需要创建、复用和管理 Session、消费结构化事件，才需要 SDK 或 ACP。

• Python SDK适合在 Python 程序中启动同版本 Harness 运行时、运行任务并读取结果。它要求显式的 DSH_HOME，便于隔离 Profile、插件、凭证和会话；Python SDK 官方说明
• ACP适合测试运行器、外部智能体或其他受信任控制器通过标准协议驱动持久 Session。它故意不暴露计划卡片、终端视图等 DSH 专属界面；ACP 官方说明
• 自定义插件适合新增或替换 Harness 内部能力。先在本地 patch 中验证，再做 bundle；安装来自 Git 的插件可能执行构建脚本，因此要审查来源并固定提交版本。插件打包与安装指南

三者解决的不是同一个问题。SDK 和 ACP 是“从外面驱动 Harness”，插件是“改变 Harness 里面有什么”。

18.7 一份不注水的 7 天练习

每天只做一个可以检查的小结果。项目可以继续用 daily-report，也可以从第二天开始换成你自己的小项目。

天数	练习	当天通过条件
第 1 天	建立健康基线	记录版本、模型路线、Profile、权限；npm run check 和 npm test 通过
第 2 天	只读盘点真实项目	Agent 输出入口、风险和验证命令；你手动核对至少三处事实
第 3 天	完成一项小改动	审查 diff；聚焦测试和完整测试都通过
第 4 天	沉淀项目级 Skill	新任务能发现并显式调用；停用或移走 Skill 后行为恢复
第 5 天	做一次配置隔离	实验 Profile 中启用一项能力，日常 Profile 的配置与加载状态不变
第 6 天	接一个受控外部能力	正向任务成功、范围外反向任务被拒绝，并完成停用回退
第 7 天	从全新 Session 重做任务	不依赖旧对话也能完成；终端验收、差异和操作记录齐全

某一天失败，不必为了“打卡”跳过。先按第 17 章定位失败层，修复并独立复验，再继续下一天。

18.8 毕业任务：独立完成一次可复现的改造

最后选一个你愿意保留的个人小项目，完成下面的任务：

让 DeepSeek Harness 在明确边界内，为项目增加一项真实可用的小功能；把维护流程沉淀为项目级 Skill，并用项目自身命令独立验收。若任务确实需要，再接入一种受控外部能力。

具体要求如下：

1. 在新的工作区和新 Session 中开始，先用 Read Only 做项目盘点；
2. 在 PROJECT.md、README.md 或等价文件中写清目标、禁止改动区和验收命令；
3. 选择合适的 Agent 预设并说明原因，默认从标准模式开始；
4. 只实现一项可以独立交付的改动，不顺手重构无关代码；
5. 审查真实差异，并运行聚焦检查与完整回归；
6. 创建一个项目级 Skill，让全新 Session 能重复维护流程；
7. 如接入 MCP、搜索、Schedule 或其他插件，记录授权范围、费用或副作用以及停用方法；
8. 在系统终端重新执行验收，不以 Agent 的最终回复代替结果。

如果继续使用日报助手，独立验收仍是：

npm run check
npm test

如果换了项目，把这两条替换成该项目真实存在的检查和测试命令，不要照抄不存在的脚本。使用 Git 的项目还可以补一条只读检查：

git diff --check

毕业任务通过时，你应该能交出五份证据：任务边界、执行轨迹、实际差异、终端测试结果，以及能在新 Session 中调用的 Skill。外部能力不是必选项；为了凑齐功能而扩大权限，反而不合格。

18.9 接下来只选一条路线

• 想把 DSH 变成日常开发搭档：继续做 18.3 和 18.7；
• 想沉淀团队或个人工作流：重点练 Skill、预设和 Profile；
• 想连接数据源与服务：学习 MCP，并坚持正反向权限验收；
• 想做网页、桌面或远端自动化：先在隔离环境学习 Browser Use、Computer Use 或 SSH 远程工作区；
• 想把 Harness 嵌进自己的程序：选择 Python SDK 或 ACP；
• 想改变产品本身：先读架构和插件生命周期，再从最小本地插件开始。

不要同时开六条线。能够把一项能力用于真实任务、验证结果、解释边界并安全回退，比记住全部包名更接近“掌握 DeepSeek Harness”。

---

← 上一章：常见问题排查　|　回目录