不少人应该有过这种体验团队里的 Slack 群聊永远是红点轰炸现场问个问题没人理、催个进度半天没回音、跨部门协作更是像在玩拼图。大多数团队部署的 AI 机器人本质是个“问答盒子”你问一句它答一句你不问它绝不开口。所以当我看到 company-brain 这个项目时第一反应是——终于有人把方向搞对了与其让 AI 被动等提问不如让它主动盯着频道、识别任务、自己动手把活干完。这个项目的作用可以一句话概括在 Slack 里跑一个拥有团队上下文、能独立处理事务消息的自主 AI 代理。它适合那些已经在用 Slack 协作、又不想让团队每天手动切进各种后台系统去刷新状态的人。不管你是技术团队的负责人、工具链偏好的践行者还是正在琢磨“AI 到底能在日常工作流里真正做点什么”的从业者这套思路都值得完整拆一遍。下面我会结合自己实际部署和改造这款工具的经历把它的定位、架构、关键实现和踩坑点从头到尾讲清楚。1. 定位从“被动问答”到“主动干活”的本质差异1.1 普通 Slack 机器人解决不了的问题先看大多数团队的现状。你会买各种 SaaS 工具的 Slack 集成比如把工单系统、监控告警、项目管理工具全部接进来。结果就是每个工具都在向频道里推送消息团队成员依旧要从一堆通知里人工辨认哪些需要自己处理。真正的效率问题并不在于信息缺失而在于信息到行动的转换环节完全依赖人。再叠加一个现实问题面对一条“这个需求能不能帮我查一下昨天的数据”诸如此类的消息人需要先弄清楚它归谁负责、数据在哪查、格式怎么给。一个被动式 AI 聊天机器人通常只解决“怎么查”但大部分时候团队的麻烦是“到底该不该处理、谁来处理、处理完怎么回”。1.2 company-brain 的设计前提把上下文当作资产company-brain 的核心设计主张简单说就是让 AI 长期保存团队的工作上下文然后基于上下文主动采取行动。它不是把每一条 incoming message 都当作一次独立的问答请求而是把频道内的讨论、任务安排、决策记录视为一个持续演进的“团队记忆”。这个设计前提带来的行为差异非常明显。同样是“谁能帮我更新一下项目进度”被动问答机器人会回复“你可以去某工具里自行查看”而具备自主性的代理会先确认自己的权限范围和数据来源然后主动去对应系统查询最新状态整理成简短报告发回频道。整套动作下来人只需要看到结果而不是看到一堆操作指引。所以如果要用一句话描述这个项目的定位它更像往团队里新加了一个非常勤快、话不多、记忆力好的成员而不是一个被动的问答工具。正是这种定位上的差异决定了后续的技术选型和集成方式都会和传统机器人很不一样。1.3 与传统 AI 助手的对比我用表格把这几年实际见过的几种 Slack 内 AI 形态做个直接对比帮助新人快速建立坐标系。类型典型交互方式上下文能力主动执行能力代表场景聊天问答机器人指令式机器人提问基本没有每次独立无只返回文本查文档、写周报、翻译工作流触发器通过斜杠命令或关键字触发规则范围固定靠配置有限只能执行预定动作创建工单、发起审批自主 Agent 型监听频道内语义自行判断处理持有长期记忆与项目上下文高能拆解并执行多步任务自动推进需求、汇总状态、跨系统查数拿 work 场景来说很多团队用机器人查个数据库还行但要让它“持续跟进某件事并给出结论”传统工具基本做不到。company-brain 属于第三类它的目标是在语义层面理解“发生了什么”而不是机械匹配“关键词”。2. 核心功能拆解一个会主动干活的 AI 具体做了什么2.1 主动感知它是怎么“看到”团队工作的想要主动干活首先要能持续感知频道里发生的事。这里有个重要的技术动作并不是所有消息都值得 AI 理会。company-brain 的做法是把 Slack 的 event subscription 和内部优先级过滤机制结合起来在默认情况下监听所有它被加入频道的消息事件但这些事件不会全部进入大模型处理队列。我拆代码时看到的思路很有意思它内置了一个叫“行动信号”的判断层。大概逻辑是先对消息做轻量分类区分出寒暄、通知、讨论、明确任务请求等类别只有被判定为“有行动潜力”的消息才进入下一步的深度理解。这个过滤层大量使用规则加少量模型判断而不是把所有消息都丢给大模型烧钱工程上相当务实。举个例子频道内有人说“这个按钮的样式好像有问题谁有空看一下”普通机器人会把这句话当成一般消息忽略掉。company-brain 的行动信号层会识别出“问题描述隐含待办归属”于是触发后续的任务分配逻辑——它会优先检查该频道最近的活跃成员和职责标签再结合历史消息里类似问题的处理记录推测出这件事通常由谁跟进。2.2 任务执行从理解到干活的完整链路识别出行动信号之后最关键的就是执行。我实际测试过的任务类型包括这么几类信息拉取类“把 Q3 的销售数据汇总一下”它会找到已有数据源执行查询并把结果以结构化消息发回。状态更新类“某个服务是不是挂了”它会调用内部监控 API检查服务健康状态并在频道里给出结论。任务记录类“下周三前要给客户交付”它会自动创建一个跟进事项并设置提醒。协调催办类“这个需求怎么还没人接”它会结合上下文判断负责角色并在合适的时间点私聊相关成员做提醒。以第一类信息拉取为例完整链路是这样的收到原始消息后先解析出意图和数据范围接着在内部的 tool registry 里找到与该请求最匹配的工具然后使用该工具去请求外部数据拿到数据后再由语言模型整理成人话最后通过 Slack API 发送到正确频道。整条链路里人的参与几乎为零。这里要特别注意主动执行绝不意味着不设边界。我看过的很多失败案例都是 AI 在权限边界和操作边界上没有收紧最后把频道搞得一团糟。company-brain 在权限处理上有一个设计值得每个做类似系统的人参考所有写操作如创建任务、发送私信、发起审批默认都需要一个二次确认机制。它会先在频道里提出自己的执行计划通过短时间等待窗口收集反馈只有收到“确认”或没有异议时才真正落库。这个机制虽然牺牲了一点完全无人值守的理想状态但换来了可控性我认为在真实生产环境里这个取舍非常关键。2.3 团队记忆与上下文管理它比普通机器人聪明的另一大原因是长期记忆设计。语言模型本身没有记忆company-brain 通过在背后维护一套向量存储和结构化事实库让 AI 能“回忆起”三个月前某个决定是谁做的、某个模块的代码风格是怎样的、某个客户对什么样的交付形式比较满意。实际部署时它会在数据库里持久化三类信息消息的语义向量、提取出来的实体关系人物、项目、时间点、负责人、以及由对话摘要定期压缩成的团队记忆快照。这三类信息共同构成了 AI 理解团队的基础。上下文管理也做了时间衰减处理。一个团队不可能永远靠 AI 记住所有旧消息它会把消息的重要性做评分超过一定时间且低频引用的旧消息会自动进入归档区只保留摘要。这样既控制存储成本也减少模型在无关历史里浪费精力。3. 技术架构与选型实现“主动干活”的关键设计3.1 整体架构视角从架构图去理解这个项目会更加清晰。虽然我不会在这里贴代码画图但可以按分层来描述。最底层是 Slack 集成层负责与 Slack 的事件总线和 API 做对接包括接收事件、发送消息、管理频道信息。第二层是作业调度层负责决定哪些事件需要处理、什么时候处理、是否需要排队。第三层是智能决策层里面包含语言模型调用、意图解析、行动信号判定、工具调用的编排。第四层是工具注册层任何要接入的第三方系统都通过统一接口注册成一个工具AI 通过调用工具执行实际操作。最外层是持久化层保存记忆、状态、日志和配置。这种分层带来的一个直接好处是任何一层都可以独立替换。比如某天你不想用某个模型了只需要在智能决策层内部换掉模型供应商其他层完全不动。3.2 语言模型的选择策略大规模语言模型并非越贵越好。这个项目在模型路由上是做了取舍的轻量任务如消息分类用便宜的快速模型只有复杂任务如多步骤推理才调度性能更强、成本更高的大模型。这种路由策略为团队实际控制成本提供了非常大的想象空间。我见过不少团队把任何消息都丢给最贵的大模型跑一遍月底账单出来人傻眼。company-brain 的做法给你一个很好的示范它的 prompt 进入系统前会先有一层简单的分类逻辑把消息分进不同的优先级通道。比如“今晚发布有风险吗”属于复杂分析会进入重模型“这个链接在哪”属于简单检索走轻模型。3.3 为什么选择事件驱动而非定时轮询主动干活的系统遇到的第一个架构选择就是到底用事件驱动还是定时轮询。如果按直觉做可能会想每隔几分钟扫描一次所有 Slack 频道看看有没有新消息。但这个方案有两个硬伤一是 Slack API 的使用成本会高得离谱二是消息实时性得不到保证——你永远不知道消息是刚发出来还是五分钟前发的。company-brain 采用了事件驱动架构。当 Slack 里有新消息或新事件发生时平台本身会通过 webhook 把事件推给程序程序只需要在收到推送的瞬间做出反应。这个模式的好处不用多说资源占用少、响应即时、也符合 Slack 官方推荐的集成方式。不过事件驱动也带来一个难点事件风暴。大频道在高峰期可能一秒钟推过来十几条消息如果每条都触发一次完整的智能处理系统大概率会被拖垮。解决方案在上一节已经提过在实现上用了一个带优先级的数据队列只有被行动信号层标记为高价值的消息才能插队进入模型调度其余消息批量合并处理。这套机制不是一个普通的“事件进来就处理”的流水线它更应该被理解为一个有态度、有取舍的输入处理系统。3.4 工具调用的设计哲学让 AI 主动干活最重要也是最容易翻车的环节就是工具调用。company-brain 在内部定义了一套非常简单的工具接口外部系统只需要实现“描述参数列表执行函数”三件套就能接入。这种设计让任何人都能快速给自己团队扩展新的自动化能力。工具调用里有一个我特别欣赏的细节它会记录每次工具调用的结果和成本并形成一个“哪个工具好用”的反馈回路。比如某个工具经常因为参数错误失败系统会在后续使用时增加额外校验而不是每次都犯同样的错。这种从失败中学习的能力让项目在长时间的运行中会越用越顺而不是越用越稳不会的越用越稳是不可能的稳定和智能之间永远是追随状态。要注意的是工具调用并不只是技术工作它更像一个管理问题。每接入一个工具本质上就是给 AI 开放了一部分操作权限。项目里对敏感工具有单独的白名单机制必须由系统管理员显式开启否则即便 AI 识别出了需求也无法调用。4. 实战部署与接入把 company-brain 跑起来的完整过程4.1 准备阶段先想清楚边界动手装之前我强烈建议你先花一小时回答三个问题这个 AI 要帮谁干活、它能动哪些系统、哪些操作绝对不能让它碰。很多人第一步就装歪是因为根本没想清楚边界最后做成一个大而全的玩具。以我自己的部署为例我给它划定的初期范围只有三个内部文档检索、项目状态查询、任务事项创建。三个工具看起来少但已经覆盖了团队里 80% 以上的重复询问。边界明确带来的直接好处是调试成本低出问题的面小团队成员也更容易建立对 AI 的信任。如果你打算照着官方的方式自己跑起来准备阶段大概要做这么几件事一个独立的 Slack 应用不直接复用现有的应用避免权限混乱。一个专用于存放记忆和状态的数据存储我建议单独建库便于备份和清理。一个模型服务的 API 密钥准备好计费心理预期。一个能跑进程的服务器或者本地开发环境。4.2 环境安装与配置细节官方仓库的安装逻辑并不复杂按照 README 操作即可。但有几个配置项我实际部署时花了不少时间才理顺这里单独拎出来讲。第一模型 API 的 base url。很多人直接填默认值结果连不通。要确认自己的模型服务商到底提供了什么地址官方示例里那套不是万能模板。第二Slack 应用的 signing secret 和 bot token。这两个值要在 Slack 应用后台找到对应位置复制一旦填错应用收不到任何事件。第三channel allowlist。这个参数建议一定要配否则 AI 会尝试处理它被添加到的所有频道很快就会被无关消息淹没。以下是启动前的一个最小配置示例yaml 风格和仓库默认方式保持一致slack: app_token: xapp-your-token bot_token: xoxb-your-token signing_secret: xxxx allow_channels: - product-team - ops-standup brain: model_provider: openai-compatible model_fast: small-model-name model_master: large-model-name embedding_model: text-embedding storage: connection_string: your-database-url archive_days: 90 tools: enabled_by_default: false配置文件里最容易被忽略的是 tools.enabled_by_default。这个参数默认设为 false作用是确保任何新注册的工具在未经过显式确认之前AI 不会主动调用。我第一次部署时把它改成 true 想省事结果机器人在测试频道里自作主张创建了一堆重复任务教训非常深刻。小白阶段建议保持默认关闭逐步手动启用。4.3 接入 Slack 应用的授权范围设置Slack 应用的权限配置是整个集成里最容易出问题的环节。需要确保应用至少拥有以下几个 scopechannels:history用来读取频道内历史消息。chat:write用来发送普通消息。app_mentions:read用来接收 提及事件。users:read用来获取成员信息。im:history如果需要读取私聊消息的话。权限不是越多越好最小授权原则在 Slack 平台上尤其适用。我见过有团队给机器人申请了完全控制工作区的权限结果没有做二次审计一旦机器人被恶意调用整个团队数据都面临风险。过度的权限除了方便也意味着风险被平摊到每一个功能里。配置完 scope 后记得先跑一次本地的事件订阅测试确认 Slack 能正常把事件推到本地回调地址。这个环节用内网穿透类工具暴露端口做联调即可但要注意这只是开发调试手段生产环境必须走正式的 HTTPS 回调地址。4.4 让 AI 真正“主动”起来的两个参数装好之后很多人会发现机器人依旧很被动——不它就不说话。这并不是项目不好用而是主动性参数需要调节。第一个参数是对频道内“非提及消息”的扫描深度第二个参数是行动信号判定的置信阈值。扫描深度控制机器人对非直接提及消息的关注程度。把它调高之后机器人会开始处理频道里没人它的消息这正是“主动”二字的来源。但调得太高它就会变得多管闲事甚至频繁插话打断群聊节奏。我个人的经验是从中低档开始往上试每次调整后观察一周团队反馈再决定要不要继续提高。置信阈值则是判断“这条消息值得我动手吗”的门槛。阈值低机器人容易过度反应阈值高它会漏掉一些真正需要处理的请求。与其一次性调最优不如跑一段时间积累日志看看哪些消息是误报、哪些是漏报再做针对性调整。4.5 扩展自己的第一个自定义工具如果内置工具不满足需求你可以自定义工具。以“查询某个订单状态”为例实现一个自定义工具只需要三步在配置中声明这个工具的标识和描述。实现一个函数接收参数并调用外部订单系统 API。把函数结果以纯文本或结构化 JSON 返回。有一件事值得反复强调无论是在官方文档里还是在真实工程里都容易踩坑——工具的描述信息要写清楚。AI 没有肉眼不知道你这个工具是干嘛的全靠 tool description 来理解描述写得含含糊糊它就会在错误的时候调用或者正确的时候不调用。比如“获取订单状态”这种描述就不算好应该写成“当用户询问订单是否发货、物流进度、预计到达时间时用订单号调用此工具查询”。5. 常见问题与排查实录5.1 机器人完全没有响应最常见的原因永远先查三个地方事件订阅是否成功、签名是否正确、频道 allowlist 有没有包含当前频道。把它们全部放到上面排查表格里其实这里面 90% 的问题是配置疏漏真正和代码相关的 bug 很少。我在初次部署时遇到过“本地能跑通但 Slack 里收不到事件”的诡异现象。后来排查发现是回调地址在服务器端没绑定监听端口导致 webhook 把事件推过来之后消息进了黑洞。如果遇到这种问题建议先看应用的调试日志重点是 outbound 和 inbound 两条链路的时间戳确认事件有没有触达你的服务。5.2 主动执行误操作这个项目的核心是“主动”而主动最怕的就是误操作。我在测试阶段让它在公共频道自动创建任务结果因为意图识别歧义把“我们下周可能要讨论这个”识别成了“帮忙建一个跟进任务”产生了噪音。解决办法就是我前面提过的二次确认机制在写操作前先通过 reaction 或回复“我打算这样做5 分钟内没有异议我就执行”。这个机制有人觉得多此一举但真正跑生产环境的人都会发现这 5 秒的等待换来的是团队对 AI 的信任。信任一旦没了功能再强也没人敢用。另外推荐一个小的排障习惯给 AI 的每次行动都打上独立日志 ID。当有人质疑“这活是不是机器人干的”的时候你直接甩一个日志 ID比在数据库里翻半天快得多。5.3 上下文混乱AI 在处理多轮会话时偶尔会拿旧上下文来理解新消息。比如某人今天说“这个需求优先级最高”AI 可能拿三天前的另一个需求来对齐导致结论完全跑偏。这个问题分两层解决第一层在消息进入模型前做一次时间上下文裁剪只保留与当前消息时间邻近且实体相关的历史片段第二层在 prompt 里显式声明和当前消息无关的历史不可作为决策依据。这两套处理下来我这边发生的上下文混乱问题基本消失了。5.4 成本飙升没有人愿意月底看到模型账单比服务器费用还高。成本问题通常源于两个误区一是把所有消息都送进大模型二是没有对工具调用次数做限制。建议在架构里加一层“token 预算”控制轻量分类消息走便宜模型高价值复杂任务才走贵模型对单条消息的模型调用次数做一个上限防止出现一次任务循环调用十几个工具的极端情况。同时定期分析日志中哪些意图消耗 token 最多判断是不是有优化空间。常见故障排查方向推荐处理完全无响应事件订阅、签名、频道范围检查回调日志时间戳响应延迟高模型选择、队列堆积确认轻量分类模型是否生效回答与事实不符上下文混入旧数据裁剪时间窗口强化实体过滤重复执行同一操作缺少幂等控制给执行任务加唯一 ID重复请求直接去重成本异常模型路由失效查看 token 用量按意图维度聚合写在最后的一点个人体会把 company-brain 这类“会主动干活”的 AI 真正接入团队收获往往不在所谓炫酷的自动化效果上而在于它促使你重新梳理了团队的信息流。你要先想清楚哪些消息是噪音、哪类请求真正值得自动化、哪些操作必须保留人工确认这一套整理下来团队协作本身的混乱度就已经降了一截。如果你正准备给团队部署一个 Slack 内的 AI 代理我的建议是从小范围、少量工具、谨慎权限开始让 AI 先在一个频道里证明自己靠谱再逐步扩大它的“管辖范围”。机器人的主动性和人的信任感之间找到那个平衡点才是所有自动化工具真正长期可用的前提。