万字拆解 DeepSeek Harness 桌面版：产品设计、任务实测与能力边界
杨森从 AI 产品经理视角实测 DeepSeek Harness 桌面版：同一入口承接「做任务」和「改工具」，创造模式能把已有评审流程和核验脚本封装成跨会话插件，但生效状态、任务范围和验收条件仍要人来守。
基本信息
- 来源类型：文章（人人都是产品经理）
- 原文位置：
raw/articles/2026-10-06-173838-tg-bda84b.md - 原文 URL：https://www.woshipm.com/evaluating/6473256.html
- 作者：杨森
- 发布日期：2026-10-05
- 阅读量：1250 浏览 / 2 收藏 / 0 评论 / 标注阅读时长 40 分钟
- 消化日期：2026-10-06
核心观点
-
任务入口把「先开始工作」和「再解释配置」拆开。新会话输入框周围可同时选工作区、任务模式、访问模式、模型和推理等级。四种任务模式：标准模式处理代码、文件和资料；PTC 强调批量调用工具，以及筛选、去重、统计和汇总；极简模式只用终端，供基础表现测试与比较；创造模式用于编写插件、增加功能和界面。访问模式（仅可查看 / 工作区内修改 / 完全权限）描述操作范围，任务模式描述怎样执行，两轮对照都在「工作区内修改」下交付文件，切换模式可以沿用同一授权。作者建议默认选项继续承担大多数首次任务，需要进一步控制执行方式的人再展开选择。
-
标准模式与 PTC 的差别要落在执行路径，而不是菜单文案。同一组八条反馈、任务书和提示词，两边都用 DeepSeek-V41-Flash、High 推理等级、工作区内修改权限，各在独立会话跑一轮，交付反馈数据、评审建议、改进方案与验收、以及可操作的评审页面。PTC 这轮通过代码调用工具、处理数据并生成文件，再用本机已有的浏览器工具检查页面；标准模式直接启动 Chrome 无头浏览器，遇到权限错误后报告这一步没有完成。两边都把一条「从开发环境启动、采用替代账号」的登录反馈错归到官方桌面版历史问题——执行模式不同，并没有让这条判断自动变准。作者认为这条路径差比「快出的 9 秒」更有参考价值。
-
创造模式能把一份现成流程和脚本接成可跨会话调用的本地插件，但「写好」不等于「生效」。插件名为「公开反馈评审」：一份由用户主动调用的 Skill，加上一个检查反馈报告的工具。它经历两次纠正：第一次限制文件操作范围（输入目录、报告路径、输出位置，不能覆盖原始材料、脚本和其他成果）；第二次要求评审流程、核验工具和脚本运行服务必须同时可用，缺一项就停止加载。修改后会话提示运行时仍保留旧版工具说明，需要重启才能加载新代码。重启后，把结果写进核验脚本文件被拒绝；改到允许的输出位置后，返回三条合成记录的检查结果，四条引文全部匹配。试验结束后插件保留安装并被关闭。
-
核验通过仍然可能做错任务范围。正式任务要求只处理首批九条反馈，Agent 却把同目录第二批也合进来，生成十四条记录，再把两批一起传给核验工具。工具返回通过，因为多出来的材料都是真实本地文件，结构、编号和引文都能对上。问题出在自定义工具把具体输入文件的选择留给调用方：路径保护只解决「文件能写到哪里」，没有解决「当前任务允许纳入哪些材料」。作者给出的改法是任务开始时按已指定文件固定本轮输入清单，核验按清单检查，清单作为单独任务配置保存，报告生成步骤不应随意改动它。
-
连续三阶段反馈评审把三种变化分开：材料增加、规则修订、新批次划界。材料来自 Harness 社区公开讨论：先给八条帖子正文，再补入十二条后续评论与固定版本官方文档，最后换一批七条反馈。首次交付四份成果（结构化反馈数据、版本评审建议、改进方案与验收、可操作评审页面）。第二阶段补入官方文档后，把「终端里找不到启动命令、需要新增能力」的候选撤下——桌面端已经提供可选的命令注册入口。另一条安装问题把同一人的多条回复算成三名新用户，错误同时进入数据文件和页面。第三阶段在新会话引用修订后的流程，产品形态和版本信息被分开记录：一条第三方桌面客户端反馈被正确归类，暂时无法确认归属的材料保留待核实。
-
页面一致不等于事实正确；验收模板会悄悄扩大需求。评审台支持搜索编号、按形态筛选、查看来源和详情，页面数据与结构化文件保持一致。但新一批材料里，一条插件反馈的分析混入了另一条讨论的兼容性信息：编号和主帖链接还在，一句话已经张冠李戴。两次子智能体只读审阅之后，最终结果仍出现事实串项。第三阶段根据一条历史会话迁移反馈生成改进方案时，原帖只要求迁移被拒绝时保持原始日志不变、不发布未完成的新文件；生成的验收表却把这项限制套到迁移成功的情况，要求成功后也不能出现特定的新版本文件。同轮数字抄写也出错：报告者写 321 份日志中有 282 份被拒，摘要写成 321/282；文档列九条验收，自查写八条。
-
定制的管理方式比「能不能创建」更值得比较。作者用「创建了什么、怎样调用、修改后在哪里生效、怎样停止使用」对照三条路径：Harness 把创造模式与日常任务预设并列，运行部件（模型适配器、工具注册、会话日志、执行循环）也按插件组织，配置热更新可立即应用，改已安装插件代码则要重启，共用同一套运行配置的会话都会受影响。Claude Code 的 mod 可接入工具调用、提示、命令和回合等事件，批准热重载后在回合结束时加载，默认只在创建它的会话中使用。Codex 插件把 Skills、MCP 和 Hooks 打成可安装的包，改市场条目指向的插件目录后要重启应用；项目配置可以停用并保留安装，Hooks 还要用户审阅并信任，安装不会自动完成这一步。
-
投入顺序是先让用户看懂改动是否生效，再把容易写错的规则做成可重复检查的样例。应用层优先改善插件生效状态：当前加载版本、待生效改动、下一步是重载、重启还是新建会话，应放在同一位置。验收动作很具体——修改一条工具参数约束，界面是否指出旧逻辑仍在运行；执行提示的操作后，新会话是否按新约束返回结果。定制内容层则先固定输入清单，再用少量样例反复检查：开发启动命令与版本号冲突的材料查形态判断，同一作者多次回复的材料查人数统计，成功与失败产生不同文件的迁移情形查验收约束。来源片段展示先落在评审台，确定性规则交给工具，涉及功能取舍的判断留给产品评审。
实操内容保留
代码/配置
（本文无实操代码或配置文件。作者明确说核验脚本和评审流程是事先准备好的，创造模式完成的是连接和封装，文中没有贴出脚本、插件清单或 Prompt 原文。）
Prompt 模板
（本文无完整 Prompt 模板。）
操作步骤
对照实验的控制条件：
- 准备相同的八条反馈、任务书和提示词。
- 标准模式与 PTC 各开独立会话，模型都用 DeepSeek-V41-Flash，推理等级 High，访问权限都是工作区内修改。
- 两边都要求交付：反馈数据、评审建议、改进方案与验收、可操作的评审页面。
- 任务书另约定原始材料和输出成果分放两个目录；完成后核对输入文件保持不变。
把已有流程做成可调用插件：
- 先备好反馈评审流程和核验脚本。脚本检查编号、来源、状态和逐字引文。
- 在创造模式里说明：输入哪些材料、检查哪个报告、结果写到哪里。
- 生成并安装「公开反馈评审」插件：用户主动调用的 Skill + 检查反馈报告的工具。
- 第一次纠正操作范围：输入目录、报告路径、输出位置写死，不能覆盖原始材料、脚本和其他成果。
- 第二次补齐运行组件：评审流程、核验工具、脚本运行服务必须同时可用，缺一项就停止加载。
- 看到「运行时仍保留旧版工具说明」就重启，再开新会话用指令载入流程正文。
- 工具调用先被拒绝（要求把结果写进核验脚本文件），改到允许的输出位置后才返回检查结果。
- 试用结束用启停入口关闭插件，源文件和任务产物留在本地。
连续三阶段反馈评审怎么分变化：
- 材料增加：重新检查判断，并留下判断变化记录（第二阶段补十二条评论和官方文档后，撤下「缺少启动命令」这条候选）。
- 规则修订：先把方法写成普通流程文档，用会触发冲突的样例检验，再决定要不要封装成插件。第一版冲突是「不要仅凭版本号判断产品形态」和「版本证据优先」同时存在；纠正后改为按实际安装和启动方式判断形态，版本信息单独记录，并写入按作者去重、工作量留待评估、当前状态核查与未来验收分开。
- 新批次：换会话、换输出目录，只换分析对象（第三阶段七条新反馈），上一批候选留在原来的成果里。
验收条件不要把失败路径的限制套到成功路径：
- 成功：检查内容完整、能够打开、合法产物可验证。
- 失败：检查源文件不受损、没有误发布的半成品。
- 取消：先写明发生在哪一阶段，再说明操作之后保留什么、用户看见什么。
- 每个约束必须对应材料中的事实或明确的设计决定；新增限制要解释理由。
作者建议的投入顺序：
- 应用层先做插件生效状态，不做一整套插件治理系统。
- 模式入口只做轻量调整：保留标准模式的直接开始路径，选择时补有区别的任务例子；四种预设要不要重分类，看用户是否选错、是否反复切换、切换是否真的影响完成。
- 定制层先锁输入清单，再补三类样例（形态冲突、同人多回复、成功/失败产物不同）。
- 来源片段对照先做进评审台，观察它能否缩短定位串项的时间。
关键概念
- DeepSeek Harness — 本文的实测对象：桌面版 Agent，官方强调「万物皆插件」，创造模式可对话增加工具、技能和界面
- Agent Harness — 概念层的运行底座；本文把它落成可安装、可启停、要重启才加载新代码的桌面产品
- Skill — 插件里由用户主动调用的评审流程；作者认为易变的判断规则应先放在可阅读文档，而不是过早封装
- Claude Code — 对照项：对话创建 mod，热重载默认只活在创建它的会话里
- Codex — 对照项：插件打包 Skills、MCP 和 Hooks，改目录后重启，Hooks 需单独信任
- 人机协同 — 确定性核对交给工具，功能取舍留给产品评审；两次只读子审阅仍没拦住事实串项
- PTC 模式 — Harness 任务预设之一，强调批量调用工具并集中加工返回结果；本文未单独建实体页
- 创造模式 — 与标准 / PTC / 极简并列的入口，用来编写插件、增加功能和界面
- DeepSeek-V41-Flash — 本次标准 vs PTC 对照使用的模型，推理等级 High
- Claude Code Mods — 文中作为「按事件改造工作过程」的对照接口，本库尚无独立实体页
- Kimi Code Desktop / Qwen Code — 文中点名「会话里创建 Skill」「扩展可打包 Skills、工具和子代理」，未展开实测
与其他素材的关联
- 与 2026-08-14-01deepseek-harness 的关系：那篇是「一切皆插件」的发布速通，停留在预告和 GitHub 已发布。本篇是桌面版更新后的任务实测，把同一口号拆成入口、插件生效、任务范围和竞品管理四层，并给出标准 vs PTC 的同题对照。
- 与 2026-09-16-woshipm-enterprise-agent-harness 的关系：那篇用
Agent = Model + Harness论证企业不必自研底座，真正省不掉的是业务规则和评测。本篇是底座已经做成桌面产品之后，产品经理把自己的评审方法接进去时仍然省不掉的维护：版本是否加载、输入清单是否被调用方扩大、验收条件是否悄悄改了需求。 - 与 AI产品经理工作流 的关系：补上「拆一个 Agent 桌面产品」的评测方法——同题对照看执行路径、用会冲突的样例检验规则、用生效状态验收定制，而不是只比功能清单。
- 与 企业AI落地 的关系：第二阶段的判断变化（用户说没有启动命令，补文档后确认只是没注册）和「核验通过但范围错了」，都是「先把规则显式化，再交给工具」的现场样本。
原文精彩摘录
这次把相同的八条反馈、任务书和提示词分别交给标准模式与 PTC。两边使用同一模型 DeepSeek-V41-Flash、High 推理等级和工作区内修改权限，各在独立会话中运行一轮，要求交付反馈数据、评审建议、改进方案与验收，以及可操作的评审页面。PTC 这轮通过代码调用工具、处理数据并生成文件，再使用本机已有的浏览器工具检查页面。标准模式选择直接启动 Chrome 无头浏览器，遇到权限错误后报告了这一步没有完成。我更关注这条执行路径的差异，它解释了额外的页面验证是怎样发生的，比快出的 9 秒更有参考价值。
这项插件的一轮正式任务要求只处理首批九条反馈。Agent 却把同一目录里的第二批也合进来，生成十四条记录，又将两批材料一起传给核验工具。工具返回通过；按原任务指定的首批重新核对，记录范围超出了要求。多出来的材料都是真实本地文件。检查器拿到两批输入，报告又对应两批内容，结构、编号和引文便可以通过检查。用户指定的任务范围与工具收到的核验范围，在调用之前就已经分开了。
第三阶段还要求 Harness 根据一条历史会话迁移反馈，生成改进方案。原帖讨论的是旧版命令行工具：迁移被拒绝时，要保持原始日志不变，也不能发布未完成的新文件。生成的验收表却把这项限制套到了迁移成功的情况，要求成功后也不能出现特定的新版本文件。这会改变研发要实现的行为。
这次实测后，我对 Harness 的定位更清楚了：它适合让有明确工作方法的人，逐步搭出自己需要的工具。一份已有的评审流程和核验脚本，通过创造模式变成了可以在新会话里调用的插件。对需要反复处理同类任务的产品经理，这条路径有实际吸引力。自由定制也意味着要持续维护。规则改了，要确认工具已经采用新版本；材料增加了，要重新检查原来的判断；结果出错了，要能找到依据并完成修正。