每一个 API 都将为智能体重构

MCP 解决了连接问题，但它没有解决“动词鸿沟”（verb gap）。

你可以在一个下午的时间里将一个完美的 REST API 封装进 MCP。即便如此，编程智能体（coding agent）仍会感到吃力。它可能会选错端点（endpoint），在只需要一个工具时调用了三个，甚至可能在未询问的情况下执行破坏性的写入操作。

API 并没有坏，它只是为错误的消费者而设计的。

二十年来，API 一直是为人类设计的。人类自带意图（intent）和心理模型（mental model），而智能体两者皆无。它们必须从你的接口表面重新构建这两者。

当主要消费者发生如此巨大的变化时，接口也必须随之改变。

我相信严肃的产品界面不会仅仅是封装现有的 API，它们会围绕“智能体原生”（agent-native）的操作进行重构。

这意味着从“资源导向型”（resource-shaped）API 向“意图导向型”（intent-shaped）契约转变。我们必须围绕目标、状态、副作用、审批和恢复进行重新设计。

MCP 是一个优秀的连接和传输标准。但在规范中，一个工具仅仅是一个带有名称和 Schema 的函数。它无法决定操作的顺序，也无法判断哪些操作是危险的。

这就造成了“动词鸿沟”。API 给智能体提供的是名词和 CRUD 操作，而智能体需要的是带有意图的动词。

看看 GitHub。他们正在缩小工具集以提升智能体的推理能力。他们正在意识到，将产品 API 与智能体工具进行 1:1 映射是行不通的。

研究表明，一个 API 在结构上可能是有效的，但在语义上对智能体来说却毫无用处。一个智能体原生的 API 不仅仅回答“我该返回什么”，它还要回答：

• 目标是什么？
• 我处于什么状态？
• 副作用是什么？
• 我是否需要审批？
• 我该如何恢复？

与其进行原始写入，你更需要将其拆分为：

• 预览操作。
• 获取明确审批。
• 提交更改。
• 若失败则回滚。

这不仅仅是一个“智能体版”。这本质上就是一个更好的 API。开发者同样需要预览、清晰的权限错误提示和回滚功能。最终，智能体原生的设计将取代以人为中心的设计。

这一转变是巨大的。它会影响 API、CLI 和日志。我们必须从“人类可读的文本”转向“机器可解析的状态”。

安全性不是事后添加的外壳。安全性是在设计操作本身时就应具备的属性。

Source: https://dev.to/gyu07/every-api-will-be-rebuilt-for-agents-2hj4

Optional learning community: https://t.me/GyaanSetuAi