很多人对「编辑器接 AI」的直觉是一个转发层：收下请求，换成某个模型的 API 格式发出去，再把回来的 token 流贴成文本。dsh-acp-interactive 不是这个形状。它是一个面向编辑器的 Agent Client Protocol（ACP）JSON-RPC stdio 服务器：按需创建 dsh agent，把会话里真实发生的事件投影成 ACP 的 message、thought、tool、permission、plan、title、usage、command 更新。首批兼容目标是 Zed。仓库 ClickPM/dsh-acp-interactive，npm latest 1.4.1，MIT，99 星标。判断它值不值得装，要看分层切在哪、协议基线钉在哪个版本、以及为了让普通用户跑起来它替谁付了代价。
先排除一个误解：它不是官方项目
作者自述独立、社区维护，与 DeepSeek、Zed Industries 均无隶属或背书关系，也不声称是官方 DeepSeek ACP agent。它做的是把已发布的 @deepseek-ai/dsh-* 包组合进一个经过 review 的编辑器 profile。这条信息比功能列表重要：协议兼容性由这个仓库自己负责验证，不由上游兜底。
分层：transport 不含领域，组合被预编译进包
这个包同时发两样东西：一个 UI transport 插件，和一个 dsh-acp-interactive 可执行文件。职责边界划得很硬。
transport 里没有领域逻辑
transport 只处理协议面：读 JSON-RPC 帧、维护会话映射、把领域事件翻译成 ACP 的更新类型。它不知道模型怎么选、文件往哪落、shell 用哪个方言。这个约束换来的是可复用——你已有一套 provider、工具、权限策略，把 transport 挂上去就有编辑器入口，不必接受别人的默认值。README 里的自定义部署就是这么写的：只消费 transport export，在专门的 stdio 组合里挂 credentials、llm-pi-ai，再挂 acp-interactive 并用 provider / model 指定新会话的初始路由——给默认，不给约束。
可执行文件为什么必须自带整套组合
普通用户手里没有 dsh 源码树。所以可执行文件加载 config/cordis.yml 里打包好的整套 Cordis 组合：provider、agent 主干、模型生成的会话标题、文件与搜索工具、进程内子代理、shell、权限、持久化、人类命令，以及 ACP transport 本身。
这是明确的产品判断：把「组装」预编译进分发物，换来 npm i -g 之后不必 checkout。代价同样明确——组合每次调整都要发版，用户也无法只替换其中一层，想改就得写补丁层。便利与可塑性在这里互斥，它选了前者。
与上游 automation-only transport 的分岔
上游也有 ACP transport，但只面向自动化。分岔点不在协议实现，而在「谁来回答权限」：自动化场景没人坐在旁边点按钮，权限只能预先收敛；交互式场景里权限请求要回到编辑器，由人在 Allow once / Reject 之间选。这条差异往外扩散出 plan、会话标题、usage、命令目录一整套东西——都是为了让人看懂正在发生什么。判断一个 ACP 桥属于哪类，看它有没有 permission 往返就够了。
协议基线：ACP v1 稳定 schema，SDK 1.4.0
版本决定了编辑器能不能连上。这个发布以 SDK 1.4.0 里的稳定 ACP v1 schema 为基线，不追草案。好处是字段语义不会随草案漂移；代价是上游引入新 capability 时得等这个仓库跟进。稳定与新鲜之间，它选了稳定。
八个方法，和缺席的第九个
实现了 initialize、session/new、session/prompt、session/cancel、session/list、session/load、session/resume、session/close。建、聊、打断、列、载、续、关，生命周期是完整的。
session/delete 没有对外宣告。理由挺讲究：持久化 Service Definition 里没有与后端无关的删除方法，在 transport 里直接动 JSONL 或 SQLite 会绕过持久化的所有权与对账。宁可少一个方法，也不给一个会跟索引打架的删除——工程上站得住，用户侧却疼：清理会话只能手动去 acp-sessions 动文件，而 session/list 只返回一页、也不带 updatedAt，连「最近动过哪个」都判断不了。
权限：不是前置闸门，是沙箱拒绝后的第二跳
工具调用在 Harness sandbox 里执行。以 read-only 预设为例：写操作先被沙箱拒掉并带回升级提示；被重试的调用到 Zed 这边，才变成一条 ACP permission request，给出 Allow once / Reject；批准后写入与读回都渲染成工具卡。
顺序值得注意——沙箱是第一道防线，人是第二道。对安全敏感的场景这是对的；对希望「先问再写」的流程，你看到的是一次失败之后才被询问，第一次遇到容易以为配错了。
子代理不发起权限请求
1.3.0 的进程内子代理继承父沙箱，审批固定 never，也不会发起 ACP 权限请求。委派因此不会在编辑器里弹出一堆确认框，但子代理能做什么完全取决于父会话的沙箱档位——父松子松。
1.3.0 的子代理：一张卡，一段断链
组合挂了 @deepseek-ai/dsh-subagent 的 spawn 与 fork 两个后端，以及 subagent、subagent_fork 两个委派工具。模型把自包含或带对话种子的任务委派出去，拿回最终答案作为工具结果。
在编辑器里一次委派就是一张工具卡，子代理自身的工具调用、回复、嵌套委派与结算都折叠进卡内的受限转录。这不是 UI 偷懒，是协议面没有表达：稳定 ACP 尚无 child-session 能力，卡里只能把子会话 id 放进 _meta.dsh_subagent，给不出可导航的子线程；恢复会话时委派回放成一张已结算结果卡，子转录不再保留。读起来干净，追溯起来断链。
八十个依赖，换「装完就能跑」
运行时依赖约八十个，几乎全是 @deepseek-ai/dsh-*，钉 ^0.2.0-rc.2；另有 @agentclientprotocol/sdk 1.4.0 与 @deepseek-ai/cordis 4.0.4。
打包整套组合的账
八十个直接依赖意味着体积、解析时间和供应链面都不小，这是要记在账上的。换来的是包里已含构建好的 lib/、安装时不跑构建、npm i -g 之后即用；每个版本对应 vX.Y.Z tag 与 Release，附件含 tarball 与 SHA-256，可拿源码核对安装物。
风险面也要说清：静态检查显示它未声明 dsh 版本约束，扫描结论「含敏感能力」，本站尚未做风险分级——不等于无风险，只等于没人替你把分级做完。实装是明确的：本站已在 dsh 0.2.1-rc.2 下真实安装成功。维护上最近一次提交在 31 天前，站点判「更新放缓」；综合分 56.5 / 100，周下载 67，后者是 npm 全网含 CI 与镜像的计数，不等于本站安装数。
总结
它真正提供的是「把一套完整 dsh 组合投影进编辑器协议」的方法，而不是给 Zed 加一个模型入口；同类插件的中文清单与安装形态，可以对着 DeepSeek Harness Hub 插件清单 逐项看。
适合与不适合
适合：已在用 dsh 或 Cordis、想把 agent 放进 Zed 而不是留在终端的人；需要权限请求回到编辑器、能逐个 Allow once 的交互场景；想复用同一套 provider 与凭据、同时跑 Pi Agent Desktop 与 Zed 的人。
不适合：需要会话管理的人——session/delete 未提供，session/list 只给一页且没有 updatedAt，清理只能手动动文件；想让子代理后台长跑、可续、能互相发消息的人，run_in_background、send_message、list_agents 都没组合；依赖 legacy SSE 的 MCP 配置，或需要语音、嵌入资源 prompt 的人，前者被拒、后者直接失败。
标签：dsh-acp-interactive、DeepSeek Harness、ACP 协议、Zed
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。