前言¶
在 DeepSeek Harness（DSH）里，让对话模型既拆任务又直接改仓库，常见问题是：改动范围容易漂、完成与否往往只靠模型自述。另一条路是把「写代码」交给专用 CLI，对话侧只做规划和核验——但若缺少验收标准、结构化汇报和任务台账，交接仍难复现。
下面介绍的 dsh-codex-conductor（维护者 xiaobaifly7）走后者：DSH 中的 agent 负责规划与只读核验；具体编码由 WSL 内的 Codex CLI 在后台执行。插件要求带验收标准派单，按条汇报结果，并通过工作区护栏把规划端的写操作挡在门外。当前版本 0.9.43（MIT 许可），归类为 工作流 插件；GitHub 星标为 0。插件在 SkillHub 目录 可检索——该站点是社区插件目录，与 DeepSeek / 幻方无官方从属关系。
这是什么¶
dsh-codex-conductor 是面向 Windows + WSL2 的 DSH 插件：Harness 通过 wsl.exe 调用随包 Python runner（runner/codex_runner.py），在 WSL 里启动 Codex。规划端用 codex_* 工具派活、查状态、续接阻塞、独立核验；Codex 侧按 report.v2.schema.json 逐条对照验收标准回报。DSH 版本要求 >=0.2.1-rc.2 <0.3.0；WSL 内需已安装并登录 Codex CLI，以及 Python 3.11+（runner 用 tomllib 读取 Codex 配置）。
角色分工与核心能力¶
规划端与执行端¶
README 的分工可以概括为：
- 为每个任务写好验收标准（
acceptance，至少 1 条，每条至少 4 个字符）。 - 用
codex_run派活，尽量给出scope（具体文件或目录，不支持通配符）。 - 不把 Codex 的自报当作完成证据，用只读检查逐条核验。
- 未通过时先用
codex_review记录证据，再用codex_continue在原权限下修正。
派活与台账工具¶
插件默认注册十个 Codex 相关工具（配置 gemini 后额外注册 gemini_write）。与日常流程关系最紧的有：
| 工具 | 作用概要 |
|---|---|
codex_run |
把任务交给 WSL Codex；登记后台任务后返回任务号。必填 task、acceptance、write（改文件传 true，只读调查传 false） |
codex_status / codex_output |
查询进度；分页读取报告、结果 JSON、上下文或日志 |
codex_continue |
回答阻塞或提交环境恢复依据，续接原线程，不重复派活 |
codex_review |
规划端逐条独立核验，结论为 verified / needs_changes / accepted_deviations |
codex_jobs / codex_summary |
分页查历史任务；按线程汇总多轮结果与未闭环事项 |
codex_cancel / codex_watch |
取消 WSL 内 Codex 进程树；安静观察后台任务首次重要变化 |
若 agent preset 提供 DSH 后台任务（jobs）服务，codex_run 启动后会在任务表出现 Codex <job_id> 一行；结束时有摘要通知，完整内容可用 codex_output 或 job_output 读取。任务在 WSL 后台运行，Harness 侧断开等待不影响执行。
工作区护栏（可选）¶
默认不启用护栏，只提供工具。在 cordis.patch.yml 里配置 workspaces 后，对受保护工作区会拒绝 DSH agent 直接写文件、跑任意代码等工具调用，仅放行只读核验类 shell 命令；结构化改写仍应通过 codex_run 交给 Codex。README 还说明：若 agent 声称「已派 Codex」但本轮未调用 codex_* 且无后台监控确认，插件会提醒补调或更正说法。
报告与核验¶
Codex 按验收标准逐条汇报（met / not_met / blocked 等）。阻塞项在 v2 报告中有 blockers 字段（id / kind / message / question / resolution）。规划端用 codex_review 写 reviews.json，不改写 Codex 原始 result.json。结果摘要示例形如：completed · 12 met / 1 blocked · 3 files · 148 s。
Gemini 文档写作（0.9.43，可选）¶
配置 gemini 后注册 gemini_write：适合教程、文档正文，源码改动仍用 codex_run。需要本机已安装并登录 Antigravity CLI（agy.exe）；未配置则不注册该工具。
安装与启用¶
安装前请自行阅读 GitHub 仓库 源码与 MIT 许可证。插件随 DSH 进程加载，以当前 DSH 权限运行；启用 allowHostAccess 与 host_access=true 时 Codex 以 danger-full-access 运行，需审慎评估。
在 DSH「插件 → 添加插件」中填写：
github:xiaobaifly7/dsh-codex-conductor
或用命令行（将 <profile> 换成实际 profile；桌面版建议用应用内插件页安装）：
dsh plugin --profile <profile> add github:xiaobaifly7/dsh-codex-conductor
环境前提（摘自 README「要求」）：
- Windows + WSL2，DSH 运行在 Windows 上。
- WSL 内 Codex CLI 已登录，Python 3.11+ 可用。
- DSH
>=0.2.1-rc.2 <0.3.0。
维护者在 README 中记载的验证环境包括 Windows 11、WSL Ubuntu 24.04、Codex CLI 0.154、DSH 桌面版 0.2.1-rc.2。
配置要点¶
在插件条目中按 id codex-conductor 覆盖 config。最小示例如下（护栏 + 默认推理档位）：
- id: codex-conductor
config:
workspaces:
- 'D:\work\my-project'
- path: 'D:\work\monorepo'
cwd: 'D:\work\monorepo\app'
effort: high
readOnlyEffort: medium
serviceTier: fast
常用项包括：distro（WSL 发行版）、codexBin / codexHome、timeoutSeconds（默认 runner 每次尝试 3600 秒）、idleTimeoutSeconds（默认 600）、retries（默认 2）、allowHostAccess（默认 false）、runnerHome、maxStorageMb、plannerPromptFile（规划要求 Markdown，注入 agent 系统提示）、runtimeProfileFile（热重载时指向实际 cordis.patch.yml 的 Windows 完整路径）。
启用 Gemini 时可在同一 id 下增加：
gemini:
command: 'C:\Users\apple\AppData\Local\agy\bin\agy.exe'
proxy: 'http://127.0.0.1:7890'
model: gemini-4-argon
effort: medium
timeoutSeconds: 600
command 必须是 agy 的绝对 Windows 路径；素材与提示会发往 Google，需自行评估合规与网络（无代理时须在配置中显式填写 proxy）。
典型用法¶
派单与续接¶
codex_run 调用时需至少包含自然语言 task、字符串数组 acceptance、布尔 write。可选 cwd、scope、writable_roots（沙箱内额外可写目录）、resume、effort、wait_seconds 等。只读任务（write=false）以 ephemeral 运行，thread_id 通常为 null；写任务会对任务目录加写锁，并发写同一目录时后续任务可能进入 lock_wait 排队。
Codex 阻塞并抛出问题时，应先让用户在会话中作答，再调用续接。README 给出的形式如下：
codex_continue({"job_id":"J1","answers":[{"id":"choice","answer":"采用已确认的方案"}]})
环境恢复时在 resolution 中写实际证据。续接不扩大 scope、不擅自增加写权限。
核验与读结果¶
作业结束后用 codex_output 按 job_id 分页读取（artifact 可选 report、result、context、review、stderr、events）。规划端对照验收标准做只读检查，再调用 codex_review 写入独立结论。需要同步等待时，对同一 job_id 调用 codex_status 并传入正数 wait_seconds。
文档章节（可选）¶
配置 gemini 后，可按 README 示例一章一章生成文档：
gemini_write({"prompt":"根据素材写第一章入门说明，事实不得超出素材。","sources":["notes.md"],"output":"chapter-01.md","cwd":"D:/work/course","max_chars":2500})
插件会读回文件、统计字数，并列出范围外改动；同目录有 Codex 写任务在跑时会拒绝新的 Gemini 或可写派单。
适用场景与注意¶
适合谁： 已在 Windows 上使用 DSH，并希望在 WSL 里用 Codex CLI 做仓库级改动；希望 Harness 侧固定为「拆任务 + 验收」，且能接受验收驱动、结构化 JSON 报告的工作流。
不太适合： 纯 Linux 原生环境（package.json 的 os 为 win32）；没有 WSL / Codex CLI 的团队；期望规划端在受保护工作区内直接改文件而不走 Codex 的场景（需关闭或缩小 workspaces 护栏范围）。
运行中值得留意的行为：
- WSL 桥接超时或
bridge_error时，应先codex_status再决定是否重派，避免重复作业。 - WSL 重启后 runner 可能将旧任务标为
worker_died；可写任务会核对验收与已落盘产物后再决定是否补做。 - 默认不向 Codex 加载
config.toml中的 MCP 与 hooks（除非use_user_config=true）。 - 0.9.42 起，派单前无法连接 WSL 时会说明原因并保留原有写入范围与续接检查。
结尾¶
dsh-codex-conductor 把 DSH 生态里「一切皆插件」的思路落到一条清晰链路上：规划与验收留在 Harness，编码与逐条汇报交给 WSL Codex，并可选用护栏约束规划端权限。若你要在 Windows 上试装，可从目录页与仓库核对版本与配置后再启用。
- 目录页：https://www.skillhub.cn/plugins/xiaobaifly7/dsh-codex-conductor
- GitHub：https://github.com/xiaobaifly7/dsh-codex-conductor
