基于Cloudflare Workers与MCP构建主动型Slack AI机器人实战-北京尧图网络

1. 为什么“会主动干活的 AI”才是团队协作的下一站Slack 里塞一个 AI 机器人这件事本身不新鲜。真正让我眼前一亮的是company-brain这个项目的定位——它不是那种你问一句它答一句的“问答机”而是一个会主动在频道里干活、主动整理信息、主动把散落在对话里的知识沉淀下来的角色。这个差别用过团队协作工具的人都懂被动型机器人你三天就想把它踢出频道主动型机器人你一天不看它汇报就浑身难受。先把话说清楚company-brain 解决的核心痛点有三个。第一团队在 Slack 里产生的信息是碎片化且易失的今天讨论的决策、明天就淹没在几百条消息里新人进来根本找不到上下文。第二传统的知识库需要人手动维护没人愿意干这活最后知识库变成“僵尸文档”。第三现有的 AI 助手大多停留在“你问我答”需要人主动发起而真正有价值的场景是 AI 自己发现“这里有个值得记录的东西”然后动手。这个项目适合谁来研究我建议三类人重点看一是中小团队的技术负责人想用低成本给团队加一个“记忆中枢”二是做 AI Agent 方向的开发者想看看怎么用 Cloudflare Workers MCP 这套组合拳落地一个真实可用的主动型 Agent三是对 MCP 协议好奇但还没上手的人这个项目是一个非常好的实战样本因为它把 MCP 的调用链路完整跑通了。我先把技术栈的骨架摆出来方便你建立全局认知。整个项目跑在Cloudflare Workers上这意味着它是无服务器架构冷启动快、按量计费、全球边缘节点分发。AI 能力通过MCPModel Context Protocol接入MCP 你可以理解成“AI 和外部工具之间的标准插座”让模型能规范地调用搜索、读写、数据库等能力。Slack 侧通过 Events API 和 Web API 双向通信AI 既能“听”频道消息也能“说”和“做”。这套组合的妙处在于边缘计算负责响应速度MCP 负责能力扩展Slack 负责交互入口三者各司其职。提示MCP 不是某个厂商的私有协议它是一个开放标准核心价值是让 AI 调用工具的方式统一化。你写一次工具描述理论上可以被任何支持 MCP 的客户端复用这是它比“每个平台自己写一套 function calling”更值得投入的原因。接下来我会从整体设计思路、核心机制拆解、实操落地步骤、踩坑排查四个维度把这个项目掰开揉碎讲一遍。不管你是想直接复现还是想借鉴它的架构做自己的 Agent都能拿到能直接抄的东西。2. 整体架构设计与技术选型背后的取舍2.1 为什么是 Cloudflare Workers 而不是传统服务器很多人第一反应是“我拿个 Node.js 服务器 ngrok 不也能跑 Slack 机器人吗”能跑但你会很快撞到三堵墙。第一堵是冷启动和响应延迟Slack 的事件回调有 3 秒超时限制你服务器稍微卡一下Slack 就认为你没响应会重试重试又带来重复处理。第二堵是运维成本你要管进程、管日志、管证书续期一个个人项目根本扛不住。第三堵是全球访问团队成员分布在不同地区你的单点服务器总有人访问慢。Cloudflare Workers 恰好把这三堵墙都拆了。它跑在边缘节点上Slack 的请求就近处理冷启动通常在毫秒级它是无服务器你只管写代码运维交给平台它天然全球分发不用你操心 CDN。代价是什么Workers 的运行时有约束比如不支持完整的 Node.js APICPU 时间有限制长时间后台任务要用 Durable Objects 或 Queues 来兜。所以选型的本质是用运行时约束换取运维和延迟上的巨大收益对于 Slack 机器人这种“请求-响应”为主的场景这笔买卖非常划算。我实测下来一个简单的 Slack 事件处理函数在 Workers 上的 P99 延迟能稳定在 100ms 以内这个数字放在自建服务器上光 TLS 握手加网络往返就未必达得到。2.2 MCP 在架构里扮演什么角色如果把 company-brain 比作一个人Slack 是它的耳朵和嘴Workers 是它的身体那 MCP 就是它的工具箱接口。AI 模型本身只会“生成文本”它不知道怎么读数据库、怎么搜历史消息、怎么写文件。MCP 做的事情就是把这些能力标准化成一个个“工具”模型通过 MCP 协议去调用。为什么不用传统的 function calling 直接写因为 function calling 是各家模型厂商自己的格式你换一个模型工具定义就得重写一遍。MCP 把这一层抽象出来了工具的描述、参数、调用方式都是统一的。company-brain 里 AI 需要的能力大概有这么几类读取 Slack 频道历史、搜索特定关键词、写入知识库、调用外部搜索。这些能力如果都用 MCP 封装未来你想换模型、加工具改动量会小很多。注意MCP 目前生态还在快速演进不同客户端对 MCP 的支持程度不一样。你在选型时要确认你的 AI 客户端比如某些支持 MCP 的编辑器或 Agent 框架是否支持你需要的传输方式stdio 还是 HTTP/SSE。company-brain 跑在 Workers 上通常走的是 HTTP 类的传输这点在配置时要特别留意。2.3 主动型 Agent 的触发机制设计这是整个项目最核心、也最容易被忽略的部分。被动型机器人是“事件驱动”——有人它它才动。主动型机器人需要额外的触发源常见的有三种定时触发Cron、事件触发新消息进来就判断、状态触发某个条件满足就行动。company-brain 用的是组合拳。定时触发用 Cloudflare 的 Cron Triggers比如每小时扫一遍频道把有价值的讨论整理成摘要。事件触发用 Slack Events API新消息进来时判断是否包含决策、待办、关键结论等信号。状态触发则是当知识库积累到一定量时触发一次“知识重组”把零散条目合并成结构化文档。这里有个设计上的关键取舍主动不等于频繁打扰。如果 AI 每隔十分钟就在频道里发一条“我整理了以下内容”团队会疯掉。所以 company-brain 必须有一套“静默判断”逻辑——大部分时候它只是默默记录只在真正有价值时才冒泡。这个阈值怎么定后面实操部分我会给具体参数。3. 核心机制拆解AI 是怎么“主动”起来的3.1 Slack 事件订阅与消息过滤链路Slack 的事件订阅机制是这样的你在 Slack App 配置里填一个 Request URLSlack 会把频道里发生的事件 POST 到这个 URL。company-brain 的 Workers 就是接收这个 POST 的端点。但这里有个坑Slack 要求你在 3 秒内返回 200否则会重试。而 AI 处理一条消息可能要好几秒怎么办标准解法是先 ACK 再异步处理。Workers 收到请求后立刻返回 200然后把实际处理逻辑丢给waitUntil或者一个 Queue。waitUntil是 Workers 提供的 API允许你在返回响应之后继续执行异步任务。这样 Slack 那边看到的是“秒回”用户体验上不会有任何卡顿。消息过滤是第二道关卡。不是每条消息都值得 AI 处理。company-brain 的过滤逻辑大致是先排除机器人自己的消息否则会无限循环、排除纯表情和短消息、再用一个轻量判断可以是关键词匹配也可以是让模型快速分类决定这条消息是否进入深度处理。我建议过滤要宁可漏过不可错杀因为误处理一条闲聊的代价是浪费 token 和可能打扰团队而漏掉一条有价值消息的代价只是少记录一次。3.2 用 MCP 工具链把“对话”变成“知识”这是整个项目最有技术含量的部分。一条 Slack 消息进来AI 要做的不是简单回复而是判断“这条消息里有没有值得沉淀的东西”如果有就调用 MCP 工具把它写进知识库。具体链路是这样的消息文本先经过一次意图识别判断它属于“决策”“待办”“事实”“闲聊”中的哪一类。如果是前三类就提取关键信息生成结构化条目然后调用 MCP 的写入工具存起来。存储可以用 Workers KV键值存储适合简单场景或者 D1Cloudflare 的 SQLite 数据库适合需要查询的场景。我倾向于用 D1因为知识库迟早需要按时间、按标签、按关键词检索KV 做这个很别扭。MCP 工具的定义大概长这样这是基于常见实践的示例不是项目原文{ name: save_knowledge, description: 把一条团队知识写入知识库, inputSchema: { type: object, properties: { content: { type: string, description: 知识内容 }, category: { type: string, enum: [decision, todo, fact] }, source_channel: { type: string }, timestamp: { type: string } }, required: [content, category] } }模型看到这个工具描述就知道自己可以调用它来存知识。这就是 MCP 的价值——工具的能力用自然语言描述清楚模型自己决定什么时候用。3.3 主动汇报的触发阈值与频率控制前面说了主动不能等于打扰那阈值怎么定我的经验是分三档。低价值内容比如零散的事实只存不报永远不主动发消息。中价值内容比如一个明确的决策在当天结束前汇总成一条日报。高价值内容比如影响多个团队的架构决策立即在相关频道发一条提醒。频率控制上company-brain 应该有一个“冷却期”机制。同一个频道AI 主动发言的间隔不能短于某个值比如 30 分钟避免刷屏。这个状态可以存在 KV 里每次发言前检查一下上次发言时间。另外AI 的发言最好带一个明确的标识让团队知道这是自动整理的而不是某个人说的避免混淆。实操心得我见过太多 Agent 项目死在“太吵”上。主动型 AI 的第一原则是克制宁可少说不可多说。你可以在项目初期把主动汇报的频率调得很低观察团队反应再逐步放开。4. 从零复现完整实操步骤与关键配置4.1 环境准备与依赖安装先把工具链备齐。你需要一个 Cloudflare 账号免费版就够跑起来、一个 Slack 工作区有管理员权限才能装 App、一个支持 MCP 的 AI 客户端或 API Key。本地开发环境建议装 Node.js 18 和 WranglerCloudflare 的官方 CLI。npm install -g wrangler wrangler login登录之后创建一个新的 Workers 项目npm create cloudflarelatest company-brain cd company-brain创建过程中会让你选模板选“Hello World”起步就行后面我们自己改。然后装几个关键依赖Slack 的 SDK或者直接用 fetch 手写也行看你偏好、MCP 相关的客户端库。npm install slack/web-api modelcontextprotocol/sdk这里有个细节要注意Workers 的运行时不支持所有 npm 包有些包依赖 Node.js 的fs、net等模块装上去会报错。Slack 的 Web API 包是纯 HTTP 的没问题MCP SDK 要看版本建议用较新的、明确支持 Workers 的版本。如果遇到兼容问题退而求其次直接用 fetch 手写 HTTP 调用反而更可控。4.2 Slack App 配置与权限申请这一步是很多人的拦路虎我详细说。去 Slack API 后台创建一个新 App选择“From scratch”起个名字选好工作区。然后进入配置页面重点配三块。第一块是OAuth Permissions。你需要申请这些 Bot Token Scopeschannels:history读频道历史、channels:read读频道信息、chat:write发消息、app_mentions:read读提及。如果要做主动汇报chat:write是必须的。申请完 scope 后把 App 安装到工作区拿到 Bot User OAuth Token这个 token 要存到 Workers 的环境变量里千万别硬编码在代码里。第二块是Event Subscriptions。打开开关填你的 Workers URL格式是https://你的项目名.你的子域.workers.dev/slack/events。然后订阅这些 bot eventsmessage.channels频道消息、app_mention被。填完 URL 后 Slack 会发一个 challenge 请求验证你的 Workers 要能正确响应这个 challenge否则验证不过。第三块是Interactivity Shortcuts可选。如果你想让 AI 的消息带按钮比如“确认保存”“忽略”需要在这里配置。注意Slack 的 URL 验证请求里有一个challenge字段你的代码必须原样返回它。很多人卡在这里以为是签名验证问题其实是没处理 challenge。下面这段代码是必须的if (body.type url_verification) { return new Response(body.challenge, { status: 200 }); }4.3 Workers 端事件处理与签名验证Slack 每个请求都带签名你必须验证签名否则任何人都能伪造请求打你的端点。验证逻辑是用你的 Signing Secret 对请求体做 HMAC-SHA256然后和请求头里的签名比对。Workers 里可以用 Web Crypto API 做这个。async function verifySlackSignature(request, body, signingSecret) { const timestamp request.headers.get(x-slack-request-timestamp); const signature request.headers.get(x-slack-signature); const sigBasestring v0:${timestamp}:${body}; const key await crypto.subtle.importKey( raw, new TextEncoder().encode(signingSecret), { name: HMAC, hash: SHA-256 }, false, [sign] ); const sig await crypto.subtle.sign(HMAC, key, new TextEncoder().encode(sigBasestring)); const mySignature v0 [...new Uint8Array(sig)].map(b b.toString(16).padStart(2, 0)).join(); return mySignature signature; }验证通过后判断事件类型。如果是message且不是机器人自己发的就进入处理流程。这里记得用waitUntil把耗时逻辑异步化先返回 200。ctx.waitUntil(processMessage(event)); return new Response(, { status: 200 });4.4 MCP 工具接入与知识写入MCP 工具的接入分两步定义工具、注册到客户端。定义就是前面那个 JSON schema注册则是把你的工具端点告诉 MCP 客户端。如果你用的是支持 MCP 的 Agent 框架通常有一个配置文件或者初始化代码来注册工具。知识写入这块我建议用 D1。先创建数据库wrangler d1 create company-brain-db然后在wrangler.toml里绑定[[d1_databases]] binding DB database_name company-brain-db database_id 你的数据库ID建表语句CREATE TABLE knowledge ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT NOT NULL, category TEXT NOT NULL, source_channel TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP );写入的时候AI 提取出的结构化内容通过 MCP 工具调用落到这张表里。查询的时候可以用关键词匹配或者向量检索如果内容量大建议上向量但初期用 LIKE 查询完全够用。4.5 定时任务与主动汇报实现Cloudflare 的 Cron Triggers 在wrangler.toml里配置[triggers] crons [0 * * * *]这表示每小时触发一次。触发时 Workers 会调用你的scheduled处理函数。在这个函数里你查询过去一小时新增的知识条目判断是否有值得汇报的内容如果有就调用 Slack API 发消息。async function scheduled(event, env, ctx) { const recent await env.DB.prepare( SELECT * FROM knowledge WHERE created_at datetime(now, -1 hour) AND category decision ).all(); if (recent.results.length 0) { const summary await summarizeWithAI(recent.results); await sendSlackMessage(env.SLACK_TOKEN, env.REPORT_CHANNEL, summary); } }这里的summarizeWithAI就是调用你的 AI 能力把零散条目合成一段人话。注意频率控制别每小时都发可以加一个判断只有决策类条目超过 3 条才发。5. 常见问题与排查技巧实录5.1 Slack 验证不通过怎么办这是最高频的问题。排查顺序是这样的先确认你的 Workers URL 是 HTTPS 且公网可访问本地开发用wrangler dev时Slack 访问不到你的 localhost需要用wrangler dev --remote或者部署到线上测试。再确认 challenge 处理逻辑正确返回的是纯文本的 challenge 值不是 JSON。最后检查签名验证如果签名验证失败先临时把验证逻辑注释掉确认链路通了再打开避免两个问题混在一起排查。还有一个隐蔽的坑Slack 的请求体是原始字符串你在验证签名时必须用原始 body不能先JSON.parse再JSON.stringify因为序列化顺序可能变导致签名对不上。正确做法是先await request.text()拿到原始字符串验证签名后再JSON.parse。5.2 AI 不主动发言或发言太频繁不发言通常是触发条件太严。检查你的 Cron 是否真的在跑可以在 scheduled 函数里加日志用wrangler tail看输出检查查询条件是否过滤掉了所有数据检查 Slack token 是否有chat:write权限。发言太频繁则是阈值太低。把冷却期调长把汇报门槛提高。我建议初期把主动汇报设成“每天一次日报”跑一周看团队反馈再决定要不要增加频率。记住主动型 AI 的信任是慢慢建立的一上来就刷屏只会被拉黑。5.3 MCP 工具调用失败排查MCP 调用失败常见原因有三类。一是工具描述不清晰模型不知道该什么时候调用解决方法是把description写得更具体加上使用场景说明。二是参数格式不匹配模型传的参数类型和 schema 对不上解决方法是把 schema 写严格用enum限制取值范围。三是传输层问题HTTP 类的 MCP 要确认端点可达、认证正确。排查时建议打开详细日志把模型请求和工具返回都打出来。很多时候问题不在 MCP 本身而在模型根本没触发工具调用——这时候你要检查你的提示词里有没有明确告诉模型“你有这些工具可用”。5.4 常见问题速查表问题现象可能原因排查方向解决建议Slack 验证失败challenge 未返回或签名错误检查原始 body 处理先注释签名验证定位问题事件重复处理未及时返回 200检查是否用了 waitUntil先 ACK 再异步处理AI 不发言Cron 未触发或条件过严用 wrangler tail 看日志放宽查询条件测试发言刷屏冷却期缺失或过短检查 KV 状态记录加冷却期提高门槛MCP 调用失败工具描述不清或参数不符打印请求和返回细化 schema 和描述知识写入失败D1 绑定错误或 SQL 问题检查 wrangler.toml 绑定本地先跑通 SQL实操心得我踩过最大的坑是在 Workers 里用了 Node.js 专属的库本地wrangler dev跑得好好的一部署就报错。原因是本地模拟环境和线上运行时不完全一致。所以我的建议是任何依赖装完后先在线上环境跑一遍冒烟测试别等全部写完再部署那时候排查成本高得多。6. 这套架构还能怎么扩展company-brain 跑通之后你会发现它的骨架其实很通用——边缘计算 MCP 工具链即时通讯入口这个组合可以套到很多场景上。比如把 Slack 换成其他团队协作工具把知识库换成工单系统AI 就能主动帮你分派任务。再比如把触发源从消息换成代码提交事件AI 就能主动做代码审查摘要。我个人比较看好的一个扩展方向是多 AI 协作。现在是一个 AI 在干活未来可以是多个各有专长的 AI 分工一个负责提取信息一个负责校验准确性一个负责汇总汇报。MCP 在这里的价值会更明显因为每个 AI 都可以通过统一的协议调用同一套工具协作成本很低。另一个方向是知识库的检索增强。现在存进去的知识是死的未来可以做成 RAG检索增强生成当有人提问时AI 先从知识库里检索相关条目再结合检索结果回答。这样团队的知识就真正“活”起来了而不是躺在数据库里吃灰。最后分享一个我在实际配置中的小技巧把 AI 的行为参数全部做成环境变量比如汇报频率、冷却期时长、触发阈值。这样你不用改代码就能调优团队反馈“太吵了”你就把频率调低反馈“怎么不说话了”你就调高。这种可调性在 Agent 项目里特别重要因为 AI 的“合适行为”没有标准答案只能靠实际使用中不断校准。

基于Cloudflare Workers与MCP构建主动型Slack AI机器人实战

相关推荐

SpringBoot日志脱敏与截取：基于Logback的优雅实现方案

T3 Stack 实战：全栈类型安全从选型到部署的完整记录

t3code：从模板引擎到工程效能提升的代码生成工具实战

更多资讯

arduino-esp32 上手指南：装好核心，跑通第一个 WiFi 程序

文件上传漏洞靶场通关日记

016：AQS节点取消机制深度解析：CANCELLED状态与并发安全清理引言

不装客户端的网盘直链下载浏览器脚本怎么用？LinkSwift 快速上手与完整指南

免费开源视频下载工具 Parabolic：图形化操作，数百站点一键下载

Cindy 开发工作流实战：worktree 会话契约、DCO 门禁与 PR Review 口径

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？