Slack+Cloudflare Workers+MCP：构建主动式AI Agent实战

1. 从一条 GitHub 热榜说起：company-brain 到底想解决什么问题

第一次在 GitHub 趋势榜上刷到company-brain这个项目时，我的第一反应是：终于有人把“AI 主动干活”这件事从演示视频里拽出来，塞进了团队每天真正在用的工具里。它的定位很直白——在 Slack 里给团队装一个会主动干活的 AI。注意关键词是“主动”，不是那种你问一句它答一句的问答机器人，而是能感知团队上下文、自己判断该不该出手、然后真的把活干完的角色。

我见过太多团队把 AI 助手接进聊天工具，最后都变成了一个“高级搜索框”：大家新鲜三天，之后就没人 @ 它了。原因很简单，被动响应的 AI 本质上还是个工具，你得先想到它、再组织语言、再等它回复，这个链路比直接问同事还长。company-brain 想打破的就是这个链路——它要做的不是“你来找我”，而是“我发现这事该我管，我就上了”。

这个项目适合谁来研究？我认为有三类人值得花时间：一是中小团队的技术负责人，想用极低成本给团队加一个“虚拟运营/虚拟助理”；二是做 AI Agent 方向的开发者，想看看一个真实可用的主动式 Agent 是怎么设计的；三是任何对MCP、Cloudflare Workers这套组合感兴趣、想找个完整案例上手的人。它不是一个玩具 demo，而是一个把“感知—决策—执行—反馈”闭环跑通的最小可用系统。

在展开细节之前，先把它的核心骨架说清楚：Slack 负责交互入口和事件来源，Cloudflare Workers 负责常驻运行和调度，MCP 负责把外部能力（比如查数据、调工具）标准化地接进来，AI 模型负责判断和生成。这四块拼在一起，才构成了“会主动干活”这件事的技术底座。下面我按自己的理解，把这个项目从设计思路到落地细节完整拆一遍。

2. 整体设计思路拆解：为什么是 Slack + Workers + MCP 这套组合

2.1 为什么入口选 Slack 而不是自建网页

很多人做 AI 助手的第一反应是做个网页或者做个独立 App，但 company-brain 把入口放在 Slack，这个选择背后有很实在的考量。团队每天的沟通、决策、任务分配本来就发生在 Slack 里，信息密度最高的地方就是这里。你把 AI 放在 Slack，等于让它直接站在信息流的旁边，不需要用户切换上下文，也不需要额外培养使用习惯。

更关键的是，Slack 提供了完整的事件订阅机制。消息发出、频道创建、表情回应、成员加入，这些都能变成 AI 的“感知信号”。一个主动式 Agent 最怕的就是“看不见”，而 Slack 的事件流天然就是它的眼睛和耳朵。相比之下，自建网页只能被动等用户输入，感知能力几乎为零。

提示：如果你的团队不用 Slack，这个项目的思路完全可以平移到其他支持事件订阅的协作工具上，核心逻辑不变，只是适配层要重写。

2.2 Cloudflare Workers 在这里扮演什么角色

主动式 AI 和被动式 AI 最大的工程差异在于：主动式需要一个“一直在场”的运行环境。它得定时醒来看看有没有事、得随时响应 Slack 推过来的事件、还得在需要的时候调用外部工具。传统做法是租一台服务器跑个常驻进程，但这对小团队来说既贵又麻烦。

Cloudflare Workers 的优势在这里体现得很明显：它是事件驱动的无服务器环境，有请求就执行，没请求就不占资源，冷启动又快。配合 Cron Triggers 做定时任务，配合 Durable Objects 做状态保持，一个“轻量常驻 Agent”就成型了。成本上，小团队的日常用量基本落在免费额度或极低付费区间，这对一个内部工具来说太重要了。

我实测下来的感受是，Workers 特别适合这种“低频但要求随时在线”的场景。你不需要为它维护服务器、打补丁、盯监控，写完部署上去就不用管了，这对没有专职运维的团队是刚需。

2.3 MCP 为什么是这套方案的关键拼图

MCP（Model Context Protocol）是这两年 AI 工程领域最值得关注的东西之一。简单说，它是一套让 AI 模型和外部工具、数据源之间标准化对话的协议。在没有 MCP 之前，你每接一个工具就要写一套适配代码，接十个工具就是十套，维护成本爆炸。有了 MCP，工具方按协议暴露能力，AI 方按协议调用，双方解耦。

company-brain 用 MCP 来接入各种能力：查项目进度、读文档、发通知、更新表格等等。这意味着它的能力边界是可以随时扩展的——今天接一个查数据的 MCP Server，明天接一个发邮件的，AI 能干的活就变多了，而核心代码几乎不用动。这种可扩展性对一个要长期演进的团队工具来说，价值极高。

2.4 “主动”这两个字的技术含义

很多人以为“主动”就是加个定时任务，其实远不止。真正的主动包含三层：第一层是感知，能持续接收 Slack 的事件和定时轮询的结果；第二层是判断，用 AI 判断当前信息是否触发了某个该执行的动作；第三层是执行与反馈，干完活之后把结果同步回 Slack，并且记录状态避免重复执行。

这三层里最难的是第二层。判断“该不该出手”需要给 AI 足够的上下文和清晰的规则，否则它要么什么都不做，要么乱做。company-brain 的做法是把判断逻辑和上下文一起喂给模型，让模型输出结构化的决策结果，再由代码去执行。这个“模型决策 + 代码执行”的分工，是它稳定的关键。

3. 核心细节解析与实操要点：把每个模块拆开看

3.1 Slack App 的配置要点与权限设计

要让 AI 在 Slack 里干活，第一步是创建一个 Slack App。这里有几个容易踩坑的地方。权限（Scopes）一定要按最小必要原则申请，常用的包括读取消息、发送消息、读取频道列表、读取用户信息。权限申请多了审核麻烦，申请少了功能跑不起来，建议先列清楚 AI 要干的活，再反推需要哪些权限。

事件订阅（Event Subscriptions）是主动感知的核心。你需要把 Slack 的事件推送到 Cloudflare Workers 的某个 URL 上。这里要注意 Slack 的 URL 验证机制：它会在配置时发一个 challenge 请求，你的 Worker 必须正确响应才能通过验证。很多人卡在这一步，其实只要按官方文档把 challenge 原样返回就行。

注意：Slack 的事件推送有重试机制，如果你的 Worker 处理超时或报错，Slack 会重复推送同一条事件。所以你的处理逻辑必须做幂等，否则 AI 可能对同一条消息重复干活。

3.2 Cloudflare Workers 的部署与定时任务配置

Workers 的部署现在很顺滑，用 Wrangler CLI 几条命令就能搞定。核心是wrangler.toml这个配置文件，里面要写清楚入口文件、环境变量、以及 Cron Triggers。环境变量里放 Slack 的 Token、AI 模型的 API Key 这些敏感信息，千万别硬编码在代码里。

定时任务是主动性的来源之一。比如你可以配置每 30 分钟跑一次，让 AI 去检查有没有逾期任务、有没有需要提醒的事项。Cron 表达式按需配置，但要注意 Workers 的免费额度对执行次数有限制，别把频率设得太高。

name = "company-brain" main = "src/index.js" compatibility_date = "2024-01-01" [triggers] crons = ["*/30 * * * *"] [vars] SLACK_BOT_TOKEN = "xoxb-..."

上面这个配置的意思是每 30 分钟触发一次。实际用的时候，我建议先从低频开始，观察 AI 的判断质量，稳定了再考虑提高频率。

3.3 MCP Server 的接入方式与工具注册

MCP 的接入是这套方案里技术含量最高的部分。你需要一个 MCP Server 来暴露团队内部的能力。比如一个“查项目状态”的工具，输入项目名，输出当前进度。MCP Server 可以用任意语言写，只要遵循协议规范。

接入的时候，Worker 作为 MCP Client 去连接 Server，把可用的工具列表拉过来，然后在需要的时候调用。这里的关键是工具描述要写清楚，因为 AI 是靠描述来判断该不该用这个工具的。描述模糊，AI 就会乱用或者不用。

这张表是我根据常见实践整理的，实际项目里工具会更多。每加一个工具，AI 的能力就扩展一分，但也要注意别加太多导致判断混乱。

3.4 AI 决策层的提示词设计

提示词是主动式 Agent 的大脑。company-brain 的提示词需要包含几块内容：角色设定（你是团队的助理）、当前上下文（最近的 Slack 消息、定时任务的结果）、可用工具列表、以及输出格式要求。输出格式一定要结构化，比如要求模型返回 JSON，包含“是否执行动作”“执行哪个工具”“参数是什么”。

我试过用自然语言让模型直接输出动作，结果很不稳定，有时候它会在回复里夹带解释，导致解析失败。改成强制 JSON 输出之后，稳定性提升非常明显。这是实操中非常值得记住的一点：凡是需要代码解析的模型输出，一律用结构化格式。

4. 实操过程与核心环节实现：从零跑通一个主动 Agent

4.1 环境准备与依赖安装

先把基础环境搭起来。你需要 Node.js 环境、Wrangler CLI、一个 Slack 工作区的管理员权限、一个 Cloudflare 账号，以及一个可用的 AI 模型 API。依赖装好之后，初始化项目结构，大致分成入口文件、Slack 处理模块、MCP 客户端模块、AI 决策模块四块。

npm install -g wrangler wrangler login npm init -y npm install @slack/web-api @modelcontextprotocol/sdk

装依赖的时候注意版本兼容，MCP 的 SDK 更新比较快，建议锁定一个稳定版本，别用 latest 免得踩到 breaking change。

4.2 Slack 事件接收与验证实现

Worker 的入口要处理两类请求：一类是 Slack 的事件推送，一类是定时任务触发。事件推送进来之后，先做签名验证，确认请求确实来自 Slack，这是安全底线。验证通过后，解析事件内容，判断是消息事件还是其他类型，然后交给对应的处理逻辑。

export default { async fetch(request, env, ctx) { const body = await request.text(); // 验证 Slack 签名 if (!verifySlackSignature(request, body, env.SLACK_SIGNING_SECRET)) { return new Response("Unauthorized", { status: 401 }); } const event = JSON.parse(body); if (event.type === "url_verification") { return new Response(event.challenge); } ctx.waitUntil(handleEvent(event, env)); return new Response("OK"); } };

这里用ctx.waitUntil是为了让 Worker 先快速返回 200 给 Slack，避免超时重试，实际处理逻辑放到后台跑。这个技巧在处理耗时任务时非常关键。

4.3 定时巡检任务的实现

定时任务通过scheduled事件触发。逻辑是：醒来之后，调用 MCP 工具拉取需要关注的信息，比如逾期任务，然后把这些信息连同判断规则一起喂给 AI，让 AI 决定要不要发提醒、发给谁、说什么。

async scheduled(event, env, ctx) { const overdueTasks = await mcpClient.call("list_overdue_tasks", {}); if (overdueTasks.length === 0) return; const decision = await aiDecide(overdueTasks, env); if (decision.shouldAct) { await slackClient.chat.postMessage({ channel: decision.channel, text: decision.message }); } }

这段逻辑里，aiDecide是核心。它把任务列表和规则交给模型，模型返回是否行动、行动内容。我实测下来，给模型明确的判断标准（比如“逾期超过一天且负责人未请假”）比让它自由发挥要稳得多。

4.4 主动响应的完整链路演示

举个具体场景：团队在 Slack 里讨论某个功能延期，AI 感知到这条消息，判断这涉及项目进度，于是调用get_project_status工具查到实际进度，发现确实延期了，于是主动在频道里发一条消息，附上当前进度和建议的调整方案。

这个链路走下来，用户什么都没问，AI 就把信息补齐了。这就是“主动干活”的价值。实现上，它依赖事件感知、工具调用、AI 判断、消息发送四个环节的顺畅衔接。任何一个环节卡住，体验都会断掉。

提示：第一次跑通链路时，建议把 AI 的动作先发到一个测试频道，人工确认判断质量，稳定后再放开到正式频道。

5. 常见问题与排查技巧实录

5.1 Slack 事件收不到怎么办

这是最常见的问题。排查顺序是：先看 Slack App 的事件订阅 URL 是否验证通过，再看 Worker 的日志有没有收到请求，最后看签名验证是否通过。我遇到过好几次是签名验证的密钥配错了，导致所有请求都被拒。还有一个坑是 Worker 返回超时，Slack 认为推送失败，这时候要检查处理逻辑是不是同步执行了耗时操作。

5.2 AI 判断不稳定怎么调

判断不稳定通常有三个原因：提示词不够明确、上下文给得不够、工具描述太模糊。我的经验是，先把判断规则写成明确的条目，再给足上下文，最后把工具描述改成人话。如果还是不稳，就降低主动性，从“只在明确触发条件下行动”开始，逐步放开。

5.3 MCP 工具调用失败排查

MCP 调用失败先看连接是否正常，再看工具名和参数是否匹配。常见错误是参数类型不对，比如该传字符串传了数字。另外要注意超时设置，外部工具响应慢的时候要设合理的超时，避免 Worker 卡死。

5.4 成本控制的实操心得

Workers 和 AI 模型都是按量计费的，小团队要控制成本。我的做法是：定时任务频率别太高，AI 调用做缓存，相同输入短时间内不重复调用模型。另外，把简单的判断逻辑用代码实现，只把真正需要理解语义的部分交给模型，这样能省下大量调用。

6. 这套方案还能怎么扩展

跑通基础版本之后，扩展空间很大。比如接入更多 MCP 工具，让 AI 能操作项目管理工具、能查代码仓库状态、能发邮件。再比如增加多轮记忆，让 AI 记住之前的判断结果，避免重复提醒。还可以做权限分级，不同频道的 AI 能力不一样。

我个人觉得最有价值的扩展方向是“判断逻辑的可配置化”。把判断规则从代码里抽出来，做成配置文件，团队可以自己调整 AI 什么时候该出手。这样非技术人员也能参与调优，AI 的行为会越来越贴合团队的实际需求。

最后分享一个小技巧：给 AI 的每条主动消息都加一个“为什么发这条”的简短说明，比如“检测到任务逾期”。这样团队成员能理解 AI 的判断依据，信任感建立得快，也不会觉得被莫名其妙打扰。这个细节看起来小，但对一个主动式 Agent 能不能被团队接受，影响很大。