TOON（Token-Oriented Object Notation）完整说明
全称：Token-Oriented Object Notation，面向Token的对象表示法，后缀 .toon；2025年推出，专门为大模型LLM结构化输入设计的数据序列化格式。
注意：不要和图形领域 Toon Shader（卡通渲染）混淆，二者完全无关。
一、TOON格式是什么
TOON是JSON数据模型的无损紧凑编码格式：
- 可以100%双向无损转换 JSON ↔ TOON，支持对象、数组、字符串、数字、布尔、null；
- 语法融合两类风格：
- 嵌套对象：类似YAML，用缩进代替
{}； - 同构对象数组：类CSV表格，字段名只写一次，每行只放数值；
- 嵌套对象：类似YAML，用缩进代替
- 设计目标：减少送入LLM时的Token数量，同时提升模型解析准确率。
简单示例
JSON
{"users": [{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]}
TOON
users[2]{id,name}:
1,Alice
2,Bob
二、TOON 解决什么核心问题
传统场景向大模型传递批量结构化数据（知识库、列表、业务记录）时，JSON存在严重Token浪费：
- 数组内每条记录重复书写
"id":、"name":大量重复键名； - 大量括号、引号、逗号占用额外Token；
- Token变多带来三大痛点：
- API调用费用更高；
- 更容易触发上下文长度超限；
- 超长文本下LLM更容易乱解析、字段丢失。
TOON核心定位： 日常代码依然使用JSON处理业务；仅在投喂数据给LLM前，把JSON转TOON，降低Token开销，提升解析稳定性。
三、优点
- Token显著节约 同一份结构化数组数据，相比JSON减少 30%～60% Token；同构列表（订单、用户、日志）收益最大。
- LLM识别准确率更高
显式标注数组长度
[N]与字段头{field1,field2}，给模型明确结构约束，减少幻觉、字段错乱。 - 可读性良好 去除大量冗余标点，表格形式直观，人工调试比压缩JSON更容易阅读；不需要额外转义大量引号。
- 无损双向转换 JSON具备的数据类型TOON全部支持，序列化/反序列化不会丢失信息。
- 多语言SDK成熟 Python、TS/JS、Go、Rust、Java均有官方解析库，集成成本低。
- 区分优化不同结构 扁平表格数组采用CSV风格极致压缩；深度嵌套对象使用缩进，兼顾两种场景。
四、局限性（适用边界，非常关键）
- 不适合通用网络API传输 HTTP接口标准生态是JSON；没有浏览器原生解析支持，不能替代JSON作为通用接口格式。
- 深度不规则嵌套收益很差 当对象层级极深、每条数据字段不统一（异构结构），TOON压缩优势大幅缩水，甚至略逊JSON。
- 生态普及度低 不属于行业标准格式，缺少通用中间件、日志工具原生支持；团队外部协作不友好。
- 不适合持久化长期存储 诞生时间短，规范还在迭代；数据持久存储优先JSON/Parquet等成熟方案。
- 对超短零散对象提升有限 只有批量数组列表场景收益明显；单个简单对象，TOON和JSON差距很小。
- 存在分隔符冲突风险 CSV风格逗号分隔，字段内容包含逗号时需要转义，增加编解码复杂度。
五、适用场景 vs 不适用场景
✅ 适合
- RAG检索后，批量文档元数据送入LLM；
- 批量业务数据表（用户、商品、订单）作为Prompt上下文；
- Agent工具调用，需要把多条记录传给大模型；
- 需要控制Token成本、避免上下文溢出的长提示词工程。
❌ 不适合
- Web前后端接口交互；
- 数据库持久存储、消息队列标准消息体；
- 对外公开开放API；
- 深度嵌套、结构多变的复杂异构数据。
六、一句话总结对比
- JSON：通用、全场景标准，但是送入LLM存在大量冗余Token；
- TOON：LLM Prompt专用的轻量化交换格式，批量表格数据极致省Token；它是JSON的“LLM专用传输变体”，不是替代品，是补充方案。
如果你需要，我可以给你一份：TOON、JSON、YAML三者横向对比表格，或者一段Python JSON ↔ TOON转换示例代码。