Codex 委派增强 ckanner/dsh-subagent-codex-pro

dsh-subagent-codex-pro

一个 Codex 委派工具，每次调用都能带上模型和推理强度 —— 这两样东西 @deepseek-ai/dsh-subagent-codex 表达不了。

tools.subagent_codex({
description: "Probe output PROBE_OK",
prompt: "Output exactly one line of text: PROBE_OK",
model: "gpt-6-astra",
reasoning_effort: "xhigh",
})

它补上了哪个缺口

subagent_codex 的 schema 只暴露 description 和 prompt，所以调用方没法指定模型，也没法指定思考等级。在一次录制的会话里，模型被要求做这件事，试了最直接的做法，结果被拒：

ToolCallError: child model selection is disabled for this tool instance

从 harness 源码看，这条链路是：

tool schema exposes model / reasoning_effort
← only when modelSelectionEnabled
modelSelectionEnabled ← modelSelectionSettings: true on the tool row
modelSelectionSettings: true ← requires a provider declaring agentOptions
@deepseek-ai/dsh-subagent-codex ← declares NO_START_CAPABILITIES (no agentOptions)
→ enabling it throws while the preset mounts

Codex 协议两个字段都支持（ThreadStartParams.reasoningEffort、TurnStartParams.effort），官方服务商却从不发送它们。已向上游反馈：<https://github.com/deepseek-ai/deepseek-harness/discussions/9115>

还有第二个独立的缺陷：在服务商为外部（codex-pro）的行上开启 modelSelectionSettings: true，会让这一行悄无声息地一个工具都不注册 —— 没有报错，没有日志，也没有 preset 失败标记。另一行控制组除了这个标志外完全相同，却能正常注册。这一点也写在那份报告里。

那它是怎么做的

两层，都在本包的控制之下。

执行：说官方服务商说的那套协议

src/wire.ts 和 src/run.ts 是官方 app-server 适配器的移植 —— initialize 握手、临时线程、thread/turn 关联（包括在 turn/start 返回之前就到达的通知）、无人值守的审批决策，以及按阶段挑选最终答案 —— 只加了两处：

// thread/start
{ cwd, ephemeral: true, ...(model ? { model } : {}), reasoningEffort, ...THREAD_PERMISSION_PARAMS[mode] }
// turn/start
{ threadId, input: [...], effort }

这两个字面量在官方适配器那 871 行里一处都没有。与源码相比有两处机械差异：JSON-RPC 传输用的是本包自己的实现（src/jsonrpc.ts），app-server 从 PATH 以 <command> app-server --stdio 启动，而不是从 @openai/codex 的 manifest 启动。src/codex-exec.ts 是更早的 codex exec 路径，保留着也有测试，但没在用。

工具注册：用插件自己的上下文

插件自己注册委派工具，在 agent/created 时注册进那个 Agent 自己的上下文 —— 也就是 dsh-plugin-lcu 给它的工具用的那条路径：

ctx.on('agent/created', ({ agent }) => { if (!presetAllows(agent)) return; serve(agent) })js
ctx.on('agent-preset/selected', (sessionId, preset) => { … })
// serve(): agent.ctx.tools.register(createCodexTool({ … }))

这样就把 harness 的 preset-row 机制完全绕开了。preset 不需要自己的 row：presets 列出的是获得该工具的已提交 Agent preset——这里是 daily 和 heavy。

由于工具名固定，官方 tool-subagent-codex row 在这些 preset 中是禁用的。两个 row 在同一个 Agent 作用域内注册相同的工具名会冲突：第二次注册抛错，其工具会静默地永不出现。

提示词里写什么，就跑什么。 model 和 reasoning_effort 在 schema 中，调用里显式指定就生效；当委派两者都不指定时，选择权留给 Codex 自己的配置（~/.codex/config.toml）——插件配置时不设默认值，这样不会有任何东西静默覆盖任一方。modelSelection: false 会完全隐藏这两个字段。

Host 的 subagent-model-selection 设置被刻意不参考。它授权的是从 DSH 目录中选出的子 LLM 路由，按 token 计费；而 Codex 委派指定的是 Codex CLI 自己订阅下的 Codex 模型 id：资源不同，命名空间不同。该设置既不能授权也不能约束这个选择，读取它只会把工具耦合到一个与它无关的设置上。

安装 sh

as a bundle in a DSH profile

dsh plugin --profile desktop add dsh-subagent-codex-pro

or from a checkout, for development

dsh plugin --profile desktop add link:/path/to/dsh-subagent-codex-pro

验证 sh
npm install
npm run typecheck
npm test # argv + tool-schema cases; live case skipped
CODEX_SUBAGENT_LIVE=1 npm test # also runs gpt-6-astra + xhigh for real

插件把每个决策都记录到 ~/.dsh/codex-pro.log：

apply: provider "codex-pro" registered with agentOptions: true; presets=["daily","heavy"]
decide … composed=standard header=standard -> skip serve …: subagent_codex registered (modelSelection=true, background=true, via=app-server) run: model=gpt-6-astra effort=xhigh cwd=… prompt=179B via=app-server run: published 3f2a…
run done: text=8B

一次验证过的端到端运行：30 秒墙钟时间，模型的 PROBE_OK 作为工具结果返回。真实的 app-server 运行也由 live 测试覆盖，它会用 reasoningEffort 打开一个临时 thread，并用 effort 跑一个 turn。

后台运行与进度

一次委派要花一分钟甚至更久，所以只要 jobs 服务（@deepseek-ai/dsh-jobs）已加载，run_in_background 就存在。它返回一个 job id： js
tools.subagent_codex({ description: "…", prompt: "…", run_in_background: true })
// → { kind: "background", jobId: "subagent-3" } collect with job_output

子进程自己的活动会实时追加到 job 的输出环形缓冲区——完成的命令和文件变更，加上 Codex 的 commentary 消息——所以 job_output 展示长时间委派任务的进展，而不只是它最后说了什么。

能力

| | 状态 |
| 每次调用可指定 model / reasoning_effort | ✅ |
| 返回最终消息 | ✅ |
| run_in_background + 通过 job_output 查看进度 | ✅ |
| app-server 协议（握手、临时线程、审批决策） | ✅ |
| 交互式审批 | 设计上就没有——委派运行无人值守，官方服务商也是如此 |
| 可继续 / 线程复用 | ❌ 一次性，官方服务商也是如此 |
| 深度限制、persona、outputSchema、toolFilter | ❌ 未实现 |

在协议保真度重要的场景，官方服务商仍是更好的选择——

这个插件之所以存在，是因为官方服务商无法表达上面这两个选择；等上游支持后，它就该退役了。