企业官网建设流程全解析

最近在 GitHub 上刷到 company-brain 这个项目，第一眼就被名字吸引了——“公司大脑”。它做的事情直白点说就是：给 Slack 团队装一个会自己看消息、自己判断、自己动手干活的 AI 助手，而不是那种挂在频道里、非要你 @ 一下才吐一句话的聊天机器人。我把它部署进工作区体验了两周，又翻了源码和文档，这篇文章就从一个使用者和工程视角，拆一下 company-brain 这类“主动性 AI Agent”是怎么设计的，优势在哪，部署时有哪些坑，以及怎么把它真正用好。

不管你是想给团队引入 AI 协作工具的负责人，还是最近在研究 AI Agent 落地方式的开发，这篇文章都能给你一些可以直接拿去用的经验。下面进入正题。

1. 为什么我会盯上 company-brain：Slack 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 digest；
• app_mentions:read：至少保留对 @mention 的响应能力，用于显式调用。

权限不是越多越好，我建议按需申请，遵循最小权限原则。我见过有人图省事把一堆权限全开，结果 Bot 能看到私聊消息，这在大团队里会有隐私争议，后面再想收敛就很麻烦。

3.2 环境变量与模型配置

company-brain 的配置通常走环境变量，核心字段大概是这样：

SLACK_BOT_TOKEN=xoxb-xxxx SLACK_SIGNING_SECRET=xxxx SLACK_APP_TOKEN=xapp-xxxx LLM_API_KEY=sk-xxxx LLM_MODEL=your-model-name DEFAULT_CHANNEL=general

这里多说一句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 的事件，调试效率高一个量级。

跑通第一版时，你只需要在测试频道里关注三件事：

1. Bot 是否在线，能被 @ 到；
2. 发一条“帮我汇总下这个频道这周讨论了什么”，看它能不能正确响应；
3. 发一条带有任务语义的消息，比如“谁把支付页的测试用例补一下”，看它能不能监听到并生成待办。

第 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 还真靠谱”。