前言¶
在 Harness 里跑 DeepSeek 时，常见做法是让模型在对话里直接改代码或开终端。Codex 一侧要交办明确任务、收结果并独立验收时，往往需要额外编排：谁在哪个目录动文件、端口重启后客户端要不要手改、凭据是否只覆盖登记过的工作区。本插件把 Codex 派单、DeepSeek 在专属工作区执行、结果回到原工单收件箱串成一条链路，并复用 Harness 已有 HTTP 服务，不要求 computer-use。
这是什么¶
dsh-codex-handoff（仓库 lightcoloror/dsh-codex-handoff）由维护者 lightcoloror 发布，在 SkillHub 目录中归类为模型推理。定位是：Codex 派单，DeepSeek 在明确登记的专属工作区执行，结果回到原工单收件箱，由 Codex 独立验收。
插件随 Harness profile 加载，不新建常驻服务；每次加载会发布实际端口及实例信息。Windows 客户端在发送受限令牌前，会核对已建立 TCP 连接的操作系统归属、Harness 可执行文件和进程代次，端口变化时不必再手改客户端地址。
核心功能¶
下面能力均来自项目 README 与包说明，未列入的部分不作推断。
- 工作区 Scoped 协作：DeepSeek 只在 Harness 中登记并授权的路径内操作；宿主 state、令牌目录与兄弟项目不属于模型工作区。
- 桥接与配对：一次性配对生成仅覆盖指定 workspace、不能创建 workspace 的桥接凭据，并将客户端复制到宿主目录；不启动模型、不创建聊天、不修改沙箱。
- 重启安全的端点发现：以
.state/endpoint.json为准；启用发现后不再需要DSH_CODEX_BRIDGE_URL；Harness 未监听时客户端报告未就绪，不猜端口、不扫端口。 - Windows 连接身份检查：在每个新连接上核对 OS 归属；响应丢失的修改请求标记
uncertain，保留 job/session/request ID，先对账、不自动重投。 - 工单与验收流程：支持
doctor、prepare、run-foreground等 CLI；独立验收可走inbox、核对身份后的ack、stage-review/stage-next或feedback，最后close。参考包内task.example.json与skills/deepseek-handoff/SKILL.md。 - 权限细分：终端、代码修改、设备操作分别授权；需要跑测试的工单需明确
requires_shell:true及命令、cwd、输入输出范围。
本插件不提供、不读取 DeepSeek API Key，也不改请求门控；DeepSeek API 与峰谷门控由使用者自己的 Harness 管理。默认 enableInboxWakeups:false。显式选模受 Harness 上游行为约束（README 中说明 routing:"inherit" 及 SessionController.selectModel 的已知限制，v0.1.0 起已在 Release 说明中列出）。
协议与来源：vendor/collab（ESROAMER/codex-dsh-collab）、vendor/dax（Dax233/dsh-codex-bridge），固定提交见 vendor-manifest.json，均为 MIT。同类对比见仓库内 COMPARISON.zh.md。
当前包版本 0.1.1（MIT）。GitHub 星标为 0（以目录页信息为准）。
安装与启用¶
环境要求：
- DeepSeek Harness
0.2.1-rc.5或兼容的0.2.x - Node 22+
- Python 3.11+
Windows 是当前自动发现与连接身份检查的验证平台；其他平台尚未实现同等检查。包含可直接运行的源码，无单独安装脚本或构建步骤。
在 Plugins 添加插件入口粘贴仓库链接，或使用 CLI（desktop 可换成你实际使用的 profile；装到未使用的 profile 不会让当前应用加载插件）：
dsh plugin --profile desktop add github:lightcoloror/dsh-codex-handoff#v0.1.1
也可在 Harness 的 Custom plugin indexes / 自定义插件索引 中添加本项目维护的索引源 https://raw.githubusercontent.com/lightcoloror/dsh-codex-handoff/main/market-index.json，再从 Discover 安装。该索引由本项目维护，不代表第三方公共市场收录。
安装后插件与 Harness 同生命周期；更新若改变模块路径或客户端源码，需审阅后重新配对并保留旧状态。
典型用法¶
首次配置¶
- 在 Harness 中登记 DeepSeek 的专属 workspace。
- 在本插件设置中，将
workspacePaths设为该目录的完整路径，将dataDir设为不同的宿主目录（例如共同父目录下的C:/AgentWork/bridge与C:/AgentWork/deepseek）。workspacePaths初始为空时，授权范围也为空。 - 运行一次配对。
--home须与dataDir一致，--harness-executable为正在运行的 Harness 程序完整路径：
dsh plugin --profile desktop exec dsh-codex-handoff-setup --home C:/AgentWork/bridge --workspace C:/AgentWork/deepseek --harness-executable 'C:/Apps/DeepSeek Harness/DeepSeek Harness.exe'
也可在插件源码目录执行 python -B setup.py 并使用相同参数。配对会核实当前连接与已配置工作区；既有不一致的配对及代码会保留并报错，不静默覆盖。
- 使用配对命令打印的 CLI 路径，例如：
python -X utf8 -B C:/AgentWork/bridge/cli.py doctor --service
python -X utf8 -B C:/AgentWork/bridge/cli.py prepare --request C:/AgentWork/task.json
python -X utf8 -B C:/AgentWork/bridge/cli.py run-foreground JOB_ID --authorization-ref C:/AgentWork/assignment.md --timeout-seconds 900
CODEX_THREAD_ID 应来自真实来源聊天；assignment.md 记录真实用户交办，仅作证据。相关串行步骤可在同一工单的 stages 中复用会话。
重启与多实例¶
- 旧端口字段仅作配置兼容；启用发现后以
.state/endpoint.json为准。 - 多实例请使用不同
dataDir和路由前缀；同一宿主目录被另一存活进程占用时拒绝接管。 - 本地身份检查信任宿主状态目录和指定 Harness 程序，不能抵御同账号下已能修改这些文件的恶意程序；桥接令牌不是 DeepSeek API Key。
项目自述验证范围包括：发布不同实际端口、Windows 真实连接归属、错误进程/工作区拒绝、实例变化、丢失提交响应不重发等；尚未执行整机重启验收，也未为发布启动额外付费模型任务。
适用场景与注意¶
适合谁：需要在 Codex 与 DeepSeek Harness 之间做工作区级派单与回传、又希望端口与进程身份在 Windows 上可核对、且不想引入 computer-use 或 GUI 自动化的开发者。
安装前建议：插件在当前 dsh 进程权限下运行；安装前应阅读仓库源码与 MIT 许可证（LICENSE、NOTICE）。工作区约束与原生审批仍由 Harness 实际运行策略决定。不要删除旧工单或换 ID 绕过冲突；不得为单工单追踪擅自搭建自动化。
DSH 生态理念是「一切皆插件」；SkillHub 目录页为社区站点，与 DeepSeek / 幻方无官方从属关系，不宜当作官方应用商店。
结尾¶
经过上面的步骤，你可以在登记好的 workspace 内让 DeepSeek 执行 Codex 工单，并通过桥接 CLI 与收件箱完成验收；端点随 Harness 发布，Windows 上可核对连接归属。细节以仓库 README 为准。
- 目录页：https://www.skillhub.cn/plugins/lightcoloror/dsh-codex-handoff
- GitHub：https://github.com/lightcoloror/dsh-codex-handoff
