TOON：一种为大模型设计的JSON压缩型数据结构

一、精准定义，什么是 TOON？

1、JSON 数据格式的局限性

2、TOON 的结构与优势

3、TOON 数据结构的主要特征

4、媒体类型与文件拓展名

二、举例：JSON 与 TOON 描述同一组数据分别是什么样

三、结语

作者：watermelo37
CSDN优质创作者、华为云云享专家、阿里云专家博主、腾讯云“创作之星”特邀作者、火山KOL、支付宝合作作者，全平台博客昵称watermelo37。
一个假装是giser的coder，做不只专注于业务逻辑的前端工程师，Java、Docker、Python、LLM均有涉猎。
---------------------------------------------------------------------
温柔地对待温柔的人，包容的三观就是最大的温柔。
---------------------------------------------------------------------

TOON：一种为大模型设计的JSON压缩型数据结构

最近 AI 圈子里出现了一个新概念：TOON。

官方对它的描述是这样的：一种简洁、易读的 JSON 数据模型编码，最大限度地减少令牌数量，使模型易于理解结构。它旨在作为现有 JSON 的可随插、无损表示，用于 LLM 输入。它结合了 YAML 基于缩进的嵌套对象结构与 CSV 风格的表格布局，用于统一数组。TOON 的优势在于对象数组统一（每行多个字段，项目结构相同），实现类似 CSV 的紧凑性，同时增加了显式结构，帮助大型语言模型可靠解析和验证数据。

当下社区中关于 TOON 的文章质量良莠不齐，有些描述甚至是错误的。本文将结合官方描述与工程视角，对 TOON 做一次尽量简洁、准确的入门性介绍，帮助读者先弄清楚一个问题：

TOON 到底是什么？它解决的是什么问题？

截至目前，TOON 在 GitHub 上已经获得了 21.5k+ Star，一种比JSON更优秀的大模型友好数据格式真的诞生了？

一、精准定义，什么是 TOON？

1、JSON 数据格式的局限性

JSON 在工程世界里几乎无可替代，但在与大模型交互时，它有一个非常现实的问题：结构冗余。尤其是同构对象数组，比如：

{ "hikes": [ { "id": 1, "name": "Blue Lake Trail", "distanceKm": 7.5 }, { "id": 2, "name": "Ridge Overlook", "distanceKm": 9.2 }, { "id": 3, "name": "Wildflower Loop", "distanceKm": 5.1 } ] }

每一行都在重复："id" "name" "distanceKm"。

在 LLM 输入中，这些重复的结构信息会消耗更多的上下文空间。JSON 的问题在于并非为语言模型的上下文机制设计，完善通用的结构给它带来了更多的信息冗余，但信息冗余是要花钱的。

2、TOON 的结构与优势

TOON 的核心思想就是：在保持 JSON 语义不变的前提下，把重复结构前移并声明一次 + 提前告知数据条目总长度。

它融合了三种表达风格：

YAML 的缩进结构：表达对象嵌套
表格化声明：表达同构对象数组
显式结构标注：减少歧义，方便模型解析

其核心就在于 TOON 将键名重复的同构对象数组变成形如“key[n]{a,b,c}:”的声明，后续n行只表示值。

举个例子，上面的JSON数据转化为 TOON 就是：

hikes[3]{id,name,distanceKm}: 1,Blue Lake Trail,7.5 2,Ridge Overlook,9.2 3,Wildflower Loop,5.1

是不是简洁了很多？重复的键名、空格、括号都被去除了。

3、TOON 数据结构的主要特征

官方仓库对于 TOON 的主要特征是这样描述的：

令牌高效且准确：TOON 在混合结构基准测试中，在 4 个模型中，准确率达到 74%（而 JSON 仅为 70%），同时使用约 40% 的令牌。
JSON 数据模型：通过确定性、无损的往返编码与 JSON 相同的对象、数组和原语。
LLM 友好型护栏：明确的[N]长度和{fields}头部为模型提供了清晰的模式，提高了解析可靠性。
最小语法：使用缩进代替大括号，减少引用，赋予类似 YAML 的可读性和 CSV 风格的紧凑性。
表格数组：均匀的对象数组合并成表，表中声明字段一次，逐行传输取值。
多语言生态系统：TypeScript、Python、Go、Rust、.NET 及其他语言中的规范驱动实现。

4、媒体类型与文件拓展名

TOON 文件在 HTTP 和内容类型感知的上下文中使用 .toon 扩展名和临时媒体类型 text/toon。TOON 文档始终采用 UTF-8 编码；可以指定 charset=utf-8 参数，但省略时默认为 UTF-8。

二、举例：JSON 与 TOON 描述同一组数据分别是什么样

TOON 看起来像添加了长度的 csv ？先别急，我们可以通过一个官方的对比案例理解一下 TOON 结构的真实魅力。

原始 JSON是这样的：

{ "context": { "task": "Our favorite hikes together", "location": "Boulder", "season": "spring_2025" }, "friends": ["ana", "luis", "sam"], "hikes": [ { "id": 1, "name": "Blue Lake Trail", "distanceKm": 7.5, "elevationGain": 320, "companion": "ana", "wasSunny": true }, { "id": 2, "name": "Ridge Overlook", "distanceKm": 9.2, "elevationGain": 540, "companion": "luis", "wasSunny": false }, { "id": 3, "name": "Wildflower Loop", "distanceKm": 5.1, "elevationGain": 180, "companion": "sam", "wasSunny": true } ] }

其中有各种特殊格式，比如嵌套、对象数组、非对象数组、普通对象等。转化为 TOON 后就变成了这样：

context: task: Our favorite hikes together location: Boulder season: spring_2025 friends[3]: ana,luis,sam hikes[3]{id,name,distanceKm,elevationGain,companion,wasSunny}: 1,Blue Lake Trail,7.5,320,ana,true 2,Ridge Overlook,9.2,540,luis,false 3,Wildflower Loop,5.1,180,sam,true

在不影响人类可读性的基础上，TOON 去除了所有的普通对象中的大括号、空格甚至双引号，将所有的同构对象数组和普通数组都简化成类似CSV的结构，并将数组的总长度、键名都提前声明，便于大模型获取核心信息。

这一点除了节省 token 外，官方认为还带来了识别和搜索效率的提升，这一点小瓜将在下一次更新《探究TOON的价值边界：比JSON更优的大模型友好数据格式？》中展开介绍。