Teams 给第三方 AI Agent 设关卡：默认丢进等候室，组织者点头才能进

微软今天（7 月 6 日）在官方渠道确认，Microsoft Teams 会议正式启用一套针对第三方 AI 机器人的准入策略：不管是 Otter、Fireflies，还是自家搓的 Bot，只要不是本租户内的可信身份，进会议前统统先在等候室（Lobby）排队，会议组织者点了「允许」才能坐上桌。

这个策略叫 Manage external bots and their access to meetings，已经上到 Teams 管理中心，默认启用。管理员可以按用户或用户组下发，也可以按需关掉——但微软的意思很明白：默认打开这件事本身，就是产品态度。

这不是新问题，是欠了两年的账

开会时突然弹进来一个陌生的「AI Notetaker」，是过去两年 SaaS 会议软件普遍的尴尬。Zoom、Google Meet、Teams 都遇到过：用户 A 在自己日历上挂了个 Otter，用户 B 组织的会他也顺手拉了进来，Otter 不请自到、全程录音转写，然后把摘要发回 A 的邮箱。

从产品逻辑上讲，这叫「代表用户参会」；从合规和安全的角度讲，这叫未经授权的第三方数据出境。尤其是律所、投行、医疗这种客户，一直在给微软施压。

微软之前的解法是 CAPTCHA——让 Bot 进会议前先过一道验证码。这个方案的问题在于：

• 它挡的是「非人类」，但现在 Agent 早就能过 CAPTCHA 了，尤其是带视觉模型的
• 它没有把决策权交回给会议组织者，而是把安全责任推给了 Bot 厂商的「诚信」
• 管理员在 Tenant 级别几乎没有可观测性，不知道谁的会议来过什么 Bot

新策略把这三件事一次性解决：Bot 身份识别 + Lobby 拦截 + 组织者显式审批 + 管理员集中策略。CAPTCHA 会逐步下线，被新流程整体替换。

技术上是怎么识别「外部 Bot」的

微软没有把细节完全铺开，但从 Teams 现有的 Bot Framework 和 Graph API 结构能推断个大概。

Teams 里的机器人分几类：

1. First-party bot：微软自家，比如 Copilot、Whiteboard 助手
2. Tenant-installed bot：管理员在 Teams admin center 装过、走过 Azure AD 授权的
3. User-authorized bot：用户个人在 Teams 应用商店装的
4. External / Federated bot：通过用户日历邀请、以来宾身份加入的第三方 Agent

新策略针对的是第 4 类——它们通常通过 Microsoft Graph 的 onlineMeeting API 或者干脆用一个来宾账户加入。Teams 服务端会在参会者进入时校验其 App ID 或身份来源，命中「外部 Bot」特征就直接扔进 Lobby，不给组织者放通知就不予接入。

这里有个隐藏的产品判断：微软默认「用户自己装的第三方 Agent」也算外部。这一刀切下去，等于把 Otter、Fireflies、Read.ai 这类明星应用的自动入会体验直接干掉。它们要么去谈 Tenant 层面的 admin consent，要么接受每次都要被人工放行。

这对开发者意味着什么

如果你在做会议类 AI Agent，尤其是要接 Teams 的，接下来几个月要重新算账：

• 入会成功率会掉。以往用户日历里挂个 Bot 就万事大吉，现在每次会议都要组织者手动点一下。企业用户里，会议组织者能不能记得点，是个玄学。
• Onboarding 路径要变。之前是 C 端用户装应用，现在最好推动到 Tenant admin 装应用、走 admin consent。这意味着销售模型从 PLG 往 SLG 靠。
• 要考虑降级方案。如果 Bot 被挡在 Lobby 又没人放行，Agent 侧应该有超时策略，回退到「让用户会后上传录音」这种异步方式。

对开发者比较友好的一点是：新流程留了口子。管理员可以通过 PowerShell 或 Teams admin center 把某些可信 Bot 加白，一次性解决整个租户的准入。厂商未来的商业动作，大概率会围绕「怎么让企业 IT 把我加白」展开。

和 Google、Zoom 的对比

横向看一眼三家：

| 平台 | 第三方 Bot 准入 | 默认策略 | 管理员集中管控 | | --- | --- | --- | --- | | Teams（新） | Lobby + 组织者审批 | 默认拦截 | 有，Tenant 级 | | Google Meet | 依赖 Workspace 域策略 | 部分拦截 | 有，但粒度粗 | | Zoom | Companion Mode / Waiting Room | 视账户设置 | 中等 |

Teams 这次是把「默认拒绝」摆到了最前面，是三家里最激进的。这也是它这两年在企业市场的一贯打法——先把安全和合规拉满，功能体验的锅让生态伙伴去背。

一个更大的信号

把这件事放到今年 AI Agent 的语境里看，其实是Agent 时代身份和权限体系的一次早期实践。

2025 年下半年到 2026 年，几乎每家 SaaS 都在谈「Agent as a User」——让 Agent 有自己的身份、自己的权限边界、自己的审计日志。Salesforce 的 Agentforce、Google 的 Agentspace、Microsoft 自家的 Copilot Studio 都在铺这套。

但一旦 Agent 有了「用户级」的能力，它就必须接受「用户级」的准入约束。Teams 这次做的事情本质上是：把 Agent 从「用户的附属工具」升格为「独立参会者」，然后按照对独立参会者的标准审批它。

这是对的方向。接下来一年，你会看到更多 SaaS 平台把 Agent 从工具栏挪进权限系统。会议只是第一个战场，文档协作、代码仓库、CRM 都会跟上。

一点小吐槽

从产品体验角度，这个默认策略对小团队并不友好。三五个人的初创公司，天天开会都要组织者手动放 Bot 进来，用不了两天就会去 Teams admin center 把这个策略关掉。真正吃到红利的是有 IT 部门、有合规审计需求的中大型企业。

微软很清楚这点，所以给了细粒度的策略下发能力——你可以对高管、法务、财务这类用户开启，对普通研发关掉。但这套精细化配置对没有专职 IT 的团队来说，就是纯粹的心智负担。

如果你在做面向 Teams 的 AI Agent 产品，眼下值得马上做的事只有一件：去测一下你的 Bot 现在还能不能默默入会，如果不能，先出个通知用户「请组织者放行」的 UI。别等到用户投诉才发现自己被 Lobby 挡了。

---

参考来源

• 微软 Teams 加强第三方 AI 智能体权限管理，需会议组织者确认后方可放行 - IT之家 — 新策略的官方细节和管理中心配置说明