4 类任务该不该上DeepSeek Harness：选型矩阵与决策函数

4 类任务该不该上 dsh：选型矩阵与决策函数

不是所有得任务都适合用 npx @deepseek-ai/dsh web。dsh（DeepSeek Harness）把 DeepSeek 模型包成可观测、可回放、带信任边界的命令行 agent，它的机制决定了有些场景吃得开、有些场景该绕开。这篇把常见任务分成 4 类，按机制逐一判定值不值得上，最后给一段决策函数和一张矩阵，照抄就能用。判定只看机制，不靠个例数据，结论可以自己回源码核对。

为什么是这 4 类

按任务对 agent 的需求特征分，不按行业分，收敛到 4 类。需求特征决定哪条 dsh 机制能用上、哪条会卡住。4 类是：编码辅助、资料研究、运维排障、全自动生产变更。覆盖了评论区被问最多的 4 种「我这种场景能上吗」。

判定维度有三条，全部来自前几篇拆过的机制：

上下文是否稳定，决定缓存能否复用。
是否需要可回放轨迹，决定 Trajectory 的价值。
副作用是否触及生产，决定信任边界是否拦得住。

三条机制速记：append-only 真源（Session 日志只追加不修改）保证可回放、可重放；DeepSeek 端 KV cache 在前缀稳定时复用，省的是输入 token；fail-closed 信任边界让 AI 犯傻时系统默认拒绝。下面 4 类任务，就看哪条机制对得上、哪条会卡住。

下面逐类判定。

1 编码辅助：值得上

这是 dsh 的甜区。多轮迭代里，上下文是代码库本身，相对稳定；每轮追加的内容是 append-only，前缀可复用，DeepSeek 适配器把 prompt_cache_hit_tokens 计入 cacheReadTokens。也就是说，多轮编码不会每轮把整个代码库重读一遍，缓存命中省的是真金白银。

append-only 在这里的含义要补一句：每轮新内容追加在历史尾部，不改动前缀，于是 DeepSeek 端的 KV cache 能从上次中断处续上。一次 surface 替换或 compaction 会从被遮蔽的 token 起失效重用，所以编码场景要尽量让上下文自然增长，少做替换。

可回放是第二个加分项。Session 是 append-only 的真源，LLM 消息历史从它派生。你回头想看它当时为什么这么改，能回放整条轨迹；出 bug 时这是调试利器。配合 session-log-export 还能整段导出存档。

结论：高推荐。机制天然对路，缓存命中和可回放两个红利都吃得到。

也有掉档的时候：一次性问个 API 用法，不需要多轮，dsh 是杀鸡用牛刀；或者代码库每轮都被大改、前缀稳不住，缓存命中也吃不到。这两种情况自己降一档，裸 API 更直接。

2 资料研究：值得上

资料研究是多轮检索：搜文档、读文件、汇总。每轮上下文会变（新发现追加），缓存命中率不如编码辅助稳定，但 Trajectory 的价值更高。多轮检索最怕它到底查了什么、查漏了什么，append-only 真源让你能逐条回放，配合 checkpoint 落盘，查证链路完整。

可回放具体能看什么：每一步发了什么请求、调了哪个工具、工具返回了什么，全部来自 append-only 真源。研究场景里你怀疑它漏查了某个来源，直接拉轨迹核对，不用重跑一遍。这是聊天框给不了的。

结论：高推荐，但理由和编码不同。编码吃缓存，研究吃回放。如果你的研究场景经常要复盘为什么得出这个结论，dsh 比裸聊天框强很多。也有不适合的：一次性查个定义、或者结果不可追溯也没关系，裸聊天框更快。多轮、要复盘、要查证链路，才轮到 dsh 上场。

3 运维排障：评估后上

运维要 dsh 去读生产日志、跑诊断命令。读的部分能上：read-only 是 fail-safe 默认，沙箱三档里的最严档，confine 失败即拒绝 spawn。读生产日志、查配置文件这一类，机制上撑得住。

卡点在写。运维往往要重启服务、改配置、跑修复脚本，这些都是写操作。read-only 模式下写被禁；要放宽到 workspace-write 得显式 opt-in，要 danger-full-access 得过 approval。没配 approval channel 就是 unavailable，等于 deny（docs/subsystems/approval.md:21）。还有一层要注意：read-only 只拦写不拦读，运维里读 ~/.ssh、读 env secrets 不会被沙箱拦，防泄露得靠 approval 接缝和最小凭证，不是沙箱模式。

结论：中推荐。只读排障能上，写操作得先配好 approval 和沙箱边界再上。

4 全自动生产变更：先别上

这是评论区呼声最高也最危险的一类：让 dsh 自动跑 migration、kubectl apply、改生产库。机制上它直接撞三道闸：

需要 danger-full-access，不是默认档。
升级要过 approveEscalation 的有序 fail-closed 序列，没 approval channel 直接抛错。
强副作用要在 checkpoint 落盘，崩溃恢复也只能靠 exec.callId 当幂等键，不保证 exactly-once。

也就是说，机制本身就在拦你。三道闸是叠加的，不是任选其一：先要 mode 升到 danger-full-access，再要 approval channel 解出 allowed-once，再要 checkpoint 落盘意图，任何一道缺失或失败都 fail-closed。即便全过，danger-full-access + AI 自主决策 + 生产库这个组合，失败域大到不值得赌。

结论：低推荐，先别上。要上也是分步走：先在只读预检副本上跑、配齐 approval channel、用最小凭证、人在回路里盯着每一步。任何一步偷懒，机制会拦你，拦不住的部分靠人盯。这不是 dsh 不行，是这类任务本身失败域太大，换谁来都一样。

5 选型矩阵

把上面收成一张表。

任务类型	推荐度	机制依据	上之前要配什么
编码辅助	高	缓存命中+ Trajectory 回放	默认 `read-only` 即可
资料研究	高	Trajectory 回放+ checkpoint 落盘	默认 `read-only` 即可
运维排障	中	read-only 可读生产，写需 approval	approval channel + 沙箱边界
全自动生产变更	低	danger-full-access 需 approval，未配即 deny	全套：approval + 副本 + 人在回路

注意：推荐度是机制推论，不是一刀切的判决。具体场景里「读 secrets 会不会泄」这类问题，沙箱管不住读（read-only 只拦写），要靠 approval 接缝，不是沙箱模式。

用这张表的方法：先定位你的任务在哪一行，再看机制依据那一栏对不对得上你的部署，最后看「上之前要配什么」。配置没配齐，推荐度降一档。

6 决策函数

把上面的判定写成一段伪代码，你的任务套进去就能得出推荐度。

ts 复制代码

// choose_agent.ts: 任务选型决策函数（机制推论，非个例）
type TaskKind = 'coding' | 'research' | 'ops' | 'auto-prod-change'
type Recommendation = 'high' | 'medium' | 'low'

interface TaskProfile {
  kind: TaskKind
  touchesProduction: boolean   // 是否触及生产副作用
  hasApprovalChannel: boolean // 是否配了 approval
  readOnlyAcceptable: boolean // 只读能不能完成任务
}

function recommend(p: TaskProfile): Recommendation {
  // 全自动生产变更 + 触及生产 + 没人在回路：机制本身拦，低
  if (p.kind === 'auto-prod-change' && p.touchesProduction && !p.hasApprovalChannel) {
    return 'low'
  }
  // 触及生产写操作但没配 approval：中（先配再上）
  if (p.touchesProduction && !p.hasApprovalChannel) {
    return 'medium'
  }
  // 编码、研究：机制对路，高
  if (p.kind === 'coding' || p.kind === 'research') {
    return 'high'
  }
  // 运维只读：高；运维要写：中
  return p.readOnlyAcceptable ? 'high' : 'medium'
}

low 不等于永远别上，等于机制在拦你，先配齐再说。medium 等于机制允许，但缺一个前置条件。high 等于默认配置就能跑。

举个例子：任务是「让 dsh 读生产日志找 OOM 原因」。这是 ops 类，只读不写，touchesProduction=false、readOnlyAcceptable=true，套函数落到最后一行返回 high。如果同一任务要 dsh 顺手重启服务，touchesProduction=true、没配 approval，第二条返回 medium，等于「先配 approval 再上」。touchesProduction 只对写副作用置真，纯读置假，这是函数里最容易踩的边界。

函数有个诚实的局限：它只判机制，不判你的模型有多强、你的 approval 配得对不对。同一段任务，模型能干和不能干，推荐度可能差一档；approval 配了但没配最小凭证，medium 也不安全。函数给的是起点，不是终点。

收尾

4 类任务里，编码和研究是 dsh 的甜区，运维要配 approval 才吃得开，全自动生产变更机制本身就在拦你。你的主场景是哪一类？卡在哪一道闸？评论区说一说。