智能体交互中捕获Token ID以优化强化学习

强化学习（RL）是提升大语言模型在代码编写、网页浏览或研究工作流等多步骤持续任务中表现的核心技术之一。在这类场景中，模型并非单独运行，而是被封装在一个称为"执行框架"（harness）的软件中，使其能够调用工具、观察结果并决定下一步行动。为了用强化学习优化此类模型，需要让模型在执行框架中反复尝试任务，对每次尝试进行评分，并根据评分调整模型参数，使其向有效选择靠拢。

难点在于记录过程。要将一次有评分的尝试转化为参数更新，训练器需要模型输出的精确记录——不能是摘要，也不能是看似完整实则遗漏了关键信息的对话记录。

模型内部将文本视为一串带编号的单元，即Token；一句英文可能包含10到20个Token，每个Token由称为分词器（tokenizer）的软件分配一个整数ID。两段在记录中看起来完全相同的字符串，经过细微的格式变化后可能映射到不同的Token ID。这种差距无论多小，都足以让训练器基于一个与模型实际经历略有出入的历史进行优化。

今天，我们正式发布Turnstile——一款用Rust语言编写的轻量级代理程序，部署在智能体执行框架与模型运行后端之间。Turnstile在每次请求发生时，在唯一可以确保准确性的时间点——即生成的瞬间——实时记录完整的Token级历史。随后，它导出一个通用、框架无关的轨迹数据，可直接接入任何你已在使用的强化学习训练框架。

Turnstile已被用于驱动真实的强化学习训练。在我们报告的验证实验中，两种不同的智能体——一个纯文本代码智能体和一个多模态电脑操作智能体——在各自的强化学习训练过程中均实现了稳定提升。两种情况下，智能体执行框架均未作任何改动，Turnstile记录的数据直接流入训练框架，并在端到端层面产生了预期的学习信号。

核心概念解析

在深入展开之前，有三个核心概念值得先行厘清。

分词器（tokenizer）是一个确定性函数，负责将文本转换为整数Token ID列表，并将Token ID还原为文本。每个模型与特定的分词器绑定，二者不可互换。分词器极为严格：多余的空格、JSON格式的工具调用写法不同，或者对话模板（即服务系统用于将角色和消息封装成模型可读文本输入的格式字符串）的细微差异，都可能在渲染文本对人类看来完全相同的情况下改变Token ID。我们将重新运行分词器处理已见过的文本导致的偏差称为"重分词漂移"，将对话模板变化导致的偏差称为"对话模板漂移"。

rollout（执行轨迹）是一次任务尝试的完整记录：包含提示词、所有工具调用、工具反馈、模型响应以及最终结果。产生该执行轨迹的模型版本称为行为策略（behavior policy）。策略梯度强化学习的数学原理要求训练器必须基于行为策略实际所处的上下文对模型行为进行优化。一旦重新渲染提示词并得到略有不同的Token序列，训练器便是在针对一个行为策略从未真正面对过的上下文来训练模型，训练信号随之降级，且这种降级有时难以察觉，因为模型看起来仍在正常学习。

这也正是智能体执行框架会加剧问题的原因。执行框架并非静态提示词；在单次rollout中，它可能为节省上下文而压缩历史消息、重试格式错误的工具调用、分发给子智能体、合并结果或对历史进行总结。这些都是正常且有用的智能体行为，但每次改写都是一次让下一请求的Token序列偏离模型上一轮实际生成内容的机会。执行框架生成的记录是对话的忠实记录，但通常并不是Token的忠实记录，而训练器真正需要的恰恰是Token。

Turnstile的工作原理

Turnstile的核心设计理念是：不在rollout结束后尝试从文本中重建Token级状态，而是在生成的瞬间直接捕获，且不对执行框架做任何改动。

该代理程序遵循目前所有主流智能体执行框架都支持的HTTP API标准：OpenAI Chat Completions API——这一"发送消息列表、获取响应"的接口已成为事实上的行业标准。执行框架在Turnstile中创建一个rollout组，将其Chat Completions客户端指向Turnstile的地址而非真实后端，然后照常运行。在此过程中，每个请求通过Turnstile流向推理后端（目前支持SGLang，vLLM支持即将上线）。Turnstile记录模型采样的精确Token ID、每个Token的对数概率（模型对各Token的置信度，以对数形式表示，训练器计算更新时需要此数据），以及损失掩码——用于标记哪些Token是模型生成的（应纳入训练），哪些来自用户、工具或系统提示（不应纳入训练）。

rollout结束后，执行框架向Turnstile请求记录的轨迹数据。每条轨迹是一个TrainingSequence对象，包含Token ID、对数概率、完整序列的损失掩码，以及序列各段落中模型权重的版本记录（训练器需要这些权重版本边界，以判断模型参数是否因异步更新而在rollout中途发生变化）。将其转换为特定训练器所需的批量格式只是简单的适配工作：附上奖励值、展开掩码，然后交付即可。

解决执行框架的根本问题

OpenHands、Codex、Terminus等智能体执行框架已经相当实用，但它们设计之初并非为了充当训练运行时。若不借助Turnstile，使用这类框架驱动强化学习训练，就需要它们记录Token ID、对数概率、掩码和路由跟踪，而这项工作在实际中往往落到一个在训练系统内部专门构建的"类执行框架"组件上。无论哪种方式，执行框架最终都变成了Token级强化学习数据流水线，这是错误的抽象层次。执行框架知道自己打算向模型发送什么信息，但通常并不知道模型实际使用的精确Token序列、缓存状态、路由追踪或处理后的多模态输入，这些都存在于后端。

有了Turnstile，生产环境中的执行框架无需记录训练数据，只需将Chat Completions客户端指向Turnstile而非推理后端，其余照常运行。Turnstile记录面向模型的rollout状态，无需理解执行框架的内部控制流或上下文变化的语义原因。如果下一次请求是前一次请求在Token级别的真实延伸，Turnstile将其合并至同一轨迹；如果执行框架压缩了内存、重写了历史、合并了子智能体结果，或者以其他无法证明等价的方式改变了前缀，Turnstile则开启新序列，确保可训练的后缀部分保持准确。这一机制同样适用于严格黑盒场景：即使是内部实现对训练系统封闭的专有执行框架，也能在完全无需源代码级集成的情况下驱动强化学习训练。

多轮对话的合并策略

将每次请求都作为独立训练样本存储是一种朴素且低效的做法：由于每次新请求都包含完整的历史对话，相同的Token字符串会被反复复制，同时也会丢失轮次之间的关联。

Turnstile采用不同的方式：只要路径对模型实际所见保持真实，就将多轮rollout存储为一条持续增长的Token路径。当后续对模型的请求仅是前一次请求加上末尾若干新Token（即新用户消息、工具结果或大语言模型响应），Turnstile通过在Token层面——而非比较渲染后的字符串——验证之前捕获的Token ID是否在新请求开头保持不变来识别重叠部分。若验证通过，两轮对话合并为一条连续的可训练序列，损失掩码正确标记出哪些区间是模型的输出。

若下一次请求无法安全地从前一次延伸——因为执行框架重写了早期消息，或者Token因某种原因发生漂移——Turnstile不会假装情况没有变化，而是开启新的训练序列。我们将这一过程称为"轨迹分裂"。这比乐观方案消耗更多训练Token，但能确保用于强化学习训练的每个Token字符串都是行为策略真正经历过的内容。重点不在于追求存储的紧凑性，而在于永远不向训练器提供关于真实发生情况的错误信息。

混合专家模型的路由捕获

部分现代模型采用混合专家（MoE）架构，即在处理每个Token时，仅激活模型参数中称为"专家"的一小部分，由每层的一个小型路由网络决定激活哪些专家。路由决策取决于各层的激活情况，而前序Token处理方式的细微差异就可能改变专家的选择结果。这对强化学习至关重要：即使两次请求的Token ID完全相同，不同运行中Token也可能被路由到不同的专家。

北京大学研究人员及其合作者去年秋季对这一差异进行了系统性研究，并提出记录MoE模型的路由决策以供训练器重放的方案。Turnstile采纳了相同原则。启用MoE捕获后，Turnstile向推理后端请求路由追踪并将其与Token一同记录。每次扩展Token路径时，都会验证共享前缀部分的路由是否与上一轮记录的一致。若不一致——例如由于键值缓存未命中导致后端重新计算前缀并选择了不同专家——Turnstile会分裂轨迹，而非在错误路由下继续训练。

多模态视觉输入的处理

当模型还能接收图像输入（即视觉语言模型）时，rollout需要追踪另一项状态。模型看到的并非上传图像的原始字节，而是图像处理器的输出——图像处理器是一套固定流水线，负责调整图像大小、裁剪、转换为像素值张量，并在文本中插入占位Token标记图像位置。相同的图像字节，经不同版本的处理器、不同缩放策略或不同的分块几何设置后可能生成不同的张量，且占位Token数量也会随输入尺寸变化。一旦强化学习训练器需要从头重新处理图像，训练所基于的视觉前缀可能与行为策略当时见到的并不一致。

Turnstile将图像处理视为rollout的组成部分。当请求包含图像时，Turnstile对图像进行解码，对原始字节进行哈希并存储以供审计，运行模型配置的处理器，并按占位Token出现顺序将处理后的像素特征与Token ID一并记录在同一条轨迹中。导出的序列同时携带原始视觉数据和处理后的视觉数据，训练器可按需选用。

现状与展望

Turnstile目前仍处于早期阶段。当前实现包含Rust核心、SGLang后端、用于进程内训练脚本的Python绑定、前缀感知多轮捕获、可选的MoE路由捕获以及多模态支持。近期工作将进一步扩展：增加vLLM后端、更多训练框架适配器以及更广泛的多模态模型覆盖。长期设计方向与最初保持一致：智能体执行框架不应变成强化学习数据流水线，训练器也不应从渲染文本中猜测真实发生了什么。模型采样了这些Token，我们将其记录下来。

Turnstile现已在Github上开源。

Q&A

Q1：Turnstile是什么？它解决了强化学习中的什么问题？

A：Turnstile是一款用Rust语言编写的轻量级代理程序，部署在智能体执行框架与模型运行后端之间。它解决的核心问题是：在强化学习训练中，执行框架产生的对话记录无法精确还原模型实际处理的Token序列，导致训练器基于错误的历史进行优化。Turnstile在Token生成的瞬间直接捕获精确的Token ID、对数概率和损失掩码，确保训练数据真实反映模型的实际经历。

Q2：Turnstile需要对现有的智能体执行框架做哪些改动才能使用？

A：基本不需要改动。Turnstile遵循OpenAI Chat Completions API标准，智能体执行框架只需将客户端指向Turnstile的地址而非原始推理后端，其余逻辑照常运行。即使是内部实现封闭的专有执行框架，也可在完全无需源代码级集成的情况下使用Turnstile驱动强化学习训练。

Q3：Turnstile如何处理混合专家（MoE）模型的路由问题？

A：MoE模型在处理每个Token时只激活部分"专家"参数，路由决策可能因细微差异而改变，即使Token ID相同，不同运行也可能激活不同专家。Turnstile启用MoE捕获后，会向推理后端请求路由追踪并将其与Token一并记录。每次扩展训练轨迹时，都会验证共享前缀的路由是否与上一轮一致，若不一致则分裂轨迹，避免在错误的路由条件下进行训练。