智能體交互中捕獲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則開啟新序列，確?？捎柧毜暮缶Y部分保持準確。這一機制同樣適用于嚴格黑盒場景：即使是內部實現對訓練系統封閉的專有執行框架，也能在完全無需源代碼級集成的情況下驅動強化學習訓練。

多輪對話的合并策略

將每次請求都作為獨立訓練樣本存儲是一種樸素且低效的做法：由于每次新請求都包含完整的歷史對話，相同的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一并記錄。每次擴展訓練軌跡時，都會驗證共享前綴的路由是否與上一輪一致，若不一致則分裂軌跡，避免在錯誤的路由條件下進行訓練。