大家好，我是 AI 超元域。
这期我从零体验 DeepSeek Harness：启动 Web UI、配置模型与工作目录，查看 Agent 的执行轨迹，再用会话分支同时探索同一个 Issue 的两种处理方向。最直观的开发测试，是继续使用 DeepSeek V4 Pro 和相同提示词，重做前一期在 Claude Code 中测试过的游戏。
Harness 的插件化设计很有吸引力，但是否适合自己的工作流，还得看任务完成度、过程可见性和操作成本。这篇文章围绕本期实际跑过的流程展开，不把一轮游戏演示扩大成对所有编程助手的排名。
本文依据 2026 年 8 月 14 日公开视频简介、章节，以及与本期示例和时间线一致的保存版校正字幕整理。未取得此次直接导出的 YouTube 字幕，也未重新执行开发任务。官方仓库于 2026 年 10 月 24 日补核，当前启动方式与拍摄时界面可能存在差异。
播放器无法加载时，可以在 YouTube 观看完整视频。
从启动到第一个可用会话
01:40的演示从官方仓库开始：在终端运行启动流程，打开浏览器里的 Web UI，填入 DeepSeek API Key，设置工作路径，再发一条简单消息确认模型连通。
这里先做连通测试，比一上来就提交大型开发需求更容易定位问题。如果模型没有响应，应先检查提供商配置；如果模型能聊天却无法操作项目，再检查工作目录与权限。不要把所有失败都归因于模型能力。
补核时，官方仓库给出的 npm 启动命令如下。这是 2026 年 10 月 24 日所见的说明，不冒充视频中未完整呈现的历史命令：
npx @deepseek-ai/dsh web
当前 README 说明默认地址为 http://127.0.0.1:3080，并提示项目仍处于 developer preview，可能发生破坏兼容性的变更。开始前应阅读当前版本说明与安全提示，不要混用旧教程的配置片段。
API Key 应保留在对应提供商的本地配置或安全输入界面中。下面的案例只讨论操作流程，不展示任何密钥、令牌或个人公网访问地址。
Web UI 远程访问：演示范围与风险
02:40中，我通过 ngrok 做了远程访问演示，并在另一台 Mac mini 的浏览器中成功打开 Web UI，修改界面主题。由于时间原因，没有继续深入测试远程开发。
所以这部分的结果应限定为“远程页面打开并可交互”，不能写成已经验证了移动端长任务、网络中断恢复或长期稳定运行。
还需要补充一个安全提醒：能够访问 Web UI，可能意味着能够驱动本机 Agent 操作代码和运行命令。公网可访问并不等于安全。不要照着演示直接把没有可靠身份验证和访问控制的界面暴露出去，也不要把隧道令牌贴进普通对话或公开文章。
实际部署时，应先明确谁能访问、能操作哪些目录、怎样收回访问权限。这里不提供未经核对的公网配置命令。
四种模式，先看任务需要什么
03:38展示了当时界面的标准模式、代码模式、最小模式和创作者模式。讲解中的标准模式包含文件编辑、命令执行、搜索、Skill、计划、目标和子 Agent 等能力；代码模式则用于本期后续开发测试。
这些是拍摄时的模式划分，不能保证后来每个版本仍保持同名入口或相同能力组合。选择时应看当前配置实际挂载了哪些工具，并从任务必需的权限开始。
本期游戏测试采用 DeepSeek V4 Pro、high 推理级别，并给予了较宽的操作权限。这样的设置属于当时演示条件，不是对所有读者都推荐的安全默认值。尤其在包含重要资料的目录中，应先备份或使用隔离副本。
执行轨迹：比一句“正在开发”更有用
05:01的重点是轨迹界面。它用不同颜色区分内容类型，可以点开系统提示、用户输入、工具调用与结果，查看调用时间和耗时。
我可以沿着这条记录追踪：它先读了什么，接着执行了什么命令，最后得到了什么返回。这对排查失败特别实用。比如最终页面没达到预期，可以回到相关工具结果，而不是只能根据最后一段自然语言猜测发生了什么。
不过，过程可见并不自动保证过程正确。日志中出现命令调用，与命令成功完成是两回事；生成了代码，与游戏可玩也是两回事。轨迹的价值，是让这些区别有机会被检查。
第三方模型与插件
在06:58，我通过界面添加 OpenRouter，填入对应配置后，在新会话中选择其提供的模型并测试响应。
这说明本期环境能够接入另一家模型提供商，但“可以连接”不等于所有模型都具有同样的工具调用可靠性、上下文能力或开发效果。切换模型后仍应重新做小任务验证。
07:38又查看了插件列表与斜杠命令。演示涉及上下文压缩、导出 Session、目标、计划和模型选择等入口。插件化让工作流更容易扩展，同时也要求认真检查插件来源与实际权限。搜索到一个插件，不代表已经安装，更不代表它完成了安全审核。
同一个 Issue，分两条会话探索
08:06，我给出一个开源项目的 Issue 链接，要求分析成因。它返回了相关代码位置与修复建议。
接着在08:40使用会话分支：新分支继续制定完善的修复方案，原会话则查找项目现有 PR 是否已经处理这个问题。
最终，两个方向都有输出：一个找到对应 PR 并给出分析，另一个形成了详细修复方案。对于实际开发，这种分支方式可以帮助比较“沿用上游已有方案”和“自行设计修改”的差别。
但本例到这里仍然是分析与方案阶段，没有演示合并 PR，也没有展示应用补丁后的完整回归测试。会话分支同样不应该被理解成代码仓库自动获得了文件隔离或冲突解决能力。
游戏对比：这一次的可玩性更好
09:46，游戏开发完成后，我实际进入场景，测试人物移动、持剑动作、攻击敌人、恢复气血与飞行，也查看了商贩和店铺等环境内容。
这次讲解中，我对 Harness 版本的可操控性、动作和打击效果评价更好。比较对象是前一天使用相同模型与提示词在 Claude Code 中生成的游戏。
这个结果说明运行框架和执行流程值得单独观察，但它仍是一轮具体项目的体验。没有多次独立运行、统一预算或客观评分，就不能据此推出 Harness 在所有任务上都优于 Claude Code，更不能据此排除提示词之外的上下文和运行差异。
保存的材料没有记录这一轮明确的崩溃或控制失效，所以这里不补写不存在的失败案例。可确认的不足主要在验证覆盖：没有完整兼容性测试、长期运行测试或性能测量。
Codex 给 Harness 派任务，验证到了哪一步
10:48，我又尝试让 Codex 通过内置浏览器打开 Harness Web UI，输入一个分析项目架构的任务。
记录显示 Codex 打开了页面，填入较完整的提示词并发送，Harness 随后开始执行。这里验证的是浏览器驱动的任务派发，不应自动等同于原生 Agent 通信协议，也不能把“已经开始执行”写成“架构分析全部完成并通过验收”。
如果把这种方式放进实际工作流，还需要考虑重复提交、任务身份、执行状态和最终结果怎样回收。本期没有完整测试这些环节，因此保留为后续探索方向。
最后的判断
DeepSeek Harness 给我最直接的印象，是 Web UI、执行轨迹和插件组合让开发过程更容易观察与定制。本期跑通了模型连接、会话分支、具体游戏开发，以及从另一个助手发起任务的入口。
对准备上手的读者，我建议先完成一个小而可验收的任务：确认模型和目录正确，观察工具结果，打开产物实际操作，再逐步加入更多插件与协作方式。把这些基础环节跑稳，比一开始就追求全权限、远程公开访问和多工具叠加更有价值。
- 本期视频与章节
- DeepSeek Harness 官方仓库与当前启动说明，补核于 2026 年 10 月 24 日。