xmanrui/dsh-im

感谢 @xmanrui 的快速响应和实现！从 Issue 提出到功能发布只用了 4 天，效率太高了 👍

v4.1.0 的主动投递和机器人设置页都已经用上了，体验很顺畅。特别是 opt-in 开关的设计，既满足了多用户区分身份的需求，又兼顾了隐私安全，考虑得很周到。

再次感谢！

这个需求是合理的，现在已经在 [v4.1.0](https://github.com/xmanrui/dsh-im/releases/tag/v4.1.0) 补齐了九个 IM 渠道的通用主动投递能力 🎉

升级后，可先在「设置 → IM机器人 → 机器人设置」中为目标机器人配置投递目标并执行真实测试，保存后复制稳定的 `{ botId, targetId }`。任务完成回调、编排器或其他程序随后可通过以下任一入口发送通知：

- HTTP：`POST /api/dsh-im/delivery/messages`
- 同 Host Cordis 插件：`ctx.dshIm.send(botId, targetId, text)`
- Connection RPC：`/dsh-im-delivery` 的 `message.send`

三个入口共用九渠道的同一套连接与投递核心，不需要为微信、钉钉等渠道再建立第二套连接。

需要说明一个边界：v4.1.0 提供的是 dsh-im 主动投递接口，不会把你日志中的 `de_channel_send` 自动注册为每个 Agent Session 都能直接调用的模型工具。因此，原先的“渠道未注册”来自另一套 outbound hook；仅升级插件不会让这个特定工具名自动可用。若希望 Agent 自主决定发送，可由编排器或同 Host 插件把任务完成事件/受控工具调用接到上述 `ctx.dshIm`、HTTP 或 RPC 入口。

飞书原有的“关注 Session，完成后自动推送”机制继续保留，适合用户显式关注的完成通知；v4.1.0 的主动投递则覆盖微信、钉钉及其他渠道的定时任务、长任务回调和业务事件通知。

完整配置和调用示例：
[主动投递使用指南](https://github.com/xmanrui/dsh-im/blob/v4.1.0/PROACTIVE_DELIVERY.md)

本次发布已通过完整的 1,936 项测试和 GitHub CI。欢迎升级到 `@xmanrui/dsh-im@4.1.0` 后验证你的微信、钉钉任务完成通知流程；如果你的编排器需要一个更直接的 Agent 工具适配层，也请继续补充当前工具注册方式，我们可以再对齐最合适的集成形态。

这个能力已经在 [v4.1.0](https://github.com/xmanrui/dsh-im/releases/tag/v4.1.0) 正式发布，非常感谢你当时提供的完整提案和真实飞书验证经验 🎉

最终实现保留了你提议的核心方向：同 Host Cordis 插件声明 `inject = ['dshIm']` 后，可直接通过宿主服务主动投递，不经过浏览器 RPC，也不会建立第二套渠道连接：

```js
const result = await ctx.dshIm.send(botId, targetId, text);
const targets = await ctx.dshIm.listTargets(botId);
```

与原提案稍有不同的是，上游最终采用稳定的 `botId + targetId`：平台原生路由由机器人设置页保存到目标配置中，调用方不需要长期持有或解析渠道专属的 `chatRef`。设置页支持从已持久化的已聊会话中选择目标、手工配置高级路由、真实测试发送，以及复制调用参数。

除了同 Host `ctx.dshIm` 服务，这次还统一提供：

- HTTP：`POST /api/dsh-im/delivery/messages`
- Connection RPC：`/dsh-im-delivery` 的 `message.send`
- 九个 IM 渠道的同一套投递核心和公共错误码

完整配置步骤、cron/插件调用示例、九渠道字段及排错说明：
[主动投递使用指南](https://github.com/xmanrui/dsh-im/blob/v4.1.0/PROACTIVE_DELIVERY.md)

本次发布已通过完整的 1,936 项测试和 GitHub CI。欢迎升级到 `@xmanrui/dsh-im@4.1.0`，用你提到的飞书 cron、晨报或长任务通知场景验证；如果实际接入中发现接口或路由体验还需要调整，请继续反馈。

感谢补充说明，也感谢对 dsh-im 的认可。集中部署确实可以降低非技术用户的使用门槛，但经过评估，这项能力不适合直接放在 dsh-im 中实现。

dsh-im 的职责是把各类 IM 渠道连接到现有 Harness，并处理渠道身份、消息和会话路由。这里提出的目标并不只是增加飞书免密登录，还需要统一身份服务、用户与角色权限、工作区和 Session 授权、凭据隔离、文件系统及进程/工具沙箱、用户开通回收和审计等完整的多租户能力。这些安全边界必须由 Harness、运行时或独立部署控制面统一保证；仅在飞书渠道增加登录，无法防止其他渠道、Web/API 或 Agent 工具绕过，也无法可靠承诺不同用户的代码和知识不会互相泄露。

因此，本仓库暂不计划内置企业多用户 SSO 和运行时隔离，并以 not planned 关闭此 issue。未来如果 Harness 提供了稳定的多租户身份、授权和隔离运行时能力，dsh-im 可以再考虑提供渠道身份映射及用户到独立实例的路由集成。

感谢理解，也感谢提出这个企业使用场景。

已经发布了，请更新到最新版体验

在做了，明天发布：

最新版已实现

DSH Desktop是哪一家的？

DSH Desktop卸载清理缓存，dsh-im卸载重装都测试过，都不行

> 微信扫码成功了，提示报错

用的是哪个版本的DeepSeek Harness？

DSH Desktop和dsh-im都是最新版

最新版本吗？

我分析了一下，你的提案很有价值，支持你提pr，非常感谢

我测试没复现你说的问题

补充一个相关实证（same root area, delivery side）：当回合因 `ask_user_question` 暂停、由 web UI 端作答恢复后，**同一 turn 的后续所有流式播报与最终交付消息都不再送达 IM**（用户只收到提问前的早期消息）；turn 正常 `completed`。而之后用户新发一条消息开启的**新 turn 交付完全正常**（文字+文件附件均可达）。看起来转发/订阅的生命周期与提问暂停或超长回合（本例 67 分钟）存在冲突。环境同主帖：dsh-im 3.0.4 + DSH 0.1.0-rc.5，企业微信渠道。