想让LLM精确输出？试下XML格式Prompt语法约束解码GCD，帮你迭代收敛到稳定解

随着Agent的爆发，大型语言模型（LLM）的应用不再局限于生成日常对话，而是越来越多地被要求输出像JSON或XML这样的结构化数据。这种结构化输出对于确保安全性、与其他软件系统互操作以及执行下游自动化任务至关重要。然而常规的、自由形式的LLM生成过程存在两个主要问题：第一是格式不可靠：模型可能生成语法错误、无法被机器解析的输出。第二是内容不可靠：模型可能会产生事实错误，即所谓的“幻觉”。这也是许多AI产品开发者的痛点。

为了解决这些问题，学术界和工业界探索了两种主要途径，但这两种途径各有局限：

• 提示工程策略：像“思维链”（Chain-of-Thought）可以引导模型进行更复杂的推理，但它们本身并不能保证最终输出的格式是正确的。
• 语法约束解码（GCD）：这项技术在模型生成每个词元（token）时，会强制其遵守预设的语法规则，从而保证输出结果的语法绝对正确。但它更多是一种底层的解码技术，缺乏对复杂交互过程的宏观建模。

今天这篇论文研究者的核心目标就是要将这两种方法统一起来，建立一个强大的框架，利用XML的结构化能力和语法的严格性，来形式化地管理与LLM之间的复杂、多轮交互，从而同时保证高质量的推理过程和输出结果的绝对规整。

解决方案：XML Prompting

为了解决这个问题，研究者们提出了“XML Prompting”的思路，XML作为Anthropic主推的Prompt格式您可能会很熟悉。它的核心思想是，将XML作为定义整个人机交互过程的“语法”，AI的每一步思考，从计划、验证到调用工具和最终回答，都必须被“锁”在一个我们预先设计好的、层次分明的XML结构里。这就像是给AI的思维链上了一套严格的语法枷锁，让它的整个工作流变得清晰、可控且透明。关于XML提示词的文章我之前写过很多，感兴趣您可以看下

还在用陈旧的CoT？是时候升级你的技术了，你应该掌握的XML高级提示链Prompt Chain

形式化模型：将Prompt视为数学对象

这篇论文的核心是其对提示过程的数学建模，目的是为了把“让模型给我一个结构化答案”这件事，抽象为受限的生成问题。

将XML树置于一个“完备格”中

• 一个XML文档被看作是一个带标签的、有序的树形结构 。
• 作者定义了一种 “精化”（refinement关系（用t1≤t2 表示），意思是树 t2 是树 t1 的一个更完整或更详细的版本。例如，t2 可能比 t1 多了一些子节点，或者填充了 t1 中的某些占位符。
• 最关键的是，论文证明了所有可能的XML树在这种“精化”关系下，构成了一个数学上的 “完备格”（complete lattice）。这是一个源自序理论的强大结构，它保证了任何一组XML树都有一个明确定义的“最小上界”和“最大下界”。 做法：用一个形式语言/文法（如EBNF）来描述允许的输出集合，再把一次交互建模为在这个文法上的受约束导出（derivation）。
• 语法（Grammar）：

• Σ：终结符（字面字符/Token，如 <, >, 字母、数字……）
• V：非终结符（如 root, frame, intent…）
• R：产生式规则（如 frame ::= "<frame>" intent slots "</frame>"）
• S：开始符号（例如 root）
• 输出空间：所有能从 SS 推导的字符串集合 L(G)L(G)。

只要我们把接口契约（比如 XML/JSON 结构、字段枚举、数值格式）写进文法，那么非法格式就根本“不在语言里”，模型无论如何“发挥”，都出不去这条“语义高速公路”。

提示转换器与不动点

一轮完整的交互（例如，用户输入 -> LLM草拟 -> 验证器反馈）被建模成一个算子 T，它接收一棵XML树，然后将其转换为一棵新的、更精化的树：T(旧树)→新树。论文假设这个算子是单调的（monotone）：即如果你用一个更精化的输入开始，你得到的输出也会是更精化的 (t1≤t2⟹T(t1)≤T(t2)) 。这是一个非常自然的假设，因为给模型更多信息，理应不会得到一个更差的输出。

• 交互的操作化：
• 一次生成可以被看作在部分解析树上填空。
• 状态x：当前的部分解析树（或“前缀 + 解析栈”）。
• 步骤：选择一个语法允许的 token 或扩展某个非终结符，让树更完整。
• 终止：树变成完整可接受的解析树（进入接受态），或达到失败/放弃条件。

这一步把“输出格式要求”升级为“语法 + 自动机”，把“交互/生成过程”升级为“受约束的状态转移”。这就是论文的Grammar-Constrained Interaction底座。

不动点语义（Fixed-Point Semantics）

论文中有两个定理，您可以理解成“逐步补全结构化答案”的过程，看成对一个算子反复施加，直到不再改变，这就是不动点。

Knaster-Tarski定理：保证交互“必然能达成结果”

• 核心思想：可以将每一次人机交互（比如用户补充一个要求，AI填充一个标签）看作一个函数或操作 T。这个操作作用于当前的XML树，生成一个新的、更完整的XML树。
• 单调性：论文指出，这种交互是“单调的”，即信息只会不断增加或细化，不会减少。
• 不动点：一个“不动点”就是指当XML树 t 经过一次操作后，结果仍然是 t（T(t) = t），这意味着交互已经完成，信息已经饱和，达到了一个最终的稳定状态。
• 定理保证：Knaster-Tarski定理从数学上证明了，对于任何单调的操作，这种稳定的“不动点”不仅存在，而且我们总能通过从一个空的XML开始，一步步迭代达到这个“最小不动点”。
• 通俗理解：这就像是在保证，只要我们按照规则不断对话，这个对话过程就不会无限发散或兜圈子，最终必然会收敛到一个完整、自洽的最终结果。

Banach收缩映射定理：保证结果的“唯一性”和“可预测性”

• 核心思想：这次我们不看信息的增减，而是定义任意两个XML树（代表两个不同的交互状态）之间的“距离”。
• 收缩性：如果每一步交互操作 T 都能让任意两个状态之间的“距离”变小（即“收缩”），那么这个操作就是一个“收缩映射”。
• 定理保证：Banach不动点定理证明了，对于任何收缩映射，不仅存在不动点，而且这个不动点是“唯一的”。无论从哪个初始状态开始，最终都会收敛到这同一个结果。
• 通俗理解：这提供了一个更强的保证。它不仅保证了交互能完成，还保证了结果是唯一确定的，并且我们还能估算出收敛的速度。

语法对齐解码：将理论变为现实

形式化模型虽然强大但很抽象，技术上怎么落地呢？研究者通过语法对齐解码（Grammar-Aligned Decoding, GAD）技术将其与现实世界联系起来。

• GAD的工作原理是在LLM生成文本的每一步，动态计算所有符合语法规则的候选词元，并“屏蔽”掉所有不合法的词元 。
• 通过为解码器提供一个描述目标XML结构的语法文件（例如EBNF或XSD），系统可以保证其输出100%是格式良好且符合预定义模式的。换句话说，LLM根本没有机会犯语法错误，因为它从一开始就被剥夺了犯错的权利，从根源上保证了输出的结构绝对正确。
• 这个机制充当了理论模型的实践执行层，确保了生成的XML树严格遵守了交互协议所要求的结构。

四个开箱即用的“交互配方”

这篇论文最棒的地方在于，它不只谈理论，还给出了可以直接在您产品中使用的“配方”：

• 计划→验证→回答 (Plan-Verify-Answer)：这个配方是抑制“幻觉”的利器。它强制模型必须先在<plan>标签里写出计划，然后在<evidence>标签里寻找证据，最后才能在<answer>标签里给出答案，整个流程清晰可审计。

• 安全的工具调用 (Agentic Tool Use)：您可以为API调用设计一套严格的XML语法，比如函数名、参数名、参数类型都规定好。这样一来，模型生成的<toolcall>在语法上永远不会出错，大大提升了Agent的稳定性。
• 透明的多分支推理 (Multi-branch Reasoning)：面对复杂问题，可以设计多个<branch>，让模型在每个分支里独立思考问题的不同侧面。最后再来一个<compare>步骤进行汇总，整个复杂决策的过程就变得一目了然。
• 跨分支通信 (Cross-branch Communication)：这是更高阶的玩法。您可以设计一个共享的<channel>标签，让不同的推理分支能在这里交换信息、互通有无，像一个真正的小团队那样协同工作，共同解决一个大问题。

实践：合同审查与智能客服

我基于论文设计了两个Agent作为示例，模型使用的是Qwen3-4b-thinking，大部分机器都可以跑。

单分支序列化推理商业合同审查Agent

这是一个采用单分支序列化推理+XML语法约束的商业合同审查Agent，将合同逐步解析为固定Schema的结构化结果（计划→推理→风险→建议），并用语法对齐解码保证输出100%可解析。

客服意图识别Agent

这是一个客服意图识别原型，实现了LLM强制输出固定结构的JSON，主要解决LLM输出的“不可预测性”。在客服场景中，比如用户说：“你好，我想查一下我昨天在北京下的那个订单到哪了，收件人是张三。”，模型今天可能返回一个JSON，明天可能返回一个Markdown，后天可能直接返回一段描述性文字。这种输出格式的随机性，对于需要稳定数据接口的软件系统来说，是一场灾难。开发者需要编写大量脆弱、复杂的“胶水代码”去解析、清洗和重试，整个系统摇摇欲坠。

有了这项技术，以后可以不用再费尽心血编写Prompt“请求”模型输出JSON，而是通过技术手段保证模型只能输出合规的JSON。第二个Agent尚未实现论文里的XML交互协议+不动点收敛循环，因此不是完整复现，但在工程上已显著降低解析成本与胶水代码复杂度。可以让LLM从此变成一个行为可预测、接口稳定的软件组件，从一个充满随机性的对话模型，变成了一个可靠的、能返回结构化数据的API。

这周末我会将两份代码都分享在Agent开发交流群里，欢迎您来群里一起交流！

结论与未来

这套组合拳打下来，我们与LLM的交互方式就发生质变了。它不再是一种充满不确定性的艺术，而是变成了一门有数学理论托底、有工程方法可循的、严谨的“交互工程”。论文在导言里提到DSPy，DSPy像是“把一连串LLM调用编译成可学习、可优化的程序”，XML Prompting则是“把每次交互当作受语法约束的协议，并证明这类协议在迭代中会收敛到稳定解”。前者偏系统与编排，后者偏语义与约束。

但是，任何技术都不是银弹，XML Prompting这种强约束方法虽然带来了极高的可靠性，但也增加了前期定义语法的复杂度，并且可能会在一定程度上限制模型的“创造性发散”。

研究者也提到，未来的工作会继续探索更高效的约束解码算法，甚至将更复杂的逻辑检查（比如μ-calculus模型检查）作为实时过滤器集成进来，让这套方法变得更加智能和强大。

文章来自于“AI修猫Prompt”，作者“AI修猫Prompt”。