onPanda：把修订追踪搬进大模型标注，时间砍半还能保住策略分布
想象你是一名 RLHF 标注员。你的工作是这样的——模型给出一段回答，你读一遍，发现第三句开始跑偏了：它把"三角形"说成了"三角形们"，后面整段推理都跟着歪了。
onPanda：把"修订追踪"搬进大模型标注，时间砍半还能保住策略分布
一个标注员的早晨
想象你是一名 RLHF 标注员。你的工作是这样的——模型给出一段回答，你读一遍，发现第三句开始跑偏了：它把"三角形"说成了"三角形们"，后面整段推理都跟着歪了。
你该怎么办？
最朴素的做法是手动改写：把第三句之后的所有内容删掉，自己重新写一遍。问题是，你写出来的文字不是模型会说的话，它带着你的语感、你的节奏、你的偏好。拿这种数据去做 SFT，模型学到的不是"怎么生成好的回答"，而是"怎么模仿标注员写作文"。这就是所谓的 off-policy 问题——训练数据偏离了模型自己的采样分布。
另一种做法是偏好标注：给模型两个回答打分，哪个好哪个差。这省事，但监督信号太粗——你只告诉它"这个比那个好"，却没告诉它到底从哪个 token 开始走偏了。更麻烦的是，如果模型根本采样不出好的回答，你拿什么去打分？
onPanda 给出的答案简单到近乎朴素：像 Word 的修订追踪一样，找到第一个不对的 token，改掉它，让模型从那个位置重新生成。
Token 级校正：locate-correct-continue 循环
onPanda 的核心交互可以用三步概括：
1. Locate：标注员读模型的回答，找到第一个不合适的 token。界面上每个 token 下方都有一条颜色带——绿色越深表示生成概率越高，红色越深表示越低。这条颜色带本身就是诊断信号：低概率的 token 往往就是模型"没把握"的地方。 2. Correct：鼠标悬停到那个 token 上，系统弹出模型在这个位置的 top-20 候选 token 及其概率。如果候选里有合适的，点一下就替换了；如果没有，双击直接打字输入任意文本。 3. Continue：系统把该位置之后的所有内容截断，用修正后的前缀作为 assistant message 的起点，让模型从那里继续生成。
然后循环——读、找、改、继续，直到整段回答满意为止。
这个流程有一个被低估的好处：你不需要在改完之后重新读一遍整段回答。传统手动改写最折磨人的地方在于，你改了第三句，第七句可能就接不上了，于是你得从头再读一遍。onPanda 的"截断+续生成"机制把这个问题消掉了——第七句是模型自己根据修正后的前缀重新生成的，它天然和前文连贯。
52% 的时间削减，以及它意味着什么
论文报告了一个关键数字：中位标注时间相比手动后编辑减少 52%。
这个数字本身已经很可观，但更有意思的是它背后的结构。时间削减来自三个地方：
- 大部分修改是鼠标点击，不是键盘输入。从 top-20 候选里挑一个，比手敲一段话快一个数量级。
- 线性工作流。你从头读到尾，遇到问题就改，改完继续读——不需要回头复查。这把传统标注里反复通读的开销省掉了。
- 模型自己生成大部分 token。标注员只动几个关键位置，剩下的让模型来写。
用这种数据做 SFT，模型学到的不是"模仿人类写作文"，而是"在自己的语言空间里，哪些岔路口该选哪条路"。用这种数据做偏好学习，正负样本天然配对——它们共享修正点之前的前缀，在修正点处分道扬镳，形成位置精确、方向明确的训练信号。
标注树：所有中间版本都是资产
onPanda 把一次标注会话组织成一棵标注树。树的每个节点是一个完整的对话状态（包含消息、工具、标注）。每次校正会 fork 出一个新节点，父节点是校正前的对话。
这意味着什么？所有中间版本都被自动保存了。标注员不需要做任何版本管理，系统天然记录了"从初始 rollout 到最终回答"的每一步修正路径。
这棵树有几个用途：
- SFT 数据：标记为
is_good=Y的节点直接导出为 SFT 样本。 - 偏好数据：同一 prompt 下的正负节点配对。负样本通常是正样本的祖先——它们在修正点前共享前缀，在修正点处分叉。这种配对方式有一个绝佳性质：正负 token 在同一位置一一对应，优化时信号天然平衡。
- token 级校正数据：可以表示为三元组（负样本、被拒绝的 token 及其位置、被选中的 token）。这种数据的位置和方向都精确，可以作为更高效 post-training 方法的基础。
Agent 轨迹：把工具调用也纳入校正范围
onPanda 不只能标注纯文本回答。现代推理模型和 agent 的输出是结构化消息——包含 reasoning、content、tool calls。这些不能直接做 token 级校正。
onPanda 的解决方案是 response template 机制：在结构化消息和模型的原生 token 流之间做双向转换。渲染方向把结构化消息展开成带特殊 token（如 、|_begin|）的完整序列用于显示和校正；解析方向把生成流实时还原为结构化消息用于存储和工具执行。
这意味着特殊 token 也可以被直接看到和校正。标注员可以修改推理链的内容、工具调用的参数——覆盖范围统一。
外部环境通过 MCP 连接。onPanda 提供了一个 harness_to_mcp 适配器，可以把 Claude Code、Codex、OpenClaw 等现有 harness 包装成 MCP server。工具调用可以配置为"等待标注员批准后执行"——如果调用参数有问题，标注员先改参数再执行；如果整个调用不该做，可以拒绝并附上文字指导，被拒绝的轨迹自动留作负样本。
这一段是论文里最让我兴奋的地方。agent 轨迹标注的难点在于：轨迹是多步环境交互产生的，任何修正都必须真正执行工具、拿到真实反馈，才能继续生成。onPanda 把这个闭环打通了——改完工具调用参数，系统真的去执行，拿到真实结果，模型从那里继续生成。这不是事后打分，是过程中的干预。
Panda-CVL 数据集与 token 级校正 benchmark
论文发布了 Panda-CVL 数据集，用 onPanda 标注而成，同时附带一个 token 级校正的 benchmark。这个 benchmark 的意义在于：它把"找到第一个不合适的 token 并给出正确替换"这件事变成了一个可量化评估的任务。未来做自动校正模型的研究，有了统一的评测标准。
诚实评价：边界在哪里
论文坦承了几点局限：
- 用户研究规模较小（"a small controlled study"），52% 的数字需要在更大规模、更多任务类型上验证。
- token 级校正的 post-training 方法还在 future work 阶段。论文提供了数据格式和配对方式，但用这种数据训练出来的模型到底能提升多少，还没有最终答案。
- 对 API 的要求不低：需要
continue_final_message（从前缀续生成）和logprobs（top-k 候选及概率）两个能力。vLLM 支持，但不是所有推理框架都开箱即用。 - 自由编辑的 token 初始没有概率信息，需要额外的
prompt_logprobs请求来补全——这又是一个 API 要求。
一个更大的图景：标注-训练飞轮
论文在 future work 里提到了一个概念：annotation-training flywheel（标注-训练飞轮）。想法是：用 token 级校正数据做 post-training → 模型变好 → 需要标注的数据变少/变容易 → 标注效率进一步提升 → 模型再变好……
这个飞轮的关键在于：token 级校正数据提供的监督信号比偏好数据精细得多，比手动改写更 on-policy。如果 post-training 方法能充分利用这种信号——不只是做 SFT 和 DPO，而是设计专门利用位置和方向信息的优化目标——飞轮可能转得比预期快。
这是 onPanda 最有想象力的地方。它不只是一个标注工具，更是一种数据格式的定义。当你把"人在哪个 token 上做了什么修正"这件事精确记录下来，你就打开了一个新的监督信号空间。未来能在这个空间里做出什么，取决于 post-training 方法的进步——但至少，数据这边已经准备好了。
结论
onPanda 做的事情看起来很简单：把 Word 的修订追踪搬进 LLM 标注。但这个"搬"的过程解决了一组很微妙的问题——on-policy 与人工干预的矛盾、粗粒度偏好与细粒度监督的矛盾、标注效率与数据质量的矛盾。
52% 的时间削减是看得见的收益；on-policy 分布保持是看不见但更重要的收益；token 级校正数据格式是面向未来的收益。当 post-training 方法追上来的时候，这种数据的价值会被重新发现。
对于正在做 RLHF/agent 对齐的团队，onPanda 值得认真看一眼。它开源了 Python 库，接 MCP，支持 Claude Code/Codex/OpenClaw——门槛不高，试一下就知道"locate-correct-continue"这个循环到底好不好用。
论文：onPanda: Efficient Annotation of On-Policy Alignment Data for LLMs and Agents via Token-Level Correction arXiv：https://arxiv.org/abs/2609.24983 代码：https://github.com/on-panda/on-panda-python 数据集：https://on-panda.github.io/research 作者机构：StepFun + 厦门大学