前言¶
用 dsh（DeepSeek Harness）做智能体工作流时，常会遇到这样的需求：主智能体想找一个外部编码智能体出第二意见，或者把一段编码任务并行交出去。如果走 Kimi CLI，手工做法是自己 spawn kimi -p、捕获输出流、轮询状态、再把结果接回 dsh 会话——这类脚手架代码重复且容易出错，正是 harness 插件该替你消掉的东西。
下面介绍的 dsh-kimi-bridge 做的就是这件事：把 Kimi CLI 变成 dsh 里可直接调用的工具，并在 WebUI 里提供对应的观察界面。
这是什么¶
dsh-kimi-bridge 由 pandashere 维护，许可证为 MIT，当前版本 0.1.0。一句话定位：这是一个 host + browser 双面的 DeepSeek Harness 插件，把 Kimi CLI（kimi-code）桥接进 harness，是 dsh-codex-bridge 的 Kimi 对应版本，两者架构相同。
「双面」指插件同时覆盖两端：host 端向 dsh 注册工具，浏览器端由 /plugins/dsh-kimi-bridge/client.js 提供界面。DSH 的理念是「一切皆插件」，外部 CLI 的能力就是通过这个机制接进会话的。
四个工具¶
call_kimi¶
call_kimi 在当前会话的工作目录运行 kimi -p <prompt> --output-format stream-json，支持两种模式：
async：立即返回，多次调用可以并行；block：等待最终答案；传入kimi_session_id时改为等待一个先前启动的会话，取消阻塞等待会中止对应的 kimi 会话。
参数结构如下：
call_kimi: { prompt, mode?: async|block, model?, timeout_ms?, kimi_session_id? }
每次 call_kimi 都是一次性运行全新的 kimi -p。CLI 本身不支持运行中的实时 steering；kimi-code 的思考过程不写入 stream-json，插件也不会从 stderr 猜测推理内容。
kimi_status 与 kimi_abort¶
kimi_status 列出当前 dsh 会话的全部 kimi 会话，包括状态、prompt 预览和进度。kimi_abort 接收 { kimi_session_id }，对进程组先发 SIGTERM，超过 killGraceMs 后升级为 SIGKILL。
kimi_steer¶
kimi_steer 用 kimi -S <session_id> -p … 继续一个已结束（settled）的父会话：
kimi_steer: { kimi_session_id, prompt, mode?: async|block, model?, timeout_ms? }
新记录通过 parent 链接回父会话，并继承父会话的模型。Kimi 会话绑定工作目录：插件把 cwd 锁定到会话工作目录，保证续接发生在同一目录。会话是线性的——父记录必须是最新记录，一个会话同一时间只能有一个活动续接。
WebUI：Kimi 标签页¶
插件在会话面板里注册一个 Kimi 标签页，位于 Codex 之后。
左列是当前 dsh 会话的全部 kimi 会话，带状态点、prompt 预览和相对时间，点击选中。右列显示状态徽章、meta（id/kimiId/cwd/model/duration/exit/error）、prompt，以及 Activity | Text 两个视图：
- Activity：Agent Loop 瀑布图，包含消息、带参数的工具行、可折叠的工具输出和 turn 分隔符；
- Text：流式 transcript 与最终答案。
状态变化通过会话投影通道实时推送（kimi/session 事件、kimi/sessions 投影），标签页随之即时更新；刷新页面后通过历史回放恢复。
reviewOnly：默认只读白名单¶
先说清设计立场：这是一个 UX 通道，不是安全边界。kimi -p 内部以 permission:"auto" 运行，CLI 没有沙箱标志可用。
因此插件默认 reviewOnly: true：kimi 在一个受管 home 下运行，其 [tools] 白名单只含只读工具——Read、ReadMediaFile、Grep、Glob，没有 Bash/Write/Edit/MCP——并且在工具执行前再次强制。把它改成 false 意味着切换到用户不受限的 home，这是显式的运维选择，不应被称作沙箱。reviewOnly 是工具白名单，不是沙箱；真正沙箱化的 workspace-write 需要 OS 级隔离（container/namespace）。
凭据方面：插件不把凭据复制进仓库或 dsh telemetry；reviewOnly 模式下，受管 Kimi home 通过符号链接指向 CLI 现有的认证文件，CLI 仍是凭据的所有者。Kimi 自身的遥测通过子进程环境变量 KIMI_DISABLE_TELEMETRY=1 禁用。
安装与启用¶
先确认环境：Node.js 22 或更新（engines: node >=22）、@deepseek-ai/dsh@0.1.0-rc.6，以及一个已认证、可用的 kimi CLI（或在配置里设置 kimiPath）。
第一步，在插件目录里构建、校验并打包：
npm install
npm run check # typecheck + tests + compliance
npm pack
npm run check 依次跑类型检查、测试和合规校验；npm pack 生成独立 bundle 的 tarball dsh-kimi-bridge-0.1.0.tgz。如果你要改源码，npm run build 会分别用 tsc 编译 host 端、用 esbuild 打包浏览器端。
第二步，把 tarball 安装进 web profile 并重启 dsh web：
npx @deepseek-ai/dsh@0.1.0-rc.6 plugin --profile web add ./dsh-kimi-bridge-0.1.0.tgz
npx @deepseek-ai/dsh@0.1.0-rc.6 web
第三步，验证浏览器端已就位。浏览器侧代码由 /plugins/dsh-kimi-bridge/client.js 提供，可以对照运行中的默认 Web profile 检查：
curl -s http://127.0.0.1:3080/plugins/dsh-kimi-bridge/client.js | head
经过上面的步骤，会话面板里应能看到 Kimi 标签页。注意不支持以源码目录 link 方式安装，因为 host 端的 peer 依赖由 DSH profile 提供。更新时用新的 package version 重新打包，移除已安装的 bundle，加入新 tarball 并重启。卸载命令如下：
npx @deepseek-ai/dsh@0.1.0-rc.6 plugin --profile web remove dsh-kimi-bridge
配置项¶
README 明确列出以下配置项及默认值：
| 配置项 | 默认值 | 含义 |
|---|---|---|
kimiPath |
kimi |
kimi 可执行文件（绝对路径或 PATH 查找） |
reviewOnly |
true |
在 [tools] 白名单为只读的受管 home 下运行 kimi |
kimiHome |
'' |
配置与认证的来源 home（'' = KIMI_CODE_HOME，否则 ~/.kimi-code） |
reviewHomeDir |
'' |
受管 review home（'' = $DSH_HOME/kimi-review-home） |
maxTimeoutMs |
1800000 |
任何会话超时的硬上限（30 分钟） |
defaultTimeoutMs |
600000 |
每个 kimi 会话的默认存活时间（10 分钟） |
maxParallel |
3 |
并发 kimi 进程的全局上限 |
maxSessionsPerSession |
8 |
每个 dsh 会话的活动 kimi 会话上限 |
maxRetained |
16 |
每个 dsh 会话保留的已结束记录数（最旧淘汰） |
maxPromptChars |
16384 |
prompt 长度上限（argv prompt；拒绝 NUL，超长 prompt 直接拒绝） |
maxTranscriptChars |
16384 |
事件与投影中记录的 transcript 上限 |
maxLoopSteps |
32 |
Agent Loop 窗口保留的步数 |
maxLoopBytes |
16384 |
Loop 窗口的序列化字节上限（UTF-8，淘汰最旧的已完成步骤） |
allowedAgents |
roots |
谁可以调用 call_kimi：roots 或 all |
killGraceMs |
10000 |
SIGTERM 到 SIGKILL 的宽限期 |
两个超时项值得单独说明：kimi 的 print 模式可能出现长等待，所以插件用 defaultTimeoutMs（默认 10 分钟）约束单个会话的默认存活时间，用 maxTimeoutMs（默认 30 分钟）作为任何会话的硬上限。allowedAgents、maxParallel、maxSessionsPerSession 则用来约束资源放大。
已知限制¶
- Agent Loop 窗口是近期活动而非审计记录：超过
maxLoopSteps（32）/maxLoopBytes（16384）时物理淘汰旧步骤，标签页只显示保留窗口（dsh 会话日志本身仍保留完整快照）。 reviewOnly是工具白名单，不是沙箱；真正的 workspace-write 沙箱需要 OS 级隔离。- 仅支持 POSIX 进程组（
detached+ 负 pidkill）；Windows 移植需要 Job Object /taskkill /T树终止。
适用场景与注意¶
适合的场景很具体：你想让 dsh 主智能体把 Kimi 用作第二意见或并行的编码通道；或者你已经在用 dsh-codex-bridge，想以同样的架构接入 Kimi。
几点注意：
1、插件以当前 dsh 进程的权限运行。安装任何第三方插件前，都应先检查源码与许可证——本项目为 MIT。
2、环境要求：Node.js 22 或更新、@deepseek-ai/dsh@0.1.0-rc.6、已认证且可用的 kimi CLI（否则设置 kimiPath）。
3、reviewOnly 默认为 true，属于工具白名单而非沙箱；需要更大自由度时改为 false 是显式的运维选择。
小结¶
回到开头的问题：让 dsh 智能体用上 Kimi，原本需要一套 spawn、抓流、轮询、回填的手工脚手架；dsh-kimi-bridge 把它收敛为四个工具加一个标签页——调用可异步并行，会话可续接，Agent Loop 可观察，默认只读白名单兜底。源码与文档在 GitHub：https://github.com/pandashere/dsh-kimi-bridge，许可证 MIT。社区的 DSH 插件目录（独立站点，与 DeepSeek、幻方没有官方从属关系）也可以按插件名检索。
