最近 DeepSeek 放出的 DeepSeek Harness（简称 DSH），容易让人产生两个误解：一是把它当成 DeepSeek 模型的新版本，二是把它当成又一个套壳聊天工具。实际都不是。

DSH 更接近一套让 AI Agent 真正工作的“底盘”：模型只是其中一个零件，工具、技能、会话、沙箱、存储、执行循环、定时任务和界面都可以作为插件组合。官方把这种思路概括为 Everything is a plugin。如果说模型决定 Agent “会不会想”，Harness 解决的就是它“怎样拿到上下文、调用工具、留下记录并把任务做完”。

它最值得看的三个地方

1. 插件不是装饰，而是架构本身

很多 Agent 产品也支持扩展，但核心循环仍然是封闭的。DSH 把模型、工具、Skill、存储甚至 Agent Loop 都放进插件系统，意味着团队可以替换其中一个部分，而不必把整套运行时推倒重来。

这对需要接入私有模型、内部工具或特定审批流程的团队尤其有吸引力。官方文档已经提供 DeepSeek、Anthropic、OpenAI 以及自定义 OpenAI-compatible Provider 的配置入口；同一个会话中切换模型后，下一次请求即可生效。

2. 任务过程可以回看，而不只留下最终答案

DSH 会把一次运行写入追加式会话日志，也就是官方所说的 Trajectory。你可以恢复、分叉、搜索或回放会话。

这件事看起来没有“自动写完整项目”那么炫，但对真正的工程协作更重要：Agent 为什么改这个文件、调用过什么工具、在哪一步改变计划，都应该能够追溯。社区体验中，对 DSH 评价最稳定的亮点也正是界面清晰、上下文组织较好，以及会话轨迹透明。

3. 同一底盘可以适配不同任务

官方当前提供 Standard、Code、Minimal、Creator 等模式。它们不是简单换一个系统提示词，而是对插件和工作方式的不同组合。写代码时可以使用 Code Mode；只想做最小实验时可从 Minimal 开始；要研究插件本身，则可以进入 Creator。

这让 DSH 更像一个实验平台，而不是一个“只允许按产品经理预设方式工作”的成品应用。

15 分钟上手：先做一次安全实验

不要第一次就把 DSH 指向唯一一份工作目录。最稳妥的做法，是复制一个不含敏感信息的小项目，用它完成一次只读任务。

第一步：启动 Web UI

在终端运行：

npx @deepseek-ai/dsh web

启动成功后，浏览器访问：

http://127.0.0.1:3080

如果你准备研究源码，也可以克隆官方仓库后使用 pnpm 安装和构建：

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

第二步：配置模型

进入 Settings → Models，选择 DeepSeek 并填写 API Key。凭据会写入本机 $DSH_HOME/.credentials.yaml，界面不会再次回显已保存的密钥。

如果使用其他兼容 OpenAI API 的模型服务，需要填写 Provider ID、Base URL、API 协议、凭据和模型名。遇到网关不接受 developer role 或 max_completion_tokens 时，可以按 Provider 文档调整兼容选项，而不是先判断模型不可用。

第三步：选择工作目录

新会话默认不会替你选中工作区。选择刚才准备的测试项目，再从一个只读问题开始：

请只读取当前仓库，不修改文件。概括项目用途、主要 package、启动方式，
并列出你还不能从现有文件确认的三件事。请为每个判断给出文件路径依据。

这个问题可以同时检查三件事：DSH 能否正确理解目录、是否遵守权限边界，以及它给出的结论是否可追溯。

第四步：再做一个可撤销的小改动

确认只读任务没问题后，可以让它改一处低风险文档，并要求先计划、后执行：

先说明你准备修改哪些文件和原因，等我确认后，再补充本项目的本地启动说明。
不要安装依赖，不要运行发布命令，不要修改业务代码。

如果它能稳定完成“理解 → 计划 → 获批 → 修改 → 报告证据”这个闭环，再逐步扩大任务范围。

Windows 上需要多留意什么

官方已经让 Windows 配置默认使用 PowerShell 工具栈，不再假定 Bash，这一点比不少开源 Agent 友好。但社区讨论中仍有人遇到盘符根目录选择、文件夹选择器和子目录权限问题。

因此首次试用建议：

• 使用普通项目目录，不直接选 C:\、D:\ 等盘符根目录；
• 先避开同步盘、权限复杂目录和唯一原件；
• 默认权限起步，确认计划后再允许写入；
• 每次实验前提交 Git 或保留可恢复副本；
• 出现异常时先判断是模型调用、Provider 兼容还是工作区权限，不要把三类问题混在一起。

“使用短一些的英文路径”是我基于现有 Windows 问题作出的保守建议，并非官方硬性要求。

别人的实际评价：优点很集中，短板也很一致

目前 DSH 仍处于开发者预览，社区样本不算大，但几类反馈已经比较清楚。

正面反馈主要集中在底层体验。 有用户认为基础 Harness 扎实、界面干净、上下文和会话轨迹做得好；也有人把本地模型通过 OpenAI-compatible Endpoint 接入 Code Mode，说明它并不只围绕 DeepSeek 自家 API 工作。

保留意见主要集中在生态成熟度。 有体验者认为“万物皆插件”的方向很有吸引力，但现阶段的旗舰插件和真实案例还不足以证明生态已经成形；也有人报告一个格式错误的插件会影响整个插件系统，说明隔离和容错仍需要打磨。

模型接入不等于开箱体验一致。 有用户比较后认为，同一个第三方模型在 DSH 里的工具调用表现不如其原生工具。这未必说明 Harness 本身不好，但提醒我们：Provider 兼容、提示配置和工具协议都会影响最终效果，不能只看模型名称。

这些评价并不矛盾：DSH 已经展示了一个有辨识度的架构，但还没有证明它在所有模型、插件和操作系统组合下都足够稳定。

我的结论：值得跟进，但暂时不要押上主工作流

我会给 DSH 的当前判断是：值得跟进。

理由不是它今天已经比所有成熟工具更强，而是它抓住了 Agent 工程里三个会越来越重要的问题：可组合、可审计、可自定义。对于需要私有模型、内部工具、复杂交付流程的人，这套架构的长期价值可能高于某一次代码生成榜单。

但“值得跟进”不等于“马上替换主力工具”。在开发者预览阶段，更合理的方式是让它承担可撤销、可核验的实验任务，并持续观察三个信号：

1. 插件故障能否被更好地隔离，兼容契约是否稳定；
2. Windows 工作区、权限和长任务的稳定性是否持续改善；
3. 是否出现一批由真实团队维护、可以复用的高质量插件与工作流。

如果这三点逐步成立，DSH 就不只是 DeepSeek 的一次产品尝试，而可能成为构建 Agent 工作系统的一块长期底座。

参考资料

• DeepSeek Harness 官方产品页
• DeepSeek Harness 官方仓库
• 官方 Quickstart
• 官方 Provider 配置指南
• Windows PowerShell 默认工具栈说明
• 社区讨论：插件生态成熟度
• 社区讨论：不同 Provider 下的工具调用体验
• 社区讨论：错误插件影响运行
• 社区实践：接入本地 OpenAI-compatible 模型

很多人第一次使用 WorkBuddy，会把它当成“能操作文件的聊天机器人”：丢进去一句大而全的要求，然后等它一次交出完美结果。效果不稳定时，就继续堆提示词。

但 WorkBuddy 更接近一个能在工作区里规划、读写文件、调用 Skill 和连接器的桌面 Agent。决定效果的关键，不只是“怎么问”，而是怎样给它安排任务环境和执行边界。

腾讯云官方已经发布过一份“10 个上手技巧”。下面这份清单不照抄标题，而是结合官方任务模式、权限说明和社区实践，把那些容易被忽略、却会直接影响交付质量的用法重新整理成可执行的方法。

1. 写提示词之前，先选对任务模式

WorkBuddy 的任务模式承担不同风险：Ask 适合阅读、解释和讨论；Plan 适合先拆解复杂任务；执行类模式（不同版本界面可能显示 Default 或 Craft）才用于真正改文件、运行工具。

很多“它怎么擅自修改了”的问题，其实在发出第一句话之前就可以避免。一个简单判断方法是：

• 只需要答案或审阅意见，用 Ask；
• 任务超过三步、涉及多个文件，用 Plan；
• 目标和验收都已明确，再进入执行模式。

示例：

先使用 Plan 模式。阅读当前工作区，列出完成官网改版所需的步骤、
将修改的文件、每一步验证方式和可能风险。现在不要修改任何文件。

2. 一个任务，一个独立工作区

不要把整个桌面、下载目录或硬盘根目录交给 Agent。工作区既是上下文边界，也是安全边界。把任务所需文件复制进一个独立目录，WorkBuddy 更容易找到正确材料，也不容易误碰无关文件。

推荐结构：

客户报告-2026-08/
├─ input/       原始材料，只读使用
├─ reference/   范例和口径
├─ output/      最终交付物
└─ README.md    任务目标与禁区

第一次运行最好使用可丢弃副本。涉及代码时，先提交 Git；涉及 Office 文件时，保留原件并要求结果写入 output。

3. 用“交付契约”代替一句宽泛命令

官方建议用“做什么 + 有什么 + 怎么样”表达任务。再往前一步，可以把提示词固定成五项交付契约：

1. 目标：最终要解决什么问题；
2. 输入：只能依据哪些文件或数据；
3. 输出：文件名、格式、受众和篇幅；
4. 验收：怎样才算完成；
5. 禁区：不能改什么、不能做什么。

示例：

目标：把 input 下的会议记录整理成客户确认稿。
输入：只使用 input/meeting.docx 和 reference/术语表.md。
输出：生成 output/会议纪要.docx，面向非技术客户，不超过 4 页。
验收：决策、责任人、截止日三项齐全；不确定内容标“待确认”。
禁区：不要补造事实，不覆盖原文件，不发送邮件。

这种写法不仅提高第一次输出质量，也让你更容易判断偏差出在哪一项。

4. 给一份好范例，比堆十个形容词有效

“专业、简洁、高级、像大厂”对人和 Agent 都很含糊。一份经过认可的范例，则同时包含结构、语气、信息密度和视觉层级。

把参考文件放进 reference，明确告诉 WorkBuddy 学什么、不学什么：

参考 reference/优秀周报.docx 的标题层级、表格结构和结论先行风格，
不要复制其中的项目名称、数字和具体句子。内容只依据 input 下材料。

“给例子”不是让它照抄，而是减少审美词汇带来的理解误差。

5. 话题变了就开新任务，卡住了也别在旧上下文里死磕

WorkBuddy 支持多个独立任务。这个能力不只是为了并行，更是为了隔离上下文。

如果一个会话先做合同审查、再写公众号、又开始整理代码，前面的术语、假设和失败路径都会继续影响判断。出现以下情况时，通常应该新开任务：

• 目标、受众或交付格式已经改变；
• 连续两轮都在修同一种误解；
• 需要换一组输入文件；
• 你想比较两套彼此独立的方案。

新任务开头写一段简短交接，比在污染的上下文里不断说“重新来”更可靠。

6. 分清 Skill、Expert 和 Expert Team，再决定要不要创建

三者解决的不是同一个问题：

• Skill：一套可复用的操作方法，例如按固定模板生成周报；
• Expert：稳定的角色、领域判断和回答方式，例如合同审查专家；
• Expert Team：多个角色之间的分工协作，例如研究、起草、复核分开进行。

一个常见误区是刚上手就安装很多 Skill，结果工具选择变复杂、上下文也更嘈杂。更稳的顺序是：先手工完成三次同类任务，找出稳定步骤；步骤稳定后再做 Skill；如果瓶颈是专业判断，再配置 Expert；只有单个角色确实顾不过来时，才组 Expert Team。

7. 先让它交“变更清单”，再给写权限

权限不是越大越省事。官方权限指南建议日常使用默认权限，Full Access 只适合隔离、可恢复的环境。

对于有风险的任务，可以分两段：

第一阶段只读：请列出需要修改的文件、每个修改点和验证命令。
同时指出你缺少的信息。不要写文件、不要安装依赖、不要访问外部服务。

确认清单后再说：

同意执行清单中的第 1、2 项。第 3 项暂不执行。
完成后报告实际改动、验证结果和剩余风险。

这比一开始授予 Full Access、事后再检查所有副作用更省时间。

8. 自动化只接管“已经跑顺”的流程

WorkBuddy 可以把任务交给自动化持续执行，但自动化不会自动修复一个含糊流程，只会稳定地重复它的问题。

在设置定时或远程执行前，至少确认：

• 输入来源固定且可用；
• 同一任务重复运行不会产生重复数据；
• 失败会留下可见记录；
• 第一次正式执行可以只生成预览，不直接发布；
• 涉及发送、发布、删除或付款时仍保留人工确认。

一个好的自动化提示词还应写明“没有新数据时做什么”和“部分数据缺失时做什么”，否则最容易在边界状态失控。

9. 先在本地跑顺，再交给云端或远程助手

云端助手适合长时间运行、跨设备继续或定时任务，但不要把调试过程也一开始就搬到远程。先在本地用少量、脱敏数据跑通，可以更快确认文件路径、权限、连接器和输出格式。

迁移到云端前做一次检查：

• 是否真的需要上传原始文件；
• 能否使用脱敏副本或最小数据集；
• 连接器权限是否只覆盖必要范围；
• 最终文件写到哪里、由谁复核；
• 任务完成后是否需要清理临时数据。

“先本地后远程”不是保守，而是在成本最低的环境里暴露问题。

10. 把 Agent 输出当成一个有版本的交付物

不要只问“做完了吗”，要让 WorkBuddy 给出交付证据。每次任务结束时，可以固定追问：

请用交付清单收尾：
1. 新增或修改了哪些文件；
2. 每个关键结论依据什么；
3. 做了哪些验证，结果是什么；
4. 哪些内容仍是推断或待人工确认；
5. 如果要回退，应该恢复哪些文件。

配合 Git、文件版本或备份，这会让“AI 帮我做了什么”从模糊感受变成可检查的记录。对于不满意的结果，也不要一轮定生死：指出具体不合格项，让它只重做对应部分，而不是把已正确的内容全部推翻。

一套可以直接复用的启动模板

把前面的技巧合在一起，新任务可以这样开始：

你现在负责【任务名称】。

目标：
输入文件：
参考范例：
输出文件与受众：
验收标准：
禁止操作：

先在只读状态检查工作区，复述你理解的目标，列出计划、将涉及的文件
和缺失信息。未经确认不要写文件、安装依赖或调用外部服务。

真正好用的 WorkBuddy 工作流，往往不是靠一段神秘提示词，而是把任务拆得足够清楚：模式匹配风险，工作区隔离材料，范例校准预期，权限分阶段开放，最后用版本和证据收尾。

参考资料

• WorkBuddy 产品页
• WorkBuddy 产品文档
• 官方：WorkBuddy 10 个上手技巧
• 官方：新建任务与任务模式
• 官方：权限管理指南
• 官方：Skill 使用说明
• 腾讯云开发者社区：新手上路完全指南
• 腾讯云开发者社区：Skill 实战与适用边界