DeepSeek Harness 子代理提供方怎么装？Codex、Claude Code 与 ACP 组合包

DeepSeek Harness 的子代理提供方不是默认全开的：Codex 和 Claude Code 各是一个可选组合包，要用 dsh plugin add 装进去，再重启 Profile，最后在复制出的 Preset 里启用工具行。 少任何一步，表现都不是报错，而是“装完了但 Agent 看不到工具”。这篇把安装、启用、验证和卸载串成一条线。

DeepSeek Harness：Codex、Claude Code 与 ACP 分别是什么

三者都在 subagent 提供方这一层，但安装方式和运行前置不同：Codex 与 Claude Code 有官方可选组合包，ACP 是另一种后端家族。 先分清角色：（来源）

这张表的重点是：“子代理”不是单个插件，而是一层可替换的后端。你装哪个提供方，决定子 Agent 实际在哪里跑、用谁的凭据、受哪套限制。

DeepSeek Harness：安装命令与组合包行为

安装就是两条 dsh plugin add，它们把包写进指定 Profile 的依赖与 dsh.profile.bundles，不会影响别的 Profile。 命令如下：（来源）

# 只装 Codex
dsh plugin --profile web add @deepseek-ai/dsh-subagent-codex

# 只装 Claude Code
dsh plugin --profile web add @deepseek-ai/dsh-subagent-claude-code

# 两个一起装
dsh plugin --profile web add \
  @deepseek-ai/dsh-subagent-codex \
  @deepseek-ai/dsh-subagent-claude-code

执行前后注意三件事：

1. --profile 必须写在最前面 — dsh plugin 只在自己能识别的参数里读 --profile，后面的内容原样转给 pnpm。预期：dsh plugin --profile web add ... 能正确落到 $DSH_HOME/profiles/web。
2. pnpm 必须在 PATH 上 — 插件管理命令本质是把 add、remove、update 转发给 pnpm。预期：pnpm -v 有输出再执行安装。
3. 看 bundles 是否更新 — 只有包在 manifest 里声明了 dsh.bundle，安装后才会进入配置层栈；普通依赖只留在 node_modules。预期：安装输出没有“没有组合包声明”的警告。

如果只是想试一下，建议先装一个。两个都装不会冲突，但排查“到底是哪个后端在跑”会更费劲。

DeepSeek Harness：为什么装完还看不到工具

组合包安装只完成“注册提供方”，不完成“给 Agent 开工具”；后者要在 Preset 里单独做。 官方对这一点的描述很明确：下一次启动时，每个已安装组合包只注册自己的休眠 Host 提供方，还必须到复制出的 Preset 中启用对应工具行，新 Agent 才能看到该工具。（来源）

按下面顺序检查：

1. 确认 Profile 已重启 — 关闭当前 dsh web 进程再启动。预期：启动日志里能看到新组合包被加载。
2. 打开 Preset 配置 — 找到你实际使用的 Agent Preset，确认它是复制出来的可编辑版本，而不是只读内置项。预期：能看到 subagent 相关工具行。
3. 启用对应工具行 — 只启用你装了的那个提供方，不要把未安装的也打开。预期：保存后新建 Agent 时工具列表出现该项。
4. 新建会话验证 — 旧会话可能沿用创建时的工具快照。预期：新会话里让模型列一下可用工具，能看到 Codex 或 Claude Code。

如果第 3 步找不到工具行，先确认装的是不是组合包、Profile 名字有没有写错；如果第 4 步仍看不到，检查是否还在用旧会话或旧 Preset。

DeepSeek Harness：组合包安装后 manifest 变了什么

官方行为是：每次成功的 add / remove / update 之后，系统都会按当前安装状态更新 dsh.profile.bundles。 变化规则：（来源）

• 带 dsh.bundle 声明的依赖 — 安装后自动加入配置层栈。预期：package.json 的 bundles 列表多一项。
• 没有组合包声明的依赖 — 仍作为普通依赖保留，并显示一次性警告。预期：它不会改变配置层。
• 被移除的依赖 — 从配置层栈中删除。预期：重启后不再加载它的 patch。
• 运行中的 Profile — 保留本次启动时的组合包集合。预期：不重启就不会加载新提供方。

manifest 里会直接多出 @deepseek-ai/dsh-subagent-codex 这样的 bundle 项；装完先看 bundles，再去 Preset 开工具行，两步都对，新 Agent 才会看到后端。

DeepSeek Harness：三条接入路径怎么选

官方组合包适合“直接用现成后端”，自定义 provider 适合“接内部 Agent”，进程内派生适合“只要拆任务、不要外部依赖”。 三条路径的取舍：（来源）

1. 官方 Codex / Claude Code 组合包 — 安装最快，适合已经有对应 CLI 或账号的团队。代价：要额外维护后端可执行文件与认证。
2. 自定义 subagent provider — 实现 SubagentProvider 并注册到 ctx.subagents，适合接公司内部 Agent 平台。代价：要自己处理启动、续跑与失败。
3. 进程内派生 / fork — 不依赖外部产品，适合纯拆任务的场景。代价：能力受当前进程限制，隔离性弱于外部后端。

三条路径可以共存。实际项目里常见的是“默认用进程内派生，重活交给 Codex 或 Claude Code”。

DeepSeek Harness：重启、验证与卸载

组合包成员变化始终以重启为边界；卸载也是同样的顺序，先 remove，再重启，最后清理 Preset 行。 卸载命令：（来源）

dsh plugin --profile web remove @deepseek-ai/dsh-subagent-codex
dsh plugin --profile web remove @deepseek-ai/dsh-subagent-claude-code

1. 先 remove 包 — 一次只卸一个，确认另一个还能正常工作。预期：manifest 的 bundles 列表里对应项消失。
2. 重启 Profile — 让运行中的进程丢掉旧组合包集合。预期：启动不再加载被移除的提供方。
3. 撤掉 Preset 工具行 — 避免留下指向不存在后端的入口。预期：新 Agent 的工具列表不再出现该项。
4. 检查残留 — 看 dsh plugin --profile web list 与 Profile 目录。预期：没有残留依赖，也没有孤立的 patch 行。

需要找替代的子代理类插件时，可以在「设置 → 插件市场」里的 DSH Plugin Hub 按分类浏览；但官方 Codex / Claude Code 组合包仍建议走 dsh plugin add，因为它们的版本要与当前 DSH 对齐。

DeepSeek Harness 常见问题

Q：装了两个提供方，Agent 会自己选吗？ 不会自动选。Preset 里启用哪些工具、提示词里怎么要求委派，才决定实际使用哪个后端。两个都启用时，建议在委派指令里写清优先级。

Q：能不能只给某个项目装？ 可以。用独立 Profile，例如 dsh plugin --profile myproj add ...，再用 dsh --profile myproj 启动。插件与 Preset 都按 Profile 隔离。

Q：卸载后旧会话还能用吗？ 旧会话日志还在，但指向已移除提供方的工具调用会失败。要么保留提供方，要么在新会话里换用其他后端。

一句话收束： 子代理提供方的安装不是“装完即用”，而是“装包 → 重启 → 在 Preset 开工具行 → 新会话验证”四步；少一步，工具就不会出现。