【Agentic API 实战】02 重新定义动作：掌握 ACTION 接口分类法
大家好，我是Tony Bai。
欢迎来到微专栏 《Agentic API 实战：为 AI 智能体设计下一代接口》的第二讲。
在上一讲中，我们探讨了为什么 RESTful API 这种基于名词（资源）和 CRUD（增删改查）的设计范式，在面对 AI 智能体时显得力不从心。当我们将复杂的业务操作强行映射到POST或PUT上时，我们丢失了最关键的信息——意图（Intent）。
这就像是你拥有一支极其聪明的军队（AI Agent），但你却只给他们下达了四个指令：创建（Create）、读取（Read）、更新（Update）、删除（Delete）。当你要他们去“勘察地形”、“安抚难民”或者“发动奇袭”时，你只能尴尬地让他们把这些复杂的动作塞进一个叫Update(Task)的指令里。
今天，我们要彻底打破这层束缚。我们要赋予这支 AI 军队一套丰富、精准、且专门为他们设计的词汇表。这就是本讲的核心：ACTION 接口分类法。
为什么 HTTP 的“老四样”不够用了？
HTTP 协议的四个标准方法（GET, POST, PUT, DELETE）最初是为了管理静态文档而设计的。在微服务时代，我们将业务实体映射为文档（资源），勉强凑合着用了下来。
但这在 AI 自动化时代遇到了两个致命问题：
动作重载（Action Overloading）：我们经常看到一个
POST /users/123接口，它可能是用来更新用户资料的，也可能是用来触发发送重置密码邮件的，甚至是用来禁用账号的。AI 看到POST，完全不知道调用后会发生什么副作用（Side Effects）。缺乏粒度：AI 在规划任务时，需要清楚地知道一个 API 是仅仅读取数据，还是需要执行长时间的计算，亦或是会产生不可逆的资金变动。HTTP 动词无法提供这种粒度的安全承诺。
为了解决这个问题，我们需要一套超越 HTTP 标准动词的分类体系。
破局：ACTION 框架的六大动词分类
在 Agentic API 的设计哲学中，我们不再纠结于 URL 应该是名词还是动词。我们直接将“动作（Action）”提升为一等公民。
我们可以将 AI 智能体可能调用的系统能力，归纳为以下六大核心 ACTION 分类：