TOON 是一种专为大型语言模型设计的轻量级数据格式。它的名字是 Token-Oriented Object Notation 的缩写，直译过来就是“面向令牌的对象表示法”。

它的核心设计理念是：在保证数据可被机器解析的前提下，最大限度地减少不必要的格式符号（如引号、逗号、大括号），从而节省宝贵的令牌数量，并提升LLM阅读和生成的效率。

为什么需要 TOON？（解决的问题）
在使用LLM时，我们最常用的数据交换格式是 JSON。JSON 对人类和机器都很友好，但它有一些对LLM不友好的地方：

令牌浪费：JSON 中的引号 " "、逗号 ,、花括号 {}、方括号 [] 等符号本身也会被LLM当作令牌来处理。在一个复杂的结构中，这些“格式令牌”可能会占到总令牌数的20%-30%，但它们并不承载核心数据信息。

解析负担：LLM在生成JSON时，必须小心翼翼地保持这些符号的平衡和正确性，否则就会导致解析失败。这会增加LLM的认知负担和出错概率。

可读性干扰：对于LLM来说，过多的标点符号会干扰它对核心数据内容的提取和理解。
TOON 就是为了解决这些问题而诞生的。
TOON 的核心语法规则
TOON 的语法非常简洁，可以看作是 JSON 的“极简主义”版本。

TOON 的核心语法规则

TOON 的语法非常简洁，可以看作是 JSON 的“极简主义”版本。

特性

TOON 与 JSON 的直观对比
假设我们要描述一个用户信息：

JSON 格式：

{
  "user": {
    "id": 12345,
    "name": "Charlie",
    "email": "charlie@example.com",
    "hobbies": ["reading", "hiking", "coding"],
    "profile": {
      "level": "admin",
      "active": true
    }
  }
}

（令牌数：约50+）

TOON 等效格式：

user: {
  id: 12345
  name: Charlie
  email: charlie@example.com
  hobbies: [ reading hiking coding ]
  profile: {
    level: admin
    active: true
  }
}

（令牌数：约35-）

对比分析：
TOON 版本移除了所有双引号和大部分逗号。
结构依然清晰，但对LLM和人类来说，核心数据（Charlie, reading, admin）更加突出。
令牌数量显著减少，这意味着更低的API成本和更快的处理速度。

TOON 的优势
令牌高效：最核心的优势，直接节省开销。
LLM友好：简化了生成和解析的难度，LLM更容易输出格式正确的内容。
易于解析：虽然不如JSON标准，但其基于换行和缩进的规则仍然足够简单，可以很容易地用正则表达式或简单的解析器来处理。
可读性强：对于人类来说，干净的格式也提升了可读性。

TOON 的潜在挑战与注意事项
类型模糊：由于默认都是字符串，数字、布尔值等需要LLM或解析器根据上下文来推断。在复杂场景下可能存在歧义。
生态不成熟：JSON拥有无比强大的生态系统和工具支持。TOON 作为一种新格式，缺乏成熟的验证器、解析库和广泛的行业认可。
需要约定：使用TOON需要团队内部或与LLM之间提前约定好数据结构和类型，不像JSON那样是“自描述”的。
特殊字符处理：如果字符串值本身包含冒号 :、方括号 [] 或定界符 »«，可能会引起解析错误，这时可能需要回退到使用引号或转义机制。

总结
TOON 是在 LLM 时代对数据格式进行的一次“成本优化”和“效率优化”的探索。
它不是要取代 JSON，而是作为在 “LLM-to-LLM” 或 “LLM-to-Program” 通信场景下的一个高效替代方案。
在需要极致优化令牌用量、并且对类型要求不苛刻的内部流程中，TOON 是一个非常出色的选择。
在与外部系统交互或需要严格类型定义的场合，JSON 仍然是更安全、更标准的选择。
简单来说，你可以把 TOON 理解为 “为AI特供的简化版JSON”。