LLM 作为通用协议翻译器：无人规划却悄然兴起的中间件模式

每个集成工程师都曾面对过两个拒绝相互通信的系统。一个说的是 2008 年的 SOAP XML，另一个期望的是上季度刚设计的 REST JSON 负载。传统的解决方案——编写自定义解析器、维护映射层、祈祷没人改动模式——在第三或第四个系统加入之前都还能用。之后你就要维护一个没人愿意接手的组合爆炸式翻译代码了。

现在团队正在将 LLM 放入这个缺口中。不是作为聊天机器人，不是作为代码生成器，而是作为运行时协议翻译器——读取一种格式并输出另一种格式。对于某些用例，它的效果出奇地好——而对于其他用例，它的失败方式则真正令人担忧。理解这两个区域之间的边界就是整个博弈的关键。

催生此模式的 N×M 问题

企业集成一直受困于 N×M 问题。如果你有 N 个源系统和 M 个目标系统，你需要 N×M 个自定义集成。一家拥有 15 个内部服务和 10 个外部合作伙伴 API 的公司面临 150 个潜在集成点——每个都有自己的序列化格式、认证方案和错误处理约定。

传统中间件——ESB、API 网关、iPaaS 平台——通过引入规范格式来解决这个问题。每个系统都与规范模型进行双向转换，将问题简化为 N+M 个适配器。但规范模型也有其代价：它们需要前期设计，随着系统演进会与现实脱节，而且会成为关于哪个团队的数据模型被认定为"规范"的政治角力场。

LLM 提供了一种不同的方案。不是一个刚性的规范模式，而是一个已经消化了足够多的 API 文档、数据格式和协议规范的模型，能够在推理时执行即席翻译。"规范模型"隐式地存在于模型权重中，而不是显式地存在于模式注册中心里。

这不是理论练习。团队正在生产环境中应用这一模式：

• 遗留系统 SOAP 转 REST 桥接，为每个服务编写 WSDL 解析器的成本过高
• 跨供应商数据标准化，医疗系统需要交换 HL7v2、FHIR 和专有 CSV 格式
• 内部 API 版本管理，v1、v2 和 v3 的消费者共存，在代码中维护向后兼容性已变得不可持续
• 合作伙伴接入，每个新合作伙伴以略有不同的 JSON 结构发送数据，对相同概念使用不同的字段名

翻译层的实际工作原理

架构在概念上很直观。LLM 位于内部 API 端点之后。上游系统将其原生负载连同关于源格式和期望目标格式的元数据一起发送到该端点。LLM 转换负载并返回结果。

在实践中，实现根据你对模型输出的信任程度分为三个层级。

第一层级：模式引导翻译。 你向 LLM 提供源模式、目标模式和负载。模型映射字段、转换类型，并处理结构差异，如展平嵌套对象或拆分复合字段。这是最高置信度的层级，因为两端的模式都约束了输出空间。

第二层级：示例引导翻译。 你没有一方或双方的正式模式。取而代之的是，你提供一些示例输入-输出对，让模型进行泛化。这对于半结构化格式效果很好，比如列名不一致的 CSV 文件或带有可选字段的 XML 文档。当模型遇到示例未覆盖的边缘情况时，它就会失败。

第三层级：自由格式翻译。 你用自然语言描述源和目标，让模型自行推断映射关系。这是"演示令人印象深刻、生产环境却很危险"的层级。它在演示中很出色，但不应该碰你的计费管道。

关键的架构决策是 LLM 在请求路径中的位置。目前出现了三种模式：

• 同步内联：LLM 实时处理每个请求。简单但每次翻译增加 200-800ms 延迟，并创建单点故障。
• 异步富化队列：负载进入队列，LLM 异步翻译，下游消费者获取翻译后的版本。更适合对吞吐量有容忍度的工作负载。
• 编译时翻译：LLM 生成静态翻译代码（映射函数或配置文件），在请求时无需 LLM 即可运行。这让你在构建时获得 LLM 的智能，在运行时获得确定性执行。

编译时模式值得特别关注。你不是在每个请求上调用模型，而是调用一次来生成转换逻辑，审查和测试该逻辑，然后将其作为传统代码部署。你获得了基于 LLM 翻译的灵活性，却不承担运行时成本或非确定性。当模式变更时，重新生成即可。这是大多数生产团队在尝试内联方式后最终收敛到的模式。

模型在哪里"幻觉"你的数据

LLM 中介翻译的失效模式与传统集成失败有本质不同。传统解析器遇到意外输入时会大声崩溃。LLM 则通过生成看起来合理但存在微妙错误的输出来静默失败。

最危险的失效模式是字段幻觉。当模型遇到在目标模式中没有明确映射的源字段时，它不会报错——它会发明一个映射。customer_tier 字段可能被悄悄映射到 account_type，因为模型认为它们语义相似。它们可能是，也可能不是。你不会知道，直到有人发现下游分析出了问题。

类型强制幻觉是第二个主要风险。模型可能将字符串 "001234" 转换为整数 1234，去掉了编码有意义路由前缀的前导零。或者它将 Unix 时间戳转换为 ISO 日期字符串，但默认假设 UTC，而源系统使用的是太平洋时间。这些错误在 95% 的测试用例中看起来正确，在剩余 5% 中损坏数据。

结构幻觉发生在模型改变数据基数时。一对多关系被展平为一对一。数组被解包为单个值，因为测试示例中只有一个元素。模型是在做模式匹配，而不是推理数据语义。

经历过这些失效模式的生产团队报告了一个一致的发现：LLM 翻译层周围需要的验证代码比传统解析器本身需要的还多。但有一个关键区别——验证代码是通用的（模式验证、类型检查、基数断言），而不是特定于格式的。你写一次，在每个集成中重用，这就是经济性开始显现的地方。

使其安全的验证架构

使 LLM 中介翻译达到生产安全需要基于契约的验证层。关键洞见是你不需要信任模型——你需要根据你本来就会用来构建传统解析器的同一模式来验证其输出。

输入契约定义源负载必须是什么样子。如果传入数据不匹配预期结构，在 LLM 看到之前就拒绝它。这防止模型对畸形输入进行操作并产生自信但错误的输出。

输出契约严格执行目标模式。模型响应中的每个字段都要验证类型、存在性和约束。使用 JSON Schema、Pydantic 模型或 Protocol Buffer 定义——无论你的目标系统已经在用什么进行验证。如果模型的输出未通过模式验证，用更明确的提示重试或回退到基于规则的翻译器。

语义契约超越结构验证，检查数据不变量。如果源负载有 47 个行项目，翻译后的输出也必须有 47 个行项目。如果源总金额是 $1,234.56，翻译后的总金额必须匹配。这些校验和捕获了模型静默丢弃或重复数据的结构幻觉问题。

验证-重试模式在实践中效果很好：验证输出，如果失败，将验证错误连同原始负载一起发回给模型，要求其修复翻译。大多数模型在第一次重试时就能自我纠正。如果第二次尝试也失败，则路由到死信队列进行人工审查。

结构化输出约束已经快速成熟。OpenAI、Anthropic 和 Google 现在都支持受约束解码，保证语法有效的输出匹配 JSON Schema。Instructor 和 Outlines 等库让你在解码级别对模型输出强制执行 Pydantic 模式，消除了一整类结构错误。

这不能防止语义错误——模型仍然可能映射错误的字段——但它保证输出至少是格式良好的。结合语义校验和，你获得了双层安全网：来自受约束解码的结构正确性，以及来自不变量检查的数据正确性。

何时使用此模式（何时远离）

决策矩阵比大多数团队意识到的更清晰。LLM 中介翻译在以下情况下有意义：

• 格式多样性高但吞吐量低。 你正在与 20 个合作伙伴集成，他们各自以略有不同的格式发送数据，但每个每天只发送几百个请求。20 个自定义解析器的成本超过了带验证的 LLM 翻译层的成本。
• 模式频繁变更。 如果你的合作伙伴每季度更新其 API，而你每季度花两周更新解析器，那么通过提示更新即可适应模式变更的 LLM 层就很有吸引力。
• 数据非关键。 在系统之间翻译营销分析、日志格式或文档。如果一个字段出了小错，成本很低，最终会有人注意到。
• 你在原型化集成。 使用 LLM 快速构建集成，针对生产流量进行验证，然后在映射稳定后生成静态翻译代码。

LLM 翻译不适合以下情况：

• 吞吐量超过每秒数千个请求。 LLM 推理的延迟和成本使其不适合高吞吐量数据管道。编译后的映射函数运行仅需微秒；LLM 调用需要数百毫秒。
• 数据准确性不可妥协。 金融交易、医疗记录、监管申报。如果一个幻觉字段映射可能导致合规违规或财务损失，风险不能为便利性辩护。
• 格式实际上定义良好。 如果双方都发布了 OpenAPI 规范或 Protocol Buffer 定义，你可以确定性地生成翻译代码。在这里使用 LLM 只是无谓地增加了非确定性。
• 你需要可审计性。 监管机构和审计人员希望看到他们可以审查的确定性转换逻辑。"模型决定这个字段映射到那个字段"不是一个能满足 SOC 2 或 HIPAA 要求的答案。

与 MCP 和结构化协议的融合

Model Context Protocol（MCP）代表了这一模式的正式演进。MCP 不是临时的 LLM 翻译层，而是为 AI 系统与外部工具和数据源交互提供了标准化协议。它通过定义 AI 系统和工具都实现的通用接口，将 N×M 问题简化为 N+M。

截至 2026 年初，MCP 生态系统包括超过 10,000 个注册服务器，涵盖数据库、通信平台、云基础设施和开发工具。该协议 2025 年 11 月的规范增加了异步操作和无状态支持，使其适用于团队之前使用原始 LLM 翻译的相同集成场景。

MCP 快速普及的启示是，"LLM 作为翻译器"模式在从临时中间件演进为结构化协议时效果最佳。原始模式——将负载丢给模型，期望输出正确——是一个过渡阶段。目标是带有模式契约的标准化接口，其中 LLM 的角色从"猜测映射"转变为"在明确定义的约束内执行映射"。

给今天开始的团队的实用建议

如果你正在评估 LLM 中介翻译用于你的集成层，从编译时模式开始。使用模型生成映射代码，审查它，针对生产样本测试它，然后在你的请求路径中部署生成的代码——而不是模型。这让你以 20% 的风险获得 80% 的收益。

如果你需要运行时翻译，在投资模型之前先大力投资验证层。先编写你的输出模式。构建你的语义校验和。设置你的死信队列。验证基础设施无论你使用 GPT-4、Claude 还是微调的开源模型都是一样的，而且它才是真正保护你数据安全的部分。

执着地跟踪你的翻译准确率。记录每一个输入-输出对。每晚针对黄金数据集运行批量验证。监控漂移——当提供商更新模型版本时，模型的翻译质量可能会下降，即使是"等效"模型也是如此。周二完美工作的翻译可能在周四模型更新后悄悄损坏数据。

从这一模式中获得最大价值的团队将 LLM 视为草稿翻译器，将验证层视为真理来源。模型提议；契约裁决。这种心智模型——受确定性验证约束的概率生成——是适用于代码生成、内容创作以及所有其他生产 LLM 应用的相同架构。协议翻译只是这一模式的最新实例，而且可以说是最自然的契合。