数据格式演进史（七）：LLM 时代，TOON 与格式的未来

当 AI 成为数据的消费者，一个新的稀缺资源出现了：Token。JSON 的每一个大括号、引号、冒号，都在消耗你的钱。

系列回顾

在这个系列中，我们看到了数据格式 40 年的演进：

每一次演进都由新的约束条件驱动。

2023 年后，一个全新的约束条件出现了：Token。

新时代，新稀缺资源

在 LLM 时代，成本不再按字节计算，而是按 Token 计算。

什么是 Token？

Token 是 LLM 处理文本的基本单位。大致可以理解为：

• 英文：约 4 个字符 = 1 个 Token
• 中文：约 1-2 个字符 = 1 个 Token
• 代码/标点：每个符号可能是独立的 Token

"Hello, World!" → ["Hello", ",", " World", "!"] → 4 Tokens

Token 就是金钱

以 GPT-4 为例（2024 年价格）：

听起来不多？算一下：

Token 数直接决定了 AI 应用的运营成本。

上下文窗口的限制

除了成本，还有容量限制：

听起来很大？但如果你要让 AI 分析一个代码库，或者处理大量结构化数据，很快就会撞到天花板。

JSON 在 LLM 时代的问题

JSON 是为人类可读设计的，不是为 Token 效率设计的。

结构符号的开销

{
    "user_id": 12345,
    "name": "Alice",
    "email": "alice@example.com"
}

让我们数一下 Token：

大约 50% 的 Token 是结构开销，不是实际数据！

更极端的例子

假设你要发送一个用户列表：

[
    {"id": 1, "name": "Alice", "age": 30},
    {"id": 2, "name": "Bob", "age": 25},
    {"id": 3, "name": "Charlie", "age": 35}
]

每个用户都重复 "id", "name", "age"。100 个用户，这些字段名就重复了 100 次。

JSON 的自描述特性，在 LLM 场景下成了累赘。

TOON：Token 导向的格式

2025 年 11 月，TOON（Token-Oriented Object Notation）正式发布，专门为 LLM 场景设计。

设计目标

在保持可读性的同时，最大限度减少 Token 消耗。

TOON 的核心语法

TOON 的核心思想是：用声明式的结构头，替代重复的字段名。

JSON 格式（16 tokens）：

{"users":[{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]}

TOON 格式（13 tokens）：

users[2]{id,name}:
 1,Alice
 2,Bob

关键创新：

• [2] 声明数组长度
• {id,name} 声明字段结构（只出现一次）
• 数据行用逗号分隔，无需重复字段名

Token 节省：18.75%

数组的表示

原始数组：

tags[3]: python,rust,go

等价于 JSON：{"tags": ["python", "rust", "go"]}

对象数组（表格形式）：

JSON：

{
    "users": [
        {"id": 1, "name": "Alice", "active": true},
        {"id": 2, "name": "Bob", "active": false}
    ]
}

TOON：

users[2]{id,name,active}:
 1,Alice,true
 2,Bob,false

省略了什么？

• 所有大括号 {}、方括号 []
• 所有引号 ""
• 重复的字段名（id、name、active 只出现一次）
• 大量的冒号和逗号

Token 节省效果

根据官方测试（使用 GPT-4 tokenizer）：

数据越规整、越重复，节省越多。

TOON 的完整语法

基本类型

# 字符串（简单值不需要引号）
name: Alice

# 包含特殊字符的字符串需要引号
message: "Hello, World!"

# 数字（标准十进制，不用科学计数法）
count: 1000000
price: 19.99

# 布尔值
active: true

# 空值
data: null

对象

user:
 name: Alice
 age: 30

等价于 JSON：

{"user": {"name": "Alice", "age": 30}}

数组语法详解

1. 原始值数组：

colors[3]: red,green,blue

2. 对象数组（表格形式）：

items[2]{id,name,price}:
 1,Apple,1.50
 2,Banana,0.75

3. 列表项形式（用于非统一结构）：

mixed[3]:
 - simple value
 - key: value
 - another

混合结构示例

order:
 id: 12345
 customer:
  name: Alice
  email: alice@example.com
 items[2]{productId,qty,price}:
  101,2,29.99
  102,1,49.99
 tags[2]: urgent,premium
 total: 109.97

等价的 JSON 需要更多结构符号，Token 消耗显著增加。

分隔符选项

TOON 支持多种分隔符：

什么时候用 TOON？

✅ 适合的场景

❌ 不适合的场景

格式演进的新维度

TOON 的出现揭示了一个有趣的趋势：

数据格式的「消费者」在变化。

未来可能会有更多为 AI 优化的格式。

三方博弈

现在的数据格式需要同时考虑三方：

        人类可读
           ▲
          /|\
         / | \
        /  |  \
       /   |   \
      /    |    \
     ▼     ▼     ▼
程序高效 ◄────► AI 高效

• 人类可读：JSON, YAML, TOML
• 程序高效：Protobuf, FlatBuffers
• AI 高效：TOON（以及未来更多）

最优解可能是：不同场景用不同格式。

未来展望

趋势一：场景专用化

通用格式（JSON）的时代可能在终结。未来可能是：

• 公开 API → JSON（通用性）
• 微服务 → Protobuf（效率）
• 配置 → TOML（简单性）
• AI 交互 → TOON（Token 效率）

趋势二：智能转换

未来的工具可能自动选择格式：

# 伪代码
data = load_data()

if target == "human":
    output = to_json(data)
elif target == "service":
    output = to_protobuf(data)
elif target == "llm":
    output = to_toon(data)

趋势三：AI 原生格式

TOON 可能只是开始。未来可能出现：

• 针对特定模型优化的格式
• 动态压缩（根据上下文调整）
• 语义压缩（AI 自动理解省略）

系列总结

40 年的演进规律

驱动力一直是：新的约束条件。

每次演进都不是「更好」，而是「更适合新场景」。

格式选择的本质

选择数据格式，本质上是在多个维度之间做权衡。

没有最好的格式，只有最适合当前约束的格式。

决策框架

你的数据要做什么？
│
├── 人类编写和阅读 → YAML / TOML
│
├── 程序间通信
│   ├── 公开 API → JSON
│   ├── 内部微服务 → Protobuf / gRPC
│   └── 极致性能 → FlatBuffers
│
├── AI 交互 → TOON
│
└── 不确定 → 从 JSON 开始，按需演进

最重要的教训

技术选型的核心不是「什么最好」，而是「什么最适合」。

每种格式都是在特定约束下的最优解。约束变了，最优解就变了。

保持开放，持续学习，是应对技术演进的唯一方式。

这个系列到此结束。感谢阅读。

如果你的团队正在选型数据格式，希望这个系列能给你一些启发。

如果你有任何问题或想法，欢迎留言讨论。

上一篇：API 范式之争：REST、GraphQL、gRPC

本系列：

1. 从 XML 到 JSON，复杂之死
2. 二进制觉醒：当 JSON 不够快
3. 零拷贝：当序列化本身也嫌慢
4. 列式革命：当数据以亿行计
5. 配置文件简史：从混沌到秩序
6. API 范式之争：REST、GraphQL、gRPC
7. LLM 时代：TOON 与格式的未来（本篇）

延伸阅读：

• TOON 官方规范
• TOON Rust 实现