每一个 AI 编排平台都会挂出一面 logo 墙，而每一面 logo 墙回答的都是错的问题。集成数量告诉你的是厂商建了什么。它一句也没告诉你：当你真正依赖的那个工具不在墙上时，会发生什么。
那才是值得问的问题，因为答案通常是同一个：你提一个需求，你等着，然后厂商把它和其他所有需求一起排优先级。你的工作流被卡在别人的路线图上。
AI 编排平台连接什么，又连不上什么
把这个品类里任意三个平台放在一起比，你会看到同一个形状。一份庞大的官方连接器目录，由厂商建设和维护，外加一个给其他一切用的通用 webhook。目录是产品。webhook 是道歉。
这个模式有一道永远不动的天花板。不管存在多少个连接器，这个集合都是有限的，而且由你以外的人控制。而被建出来的连接器都是热门的那些，这意味着你所在细分领域特有的工具，在结构上永远排在最后。
Crew Studio 是反过来搭的。八个原生连接覆盖多数运营者每天要用的东西。此外的一切走 MCP，也就是说天花板不再是那份目录。天花板是这个工具到底有没有 API。
所以在几个 AI 编排平台之间做有用的比较，比的不是目录有多长。比的是当你的工具不在目录里的那一天，目录后面站着什么。是一张需求表和一条队列，还是一个你不必问任何人就能对着它开发的开放标准。
原生集成
八个连接开箱即用，挑它们是因为运营者真的在这些地方工作，而不是因为它们能把墙填满。每一个都是双向的：Crew 从里面读，也往里面写。
- Gmail
- 专家读一整条邮件线索来获取上下文，然后用这个 Studio 的声音起草回复。在 Confirm 挡上，没有你什么都不会发出去。一位客服分流专家可以在你打开收件箱之前就把它理好，那是和写回复不同的一份活。
- Notion
- crew 会往你的内容库里写，不只是从里面读。一份内容计划落地时是一页页填好属性的页面，而不是一大块还要你自己重排的文本。存在 Notion 里的过往简报会成为 Studio 的上下文。
- Slack
- 读频道获取上下文，并把综述发到对话正在发生的地方。主要对和客户团队一起工作、而非单干的运营者有用。
- GitHub 和 Linear
- issue、pull request，以及读到实际发布了什么而不是计划了什么的能力。从代码仓库写出来的 changelog，准确度是凭记忆写的那种做不到的。
- Stripe
- 把营收、流失和分群数据作为简报的输入。一位读到真实数字的增长专家，给出的建议和一位读你对数字的描述的专家不一样。
- HubSpot 和 Calendly
- 商机上下文和会议排期。会前简报由 CRM 加上这个 Studio 里关于该客户的历史组装而成，而不是靠你在赶去开会路上还记得的那点东西。
看它跑一遍
连接你的工具栈
下面写的是 crew 在每个连接内部做什么，而不是那些 logo 本身。最后一张卡最要紧，而它不是一个 logo。
有一个细节比看上去重要：集成挂在 Studio 上，不挂在账户上。你的客户 Studio 连的是他们的 Notion。你的个人 Studio 连的是你自己的。两边都看不到对方的，而这正是“能不能拿来做客户工作”的分界线。
Gmail
读线索，用你的声音起草回复，留着等你批准。
Notion
往你的内容库里写，属性都填好。不只是读它。
Stripe
读分群留存，让增长简报用数字说话，而不是用你对数字的转述。
GitHub · Linear
按实际发布了什么来写 changelog，而不是按计划了什么。
其他一切 · MCP
你自己的服务器，你自己的凭证，你自己的工具。包括我们从没听说过的那些。没有需求表，没有等候名单，没有路线图投票。
集成按 Studio 挂载 · 你客户的 Notion 不是你的 Notion
MCP 改变了什么
MCP 是把 AI 系统连接到外部工具的开放标准。抛开这个缩写，它的意思是：一个工具可以用任何 AI 系统都看得懂的格式描述自己能做什么，而 AI 厂商不必为它专门建过任何东西。
这条连接不再属于厂商。
原生集成是厂商产品的一部分。MCP 服务器是你产品的一部分。你要走，它跟你一起走。
天花板从目录挪到了 API。
问题不再是 Crew Studio 支不支持你的工具，而变成你的工具到底有没有对外开放。被这样一个问题限制住，要好得多。
小众工具不再排在最后。
厂商按用户数给连接器排优先级，这在结构上就把任何特定需求往后压。MCP 没有队列。
内部工具变得够得着。
那张表格、那个内部看板、你的开发两年前做的那个东西。它们永远不会出现在任何人的 logo 墙上，而它们全都可以被接入。
这些都不会让原生连接变得没用。它只是意味着，多数 AI 编排平台的天花板是一个商业决定，而不是一个技术决定，而在你围绕一个还不存在的连接器规划一个月的工作之前，这件事值得先弄清楚。
接一个 Crew Studio 从未列出过的连接
换成别的平台，这里通常会写“联系销售”。诚实的说法是：这取决于你的工具是否已经有现成的 MCP 服务器。
如果已经有，那只是配置。
越来越多的工具会发布自己的 MCP 服务器，接入只是把 Crew Studio 指向它并完成授权。不用写代码。
如果没有，那就是开发工作。
得有人把它写出来。对开发者来说不算大工程，但它确实是工作，假装不是就不诚实了。如果你手上没有开发，这个选项对你今天而言只是理论上的。
两种情况下你得到的都是所有权。
这台服务器是你的。它既能配 Crew Studio，也能配任何说 MCP 的东西，而这个比例在这个品类里还在上升。
集成按 Studio 挂载
这是把“能拿来做客户工作的工具”和“不能”分开的那个设计决定，而它很容易被忽略，因为听起来像个细节。
每个 Studio 授权自己的账号。
你的客户 Studio 连的是他们的 Notion、他们的 Slack、他们的 Stripe。你的个人 Studio 连的是你自己的。在其中一个里工作的专家，没有任何通路能到达另一个的，这是一种结构属性，不是你设的某项权限。
结束合作只需要一个动作。
客户关系结束时，删掉这个 Studio，连接会随它一起消失。不用再去清查哪个账号的令牌还留在什么地方。
同一个工具可以被连接两次，各连各的。
两个客户都用 HubSpot，就是两个 Studio 里的两次授权。即便集成是同一个，两边也看不到对方的销售管道。
它让隔离变得可信。
如果每个 Studio 共用同一个 Gmail 令牌，封闭的记忆就没多大价值。只到语境边界为止、不到集成边界的隔离不算隔离，而多数工具正是停在这里。
这件事对谁要紧
身处细分领域的运营者。
如果你的工具栈里有一堆没人听说过的工具，目录模式本来就不可能服务你，logo 墙上的数字对你从来都不相关。
要应付客户工具栈的代理商。
每个客户带来的工具组合都略有不同。按 Studio 挂载的集成加上 MCP，是唯一撑得住这种局面的形态。
被下线过一次连接器的人。
厂商决定退役的原生连接器，会把你的工作流一起带走。你自己拥有的服务器，不会被别人退役。
预期自己工具栈会变的运营者。
两年后你用的工具不是今天这些。由“有没有 API”定下的天花板，比由别人维护的一份目录定下的天花板更耐老。
共同的线索是，这四类人都被别人的路线图卡着。那些把每一条连接都攥在自己手里的 AI 编排平台，替你决定了哪些工具值得支持、按什么顺序支持。唯一的出路，是一条你自己能搭、也能留得住的连接。
它帮不上忙的地方
什么时候集成不是你的卡点
如果你主要在文档里工作，你需要的连接可能比你以为的少。
导出一份综述再粘贴一次，不是瓶颈。瓶颈是产出那份综述。
如果你的工具没有 API，任何平台都帮不了你。
MCP 连接的是对外开放的东西。一个没有任何接口的封闭桌面应用够不着，也没有哪个厂商能改变这一点。
如果你要的是某一条连接而不是一支团队，去看工作流工具。
按触发条件把两个应用连起来，是 Zapier 和 n8n 在做的事，更便宜也更直接。Crew Studio 连接应用，是为了让一支 Crew 能在里面工作，那是另一份活。
如果你的工具栈受合规约束，先确认再连接。
Crew Studio 现阶段不提供 SSO 或 SAML。采购流程要求这些的组织应该再等等。
如果你没有开发，而你的工具也没有 MCP 服务器，就实话实说。
开放的天花板是真的，但它不是免费的。在断定这道天花板对你要紧之前，先查一查你依赖的那些工具有没有发布服务器。
并排对比
Crew Studio 与封闭集成市场的对比
有两行明显归集成市场，如果你的工具栈全是主流工具，今天的广度胜过日后更高的天花板。这笔交换只有在你依赖的某样东西不在清单上时才回本。
这场对比有一个会随时间自行化解的版本。原生连接还在持续上线，所以广度差距每个季度都在缩小，而天花板的差别是结构性的，不会缩小。这对你要不要紧，完全取决于你等不等得起。
| 能力项 | Crew Studio | 封闭集成市场 |
|---|---|---|
| 原生连接 | 上线时 8 个，还在增加 | 常有数百个 |
| 接入清单外的工具 | 可以，通过你自己的 MCP 服务器 | 不行。你只能等厂商。 |
| 谁拥有这条连接 | 运营者 | 厂商 |
| 按项目隔离 | 按 Studio | 通常按账户 |
| 接一个原生连接的步骤 | OAuth，点几下 | OAuth，点几下 |
| 接一个清单外工具的步骤 | 没有现成服务器就需要开发 | 根本做不到 |
| 今天的广度 | 更窄 | 更宽 |
| 天花板 | 这个工具有没有 API | 那份市场目录 |
| agent 在工具内部行动 | 可以，取决于该 Studio 的自主挡位 | 视情况而定 |
还没有连上的东西
当你在权衡要不要投入时，路线图比现有清单更重要，所以这里给的是诚实版本，不是预告片。
主动触达只在 Telegram 上。
WhatsApp、Email 和 iMessage 已在计划中，尚不可用。如果 Telegram 不是你本来就在的地方，为这一件事把它加上并不划算。
没有 SSO，没有 SAML。
这会卡住多数超过一定规模的公司的采购流程，我们把它写在安全页面上，而不是略过不提。
Google Drive、Airtable 和 Shopify 呼声很高，目前还不是原生连接。
这三者都已经发布或即将发布 MCP 服务器，那是我们打算走的路径，而不是一条绕行方案。
没有哪个原生连接会在自主挡位不允许时行动。
值得在这里重复一遍，因为这是运营者在授权任何东西之前会问的问题：连上一个应用，不等于授予 crew 破坏性使用它的权限。
继续读
相关
问题
关于集成的问题
Crew Studio 能连接哪些应用？
Crew Studio 原生连接 Gmail、Notion、Slack、GitHub、Linear、Stripe、HubSpot 和 Calendly，路线图上还有更多。其他任何工具都可以通过自定义 MCP 服务器接入，包括 Crew Studio 从未列出过的工具。
什么是 MCP 服务器，它为什么重要？
MCP 是把 AI 系统连接到外部工具的开放标准。Crew Studio 采用 MCP 优先，意味着运营者可以连接任何暴露了 MCP 服务器的服务，不必等待官方集成。这条连接属于运营者，不属于厂商。
Crew Studio 能代我发布或发送东西吗？
只在运营者设定的自主挡位内。在 Ask 和 Confirm 挡上，没有批准就没有任何东西离开 Studio。在 Ship on trigger 挡上，已定义的动作会在已连接的应用里执行。挡位按 Studio 配置，随时可改。
某个应用改了 API 会怎样？
原生集成会像所有集成一样坏掉，然后我们去修。这一页之所以强调 MCP，是因为它改变了谁在等：一条你通过自己的 MCP 服务器搭起来的连接，坏掉的那天由你来修，按你的时间表，而不是我们的。这就是那笔交换，直说出来，也是为什么一份固定集成清单的天花板，比它的长度更要紧。