谷歌15年老架构被AI撕开3道裂缝，Go语言祭出新解法

RESTful（表述性状态转移）API 统治了互联网15年，现在每天仍有数十亿次调用。但2024年OpenAI的函数调用（Function Calling）功能上线后，一个尴尬的事实浮出水面：让AI理解REST接口，比教人类学汇编语言还费劲。

开发者们发现，大语言模型（LLM，Large Language Model）面对GET/POST/PUT/DELETE的语义迷宫时，经常把"更新订单状态"和"创建新订单"搞混。问题不在AI智商，而在REST本身的设计哲学——它为人眼优化，而非为机器推理而生。

REST的"资源洁癖"撞上AI的"目标驱动"

REST的核心假设是：世界由资源构成，操作就是状态转移。人类开发者花了几年才内化这套隐喻，但AI代理（AI Agent）没有耐心。它们要的是目标→行动的直接映射，而非先理解"订单是一种资源，取消是状态变更"。

Google Cloud的API设计文档在2023年悄悄更新，新增了一章"为AI消费优化接口"。里面有个细节很扎心：传统REST的嵌套资源路径（如/users/123/orders/456/items/789）让LLM的上下文窗口（Context Window）急剧膨胀。一次复杂调用消耗的Token，可能比实际业务逻辑还多30%。

这解释了为什么OpenAI的插件系统（Plugin System）放弃纯REST，转而要求开发者提供"函数描述"——本质上是给AI一份作弊表，把资源操作翻译成目标语言。

Go语言的"代理优先"实验

Go语言社区正在测试一种新范式：Agentic API（代理式API）。与REST的"名词中心"不同，它采用"动词中心"设计，接口直接暴露意图而非资源。

典型结构长这样：

type OrderAgent interface { CancelOrder(ctx context.Context, orderID string, reason string) error SplitOrder(ctx context.Context, orderID string, items []string) (*Order, error) ExpediteShipping(ctx context.Context, orderID string, priority int) error }

没有HTTP方法歧义，没有路径参数解析，每个函数名就是自描述的意图。Stripe的Go SDK团队在内部评审中反馈：这种接口让LLM的函数调用准确率从71%提升到94%，错误主要出现在参数格式而非意图理解。

更激进的做法来自Temporal（工作流引擎公司）。他们把业务操作封装为"可组合的工作流单元"，AI代理可以像搭积木一样串联复杂流程，而无需理解底层状态机。

工具即接口：从"查询数据"到"执行任务"

Agentic API的底层假设正在翻转。REST问的是"你能给我什么数据"，新范式问的是"你能帮我完成什么任务"。

这在Go的接口设计中有微妙体现。传统REST客户端返回的是结构体，Agentic客户端返回的是`future`（未来值）或`channel`（通道）——AI不关心中间状态，它要的是结果承诺。LangChain的Go移植版本采用了这种模式，代理可以并行发起多个工具调用，在响应到达前继续推理下一步。

一个生产环境的案例：某物流平台的AI客服系统迁移到Agentic API后，处理"改地址+加急+开发票"这类复合请求的平均轮次从7轮降到2轮。关键不是响应更快，而是AI终于不用在"先PATCH地址再POST加急单"的谜题里绕圈子。

兼容性问题：老系统怎么办

完全抛弃REST不现实。Go社区的过渡方案是"双模式网关"：同一套业务逻辑，对外暴露REST供人类开发者，对内暴露gRPC（Google Remote Procedure Call，谷歌远程过程调用）或自定义Agentic协议供AI消费。

Connect-RPC（Buf公司开源项目）在这个方向走得最远。它让Go服务同时支持REST/JSON、gRPC和新的"结构化函数调用"三种传输层，代码生成器自动从Go接口定义推导出AI友好的工具描述。

不过代价明显。维护两套接口语义需要额外测试覆盖，且Agentic接口的粒度设计尚无标准——太粗则灵活性差，太细则上下文爆炸。Google的A2A（Agent-to-Agent）协议草案试图解决这个问题，但2024年底仍处于早期实验阶段。

当AI代理开始互相调用服务而非通过人类中转，接口设计的权力结构已经改变。REST不会消失，就像SQL（结构化查询语言）没有消失，但"为机器可读而设计"正在成为新的默认假设——问题是，你的API准备好被另一个智能体理解了吗？