大模型的JSON之殇：从脆弱的API调用到稳健的未来-优快云博客

大家好，今天我们来聊一个让许多AI开发者感到不安的话题：大模型工具调用中的JSON格式。

当我们尝试让大模型（LLM）调用外部工具，尤其是像OpenAI的API那样，通常需要模型生成一个严格的JSON对象。这在处理简单参数时或许还行，但一旦涉及到复杂数据，比如一段C#或Python代码、一个正则表达式，情况就变得棘手起来。代码中的引号、特殊字符都需要转义，这极易让概率性的LLM“犯迷糊”，生成一个格式错误的JSON，导致整个调用链失败。

这种脆弱性不禁让我们思考：强制使用JSON真的是最佳实践吗？有没有更稳健、更不容易让模型困惑的替代方案？今天，就让我们一起深入探讨这个“JSON之殇”，看看业界是如何应对的，并展望一下工具调用的未来。

第 1 节：JSON的根本性冲突：概率模型与确定性语法的博弈

LLM与JSON之间的矛盾，本质上是概率系统与确定性系统的冲突。LLM的核心是基于海量非结构化文本训练出的概率模型，它擅长理解语义和生成自然语言，却不擅长严格遵守JSON这种需要精确句法规则的格式。

LLM通过一步步预测下一个最可能的词元（Token）来生成文本。在这个过程中，要让它始终记住哪个括号没闭合、哪个引号要转义，是一项巨大的挑战。即便经过专门的函数调用微调，模型也无法100%保证生成的JSON绝对正确，尤其是在处理复杂或边缘情况时。

字符串序列化的常见“翻车现场”

在实践中，这种冲突导致的失败模式屡见不鲜：

嵌套引号与特殊字符： 比如传递一段C#代码 Console.WriteLine("Hello World")。理想的JSON输出是 {"code": "Console.WriteLine(\"Hello World\");"}。但LLM很可能忘记转义，生成一个无效的 {"code": "Console.WriteLine("Hello World");"}。
正则表达式： 正则表达式中充满了需要转义的特殊字符，如 \。一个简单的正则 \d{3}-\d{4} 在JSON字符串中需要写成 \\d{3}-\\d{4}，这种双重转义极大地增加了模型犯错的概率。
多行代码块： JSON标准要求字符串中的换行符必须转义为 \n。然而，LLM经常会直接在字符串值之外插入原始的换行符，直接破坏JSON结构。

这些问题并非个例，它们共同构成了当前基于JSON Schema的工具调用范式中的核心脆弱点。为了应对，开发者被迫在应用层构建一套复杂的“防御工事”，包括后处理、验证和修复逻辑，这不仅增加了延迟和成本，也让代码变得臃肿，严重影响了系统的可靠性和可信度。

第 2 节：三层防御体系：我们如何“驯服”JSON？

面对LLM生成结构化数据的不确定性，业界已经发展出一套从易到难、从弱到强的多层次缓解策略。

第一层：提示工程（君子协定）

这是最直接的防线。通过在提示中给出明确指令、提供“少样本”示例（Few-Shot Examples），甚至预填充部分响应（如 {"），可以显著提高模型生成正确格式的概率。但这本质上是一种“君子协定”，缺乏强制性约束，对于生产级系统来说往往不够可靠。

第二层：框架抽象（开发者的护盾）

为了将开发者从繁琐的格式处理中解放出来，主流的AI应用框架（如LangChain, LlamaIndex, Semantic Kernel）提供了一层强大的抽象。这代表了当前构建可靠AI应用的行业标准。

作为.NET开发者，我们最熟悉的当属 Semantic Kernel (SK)。SK深度集成了.NET生态，利用C#的特性（Attributes）来标记和描述供LLM使用的函数，这正是一种典型的“.NET骚操作”。

核心机制： 开发者只需在自己的C#方法上标记 [KernelFunction] 和 `` 等特性。
抽象实践： SK的SDK在运行时会利用.NET的**反射（Reflection）**机制来扫描代码，自动提取方法名、参数、类型以及描述，并将其精确地生成为LLM所需的JSON Schema。
处理复杂类型： SK在处理复杂的C#对象作为参数时表现尤为出色。它能够递归地解析对象的属性及其数据注解（如 ``），构建出相应的嵌套JSON Schema。反之，当模型返回JSON时，SK也能自动将其反序列化回正确的.NET对象，极大地简化了数据交互。

看一个例子，我们定义一个复杂的请求类和一个使用它的插件函数：

/* by yours.tools - online tools website : yours.tools/zh/jpegcompression.html */
// 复杂的参数模型
public class ComplexRequest
{
    public string StartDate { get; set; }
    public string EndDate { get; set; }
}

// 使用该模型的插件
public class ComplexTypePlugin
{
    public bool BookHoliday(ComplexRequest request)
    {
        Console.WriteLine($"Booking holiday from {request.StartDate} to {request.EndDate}");
        return true;
    }
}

我们无需手动编写任何JSON，SK会自动为我们生成如下的Schema发给大模型：

/* by yours.tools - online tools website : yours.tools/zh/jpegcompression.html */
{
    "name": "ComplexTypePlugin-BookHoliday",
    "description": "Book a holiday based on a request.",
    "parameters": {
        "type": "object",
        "properties": {
            "request": {
                "type": "object",
                "properties": {
                    "StartDate": {
                        "type": "string",
                        "description": "The start date in ISO 8601 format"
                    },
                    "EndDate": {
                        "type": "string",
                        "description": "The end date in ISO 8601 format"
                    }
                },
                "required":,
                "description": "A request to answer."
            }
        },
        "required": ["request"]
    }
}

无论是LangChain的Pydantic模型，还是Semantic Kernel的.NET特性，它们都殊途同归地走向了 “代码即Schema” 的设计模式。这让开发者能编写干净、类型安全的代码，而框架则负责将这些定义翻译成LLM可理解的Schema。这无疑是弥合LLM与代码之间鸿沟的最佳实践。

第三层：生成层面强制执行（语法的金钟罩）

框架之所以可靠，背后依赖的是LLM API自身提供的约束生成（Constrained Decoding）能力。其原理是在LLM生成每一步时，通过一个“掩码（Mask）”技术，将所有不符合JSON语法的Token的概率强制设为零。

例如，当模型生成了 {"code": " 后，约束逻辑会屏蔽掉像 { 或 } 这样的非法Token，只允许模型从合法的字符中进行采样。这能100%保证输出的句法正确性，是目前实现可靠工具调用的最强技术。

这种方法的强大之处在于它能100%保证输出的句法正确性。然而，它也存在一个重要的权衡：它可能会迫使模型选择一个概率较低但句法合法的路径，而放弃一个语义上更自然但句法不合法的路径。这可能导致生成的JSON虽然格式完美，但其内部的值却显得有些牵强或不那么连贯。尽管如此，对于工具调用场景而言，句法的正确性是执行的前提，其重要性通常高于语义的细微差别。因此，约束生成是目前实现可靠工具调用的最强大技术。

第 3 节：替代方案的探索：XML与Multipart

审视当前行业应对JSON生成不可靠性的普遍做法，可以发现一个清晰的模式：开发者们在基础不牢固的架构之上，层层叠加了各种“补丁”。这个基础就是让一个概率性模型去生成一种对其语法不友好的确定性格式。

这个“补丁堆栈”本身就是一种架构上的反模式（Architectural Anti-Pattern）。它清晰地表明，问题的根源在于基础选择——即强制使用JSON来承载对其语法构成挑战的复杂载荷——存在固有缺陷。每一层补丁都增加了系统的复杂性、潜在的故障点和开发者的认知负担。因此，选择质疑JSON这一基础本身，而不是仅仅寻求另一个补丁，这恰恰体现了一种深刻的架构性思考。

既然JSON有其固有的问题，探索替代方案便是理所当然的。

方案一：XML/CDATA范式

XML有一个JSON无法比拟的优势：<!]>（字符数据）节。在CDATA块内的所有内容，包括 <, >, &, " 等，都无需任何转义。这完美地解决了我们开头提到的代码和正则表达式的转义噩梦。

<Tool Name="RunCSharpCode">
  <Parameter Name="Code">
    <![CDATA[
    Console.WriteLine("Hello World");
    // 此处无需任何转义
    ]]>
  </Parameter>
</Tool>

优点： 对复杂字符串提供了极高的可靠性，概念清晰。
缺点： 比JSON更冗长（意味着更高的Token成本），且在现代Web生态中支持度不如JSON。

方案二：类Multipart协议构想

从HTTP的 multipart/form-data 中获得灵感，我们可以设想一种新的协议，将结构化的元数据（如工具名）与非结构化的复杂载荷（如代码）在物理上分离。

Boundary:
--
Content-Type: application/json

{"tool_name": "RunCSharpCode", "parameter_name": "Code"}
--
Content-Type: text/plain; charset=utf-8

Console.WriteLine("Hello World");
// 此处无需任何转义
----

优点： 提供了最高级别的可靠性，从根本上消除了转义需求。
缺点： 完全是概念构想，没有任何主流LLM API支持，实现复杂。

决策框架

特性	JSON Schema (标准)	XML with CDATA	类Multipart协议
可靠性 (复杂字符串)	低至中 (使用约束生成后为高)	高	非常高
生态系统支持	非常高 (事实标准)	小众	无 (概念性)
Token成本	中	高	可能最低
开发者体验	优秀 (有框架抽象)	良好	需写解析代码
主要用例	通用工具调用	参数为代码、正则或标记的工具	理想化方案

这些替代方案都指向一个共同的设计原则：将需要严格结构的元数据与需要保持原样的自由文本分离开来。未来的理想协议可能是一种混合格式，既支持简单的结构化调用，也提供一种机制来为特定参数传递原始、未经转义的载荷。

第 4 节：未来的地平线：超越单次调用的工具宇宙

当前的工具调用范式仍是相对独立和无状态的。但AI领域正朝着更宏大、更互联的方向演进。

标准化之路：模型上下文协议（MCP）

为了解决当前各框架实现工具调用编排逻辑的碎片化问题，模型上下文协议（Model Context Protocol, MCP）应运而生。它是一个开放、模型无关的协议，旨在标准化LLM发现、调用和链接外部工具的方式，目标是创建一个可互操作的“工具互联网”。

但MCP其实并没有规定工具调用的具体数据格式，而是提供了一种机制来描述工具的功能和参数。这意味着，MCP可以与现有的JSON Schema、XML或其他格式无缝集成。

第 5 节：给.NET开发者的战略建议

作为.NET开发者，我们该如何在这场技术浪潮中导航？

默认拥抱框架抽象： 别再手动拼JSON了！果断使用像.NET 9 JsonSchemaExporter这样的成熟库。它提供的“代码即Schema”抽象能极大降低开发复杂性。
隔离高风险载荷： 对于频繁传递代码、SQL等复杂字符串的核心工具，可以考虑创建自定义的工具定义，采用XML/CDATA模式，以获得更高的可靠性。
实施“信任但验证”： 无论生成方法多可靠，在工作流末端都应设置验证环节。比如在解析JSON的代码外包裹 try-catch，甚至可以考虑使用更宽容的解析器（如json5）作为备用方案。
设计更简单的原子工具： 将复杂函数分解为更小、更专注的原子工具。优先使用枚举（enum）而非自由格式的字符串作为参数。在工具接口设计上投入的精力，回报远大于在数据格式上纠结。
保持架构灵活性： 关注MCP等开放标准的发展，设计解耦的、模块化的系统，以便未来能平滑地迁移到更优越的协议上。