Claude、Codex：玩具级分词器30分钟搞定，实战版全部失败

Liquid AI在研究端侧（edge）LLM词表大小对性能的影响时，需要一个能在单台机器上处理数万亿个token的字节对编码（BPE，一种把高频出现的字符对合并成词表的分词方式）训练器。但现有工具无一满足需求：sentencepiece针对非BPE方式做了优化，速度较慢；Hugging Face的tokenizers库在处理大规模语料库时会出现内存不足；tiktoken则从一开始就不具备训练功能。

Liquid AI选择这项任务作为实验对象有三个原因。第一，这不是把现有系统移植到另一种语言的搬运工作，而是以实际部署为目标的任务。第二，这项工作同时需要理解分词器训练的机器学习研究员，以及能写出具备内存意识的多线程代码的Rust工程师这两种不同专业背景。Liquid AI表示，他们想验证的是“智能体能否替代我们任何一名工程师都无法独自兼顾的专业跨度”。第三，成果必须能直接加载进tiktoken和Hugging Face的tokenizers中，这是一项外部验证条件，智能体没有自行操纵结果的空间。

将目标与验证分离设计

实验设计者在智能体写下第一行代码之前，先准备好了两样东西。其一是规定目标的AGENTS.md、CLAUDE.md规格文档。这份文档只写明结果和约束条件，而非实现方法——例如内存是最大的约束，因此必须能稳定处理远大于RAM容量的语料库；运算和输入输出用Rust和多线程处理即可，诸如此类。

另一样是智能体无法插手的验证装置。智能体被授予了对实际生产训练数据集，以及能够处理这些数据的AMD EPYC 9755服务器（128核256线程，2TB内存）的沙盒访问权限。训练出的词表会被同时加载进tiktoken和Hugging Face的tokenizers，检验编码解码往返结果是否一致，以及在多种语言、数字、货币符号、制表符、换行符和源代码中是否都没有问题。

代码通过了测试，为何还是崩溃

问题出在规模上。在几兆字节的测试数据中不曾暴露的缺陷，在实际语料库中接连爆发。Liquid AI整理出的7个问题如下。

发现的问题	如何暴露	是什么发现的	修复耗时
文件编码不一致	测试时正常，但在语料库中悄悄出错	实际语料库文件	数小时
缺乏内存感知	在目标语料库约1%处出现内存不足	全量规模运行	2~3天
并行化不足	所有核心都处于忙碌状态，但吞吐量仍不达标	全量规模运行	1~2天
预分词速度下降	正则表达式回溯导致处理速度骤降	性能分析器	数小时
排名（rank）排序错误	词表能加载，但编码结果与预期不符	外部验证工具	数小时
重复合并	词表数量不足，此后所有排名整体错位	外部验证工具	数小时
数字编码错误	两个库仅在数字上结果不一致	外部验证工具	一行代码修复

引入循环之后的变化

Liquid AI在这一节点改变了方式。他们引入了一种循环结构：智能体用实际数据运行，遇到瓶颈就报告症状，自行诊断并修复后再次运行。Liquid AI表示，随着这一循环反复进行多次，两个智能体逐一解决了前表中列出的问题。最终成果——BPE分词器训练器toktoktok——目前已作为开源项目发布在Liquid AI的GitHub账号上。

业界将这种反复结构称为智能体循环（agent loop）。一轮循环分为四个步骤：用实际数据运行，如实报告哪里以何种方式出了问题，找出的是原因而非表面症状，修复后再回到起点。前表中修复耗时从「数小时」到「2~3天」不等，是因为每个缺陷所经历的循环轮数各不相同。

在这一结构中，负责评分的一方并非智能体本身。再看前表中的「是什么发现的」一栏，智能体自身的单元测试没有发现任何一个缺陷，七个问题全部是由实际语料库文件、全量规模运行、性能分析器和外部验证工具发现的。而30分钟就做出的玩具训练器同样通过了自身测试这一事实，从反面印证了同一个道理。要让循环真正发挥作用，前提是要先有一份智能体无法插手的评分标准。

想亲自尝试搭建循环结构

这项实验的结构无需特殊设备也能照做。Claude Code和Codex都已提供了无需人类值守也能运行的执行模式。步骤共有四步。

第一，把目标和评分标准放在不同的文件中。规格文档只写结果和约束条件，不写实现方法。约束条件要把最先崩溃的那一项写在最前面——本次实验中内存就是那一项。由于Claude Code不会直接读取AGENTS.md，可以按照Anthropic文档的指引，在CLAUDE.md首行加入@AGENTS.md，或建立软链接，让两个工具看到同一份规格文档。

第二，把评分标准放在智能体权限之外。在Claude Code中，只要在.claude/settings.json的permissions.deny里加入验证脚本路径，该文件的编辑本身就会被禁止。这与在规格文件里写「不要修改这个文件」相比，约束力完全不同。同一份文档也明确指出，CLAUDE.md只是可供参考的上下文，并非强制生效的设置。

第三，把主导循环的主体交给shell。如果只是让智能体「重复到成功为止」，它一旦自认为完成就会停下来。更可靠的做法是，在shell里写一个循环：先运行验证脚本，失败就把完整日志附上重新调用智能体。日志不要做摘要，原样传递。像「两个库仅在数字上不一致」这类线索，恰恰是做摘要时最先被丢掉的。

操作	Claude Code	Codex
无人值守执行一轮	claude -p "指令"	codex exec "指令"
允许修改文件	--permission-mode acceptEdits	--sandbox workspace-write
关闭审批弹窗	用--allowedTools指定工具	--ask-for-approval never
衔接上一轮上下文	--resume 会话ID	codex exec resume --last
轮次・费用上限	--max-turns、--max-budget-usd	直接在shell循环中设定

Codex的--full-auto已被弃用，由--sandbox workspace-write取代。如果不关闭审批设置，一旦弹出审批请求执行就会直接失败，因此在非交互式执行中必须一并指定该选项。

第四，事先设定好停止条件。分别为轮次数和费用设置上限，如果使用Claude Code，还可以用Stop钩子让智能体在通过验证之前根本无法停下。只要钩子脚本返回退出码2，停止就会被阻止，写在标准错误中的内容会原样传给智能体。此时需要先检查钩子输入中的stop_hook_active值，如果已经是因钩子而处于循环状态，就应当放行。少了这道设置，智能体就会被一个怎么也修不好的缺陷困住。

如果同样的日志重复出现三次，就不该再增加轮次。这是规格文档含糊不清，或评分标准没能指出真正原因的信号，此时需要由人重新撰写规格文档。

编辑视角

这项实验有趣之处在于，它问的不是“智能体是否擅长写代码”。Liquid AI要确认的是“能否在无人监督下通过生产级验证”，而分界线恰恰出现在这里。30分钟就做出的玩具训练器，因为通过了自身测试而乍看像是成功了，但真正的失败只有在扩大规模的那一刻才会显现。这项实验揭示了一种可能性：基准测试或演示中常见的诸多“成功案例”，或许仍停留在这个“玩具阶段”。

把类似规模的编程智能体任务实际投入业务中，得出的结论也往往大同小异——最初的成果看起来很像样，但一旦遇到真实数据规模或边缘情况，隐藏的假设就会崩塌。本次实验中内存不足恰恰在目标语料库仅1%处爆发，正是这一点的例证。这是用小规模测试永远抓不到的错误。

从实务角度来看，有意义的是“将目标与验证分离”这一设计原则。只规定结果和约束条件而非实现方法，再用智能体无法插手的外部库来做验证，这种方式是国内团队若想把实际业务交给智能体时可参考的最低条件。这意味着，与其由人来代替做代码审查，不如先搭建好能自动化验证本身、并允许反复执行的结构。

未来几周内，其他公司很可能也会公布类似的“基于循环”的智能体评估案例。在前沿模型编程基准分数竞争持续进行的背景下，像这次实验一样区分“玩具级”与“生产级”的评估方式，或许会成为检验基准测试可信度的新标准。