软件工程界在设计 API 时始终考虑到人类开发者，因为他们具有可预测且一致的使用模式。但一种独特的新型 API 使用者正在迅速涌现：AI 代理。
与人类开发人员不同，AI 代理的行为就像一个线程。它们是基于任务的机器人，旨在实现特定目标。完成任务可能需要它们按需建立 API 连接、查询 API 并关闭连接。有了代理 AI，集成不再是静态和不可改变的概念。独特的、短暂的集成将成为常态。随着 AI 代理成为数十种编码辅助工具和平台中的常态，问题不再是“是否”而是“何时”API 设计方法会随之改变。
AI 代理将如何改变 API 和应用程序开发 无限 API 调用 让我们以航班预订应用程序为例，来看一下人工智能代理是如何改变应用程序开发的：
流程图 TD 子图 传统[“传统集成”] A1[用户输入搜索条件] –> B1[应用程序验证输入格式] B1 –> C1[应用程序将字段映射到 API 模式] C1 –> D1[进行航空公司 API 调用] D1 –> E1[解析响应] E1 –> F1{航班可用？} F1 –>|是| G1[显示结果] F1 –>|否| H1[显示错误] G1 –> I1[用户选择航班] I1 –> J1[用于预订的新 API 调用] J1 –> K1[处理响应] 结束
子图 AI[“AI-代理集成”] A2[用户输入自然请求] –> B2[AI 解析意图] B2 –> C2{请求类型？} C2 –>|搜索| D2[提取搜索参数] C2 –>|修改| E2[理解修改] C2 –>|问题| F2[处理查询] D2 & E2 –> G2[AI 进行 API 调用] G2 –> H2[处理响应] H2 –> I2[生成自然回复] I2 –> J2[用户响应] J2 –> B2 F2 –> I2 结束 在这里，API 使用上的差异归结为确定性与非确定性。传统应用收集用户的输入，并进行一次 API 调用来显示结果。通常，用户的一次操作对应一次 API 调用。
相比之下，AI 代理应用程序理论上对单个用户请求的调用次数没有限制。它会不断迭代，进行几次甚至几十次调用，直到满足用户的请求。如果结果不令人满意，用户还可以重新提示代理。
维护您的 OpenAPI 规范 AI 代理并不关心你的 API 文档有多漂亮。他们只关心你的 OpenAPI 规范是否正确、描述性强且最新。他们关心你的 API 接收什么数据以及输出什么数据。仅此而已。
如果您不熟悉 OpenAPI，它是描述 REST API 的标准。如果您有 REST API，则很有可能有一个 OpenAPI 规范。该规范是否正确且最新则完全是另一个问题。
如果您一直推迟更新规范，那么 AI 代理就是进行适当清理的重要原因。大多数主要的 AI 代理框架（Langchain、LangGraph、Crew AI 等）都使用 OpenAPI 作为媒介，使 LLM 能够与您的 API 交互。如果您的规范不准确或含糊不清，那么您就会损害其他试图在您的 API 上使用 AI 进行构建的开发人员。
关注 MCP 11 月，Anthropic 宣布推出模型上下文协议(MCP)，旨在改进当前使用 OpenAPI 的系统。虽然当今的 API 需要为每个想要访问它们的 AI 助手或代理提供独特的实现，但 MCP 提出了一种单一的服务器-客户端架构，为您的 LLM 可访问的 API提供了简单的 JSON 模式。
对于 API 构建者来说，这标志着他们可能不再构建特定于 AI 的端点或功能，而是转向通过任何 AI 系统都可以使用的标准化 MCP 服务器来公开他们的数据。
这可以大大简化 API 处理 AI 集成的方式，并使其数据更易于不断增长的 AI 工具和代理生态系统访问。
MCP 是否会被广泛采用或成为 Anthropic 独有的尚不清楚。但是，作为市场上最大的 LLM 提供商之一，无论是否被广泛采用，您都应该考虑构建 MCP 服务器。要使您的 API 可用，您必须创建一个遵循标准中概述的原则的精简 SDK。
API 设计和使用的 AI 代理时代将为开发人员带来新的挑战和新的机遇。例如，人类开发人员之间的 API 发现至今仍是一个尚未解决的挑战，而 AI 代理既可以解决这一问题，也可以加剧这一问题。
但无论软件集成行业最终如何适应代理商，开发人员都必须开始为它们打下基础。
评论