\n\n本文指出企业对 AI 代理的适应能力取决于其 API 基础设施的成熟度。成熟的 API 门户、规范的文档及工程文化是关键，忽视这些基础建设的企业在 AI 转型中将处于劣势。
译自：The API portal is the clearest signal of whether your company can handle AI agents
作者：Nick Lucchesi
当我最近与 Kin Lane（Naftiko 的 API 布道者兼联合创始人）交谈时，我反复被生成式 AI（GenAI）的采纳过程与当年从私有数据中心向公共云迁移过程之间的相似之处所震撼。
在云计算采纳过程中，拥有强大心理安全感的公司能够更好地进行实验和快速学习，因为它们已经拥有了“允许失败”的文化。采用领域驱动设计的组织能够更好地将单体架构重构为微服务。而那些拥抱了 XP（极限编程）或敏捷开发变体的公司，则能更快速地实现独立部署的微服务。
换句话说，拥有强大工程实践和良好文化的跨国公司最能应对转型。这并不令人意外，但它确实暗示，如果缺乏对高质量 API 文档等方面的投资，公司将处于明显的劣势。
MCP 仅仅是一个 API
Lane 告诉 The New Stack，在代理化采纳过程中，最占优势的组织是那些已经拥有干净的数据管道、成熟的 API 管理、云计算熟练度以及行之有效的治理结构的组织。
“MCP 仅仅是一个 API —— 一个提供 JSON 数据的长连接 HTTP 连接。我们已经这样做很多年了，这没什么新鲜的。”
这是因为软件中的一切都是建立在预先存在的基础之上的。“MCP 仅仅是一个 API —— 一个提供 JSON 数据的长连接 HTTP 连接，” Lane 说道，“我们已经这样做很多年了，这没什么新鲜的。” 这意味着像 OpenAPI 规范、AsyncAPI 合约、API 网关、开发者门户和文档标准等产物，都成为了代理世界的原材料。
OpenAPI 规范已经描述了你的 API 操作、数据形态和语义。相同的规范可以用来生成 MCP 服务器。从此基础上，调用这些 MCP 服务器的代理技能可以从同一个源头衍生出来。
“OpenAPI 提供了那种菜单，即事实来源，” Lane 说，“‘技能’是你如何使用这份菜单——你如何点那个汉堡？Open API 将把这份菜单提供给代理。”
那些严格执行 OpenAPI 定义的组织，正坐拥一项可复用的资产，这项资产与代理的需求高度匹配。而那些将 API 规范视为事后补救，或任由规范偏离实现现实的组织，会发现转化过程相当困难。
反转中子流的极性
Lane 描述了在思考 AI 时刻的新特性时的一种概念转变。在过去的 15 年里，API 投资主要面向外部：组织通过 API 暴露资源，以便开发者可以基于其进行构建。消费者是一个已知的量：少数合作伙伴、一个开发者社区，或者规模化后的数百万次 API 调用。
随着 AI 代理的出现，这种压力的方向和体量发生了变化。
“你的 API 消费者不仅仅是 Bob 和 Fred 这种对在你的 API 上构建东西感兴趣的人，每月也就来那么几个人，” Lane 说，“你会面临这些代理发起的 DDoS。就像《黑客帝国》里的乌贼哨兵试图闯入，而不是你试图走出去并提供资源。这种极性的反转是一个巨大的转变。”
“你会面临这些代理发起的 DDoS。就像《黑客帝国》里的乌贼哨兵试图闯入，而不是你试图走出去并提供资源。这种极性的反转是一个巨大的转变。”
这对 API 治理的影响是重大的。那些已经投资于访问控制、速率限制、安全策略和细粒度权限的企业已经为这种倒置做好了准备。而那些没有准备的企业，将在运营韧性和安全态势方面面临风险。
作为 API 设计的上下文工程
我在 AI 项目中看到的另一个反复出现的问题是过度共享。防止过度共享为组织的安全团队增加了沉重负担。建立 MCP 服务器时的本能是暴露一切，从而授予代理访问平台完整 API 接口的权限。例如，Figma 的 MCP 服务器提供了对整个 Figma API 的访问权限。Lane 认为这既是一个错失的机会，也是一个潜在的隐患。
“大多数 MCP（无论是从 OpenAPI 生成的还是其他方式）都应该有更多的上下文。谁在使用它？他们需要什么访问权限？你需要将其缩小到他们完成工作所需的工具和操作。他们可以更改任何内容，还是只能读取？如果是这样，他们是可以读取全部内容，还是只能读取其中一部分？通过 MCP 进行的上下文工程是安全以及成功的关键：你到底想让代理做什么？”
这是领域驱动设计应用于新场景的体现。那些实践过限界上下文（bounded context）思维、围绕业务能力而非数据库表构建 API、并仔细思考过每种消费者类型需求的组织，拥有做好上下文工程的概念肌肉记忆。
门户作为就绪程度的代理指标
Lane 开发了一套研究方法来评估企业 API 的成熟度，通过从数百家主要组织的招聘启事、新闻稿和公共 API 文档中提取信号。他发现最可靠的领先指标之一出奇地简单：该公司是否有面向公众或合作伙伴的 API 门户？
“如果你是 Chase Bank 或 Ford Motor Company，你就会有一个 API 门户，” Lane 断言，“有很多公司没有 API 门户。它们有 API，但没有将其公开的经验。这让它们紧张得要命，从而引发了大量的内斗和政治戏码。”
在 Lane 的框架中，门户是组织流程的体现：决定公开什么，向谁公开，在什么条件下公开，配以什么样的文档，以及由哪些行动提供支持。这种经验决定了一家企业能够多有信心地响应代理的需求。
“那些对此更加紧张、说着‘我们不想把东西放出去’的公司，并不理解 API 的工作原理，” Lane 说，“它们受 AI 的冲击更大，因为它们缺乏灵活性，无法根据市场需求进行调整。”
在 AI 代理自主导航 API 接口的世界里，语义描述的质量直接影响到这些代理能代表你做什么以及不能做什么。
同样的逻辑也适用于文档、入职流程和开发者体验。那些投资于缩短首次调用时间（TTFC）、编写帮助开发者成功的文档、并为 API 消费者维持支持模型的公司，已经构建起了代理工具可以使用的脚手架。在 AI 代理自主导航 API 接口的世界里，语义描述的质量直接影响到这些代理能代表你做什么以及不能做什么。
如果你落后了，你并没有出局
如果你的雇主在 API 治理方面投资不足，情况并非毫无希望，但这需要对你的起点保持诚实。“了解你今天的能力，” Lane 建议道，“绘制出你的内部 API、内部数据和外部 SaaS 工具图谱。了解你的能力并从那里开始。”
他建议，起步较晚也有一些优势。传统组织背负着限制其选择的技术债。一家没有根深蒂固的 Oracle 基础设施和数十年积累的 API 蔓延的公司，可以在数据管道和云架构上做出更干净的决策。现代工具——用于数据的 Snowflake、当代的 API 网关和云原生架构——以五年前无法想象的方式变得触手可及。
但存在知识差距。“如果你没有那个强大的工具箱，你就必须去开发它。REST、事件、webhooks、WebSockets 或 GraphQL 各有什么好处？你需要更加谨慎，你会吸取一些惨痛的教训。”
坚持到底
Lane 对 300 多家企业的研究支持了一个更广泛的论点：AI 奖励一致性而非反应性。那些在没有建立持久 API 基础的情况下从一个趋势跳到另一个趋势的组织，现在是最危险的。而那些在治理、文档、设计标准和商业实践方面进行枯燥、复合投资的组织发现，这些投资实际上正是为此而做的准备。
正如 Lane 所说：“你的根越深，你就越不可能做出膝跳反应或情绪化反应，或者把每样新东西都看作解决方案。你不能直接跳过这些长期投资。”
MCP 奖励那些已经知道如何为可复用性而设计、为安全而治理、以及为尚未谋面的消费者而构建的组织。如果这描述的是你的组织，那么信息很简单：继续前进。如果不是，第一步就是认清你真实的处境。全 端 工智能
