智能体连接器平台

这个品类是什么。

一个只跟模型说话的智能体什么都不需要。而一个必须读这位用户的收件箱、更新这位用户的 CRM 记录、或提交这位用户的工单的智能体，需要一份"按用户、按提供方"的凭据，而这个需求的乘法很糟糕：十个集成乘十万用户，就是一百万份需要获取、存放、刷新与吊销的凭据。智能体连接器平台是一个把这个问题接管过去、并把结果暴露成可调用工具的托管服务——而且越来越多是通过 MCP 暴露，于是任何智能体都能指过来。Arcade、Composio、Pipedream Connect 与 Nango 是好认的例子；但定义这个品类的是它干的活，不是厂商名单。

它容易与两个邻居混淆。智能体框架决定你如何表达那个调用工具的循环；连接器平台提供工具本身，以及调用它们所用的身份。托管智能体运行时运营那个循环，通常也自带一个工具网关——往往更薄，这也正是两者常被一起使用的原因。

一次采购里的三个产品。

这个品类里的每个平台，实际上都是捆在同一个 URL 之后的三项服务。而它们各自有多难替换，差别极大。

• 连接器目录——与你的用户本来就在用的 SaaS 产品之间的预置集成。这是被拿去宣传的那个数字，也是这次采购里最不经久的部分。它在处处相同的那十来个产品上很深，在长尾上很浅，而长尾正是你差异化所在的地方。每个平台也都支持自定义工具，所以把缺的补上，是你真做得动的活。
• 令牌保险库——一个加密的、按用户按提供方存放的凭据库，负责跑 OAuth 挑战、刷新与轮换令牌、从 scope 不匹配中恢复，并在执行时把密钥注入到对外的调用里。没人拿它做营销。它是那种要花一个季度才能做对、还要靠一次安全评审才守得住的部分。
• 工具重塑层——改参数名、隐藏字段、裁剪响应、决定厂商那五十个操作里哪些要呈给模型。这是个潜伏的关键特性，因为多数厂商 API 是为"读文档的开发者"设计的，而不是为"在 token 预算下做选择的模型"设计的。见面向智能体的工具设计。

值得付费的性质是：模型从不接触令牌。

这些平台共享的那套机制值得精确表述，因为它是一道真实的安全边界，而不只是便利。你的智能体按名字请求一个工具，并带上一个用户标识。平台在服务端解析出该用户的凭据，并在执行时把它注入到对外的请求里。回到模型那里的只有响应。

另一条路——在你的智能体循环内部拼出一个 Authorization 头——会把一份有效凭据放进与不可信工具输出同一个上下文窗口。一旦它进了上下文，一份被检索到的文档里的提示注入就有了可以索要的东西。而一份从未进过上下文的令牌，没法被话术骗走，这就把一整类攻击变成了非事件。

从权限的角度看，这也改变了智能体是什么：它以某个具体用户的身份行动、带着那位用户的 scope，而不是以一个持有所有人权限并集的服务账号行事。这个区分正是智能体身份与权限的全部主题，而连接器平台是团队最终站到正确一侧的最常见途径。

怎么选，以及那件唯一无法事后补救的事。

真正要紧的对比很短，而且不是目录条数。先问计量表跑在什么上，因为这些单位在结构上就不同——按工具调用、按执行秒数、按已连接账号、按授权挑战——而每一种课的都是不同形态智能体的税。一个话多的循环在其中一种下很便宜、在另一种下则是灾难，所以要拿你自己的用量在每一种下各算一遍，而不是去比档位标价。再问凭据库能不能落在你自己的基础设施里，因为这条要求比任何别的标准都更快地砍掉选项，而且它与目录大小呈反相关。再问你的 trace 会变成什么样。

然后问那个没人写在定价页上的问题：同意授权页面上写着谁的名字？当你的用户点下"连接 Gmail"，那个 OAuth 对话框会写出一个应用名。在托管平台的默认路径上，那个名字是平台的，不是你的。这里的每个平台都支持你使用自己的 OAuth 客户端 ID，而在采纳当天做掉它，代价不过是花一天去各家注册应用。

这一天花得值，因为令牌是针对某个特定 OAuth 客户端签发的。以后再换那个客户端，就意味着每一个既有用户都要重新授权——那不是一项迁移任务，而是一条转化漏斗，总有一部分人再也不会回来。一位把你厂商的应用加进白名单的企业管理员，批准的是你的厂商而不是你；而一旦你换厂商，那场评审还得重来一遍。

延伸：面向智能体的受限凭据讲一份被注入的凭据该被允许做什么，第三方工具漂移讲目录如何在你脚下变化，委托访问与同意记录讲那份令牌之外、才是真正记录的东西，MCP 注册表与分发讲这些工具集是怎么被发现和安装的。