1. 从一条 GitHub 热榜说起company-brain 到底想解决什么问题第一次在 GitHub 趋势榜上刷到 company-brain 这个项目我的反应是终于有人把这件事做对了。它的定位一句话就能说清在 Slack 里给团队装一个会主动干活的 AI。注意关键词是主动——不是你在频道里 它一下、它回你一段话那种被动问答机器人而是它自己盯着团队里发生的事该出手时主动出手。这个差别有多大做过团队协作工具的人都懂。传统的 Slack 机器人本质是个查询接口你问它部署状态它去调 CI 接口你问它文档在哪它去搜知识库。它永远在等你开口。但团队真正的问题往往不是我问了它不答而是我根本不知道该问什么——新同事不知道上周那个架构决策是怎么定的值班的人不知道这个报错三个月前有人踩过产品经理不知道某个需求在技术侧已经被讨论过两轮了。这些信息都散落在 Slack 的历史消息、GitHub 的 PR 评论、Notion 的文档里没人有精力去翻。company-brain 的思路是把这件事反过来让 AI 常驻在 Slack 里持续吸收团队产生的信息形成一份公司大脑然后在合适的时机主动把信息推给需要的人。它解决的不是检索问题而是信息触达问题。适合谁来参考我认为有三类人一是想给团队搭内部 AI 助手的技术负责人二是对 MCPModel Context Protocol和 Cloudflare Workers 这套现代 AI 应用架构感兴趣的开发者三是单纯想看看AI Agent 落地到真实协作场景长什么样的产品同学。热搜词里 MCP、Cloudflare Workers、AI Agent 这几个词反复出现说明大家关注的焦点已经从怎么调大模型 API转向了怎么让 AI 真正嵌进工作流。company-brain 正好是这条路线上的一个完整样本值得拆开看看。2. 整体架构拆解为什么是 Slack MCP Cloudflare Workers 这套组合2.1 三个技术选型背后的取舍逻辑先看 Slack 这个选择。团队协作工具那么多飞书、钉钉、Teams 都能做为什么偏偏是 Slack我的判断是Slack 的开放平台生态最成熟Bot 的事件订阅、消息 API、Block Kit 交互组件这套东西文档齐全、社区案例多踩坑成本最低。而且 Slack 用户群体里开发者密度高对AI 主动推送消息这种行为的接受度也更高——你换个偏行政场景的工具用户可能觉得机器人乱发消息很烦。这是选型时容易被忽略的一点技术可行性之外还要考虑用户心智。再看 MCP。这个词最近热度极高但很多人其实没搞清它是什么。MCP 全称 Model Context Protocol你可以把它理解成**AI 应用和外部工具之间的 USB-C 接口**。在没有 MCP 之前你想让 AI 读 GitHub、读数据库、读文件系统每个数据源都要写一套专门的对接代码换个模型或换个工具就得重写。MCP 把这层抽象出来了工具方按 MCP 协议暴露自己的能力叫 MCP ServerAI 应用方按 MCP 协议去调用叫 MCP Client两边解耦。company-brain 用 MCP 来接入团队的各种信息源意味着它接 GitHub、接文档系统、接内部数据库时不需要为每个源写死代码扩展性直接拉满。最后是 Cloudflare Workers。这是个 Serverless 运行时代码跑在 Cloudflare 的边缘节点上。选它的理由很实在Slack 的事件订阅需要一个公网可访问的 HTTPS 端点来接收回调而 Workers 天然提供这个还免去了自己维护服务器的麻烦。更关键的是 Workers 的冷启动极快毫秒级对于用户发消息后要立刻响应这种场景体验比传统 Serverless 好很多。加上 Workers KV 可以做轻量状态存储、Workers AI 可以直接跑推理整个接收事件—处理—调用模型—回复的链路能在一个平台内闭环。2.2 数据流是怎么跑起来的把这三个东西串起来company-brain 的数据流大致是这样团队在 Slack 频道里正常聊天、发文件、讨论 PRSlack 通过 Events API 把这些事件推送到 company-brain 部署在 Cloudflare Workers 上的端点Worker 收到事件后做初步过滤和格式化决定这条信息值不值得进大脑值得留存的信息通过 MCP Client 调用各个 MCP Server写入对应的存储向量库、KV、外部知识库当触发某个主动条件时比如有人问了相关问题、某个关键词出现、定时任务到点Worker 调用大模型结合检索到的上下文生成回复主动发到对应频道这个链路里最妙的是第 3 步和第 5 步。值不值得留存和什么时候该主动说话这两个判断才是 company-brain 区别于普通机器人的核心。普通机器人是有问必答它是该说才说。这个判断逻辑做得好不好直接决定用户会不会觉得它烦。2.3 为什么不做成纯本地部署有人可能会问团队信息这么敏感为什么不本地部署我的理解是company-brain 选择 Cloudflare Workers 这套云原生方案是在部署成本和隐私之间做了权衡。纯本地部署意味着要维护服务器、处理内网穿透、保证高可用对中小团队来说运维负担太重。而 Workers 的 Serverless 特性让部署一个 Slack 机器人这件事的门槛降到了几乎为零——fork 仓库、配置几个环境变量、一条命令部署完事。对于大多数团队来说这个便利性带来的价值超过了把数据放在云上的顾虑。当然如果团队有强合规要求这套架构的 MCP 层是可以替换成自建服务的这是它设计上的一个优点。3. 核心机制深挖一个会主动干活的 AI 是怎么炼成的3.1 信息摄入怎么判断一条消息值不值得记这是整个项目最考验功力的地方。Slack 频道里每天产生的消息90% 是好的收到中午吃啥这种噪音如果全量存进大脑检索质量会被稀释得一塌糊涂。company-brain 的做法我推测是多级过滤第一级是来源过滤。不是所有频道都值得监听通常只监听技术讨论频道、决策频道、值班频道。这个配置一般放在环境变量或配置文件里让团队自己决定。第二级是内容过滤。通过规则先筛掉明显无意义的短消息、纯表情、纯链接。这一步用正则和长度阈值就能搞定成本极低。第三级是语义过滤。对剩下的消息调用一次轻量模型判断这条信息是否包含可复用的知识。比如这个 bug 是因为缓存 key 没加租户 ID 导致的就是高价值信息这个 bug 我看看就是低价值信息。这一步是成本大头所以通常会做批处理或者用更便宜的模型。实操心得语义过滤这一步千万别用最贵的模型。我见过有人用顶级模型逐条判断每条 Slack 消息一个月账单直接爆炸。用便宜的小模型做初筛只把疑似高价值的交给大模型精处理成本能降一个数量级。3.2 主动触发什么时候该开口说话主动这个词说起来容易做起来极难。做过头就是骚扰做不够就是没用。company-brain 的触发机制我梳理下来大概有这么几类事件驱动触发当 Slack 里出现某个模式时触发。比如有人发了报错日志系统检索历史发现类似问题解决过就主动把解决方案贴出来。或者有人 了某个已经离职的同事系统提示这个模块现在由 XX 负责。定时触发比如每天早上把昨天频道里的关键决策汇总成一条 digest 发出来或者每周五把本周的技术讨论整理成周报。关联触发当 GitHub 上有 PR 合并、issue 关闭时如果这个改动和 Slack 里讨论过的某个话题相关主动在对应频道同步。这里的关键设计是**静默阈值**。系统内部可以判断出 100 条值得说的信息但真正推给用户的可能只有 5 条。这个阈值怎么定我的经验是宁可少说不可多说。用户对机器人漏说了一条的容忍度远高于机器人天天发废话。所以初期阈值要设得保守根据用户反馈慢慢调。3.3 MCP 层让大脑能接各种信息源MCP 在这里扮演的角色是让 company-brain 的大脑不局限于 Slack 内部信息。团队的知识散落在各处GitHub 的代码和 PR、Notion 的文档、Jira 的任务、内部的 Wiki。如果每个源都写死对接代码维护成本会随着源的数量线性增长。用 MCP 之后每个信息源只要有一个对应的 MCP Servercompany-brain 作为 MCP Client 就能统一调用。热搜词里出现的 playwright mcp、ida mcp、java rest 接口快速转为 mcp 接口 这些其实都反映了同一个趋势越来越多的工具在把自己包装成 MCP Server让 AI 应用能即插即用地接入。对 company-brain 来说这意味着它的能力边界是可以持续扩展的。今天接 Slack 和 GitHub明天想接内部工单系统只要写一个 MCP Server 就行主逻辑不用动。这种架构上的可扩展性是它比一次性写死的机器人更有生命力的地方。3.4 存储与检索向量库还是关键词公司大脑要能被检索存储方案的选择很关键。纯关键词检索的问题是用户问上次那个登录超时的问题怎么解决的而历史消息里写的是auth token 过期导致 401关键词对不上就检索不到。所以向量检索几乎是必须的。但纯向量检索也有问题它对精确匹配不友好。用户搜一个具体的错误码 ERR_5023向量检索可能给你返回一堆语义相近但错误码不同的结果。所以实践中通常是混合检索向量检索负责语义召回关键词检索负责精确召回两路结果合并后重排。company-brain 具体用哪种向量库从项目定位看大概率是接 Cloudflare 自家的 Vectorize或者通过 MCP 接外部向量库。选 Cloudflare Vectorize 的好处是和 Workers 同平台调用延迟低、配置简单缺点是生态相对年轻。如果团队已经有 Pinecone、Weaviate 这类成熟向量库通过 MCP 接进来也是合理选择。4. 实操落地从零把 company-brain 跑起来4.1 前置准备清单动手之前先把这些东西备齐不然中途会反复卡壳准备项说明注意事项Slack 工作区需要管理员权限创建 App 需要权限普通成员做不了Cloudflare 账号用于部署 Workers免费额度对中小团队够用大模型 API Key用于语义处理和生成建议准备两个一个便宜一个强GitHub 账号用于 fork 仓库和接 GitHub 信息源如果要接私有仓库需要额外授权Node.js 环境本地开发和部署用建议 18 以上版本4.2 Slack App 的创建与权限配置这一步是新手最容易翻车的地方。Slack App 的权限模型比较细配错了要么机器人收不到消息要么发不出消息。创建 App 的流程是进 Slack API 后台Create New App选 From scratch填名字和要安装的工作区。创建完之后重点配三块OAuth 权限Bot Token Scopes至少需要这些channels:history读取公开频道消息channels:read获取频道列表chat:write发送消息users:read读取用户信息files:read读取文件如果要处理文件Event Subscriptions把要监听的事件勾上通常是message.channels、app_mention这些。Request URL 先填个占位等 Workers 部署完再回来改。安装到工作区拿到 Bot User OAuth Token这个 token 后面要配到环境变量里。注意Slack 的事件订阅 URL 验证要求你的端点能在 3 秒内返回 challenge 值。Workers 冷启动快这个要求轻松满足但如果你用传统服务器冷启动慢的话这里会验证失败。4.3 Cloudflare Workers 的部署部署这块company-brain 这类项目一般会提供 Wrangler 配置。核心步骤# 安装 Wrangler CLI npm install -g wrangler # 登录 Cloudflare wrangler login # 克隆项目 git clone company-brain 仓库地址 cd company-brain # 配置环境变量在 wrangler.toml 或通过 secrets wrangler secret put SLACK_BOT_TOKEN wrangler secret put SLACK_SIGNING_SECRET wrangler secret put OPENAI_API_KEY # 部署 wrangler deploy部署完会拿到一个https://xxx.workers.dev的地址把这个地址加上/slack/events之类的路径填回 Slack 的 Event Subscriptions 里Slack 会发一个验证请求过来验证通过就通了。环境变量的管理有个坑敏感信息token、key一定要用wrangler secret存不要写在wrangler.toml里提交到仓库。我见过有人把 API Key 直接写配置文件里推到公开仓库第二天就被人刷爆了额度。4.4 MCP Server 的接入配置如果要接 GitHub 信息源需要配置对应的 MCP Server。通常是在配置文件里声明{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_PERSONAL_ACCESS_TOKEN: your_token } } } }这里的关键是GitHub Token 的权限范围。如果只读公开仓库public_repo就够如果要读私有仓库的 PR 和 issue需要repo权限。权限给大了有安全风险给小了功能不全按需配置。4.5 参数调优让机器人聪明起来部署完只是开始真正决定体验的是参数调优。几个关键参数语义过滤的置信度阈值。太低会把噪音存进去太高会漏掉有价值信息。建议从 0.7 开始观察一周后调整。主动推送的频率上限。给每个频道设一个每小时最多主动发言 N 次的限制防止刷屏。初期建议 N2。上下文窗口大小。生成回复时带多少历史上下文。带太多成本高且容易跑题带太少信息不足。一般 3-5 条相关消息比较合适。检索返回条数。向量检索返回 top-kk 太大会引入噪音太小会漏。建议 k5 起步配合重排。5. 踩坑实录那些文档里不会写的问题5.1 Slack 消息重复推送这是最常见的坑。Slack 的事件订阅有重试机制如果你的端点处理慢了或者返回了非 200Slack 会重发同一个事件。如果不做去重机器人就会对同一条消息处理两次甚至回复两次。解决办法是用事件的event_id做幂等。在 Workers KV 里存一个短期记录处理前先查这个 id 有没有处理过处理过就直接返回 200。KV 的 TTL 设个几分钟就够因为 Slack 的重试窗口不会太长。5.2 大模型调用超时Slack 要求事件处理在 3 秒内响应但大模型调用动辄好几秒。如果同步处理必然超时然后触发 Slack 重试形成恶性循环。正确做法是异步处理收到事件后立刻返回 200把实际处理逻辑丢到后台Workers 可以用waitUntil或者队列。处理完再通过chat.postMessage主动发消息。这个模式是所有 Slack 机器人的标配新手一定要记住。5.3 检索质量差上线初期最常见的问题是机器人答非所问。原因通常是检索环节出了问题。排查思路现象可能原因排查方法检索不到相关内容信息没存进去查存储里有没有对应数据检索到但答非所问向量质量差换 embedding 模型试试检索到但排序不对缺重排加一层 rerank答非所问且自信上下文太长跑题缩短上下文加约束提示词5.4 成本失控AI 应用最容易失控的就是成本。company-brain 涉及多次模型调用过滤、检索、生成如果不加控制账单会很难看。几个控制手段语义过滤用便宜模型只在必要时用贵模型对相同或相似的问题做缓存避免重复调用设置每日调用上限超了降级处理监控 token 消耗设告警实操心得我建议上线第一周每天看一次账单摸清消耗规律。很多团队是月底收到账单才发现超支那时候已经晚了。5.5 用户觉得机器人烦这是产品层面的坑但比技术坑更致命。机器人再聪明如果天天发没用的消息用户会直接把它静音那这个项目就废了。我的经验是上线初期让机器人少说话。先只做被动响应观察用户都在问什么摸清高频需求后再针对性地开放主动推送。而且主动推送要提供这条有用/没用的反馈按钮用反馈数据持续优化触发策略。让用户参与调教比你自己拍脑袋定规则靠谱得多。6. 这套架构还能怎么扩展company-brain 的价值不只是一个 Slack 机器人它展示的是一套**AI 常驻协作场景的通用架构**事件接入层Slack/其他工具 处理层Cloudflare Workers 能力层MCP 智能层大模型 存储层向量库/KV。这套架构可以迁移到很多场景。比如把它接到飞书或钉钉逻辑几乎不用改只换事件接入层。比如把 MCP Server 换成内部的工单系统、监控系统机器人就能回答这个告警历史上出现过几次、怎么处理的。再比如把主动触发从回答问题扩展到发现风险——监控到某个服务的错误率上升主动在值班频道预警并附上历史处理方案。热搜词里 多 AI 协作、AI Agent 这些概念其实都能在这套架构上找到落点。单个 company-brain 是一个 Agent多个 Agent 各管一块一个管代码、一个管文档、一个管运维通过 MCP 互相调用就是一个多 Agent 协作系统。这条路还很长但 company-brain 给了一个很扎实的起点。我个人在实际折腾这类项目时的体会是技术选型上别追求最新最炫要追求最省心。Slack Workers MCP 这套组合单看每个都不是最前沿的但组合起来部署成本低、扩展性好、维护负担小这才是能长期跑下去的关键。很多团队做内部 AI 工具失败不是技术不行是维护成本太高做着做着就没人管了。选一套自己能 hold 住的架构比选一套理论上最强的架构重要得多。
