昨天下午，我们团队的一位工程师在SaaStr大会上观看了Anthropic演示其内部GTM技术栈，截了一张幻灯片，然后向Zero提了一个问题：这些工具里我们缺哪些？ 六小时十九分钟后，Snowflake已在生产环境中向所有Zero用户正式上线。这是我们一年内发布的第180多个集成，而且越来越多地，下一个集成的编写者根本不是工程师。以下是让这一切成为可能的框架，以及构建在其上的内部技能。
没人告诉你的关于智能体平台的事
LLM就像一个装在瓶子里的大脑。单靠它自己，它可以为你写一首关于数据仓库的诗，但它实际上无法打开数据仓库。将聊天机器人变成智能体的东西——你的团队真正为之付费的东西——是智能体能否深入你已在使用的工具并在其中完成工作。
我们把这种触达能力称为连接器层。经过一年的Zero构建，我们认为它是智能体产品中最重要的基础设施。因此我们自己构建了它。更重要的是，我们围绕它建立了一套工作流，让团队中的任何人都能编写连接器。
为什么不用MCP，为什么不用Zapier
这两个方案在早期都有人问过我们。它们各有所长，但都不是我们所需要的。
MCP是一个协议，而不是一个产品。对于希望自己的服务能被任何LLM访问的工具开发者来说，它非常出色。但目前部署的MCP服务器会向模型提供一份工具列表，并信任模型能安全地调用它们。它没有按组织划分的凭证保险库，没有限制哪些端点可以被访问的防火墙，也没有将调用追溯到授权人的审计日志。对于一个产品来说——其中一个智能体可能会操作客户的生产环境Stripe，另一个可能会在客户CEO的Gmail中起草邮件——"信任模型"并不是一种安全模型。
Zapier式集成平台解决的是另一个问题：它们将确定性触发器与确定性动作连接起来。智能体的工作方式并非如此。智能体会在思考过程中临时决定下一步是查询Snowflake，然后创建一个Linear工单。它需要的是立即获得凭证、有范围限制的HTTP客户端和审计追踪，而不是一个预先构建好的流程。
因此，我们构建了那个看似无聊的东西：一个集成注册表，其中每个条目都包含认证元数据、将哪些密钥注入沙箱的环境映射、允许访问的主机防火墙，以及处理OAuth或令牌特殊情况的小型处理器。这就是基础设施。
但基础设施并不是这个故事中最有趣的部分。最有趣的部分是在它之上发生的事情。
让每个人都能编写连接器的技能
新的SaaS工具大约每天两次进入我们的集成待办列表。有些来自客户需求，有些来自团队成员发现Zero无法完成他们需要的事情，有些来自商务拓展对话——潜在客户的技术栈中包含我们尚未接触过的工具。
如果每一个都必须经过工程师的队列，我们每周只能发布一个。而我们每天能发布一个。
原因在于一个我们称之为连接器编写技能的内部工具。它是一个Zero技能，与我们向客户发布的技能形式相同，但指向我们自己的代码库。当团队中的任何人说"我想添加Notion连接器"时，Zero会引导他们完成整个过程：
- 从用户场景出发。 用户实际上想用这个工具做什么？"查询数据库"、"创建页面"、"在工作区中搜索"。在触碰任何文件之前，该技能坚持要有一个具体的用户故事。连接器的目标是实现智能体能力，而不是穷举地封装一个API。
- 确定认证形式。 OAuth、API令牌，或两者兼有。该技能了解每种形式的含义：对于OAuth，是同意界面和重定向管道；对于API令牌，是按组织的密钥注入以及用户从哪里获取令牌。编写者选择与工具匹配的形式，后续一切都由此推导出来。
- 将端点映射到场景。 不是"封装整个REST API"，而是仅选择满足用户故事所需的少数端点。三个精心挑选的端点胜过四十个智能体从不调用的端点。
- 生成十二个文件。 注册表条目、处理器、防火墙规则、平台图标、环境映射管道，以及教Zero如何使用连接器的面向智能体的技能。技能负责生成脚手架，编写者负责表达意图。
- 提交两个PR。 一个提交到连接器框架，一个提交到技能库。两者都由工程师审查，但审查的重点是正确性，而不是教编写者如何使用框架。
过去需要大量内部知识的事情（选哪种认证形式、选哪些端点、哪两个代码库中的哪十二个文件、防火墙规则如何与动态子域名组合）现在都由技能本身承载。编写者带来的是对用户的理解，技能带来的是脚手架。
这就是设计师、商务拓展负责人或产品经理最终能够发布连接器的原因。他们知道用户想要什么，技能知道其他一切。
案例研究：昨天的Snowflake
昨天，Anthropic在SaaStr大会上演示了他们的内部GTM技术栈：Salesforce作为系统记录，Clay用于数据丰富，LeanData用于路由，Gong用于通话，Jira用于工单，Intercom（Fin）用于支持，Ironclad用于合同，Snowflake作为数据仓库。[演讲链接]
我们的一位工程师截了那张幻灯片，将其发给Zero并提了一个问题："这些工具里我们缺哪些连接器？"
以下是随后发生的实际时间线。所有时间均为PDT。
16:59。 截图到达。Zero将其与连接器目录进行比对：10个工具中有7个已存在（Salesforce、Gong、Jira、Intercom、Ironclad、Gmail、Slack）。三个缺失（Clay、LeanData、Snowflake），Snowflake被标记为最有价值的，因为数据仓库是GTM技术栈的基础。回复在17:00到达。
17:01。 追问："这些工具中哪些可以作为API令牌连接器来实现？"Zero查阅了认证文档：Clay有个人API密钥，Snowflake最近发布了程序化访问令牌，LeanData仅支持OAuth且与Salesforce绑定。 结论在17:02给出：先做Snowflake（价值最高，认证最简洁），然后是Clay。
17:04。 工程师说"开始"。连接器编写技能接手。到17:07，它已将Clay排除在外（唯一的公开接口是按表的Webhook，没有真正的连接器可构建），并确认了Snowflake的形式：SNOWFLAKE_PAT密钥 + SNOWFLAKE_ACCOUNT变量，通过bearer认证访问Snowflake REST API和SQL API v2，动态子域名防火墙规则参照Zendesk建模。
17:35。 两个PR在同一分钟提交：
vm0-skills#176：面向智能体的技能。如何编写Snowflake SQL、格式化结果、在瞬态错误时重试。vm0#13356：连接器本身。注册表条目、PAT处理器、防火墙生成器、平台图标、环境映射管道。
18:22。 技能PR合并。
18:42。 连接器PR合并。
18:52。 发布PR自动创建。
23:18。 [email protected]及其余发布列车部署到生产环境。Snowflake对所有组织正式上线。
从"Anthropic技术栈截图"到"Zero可以查询你的数据仓库"，仅用了六小时十九分钟。一位工程师，一次对话，零次移交给"连接器团队"。
这里的效率并不是因为工程师速度快，而是因为连接器编写技能承载了过去需要大量内部知识的部分：选择哪种认证形式、哪些端点映射到用户场景、哪十二个文件需要落地到哪两个代码库、防火墙规则如何与动态子域名组合。编写者写的是意图，技能写的是脚手架，生产环境完成了剩下的事情。
这就是这套框架带给我们的价值。不仅仅是速度（尽管速度确实很快），更重要的是谁可以承担这项工作。Snowflake的编写者碰巧是一位工程师，但他不必是。
为什么API令牌是一等公民
这个注脚值得单独提出来，因为这是一个经过深思熟虑的设计选择，曾让一些人感到意外。
大多数智能体平台将OAuth视为唯一正统的认证方式，将API令牌视为遗留工具的备用方案。我们恰恰相反。API令牌在我们的连接器模型中是一等公民，拥有相同的同意界面、相同的按组织保险库、相同的审计追踪、相同的防火墙执行。
原因有两个。
第一，API令牌认证的首次使用时间更短。Snowflake正是出于这个原因最近发布了程序化访问令牌：长期有效、可限定范围、可撤销的凭证，不需要经历OAuth流程。拥有PAT的用户可以在不到一分钟内在Zero中开始工作。OAuth流程，即使是简洁的那种，也需要更长时间，并且对用户要求更多。
第二，OAuth并非总是可用。一些企业工具根本不提供OAuth，或者将OAuth功能锁定在企业版SKU之后。将API令牌视为同等地位（而非备用方案）意味着我们可以正确支持这些工具，而不是将它们留在"即将推出"的墓地里。
昨天发布的Snowflake连接器使用的是API令牌。发送客户邮件线程的Gmail连接器使用的是OAuth。两者都经过相同的框架、相同的技能、相同的审查。编写者选择与工具匹配的形式，框架让两种形式的构建成本都很低。
180多个集成真正解锁了什么
数字本身不是重点。重点是在这种密度下，智能体不再是你召唤的工具，而是你生活其中的环境。
当Zero同时拥有连接到你的CRM、数据仓库、支持收件箱、设计工具和代码库的连接器时，它能做任何单一集成智能体都无法做到的事情。它可以拉取Snowflake查询，与未解决的Linear工单进行交叉比对，然后在客户成功团队所在的Slack频道发布摘要。它可以阅读一段Gong通话记录，找到潜在客户询问的功能，检查它是否在路线图中，然后起草跟进邮件——所有这些一气呵成。
每个新连接器带来的价值不是线性增长的，而是组合式增长的。第180个连接器比第1个更有价值，因为它可以与之前的179个组合使用。
这就是这套框架背后的赌注。而技能背后的赌注是：复利的速度取决于你团队中有多少人被允许向这个堆栈中添加内容。
下一步
我们正在努力向客户开放连接器编写技能。如果你正在为团队运行Zero，并且需要与某个内部工具集成（你的计费系统、数据仓库、自定义内部管理面板），那么昨天发布Snowflake所用的工作流，将会是你发布自己集成时所用的工作流。相同的脚手架、相同的认证模型、相同的防火墙、相同的审计追踪，只是换了一位编写者。
如果这让你感兴趣，我们很乐意交流。
