谷歌15年老架构被AI撕开3道裂缝，Go语言祭出新解法|context|上下文|工作流|电子表格|知名企业|调用|谷歌

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加急单"的谜题里绕圈子。