CopilotKit/channels-sdk 是一个开源 SDK，旨在帮助开发者将任何 AI 智能体（Agent）无缝集成到 Slack、Microsoft Teams、Discord、Telegram 等日常沟通平台中。
它的核心理念是“你的智能体属于工作发生的地方”，让 AI 能以原生、交互式的界面融入团队现有的工作流。
你给AI一个任务，它转头就去Slack群里跟你老板汇报进度——还顺手把修改建议做成了带按钮的卡片。这不是科幻片。这是今天就能跑起来的代码。
Channels SDK是一套开源工具，专门解决AI机器人被困在单一聊天窗口里的老毛病。它让同一个AI代理能同时出现在Slack、微软Teams、Discord这些地方，而且每处的界面都长得像那个平台原生的东西。
本文拆解这套工具怎么工作、为什么它比传统聊天机器人多了一层“长跑”能力、以及一个普通开发者从零跑到上线到底要敲几行代码。
消息从哪来，就往哪长出合适的形状
先看一个最基础的尴尬。你写了个AI助手，在网页对话框里跟人聊天，表现完美。老板说：把它挪到公司Slack里。你复制粘贴了代码，改了几行适配，跑起来一看——消息是能收了，但回复只是一坨纯文本。Slack里别人发的带按钮的投票、带下拉菜单的表单，你的AI一个都做不出来。它像个外地人进了本地菜市场，听不懂行话，也不会用摊位上的秤。
Channels SDK解决的就是这个“水土不服”。它的核心思路叫“一次描述，到处渲染”。你在代码里写一句“给用户三个选项：批准、驳回、稍后”。SDK不替你把这句话翻译成某种通用的中间格式，而是直接把它变成Slack的Block Kit按钮、Teams的Adaptive Card选项、Discord的组件。平台长什么样，消息就长什么样。
这背后的机制依赖一个叫AG-UI的协议。你可以把AG-UI理解成AI和聊天平台之间的翻译官。它规定了一套标准动作：发消息、调用工具、等待人工确认、渲染界面组件。你的AI只要会说AG-UI这套话，Channels SDK就能把它的话翻译成各个平台听得懂的口令。目前支持的AI框架包括LangGraph、CrewAI、Mastra、Pydantic AI、Google ADK，还有CopilotKit自己内置的代理。
这个设计有个明显的好处：你的AI不用为了迁就Slack重写一遍逻辑，也不用为了适配Teams再改一套代码。工具函数、模型参数、业务规则，全在你自己那边跑。SDK只管最后一公里的翻译和投递。
长跑选手才能接住每一句招呼
聊天的本质是“来回”。你发一句，它回一句。但如果这句回复需要查数据库、算数据、等外部API返回，那中间就有一段空白期。普通的聊天机器人在这段空白期里什么也做不了——它像个接线员，接起电话听完诉求，然后把听筒搁桌上跑去找资料，等你再拿起听筒时，那边已经挂断了。
Channels SDK的设计把AI变成了长跑选手。它用一个长期运行的Node进程来接待每一个会话。这个进程不会因为一条消息处理完了就退出。它会一直驻留在服务器上，等着下一条消息进来，也等着你的人工审批按钮被点击。
代码里能看到这个“长跑”的痕迹。createChannel创建了一个通道实例，channel.onMessage注册了消息处理器。但这个实例不会在处理完一条消息后销毁。它会一直存在，直到你手动调用channels.stop()或者进程收到终止信号。这意味着同一个对话线程里的上下文可以持续累积。AI记得你五分钟前说了什么，因为你那边的状态一直没丢。
更关键的是“暂停等人”这个能力。SDK允许AI在执行某个危险操作之前，先往群里扔一个带按钮的卡片。卡片上写着“要删除这条记录吗？”旁边放着“确认”和“取消”。按钮按下去之前，AI的进程就挂在那里等着。这不光是用户体验的提升——对需要人工把关的业务场景来说，这是合规底线。
钥匙在你兜里，地图在它手上
部署一个能跨平台聊天的AI，最让人头疼的不是写代码，是配权限。Slack要Bot Token，要Signing Secret，要把应用安装到工作区。Teams要类似的凭证。这些敏感信息放哪、谁有权限看、怎么轮换，都是麻烦事。
Channels SDK对凭证的处理方式很干脆：命令行不碰你的密钥。copilotkit channels add这类命令只管声明通道、挂接适配器，不会让你在终端里输入Token。所有的Bot Token、Signing Secret都放在你本地的.env文件里。跑起来的时候，Node进程从环境变量里读。CopilotKit Intelligence那边只管理平台连接的入口和消息投递，不持有你的平台凭证。
配置通道本身只需要三个东西：通道代码、Intelligence API密钥、以及你选的平台。通道代码是在CopilotKit Intelligence控制台里创建通道时生成的短码。API密钥是项目级别的，控制台里也能拿到。拿到这三样，填进.env，跑起node --env-file=.env --import tsx channel.ts，通道就活了。
有意思的是官方提供的“让AI帮你配置”这条路径。你执行npx copilotkit@latest channels setup，CLI会打印一段提示词并复制到剪贴板。你把这段提示词贴给你的编程助手AI，它会自己去读一份在线指南，然后操作Slack控制台和Intelligence控制台，帮你把应用创建好、安装好。如果那个AI没有浏览器操作能力，它会主动要求你先给它装一个——这是设计好的路径，不是应急方案。
这个做法把“配置”这件事从“人看文档手动点”变成了“AI按流程自动点”。你只负责在关键步骤输入密钥，其余点击工作交给AI。
一个通道跑起来，背后藏了四层分工
把一条消息从Slack发出来，到AI回复回去，中间经过了四个角色的接力。理解这个分工，就能明白为什么这套东西既能跑在笔记本上，也能跑在生产环境里。
第一层是平台。Slack或Teams收到用户@机器人的消息，把事件推出来。第二层是CopilotKit Intelligence。它收到平台事件后，不做任何业务处理，只负责把事件投递到你那边跑着的Channel进程。第三层是你的Channel进程。它收到事件，调用你的AI代理，执行工具，拿到结果。第四层是 Intelligence 把结果包装成原生UI格式，发回平台。
这四层里，你控制的是第三层全部，外加第一层的应用注册和第二层的通道创建。Intelligence那边管理的是平台凭证和消息投递的可靠性。SDK本身开源且MIT协议。Intelligence可以托管在CopilotKit那边，也可以企业自行部署。
这个分工意味着两件事。第一，你的业务逻辑始终跑在你的基础设施上，模型密钥、工具代码、业务数据不过别人的手。第二，即使Intelligence服务出了故障，你的Channel进程也不会丢消息——它有自己的健康检查和重连机制。
官方提供了一个完整的开源示例项目叫OpenTag。它是一个值班事故处理助手，用Python的LangGraph写AI逻辑，通过AG-UI协议接到Channels上，同时支持Slack和Teams，还能在处理事故前发卡片等人批准再执行写操作。想研究完整实现的人可以直接翻它的源码。
AI走进聊天群这件事，过去难在每家的餐具不一样。Channels SDK不教AI用刀叉，也不教它用筷子——它给AI配了一个会十八种方言的服务员，客人点什么，服务员就翻译成厨房听得懂的指令。AI只管把菜做好。
这东西的真正价值不在于“能发消息了”，而在于AI终于能蹲在人类干活的地方，用人类习惯的交互方式，跟人类一起把事办了。
按钮、卡片、审批、文件——这些聊天软件里早就有的东西，AI现在也能用，而且用起来跟人没什么两样。