简介：在大模型应用中，结构化数据的表示方式会直接影响Token消耗、上下文利用率和模型理解准确度。本文围绕TOON这一面向LLM的JSON压缩与改写格式，系统对比JSON、YAML、XML等常见表达方式，从压缩效果、可读性、校验能力、适用场景等维度展开分析，帮助开发者在数据喂给大模型前选择更合适的中间表示格式，降低调用成本并提升输出稳定性。
在大模型应用开发中，Token数量不仅直接决定调用成本，还影响上下文窗口的利用率。当需要把结构化数据，例如用户列表、日志记录、商品信息、配置项或表格数据传给大模型时，数据表达格式的选择会显著影响最终消耗的Token数量。
常见的做法是直接把JSON或YAML文本放入提示词。但这类格式为了满足人类可读性和程序可解析性，通常带有大量结构符号，例如引号、花括号、方括号、冒号、换行和缩进。对于大模型而言，这些符号并不总是必要的信息载体，反而会占用宝贵的Token预算，压缩真正可用于推理和生成的空间。
因此，在“程序之间仍然使用标准数据格式”的前提下，引入一种面向大模型输入场景的中间表示格式，成为一种降低Token消耗、提高上下文利用率的可行思路。TOON就是围绕这一目标设计的结构化标记格式。
本文主要对比以下四类结构化数据表达方式在大模型输入场景下的表现：
JSON：最常见的结构化数据交换格式，广泛用于API通信、配置文件和日志记录。优点是生态成熟、解析器丰富，但在表示大型数组或表格数据时，结构符号重复度高，Token消耗较大。
JSON Compact：去除换行和多余空格的紧凑JSON形式，减少无效空白字符，但保留引号、冒号、逗号和括号等必要语法符号。相比格式化JSON，Token数量有所下降，但结构信息仍然冗余。
YAML：以缩进表示层级关系的配置友好格式，可读性较好，常用于配置文件。Token消耗通常低于格式化JSON，但在深层嵌套或大型数组场景下仍存在较多结构开销。
XML：标记语言格式，带有开始标签和结束标签，结构清晰但冗余度最高，Token消耗通常最大。在数据交换领域已逐渐被JSON取代，但在某些行业和遗留系统中仍然存在。
TOON：面向Token优化的结构化标记格式，专为LLM输入设计。它试图在保留数据完整性的前提下，用更紧凑的语法表示结构化数据，尤其适合对象数组和表格类数据。
这些格式在本质目标上存在共同点：
都能表示结构化数据：无论是JSON、YAML、XML还是TOON，都具备表达键值对、嵌套对象和数组的能力。
都需要被解析或理解：在传统程序场景中，这些格式需要对应的解析器；在大模型场景中，则依赖模型对格式语义的理解能力。
都服务于数据传递：它们的核心用途是在不同组件之间传递结构化信息，区别只在于传递的对象是人类、程序还是大模型。
都关注表达效率与准确性：任何格式都希望在表达完整信息的前提下尽可能简洁，只是不同格式对“简洁”的定义和优化方向不同。JSON优化程序解析，YAML优化人类可读，TOON优化Token效率。
TOON最具辨识度的特点是将对象数组抽象为“表格”结构。以一组用户数据为例：
格式化JSON：
{"users": [{"id": 1,"name": "Alice","role": "admin"},{"id": 2,"name": "Bob","role": "user"}]}
YAML：
users:- id: 1name: Alicerole: admin- id: 2name: Bobrole: user
TOON：
users[2]{id,name,role}:1,Alice,admin2,Bob,user
可以看到，TOON把数组声明为users[2]{id,name,role}，其中[2]表示元素数量，{id,name,role}声明列名，后续每行用逗号分隔字段值。这种方式消除了每个元素中重复的键名，也去掉了引号、花括号和层级缩进。当数组规模越大、字段一致性越高时，节省效果越明显。
根据相关测试数据，在统一对象数组场景下，TOON相比格式化JSON通常可以减少30%至60%的Token消耗。在一组包含多字段记录的对比测试中，各格式的Token消耗和任务准确度表现如下：
| 格式 | 相对得分 | 准确度 | Token消耗 |
|---|---|---|---|
| TOON | 26.9 | 73.9% | 2,744 |
| JSON Compact | 22.9 | 70.7% | 3,081 |
| YAML | 18.6 | 69.0% | 3,719 |
| JSON | 15.3 | 69.7% | 4,545 |
| XML | 13.0 | 67.1% | 5,167 |
从数据可以看出，TOON在Token消耗最低的同时，还取得了最高的任务准确度。这说明紧凑的表格化表达不仅节省了Token，也有助于模型更快地抓住数据结构的关键信息。
JSON和XML支持任意深度的嵌套结构，可以表达非常复杂的层级关系。YAML通过缩进也能表达深层嵌套，但在层级深时容易产生可读性问题。
TOON虽然在名称上带有“面向Token优化”的定位，但其表格化设计更适合字段一致的数组数据。对于高度不规则、深层嵌套或字段差异较大的对象，TOON的表达优势会减弱，甚至需要额外的约束标记来维持可解析性。因此，TOON更适合作为“中间层格式”，而不是完整替代JSON的所有使用场景。
TOON的设计还引入了格式化层面的约束信息，帮助大模型在生成或解析时进行校验。例如，通过显式声明数组长度和列名，模型在处理数据时可以更清楚地知道预期字段和记录数量。这种“安全栏”机制有助于减少模型在输出结构化数据时出现字段遗漏、格式错误或幻觉生成的情况。
JSON Schema虽然也能实现类似的校验能力，但需要额外的Schema定义文件，通常只被程序校验器使用，大模型在免费文本生成场景下难以直接利用这些约束。TOON则把基础约束直接嵌入数据表示中，使模型能够在单一输入内获得结构信息，从而提升解析和生成的稳定性。
JSON和YAML对人类可读性较好，尤其是格式化JSON和YAML，在调试和人工审查时更直观。TOON的紧凑语法在Token效率上占优，但当数据行数增加、字段含义不直观时，人工阅读和排查问题的难度会上升。
这意味着TOON更适合由程序自动生成和解析，而非作为人工维护的配置文件格式。在实际应用中，后端系统可以保持JSON作为内部数据格式，在发送给大模型前自动转换为TOON，模型返回结果后再转换回JSON。这种自动化链路可以兼顾可维护性和Token效率。
JSON被几乎所有编程语言和工具原生支持，YAML也在配置管理领域广泛使用，XML则有成熟的解析体系和行业标准。TOON作为较新的格式，生态兼容性仍在建设阶段，需要开发者自行实现编码器和解码器，或依赖社区提供的转换工具。
在现有系统中引入TOON，需要额外开发和维护格式转换逻辑。这部分工作应当在评估Token节省收益后谨慎决定。如果数据规模不大或调用频次不高，直接使用紧凑JSON可能是更务实的选择。
适合使用TOON的场景：
适合继续使用JSON或紧凑JSON的场景：
适合使用YAML的场景：
XML在今天的大模型输入场景中通常不是优先选择，除非数据源本身来自遗留系统，或需要基于行业标准进行数据交换。
如果决定在项目中引入TOON作为大模型输入格式，需要注意以下问题：
格式转换的正确性：转换逻辑需要保证原始数据和TOON表达之间的无损映射，尤其是处理空值、字符串中包含逗号、嵌套数组、特殊字符转义等情况。对于可能包含逗号的字符串字段，需要在转换规则中明确转义或定界策略。
模型理解能力：虽然TOON的设计面向LLM，但不同模型对紧凑格式的理解能力可能存在差异。在上线前应针对实际模型进行小规模测试，对比不同格式下的输出准确率和格式合规率，确保压缩带来的Token收益没有被理解能力下降所抵消。
链路可观测性：由于TOON的可读性一般，建议在日志和调试环境中保留原始JSON版本，仅在发送给模型前做转换。这样可以在排查问题时快速定位数据层面的异常。
降级机制：当模型对TOON格式的输出或输入出现明显不稳定时，系统应能快速回退到JSON格式。这也意味着提示词模板需要支持格式切换，而不是将TOON硬编码在所有调用路径中。
数据安全考虑：无论使用哪种格式，发送给大模型的数据都应经过必要的脱敏和权限控制。TOON压缩的是表达方式，不能替代数据访问层和敏感信息过滤机制。
TOON与大模型输入场景中常见的JSON、YAML、XML格式相比，最核心的差异在于它不再以“程序解析方便”或“人类可读性好”为首要目标，而是以“降低Token消耗、提升模型理解效率”为设计出发点。通过将对象数组抽象为表格结构，TOON在字段一致性高、数据量大的场景下能够显著减少冗余结构符号，从而节省Token预算并提高上下文利用率。
但TOON并非适用于所有场景。对于数据结构简单、调用量低或人工审查频繁的情况，继续使用JSON可能是更合理的选择。对于需要强生态兼容性和跨系统互操作的场景，JSON和YAML的地位短期内难以被替代。
选择哪种格式，本质上是在Token成本、开发维护成本、模型理解稳定性和团队调试效率之间做出权衡。对于已经具备程序化提示词生成能力、且在大规模数组数据上消耗大量Token的团队，TOON提供了一条值得验证的优化路径；而对于更注重简单性和可维护性的团队而言，紧凑JSON依然是稳健的默认选择。