直接回答
TOON（Token-Oriented Object Notation）是面向 LLM 输入的紧凑 JSON 数据模型文本编码。当数据包含同构对象数组时，它可以只声明一次字段名，让每一行只携带值，因此最可能获得 Token 收益。
TOON 不保证固定节省比例、更低时延、更高准确率或所有模型兼容。当前 TOON v4.1 规范仍是 Working Draft。更稳妥的用法，是在 LLM 边界把 TOON 作为经过实测的翻译层，而在应用内部继续以 JSON 或类型化对象作为 Source of Truth。
TOON 编码什么
TOON v4.1 表示与 JSON 相同的六类值：Object、Array、String、Number、Boolean 与 Null。它使用缩进、显式数组长度、有作用域的 Delimiter 和最小必要引号。
JSON 示例：
{
"users": [
{"id": 1, "name": "Ada", "role": "admin"},
{"id": 2, "name": "Bob", "role": "user"}
]
}
对应 TOON：
users[2]{id,name,role}:
1,Ada,admin
2,Bob,user
收益来自移除重复 Key 与标点。数据没有重复结构时，这项优势可能消失。
四种数据形态
v4.1 规范根据数据形状选择四种形式：
| 形式 | 适合的数据 | 示例 |
|---|---|---|
| Inline | Primitive Array | tags[3]: api,go,ai |
| List | 混合或非同构 Array | 每个元素一行 - |
| Tabular | 同构对象 Array | users[2]{id,name}: |
| Keyed Tabular | Value 具有同一结构的 Object | Key 加共享字段 |
Object 使用缩进键值行。只有语法要求时才为 String 加引号，例如容易混淆的 Literal、Active Delimiter、首尾空格和特定特殊字符。
显式长度和字段列表可帮助 Strict Decoder 发现缺行或缺列，但不能证明数值在事实上正确。
何时值得评测 TOON
以下情况适合把 TOON 纳入候选：
- Prompt 中有大量同构记录数组；
- 重复 JSON Key 占据明显负载；
- 目标模型已经表现出足够的 TOON 理解能力；
- 应用可以使用锁定版本的实现进行 Encode 与 Strict Decode；
- 数据只穿过内部 LLM 边界，而不是公共 API 契约；
- Token 减少能对容量或成本产生实际影响。
例如经过筛选的分析记录、商品列表、事件摘要，或结构稳定的只读 Tool Result。
以下场景应优先考虑 JSON、Compact JSON、CSV 或其他契约：
- 数据深层嵌套、稀疏或非同构；
- Payload 很小，格式说明反而占主导；
- 供应商的 Constrained JSON 能可靠覆盖目标 Schema；
- 外部系统已经要求
application/json； - 模型输出需要接入广泛的现有工具链；
- 团队无法维护版本化 Codec 与 Conformance Suite。
纯平面表格可能由 CSV 更紧凑；混合业务对象则可能由 Compact JSON 获得更好互操作性。
为什么不能承诺统一节省比例
Token 节省取决于：
Payload 形状
+ Serializer 选项
+ JSON 基线是 Pretty 还是 Compact
+ Tokenizer 与 Vocabulary
+ 语言和值
+ TOON 说明和示例
+ 模型生成错误
+ Repair 与 Retry Turn
字符数不是 Token 数。相同文本在不同 Encoding 下会产生不同切分，标点也可能与相邻文本合并。不能用“四个字符约等于一个 Token”估算生产费用。
官方项目发布了特定语料和模型下的 Benchmark，可用于理解对应设置，不能作为 SLA。
两项 2026 年独立研究揭示了适用边界：
- TOON 生成对比实验发现，短输出或复杂结构中的格式说明和修复轮次可能削弱优势；该实验里 Plain JSON 的 One-shot 与 Final Accuracy 更强，Constrained JSON 在部分简单案例中 Token 更少。
- Agentic Tool-use Benchmark覆盖四项 Benchmark 和五个开源模型。在其聚合设置中，TOON 最高约减少 18% Token，同时最多损失约 9 个百分点准确率，多轮 Parse Failure 还可能发生级联。
两篇论文都不能证明 TOON 没有价值。它们共同说明：输入压缩、输出生成和端到端 Agent 成功必须分开测量。
输入与输出是两个决策
把可信应用数据编码成 TOON 输入，比要求模型生成 TOON 更容易控制。
输入翻译
类型化应用数据
-> JSON-compatible Value
-> 锁定版本 TOON Encoder
-> 模型上下文
序列化由应用控制。需要让同一份数据分别使用 Compact JSON 与 TOON，比较模型理解效果。
模型生成输出
模型输出
-> Strict TOON Decoder
-> Schema 与语义校验
-> Retry 或 Reject
生成路径增加了解析与修复风险。Constrained JSON API 可能提供更强输出契约。应比较 First-pass Validity、Semantic Accuracy、包含修复在内的总 Token 与 Tail Latency。
Function Calling 和 MCP 等 Tool Protocol 通常使用 JSON-shaped Schema 与 Wire Message。替换外部 Wire Format，与压缩模型上下文中的有界数据块是两件事。不要把 TOON 描述成协议升级。
固定版本与 Round Trip 契约
记录：
{
"format": "toon",
"spec_revision": "4.1",
"implementation": "github.com/toon-format/toon-go",
"implementation_version": "v0.1.0",
"options": {
"indent": 2,
"delimiter": "comma",
"strict_decode": true
},
"source_schema": "records-v3",
"tokenizer": "[email protected]"
}
官方 Go 实现明确记录了 Host Language 边界：无类型 Number 解码为 float64，超出互操作范围的整数可能转为带引号字符串，Go Map 不保留源字段顺序，Strict Mode 会拒绝缩进中的 Tab。应用必须测试真正关心的类型。
Round-trip Test 至少覆盖：
- 空 Object 与 Array；
- 看起来像 Boolean、Null 或 Number 的 String；
- Delimiter、Colon、Quote、Backslash 与 Newline；
- Unicode 与 Normalization 变体；
- 大整数与 Decimal；
- Mixed / Deeply Nested Array；
- 截断 Row 与错误声明长度；
- 不同实现之间的 Fixture。
“Decode 成功”弱于“与期望类型值完全一致”。
可复现的 Go 测量
下面固定官方组织的 Go Codec 和一个 Tokenizer 实现，比较相同类型值的 Compact JSON 与 TOON，并验证 Round Trip。
go mod init toon-measure
go get github.com/toon-format/[email protected]
go get github.com/tiktoken-go/[email protected]
go run .
package main
import (
"encoding/json"
"fmt"
"reflect"
"github.com/tiktoken-go/tokenizer"
"github.com/toon-format/toon-go"
)
type User struct {
ID int `json:"id" toon:"id"`
Name string `json:"name" toon:"name"`
Role string `json:"role" toon:"role"`
}
type Payload struct {
Users []User `json:"users" toon:"users"`
}
func tokenCount(encoder tokenizer.Codec, text string) (int, error) {
ids, _, err := encoder.Encode(text)
if err != nil {
return 0, err
}
return len(ids), nil
}
func main() {
input := Payload{Users: []User{
{ID: 1, Name: "Ada", Role: "admin"},
{ID: 2, Name: "Bob", Role: "user"},
{ID: 3, Name: "Lin", Role: "reviewer"},
}}
jsonBytes, err := json.Marshal(input)
if err != nil {
panic(err)
}
toonText, err := toon.MarshalString(input)
if err != nil {
panic(err)
}
encoder, err := tokenizer.Get(tokenizer.Cl100kBase)
if err != nil {
panic(err)
}
jsonTokens, err := tokenCount(encoder, string(jsonBytes))
if err != nil {
panic(err)
}
toonTokens, err := tokenCount(encoder, toonText)
if err != nil {
panic(err)
}
var decoded Payload
if err := toon.UnmarshalString(toonText, &decoded); err != nil {
panic(err)
}
if !reflect.DeepEqual(input, decoded) {
panic("round trip changed the payload")
}
fmt.Printf(
"encoding=cl100k_base json=%d toon=%d delta=%d round_trip=true\n",
jsonTokens,
toonTokens,
toonTokens-jsonTokens,
)
}
使用上面固定的依赖版本，这份 Fixture 输出：
encoding=cl100k_base json=41 toon=33 delta=-8 round_trip=true
这只是一次具体测量，不是通用节省比例。应使用生产形态 Payload 与目标模型实际使用的 Tokenizer 重复测试，并把所有格式说明一起计入 Prompt。
评测端到端结果
建立以下矩阵：
| 维度 | 测量内容 |
|---|---|
| Size | 输入、输出、说明与修复 Token |
| Parsing | 首次有效率、Strict Error、截断检出 |
| Semantics | 精确字段、值、类型与缺失数据 |
| Model Behavior | 理解、生成、Tool Selection、最终任务成功 |
| Operations | Encode/Decode CPU、时延、内存、重试 |
| Compatibility | Model、Tokenizer、Language、Library、Schema |
| Security | Injection、超大值、损坏嵌套、Authorization |
至少比较 Compact JSON 与 TOON。只有真正的 Flat Table 才加入 CSV；目标端点支持时，再加入 Constrained JSON。
决策指标应使用每个合格任务成本：
(所有 Prompt + Completion + Repair + Downstream Cost)
/ Valid 且语义正确的结果
若一种格式首轮节省 15%，却让修复次数翻倍，端到端结果仍可能更差。
安全边界
TOON 是语法，不是信任机制。
- 不要手工插值不可信值，应使用一致性 Encoder。
- 使用 Strict Mode，并限制 Depth、Size、Row 与 Time。
- 解码后继续执行应用 Schema 校验。
- 在编码文本之外保存来源与 Trust Metadata。
- 即使字符串中包含指令，也要把它当成数据。
- 解码后逐次授权 Tool Call 与副作用。
- 不要因为格式紧凑就把 Secret 放进 Prompt。
规范中的长度声明可以发现部分损坏输入，却不能阻止 Prompt Injection、Data Poisoning 或 Unauthorized Action。
迁移与回滚
通过 Experiment Flag 引入 TOON：
- 固定代表性 Payload 与期望输出；
- 固定 Spec、Codec、Tokenizer、Model 与 Prompt；
- 离线比较 Compact JSON 与 TOON；
- Shadow 生产输入，不改变用户结果；
- 只在低风险、只读路径上 Canary；
- 监控 Parse Error、Repair、任务质量、时延与成本；
- Schema、Model 或 Data Shape 不支持时回退 JSON。
如果应用需要长期互操作，不要只保存 TOON 文本。保留类型化源数据与 Schema，使 Working Draft 或 Library 变化后仍可重新生成表示。
常见问题
TOON 是什么？
TOON 是面向 LLM 输入、按行并依赖缩进的 JSON 数据模型编码。它声明 Array Length，并可让同构记录只声明一次共享字段。当前 v4.1 文档仍是 Working Draft，因此部署必须固定 Spec 与 Codec。
TOON 能节省多少 Token？
没有可移植的百分比。需要在代表性 Payload 上使用精确 Tokenizer 比较 Compact JSON 与 TOON，并把 Format Instruction、Output、Parse Failure、Repair 和 Retry 纳入端到端结果。
TOON 是无损的吗？
规范为其 JSON 数据模型定义了确定性 Round Trip，但 Host Language Normalization 与实现限制仍会影响结果。应测试数值精度、顺序、Unicode、时间、边界字符串、截断和跨实现 Fixture。
应该让 LLM 生成 TOON 输出吗？
只有直接比较后才能决定。TOON 生成可能增加说明和修复成本，而供应商的 Constrained JSON 可能提供更强的机器消费契约。必须测量 First-pass Semantic Correctness，而不只是语法。
TOON 能提高安全吗？
不能。它可以让 Strict Decoder 检查长度和结构，却不能建立 Provenance、防止 Prompt Injection、授权 Tool 或验证业务动作。每个解码值仍是不可信输入。
常见失败模式
- 承诺固定节省 30%、40% 或 50%；
- 用 Pretty JSON 对比 TOON，却在生产使用 Compact JSON；
- 根据字符数估算 Token；
- 忽略格式说明与 Repair Turn；
- 未实测便对不规则或深嵌套数据使用 TOON；
- API 已支持 Constrained JSON，却不比较便要求模型输出 TOON；
- 假设任何模型无需示例就能理解；
- 非严格解码并接受部分结果；
- 把 Round Trip 成功当作模型准确；
- 只为 Prompt 压缩而替换公共 JSON API 或存储；
- 不记录 Codec、Spec、Tokenizer 与 Model 版本；
- 把紧凑语法当成 Injection 防护。
决策检查清单
- [ ] 确认重复 Key 占据了有意义的 Payload。
- [ ] 使用相同数据与 Compact JSON 比较。
- [ ] 使用目标 Tokenizer 计数。
- [ ] 计入格式说明、输出、Repair 与 Retry。
- [ ] 固定 TOON v4.1 或实际支持的 Spec Revision 与 Codec。
- [ ] 对边界 Fixture 做 Strict Round Trip。
- [ ] 分开测量模型理解与生成。
- [ ] 解码后执行语义与业务校验。
- [ ] 把身份、权限与副作用留在格式之外。
- [ ] 使用 Feature Flag 发布，并保留 JSON Fallback。
相关资源
一手资料
- TOON v4.1 规范
- TOON for Go v0.1.0
- TOON 与 JSON 的普通生成和约束解码实验
- Notation Matters：Agent 系统中的 Token 优化格式
- RFC 8259：JSON 数据交换格式
总结
只有 Data Shape、Tokenizer、Model 和 Workflow 同时匹配时，TOON 才有价值。Tabular Form 能消除重复结构，但格式说明、Parse Failure、Retry 和语义错误决定了压缩收益能否保留到端到端。应用继续以 JSON 作为稳定契约，固定 TOON Revision，测量完整请求，并且只在不牺牲可靠性的路径上按每个合格任务成本采用它。