// 产品族 · im-channel
让你的 Agent 出现在用户已经在用的地方
每个 IM 平台都有自己的 webhook 握手、签名算法、消息格式和奇怪的坑。im-channel把 10+ 平台抹平成统一的入站/出站模型：平台消息进来触发你的 Agent，Agent 结果回到原会话——你的 Agent 核心不需要知道「飞书的 challenge 怎么回」。
订阅开源通知当前为功能原型阶段 · 开源许可证评估中
平台支持矩阵
| 平台 | 入站（webhook → 触发 Agent） | 出站（Agent → 发消息） |
|---|---|---|
| 飞书 | 事件回调（自动应答 URL 验证） | text / markdown 卡片 · @人 · 签名 |
| 钉钉 | Outgoing 机器人回调 | text / markdown · @人 · 加签 |
| 企业微信 | —（群机器人只发不收） | text / markdown · @人 |
| Slack | Events API | chat.postMessage |
| Telegram | Bot API update | sendMessage · Markdown |
| 微信公众号 | 握手 + XML 消息推送 | 客服消息 API |
| Cloud API webhook | Cloud API text | |
| LINE | Messaging API webhook | Push message |
| Discord | —（需 Gateway bot） | Incoming webhook |
| 通用 (generic) | 任意 JSON webhook | POST JSON 到配置 URL |
Agent 中立
通过 AgentInvoker 接口触发任意 Agent 实现——接 uuos 的工作流，也接你自己写的服务。核心不绑定 uuos 的内部模型；在 uuos 中即以产品插件 ai.uuos.im-channel 形态接入。
会话与人工接管
统一的渠道、会话与消息模型：查看跨平台会话历史，需要时人工插入回复——机器人答不好的时候人能兜底。
平台协议细节已处理
webhook 验签、@人、markdown 降级、平台错误码校验——每个平台的协议细节封装在 adapter 里，加渠道是配置而不是开发。
当前状态（如实说）
已有 10 平台 Go adapter、渠道/消息内存 Store、React 组件包与 standalone 页面，竞态测试与前端构建通过。 发布缺口：独立 API/worker、PostgreSQL 持久化、平台事件幂等、重试/死信队列与出站 SSRF 防护。