先确认父子请求是不是同一条路由
如果 DeepSeek Harness 的父会话使用公司网关，冷恢复后子 Agent 却出现在 DeepSeek 官方账单里，先不要把它当成 API Key 泄露。公开复现显示，父 Agent 的实际请求路由来自会话持久化的 request/header，但子 Agent 仍从创建时的 parent.options 继承 provider 和 model。
这会造成两个结果：子 Agent 静默切到部署默认模型，并把 token 费用记到错误的 provider；另一个复现还显示，子 Agent 首次请求可能丢失 reasoningEffort，始终思考的模型因此返回 400。
从日志中找出路由漂移
不要打印 API Key。只保留 provider、model、reasoning effort、session ID 的脱敏值，并对照三类事件：
- 父会话的
request/header - 子会话的
subagent/descriptor - 子会话第一次
request/header
如果父请求一直是 custom-provider/custom-model，而子会话出现 deepseek-official/deepseek-v4-pro，就已经证明发生了路由分叉。公开事故中，61 个子/孙会话合计约 770 万 token 都走了错误 provider。
用无余额测试账号做最小复现
先在隔离配置目录中设置一个没有余额或额度极低的测试 provider，再让 Harness 完成一次冷恢复和一次子 Agent 派生。只执行 echo、读取固定文本和返回模型名，不运行真实项目命令。
记录父子请求的配置摘要：
parent request: provider=custom-test, model=test-model, effort=medium
child request: provider=deepseek-official, model=deepseek-v4-pro, effort=<missing>成功标准是父子请求的 provider、model、effort 完全一致，且测试 provider 的请求数与子会话数量相等。不要只看界面上的当前模型选择器。
effort 丢失时先让子 Agent 失败得可见
如果网关要求 low、high 或 max，而子请求没有 reasoningEffort，不要让 Harness 自动重试十次。先把子 Agent 并发降到 1，开启请求头和错误码记录，并确认 400 是否只发生在子会话首请求。
当你需要临时止损时，可以先关闭子 Agent 派生，或把默认模型切到允许不带 effort 的测试模型。不要把 provider Key 写进项目文件来绕过 readiness 检查。
账单和修复后的验收
修复或升级后，再做一次相同的父子任务：
- 对比父子
request/header的 provider、model 和 effort。 - 在两个 provider 后台分别核对请求数量和 token。
- 检查冷恢复前后，子会话是否仍继承会话实际路由。
- 确认始终思考模型的首请求不会再返回 400。
只有日志、账单和子任务行为三者一致，才能认为路由漂移已经消失。DeepSeek V4 价格变化带来的成本计算，继续参考站内的峰谷计费文章。