前言¶
在 DeepSeek Harness（DSH）里做智能体，常见做法是在桌面或 Web 客户端里对话。若希望从 Discord 私信或飞书/Lark 直接驱动同一条原生 Session，还要把进度、Ask User 和定时任务结果可靠地推回渠道，往往需要自己接 Bot、管凭证、防重复投递和跨渠道身份对齐。Channel Core 把 Discord 与飞书适配收进同一个插件包，并与 DSH 原生的 steer/queue/interrupt、Ask User 和进度展示对齐。
这是什么¶
dsh-channel-core（仓库 Kerberos255/dsh-channel-core）由维护者 Kerberos255 发布，在 SkillHub 目录中归类为客户端插件。README 的定位是：一个插件同时覆盖 Discord 与 Feishu/Lark 渠道，提供已验证的 owner 身份、可选的跨渠道共享 Session、可靠的消息投递，以及进度/状态集成。插件不替代 Host 上的模型与任务引擎，只管理渠道侧的投递、回执与绑定状态。
核心功能¶
双渠道与独立生命周期¶
Discord 与飞书适配器在同一 npm 包内，各自使用独立凭证与连接生命周期。在 Settings → Plugins → Channels & Sessions 中分别配置 Discord、飞书 Tab、平台凭证以及允许的用户/频道；仅连接成功并不自动授权消息投递。
身份验证与会话映射¶
每个 Bot 账号下会验证 channel owner。群聊与未验证用户不应继承个人记忆（personal-memory）权限。在入站消息通过渠道 allow 规则后，可对首次私信做自动 owner 认领，也支持手动选择 owner。若显式配置，可将同一已验证 owner 在不同渠道上的私信映射到同一个原生 DSH Session；共享长期记忆不必强制共享 Session。Session 映射决策可审计，不能静默复用其他 workspace 的 Session。
入站可靠性与原生交互¶
插件使用持久化入站回执、串行 Session 准入，以及原生 steer/queue/interrupt，避免重放消息。Ask User 提交后，Discord 与飞书都会把问题与所选/自定义答案呈现为只读回执并移除交互控件，已提交的上下文保持可见且不会作为重复答案再发。Discord 在滚动进度消息中流式展示 thinking、draft 与 tool 活动；飞书支持 CardKit 组件流式，并有 IM 卡片回退，draft 与 thinking 有独立可见性开关。
斜杠命令¶
Discord 提供扁平命令：/new、/stop、/status、/session、/answer、/prompt、/model、/think。飞书支持文本形式的同名命令。模型选择受可用模型约束，从下一轮生效；provider 歧义时会给出候选。
主动出站（channel_send）¶
智能体可在没有先入站消息的情况下发起出站。面向模型的渠道工具为 channel_send({ text?, imagePath?, filePath?, bindingId?, idempotencyKey? })，向当前原生 Session 已授权且符合条件的 Feishu 或 Discord 目的地发送。一次调用可发文本、一张飞书图片或一个飞书文件；filePath 须在当前 workspace 内，以媒体上传而非 Markdown 路径发送。Session 只能向自身 eligible binding 发送；多 binding 须显式 bindingId，不接受任意 recipient ID 或跨 Session 投递。投递经 durable outbox，状态为 pending、sent、failed 或 uncertain；稳定 idempotency key 不会重复发送同一条消息。
受信 Host API ctx.channelCore.sendToBoundSession({ sessionId, text, idempotencyKey, bindingId?, source? }) 仍可供调度器与其他插件使用；outboundTargets(sessionId) 返回 eligible binding ID，不暴露 recipient ID。飞书侧 channel_send 还支持 { filePath: "_scratch/report.pdf" } 等形式的真实可下载附件（README 列出的格式含 PDF、Office、压缩包、TXT、CSV、Markdown、JSON 等，以仓库文档为准）。
可选任务通知¶
General & Sessions → Task notifications 默认关闭。开启后可选择通知渠道（None、Feishu 或 Discord），且仅限当前 Host 已启用并配置的渠道。调度任务失败时，可向已验证 owner 的 DM 发送简短告警，不会发到任意聊天；收件人解析跟随当前 authorized channel binding，正常 /new 或归档 Session 交接一般无需重配。其他插件可独立发出 dsh/task-alert 等事件，由 Channel Core 负责选择与投递；payload 不包含私密对话正文。
安装与启用¶
需要与 package.json 中 peer 服务兼容的 DSH Host，以及你所启用渠道的凭证。安装或更新代码后需重启 DSH。若需可复现安装，可将安装 pin 到指定 Git commit。
dsh plugin --profile desktop add github:Kerberos255/dsh-channel-core
将 desktop 换成你实际使用的 DSH profile 名称。
典型用法¶
按 README Quick start，建议顺序如下：
- 打开 Settings → Plugins → Channels & Sessions。
- 在 Discord 和/或飞书 Tab 中填写平台凭证与 allowed users/channels。
- 检查各渠道的 owner 识别模式（自动首次 DM 认领或手动选择）。
- 若要在 Discord 与飞书之间共用同一条 live DSH session，按需关联 owner 账号；仅共享记忆时可不做 Session 共享。
- 发送测试私信，确认绑定 workspace、Session 与进度输出是否符合预期。
定时任务或报表生成后，可在 Session 内调用 channel_send 推送结果；若需写入对话历史，应使用绑定到相关 Session 的原生 DSH Schedule。本地可运行 npm test 做无外部依赖的回归；npm run test:host 需在已配置的 DSH 开发环境中运行更广的集成套件。README 明确：CI 通过不能证明真实 Discord、飞书或网络鉴权；Bot 投递与 UI 交互需在自有 Host 上验证。
适用场景与注意¶
适合已在 DSH 上运行智能体、并希望通过 Discord 私信或飞书/Lark 与同一 Harness 会话交互的开发者或团队。需要跨渠道统一 Session、原生 Ask User、流式进度，或由调度/插件向已绑定渠道主动发消息时，该插件与 Host 原生能力是对齐的。
安全与运维边界（摘自 README）：设置与渠道文件保存在本机 DSH，勿上传凭证、binding 数据库或历史消息；配置可参考仓库 config.example.json。插件以当前 dsh 进程权限运行，安装前应自行审阅源码与 MIT 许可证（见 LICENSE）。DSH 生态强调「一切皆插件」；SkillHub 等社区目录为独立站点，与 DeepSeek / 幻方无官方从属关系。
同维护者的相关项目包括 dsh-status-cards、dsh-memory-dreaming、dsh-lossless-context，可按需组合，并非安装 Channel Core 的前置条件。
结尾¶
Channel Core 把 Discord 与飞书收进单一 DSH 客户端插件：验证 owner、可选共享 Session、 durable 投递与原生进度/Ask User 一体。目录页：skillhub.cn/plugins/Kerberos255/dsh-channel-core；源码与完整说明：github.com/Kerberos255/dsh-channel-core。
