你的 AI agent 在推理、规划和生成自然语言方面表现出色。然后你把它指向企业的 SAP 端点，它接下来花了 4,000 个 token 试图理解一个 SOAP 信封。欢迎来到阻抗失配的世界——这个隐性税收把每一次企业 AI 集成都变成了 token 的焚烧炉。
这种失配不仅仅是 XML 与 JSON 的问题。它是 LLM 思维方式（自然语言、扁平的键值结构、简洁的上下文）与企业系统通信方式（深层嵌套的 schema、特定于实现的命名、分页游标以及数十年积累的协议约定）之间的根本冲突。与人类开发者只需阅读一次 WSDL 文档就可以继续工作不同，你的 agent 在每次调用时都要重新解析这种复杂性。
隐藏的 Token 税
当基于 LLM 的 agent 与返回干净 JSON 的现代 REST API 交互时，格式开销是最小的。一条客户记录可能花费 200 个 token。同样的记录来自传统的 SOAP 服务——包裹在 XML 命名空间、信封头和 schema 声明中——在 agent 提取单个有用字段之前，很容易膨胀到 800-1,200 个 token。
这不是四舍五入的误差。在链式调用多个 API 的生产 agent 工作流中，格式开销会累积。一个需要查找客户、检查其订单历史并在三个企业系统中验证库存的 agent，仅在结构解析上就可能消耗 5,000-8,000 个 token。这些 token 没有用在推理、规划或为用户生成有用的输出上。
当涉及工具定义时，问题变得更糟。当团队将整个 API 自动包装为 agent 工具——暴露 ERP 系统的所有 200 个端点时——仅工具 schema 就可能在第一条用户消息到达之前消耗模型上下文窗口的 5-7%。当工具超过 50 个时，模型不会优雅降级，而是直接崩溃。工具选择准确率急剧下降，agent 开始幻觉出不存在的工具名称。
为什么"直接用 API 网关"行不通
平台团队的本能反应是：在所有东西前面放一个 API 网关，把 XML 转换成 JSON，就完事了。这解决了格式问题，却完全忽略了语义问题。
考虑一个典型的企业 CRM。它的 API 暴露了像 get_customer_by_internal_id、list_orders_with_cursor_pagination 和 update_account_status_with_audit_trail 这样的端点。这些名称的存在是因为后端架构——数据库规范化选择、微服务边界、合规要求。它们与用户实际想要完成的事情毫无关系。
当你将这些具有实现风味的端点暴露为 agent 工具时，你就将后端架构注入到了 LLM 的推理空间中。agent 必须理解你的内部 ID 方案、游标分页格式和审计跟踪约定。这相当于要求一个新员工在查询客户订单状态之前先学习数据库 schema。
API 网关将 <CustomerRecord> 转换为 {"customer_record": ...}。它不会将"反映我们微服务分解的三个链式 API 调用"转换为"一个回答用户问题的操作"。格式转换是一个已解决的问题。语义转换才是团队真正卡住的地方。
真正有效的适配器层
在生产中成功的模式是面向结果的适配器层——一个位于你的 agent 和企业 API 之间的薄服务层，暴露映射到用户意图而非后端操作的工具。
不再是三个工具（get_customer → list_orders → get_order_status），而是暴露一个：track_latest_order。适配器在服务端处理 API 编排，将响应压缩成 agent 可以推理的紧凑结构，并剥离 LLM 不需要的每个字段。
这种方法带来三个复合收益：
- Token 效率：agent 看到的是一个具有简单 schema 的工具，而不是三个具有复杂 schema 的工具。响应载荷缩小，因为适配器只过滤相关字段。
- 可靠性：一次工具调用而非三次意味着一个故障点而非三个。适配器可以在内部处理重试、分页和错误规范化。
- 推理质量：agent 的上下文保持整洁。它推理的是"追踪客户的订单"而不是"调用端点 A，提取字段 X，将其传递给带有游标参数 Y 的端点 B"。
80/20 法则在这里非常适用。在大多数企业场景中，20% 的 API 能力服务于 80% 的实际用户请求。你的适配器层不需要包装每个端点——只需要那些映射到真实工作流的端点。
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部