在构建 AI Agent 系统时，一个常被忽视的成本来自标识符本身。当 Agent 需要在上下文中处理大量实体引用 —— 用户 ID、任务 ID、会话 ID、工具调用 ID—— 传统的 UUID v4 每个消耗约 23 个 Token，在复杂的 Agent 工作流中，这些看似微不足道的开销会迅速累积，挤占本可用于推理和生成的上下文窗口空间。
id-agent 是一个专门针对这一问题设计的开源方案，它通过词表工程将标识符的 Token 成本降至约 14 个（默认配置），同时保持与 UUID 相当的碰撞安全性。这不是简单的缩写方案，而是基于现代 LLM tokenizer 特性的系统性优化。
UUID 的 Token 效率问题
现代 LLM 普遍采用 BPE（Byte Pair Encoding）tokenizer。在这种机制下，Token 的划分取决于训练语料中的频率分布。UUID 的典型格式如89b842d9-6df9-4cf4-8db0-9dc3aed3cfd7由 32 个十六进制字符和 4 个连字符组成，这些随机字符串在 tokenizer 的词汇表中缺乏对应的完整词条，因此被拆分为多个子词 Token。
实测数据显示，一个标准 UUID v4 在 o200k_base tokenizer（GPT-4o、GPT-4.1、o1、o3 等模型使用）下平均消耗约 23 个 Token。这意味着在 Agent 需要引用 10 个不同实体时，仅标识符就占用 230 个 Token—— 相当于几百个汉字的上下文空间。
更严重的是，UUID 的随机性对 LLM 本身也是一种负担。模型难以 "记住" 这些无意义的字符串，在生成长上下文时容易产生幻觉或混淆相似 ID，这在多步骤 Agent 推理中尤为危险。
id-agent 的核心机制：词表工程
id-agent 的解决方案建立在词表工程之上。它维护一个精心筛选的 4096 词词表，每个词具有以下特性：
- 单 Token 保证：每个词在 o200k_base tokenizer 下恰好编码为 1 个 BPE Token
- 长度控制：单词长度控制在 3-6 个字符，兼顾可读性与紧凑性
- 语义过滤：排除冒犯性词汇、易混淆的同音词和罕见词汇
基于这个词表，id-agent 生成的标识符形如urd-antes-sorry-pac-dire-total-expire-going（8 词默认配置）。由于每个词都是单 Token，加上连字符的少量开销，整个 ID 仅需约 14 个 Token，相比 UUID 节省约 39%。
词表大小 4096（2^12）的设计也经过精确计算：每个词贡献 12 比特熵，8 词组合即提供 96 比特熵，碰撞概率在生成 300 万亿个 ID 时才达到 50%。对于大多数应用场景，这一安全性已完全足够。
熵与 Token 成本的权衡矩阵
id-agent 支持灵活配置词数（1-16 词），允许开发者根据应用规模在 Token 效率和碰撞安全性之间做出精确权衡：
| 词数 | Token 成本 | 熵值 | 安全规模（50% 碰撞点） | 适用场景 |
|---|---|---|---|---|
| 3 词 | ~5 Token | 36 比特 | ~30 万 | 开发测试、临时 ID |
| 5 词 | ~8 Token | 60 比特 | ~13 亿 | 生产级 SaaS |
| 8 词（默认） | ~14 Token | 96 比特 | ~300 万亿 | 高容量分布式系统 |
| 10 词 | ~17 Token | 120 比特 | ~1.4×10^18 | UUID 等效安全级别 |
对于中小型应用，选择 5 词配置可将 Token 成本降至 UUID 的 35%，同时支持超过 10 亿个安全 ID。这种配置特别适合 Agent 需要频繁引用大量短期实体的场景，如多轮工具调用、临时会话状态等。
可落地的采用策略
id-agent 提供了多种采用路径，降低迁移成本：
前缀命名空间：支持为不同类型实体添加前缀，如task_slide-exact-cede-bury-linge-ease-bean-impact，既保持 Token 效率，又通过人类可读的语义前缀提升可维护性。
确定性生成：通过idAgent.from()方法，可基于输入字符串（如邮箱地址）生成确定性 ID，使用 HMAC-SHA256 保证相同输入始终产生相同输出，适用于需要稳定标识符的集成场景。
Alias 映射：对于已有 UUID 的存量系统，createAliasMap功能允许建立 UUID 到短词别名的双向映射。在将数据发送给 LLM 前替换为短别名，接收响应后再还原为原始 UUID，实现渐进式迁移而无需改动底层存储。
验证与解析：内置的parse和validate函数支持对 ID 格式进行严格校验，确保 Agent 生成的引用始终符合预期格式，减少因格式错误导致的推理失败。
局限与适用边界
尽管 id-agent 在 Token 效率上表现优异，仍需注意其适用边界：
存储成本：词 - based ID 的字符串长度通常比 UUID 更长（8 词约 40-50 字符 vs UUID 36 字符），在数据库存储和索引层面可能带来轻微开销。这一权衡在大多数场景下可以接受，但在极端存储敏感的场景需要评估。
tokenizer 依赖：词表针对 o200k_base 优化，若使用其他 tokenizer（如 Llama 系列的 BPE 变体或 Gemini 的 SentencePiece），单词 Token 数可能略有差异。项目提供了测量脚本，建议在目标模型上验证实际 Token 成本。
可读性陷阱：虽然词 - based ID 对人类更友好，但过度依赖可读性可能导致开发者误以为可以手动构造或猜测 ID。应始终通过 API 生成，避免破坏随机性保证。
结语
id-agent 代表了 AI 原生工具设计的一个趋势：从 "对人类可读" 转向 "对 LLM 高效"。在 Agent 上下文成为稀缺资源的当下，每个 Token 的节省都意味着更长的推理链、更丰富的上下文引用和更低的 API 成本。通过词表工程将标识符 Token 成本降低近 40%，同时保持足够的安全性，这一方案为构建大规模 Agent 系统提供了实用的工程基础。
对于正在构建 Agent 平台的团队，建议从 5 词配置开始试点，在内部 API 和工具调用场景中验证效果，再逐步扩展至核心实体标识。Token 效率的优化往往藏在细节之中，而 id-agent 提供了一个立即可用的切入点。
参考来源
- GitHub: vostride/id-agent — Token efficient IDs for AI agents
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。