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 为什么是这套方案的关键拼图MCPModel 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 就会乱用或者不用。工具名称输入参数输出内容使用场景get_project_status项目名进度百分比、负责人被问到项目进展时list_overdue_tasks无逾期任务列表定时巡检时send_reminder用户、内容发送结果需要提醒某人时search_docs关键词相关文档片段回答知识类问题时这张表是我根据常见实践整理的实际项目里工具会更多。每加一个工具AI 的能力就扩展一分但也要注意别加太多导致判断混乱。3.4 AI 决策层的提示词设计提示词是主动式 Agent 的大脑。company-brain 的提示词需要包含几块内容角色设定你是团队的助理、当前上下文最近的 Slack 消息、定时任务的结果、可用工具列表、以及输出格式要求。输出格式一定要结构化比如要求模型返回 JSON包含“是否执行动作”“执行哪个工具”“参数是什么”。我试过用自然语言让模型直接输出动作结果很不稳定有时候它会在回复里夹带解释导致解析失败。改成强制 JSON 输出之后稳定性提升非常明显。这是实操中非常值得记住的一点凡是需要代码解析的模型输出一律用结构化格式。4. 实操过程与核心环节实现从零跑通一个主动 Agent4.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 卡死。问题现象可能原因解决方向事件收不到URL 验证失败或签名错误检查密钥和验证逻辑AI 不行动提示词模糊或上下文不足明确规则、补充上下文工具调用报错参数不匹配或超时核对参数、设置超时重复执行未做幂等处理加事件去重逻辑响应太慢同步执行耗时任务改用 waitUntil 异步5.4 成本控制的实操心得Workers 和 AI 模型都是按量计费的小团队要控制成本。我的做法是定时任务频率别太高AI 调用做缓存相同输入短时间内不重复调用模型。另外把简单的判断逻辑用代码实现只把真正需要理解语义的部分交给模型这样能省下大量调用。6. 这套方案还能怎么扩展跑通基础版本之后扩展空间很大。比如接入更多 MCP 工具让 AI 能操作项目管理工具、能查代码仓库状态、能发邮件。再比如增加多轮记忆让 AI 记住之前的判断结果避免重复提醒。还可以做权限分级不同频道的 AI 能力不一样。我个人觉得最有价值的扩展方向是“判断逻辑的可配置化”。把判断规则从代码里抽出来做成配置文件团队可以自己调整 AI 什么时候该出手。这样非技术人员也能参与调优AI 的行为会越来越贴合团队的实际需求。最后分享一个小技巧给 AI 的每条主动消息都加一个“为什么发这条”的简短说明比如“检测到任务逾期”。这样团队成员能理解 AI 的判断依据信任感建立得快也不会觉得被莫名其妙打扰。这个细节看起来小但对一个主动式 Agent 能不能被团队接受影响很大。