DeepSeek Harness 进阶玩法：Agent Teams、动态工作流与自然语言开发插件

很多人第一次接触 DeepSeek Harness（简称 DSH）时，会把它理解成“一个可以调用 DeepSeek 的聊天窗口”。这个理解太窄了。DSH 更接近一个可插拔的 Agent 运行环境：它负责承载模型、工具、会话、Agent Loop 和界面，而具体能力可以通过插件继续扩展。

本文根据视频《DeepSeek Harness 进阶玩法：Agent Teams、动态工作流、零门槛创建插件》整理，并结合公开文字稿重新编排为一份可执行的进阶指南。文章重点不是复述视频中的每个点击，而是回答几个更实用的问题：

• 标准、极简、PTC 和创造模式分别适合什么任务？
• 插件到底改变了什么，如何判断一个插件值得安装？
• Agent Teams 和动态工作流为什么有用，什么时候反而会增加复杂度？
• 不会写完整前端插件时，能不能让 DSH 用自然语言帮自己扩展？

DeepSeek Harness、社区插件和模型适配器都在快速变化。本文中的菜单名称、命令和插件仓库应作为理解路线，实际操作时请以项目仓库当前 README、版本和本地界面为准。

先看结论：第一次使用只完成一条闭环

不要一开始就安装所有插件，也不要一上来让 Agent 修改整个项目。第一次使用的目标应该很小：

安装 DSH
  → 选择一个模型并完成最小配置
  → 用标准模式阅读一个项目
  → 让 Agent 修改一个小文件
  → 查看 diff
  → 运行一次验证命令

这条路径能同时验证四件事：

1. 模型配置是否可用。
2. DSH 是否能正确读取当前目录。
3. Agent 是否能调用工具并写入文件。
4. 你是否理解它在修改前后做了什么。

最初的练习可以是：

阅读当前项目的 README 和 package.json，
告诉我项目的启动命令、主要入口文件和可能的风险。
不要修改任何文件。

确认阅读结果合理后，再执行一个低风险修改：

在 README 末尾增加“本地开发”一节，
只描述当前仓库已经存在的启动命令。
修改前先说明计划，完成后展示 diff。

这里的关键不是让 DSH 展示多少能力，而是建立一个可观察、可回滚、可验收的工作循环。

DeepSeek Harness 到底是什么？

可以把 DSH 看成下面这几层：

模型层       负责理解、规划和生成结果
工具层       负责读写文件、执行命令、访问外部系统
Agent Loop   负责决定下一步动作并处理工具返回
会话层       保存上下文、任务状态和历史记录
插件层       扩展模型、工具、界面或协作方式

传统脚本通常把“输入、处理、输出”写死在一个流程中。Agent Harness 则把这几层拆开，让不同实现可以组合：

同一个任务
  + 不同模型
  + 不同工具
  + 不同权限策略
  + 不同界面
  + 不同 Agent 协作方式

这种设计的好处是，社区不必等待核心项目把所有功能做进去。视觉理解、网页操作、上下文分析、终端界面、多 Agent 协作，都可以作为独立插件加入。

代价也很明显：插件是第三方代码，质量、维护状态、依赖和权限范围都不统一。安装插件时，应该把它当成一段需要审查的代码，而不是浏览器里的普通主题。

安装前准备

运行环境

根据教程的流程，安装前至少需要准备：

• 能运行 Node.js 的开发环境；
• 一个可用的 DeepSeek 或兼容模型 API 配置；
• Git，用于下载项目和查看插件仓库；
• 一个用于测试的独立项目目录；
• 能够回滚的 Git 工作区。

官方 Web 入口可以用下面的命令启动：

npx @deepseek-ai/dsh web

命令执行后会输出本地 Web 地址。第一次打开时，需要配置 DeepSeek API Key；密钥应保存在本地配置中，不要写进仓库、截图或交给不必要的插件。

不建议第一次直接在生产仓库、包含密钥的目录或有未提交改动的工作区里测试。先创建一个小型练习项目，或者至少先记录：

git status
git branch --show-current

如果当前目录有重要未提交修改，先提交或复制一份，再让 Agent 进入自动编辑模式。

配置模型时先追求可用

第一次配置模型时，不要同时调试一堆高级参数。先确认下面这条链路能完成：

输入任务
  → 模型返回计划
  → Agent 调用一个工具
  → 工具返回结果
  → Agent 给出最终答复

如果调用失败，先判断失败发生在哪一层：

现象	优先排查
模型完全没有响应	API 地址、密钥、模型名和网络
能聊天但不能读文件	当前工作目录、权限或工具配置
能读文件但不能写文件	编辑模式、目录权限或安全策略
命令执行后结果异常	命令本身、环境变量和工作目录
只会反复解释，不采取动作	任务描述不够具体或当前模式限制

不要把所有问题都归因于模型能力。Agent 系统通常是多个组件拼起来的，先定位层级，修复速度会快很多。

四种运行模式

视频里真正值得理解的四种模式，不是简单的“自动程度开关”，而是当前会话加载了哪些工具插件。模式不同，Agent 能看到的工具集合、任务边界和适合的工作类型也不同。

标准模式：日常工作的默认入口

标准模式加载完整的常用能力，通常包括文件编辑、Shell 命令、网页搜索、子 Agent 和 Skills 等。代码阅读、项目开发、调研和普通自动化任务，都可以先从这里开始。

它适合：

• 阅读和修改代码；
• 运行测试、构建和脚本；
• 生成架构图或文档；
• 调用搜索、Skills 和子 Agent；
• 需要多个工具配合的日常任务。

如果你还不确定该选哪种模式，先用标准模式，再根据任务是否需要更强的工具编排切换。

极简模式：只留下最基础的工具

极简模式只保留 Bash 和文件编辑等少量基础能力，其他插件不参与当前会话。它更适合做最小环境 benchmark、隔离变量，或验证模型在没有额外工具帮助时的纯编程能力。

普通用户不需要把它当成默认模式。它的主要价值是回答：“问题来自模型本身，还是来自搜索、Skills、子 Agent 等额外能力？”

PTC 模式：程序化工具调用

PTC（Programmatic Tool Calling）模式允许模型生成一段 TypeScript，把多个工具调用串成一个程序后再执行。普通模式是“调用一个工具、读取结果、决定下一步”；PTC 更像是“先写出一段小型自动化脚本，再批量运行”。

它适合：

• 批量重命名或移动文件；
• 遍历目录并汇总结果；
• 多步骤且逻辑固定的自动化；
• 需要减少大量单步工具往返的任务。

PTC 并不意味着可以跳过审查。生成的 TypeScript 本身就是一段可执行代码，应检查它访问的目录、调用的命令和异常处理。

创造模式：检查、试验和创建插件

创造模式继承标准模式的主要能力，并允许 Agent 检查当前插件树、试验插件组合、创建新的插件或定义新的模式预设。视频中用它开发桌宠插件，展示了“让 Agent 修改自己的运行环境”的可能性。

创造模式适合：

• 开发新的 DSH 插件；
• 移植已有工具或界面组件；
• 创建团队专用的模式预设；
• 检查当前插件如何影响 Agent Loop；
• 在人工批准后安装和验证新的能力。

由于创造模式接触的范围更大，建议先在测试目录中使用，并要求 Agent 先输出权限和安装计划。

四种模式怎么选？

可以用一个简单的决策表：

任务特征	推荐模式	核心原因
日常开发和多工具任务	标准	工具集合完整
需要隔离变量或做最小基准	极简	降低外部能力干扰
多步骤、逻辑固定的批处理	PTC	用程序串联工具调用
创建插件或模式预设	创造	可以检查并改装插件体系

一个实用的路径是：

标准 → PTC
标准 → 创造

不是每个任务都需要切换模式。任务越接近日常开发，越适合留在标准模式；任务越像确定性批处理，越可以尝试 PTC；只有确实要开发或改装插件时，才进入创造模式。

用四个小任务建立手感

任务一：让 Agent 介绍项目

阅读项目结构、README、依赖配置和主要入口。
输出：
1. 项目解决什么问题；
2. 本地启动命令；
3. 主要模块；
4. 测试命令；
5. 你无法确认的地方。
不要修改文件。

验收标准是：你能根据输出找到入口文件，并用命令启动项目。不能只看回答是否流畅。

任务二：增加一个小功能

给当前项目增加一个“健康检查”接口。
先提出计划，说明会读取和修改哪些文件。
确认计划后再实现。
保持现有路由风格，并补充一个最小测试。
完成后运行测试并展示 diff。

这个任务能够验证 DSH 是否理解现有架构，而不是只会生成孤立代码。

任务三：让 Agent 调查问题

定位“用户登录后偶尔被重定向到首页”的原因。
先不要修改。
请追踪登录状态、路由守卫、错误处理和相关测试，
最后给出最可能的根因、证据和最小修复方案。

调查任务先使用标准模式，并在提示词中明确“先调查、不要修改”。先让 Agent 解释证据，再让它修改，能显著减少“修了症状但没修原因”的情况。

任务四：把重复工作交给 PTC

在临时分支中，统计 src/legacy/ 下所有旧导入路径，
生成一个迁移计划，并用一段可审查的 TypeScript
批量更新符合条件的文件。
只允许修改这些文件，不安装依赖，不删除文件。
执行前先展示将要运行的程序和文件清单；失败立即停止并报告。

这个任务适合 PTC，因为它的步骤很多，但每一步的逻辑相对固定。重点仍然是三个前提：范围明确、动作可回滚、验收自动化。

插件的价值：改变能力，而不只是换皮肤

DSH 的插件可以粗略分成四类：

类型	作用	例子
能力插件	增加视觉理解、搜索、浏览器控制等工具	ModLens、ModSearch、dsh-browser
协作插件	把任务分给多个 Agent 并汇总结果	Agent Teams
工作台插件	改善会话、上下文、终端和任务管理	dsh-context、dsh-TUI、dsh-web-ui
体验插件	主题、桌宠、界面和社区创意玩法	dsh-deep-whale、dsh-genui

选择插件时，先看它改变的是哪一层。一个视觉插件可能需要外部模型和图片上传权限；一个浏览器插件可能可以读取已登录页面；一个工作台插件可能会修改大量界面组件。功能名称相似，权限边界可能完全不同。

插件安装前的四项检查

1. 来源：仓库是否是作者公开维护的项目，安装包是否能从可追溯的 Release 获取。
2. 维护：最近是否有提交，是否有人处理兼容性问题，Issue 是否有明确回复。
3. 依赖：是否需要额外 API Key、浏览器扩展、后台服务或本地端口。
4. 权限：能读取哪些文件、能执行哪些命令、能访问哪些网络资源。

建议每次只安装一个插件，用一个小任务验证后再装下一个。否则发生问题时，很难判断是核心版本、插件冲突还是配置错误。

Agent Teams：什么时候值得拆成一支队伍？

Agent Teams 的思路是让一个 Captain 负责拆题和汇总，再由多个成员 Agent 并行处理不同方向。

例如代码审查可以拆成：

Captain
  ├─ 功能审查：行为是否符合需求
  ├─ 安全审查：输入、权限和敏感数据
  ├─ 性能审查：复杂度、缓存和资源使用
  └─ 测试审查：覆盖率、边界和回归风险

它真正有价值的前提是：子任务之间相互独立，并且每个成员都有清晰的验收输出。

适合使用 Agent Teams 的任务：

• 同一份代码需要多个专业角度审查；
• 调研需要同时收集、验证和归纳；
• 大项目可以按模块分工；
• 某些任务必须并行完成才能节省时间。

不适合的任务：

• 只改一个按钮文案；
• 需要所有步骤严格串行；
• 子任务共享大量上下文；
• 结果没有明确的合并标准。

多 Agent 会增加上下文、调度和汇总成本。第一次使用时，先拆成两个成员就足够：

成员 A：只检查功能和接口行为。
成员 B：只检查安全和异常处理。
Captain：合并重复问题，按严重程度排序，不自行添加没有证据的结论。

团队提示词应把“谁负责什么”和“什么算完成”写出来。否则多个 Agent 只是重复阅读同一批文件，最终由 Captain 把重复内容重新拼在一起。

动态工作流：让任务根据结果决定下一步

动态工作流和固定脚本的区别，在于下一步不是预先写死的，而是由当前阶段的结果决定。例如：

读取仓库
  → 判断项目类型
  → 选择对应的检查 Agent
  → 汇总问题
  → 只有发现高风险项时才启动安全复核
  → 根据复核结果决定是否修改

这种工作流适合任务分支明显、每一步都有判断条件的场景。它可以和 Agent Teams 组合：Captain 先识别项目和问题类型，再动态调度真正需要的成员，而不是每次都启动完整团队。

设计动态工作流时，建议把每个节点写成明确的输入、输出和转移条件：

节点	输入	输出	下一步条件
项目识别	文件树、依赖配置	项目类型和入口	类型已确认
功能检查	目标模块、需求	行为问题清单	发现功能风险
安全检查	风险清单、敏感路径	安全问题和证据	存在高风险项
修复执行	已确认问题	补丁和测试结果	测试通过
汇总	各成员结果	最终报告	所有必需节点完成

这样做有两个好处：一是避免无条件启动多余 Agent，二是让失败能够停在具体节点，而不是最后只得到一句“任务未完成”。

自然语言开发插件：从需求到可安装包

视频教程里最有启发性的部分，是展示了如何让 DSH 帮助开发自己的插件。这里的重点不是“完全不写代码”，而是让 Agent 负责搭建、解释和迭代，人负责定义边界、验收行为和检查权限。

插件的最小组成

一个可安装插件通常至少需要：

• 插件元数据文件，例如名称、版本和入口；
• 主入口文件；
• 必要的样式或资源；
• 构建脚本和依赖配置；
• 使用说明；
• 一条可重复的安装或加载方式。

在让 Agent 开始前，先定义一个小功能。例如：

开发一个 DSH 插件：
当用户输入 /recent 时，列出当前项目最近修改的 5 个文件。
只读取 Git 状态，不修改文件，不执行网络请求。
先给出目录结构、权限边界和验收用例，不要写代码。

这样做的好处是，插件的产品需求、权限要求和测试条件先被固定下来。之后再让 Agent 生成实现：

按照刚才确认的目录结构实现插件。
遵循当前 DSH 插件 API 和仓库已有代码风格。
不要引入不必要的依赖。
完成后给出构建命令、安装方式、已知限制和测试结果。

从自然语言到插件的迭代循环

推荐使用下面的循环：

描述一个动作
  → 让 Agent 先写验收标准
  → 生成最小插件
  → 构建并加载
  → 用真实输入测试
  → 只修一个失败点
  → 记录版本和限制

不要一次把“搜索、浏览器控制、任务面板、主题和多 Agent”全部塞进一个插件。功能越多，入口、状态和权限越难测试；一个小插件稳定后，再通过组合或第二个插件扩展。

验收一个自制插件

至少验证以下内容：

• 插件能被 DSH 识别和加载；
• 禁用插件后，核心功能仍然可用；
• 正常输入得到预期结果；
• 空输入、错误输入和权限不足时能明确失败；
• 插件不会静默修改无关文件；
• 依赖缺失时能给出可读错误；
• 重新启动后状态不会悄悄丢失；
• 构建产物与源码版本一致。

如果插件涉及文件、浏览器或外部 API，还要额外检查数据边界。能完成任务不等于权限设计合理。

常见失败与恢复方法

Agent 反复规划却不执行

可能原因：

• 当前仍处在不允许自动编辑的模式；
• 任务只描述了目标，没有给出允许修改的范围；
• Agent 在等待一个未明确的确认；
• 工具调用失败但错误信息被忽略。

恢复步骤：

1. 查看当前模式和待确认动作；
2. 明确允许修改的文件；
3. 给出一个可验收的小步骤；
4. 要求展示执行结果，不要只输出“已完成”。

Agent 修改了不该修改的文件

先不要继续让 Agent 自动修复。立即查看：

git status
git diff --stat
git diff

把需要保留的改动单独记录，再回到上一个可用提交或临时分支。后续提示词中明确“只允许修改哪些文件”，并将任务拆小。

插件安装后界面或工具异常

优先按下面顺序排查：

1. 记录 DSH 核心版本和插件版本；
2. 禁用最近安装的插件；
3. 重启 DSH；
4. 单独重新启用插件验证；
5. 查看插件 README 和 Issue；
6. 必要时回滚到上一个已知可用版本。

一次安装多个插件会让这个过程变得困难，所以插件管理也应该像依赖升级一样保持可追踪。

Agent Teams 输出重复或互相矛盾

检查子任务是否真的独立，以及 Captain 是否有合并规则。可以要求：

只保留有文件、行号或可复现实验支持的问题。
相同根因只保留一条，注明涉及的多个位置。
无法确认的内容放入“待验证”，不要当成结论。

自制插件能构建但不能加载

常见原因包括元数据字段错误、入口文件路径不匹配、构建产物没有复制到正确目录，或者插件 API 与当前核心版本不兼容。让 Agent 先输出“加载链路”：

从 DSH 发现插件目录开始，逐步列出它如何读取元数据、
加载入口文件、注册命令并显示错误。
不要修改代码，先给出排查清单。

比起让 Agent 连续重写代码，先确认它到底有没有被加载，通常更快。

一套可复用的 DSH 任务模板

以后给 DSH 分配任务时，可以使用这份模板：

任务目标：
[一句话描述唯一目标]

背景：
[项目是什么，为什么要做]

允许读取：
[目录、文件或日志范围]

允许修改：
[精确到目录或文件]

禁止操作：
[删除、联网、安装依赖、发布、修改 Git 历史等]

执行模式：
[标准 / 极简 / PTC / 创造]

验收标准：
1. [可观察的行为]
2. [需要运行的命令]
3. [需要展示的 diff 或输出]

失败时：
[遇到什么情况必须停止，以及如何报告]

这份模板的价值在于把自然语言目标转成输入、权限、动作和验收四个部分。Agent 越自主，权限和失败处理越不能省略。

最后：把 DSH 当成一个可维护的能力层

DeepSeek Harness 值得关注的地方，不只是它能调用哪个模型，而是它提供了一种更开放的 Agent 工作方式：

• 用标准模式完成日常开发和多工具任务；
• 用极简模式隔离变量或测试最小工具集合；
• 用 PTC 批量执行逻辑固定的多步骤工作流；
• 用创造模式检查、组合和创建插件；
• 用插件增加视觉、搜索、浏览器和协作能力；
• 用 Agent Teams 将真正独立的工作并行化；
• 用自然语言让 Agent 参与构建新的插件。

但开放性也意味着责任边界更清楚：插件不是模型输出，Agent 也不是自动获得正确权限。真正可靠的使用方式，是把每次扩展都当成一个小型工程变更，记录版本、权限、输入、输出和回滚路径。

第一次使用 DSH，完成一个小任务并看懂 diff，就已经足够。等这条闭环稳定下来，再逐步加入插件、团队和自动化流程，最终让 Harness 适应你的工作方式，而不是让工作方式被一堆未经验证的功能牵着走。

来源说明

本文整理自 YouTube 视频《DeepSeek Harness 进阶玩法：Agent Teams、动态工作流、零门槛创建插件》及其公开文字稿，内容经过结构化改写和补充。视频中的具体版本、插件名称、命令和界面可能随项目更新而变化；安装前请以 DeepSeek Harness 官方仓库及对应插件的当前文档为准。