★ FEATURED ARTICLE 最近在 GitHub 上刷到 company-brain 这个项目第一眼就被名字吸引了——“公司大脑”。它做的事情直白点说就是给 Slack 团队装一个会自己看消息、自己判断、自己动手干活的 AI 助手而不是那种挂在频道里、非要你 一下才吐一句话的聊天机器人。我把它部署进工作区体验了两周又翻了源码和文档这篇文章就从一个使用者和工程视角拆一下 company-brain 这类“主动性 AI Agent”是怎么设计的优势在哪部署时有哪些坑以及怎么把它真正用好。不管你是想给团队引入 AI 协作工具的负责人还是最近在研究 AI Agent 落地方式的开发这篇文章都能给你一些可以直接拿去用的经验。下面进入正题。1. 为什么我会盯上 company-brainSlack AI 的现状很“被动”1.1 大多数团队里的聊天机器人只是“客服”在 Slack 里装 AI 工具这件事其实很多团队都做过了。最常见的形态是接入某个 GPT 机器人把它放到一个叫 #ai-help 的频道然后谁有问题就 它一下。它回答完问题就结束了你问一句它答一句问得模糊它就给你一段片汤话。这种模式说白了就是个“带记忆的客服”根本没进到工作流里。真正的团队协作是啥是有项目进度、有任务分派、有代码评审通知、有信息同步、有突发状况要处理。这些事发生在不同的频道、不同的 thread 里甚至发生在你没有主动提问的时候。你要的是一个能主动看到这些信息、判断“这件事需要我处理”、然后直接把活干了的 Agent而不是一个等命令的问答机。1.2 主动 Agent 和被动 Bot 的分界线在哪里我拆了几个开源项目之后发现主动和被动之间的差异其实就三条触发方式不同被动 Bot 靠 mention 或显式命令触发主动 Agent 靠监听频道内的完整信息流自己判断哪些信息值得响应。是否有目标闭环被动 Bot 回一句话就算完事主动 Agent 会把“提醒我明天开会”这类需求变成日程检查、会议邀请、提前提醒这一连串动作。有没有权限执行被动 Bot 只能输出文本主动 Agent 可以调用 API、改状态、创建任务甚至发通知。company-brain 之所以值得拿出来说就是因为它把第三点做得很重。它不满足于“给你答案”而是尝试在团队协作的环境里做出“替你执行”的动作。1.3 company-brain 瞄准的痛点团队信息流是碎片化的举个最常见的场景。早上打开 Slack你可能会看到 200 条未读有人反馈线上 Bug、有人在等一个设计图、有个线程里客户在催方案、还有人在群里问今天发布几点开始。这些信息像碎片一样散落在各个频道里没有人有精力把它们串成一张“今天真正需要处理什么”的清单。company-brain 的定位就是把这个碎片化信息流收敛起来。它监听频道里的一切动静提取出“任务”、“问题”、“承诺”、“待办”这些结构化的东西然后根据角色分工和预设规则决定哪些事情自己去跟进哪些事情该提醒对应的人哪些事情直接汇总成一份每日报告发给你。你不需要去翻几百条消息它已经把答案整理好递到你面前。这和我之前用过的一些“知识库问答机器人”相比完全是两个物种。一个是在你发问时找答案另一个是持续盯着生产过程把需要关注的信号主动捞出来。这个“主动”听起来不起眼但在团队日常里价值非常大。2. company-brain 怎么实现“主动干活”从事件到行动的链路2.1 事件监听层Slack 里的每条消息都是信号先看它最底层的一层——事件监听。Slack 平台本身提供了 Events API可以订阅各种事件类型频道消息、thread 回复、频道创建、成员加入、reaction 等等。company-brain 这类项目的根基就是把 Events API 用得很透。它通常不会只订阅message.channels这种大而全的消息事件而是会区分消息类型来做预处理。比如带有channel的消息可能是需要全体注意的通知出现在 thread 里的回复可能表示一个话题正在深入讨论带有特定关键词比如“谁有空检查下”“帮忙看看”“这个 Bug 有点严重”的消息会被判定为“潜在任务”定时任务cron job产生的事件则会被单独分流进入固定的执行链路。我在本地跑 company-brain 的时候故意在测试频道里发了三四种不同类型的消息然后看它的日志。它确实不是每条消息都触发完整 AI 链路而是先做过一遍规则过滤只有命中“值得关注”的消息才会继续往下走。这个设计非常关键因为 Slack 规模一大消息量是非常恐怖的如果每条消息都送给大模型分析一遍成本当场爆炸。2.2 意图理解与任务分解把“帮忙看一下”变成三件事消息被判定为“值得关注”之后才进入意图理解阶段。这一步通常有两个层次浅层规则 大模型兜底。浅层规则适合那些格式非常固定的请求。比如“创建任务xxx”“提醒我明天 10 点开会”“安排周五和周一的发布”这些可以直接用正则或短语模板匹配完全不需要走大模型速度快还省钱。真正考验系统的是模糊表达。比如有人发了一条“这个页面加载有点慢是不是 CDN 配置有问题有谁在负责吗”这句话没有明确指令但里面有好几个信号一个潜在问题页面慢、一个可能的方向CDN 配置、一个角色匹配谁是负责人。company-brain 的做法是把这句话丢给大模型让它做两件事第一判断这个问题到底要不要现在回应第二如果需要把这件事拆解成具体行动。我见过它的日志输出针对这句话它给出的行动是查一下 CDN 配置是否有最近的变更记录在 #infra 频道找最近有没有相关讨论如果都没有就生成一条待办并 对应的负责人。你看这就是“主动干活”和“被动回答”的区别。普通的 Bot 会直接回你一段“建议检查 CDN 配置”但 company-brain 会把这个事情当成一个任务推进下去直到找到负责人或者确认没关系。2.3 工具调用层给 AI 装上公司的“数字手脚”光会理解意图还不够理解了但执行不了依然是纸上谈兵。company-brain 把执行能力做成了工具调用层也就是现在 AI Agent 里很流行的 Function Calling / Tool Use 模式。在这一层它会预先注册好一批工具每个工具对应一个 API 调用或内部动作。我举几个典型的工具get_channel_history(channel, time_range)拉取某频道某段时间的消息摘要create_task(title, assignee, due_date)在项目管理工具里创建任务query_knowledge_base(keyword)在团队知识库里搜索资料list_calendar_events(user, date)查某个人的日程send_digest(channel, summary)向某个频道发送汇总消息。大模型拿到了消息内容和工具列表之后会自己决定调用哪个工具、传什么参数、按什么顺序调。这就有点像给 AI 装了手和脚它能自己去翻记录、建任务、写汇总而不是只动嘴皮子。我之前看到有些团队部署 Agent 失败原因就是只接了大模型没有接工具。模型再聪明也只能生成文本无法改变系统状态。而 company-brain 的设计比较务实它把“理解”和“执行”拆开理解靠模型执行靠工具。这样即使模型换掉工具层还能复用反过来新增一个公司内部的系统对接也只需要新写一个工具注册进去。2.4 上下文记忆让 AI 记得昨天说过什么这是所有 Slack 类 Agent 都绕不开的难题对话是分散的上下文是割裂的。用户周一在 thread 里说“这周要把支付流程重构完成”周五又去另一个频道问“支付流程改到哪一步了”。如果 AI 没有跨频道记忆它就是一个失忆的工具人。company-brain 在上下文处理上做了一套组合方案。短期记忆是每个 thread 内部的连续对话这个好解决把同一 thread 的消息打包成一个 session 上下文传给模型就行。长期记忆则是把关键信息抽出来存成结构化条目。比如从“这周要把支付流程重构完成”这句话里它可以抽取主题支付流程重构目标时间本周状态进行中来源频道xxx主要负责人可能是提到的人这些条目会被写入一个轻量的数据库或向量库。之后不管用户在哪个频道问起相关话题都能把这个长期条目拉回来作为上下文。这一层做得好不好直接决定了 Agent 在团队里是不是“真的懂你们在干嘛”。2.5 权限闸门主动的前提是不闯祸前面说的都是“怎么干活”但“主动干活”最让人不放心的就是怕它乱干活。一个 AI 擅自建了一堆任务或者误改了状态在真实团队里会产生很大的干扰。所以在权限设计上company-brain 这类项目普遍采用“分级授权”的思路。我见过比较稳妥的做法是操作类型处理方式只读操作查文档、搜历史、汇总消息自动执行无需确认低风险写入发通知、建草稿任务自动执行但会把动作记录到日志频道中风险操作真正创建任务、修改状态执行前发一条确认消息等人点头高风险操作删除内容、修改权限、外部发送直接拒绝只反馈给管理员这个分级非常像真实团队里的授权逻辑。新员工可以看资料但不能随便删库组长能改任务状态但要提前说一声只有管理员能删东西。AI Agent 在团队里也应该按这套规矩来。我在看到 company-brain 把确认消息做成了 Slack 里的按钮交互时确实觉得这是懂实际需求的设计——点了“确认”才继续不然就取消整个流程都在聊天界面里完成不打断工作节奏。3. 本地部署 company-brain 到 Slack 的实操笔记3.1 创建 Slack App 时的权限清单把 company-brain或者任何 Slack AI Agent接进来的第一步都是去 api.slack.com 创建一个新的 Slack App。这里有几个权限项基本都是绕不开的channels:history读取频道消息历史这是 AI 感知团队动态的前提chat:write让 Bot 能发消息到频道users:read读取成员信息用于识别谁在说话、负责人是谁reactions:add有时候 AI 会用表情回应表示“已收到”commands注册斜杠命令比如/brain digestapp_mentions:read至少保留对 mention 的响应能力用于显式调用。权限不是越多越好我建议按需申请遵循最小权限原则。我见过有人图省事把一堆权限全开结果 Bot 能看到私聊消息这在大团队里会有隐私争议后面再想收敛就很麻烦。3.2 环境变量与模型配置company-brain 的配置通常走环境变量核心字段大概是这样SLACK_BOT_TOKENxoxb-xxxx SLACK_SIGNING_SECRETxxxx SLACK_APP_TOKENxapp-xxxx LLM_API_KEYsk-xxxx LLM_MODELyour-model-name DEFAULT_CHANNELgeneral这里多说一句SLACK_APP_TOKEN和SLACK_SIGNING_SECRET的区别。APP_TOKEN用于 Socket Mode 连接也就是 Bot 主动和 Slack 服务端保持一条长连接SIGNING_SECRET用于验证请求合法性防止外面伪造 Slack 请求打进来。两个角色不同别搞混。模型接入上它一般是兼容 OpenAI 格式的接口所以也可以用其他兼容接口的模型。实际使用中意图识别和工具调用这块普通模型和顶级模型的差距非常明显涉及多工具选择、多步骤拆解的任务模型推理能力弱了很容易选错工具。预算允许的话建议切一个推理能力强一点的模型来跑 Agent 链路查资料回复这类纯对话任务再走普通模型。3.3 用 Socket Mode 跑通第一版本地开发阶段我强烈建议开 Socket Mode。传统的 Slack Bot 需要一个公网 URL 来接收事件回调你得部署到服务器之后才能调试。而 Socket Mode 让 Bot 主动建立一条出站连接本地python app.py就能直接收到 Slack 的事件调试效率高一个量级。跑通第一版时你只需要在测试频道里关注三件事Bot 是否在线能被 到发一条“帮我汇总下这个频道这周讨论了什么”看它能不能正确响应发一条带有任务语义的消息比如“谁把支付页的测试用例补一下”看它能不能监听到并生成待办。第 3 步是判断这个 Agent 是否“主动”的试金石。如果它只能回答第 2 步那说明事件过滤或意图识别的链路还没有完全生效需要回去查消息订阅配置。3.4 接入生产环境前需要确认的事本地跑通只是开始。真正放进团队生产环境还有几个比代码更需要确认的问题Bot 放进哪些频道不是所有频道都需要 AI 监听。内部闲聊频道就别放了既不产生有效任务还浪费上下文额度。一般是放项目管理、技术讨论、运维告警、设计评审这类工作频道。谁有权限让 AI 执行动作建议初期只让核心成员有确认权限AI 输出的内容先发给小范围频道等人真觉得有价值了再逐步放开。数据合规问题。Slack 里的聊天记录会透传给大模型厂商。如果团队对数据敏感要么选私有化部署的模型要么在配置里过滤掉含敏感关键词的消息不让它们进入大模型链路。这些听起来像管理问题但技术上都会影响实现方式。比如过滤敏感消息你必须在事件监听层做一道关键词拦截而不是等消息进到 LLM 再去挡。4. 把“会回话”调教成“会干活”的关键配置4.1 用岗位说明书限制 AI 的行动半径很多 Slack AI 不好用不是因为模型不够聪明而是因为它的“人设”太模糊。你让它什么都管它就会什么都插嘴最后变成一个群聊里的复读机。company-brain 这类项目好用的关键在于你有没有给它写好“岗位说明书”。我通常会在初始化配置里明确三件事我负责什么比如项目进度跟踪、信息汇总、提醒通知我不负责什么比如不回答和业务无关的问题、不替人做决策我在什么情况下要主动出手比如出现“紧急”“Bug”“延期”等关键词时。有了这个边界AI 的“主动”才不是骚扰。它知道你团队的业务重点宁愿漏掉一些无关信息也不要把人淹没在无效提醒里。这个取舍非常重要。有人希望 AI 什么都抓结果频道里全是 AI 的消息人类真正要看的反而被淹没了。记住AI 在协作工具里要学会的第一件事是“闭嘴”。4.2 高频流程固化成按钮和快捷指令纯靠自然语言让 AI 干活体验其实不稳定。公司里的高频流程更好的做法是固化成 Slack 里的交互组件让它变得可重复、可预期。比如“每日站会汇总”这个场景。你可以给 AI 设计一个指令它早上把各频道消息拉一遍生成三条摘要昨天完成了什么、今天有什么重点、哪些事项需要关注。然后通过 Slack 消息里的按钮让成员点选“确认无误”或“补充内容”。点击反馈又会作为上下文喂给 AI形成闭环。这么做的好处是AI 每次干活的方式是相对固定的输出的质量也稳定人的反馈又能持续校准它。而不是每次都要靠自然语言重新编排流程那样既慢又不稳定。这条建议对于所有想上 Agent 的团队都适用先把高频、标准化、低风险的流程固化再让 AI 去处理那些非结构化的开放任务。4.3 定时主动巡检让 AI 按计划干活真正让 company-brain 区别于一般 Chatbot 的是它可以完全靠定时器驱动而不是等消息来。比如设定每天早上 9 点它自动执行“巡检所有未关闭的任务找出明天就到期的私信提醒负责人”。这个动作根本不依赖任何人发消息。我在配置里加了两个定时任务每个工作日上午 9 点汇总各项目频道的讨论要点发到 #daily-report 频道每天下午 4 点扫描所有已逾期任务生成催办清单私信给对应负责人。跑了一周下来团队成员形成的习惯是早上先看 #daily-report 再开干。这个价值非常直观以前开站会要各自报进度现在 AI 已经把进度汇好了站会只需要讨论异常项。定时任务实现的底层没啥特别复杂的技术本质是集成一个 cron 调度器把“时间到了”当作事件源和 Slack 事件统一进入 Agent 的处理链路。但它带来的产品体验是一种“这个 AI 真的在上班”的实感。4.4 反馈闭环AI 干完活如何通知到人AI 干活之后“结果要往哪发”也是个需要明确的设计。不是所有结果都适合丢回原频道。我建议按信息强度分三级私信只和某个人相关的信息比如“你有个任务明天到期”直接私信不要公开 指定频道涉及多人的信息比如发布提醒、每日汇总发到专门的 #digest 频道原线程回复和当前讨论直接相关的补充比如 AI 帮你在某个工单线程里查到了状态就在原线程下回复结果。有些团队把所有 AI 输出都丢到一个 #ai-activity 频道看起来像是留了审计记录但根本没人看。信息只有发到真正会被人看到的地方才叫闭环。这一点配置很简单但产品观感差异巨大值得花时间调。5. 跑了一阶段后我踩过的坑和调整方案5.1 误触发把闲聊当成任务最开始的版本我把事件监听做得太敏感了。有人在频道里随口说一句“这个设计稿要改改”AI 马上就把它当成一个任务创建了一个待办项还 了设计师。结果是设计师一脸懵跑来问这个是我要做的事吗问题出在意图判定的置信度阈值。聊天里的口头语、调侃、反讽太多了直接丢给大模型判断模型倾向于“宁可多做也不要漏掉”于是产生一堆误触发。我的调整方案是三道闸门第一关键词白名单和黑名单。白名单包含“Bug、延期、阻塞、创建任务、安排会议”这类强任务词黑名单包含“随便说说、吐槽、开玩笑”这类弱信号词。第二对消息做上下文判断。如果消息所在 thread 本身没有明确讨论目标或者消息长度特别短降低它的任务分数。第三大模型只负责辅助判断不负责最终决策。最后的“是否创建任务”必须过一个规则引擎规则不满足就只记录不执行。加完这三层之后误触发率明显降下来了。我不追求它把所有真任务都捕捉到因为漏几个还能靠人工补救但如果它老是瞎创建任务大家在信任度上就会大打折扣这个 AI 基本就废了。5.2 通知轰炸与员工屏蔽 Bot第二个问题很快跟着来了。AI 太勤快了每天发一堆汇总、提醒、催办同事开始频繁把 Bot 静音。一旦被屏蔽你的 AI 再智能也没用因为消息根本不会被人看到。这个坑的根源是我把“发送频率”设计得太高而没有考虑人的注意力有限。后来我做了一个调整所有 AI 主动通知必须满足“频率限制”和“场景白名单”两个条件才能发出每日汇总合并成一条而不是分频道各发一条私信提醒只发最紧急的非紧急的自动滚入次日日报。这个教训说白了就是AI 的主动应该用来减少信息过载而不是制造新的噪音。它存在的价值是帮你分流信息而不是成为新的信息源。5.3 幻觉AI 一本正经地编造进度有一次AI 在汇报项目进度时写了一句“支付模块联调已完成 80%”但实际上当时联调根本还没开始。我看日志发现它是从某个频道的一条消息里推断出“好像有人在推进联调”然后自作主张写成了“完成 80%”。这种一本正经地编造数据在团队工具里是绝对不能接受的因为它会直接污染管理决策。解决这个问题技术上只有一条准则AI 只能引用真实存在的数据源禁止从对话内容里推断进度和数值。我调整了它的 prompt明确要求“所有进度、百分比、截止时间必须来源于关联工具接口的实际数据如果数据不存在回复‘暂未找到对应数据’禁止根据聊天内容推测”。同时给工具调用层加了一层检查凡是进度类工具没有返回数据输出模板默认显示“未同步”不允许 AI 自行填数字。这一步非常重要。团队成员可以容忍 AI 偶尔总结不到位但绝对不能容忍它编造事实。一旦发生过一次所有人都会怀疑它的每一条输出。5.4 权限事故只读与写操作的边界最让我后怕的一次是 AI 差点把另一个团队的任务状态改错了。当时我为了测试一个“批量更新任务状态”的功能给了 Bot 一个过宽的权限范围结果它在处理一条不相关的消息时错误地识别成了一个“状态变更指令”对着项目工具发起了状态修改请求。还好那一次有二次确认按钮没有直接执行但我是真的出了一身冷汗。从那以后我严格执行分级权限并且专门梳理了一个权限矩阵。核心原则是所有会改变系统状态的请求必须走确认流程而且确认消息里必须写清楚将要执行的动作、对象、影响范围让人能一眼看懂再决定点不点确认。权限宽泛导致的低级事故是完全可以从设计上避免的不要在形式上偷懒。5.5 Token 消耗和成本控制最后说一个没有技术含量但必须面对的问题钱。Agent 类应用和普通问答最大的不同是它每次处理消息可能需要多轮模型调用和工具调用token 消耗是肉眼可见的涨。一次简单的“汇总近三天讨论”任务我观察到的模型调用 token 常常能到一两万而且这只是在外层循环还没算深层调用。我的成本治理手段有三条消息进入 LLM 之前先做规则过滤能不用模型就不用模型长上下文的频道历史先用专门的摘要工具压缩成要点再喂给模型。不要在 prompt 里堆原始消息设置 token 上限和月度预算超出阈值自动降级为“只回复摘要不执行工具”。这三条落地之后月度成本下降了大概一半而功能感知上几乎没有差别。在 Agent 设计里成本优化不是后期的事而应该从一开始就刻在架构里。6. 从 company-brain 延伸出去的几个玩法6.1 把 CI/CD 信号接进来做智能发布通知公司里最吵的频道往往就是发布频道。每次有个构建通知就刷屏没人能分得清哪个是重要的。可以把 company-brain 的监听源扩展到 CI/CD 平台的 Webhook。当普通构建失败时它不做声但当主分支发布失败、或者同一服务连续失败超过两次时它会主动去翻最近的提交记录、找出可能相关的变更人和提交说明然后把“发布失败 疑似关联提交 相关责任人”一条消息组织好发出来。这样 AI 干的不再是消息搬运而是把一堆孤立信号串联成一个“马上可以行动”的信息包。6.2 把团队知识库变成 RAG 问答能力company-brain 的另一个实用方向是接入公司内部的文档或知识库形成 RAG 链路。团队日常问得最多的话就是“这个接口怎么用”“这台服务器的登录入口在哪”“线上配置怎么改”。如果 AI 能直接查知识库并给出精确答案会省大量打断式提问的时间。需要注意两点一是知识库文档必须有版本和来源标注AI 引用时要能返回出处链接二是定一个“能力边界”只回答知识库里存在的内容超出范围直接说不知道避免它拿其它文档里的过时内容来硬套。6.3 多 Agent 协作让不同角色各管一摊最后提一个我准备下一步尝试的方向把 big brain 拆成多个小 Agent每个只管一个领域。比如一个负责项目进度、一个负责代码评审、一个负责客户反馈。领域 Agent 只关注自己领域内的消息相互之间通过一个共享的“公共频道”交换任务。这么做的好处是单个 Agent 的上下文更干净不被无关消息污染工具也只需要挂自己领域的误触发概率更低。复杂请求进来时由一个调度 Agent 拆解后分发给领域 Agent各干各的再汇总。多 Agent 的架构复杂度肯定比单 Agent 高不少但它更贴近一个组织运转的真实方式也更可控。对于消息量大、角色分工明确的团队很值得深入了解。这篇文章写到这里其实还有很多细节没有完全展开比如具体的事件过滤规则怎么写、确认按钮的交互逻辑、定时任务的编排方式每个单独拿出来都能写一篇。但核心思路我已经表达完了company-brain 这类项目真正有价值的不是它用了多花哨的模型而是它把“感知 → 理解 → 决策 → 执行 → 反馈”这条链路在团队协作场景里完整地打通了。我在部署过程中最大的体会是——AI 进团队不是越积极越好而是要在“主动干活”和“不添乱”之间找到平衡并且所有关键动作都要留给人确认的空间。如果你也想在 Slack 里给团队试一个会干活的 AI建议从一个小范围频道开始跑先把误触发和通知频率调顺再逐步扩大它的行动半径。毕竟一个 AI 助手能不能被团队接受往往不是看它能干多少活而是看它有多少次让人觉得“这 AI 还真靠谱”。
阅读完成 · 觉得有帮助？
