我让两个 AI 编程工具协作做一个任务，token 账单是单独跑的 4 倍——这个问题今天终于有解了

我让两个 AI 编程工具协作做一个任务，token 账单是单独跑的 4 倍——这个问题今天终于有解了。

这不是工具的问题，也不是模型的问题，而是 CoT（Chain-of-Thought）本身的结构性问题：自然语言是人类设计的推理语言，但它从来不是为机器之间的高效通信设计的。中科院 ICML 2026 这篇论文提出了一个新思路——让 LLM 自己发明「机器语言」，结果 token 消耗直接降了 3 到 6 倍，准确率还基本不掉。

CoT 的代价：人类友好，机器费油

CoT 之所以有效，本质上就是把「一次性猜答案」拆成「一步步推理」，中间状态外化出来，降低单次解码难度。但它默认中间状态必须用自然语言 prose 展开——这就产生了一个隐蔽的结构性成本。

你去看一段标准 CoT 推理，里面有大量的修辞性冗余：「首先我们考虑……」「因此可以看出……」「为了验证答案，我们再检查……」，这些对人类读者友好，但对模型继续推理的最小状态而言，信息密度其实很低。在 autoregressive decoding 里，每个 token 不仅影响成本，还直接影响延迟和吞吐。

现有的三条路线都有各自的局限：

第一条是 prompt optimization——优化自然语言指令的表面形式。它很有价值，但本质上还是在优化「怎么提问」，而不是改变「推理过程的通信介质」。

第二条是压缩推理——比如 Chain-of-Draft、Sketch-of-Thought、Compressed CoT。核心思路是让模型少写。但问题在于：短不等于有效。压缩删掉变量绑定、候选排除、证据链接，准确率会跟着掉。

第三条是程序辅助推理——PoT、PAL，把推理转成程序由外部解释器执行。这条路在可程序化任务上非常强，但它依赖人类预设的程序语言和 executor，不回答「LLM 自身能否发现适合自己的中间符号系统」这个更底层的问题。

换个角度：推理是机器之间的通信问题

CLSR 这篇论文的核心洞察，是把测试时推理从「写文本」重新定义为「机器之间的带宽受限状态传输」。如果 token 是带宽，那么推理效率的本质问题就变成了：每个 token 能携带多少对答案有用的状态？

这个视角转换带来的改变是根本性的——从「让模型少说话」转向「让模型用更高信息密度的中间语言」。

论文把这种中间语言叫做 LSF（Language Symbolism Framework）。注意，这里说的「语言」不是人类专属的自然语言，也不是说 LLM 获得了人类的语言能力，它指的是操作意义上的离散符号通信协议。一个 LSF 包含符号表、语法规则、推理操作定义、有效性约束和经验 profile。

比如一个数学类 LSF 可能长这样：

[bind] x=..., y=...
[sub] need: eliminate distractor B/C
[op] evidence(A) > evidence(D); constraint: mechanism match
[chk] no contradiction with condition-2
[ans] A

这跟自然语言的风格完全不一样。它不追求文学性，也不追求对人类完全自解释，只追求在尽可能少的 token 中，保留足以让模型继续推理、验证或输出答案的结构化状态。

CLSR 三阶段：生成→演化→路由

CLSR 分三个阶段工作。

第一阶段：LSF synthesis。 给定 benchmark 的训练样例，CLSR 先采样一批 exemplars 作为上下文，让 LLM 自己设计能在保持推理能力的同时减少 token 的 LSF。这一步人类只给高层目标「正确且 token-efficient」，不对符号表、语法做任何人工编辑。较高采样温度会产生从 strict LSF（接近机器式压缩协议）到 soft LSF（仍保留较多自然语言结构）的多样化候选。

第二阶段：LSF evolution。 这是整个框架最有趣的部分。CLSR 用一个迭代 bootstrapping 过程逐代改进 LSF pool：先用当前 LSF 回答新的训练/验证问题，记录答案正确性与 completion token 成本；然后选择同时正确且短的 high-leverage traces；将这些 trace、父代 LSF 和失败信息反馈给 LLM，生成下一代 LSF；重复评估、选择、变异。

这里的「agent」并不是训练出的独立神经模块，而是由 backbone、随机种子、样例子集和生成上下文定义的 black-box LLM proposal/critique/mutation worker。增加 agent 数量本质上是在扩展符号协议搜索空间。这个过程类似于一个小型机器语言体系演化：communicative success 是正确性，production cost 是 token 长度，能反复被采用的符号与格式会被保留，不能稳定支持答案的压缩方式会被淘汰。

第三阶段：test-time routing。 给定新任务时，router 会从 LSF pool 中选择最适合当前任务和模型的 LSF 协议，然后执行推理。不同任务类型（数学/科学问答/多跳检索）会路由到不同类型的 LSF。

实验结果：3 到 6 倍 token 节省

实验在多类推理 benchmark 和多种开源 backbone 上进行。结果显示，CLSR 通常可以把面向延迟的 completion tokens 降低约 3 到 6 倍，同时基本维持 Raw CoT 的准确率水平，并在若干设置中获得更好的 accuracy–token Pareto frontier——即准确率和 token 消耗的帕累托最优边界。

这个结果的关键在于它揭示了一个被忽视的事实：推理效率的关键不只是「让模型少说话」，还要让模型使用更高信息密度、更可复用、更可路由的中间语言。题目越难，需要的推理信息越多；目标准确率越高，允许的误差越小。高效推理系统必须能够根据问题难度自适应分配 token。

对 AI 编程工具的启示

回到开头的问题：为什么两个 AI 编程工具协作，token 账单会是单独跑的 4 倍？因为现在的多 Agent 协作本质上是让两个模型用自然语言互相「写长信」。每次 agent 间传递上下文，都是一段 prose 到 prose 的传输，中间有大量的人类可读性冗余对机器来说是纯开销。

CLSR 指向的方向是：与其让人类给 AI 设计 prompt，不如让 AI 自己设计 AI 之间通信的协议。这对 AI 编程工具的工程化有直接影响——未来的多 Agent 系统，可能不再靠人类设计的 JSON schema 或者 Markdown 格式做 agent 间通信，而是让模型自己协商出一套更高密度的符号协议。

GitHub 上已经有人基于这个思路做实验了，仓库叫 LSF_MDia，论文代码也在 When LLMs Develop Languages 的官方 repo 里。值得去跑一下 demo，感受一下「让模型自己发明通信语言」这件事到底是怎么工作的。

下一步

如果你想验证这个方向，最直接的方式是：在你现有的多 Agent 协作流程里，尝试让每个 agent 用更结构化的中间格式（不是自然语言 prose，而是类似 [bind]、[op]、[chk] 这样的标签化符号）做任务交接。手动做一次，感受 token 节省的幅度。然后再想：这件事有没有可能让模型自己学会做？