id-agent：一个小 ID 库，戳中了 AI Agent 的新成本

一个 UUID v4，在数据库里很安静。放进大模型上下文里，就可能变成一串又贵、又难复述的十六进制长码。

id-agent 这个 GitHub/npm 项目的切口很小：把部分 UUID 场景换成英文词 ID。一个 UUID v4 示例大约 23 tokens；id-agent 默认 8 个词，大约 14 tokens。单次省不了多少，但 agent 工作流里到处都有 task_id、file_id、run_id，账就会变厚。

我更在意的是后半句：模型不只是在“看”这些 ID，它还要引用、复制、比较、传回系统。ID 从数据库字段，变成了上下文里的沟通对象。

它做了什么，省在哪里

id-agent 的设计不复杂：准备一个 4096 个英文词的词表。每个词在 o200k_base tokenizer 上正好是 1 个 BPE token。

4096 等于 2 的 12 次方。所以每个词贡献 12 bits 熵。

它提供的能力也很工程化：随机 ID、基于 HMAC-SHA256 的确定性 ID、parse/validate，以及 UUID 到短别名的 replace/restore。

最相关的用户不是普通应用开发者，而是两类人：做 AI agent 的团队，以及维护长上下文任务链、日志链路、对象引用系统的工程团队。

他们可以做一件很具体的调整：系统内部继续用 UUID；发给模型前，把 UUID 映射成短词别名；模型输出后，再 restore 回原始 UUID。

收益很明确：少花 token，降低长十六进制串被模型记错、抄错、漏掉一位的概率。

但边界也要讲清楚。README 里的碰撞概率推导，只能理解为项目方宣称和数学估算，不是第三方安全审计。默认 8 词是 96 bits，不等于 UUID v4。要接近 UUID v4 的碰撞水平，得看 10 词的 120 bits。

还有一个硬前提：token 优势绑定 o200k_base。换模型、换 tokenizer，结果可能变。这个库目前能看到的是 GitHub/npm 项目，不是行业标准，也不能假装已经被主流框架采纳。

真问题不是 ID，是模型成了 ID 的新读者

数据库时代，ID 的主要读者是机器。

UUID 的优点很朴素：全局唯一、无需协调、实现成熟。它不好读，不省 token，也没关系。机器能处理就行。

Agent 时代，情况变了。

ID 要进 prompt，要进工具调用，要进日志摘要，要被模型复述回来。大模型成了 ID 的新读者，也成了新的出错点。

这就是 id-agent 有意思的地方。它不是把 UUID 批倒批臭，而是提醒开发者：过去不计成本的字符串，现在进了上下文窗口，就开始收费。

“天下熙熙，皆为利来。”放到 AI 工程里，利就是 token，害就是误读。以前这点损耗藏在系统外面，现在被模型上下文照出来了。

这和早期互联网有点像。电话簿、报纸版面、门牌号都能搬上网页，但网页最后长出的不是纸面编号，而是 URL、锚文本和搜索排序。不完全一样，但逻辑相通：媒介换了，旧标识系统的成本会重新暴露。

AI 应用也是这样。以前优化数据库读写，现在还要优化模型阅读。以前担心 ID 碰撞，现在还要担心模型把 ID 抄错。

这不是小题大做。Agent 一旦跑长链路，错一个对象引用，就可能把后面的工具调用带偏。你以为是模型能力问题，实际可能是引用系统太难读。

该怎么用，别把它神化

最容易误传的一句话是：UUID 过时了。

我不买账。

UUID 没有过时。过时的是把 UUID 无脑暴露给模型，还指望模型每次都像数据库一样稳定处理。

数据库主键、跨系统幂等、审计追踪、安全边界，仍然该用成熟工程规则。id-agent 更像一层面向 LLM 的引用编码。它适合上下文、别名映射、短生命周期任务对象，不适合一把梭替代所有 UUID。

对 agent 团队来说，更稳的路线是分层：

接下来真正该观察的，不是这个库会不会“一统 ID”。这说法太大，也没证据。

更现实的观察点有两个。

一是更多 agent 框架会不会把 alias map、ID 压缩、引用校验做成默认能力。二是不同 tokenizer 下，这种单 token 词表还能不能稳定省 token。

如果这两点成立，id-agent 代表的就不是一个库，而是一类基础设施补丁：给模型看的东西，要重新设计一遍。

这也是我觉得它值得写的原因。模型越强，产品越依赖这些不起眼的工程缝线。缝得好，agent 像系统；缝不好，agent 就像一场昂贵的传话游戏。