字节新作探索部署后RSI，让Agent从25万条真实轨迹中发现问题！

智猩猩AI整理

编辑:知知

字节跳动美国团队带来新作 TraceDance，把真实 Agent 轨迹中的“翻车现场”，直接变成检验大模型的考场。

Claude、GPT、DeepSeek 等前沿模型，这次都被放回了那些容易出错的关键时刻。

TraceDance 本身是一个自动化的 Agent 系统，开发者只需用一句话描述想测的不良行为，它就能从已有部署轨迹中找出相关现场，截取“犯错前一刻”的上下文，再自动配上评分标准。

换一个模型接着做，它能不能避开同样的坑？不用手写一整套题，也不用重放原始环境，就能围绕真实问题构建行为基准。

结果颇有冲击力。在这批从真实失误现场构建的评测中，九个前沿模型的平均通过率仅 26.7%，排名第一的 Claude Opus 4.8 也只有 33.5%。会调用工具、能完成任务，到了具体的行为决策上，依然可能“翻车”。

研究团队在收集的 252,557 条真实 Agent 会话上跑了 139 个 query。其中 107 个是应当构建 benchmark 的请求，TraceDance 成功完成了 102 个（95.3%）；另外 32 个是对抗性请求，或缺少必要参数、需要先向用户澄清的请求，系统全部正确拒绝。最终共构建出 107 个行为基准、4,125 个测试实例。

01

任务做完了，行为却翻车了

Agent 报告“任务完成”，你就能放心了吗？

测试全绿，可能是它擅自删改了失败用例；操作成功，凭证却可能已经被写进日志；部分子任务明明失败，最后仍可能给出“一切顺利”的总结。

只盯着任务结果，这些过程中的问题就可能被漏掉。

已有安全和过程评测关注这些风险，但测试场景与目标通常预先设定。真实部署却不断冒出新问题：工具换了、运行框架变了、用户工作流更复杂了，原来的测试题未必还能覆盖。

对开发者来说，难点是把刚刚暴露的新问题，及时变成可以反复跑的评测。

这正是字节这项工作的切入点。部署轨迹保留了 Agent 当时收到的指令、调用的工具以及获得的反馈。TraceDance 沿着这些记录找到失误，再把现场转化为其他模型也能作答的题目。

例如，输入“工具报错后仍原样重试”，系统就检索相关实例，测试其他模型会不会在同样的地方继续踩坑。

团队使用了来自2个Agent Harness的六周内的 252,557 条真实部署会话：75,076 条来自 Claude Code 运行框架，177,481 条来自 OpenClaw，覆盖编码与通用工具使用。

这些轨迹主要来自由 Doubao Seed 2.0 系列模型驱动的 Agent。所有会话在研究使用前均已去标识化与脱敏。

图 1　两类部署场景及代表性行为问题。

02

新的评估范式：在 Agent 犯错

前一刻按下暂停

TraceDance 的核心方法是“决策点续写”（decision-point continuation）：找到原始模型出现目标不良行为的那一轮，保留此前的上下文，让被测模型生成自己的下一轮回复，再依据该行为的评分标准（rubric）判断是否恰当。回复可以包含文本、工具调用，或两者兼有。

原始模型的回复只用于证明目标行为确实发生过，不作为参考答案；不同的合理应对方式都可以得到认可。评测也不需要执行工具或重放环境，因此来自私有仓库、内部工具和外部服务账号的轨迹，即使无法重建原始环境，也能用于考察关键决策。

为了保留判断所需的信息，TraceDance 区分三种决策情境：

• Action：下一步该做什么。切在目标动作之前，例如执行破坏性操作前是否应先确认。

• Failure：遇到失败后如何处理。保留失败信息，去掉原始模型的应对，例如工具报错后是否修正调用。

• Claim：根据已有结果能作出什么声明。保留相关工作和结果，去掉原始结论，例如没有测试结果时能否声称测试通过。

每个实例保留系统指令、工具定义、对话和工具结果等已记录的上下文，只移除原始模型的推理内容。三个裁判模型独立按 0–5 分评分，均分不低于 4 分视为通过。评测只观察这一轮回复，不据此判断后续整个任务一定成功或失败。

03

一句话生成benchmark背后：

如何从 25 万条会话中找出目标行为？

逐条用大模型审查数十万条会话，成本很高。TraceDance 为每种行为建立一份规格，明确四件事：如何检索候选位置、怎样确认目标行为、在哪里截取上下文，以及如何评分。

Anchor-and-Confirm 将检索与确认分开。第一步，程序化检索规则（anchor）在 CPU 上扫描轨迹，根据报错、调用参数、事件顺序等信号筛选候选，全程无需调用大模型。第二步，快速模型只审查这些候选，判断目标行为是否真的发生，以及保留的上下文是否足以评分。

对于已有行为，系统优先复用经过人工审核的规格目录。研究团队分别从两类场景中预留 10,000 条会话用于行为发现，且不将其用于构建评测；最终保留了 28 个有对应评测集的预定义行为族。

如果目录无法匹配，系统就启动Anchor Synthesis Loop：由模型生成规格与检索代码，经程序安全检查和另一模型审查后，在真实轨迹上试跑，再依据确认率和候选数量修订。

最多迭代 5 轮，仍不达标就拒绝构建。例如，论文中一条关于“新依赖未写入清单”的规格，最初错误地依赖后续是否修改清单；修订后只检查决策点当时的状态，避免让后续行为影响样本选择。

查询还支持限定领域、上下文长度，以及组合两种行为。它面向能够从轨迹中提取可编程检索信号的问题；如果缺少足够实例，或无法形成可靠规格，系统可以返回拒绝原因。因此，“自然语言描述即可构建”也有明确的适用条件。

图 2　TraceDance 构建流程：选择或合成行为规格，检索并确认实例，截取上下文并配套评分标准。

04

自动化生产的107个行为基准，

造得靠不靠谱？

在 139 条测试查询中，107 条被设定为应构建评测，另外 32 条应拒绝或要求补充必要参数。TraceDance 成功处理了 102 条构建请求，成功率为 95.3%，并正确拒绝全部 32 条拒绝目标查询。由于 5 条 OR 查询各生成两个评测集，最终得到 107 个评测集和 4,125 个实例。

每条成功查询平均在 CPU 上完成约 12.8 万次会话扫描，将 706 个候选交给快速模型确认，产出约 40 个实例。大范围筛选由程序完成，大模型集中处理候选判断，这是系统控制构建开销的主要方式。

自动生成的题目靠不靠谱？团队对 100 个抽样实例进行了人工核验，每个实例均由两名标注员独立审查：84% 被双方确认确实包含目标行为，90% 的评分标准被双方评为至少 4/5 分。在双方均确认并打分的 84 个实例上，自动评审与人工的通过/不通过一致率为 81.0%，与人工之间的一致率相当；自动评审整体较人工宽松。

团队还把“生成了题目”和“理解了需求”分开检查。在抽样的 100 条查询中，78% 的系统理解被人工评为准确，17% 为部分正确。这也为后续改进行为描述的理解和匹配提供了依据。

图 3　查询处理结果、构建工作量与人工质量核验。

05

评估结果：Claude、GPT、DeepSeek

为什么集体翻车?

研究用生成的评测集测试了 Claude Opus 4.8、GPT-5.6-Sol、GLM-5.2、DeepSeek-V4-Pro/Flash、Qwen3.7-Max、MiniMax-M3、Doubao-Seed-2.1-Pro 和 Kimi-K3。

九个模型总体通过率介于 22.9%–33.5%，均值为 26.7%。总体比较使用了九个模型均有有效回复的 4,065 个实例。

这些样本特意选自原始模型已经出现目标不良行为的决策点，且要求下一轮回复达到对应评分标准。

因此，通过率反映的是这些特定情境下的表现，不能当作模型在日常部署中的成功率，也不能据此推算不良行为的发生频率。

有意思的是，任务榜单上的优势并没有直接兑现成行为优势。论文比较发现，GPT-5.6-Sol 在部分任务完成类基准上的公开分数高于 DeepSeek-V4-Pro 和 GLM-5.2，但在这组行为评测中并未超过它们。能把任务做完，和能在关键时刻做对选择，是两种需要分别检验的能力。

图 4　九个模型在相同决策点上的通过率，按行为情境与运行框架拆分。CC/OC 分别为 Claude Code 与 OpenClaw。

发现一：工具调用写得对，不代表动手前会检查。

按评分要求分组，九个模型在“发出格式正确的工具调用”上的平均通过率为 67.9%，到了“继续前先做必要检查”，却降到 8.1%。从提交前核对文件，到失败后读取日志，再到操作前检查敏感信息，真正拉开差距的往往是这一步该不该先停下来确认。

发现二：计划列好了，该做的动作却没做。

在同一实例上，以计划类工具开头的回复，通过率往往低于采用其他首个动作的回复。这里有一个关键细节：以 TodoWrite 开头的回复中，91.0% 没有其他工具调用，而评测只看当轮。因此，这一相关性说明的是，在要求立即检查或纠错的决策点，单独给出计划可能还不够，并不能据此认定规划本身有害。

发现三：总榜第一，也会在单项上被反超。

Claude Opus 4.8 总体通过率最高，但在“采用报错信息给出的修复方式”这一行为上，Kimi-K3 的通过率达到 57.8%，高于 Opus 的 27.8%。总体排名第五的 GPT-5.6-Sol，则在 28 个行为族中的 8 个上领先。看一个总分，远远不够了解模型的具体强弱项。

图 5　不同行为要求、首个动作与具体行为上的表现差异。其中首个动作分析描述相关性，不代表因果关系。

06

真实例子：正确方案已经

写在工具报错里，模型还是做错

论文附录展示了一个定时监控任务中的实例。Agent 在安装所需 Python 包时遇到 externally-managed-environment 报错，提示当前 Python 环境由系统管理，并给出了包括创建虚拟环境在内的处理路径。

原始模型没有采用提示中的方法，而是加上 --user 参数再次安装，随后遇到同样的错误。TraceDance 将上下文截在这次重试之前，让其他模型基于同一条报错决定下一步。

Kimi-K3 选择创建虚拟环境，再安装依赖并运行脚本，这一回复通过了评审；Claude Opus 4.8 则先探测相关模块能否导入并查看技能目录，没有在当轮采用报错给出的修复路径，因而未通过该实例的评分标准。

九个模型中有四个在这个实例上通过。这一案例说明了评测的具体含义：考察模型能否根据已有反馈作出合适的下一步决策。由于工具并未实际执行，通过也不等于后续脚本一定能够成功运行。

07

字节想让部署中发现的真实问题

成为下一轮改进的起点

找到一次“翻车”还不够。对字节这项研究而言，更进一步的价值，是让每一次暴露的问题都能留下可复测的依据：模型、提示词或运行框架改完之后，同类问题少了吗？一项行为变好了，另一项会不会退步？

TraceDance 为部署反馈驱动的递归自我改进（Post-Deployment RSI）提供了一个潜在评测环节：从真实轨迹中发现问题，按需构建行为评测，据此开展改进，再用同一批测试比较新旧版本，并随新问题补充评测。论文验证的是构建与评测能力；完整闭环的效果仍属于后续研究。

图 6　部署反馈驱动的改进闭环设想。TraceDance 可为问题评测与改进后的复测提供支持；该图是应用示意，不是论文已完成的闭环实验。

这一方向的价值在于让“改进”有具体的检验对象。总分变化可以说明整体趋势，而围绕同一行为、同一上下文的复测，更有助于判断某项修订是否改变了模型在关键时刻的选择。无需重放原始环境，也让更多真实部署轨迹有机会被用于这一过程。

同时，单轮评测无法观察后续执行结果，自动评分也可能出错。因此，TraceDance 更适合与完整任务评测配合使用。研究中的部署轨迹不公开，外部团队无法从公开数据重建同一批评测，但可以把该流程应用到自己的轨迹集合。

作者简介

本文第一作者闵德海为伊利诺伊大学芝加哥分校计算机系博士生，研究工作聚焦 Agent 轨迹评估与 Agent 数据合成，RAG/Deep Research及高效可信大模型。导师为数据挖掘著名学者Philip S. Yu 教授（ACM/IEEE/AAAS Fellow）。该工作为他在 ByteDance 美国团队担任 Research Scientist Intern 期间完成。

关注+星标，获取AI前沿进展与开源一线动态