DeepSeek Harness 开了 Auto review 后工具全被取消：三类评审器配置排查

「切到 Auto review 之后，连 list_agents {} 这种无参数只读调用都被拦了」——当被拒的是根本不含风险的操作时，问题几乎一定不在风险策略，而在评审器自己。 社区在同一台机器上统计了 15 个会话、55 次真实评审故障，其中一次 /permission auto 之后 24 秒内 5 次调用全被拒（#10954）。这篇用一张对照表把三类故障分开，再逐条给处置。

DeepSeek Harness 先分清：三类「看起来像权限、其实是评审器配置」

三类故障的判别只看两样东西：报错里的错误码，以及被拒的调用有没有参数。错误码指向评审请求本身，无参数调用被拒则说明评审环节坏了。

判别顺序建议固定：先看错误码 → 再看会话路由 → 最后看是不是所有工具都挂。

DSH插件 第一类：评审请求没带 sessionId

OpenCode Go 要求每个推理请求都带 x-opencode-session，而评审请求没传 sessionId，provider 就不会补这个头，于是每次评审都在到达模型前被 400 掉。

1. 看报错：auto-review: reviewer ended with error INVALID_REQUEST: 400: {"type":"MissingSessionID", ...}。
2. 确认会话模型走的是 opencode-go 路由（社区案例是 opencode-go/deepseek-v4.1-flash）。
3. 直接验证依赖：向同一端点 POST，不带 x-opencode-session 返回 400，带任意字符串返回 200。
4. 知道链路：pi-ai 的 withOpenCodeSessionHeader() 只在 options.sessionId 存在时注入；classifyRisk() 组装 GenerateOptions 时没有这个字段。
5. 对照其他辅助调用：主循环、压缩（compaction-basic）、会话标题都传了 sessionId，只有 auto-review 漏了。
6. 现状：社区核对到 master 上 classifyRisk 仍未补这一行，所以这不是「升级就好」的问题。
7. 临时方案：把权限预设切到非 Auto（比如 never），或者在该路由配置里钉一个固定的 headers.x-opencode-session，代价是失去按会话路由。

DeepSeek Harness 第二类：硬编码 temperature: 0

评审请求把 temperature: 0 深冻结后直接交给 ctx.llm.stream()，只接受 1 的模型直接回 400，而失败的评审会让每个工具调用在执行前被取消。

1. 看报错：auto-review: reviewer ended with error INVALID_REQUEST: 400: {"message":"invalid temperature: only 1 is allowed for this model", ...}。
2. 确认会话模型属于「只接受 temperature=1」这一类（社区举例是 Kimi Code 的模型）。
3. 理解位置：auto-review/src/index.ts 构造 options 时写死 temperature: 0，序列化层只要字段存在就转发，OpenAI 兼容路由没有能力门控。
4. 装社区插件：dsh plugin --profile <profile> add github:argszero/dsh-auto-review-temperature-guard#v0.1.0。
5. 在 profile 里加挂载项，条目名 @argszero/dsh-auto-review-temperature-guard；不填参数就省略 temperature，让路由默认值生效，填了就发你指定的值。
6. 验证：评审请求不再带 0，工具调用恢复执行；非评审请求必须原样透传，这是插件自带的断言之一。

插件用 system 是否以 REVIEW_POLICY 开头来识别评审请求，普通回合的 system 是 undefined，所以不会误伤对话请求。它的边界也明确：匹配不上就静默失效，属于 fail-open。

DeepSeek插件 第三类：技术失败被当成拒绝

评审器遇到传输错误、超时、配额、输出格式不对时统一返回 kind: 'deny'，而这条路径发生在 await next() 之前，人工审批根本没机会介入。

1. 看文案区分：Auto review rejected tool … 是真实判定，后面会走人工审批；Auto review of tool … failed 是评审器失败，直接终结。
2. 统计口径就用这个前缀，社区验证过它和拒绝文案不会混。
3. 看代码：failed() 注释写着「作为独立错误而不是拒绝」，但返回的 kind 仍是 'deny'，区别只留在 info 里的 AUTO_REVIEW_FAILED_ERROR_NAME。
4. 旁边已有第三条路 askUser()（kind: 'ask'），社区建议把技术失败降级成「需要人确认」，并做成可配置，默认取 ask。
5. 还有两个加重因素：parseDecision 直接 JSON.parse 原文，不剥围栏、不抽取平衡括号、不做一次格式纠正重试；schemas.length !== 1 时直接抛 schema 缺失，MCP 重连引起的工具集漂移就能触发。
6. 临时方案：切到 danger-full-access 或 workspace-write 绕开评审器，或换一条没有格式违规的路由——但这只是缓解，安全层的可靠性不该取决于你选了哪个聊天模型。

DeepSeek Harness 四步确认是「评审器坏了」而不是「风险策略太严」

先做一次对照实验：同一个工具、同一条命令，切掉 Auto 再跑。切掉就能过，说明被拦下的原因在评审环节，不在命令本身。

1. 在会话里执行 /permission，切到 never 或 workspace-write。
2. 重跑刚才被拒的那条命令。能过，记下结论。
3. 切回 auto，再跑一个无参数只读工具，比如列文件或列 agent。
4. 如果无参数调用也被拒，直接判定为评审器故障；只有带写入/网络参数的命令被拒，才可能是真的风险判定。

这四步的价值在于排除法：它不需要读源码，也不需要抓包，一次就能把「策略问题」和「评审器问题」分开。

DSH插件 为什么三类都指向同一个设计问题

评审器复用会话自己的路由，包内没有 reviewer model 的配置项，安全闸的可靠性就被绑死在聊天模型上。

1. 审查请求从最新的 request/header 取 provider 和 model，用户换模型等于换评审器。
2. 于是「换模型就正常」不是巧合，是结构决定的。
3. 社区建议的长期形态是加配置：reviewer provider/model、最大重试次数、单次评审超时。
4. 在那之前，任何一类故障的最快恢复都是先切权限预设，把会话救回来再排查。

注意事项

1. 不要用「所有工具都被拒」来判断模型有风险。无参数只读调用被拒时，先怀疑评审器。
2. 别把 Auto review of tool … failed 当成模型拒绝。两者文案前缀不同，处理方式也不同。
3. 装插件时固定版本号。experimental-auto-review 的 latest 标签曾指向更旧的构建，不锁版本可能复现出别的问题。
4. 插件是缓解不是修复。硬编码的 0 和缺的那一行都还在源码里。
5. 记录错误码与会话路由。这两项是区分三类故障的全部信息，缺一个就只能猜。

如果你的报错里既没有 MissingSessionID 也没有 invalid temperature，那大概率属于第三类，去会话日志里搜 AUTO_REVIEW_FAILED 确认。相关排查见 DeepSeek Harness 切 /permission auto 后工具全 ABORTED 怎么修。