MS Teams 太拉跨了，学习 Slack 如何把 Agent 做成一等公民

MS Teams 太拉跨了，学习 Slack 如何把 Agent 做成一等公民

同样是"把 AI 放进协作软件"，微软做了一个侧边栏助手，Slack 做了一个 Agent 操作系统。差距不在模型，在架构。

2026 年春天以来，企业用户最纠结的一个问题变成了："我们用 Teams 是因为 Office 生态，但 Copilot 做 AI Agent 真的不行。Slack 在 docs.slack.dev/ai/agents 上写了一整套 Agent 开发指南，那到底强在哪里？"

结论直接给：Teams 的 AI 是"聊天 + 一个助手"，Slack 的 AI 是"Agent 运行时 + 完整开发面"。 在 Teams 里，Agent 是附加大屏；在 Slack 里，Agent 从出现方式、数据边界、会话生命周期、工具渲染、权限到分发全链路都是原生一等公民。

这篇文章对照 docs.slack.dev/ai/agents 官方文档和 Teams Copilot 目前的实际能力，把差距一条条掰开。

本文提纲

  1. 先问：Slack 说的 Agent 到底是不是"换了个名字的 Bot"
  2. Teams 的 Copilot 今天到底能做什么、卡在哪里
  3. Slack Agent 开发面：响应循环、会话 API、事件订阅
  4. Slack Agent 的三条设计原则（为什么 Teams 一条都没做到）
  5. Agent 在 Slack 中"怎么出现"（外观、发现、透明性）
  6. 工具怎么渲染：Block Kit 不是消息格式，是 Agent UI 语言
  7. 权限与安全：Agent 不得越权、人的边界就是 Agent 的边界
  8. 典型场景对比：Deal Desk Agent / SDR Agent / HR 服务 Agent
  9. 选型建议：什么时候选 Teams、什么时候转 Slack

1. 先问：Slack 说的 Agent 到底是不是"换了个名字的 Bot"

先把定义拉齐。docs.slack.dev/ai/agents 里明确给了区分：

Agent 是：
- 边界内自主：Agent 能自己决定下一步，不需要人步步指令。重要的是它知道自己权限边界，遇到越界决定会"停下来请求人"，而不是瞎猜。
- 目标导向：人给 Agent 一个目标，Agent 自己规划如何达成——调多个工具、从多来源聚合上下文、多回合迭代。
- 能使用工具：读工具（搜索、查数据库、取文档、读日历）、写工具（发邮件、建工单、更记录、发帖）、执行工具（跑代码、推工作流、调 API）、甚至是"调另一个 Agent"。
- 有记忆：上下文记忆（当前 prompt 窗口内）、短期记忆（任务线程早期内容）、长期记忆（workspace 内跨会话留存的事实）、共享记忆（多 Agent 系统中互相可见的状态）。

Agent 不是：
- Bot：Bot 是对特定输入返回预定输出，没有推理、没有记忆、没有自适应。Bot 只会被硬编码好的那些事。
- 工作流（非 AI 版）：工作流是触发后可靠可重复的步骤串，不决策。
- Assistant：Assistant 是对话 + 反应式，回答问题有语言理解和推理，但不能自主行动、不能决定下一步做什么——Copilot in Teams 本质上在这里。
- 魔法 ✨：Agent 的能力等于它被赋予的工具 + 目标质量。不要指望无工具 Agent 能在企业里干活。

一句话：Teams 给你的是 Assistant（会话助手），Slack 给你的是 Agent 开发平台（自主工作者）。 这是产品架构层面的分野，不是"再加几个按钮"能弥合的。

2. Teams 的 Copilot 今天到底能做什么、卡在哪里

把 2026 年 4 月微软官方 MVP 回答 + Copilot Studio 文档 + Agents Toolkit 指南三条权威信息拼一下，能拼出 Teams 中 Copilot 的真实边界：

2.1 可用的部分（都在 M365 生态内）

  • 聊天总结、会议总结、动作项提取：Teams 聊天/会议深度和 Copilot 绑定，这部分微软确实做得不错——会议要总结、要行动项、要跨邮件找上下文，Copilot 能直接从 M365 Graph 拉。
  • Outlook / SharePoint / OneDrive / Teams 数据联动："总结这周关于 X 项目的邮件""找到 Sarah 共享的预算表"这类 Copilot 强于任何第三方方案，因为数据就在 Graph 里。
  • 声明式 Agent（Declarative Agent）：通过 Copilot Studio + Teams App Manifest 可以定义"声明式 Agent"——靠 metadata 定义角色、能力、对话开场白，智能在后端，Teams/Copilot 面只负责对话 UX + 工具编排 schema + 用户认证。

2.2 卡死 Teams 做不了 Agent 的地方

  • 聊天中 Copilot 的 AI 能力不是 Agent：Teams 聊天的 Copilot 是"Session 级助手"，能总结当前会议，但不会在会话之间建立持久项目知识（对比 Claude Tag 能记住数周前的讨论决定、对比 Slack Agent 有 workspace 级长期记忆）。
  • Chat API 预览版的限制非常硬：没有 Action/内容生成技能（不能建文件、发邮件、排会议）；仅文本响应；没有代码解释器、图像生成等工具；不支持长任务（网关超时风险大）；只能默认走企业搜索+Web 搜索；Web Search 关闭时只支持单轮。
  • 插件不是在 Copilot 里开的：API Plugins 仅在声明式 Agent 中作为 Action 启用，不能在标准 M365 Copilot 聊天面启用。对普通企业用户来说等于"想让 Copilot 调我的内部 API？你得先另外做一个声明式 Agent 包再发布。"
  • Teams 聊天中 Copilot 的范围限制：只能加到 1:1 或群组聊天；不能加到私聊自己、不能加到会议聊天；Teams 聊天中不支持文字生成图像。
  • 没有公开的数字硬限制，但暗示很严格：微软对每会话 prompt 数、每人每天图像生成数、每人每天文档创建数都没有官方公开数值，只写"Standard access and limits apply"。这就意味着一旦你真重度用，碰到天花板都不知道自己撞在哪。
  • 自定义引擎 Agent 仅支持独立 + Teams App：Copilot Studio、Teams SDK、Azure AI Foundry 搭的"自定义引擎 Agent"，不能以原生方式出现在 M365 Copilot 聊天界面里——只能作为独立 App 或 Teams 里的独立 bot。
  • 分发路径依旧很重：Teams Admin Center / M365 Admin Center 上传 zip 包的流程虽在简化，但对任何中小型团队而言都是"要先找 IT admin 搞一搞"。和 Slack 开发者在自己 workspace 里 hermes sideload / Bolt 一键跑通完全不在一个量级。

3. Slack Agent 开发面：响应循环、会话 API、事件订阅

docs.slack.dev/ai/developing-agents 把 Slack Agent 的开发流程写得很直白，只有一个核心循环：Receive Input → Reason → Call Tools → Stream/Render Output → Repeat if needed。听起来很简单，但每一步 Slack 都给了一等公民 API。

3.1 声明 App 为 Agent 时自动得到什么

在 api.slack.com/apps 里进入 App 设置，Agents 特性一开：

  • 自动获得 assistant:write scope（含建议提示 + 线程标题定制）
  • 可以填 Agent overview 介绍，用户发现时一眼看懂角色
  • 可以订阅 Agent-specific 事件，不是老的 Bot 事件

3.2 事件订阅（消息输入入口）

开发指南里强调：开启 App Home、在 Event Subscriptions 中订阅 message.channels / message.groups / message.im / message.mpim、订阅 app_mention。Agent 收到消息是事件驱动，不是轮询——这和 Teams Copilot 的"用户在会话里问一句、Copilot 跑 Graph 再答"的同步模式根本不一样。

3.3 Agent Sessions API（会话生命周期是一等 API）

这是 Slack vs Teams 最狠的架构差距之一。agents.sessions.setStatus 和 agents.sessions.rename 两个方法（替换了旧 assistant.threads.*）让 Agent 能向用户暴露：

  • Status：active、processing、suspended、closed 四种生命周期状态
  • Title：会话友好标题，便于用户回溯
  • Stop 按钮：Agent 工作时，用户点一下就能停
  • 订阅视图：用户看到已订阅的 sessions，置顶的先显示，按时间排列；用户可以 pin、rename、archive

Teams 里对应的东西是什么？答：没有独立的"Agent 会话生命周期 API"。 Copilot 会话线程就是 Teams 普通聊天线程，用户没有"processing→suspended→closed"的显式状态指示，也没有 stop 按钮。如果 Copilot 调工具超时或出错，用户只能看到一条报错消息。

3.4 工具的调用与流式渲染

Agent 响应循环中"Call Tools"和"Stream/Render Output"两步是紧密配合的：Agent 每次调工具，用 Block Kit 把工具状态渲染在消息里（正在查 Salesforce、正在生成报告、正在等你确认），输出是流式的，不是等所有工具跑完再发一句话。

Teams Copilot 的调用"插件/动作"虽然也能流式，但 Teams 里没有"工具渲染 Block"这个概念——用户只能看到 Copilot 在打字，最多看到一个"我正在查 XXX"的文本提示，没有结构化状态卡。对于企业 Agent 的可控感，两者之间的体验差距就是"看直播"和"听广播"的区别。

4. Slack Agent 的三条设计原则（Teams 一条都没原生做到）

docs.slack.dev/concepts/agent-design 开门见山列了三条。注意这些不是"建议"，而是 Slack 用一整套产品和 API 强约束出来的。

MERMAID_BLOCK_0

原则一：一切行动可见 + 关键操作要人确认

Slack 的要求写得非常强硬：
1. Agent 每一个动作、每一个决策，用户都要能看懂。
2. 任何"有现实后果"的操作（发邮件、审批、更新记录）必须显式人工确认。
3. 失败设计是主设计，不是事后补——Agent 会犯错和幻觉，用户必须清楚发生了什么并且能继续工作。

Teams Copilot 今天的现状：状态是隐式的（打字中 vs 真在查外部工具从消息里只能猜）；确认弹窗是通用的 Modal Prompt，没有和具体动作绑定的结构化确认 UI；出错时用户常常看到一条"AI 未能完成该操作，您可以重试"的泛化文本——和第三条完全相反。

原则二：Agent 在工作发生的地方，不抢镜头

Slack 明确说：不要把人拉到别处去跟 Agent 交互。好的 Agent 是嵌入在已有工作空间里（channels / canvas 等）的上下文感知工具。所以 Slack 的 Agent 直接以一个 bot 用户身份出现在频道、DM、群聊里；@-mention 就能用；消息线程就是 Agent 线程；画布（Canvas）、Huddle 附件也被 Agent 平等消费。

Teams Copilot 的体验恰恰相反：很多时候你需要"打开 Copilot 侧边栏""切到 Copilot 标签页""从右侧 Agents 列表里挑一个"。Agent 不是工作流的一部分，而是一个你得主动切过去访问的平行面板。对重度协作的团队，这意味着每次要用 AI 都要换焦点。

原则三：Agent 天然不安全，所以护栏、权限、人在环路必须作为工程需求提前建

Slack 直接写："自主工具+无拘无束的信息和创造权限=真实世界伤害。开发者有义务把 guardrails、permissions、human-in-the-loop checkpoints 建成工程需求，而非事后考虑。"具体落地在：
- Agent 绝对不能读/取/用调用用户自己无权访问的信息（一个文件、Canvas、List、Salesforce 记录，用户正常打不开，Agent 也绝不能打开来做上下文或生成信息）
- Huddle 纪要、会议总结、笔记遵循同样的分享可见模型
- Agent 外观必须明确标记 AI，名字/头像/描述第一时间告诉用户"我是 AI 不是人"

Teams 侧这块其实合规层面做得不差（企业 SKU + DLP + 敏感度标签），但Agent 自身的权限边界没有原生镜像到 Teams 数据模型——例如 Teams 中 Copilot 连接外部工具时，用户对它能看到什么、不能看到什么的可控性远低于 Slack 的"调用用户可见 = Agent 可见"强约束。

5. Agent 在 Slack 中"怎么出现"（外观、发现、透明性）

docs.slack.dev/concepts/agent-design 里"How agents show up in Slack"一节几乎是给产品经理写的教科书：

5.1 外观与命名（不能伪装成人）

Agent 的名字、头像、描述必须第一时间传达两件事：它是 AI、它做什么。

  • 命名优先"功能"、不要"个性"。比如 Recruit Assistant、Deal Desk，用户一眼懂。
  • 描述写真实功能边界，不要写愿景式的"赋能团队、创造未来"。
  • 头像要用 Slack 内置的 Agent 几何图案生成器或者公司 logo 但明确标"AI agent"。
  • 开发者可以写一个 advanced disclosure，点进去展示"这个 Agent 调了哪些工具、读了哪些数据源、数据出不出本组织"——这是企业采购决策人最在意的信息。

Teams Copilot 列表里的 Agent 元数据相对简陋：名称 + 一行简介 + 图标。很少显式告诉用户"我会调用哪些外部 API、我有没有权限读写你的 SharePoint 文档库。"

5.2 Agent Discovery（怎么被找到）

  • Slack 全局搜索里搜 Agent 名称 / 功能关键词就能匹配
  • Channel 内的 /agent 命令或"添加成员"里可以加 Agent，体验和邀请真人一模一样
  • 一个 workspace 内部开发的 Agent，可以选 Undistributed（内部用不对外）或发布到 Slack Marketplace（跨组织分发，有一套完整的评审和安全合规）

Teams 中声明式 Agent 的分发路径是"打包 zip → Teams Admin Center 上传 → 管理员全局或部门部署"。对于自服务发现（工程师自己写一个小 Agent 给组里用不用走 admin 流程），Teams 支持侧加载（sideload），但需要 App Setup Policy 允许，对大部分受管制企业基本等于禁用。

6. 工具怎么渲染：Block Kit 不是消息格式，是 Agent UI 语言

很多人把 Slack Block Kit 理解成"好看的消息格式"，其实对 Agent 开发而言，Block Kit 是 Agent 的 UI 引擎：

  • 状态通知卡：Agent 在处理任务时，每调用一个工具就更新一张 Block Kit 卡片（Running → Done/Failed + 用了哪些参数），用户可以不看 Agent 输出的大段文字，直接看卡片知道"进展到哪、是否卡在某一步"。
  • 人工确认交互：任何写操作，Agent 不直接执行，而是发一张带两个 Primary Action 按钮的 Block Kit 卡片："批准执行""取消"。点击按钮后 Agent 才继续。这是真·人在环路，不是口头上的。
  • 结果可视化：Agent 生成的报告不是纯文字，可以用 Section + Fields + Image Blocks 渲染表格、图表预览、附件卡片。
  • 会话标题自动生成：Agent 用 agents.sessions.rename 在任务完成后把线程标题更新成"XX 合同审核（2026Q3 · 通过）"，方便用户日后搜索回溯。

Teams Copilot 的自适应卡（Adaptive Card）技术上能做类似的事，但 Copilot 不会在默认体验中给 Agent 自动渲染工具状态卡——你需要自己写声明式 Agent + Action，而且输出和对话的混合呈现效果远不如 Slack Block Kit 顺滑。

7. 权限与安全：Agent 不得越权、人的边界就是 Agent 的边界

Slack 文档用了非常硬的措辞，我直接翻译几句核心：

An agent shouldn't be able to read, access, or use information that the invoking user wouldn't be able to access on their own.

Agent 不应该读、取、用调用用户自己无权访问的任何信息。这是硬性要求，不是建议。

If the invoking user can't open a file (canvas, list, Salesforce record, etc.) normally, the agent shouldn't use it for context or to generate information.

如果调用用户正常情况下打不开那个文件（Canvas/List/Salesforce 记录等），Agent 就不得把它当作上下文或用来生成信息。

Huddles follow the same sharing model. Transcripts, meeting summaries, and notes should not be used for generating responses in an agent conversation if the user can't access them.

Huddle（Slack 的音视频会议）遵循同一分享可见模型。用户访问不了的纪要、总结、笔记同样不得被 Agent 用来回答问题。

硬到什么程度？这意味着 Agent 的工具层实现里必须有一面"权限镜子"——每次准备读一个外部资源前，先通过 Slack API 查询"当前调用用户对该资源的可见权限"，不满足就直接跳过，而不是"先拿到数据再过滤"。

Teams Copilot 的权限模型对 M365 Graph 原生资源（邮件、SharePoint 文件）天然正确，因为 Copilot 以当前用户身份去访问 Graph。但一旦接入第三方插件 / 声明式 Agent 的外部 API，这面镜子就不存在了——插件鉴权是插件自己的事，Teams 不会帮你校验"当前用户对被查的数据有没有权限"。合规团队必须自己去审查每个外部工具。

8. 典型场景对比：Deal Desk Agent / SDR Agent / HR 服务 Agent

把上面的架构差距，放进三个最典型的企业 Agent 场景里落地比较：

场景 Slack Agent 的实现方式 Teams Copilot 能做到吗？ 差距在哪
Deal Desk 合同审核 Agent Channel 中 @Deal-Desk，Agent 读取合同附件（Canvas/PDF）、查 Salesforce 对应 deal 数据，生成风险清单 + Block Kit 卡片+确认按钮，用户批准后 Agent 将结论写入 Salesforce 并 @Sales 和 Legal 通知 可以用声明式 Agent + SharePoint 知识源 + Power Platform Connector 近似实现，但：① 审批确认非结构化（普通模态）；② 跨对话无长期记忆；③ @-mention 分发弱（需在 Agents 列表挑） 流式工具卡、结构化审批、Channel 原生工作流协作
SDR 外呼代理（24/7 跟线索） Agent 常驻 Prospect Channel，响应客户问题、处理异议、基于 CRM+外部数据安排会议，异步执行（下班后还在跑，次日早晨把结果发到频道） Copilot 无异步任务概念；Teams Chat API 不支持长任务；Cowork 只在 M365 Chat 个人侧 异步后台执行 + 群组持久身份 + 独立模型绑定 + 交接记忆
HR 服务 Agent（内部政策+入职流程） Agent 用知识库工具（Notion/Confluence/Gmail 政策库）回答问题，越出 HR 边界时自动挂起转人工；记忆每位员工的入职阶段；HR 管理员可以在 Admin Panel 中编辑 Agent 话术 声明式 Agent + SharePoint 知识库是目前主流；但转人工是手动跳转、不是挂起态（suspended）恢复；分阶段记忆不原生 Suspended→恢复生命周期（sessions API）、工具级权限边界、记忆分员工阶段隔离

Deal Desk 场景是 Slack 最典型的胜利：全流程在同一个 Channel 里发生，Agent、Sales、Legal、RevOps 全部在一起协作，Agent 的每一步都公开可见、可追问、可停可继续。Teams 中你需要"频道 + Copilot 侧边栏 + SharePoint + Power Automate"多个面切换。

9. 选型建议：什么时候选 Teams、什么时候转 Slack

选 Teams Copilot 而不折腾的场景：

  1. 公司 80% 数据在 M365 Graph（Outlook、SharePoint、Office 文档、Teams 会议纪要）。Copilot 对这些数据的原生读写能力没有任何第三方能打。
  2. 合规、合规、合规——金融、政府、医疗、军工行业，M365 E5 以上的合规栈已经很完整，IT 不愿意为了更好的 AI Agent 体验再引入一套新合规工具。
  3. 会议是工作的主轴。Teams 视频会议质量、字幕、录制、Live Event、大型 Webinar 能力在企业里是顶级的，Slack Huddle 根本不在一个量级。
  4. 全员 Office 桌面套件已经用了很多年，迁移成本极高。

必须考虑 Slack 的场景：

  1. 你真的需要"Agent"，不是"AI 助手"。对比第 1 节的定义——要自主、要长期记忆、要跨回合规划、要调多工具多系统做目标——Slack 给的是真正的 Agent 开发平台，Teams 给的是 Copilot 聊天面加声明式元数据。
  2. 工作重心不在 Office 文档而在 SaaS 工具链。Salesforce/GitHub/Jira/Zendesk/HubSpot/Stripe…… Slack 有 2,600+ 集成，每一家都有深度的 first-class API，Agent 用工具时不需要额外连接器。
  3. 你想让工程师自己写 Agent，不走 IT admin。Slack Workspace 中开发者可以快速实验、侧加载、迭代；Teams 的声明式 Agent 分发在大多数公司中仍然需要 IT 介入。
  4. 团队文化是"频道协作 + 透明化信息流转"，不是"邮件 + 会议 + SharePoint 文件夹"的文化。

混合方案（推荐给大公司真做 Agent 的团队）：

  • Teams 留作沟通和视频会议的主面，会议纪要、邮件、文档、日历场景用 Copilot。
  • Slack 作为"Agent 操作系统"，部署 Deal Desk、SDR、HR Service、On-Call 等真正需要 Agent 自主工作的场景；跨组织（客户、伙伴）频道同样用 Slack。
  • 中间用 Slack + Microsoft 365 双向集成（Slack 官方已经提供，基本覆盖邮件/日历/文件/会议通知）把两个面打通。

最后一句直白的话：Teams 不烂，它只是产品的"主坐标系"是会议和 Office，不是 AI Agent。 而 Slack 从 2025 年下半年起把 AI Agent 设成了自己的主坐标系——整个平台的 API、UI、权限模型、分发机制、安全原则都围绕"Agent 是人一样的工作成员"重写了一遍。你的团队工作重心落在哪个坐标系，就该选哪个平台。

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-09-02 20:33  iTech  阅读(7)  评论(0)    收藏  举报