DeepSeek Harness 调研报告 — 内容 Part 1（核心发现）

执行摘要

2026-08-13，DeepSeek 官方发布 DeepSeek Harness（dsh）——一个开源 agentic 编码工具，与 DeepSeek-V4-Pro GA 同日发布。定位是"Claude Code 的开源对手"，核心理念 Agent = Model + Harness："模型是 agent 的灵魂，harness 让 agent 理解环境、使用工具、在真实环境中持续工作"。口号：Everything is a plugin。

一句话结论：dsh 不是来替代 Hermes 的，而是 Hermes 工具栈里缺失的"批量生成、多模型评测、可追溯审计"拼图——它和你现有体系（Hermes 编排 + CC 编码）是互补关系，不是竞争关系。但对 Claude Code 的"批量/评测/审计"类任务构成真实替代压力。

一、DeepSeek Harness 是什么

1.1 基本事实（多源验证）

1.2 架构核心：Everything is a plugin

• 无特权核心：模型适配器、工具注册表、会话日志、agent loop 本身全是插件，均可配置替换
• profile/bundle 分层组合：web / headless 两个内置 profile，dsh --profile web --dump-config 查看插件树
• 四种运行模式：
• Standard：文件编辑、shell、搜索、skills、规划、目标、子代理、工作流
• Code Mode：工具经 Code Mode SDK 暴露，模型可用 TypeScript 程序编排多步工具调用
• Minimal：仅 bash + str_replace_editor 两工具，供评测
• Creator：运行时检视、内存中测试插件、制作自定义预设

1.3 核心特性清单（实测确认 ✅）

1. 全插件架构（Cordis kernel）——实测 dump-config 可见 ~70 个插件
2. 完整可追溯会话日志——append-only 事件流 + Trajectory 视图 + resume/fork/search/replay（实测 session.jsonl.zstd 包含 permission/sandbox/turn/step 全事件 ✅）
3. 工具系统：文件编辑、shell、搜索、LSP、grep/glob、planning、goals、subagents、workflows、todo
4. MCP 支持：官方 dsh-mcp-client，stdio + streamable-http，自动重连
5. 沙箱与权限：sandbox seam + approval 策略，permission-presets（实测 workspace-write 默认）
6. 上下文管理：compaction/spill/context injection，1M token 默认上下文窗口
7. 动态配置：settings.yaml 热更新（下一请求即生效，无需重启）
8. Subagent 系统：支持 6 种后端（in-process/fork/acp/codex/claude-code/dsh-sdk）——实测 in-process 委派成功 ✅
9. Workflow 编排：model-written orchestration script 启动 subagents（worker_threads 引擎）
10. Session-local Schedule：durable reminders（after/at/every ≥5min）
11. Goals：same-session 目标管理（active/paused/blocked/complete）
12. Skills：本地文件系统 skills 注册表（与 Hermes skills 概念同构）

二、与 Claude Code / Codex 的差异（实测 + 社区验证）

2.1 能力对比矩阵

2.2 dsh 相对优势（社区 + 实测）

• 完整可追溯日志：对比 OpenAI/Anthropic 加密隐藏 agent 日志，dsh 全留痕——审计/合规/评测场景刚需
• 插件热插拔：无需重启进程，会话中热卸载
• 多提供商开箱即用：契合"把昂贵模型工作卸载给 DeepSeek"的用例
• 1M 上下文：批量载入全量话术/知识库/历史记录做生成约束
• 严格工具校验：fail-loud，不静默降级

2.3 已知批评（对抗性验证）

• 臃肿：下载 47MB / 构建后 1.5GB（35 个依赖占 1.4GB）
• 生态风险："只靠社区插件、无电池内置"的治理担忧；发布仅 1 天
• 开发预览：破坏性变更未冻结，不适合立即上生产关键链路
• harness 用量与 API 直连价差：经 harness 的 token 消耗可能大于直连

三、模型适配性（全部实测 ✅）

3.1 DeepSeek V4 Pro（原生适配器 dsh-llm-deepseek）

• 实测：✅ 完整跑通（单文件编码 + 多文件项目 + subagent 委派，全部成功）
• 默认 1,000,000 token 上下文、256,000 max output
• thinking 模式 + reasoningEffort（off/high/max）
• 官方 V4-Pro-0813：Terminal-Bench 2.1 社区成绩 87.9（超 Opus 4.8 的 85.0，距 Fable 5 的 88.0 差 0.1）——此为社区第三方数据，非官方
• V4-Pro GA 新增：原生 OpenAI Responses API 支持、为 Codex 优化的一键接入

3.2 Kimi K3（实测 ✅）

• 适配路径：llm-pi-ai 自定义 provider + openai-completions 协议
• baseURL: https://api.kimi.com/coding/v1，模型 id kimi-k3
• 实测：✅ 适配成功（"适配成功"回复验证）

3.3 GLM5.2（实测 ✅）

• 适配路径：llm-pi-ai 自定义 provider + openai-completions 协议（⚠️ 注意：zai coding API 实测是 OpenAI 兼容协议，不是 Anthropic）
• baseURL: https://open.bigmodel.cn/api/coding/paas/v4，模型 id glm-5.2
• 实测：✅ 适配成功

3.4 适配配置模板（实测可用）

llm-pi-ai:
  providers:
    zai:
      apiKeyEnv: GLM_API_KEY
      api: openai-completions
      baseURL: https://open.bigmodel.cn/api/coding/paas/v4
      models:
        - id: glm-5.2
    kimi:
      apiKeyEnv: KIMI_CODING_API_KEY
      api: openai-completions
      baseURL: https://api.kimi.com/coding/v1
      models:
        - id: kimi-k3

DeepSeek Harness 调研报告 — 内容 Part 2（战略分析）

四、现有项目适用性评估（哪些用它优于 CC/Hermes）

4.1 总览评分表

4.2 为什么对话树是 5/5（第一性原理拆解）

对话树生成任务的本质 = "一次性、可脚本化、需要留痕、多模型"四象限任务： 1. 批量生成：D1-D7 七层逾期分级 × 多参数（逾期天数/金额/情绪/历史交互）→ headless 循环调用，prompt 模板 × 参数批量产出结构化 JSON/YAML 2. 全路径验证：对话树 = 状态机，生成后用脚本 DFS/BFS 穷举所有分支验证（无死胡同/无缺失意图/无循环/合规兜底全覆盖）——dsh 负责生成，脚本负责穷举，黄金分工 3. 1M 上下文：一次性载入全部存量话术 + 合规红线（消保法/禁用语）+ 历史质检报告作为生成约束 4. 可追溯留痕：催收强监管，每一版话术"哪个模型、哪次 prompt、哪条输入"全链路可回放——合规审计直接可用 5. 人工闸门：Web UI 让法务/运营可视化审校分支树，边看边改 prompt 重跑

4.3 为什么评测是 5/5

• 原生多模型：一个工具同时跑 V4 Pro/Flash/Kimi K3/GLM5.2 —— 同一评测集多模型对比的标准姿势
• 可复现：完整会话日志保证每次评测的 prompt/上下文/模型/参数全部留痕，结果可回溯、可仲裁
• 现有 wechat-qa-bot 评测体系可直接把 dsh 当 runner：headless 批量喂评测集 → stdout 出答案 → 解析指标 CSV → 对比表

4.4 四类重点任务专项结论

甜区 = 一次性、可脚本化、需要留痕、多模型。四类全命中。

五、能否代替 Hermes？（对抗性验证结论）

5.1 能力矩阵：dsh vs Hermes

5.2 结论：不能代替，但可以深度组合

dsh 无法代替 Hermes 的硬性原因：无消息平台、无全局调度、无持久记忆——这三个是 Hermes 作为"个人 AI 工作站中枢"的基石。dsh 是"执行型 agent"，Hermes 是"中枢型 agent"。

但 dsh 能补 Hermes 的三块短板： 1. 多模型原生评测：Hermes 评测要手动换 provider，dsh 一个工具内原生切换 2. 完整可追溯日志：Hermes session 是文本记录，dsh 是事件级留痕 3. headless 批量执行：Hermes 跑批要写脚本调 API，dsh 天然 headless

5.3 Hermes 如何吸收 dsh 特性增强自己（6 条具体路径）

1. subagent 委派链：Hermes → dsh → (CC/Codex/Kimi/GLM/V4Pro) —— dsh 的 subagent 系统支持 codex/claude-code 后端，Hermes 可以把"批量生成+多模型对比"任务整体委派给 dsh，dsh 内部再自动调度子代理，Hermes 只做编排和结果验证
2. 1M 上下文注入：Hermes 的"全量话术+合规红线"类任务，让 dsh 一次性载入，避免 Hermes 上下文碎片化
3. 可追溯评测：Hermes cron 触发 dsh headless 跑评测集 → 日志留痕 → Hermes 解析结果入看板
4. workflow 自组织：dsh 的 model-written workflow 脚本可编排多个子代理并行——Hermes 的 delegate_task 是静态的，dsh 的 workflow 是模型动态写的
5. skills 互操作：dsh skills 与 Hermes skills 概念同构，可共享技能库
6. schedule 补充：dsh session-local schedule 可作为 Hermes 全局 cron 的会话内补充（短时提醒类）

六、能否围绕它构建"信息/工具自组织自进化"应用？（第一性原理分析）

6.1 自进化体系的本质拆解

一个自进化体系需要 4 个支柱： 1. 持久记忆（跨会话累积）→ dsh ❌ 无记忆层，Hermes ✅ 有 2. 调度闭环（定期触发）→ dsh ⚠️ 仅 session-local，Hermes ✅ 全局 cron 3. 执行引擎（能做事）→ dsh ✅ 强（headless + 多模型 + workflow） 4. 反馈回路（结果回流改进）→ dsh ⚠️ 有 session 日志可回放，但无"结果→改进"自动闭环

结论：dsh 单独无法撑起自进化体系（缺 1/2/4），但它是理想的"执行引擎"层。

6.2 推荐架构：Hermes 中枢 + dsh 执行引擎（自进化增强版）

三层分工：Hermes 管"知道什么"（记忆）+ "何时做"（调度）+ "如何触达"（消息）；dsh 管"批量做"（生成/评测/审计）+ "留痕"（日志）；CC 管"精工做"（复杂代码实现）。

6.3 结论：可以围绕"这套组合"构建自进化，不是围绕 dsh 单点

用户问"是否可以围绕他来构建一套可以驱动信息、工具自组织自进化的应用"——答案是： - 围绕 dsh 单点：不能（缺记忆/调度/反馈闭环） - 围绕 Hermes+dsh+CC 组合：能，且比现在更强（dsh 补上批量生成和多模型评测的执行力）

具体落地：Hermes 自进化体系的"情报采集→记忆治理→进化页生成"批跑中，把"批量分析/多模型对比/审计留痕"环节替换为 dsh headless 执行，日志作为进化证据入库。

七、建议落地路线（剃刀原理：先做收益最大的一步）

1. 本周（9/1 试点前）：项目①用 dsh headless + V4 Pro 批量生成 D1-D7 话术骨架 → 自研全路径验证脚本 → Web UI 人工审校 → 产出合规留痕日志。这是收益最大、最紧迫的切入点
2. 次周：项目②接入 dsh 做多模型评测 runner，与现有评测体系并行跑一轮对比验证指标一致性
3. 后续：项目③④把 dsh 挂到 Hermes cron 下作执行器
4. 治理红线：dsh 只在"一次性任务"形态使用，所有常驻/调度/记忆诉求留在 Hermes 侧；不用 dsh 替换 CC 做日常精工编码（成熟度风险）；生产关键链路等 dsh 正式版（当前 developer preview 会有破坏性变更）

八、风险与对抗性验证

九、实测记录（对抗性验证：每项实测都独立核验）