早上到工位先被群里 30 条未读消息淹没一个简单的运维问题 了三个人没人回用户问的文档链接其实就在置顶里。如果你也在团队协作工具里经历过这种低效循环那今天在 GitHub 上刷到的这个项目——company-brain应该会让你眼前一亮。简单说它就是一个能跑在 Slack 里的 AI Agent 底座不只是等你提问才回答的聊天机器人而是会主动监听频道、提炼上下文、把重复事务处理掉、把该找人做的事分配出去的“数字同事”。这篇文章就来拆一拆它的设计思路、部署细节以及我在折腾类似主动式工作区 AI 时踩过的坑。适合团队负责人、DevOps、后端开发者以及对 AI Agent 落地感兴趣的读者。1. 为什么需要“会主动干活”的 AI而不是只会回答的机器人1.1 客服机器人式交互的真正局限过去我们把“AI 放进工作群”想得太简单了。最常见的做法是接一个支持 mention 的聊天机器人关键词命中或被人 的时候才回复。这种模式本质上是把 AI 当成了一个“有问必答”的搜索引擎它不会主动发现问题更不会自己去完成任务。你问它“昨天线上那个 500 错误是什么原因”它能回答但如果没人问它就永远沉默即便告警已经在群里刷了几十行。这是被动式机器人的核心问题它依赖人类发起指令而团队协作的低效恰恰在于“很多人不知道应该问什么”或者“小问题不值得专门提问”。一个能主动看群、主动总结、主动推进事项的 AI解决的是“信息有人看、事情有人接”的问题这才是协作场景里真正有价值的部分。我接触到 company-brain 这个项目时最打动我的就是它的定位它不是一个 Chatbot而是一个 Brain——大脑。它看的是整个 Slack 工作区的消息流而不是单条指令。这和我之前折腾过的一些“关键词机器人”完全不是一回事。如果你只是想要一个会答话的机器人那选择太多了但如果你想给团队装一个“会自动干活的同事”需要的就是这种主动式的架构。1.2 company-brain 的整体思路把 Slack 当成大脑的操作系统你可以把 Slack 理解成团队日常的“操作系统”所有沟通、告警、决策、文件流转都在这里发生。company-brain 的切入点很聪明——它不去做一个独立的应用而是直接驻留在 Slack 这个操作系统内部成为其中的一个常驻进程。它的工作方式可以概括为一句话通过 Slack 的实时事件接口持续接收频道里的消息流把有趣的内容转成任务分发给不同的专业化子 Agent 去处理最后再把结果以一条自然消息的形态贴回频道。也就是说AI 不是被“召唤”出来的而是始终在线的。它会注意到有人连发了三条“测试环境挂了”然后主动去翻日志、查状态、把可能的原因贴在下面而不是等着有人问“谁能看一下”。这个设计背后有一个很实际的考量团队里真正重要的信息大多不会通过工单系统完整录入而是散落在闲聊、告警、会议纪要里。过去我们靠一个人手动把这些信息串起来现在可以用 AI Agent 来做这件事。company-brain 的名字也很直白它要成为团队的“记忆中枢”和“任务分发中枢”而不是一个回答机。2. 项目核心设计拆解大脑如何与团队协作2.1 五层核心循环监听、理解、规划、执行、反馈我在看这个项目的 README 时发现它的核心逻辑其实可以拆成一条非常清晰的循环链路理解这条链路基本就理解了整个项目的设计哲学。监听通过 Slack 的 Events API 订阅消息事件拿到频道的实时动态。理解用大模型判断这条消息里有没有值得处理的信息是问题、是告警、是任务、还是普通闲聊。规划如果值得处理把目标拆成可执行的小步骤比如“先查订单服务状态再确认最近的发布记录”。执行调用已配置的工具去完成步骤比如请求内部 API、查数据库、创建 GitHub Issue。反馈把执行结果整理成简洁的人类可读消息发回原本的频道必要时 相关人员。这个循环看起来简单但它把“主动”这个能力落得很实。以“理解”为例不是所有消息都需要 AI 介入。如果频道正在闲聊午餐吃什么AI 插嘴会非常烦人。所以这里实际上有一个分层过滤器事件先经过轻量规则和关键词筛选再交给大模型做语义判断最后才进入任务队列。我自己的经验是这一层的过滤逻辑越保守用户对 AI 的接受度就越高。2.2 多 Agent 协作不是多个机器人而是角色分工“多 AI 协作”这个词最近很热但很多人理解有偏差。有人以为多 Agent 就是在 Slack 里拉一群机器人互相聊天那没有意义。company-brain 采取的方式更像是公司内部的项目组一个 Orchestrator协调者负责拆解任务、分配合适的角色各个 Agent 之间不直接对话而是通过共享的上下文和工具结果来衔接。举个例子当群里出现一条“支付接口超时”的告警时协调者会把任务交给告警分析 Agent它负责从历史消息里找出最近相关的变更再去问数据库查询 Agent 拿接口最近的成功率最后由执行 Agent 在 Jira 里创建一个带上文背景的 Bug 任务。每个 Agent 只做自己专业的事但它们分享同一份任务上下文。这个设计避免了多 Agent 系统最常见的灾难——上下文丢失和消息风暴。站在实现者的角度这种架构还有一个额外的好处方便裁剪。如果你只需要“告警自动建单”一个功能那完全可以只保留告警分析 Agent 和执行 Agent其余的全部关掉。项目的主干是协调器枝叶是各种专业 Agent这种插件式的角色组织方式让团队可以按自己的节奏逐步引入能力而不是一次性接一个庞然大物。2.3 与常用工具链的集成别让 AI 只会聊天一个只会聊天的 AI 没有价值真正的价值在于它能动手操作工具。company-brain 在工具集成上做了不少工作常见的内置集成包括 GitHub查看 Issue、创建 PR 评论、检查 Actions 状态、Jira 和 Linear任务创建与状态流转、Notion查找文档、汇总记录、日历会议提醒、纪要整理以及简单的数据库查询和内部 API 调用。这里我要多说一句这些集成本身并不神秘本质上是给大模型提供了“函数调用”的能力难点在于如何保证 AI 在调用工具时不会乱来。项目采用的方式是给每个工具一个严谨的描述让模型根据描述决定何时调用同时在工具层做参数校验和操作确认。比如“创建 Issue”这类有副作用的操作在默认配置下会要求先输出一个预览只有频道里有人明确确认后才会真正执行。我在自己搭类似系统时也有同样的感受工具本身好不好用先放一边“让 AI 在什么条件下可以用工具”才是真正的设计重点。很多翻车事故都源于模型拿到了过于宽松的操作权限。2.4 权限与安全边界AI 不是万能钥匙把 AI 接进工作区最让人担心的是安全问题它会不会看到不该看的消息会不会误删数据会不会在凌晨三点给全公司发通知这些担忧完全合理。company-brain 在权限设计上做了一些值得借鉴的处理我总结下来是四个原则。第一最小权限。Bot 的 Token 只授予它真正需要的权限范围比如只读特定频道的消息、只能发消息到指定频道、不能删除和编辑其他人消息。第二白名单机制。可以配置只有特定用户或角色能触发某些高风险操作。第三操作分级。把动作分成“无副作用”和“有副作用”两类前者可以自动执行后者需要人工确认。第四审计日志。每次 AI 执行的操作都会记录下来包括调用了什么工具、输入输出是什么、由谁确认的。这四条原则说起来容易做起来麻烦但它们是团队愿意长期使用 AI 的前提。没有人会信任一个黑盒尤其是这个黑盒还会自作主张。我看到不少人在评论区问“这项目安全吗”我的回答是安全与否不取决于项目本身而取决于你怎么配置它。默认配置永远只给你开一条小路别一上来就给它万能钥匙。3. 部署实操用 Docker 在自己的工作区跑起来3.1 前置准备创建 Slack App 并获取 Token部署 company-brain 的第一步是在 Slack 的开放平台上创建一个属于你自己的 App。这个过程本身不复杂但有几个关键选项不能选错。这里我按我实测过的路径给你捋一遍。首先要打开 api.slack.com/apps点击 Create New App选择 From App Manifest 方式。用 Manifest 的好处是只需要粘贴一段 YAML 配置就能一次性把权限范围、事件订阅都定义好不需要在网页里一个个勾选。Manifest 里需要写明 bot 的权限范围。以我的部署经验至少要包含这几个 scopechannels:history读取公开频道历史、chat:write以 Bot 身份发言、users:read获取用户信息、reactions:write如果需要添加回应的话。如果你打算让 AI 处理私聊还需要 im:history 和 im:write。创建完成后进入 App 的安装界面把 App 安装到工作区。安装成功后你能拿到一个 Bot User OAuth Token字符串以 xoxb- 开头。这个 Token 相当于是 AI 的“工作证”公司-brain 就是靠它来读取和发送消息。另外如果你打算用 Socket Mode 连接我强烈建议还需要在 App 设置里开启 Socket Mode并记下 App-Level Token以 xapp- 开头这个细节特别容易漏掉。3.2 配置环境变量把 API Key 和 Token 填进 .env拿到 Token 之后下一步就是配置环境变量。这个项目的配置思路和大多数 Docker 部署项目一致在项目根目录复制一份 .env.example 成 .env然后逐项填写。我写上几个核心变量以及它们的作用。SLACK_BOT_TOKEN前面拿到的 xoxb- 开头的 Bot TokenAI 发消息和读消息都用它。SLACK_APP_TOKENxapp- 开头的 App-Level Token用于 Socket Mode 连接。LLM_API_KEY你选择的大模型服务的 API Key。现在大部分项目都兼容 OpenAI 接口格式如果你用别的服务商记得同时修改 LLM_BASE_URL。LLM_MODEL模型名称。默认可能是 gpt-4o 之类的通用模型但你可以换成便宜一些的模型来降低成本比如处理简单过滤用快模型处理复杂任务用强模型。ALLOWED_CHANNELS允许 AI 监听的频道白名单。强烈建议一开始只填一两个测试频道别一上来就全局开放。WORK_HOURS_START / WORK_HOURS_ENDAI 主动发言的时间段限制避免半夜被它。在填这些变量时我踩过的第一个坑是 Token 的权限不够却不自知。Slack 的错误提示往往很隐晦日志里只会报“缺少响应”或“权限不足”。所以配置完 Token 后建议先用 curl 调一下 Slack API 的 auth.test 接口确认 Token 是有效的再启动项目。3.3 Docker Compose 一键启动省去环境依赖烦恼项目提供了现成的 Dockerfile 和 docker-compose.yml这是我推荐普通团队使用的方式。向量数据库如果需要记忆功能的话会作为依赖服务一并启动。配置文件类似下面这样里面加了注释方便理解services: company-brain: build: . env_file: .env restart: unless-stopped depends_on: - memory-db memory-db: image: qdrant/qdrant volumes: - ./qdrant_storage:/qdrant/storage启动只需要两条命令先执行 docker compose build 构建镜像然后 docker compose up -d 后台启动。启动后查看日志docker compose logs -f如果能见到类似 “Socket Mode connected” 或 “Bot is running” 的输出说明连接成功了。有一点务必注意如果你使用 Socket Mode就不需要把服务暴露到公网也不需要配置回调地址和内网穿透。这是很多人绕远路的地方。Slack 的 Socket Mode 是让 Slack 主动通过 WebSocket 与你的本地客户端建立连接所有事件都会推送到本地因此非常适合部署在企业内网或个人电脑上省去了一堆网络配置的麻烦也安全得多。3.4 验证部署让它开口说第一句话部署成功后的第一件事不是立刻让它干活而是先做一次最基础的“对话测试”。打开你允许的测试频道发一条“hello”或者直接 一下机器人看它是否能正常响应。如果它回复了恭喜你核心链路是通的。接下来可以测试主动监听能力。你可以故意在频道里发一条类似“有人知道昨天部署到生产环境了吗”的消息如果是配置正常的状态它会尝试根据工作区里的历史信息给出一个概括性的回答。这一步不需要它做得多准确重点是确认事件监听、模型调用、消息发送这三条链路都跑通了。到了这一步你会体会到“主动”和“被动”的区别它不需要被 仅仅因为频道里出现了一个话题它就尝试参与。要记得观察日志里模型到底看到了什么上下文、做出了什么判断这会帮助你理解它的行为逻辑。4. 从 0 到 1 落地让 AI 在团队里跑起来4.1 试点先行别在全员频道里开“主动模式”项目跑起来之后最诱人的举动就是把所有频道都交给它让它无处不在。我劝你忍住。主动式 AI 是有“刷屏风险”的它可能会在每个频道都对每条消息评头论足反而比人类同事更烦人。我的建议是前两周只在一到两个低频但信息密度高的频道里运行比如“技术值班群”或“告警通知群”。在这样的频道里AI 处理告警、整理故障时间线是明显有价值的即便偶尔出点错负面影响也可控。同时团队成员能看到 AI 的实际效果建立信任。等到大家习惯了它的存在再逐步放开到新频道。这个“试点”过程还有一个额外的收益你可以借此调教它的判定阈值。比如 AI 在试运行阶段常常对“看起来像问题但不是问题”的消息过度反应你可以在配置里加上多条排除规则等它在你关注的场景里足够靠谱再扩大范围。4.2 给 AI 写一份“岗位说明书”提示词模板如果说项目代码决定了 AI 能不能干活那提示词就决定了它愿不愿意“好好干活”。我强烈建议你为 company-brain 写一份“岗位说明书”明确告诉它你是谁、你应该做什么、更重要的是你不应该做什么。项目里通常会有基础的系统提示词但那是通用的你需要根据自己团队的情况定制。下面这个模板是我在实际使用中打磨过的你可以参考着改你是团队工作区中的值班助手。你的职责是 1. 主动关注频道中与故障、告警、任务相关的话题。 2. 当有人提问时先查找已有记录和文档再给出准确回答。 3. 遇到需要人工处理的事项用简洁的语言相关负责人。 4. 在你没有把握时明确说“我不确定”不要编造信息。 你需要注意 - 你的操作必须以事实为依据不要猜测。 - 不要在闲聊消息中刷存在感。 - 不讨论与工作无关的话题。 - 涉及删除、发送通知等操作前先征得确认。这套提示词的核心作用不是“让 AI 变聪明”而是“让 AI 别乱来”。很多团队部署后觉得 AI 烦人90% 的原因是提示词太开放它不知道该在什么时候闭嘴。4.3 设计触发规则什么时候 AI 应该主动插手主动不等于 AI 必须“评论一切”。理想的触发体系应该分优先级。最高优先级是显式 这是用户主动发起AI 必须响应其次是关键词命中比如“故障”“宕机”“线上异常”“谁负责”等再次是“空窗超时”比如一个告警消息发了 10 分钟没有人回应AI 才自动介入最后是定时触发比如每天早上汇总前一天的发布记录。这套优先级的设计逻辑本质上是让 AI 只在“人类处理不及时”或“明确需要帮助”的时刻出场。你可以在配置里为每一种触发条件设定单独的开关和阈值。我自己更倾向把“空窗超时”当作最重要的主动触发条件因为它既保证了响应速度又不会打扰正在交谈的团队。4.4 效果度量怎么知道 AI 真的在干活我在落地这类系统的时候会记录几个数字AI 每日处理的消息数量、其中被人类明确认可或采纳的比例、平均响应时间、被人工手动删除或纠正的次数。前两个说明它在干活后两个说明它有没有帮倒忙。你可以在 Slack 里建一个专门的“AI 日志”频道让 company-brain 每次执行完任务后把简要结果发到那里。这相当于给 AI 配了一本日记团队成员可以随时回顾它的操作。这样既增加了透明度也方便你每周复盘调整提示词和触发规则。记住AI Agent 不是设置完就不用管的它需要像带新人一样持续地给反馈、调教。5. 常见问题排查与避坑实录5.1 Bot 不响应或者收不到消息这是部署时最高频的问题。遇到 Bot 完全不响应优先从三个方向排查。第一确认 App 的事件订阅里是否已经添加了 message.channels 和 app_mention 这两个事件的订阅很多用户忘记勾选事件类型导致代码在跑但 Slack 根本没把消息推过来。第二确认 Token 是否具备对应频道的读取和写入权限尤其是私聊或私有频道。第三如果用了 Socket Mode确认日志里出现了连接成功的标识且 App-Level Token 没有过期。另外一个容易忽略的点是Bot 加入频道了吗Slack 的机制是Bot 必须在频道里才能收到消息。很多人以为创建了 App 就等于加入了所有频道实际上你得手动把 Bot 用户拉进目标频道或使用 “加入频道” 的 API。部署后盯着日志一般能很快定位问题在哪个环节。5.2 AI 答非所问甚至乱调用工具第二个大坑是 AI 的“幻觉”和“过度自信”。当模型拿不到足够上下文时它会编造一个看起来合理的答案。解决思路主要有两个方向。一个是在提示词中明确限制“如果找不到确切信息必须回答‘没有找到相关记录’”。另一个是给模型提供“工具查询优先”的流程先让它查文档、查历史消息再根据查询结果回答而不是凭训练数据里的旧知识硬编。至于乱调用工具那多半是工具描述写得过于宽泛。大模型的函数调用依赖描述如果工具描述里写了“创建任务”那模型就会倾向于把什么问题都变成任务。解决方案是把描述改得更有约束性比如“仅当用户明确要求创建 Jira 任务时调用此工具其他情况不要使用”。还可以在代码层面对工具功能做白名单直接禁用高风险操作等确认场景安全后再放开。5.3 权限失控与“半夜刷屏”主动式 AI 最大的社会性风险就是它会在不合适的时机出现。我见过一个案例AI 因为误判一条深夜告警把三个相关的同事都 了出来实际上那条告警只是波动不是故障。这就是为什么一定要配置工作时间限制、关键词过滤和人工确认机制。此外建议开启“建议模式”作为默认输出方式也就是 AI 不直接执行有影响的操作而是先发出“我建议这样做是否执行”的消息。等它在团队里有了一定的信任基础再逐步放开自动执行的开关。同时保留操作日志一旦有人投诉“这不是 AI 该管的”你可以迅速回看它当时的判断依据优化触发规则。5.4 团队落地避坑清单这里整理一份我从几次实际部署中总结出来的检查清单你可以直接抄作业。检查项常见问题解决办法Bot 没有加入频道Bot 收不到任何消息手动将 Bot 添加到目标频道事件订阅缺失消息事件不推送添加 message.channels / app_mention 订阅Token 权限不足只读不回或直接报错按最小权限补齐 scope重新安装 AppSocket Mode 未开启日志一直重连失败在 App 设置里开启 Socket Mode且用 xapp- Token提示词过于开放AI 到处蹭话、答非所问写岗位说明书明确“该做什么不该做什么”无时间限制半夜被 AI 刷屏配置工作时段时间限制主动发言窗口没有操作日志出问题无法追溯建立 AI 日志频道记录每次执行全局放开频道AI 在闲聊群里插嘴白名单频道先小范围试点再逐步放开最后分享一点实操体会我自己在部署这类工作区 AI 时最大的感触是技术难点其实不大真正难的是“让 AI 学会克制”。一个只会回答问题的机器人人们顶多觉得它没用一个到处插手、自作主张的 AI人们会真的讨厌它。所以如果你也想在公司里搭这个项目请一定先从最小的权限、最小的监听范围、最保守的触发规则开始让 AI 用实际表现来赢得团队的信任。一个小技巧分享给你部署完成后的第一件事不是测试它的高级功能而是在频道里发一条“大家好我是团队助手我会在值班群协助整理告警信息我的处理结果仅供参考最终请以人工确认为准”。这条消息看起来不重要但它能极大地降低同事对 AI 的抵触心理。等它帮忙处理过几次真实故障之后大家自然会把你口中的“这个 AI”真正当成团队的一员。