如何打造人和 Agent 共同协作的 Slack：下一代协作软件的六层底座

Slackbot 重新上线的那一天，Slack 的定义变了

2026 年 1 月 13 日，Salesforce 开始向 Business+ 和 Enterprise+ 客户分批推出新版 Slackbot。表面上看，这只是一个老 bot 的产品升级。真正重要的是，Salesforce 在这次发布里反复强调另一件事: Slack 不再只是企业聊天工具，而是 Agentic Enterprise 的“对话入口”。

这不是一句营销口号。Slack 官方披露，在 Salesforce 内部，超过 42,000 名员工已经在使用新版 Slackbot，每周累计节省 138,000 小时，折合约 640 万美元生产力收益，用户满意度达到 96%。如果再往前看，Salesforce 在复盘自己第一年 Agentforce 内部落地经验时还给出过一个更关键的数字: 86% 的员工已经在 Slack 中使用 Agent，99% 的全球员工使用过内部 Agent。

这些数字说明了一件非常具体的事。企业并不缺“能回答问题的 AI”。市场上真正稀缺的，是一个能让人和 Agent 在同一个工作界面里长期共事的系统。也就是说，下一代 Slack 不是把聊天框升级成 AI 聊天框，而是把 Agent 变成组织里的正式成员。

这类产品要解决的问题，比做一个聊天机器人难得多。人和人协作时，Slack 频道、Teams 群聊、Jira 工单、Confluence 文档、会议纪要、审批流、权限边界，这些元素天然就构成了组织的工作网络。Agent 如果要真的加入这张网络，就必须拥有身份、上下文、行动能力、权限边界、可审计性和交接机制。少一层，都只能算 demo。

所以，“如何打造人和 Agent 共同协作的 Slack”这个问题，真正要问的不是界面长什么样，而是底层系统该怎么设计。

把 Bot 塞进群聊，不等于让 Agent 进入组织

过去两年，很多 AI 协作产品犯了同一个错误: 以为只要把一个 bot 拉进频道，组织就会自然地开始和 Agent 协作。事实证明不会。

原因很简单。聊天只是工作的一层表象，不是工作本身。真正的工作包括谁能看到什么、谁能代表谁行动、哪些内容只能先生成草稿、哪些动作必须经过审批、哪一个知识源可以作为可信依据、哪一次自动化出错之后该由谁接手。一个只会在频道里回复文字的 bot，顶多是一个更聪明的搜索框，离“同事”还差得很远。

从产品视角看，人和 Agent 协作至少有五个天然门槛。

第一，Agent 没有稳定身份。它只是一个入口，不是一个成员。用户不知道什么时候该找它，也不知道它负责什么。
第二，Agent 没有组织上下文。它不知道这个频道的历史、这个项目的背景、这个工单的状态，也无法区分公开信息和权限内信息。
第三，Agent 没有行动闭环。它会给建议，但不能把结果落到工单、文档、流程、日程、审批里。
第四，Agent 没有治理框架。它不知道哪些动作该自动执行，哪些动作必须让人确认，哪些输出只能先给发起人看。
第五，Agent 没有分发和运营体系。组织没有办法统一发现、安装、审核、下线、评估这些 Agent。

这也是为什么 Salesforce 在复盘内部经验时会强调，Agent 不能被孤立在一个单独应用里，必须嵌进员工每天已经在用的 Slack、CRM、邮件和 Web 流程里。不是因为聊天界面更酷，而是因为工作流、上下文和行为已经在那里。

换句话说，下一代协作产品的关键，不是“让 Agent 能说话”，而是“让 Agent 能够被组织管理，并在组织中承担职责”。

市场上已经出现了三种路线

如果把今天主流产品拆开看，会发现大家其实都在回答同一个问题，只是切入点不同。

路线	代表产品	核心抓手	最强能力	主要短板
对话入口	Slack	频道、线程、搜索、Slackbot	高频协作和知识流天然集中	深度执行仍要持续下沉到工作对象
治理入口	Microsoft Teams	身份、许可、审批、商店	企业级控制和部署能力强	体验更像受控系统，不总是最轻快
工作对象入口	Atlassian Rovo	Jira、Confluence、Teamwork Graph	Agent 直接参与任务和流程	对“通用沟通层”的覆盖不如聊天平台

Slack 的路线: 先占住对话入口

Slack 的优势，是它天然就是高频协作的表层界面。消息、线程、频道、Canvas、Huddle、Workflow，本来就在同一个交互平面上。

因此，Slack 的解法很清楚: 先把 Agent 变成频道和私信里的可调用对象，再用企业搜索把上下文补齐。官方文档已经把这个思路写得很直白。Agentforce 在 Slack 里有独立的 Agentforce 标签页，用户可以像找同事一样浏览和私信 Agent，也可以把 Agent 拉进频道，用 @mention 的方式触发它。Slack 还支持分享 Agent prompt 链接，并把这些链接放进频道、Canvas 和 Workflow 里复用。

更重要的是，Slack 在把“上下文层”做厚。2025 年 3 月，Slack 正式推出 enterprise search，把 Slack 内的消息、文件和外部应用数据连在一起。到了 2025 年 7 月，Slack 又把 AI huddle notes 和更多 AI 能力扩展到付费计划，让会议记录、行动项和频道上下文可以自然地沉淀回工作流。Slack 公开表示，Slack AI 发布后，用户已经总结了超过 6 亿条消息，累计节省 110 万小时。

这条路线的核心不是“Agent 更聪明”，而是“Agent 从第一天起就处在对话和知识流的中心”。新版 Slackbot 更进一步，直接把自己定义为个人工作的 Agent 入口。用户不必先判断应该找哪个系统、哪个 Agent、哪个数据源，而是先对 Slackbot 说出目标，再由它在背后调用合适的 Agent 和系统。

这是非常强的一步，但它也有边界。只要真正的执行对象仍然大量存在于工单系统、文档系统、审批系统和垂直 SaaS 里，Slack 就必须不断向更深的工作对象渗透，否则它还是更像“协作前台”，不是“执行底座”。

Microsoft Teams 的路线: 先把治理和控制做对

Microsoft 的切入点和 Slack 不一样。它不是先强调对话流畅，而是先强调企业级控制。

2025 年 9 月，Microsoft 正式提出 human-agent teams，给 Teams、SharePoint、Viva Engage 这些协作场景分别配置上下文型 Agent。它要解决的不是“一个人怎么问 AI”，而是“一个团队怎么和 AI 一起工作”。这个变化很重要，因为协作的单位从个人 assistant 变成了 team、project、meeting、community 这些组织单元。

Teams 的产品设计里，有几个细节很值得注意。

在 Teams 群聊里，Copilot 生成的回复需要由发起 prompt 的人先审批，批准后才会对群成员可见。
想在 Teams 聊天或群聊里调用 Copilot，用户必须持有 Copilot 许可证。
Agent 可以被发布到 Teams app store 和 Microsoft 365 Agent Store，也可以通过管理员审批后在组织内推广、自动安装和固定到侧边栏。
开发者可以把 Agent 的知识范围限定到特定 team channel、group chat 或 meeting chat，最多五个具体聊天上下文。

这些机制看上去不如 Slack 那么“顺”，但它回答了企业最在意的问题: 当 Agent 开始进入群体协作，谁来控制它看到什么、说什么、被谁安装、在什么范围内生效。

如果说 Slack 是把 Agent 拉进工作现场，Microsoft 更像是在给 Agent 发工牌、开门禁、配审计。

Atlassian 的路线: 把 Agent 直接塞进工作对象

Atlassian 可能是三家里最值得重视的一条路线，因为它最接近“Agent 真正参加工作”这件事。

Atlassian 并没有把 Rovo 只做成一个聊天窗口。它在做的是把 Agent 直接嵌进 Jira 和 Confluence 等工作对象。官方文档显示，Rovo Agent 可以被加入 Jira work item 的 assignee 字段，可以在 comment 中被 @mention，可以挂到 workflow transition 上，也可以被加到看板列里，随着工单流转自动触发。更关键的是，Agent 产出的结果一开始只对触发者可见，用户确认后再决定是否发布给团队。

这就不是“和 AI 聊天”了，而是“把 AI 变成工作流中的一个参与方”。

Atlassian 的另一层优势在于 Teamwork Graph。到 2025 年 4 月，它已经在官方表述中用“跨越 100 亿数据对象、映射数十亿关系”来描述这张图谱；到 2025 年 10 月，Atlassian 又在股东信里更新为 Teamwork Graph 已经追踪超过 1000 亿个对象和关系。与此同时，开发者文档也写明 Atlassian 已经提供 100 个现成的 Teamwork Graph connectors，把 Google Drive、Slack、GitHub 等外部工具接进来。对于 Agent 来说，这意味着它不是只读取一篇文档，而是能够理解“这个文档和哪个工单有关、由谁负责、在哪个频道讨论过、与哪个目标绑定”。

Atlassian 还给了市场一个有意思的数字: 到 2025 年 4 月，已经有接近 2,000 个 Rovo Agent 被集成进客户工作流。这个量级还不算巨大，但足以说明一件事: 一旦 Agent 能嵌进具体工作对象，组织的采用路径会比纯聊天助手更清晰。

Slack 代表“对话入口”，Teams 代表“治理入口”，Atlassian 代表“工作对象入口”。三条路线看起来不同，底层却在收敛到同一个方向: Agent 必须成为组织系统中的一等公民。

真正的人机协作平台，需要六层底座

如果今天从零开始做一款“人和 Agent 共同协作的 Slack”，我会把产品拆成六层。少做一层，后面都会以更高成本补回来。

第一层: 身份层

Agent 不能只是一个隐藏功能或命令入口，它必须有清晰身份。

这意味着它要有名字、头像、职责描述、负责人、可发现入口、可分享链接、可被安装和下线的生命周期。Slack 的 Agentforce 标签页、Teams 的 Agent Store、Rovo 的 Agent profile，本质上都在解决这个问题。用户需要知道“组织里有哪些 Agent，它们分别负责什么，我该在什么场景叫它”。

没有身份层，用户的心智模型就会崩塌。每次都从空白对话框开始，Agent 很快会被当成通用问答工具，而不是协作成员。

第二层: 上下文层

上下文层决定 Agent 到底是在“猜”，还是在“理解”。

这层通常由权限感知搜索、知识图谱、组织目录、消息历史、文档关系、工单状态、会议记录和外部系统连接器组成。Slack 在做的是 enterprise search，Microsoft 在做的是 Graph 驱动的协作 Agent，Atlassian 在做的是 Teamwork Graph。三家名字不同，本质相同: 让 Agent 不再面对零散文档，而是面对组织的关系网络。

这层最难的不是接更多数据源，而是接入权限。Slack 明确写到，Agent 在 Slack 中基于用户的 Slack 和 Salesforce 权限生成答案，不会返回用户无权访问的信息。Rovo 也强调，分享 Agent 不会额外授予任何数据权限。真正可用的企业 Agent，从第一天起就必须是 permission-aware。

第三层: 行动层

只有回答，没有行动，不叫协作。

Agent 至少要能在四类对象上行动: 对话、文档、任务、流程。对话里，它可以总结、起草、提问、路由。文档里，它可以整理、改写、生成草稿。任务里，它可以被分配、评论、更新状态。流程里，它可以被触发、调用工具、产出结果、交给人审批。

Atlassian 把 Agent 放进 assignee 和 workflow transition，是行动层的典型设计。Slack 把 Agent prompt 放进 workflow、把 huddle notes 自动落到 canvas，也是同样的思路。真正的协作平台，不能只让 Agent“说完就算了”，而要让它把结果沉淀到工作对象里。

第四层: 治理层

人和 Agent 真正共事之后，产品问题会迅速变成治理问题。

哪些内容允许公开回复，哪些必须只给发起人看。哪些动作可以自动执行，哪些必须人类确认。哪个 Agent 可以调用外部系统，哪个 Agent 只能读不能写。错误输出如何回滚，谁对结果负责，审计日志存在哪里，测试环境和生产环境如何隔离。

Microsoft 在 Teams 群聊里的“先审批再公开”设计，Rovo 的“先给触发者看、确认后再发布”，都说明一个现实: 企业不是不想自动化，而是不接受黑箱自动化。好的 Agent 产品不会强迫企业在“效率”和“可控”之间二选一，而是把审批、发布、权限、审计做成默认能力。

第五层: 分发层

当组织里有 3 个 Agent 时，靠口口相传也能用；当组织里有 300 个 Agent 时，没有分发层就一定会失控。

所以平台必须有目录、商店、模板、推荐、安装权限、组织级推广、角色分层和第三方生态。Teams 有 app store 和 Microsoft 365 Agent Store，Slack 正在把 Slack 变成安装第三方 Agent 和 MCP 扩展的入口，Atlassian 则把第三方 Agent、自动化和 MCP 接入都并入 Rovo 体系。

分发层的意义，不只是“方便发现”。它决定平台能不能形成网络效应。一个组织里越多 Agent 被标准化地创建、审核、复用和扩散，用户越愿意把更多工作迁回这个平台。

第六层: 运营层

Agent 不是上线就结束，而是上线才开始。

平台必须知道每个 Agent 的调用量、成功率、复用率、被编辑率、被拒绝率、人工接管率、平均节省时间、单次任务成本和高风险失败点。否则 Agent 规模一上来，组织只能靠感觉运营。

这一层往往最容易被忽视，但最后会成为企业采购时的硬性要求。因为组织买的不是模型能力，而是一个持续可优化的劳动系统。

界面应该怎么设计: 从 DM 到频道，到会议，再到工单

做这种产品时，最容易犯的错误，是试图用一种交互覆盖所有协作场景。实际上，人和 Agent 协作至少需要四种不同表面。

1. 私聊 DM: 处理模糊、个人、探索性任务

DM 适合那些还没准备好公开的工作，比如“帮我整理一下明天的汇报提纲”“我漏看了这个项目什么信息”“给我起一个版本一的回复”。新版 Slackbot 之所以重要，就是因为它抢占了这个入口。它不是一个单点工具，而是个人在工作系统里的默认 AI 界面。

2. 频道和群聊: 处理共享上下文和公开协作

频道适合大家共同关心的问题，比如支持请求、项目状态、决策记录、跨团队协调。这里的关键不是让 Agent 代替所有人发言，而是让它成为可被点名的公共助手。Slack 的 @mention Agent、Teams 的群聊协作 Copilot 都属于这个层面。

但频道里一定要有“私有草稿到公开发布”的缓冲带。否则 Agent 一旦把不完整信息直接发进公共空间，信任就会迅速崩掉。

3. 会议和 Huddle: 处理实时同步与收尾动作

Slack 的 AI huddle notes、Microsoft 的 Facilitator for Teams meetings，本质上都在做一件事: 把同步沟通的价值结构化，变成会后可执行的结果。下一代协作平台里，会议 Agent 不是录音转写工具，而是任务归档器、共识提炼器和 follow-up 发起器。

4. 工单、文档和流程: 处理真正的执行

这一层最关键。因为只有当 Agent 的输出进入 Jira、CRM、知识库、审批流，它才真正影响组织运转。Atlassian 之所以值得警惕，就在于它把 Agent 放进了 work item 本身，而不是只放在旁边的聊天面板里。

从产品设计上，我会坚持一个原则: Agent 的默认输出应该先是 draft，而不是 final。先草稿、再确认、再发布、再触发下一步动作。这样既能让 Agent 参与执行，也不会破坏团队对结果负责的结构。

真正的护城河，不是模型，而是工作上下文

看到这里，很多人会自然得出一个结论: 谁的模型更强，谁就更可能做出“人和 Agent 协作的 Slack”。我认为这恰恰是错觉。

模型能力当然重要，但它会越来越商品化。今天是 Claude、GPT、Gemini，明天还会有新的推理层和执行层。企业协作平台真正稀缺的，不是最强模型，而是最深的工作上下文和最稳的组织分发。

Slack 的护城河在于对话流和使用频次。Teams 的护城河在于身份、权限、管理和 Microsoft 365 既有席位。Atlassian 的护城河在于工作对象和流程引擎。谁更接近“人和 Agent 共协作的操作系统”，本质上取决于谁能同时控制这三件事:

工作发生在哪里。
组织权限定义在哪里。
执行结果沉淀在哪里。

这也是为什么很多创业公司虽然能做出更惊艳的 Agent demo，却很难成为组织级协作入口。没有权限体系、没有对象模型、没有安装分发、没有长期上下文，AI 再聪明，也只是在外围打补丁。

如果今天从零做，我会怎么切这个市场

如果今天让我从零打造一款“人和 Agent 共同协作的 Slack”，我不会一开始就做一个全能平台。我会先切一个高频、强上下文、可度量的场景，再逐层外扩。

第一步，我会选支持、项目运营、工程协作这类本来就高度依赖频道和工单的场景。因为这些场景同时具备三点: 请求密度高、状态对象清晰、人工交接成本真实存在。

第二步，我只上线最小闭环:

一个可发现的 Agent 目录
一个 permission-aware 的统一搜索层
一个频道内可 @mention 的协作入口
一个工单或文档里的 draft-first 执行面
一个最基础的人类审批和审计日志系统

第三步，我再扩展到会议纪要、跨系统动作、Agent 编排和第三方生态。只有到了这一步，产品才开始接近平台。

衡量这类产品，不该只看 DAU 或提问次数。我更关心五个指标:

Time to first useful action，也就是用户发起请求后，Agent 第一次真正推动工作的速度
Human acceptance rate，也就是 Agent 草稿被直接接受或轻改后发布的比例
Autonomous resolution rate，也就是无需人工二次处理就闭环的任务比例
Re-prompt rate，也就是用户不得不重复说明、纠正或换说法的频率
Trust break rate，也就是权限错误、事实错误、误发布造成的信任损失频率

谁能把这五个指标稳定做出来，谁才有资格谈“人机协作平台”。

结语: 下一代 Slack，本质上不是聊天软件

过去十年，Slack 之所以重要，不是因为它把聊天做得更漂亮，而是因为它把组织里的沟通、文件、工具和流程拉进了同一个界面。

未来十年，真正重要的产品也不会只是“带 AI 的聊天软件”。它会是一个让人、Agent、应用和数据一起运转的协作操作系统。在这个系统里，Agent 不是外挂，不是搜索框，不是临时助手，而是被分配任务、受到权限约束、能留下产出、能被评估表现、也能和人交接的组织成员。

当一个 Agent 可以像人一样被加入频道、被分配工单、参加会议、写草稿、等待审批、记录行动、接受审计时，类别就已经变了。那时我们再说“打造一个人和 Agent 共同协作的 Slack”，真正要打造的就不再是 Slack。

而是一套新的工作基础设施。