前言¶
DeepSeek Harness（dsh）把模型、工具、会话和界面都做成插件，官方仓库的口号就是「一切皆插件」。实际干活时，很多人手里并不只有 dsh：BitFun 是另一套桌面 Agent，能写代码、做文档、操作浏览器和桌面。两边各自能跑，但默认并不互通——dsh 会话里想把一段任务交给 BitFun，没有现成通道。
Agent Client Protocol（ACP）就是为这类对接准备的协议：本地场景下，客户端和 Agent 用 stdio 上的 JSON-RPC 通信，思路接近当年的 LSP。dsh 官方已经提供了进程外 ACP subagent 包 @deepseek-ai/dsh-subagent-acp；BitFun CLI 则内置了 bitfun acp 服务端。缺的是把两者接起来的 bundle。
dsh-acp-for-bitfun 做的就是这件事。本文按社区目录页、插件 GitHub 仓库 README / package.json / index.js，以及 DeepSeek Harness、BitFun 官方仓库核对后整理：它是什么、怎么装、怎么验、边界在哪里。社区插件目录（deepseek-harness-plugin.com）是独立站点，和 DeepSeek / 幻方没有官方从属关系，不要把它当成官方应用商店。
这是什么¶
dsh-acp-for-bitfun 是一款开发与运行时类插件，由 bobleer 维护，仓库在 GitHub bobleer/dsh-acp-for-bitfun，许可证 MIT，当前版本 0.1.0，主要语言 JavaScript。目录页和 GitHub 上都显示 9 star。
它解决的问题很具体：通过 ACP v1 over stdio，把 BitFun 接到 dsh 里，作为当前会话的 subagent。装好之后，dsh 里任意会话都可以调用模型可见工具 subagent_bitfun，把任务委托给 BitFun 执行。
插件本身是一个 dsh bundle：Cordis 补丁文件 cordis.patch.yml 插入 id 为 bitfun-acp 的插件行，入口是 index.js。它没有自己实现一套 ACP 客户端，而是复用 dsh 官方的两个包：
@deepseek-ai/dsh-subagent-acp：作为 ACP 客户端，按任务拉起子进程@deepseek-ai/dsh-tool-subagent：把 provider 挂成模型能调用的工具
依赖版本与 dsh 对齐，当前是 ^0.1.0-rc.6。
工作原理¶
README 里的数据路径可以写成下面这样：
dsh 会话 ──subagent_bitfun 工具──▶ dsh-subagent-acp (ACP 客户端)
│ 每个任务 spawn 一个独立进程
▼
bitfun acp (ACP server, stdio JSON-RPC)
│
▼
BitFun Agent Runtime
一次委托大致走完：initialize → session/new → session/prompt，并流式收集 agent_message_chunk。任务结束时关闭子进程 stdin，EOF 宽限 6 秒，随后 SIGTERM，再不行就 SIGKILL。README 写明：BitFun 子进程在 SIGTERM 下立即退出，会话数据由 BitFun 自身持久化。
官方 dsh-subagent-acp 的实现还补了几条边界，写进文章里不容易误解：
- 每个子进程有自己的进程、会话、模型和工具，不继承父会话的 Cordis 上下文。
- 父侧几乎只把工作目录（cwd）传过去；子进程不能按父侧的
outputSchema/maxDepth/toolFilter来约束。 - 权限请求不会弹给人看，而是按配置自动应答。本插件默认是
reject。
插件加载时（checkOnStart 默认为 true）会先跑 bitfun --version。CLI 不在 PATH 上、或探测失败，会直接让 profile 启动失败，而不是等到第一次委托才报错。
核心功能¶
把 BitFun 暴露成 subagent 工具¶
对模型来说，见到的工具名默认是 subagent_bitfun，provider 名默认是 bitfun。dsh 会话里让模型调用这个工具，任务就会进 BitFun 的 Agent Runtime。工具通过 @deepseek-ai/dsh-tool-subagent 挂载，maxDepth 设为 provider-managed（递归预算由进程外的 BitFun 子进程自己管），并打开了 one-shot 后台运行。
按任务冷启动 ACP 子进程¶
每次委托都会 spawn 一个新的 bitfun acp 进程，而不是复用常驻连接。仓库 TODO.md 里仍把「连接复用」列为未做事项：BitFun 的 ACP server 支持多 session，但当前 bundle 选择每任务冷启动。隔离更干净，代价是启动开销。
启动前探测 CLI¶
index.js 里用 spawnSync(command, ['--version']) 做探测。失败时的错误信息会提示：从 https://github.com/GCWing/BitFun 安装 BitFun、用 bitfun acp doctor 自检，或把 command 配成可执行文件的绝对路径。
可覆盖的运行参数¶
插件 id 是 bitfun-acp。可以在 profile 的 cordis.patch.yml 里按 id 覆盖命令路径、工具名、权限策略和环境变量，不必改源码。
安装与启用¶
前置条件¶
仓库 README 列出了三样东西，需要先满足：
- BitFun CLI：ACP server 内置于 CLI，不是只装桌面端就够。安装后确认
bitfun acp doctor通过。兼容性要求 BitFun>= 0.2.17（提供 ACP v1 的bitfun acp）。截至 2026-08-14，BitFun 已发布0.2.18。 - dsh：
npx @deepseek-ai/dsh --version，需要>= 0.1.0-rc.6，与依赖的 subagent 包版本匹配。DeepSeek Harness 目前仍是 developer preview，官方 README 写明会有破坏性变更。 - pnpm：
dsh plugin通过 pnpm 安装 bundle。
BitFun 0.2.18 的发行说明里还提到桌面端「原生支持 DeepSeek Harness」，那是 BitFun 作为 IDE、通过 ACP 去连 dsh 的方向。本插件方向相反：在 dsh 里把 BitFun 当 subagent 用。两边可以同时存在，不要混成同一个功能。
目录页给出的安装命令¶
社区目录页上的安装命令以页面原文为准，在 DeepSeek Harness 终端里运行：
dsh plugin add github:bobleer/dsh-acp-for-bitfun
如需可复现安装，按目录页说明固定 commit 哈希：
dsh plugin add github:bobleer/dsh-acp-for-bitfun#commit
把最后的 commit 换成仓库里实际的提交哈希。插件以当前 dsh 进程的权限运行，安装时可能执行代码，装之前应检查源代码仓库和许可证。
README 里的 profile / 本地写法¶
插件 README 另外写了带 --profile web 的装法，以及从本地 checkout 安装：
# 把 bundle 加进 web profile（从 npm 或本地目录）
dsh plugin --profile web add dsh-acp-for-bitfun
# 从本地 checkout 安装
dsh plugin --profile web add ./dsh-acp-for-bitfun
# 启动
dsh web
需要注意：仓库 TODO.md 里「发布到 npm registry」仍未勾选。在 npm 包真正发布之前，更稳妥的是目录页这条 github:bobleer/dsh-acp-for-bitfun，或 README 的本地路径装法。不要默认 dsh plugin add dsh-acp-for-bitfun（不带 GitHub 源）已经能从 npm 解析到。
配置¶
默认配置可以不改。BitFun 不在 PATH 上、或要改工具名、权限策略时，在 profile 的 cordis.patch.yml（路径形如 $DSH_HOME/profiles/<profile>/cordis.patch.yml）里按 id 覆盖。README 给出的示例：
- id: bitfun-acp
name: dsh-acp-for-bitfun
config:
command: /absolute/path/to/bitfun # 默认 'bitfun'（PATH 解析）
providerName: bitfun # 默认 'bitfun'
toolName: subagent_bitfun # 默认 'subagent_bitfun'
permission: reject # 'reject' | 'allow'
acpArgs: ['acp'] # 默认 ['acp']
env: {} # 传给 BitFun 子进程的额外环境变量
checkOnStart: true # 加载时探测 bitfun，缺失则启动失败
配置项和 index.js 里的 Schema 一致：
command：BitFun CLI 可执行文件，PATH 上的名字或绝对路径，默认bitfun。providerName：注册到ctx.subagents上的 provider 名，默认bitfun。toolName：模型可见的工具名，默认subagent_bitfun。permission：BitFun 发起session/request_permission时的自动应答，reject（默认）或allow。官方 ACP 客户端不会把这类提示交给人点。acpArgs：跟在command后面的参数，默认['acp']，也就是实际拉起bitfun acp。env：传给 BitFun 子进程的额外环境变量。官方dsh-subagent-acp会在一份清洗过凭据的父进程环境之上再叠加这里的键值。checkOnStart：加载时是否探测command --version，默认true。
bundle 自带的 cordis.patch.yml 只负责插入这一行插件，不带自定义 config；覆盖发生在你的 profile 补丁里。
典型用法：装完怎么验¶
README 给的验证步骤可以直接照做。
1、BitFun 侧自检：
bitfun acp doctor
2、确认 dsh 配置树里已经有插件行：
dsh --profile web --dump-config | grep -A 2 bitfun
3、启动会话后，让模型调用 subagent_bitfun，委托一个简单任务。README 用的例子是：
用 subagent_bitfun 回复 hello
能返回 BitFun 的输出，说明 ACP 握手、session/prompt 和流式收集这一段是通的。更复杂的编码或桌面操作是否成功，取决于本机 BitFun 的模型配置、工作区和权限策略，那已经超出这个 bundle 的职责。
适用场景与注意事项¶
适合已经在用 dsh、同时又装了 BitFun CLI 的人：希望主会话仍留在 DeepSeek Harness，只把某一类任务（例如交给 BitFun 的代码修改、文档或桌面操作）委托出去。也适合在评估 ACP 互通时，需要一个现成的 dsh ↔ BitFun 样例，而不是从零写客户端。
使用前建议把这几条看清楚：
- 权限与进程隔离。插件以当前 dsh 进程的权限运行，安装时可能执行代码。装之前检查 GitHub 源码和 MIT 许可证。委托出去的 BitFun 子进程是独立进程，不共享 dsh 的 Cordis 上下文，但会使用父会话的工作目录；它能在这个目录里做什么，由 BitFun 自己的能力和
permission策略决定。默认reject更保守，改成allow等于自动批准 BitFun 的权限请求。 - 版本绑定。BitFun
>= 0.2.17，dsh>= 0.1.0-rc.6。dsh 仍在 developer preview，插件依赖其 rc 包。README 要求：升级 dsh 时同步升级本 bundle。仓库 TODO 也写了要跟随 rc 节奏升级依赖。 - 每任务冷启动。当前实现不为多个任务复用同一个
bitfun acp进程。短任务会感觉多一次进程启动；这是设计取舍，不是安装失败。 - npm 包尚未作为默认安装源。目录页走 GitHub 源；README 的 npm 包名装法，在作者自己的 TODO 勾掉「发布到 npm」之前，不要当成已经可用。
- 仓库仍标了未完成项。除了 npm 发布和连接复用，TODO 里还有「添加自动化冒烟测试」。目前验证主要靠
bitfun acp doctor、dump-config 和会话里实际调一次工具。
小结¶
dsh-acp-for-bitfun 不做新的 Agent Runtime，也不改 dsh 核心。它把官方 ACP 客户端和 BitFun 自带的 ACP server 接到一起，让 dsh 会话多一个名为 subagent_bitfun 的委托入口。协议是 ACP v1，传输是 stdio，进程按任务隔离。
目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-acp-for-bitfun/
GitHub：https://github.com/bobleer/dsh-acp-for-bitfun
BitFun：https://github.com/GCWing/BitFun
DeepSeek Harness：https://github.com/deepseek-ai/deepseek-harness
