行为漂移要靠轨迹评估抓工具选择、顺序和停止条件，但轨迹“看起来合规”和“任务最终正确”之间还差什么？

AGENT TRAJECTORY EVALUATION · 合规性与正确性的鸿沟

目录

一、导语：一个被反复观察到的落差

在智能体（agent）系统的评测实践中，有一类现象几乎每个团队都会遇到：把一次任务执行的完整轨迹（trajectory）拉出来逐条检查，工具调用名称合法、参数结构符合 schema、调用顺序没有违反显式规则、终止时也确实给出了最终答案——从“合规”角度看挑不出毛病，但把最终产物与任务目标对照，结论却是错的。这个落差不是偶发的噪声，而是轨迹评估方法本身的结构性特征所决定的。笔者认为，把它简单归因为“评估器不够强”是一种偷懒的解释；更准确的说法是，合规性评估与正确性评估度量的是两个不同空间里的性质，前者作用于过程的形式约束，后者作用于结果与目标的语义一致性，二者之间不存在蕴含关系。

这个判断直接决定了轨迹评估的定位。如果把它当作“正确性的代理指标”，就会在阈值设定上不断加码，最终把系统调成“什么都不敢做”的保守形态；如果把它当作“漂移的早期预警信号”，则可以在成本可控的前提下捕获大量真实故障。本文的主线就是围绕这一区分展开：先把行为漂移拆成工具选择、调用顺序、停止条件三类可观测信号，说明每一类信号的评估原理与指标构造；再系统讨论合规轨迹为何仍会失败，给出五种可检验的成因机制；最后落到一个分层评估框架和一套可执行的实施步骤上。全文强调机制与因果，避免把“评估分数高”直接等同于“系统可靠”。

核心命题：轨迹合规是正确性的必要条件而非充分条件。评估体系的设计目标，不是让二者画等号，而是让二者的偏差可测量、可归因、可收敛。

二、背景与问题定义：行为漂移、轨迹与合规性

2.1 行为漂移的可操作定义

“行为漂移”（behavioral drift）在不同文献中含义并不统一。本文采用一个偏工程的定义：在同一任务分布下，智能体的策略输出相对于基线策略发生了系统性偏移，且该偏移导致任务成功率或过程约束满足率下降。这个定义包含三个要件：同一任务分布（排除任务难度变化带来的伪漂移）、系统性偏移（排除单次随机采样波动）、后果可测（排除无实际影响的风格变化）。三者缺一，讨论就会滑向模糊。

之所以强调“系统性”，是因为大模型驱动的智能体天然带有采样随机性。温度参数、上下文长度、工具返回内容的细微差异都会让两次执行产生不同轨迹。若不做统计意义上的区分，任何两次轨迹的差异都能被说成“漂移”，评估就失去了判别力。工程上常用的做法是对同一任务做多次采样，用轨迹级指标的分布而非单点值来判断是否漂移，这一点在后文的阈值标定部分会展开。

2.2 轨迹的形式化描述

一条轨迹可以形式化为一串步骤的序列。设第 t 步的状态为 s_t，动作为 a_t，观测为 o_t，则轨迹 τ = (s₀, a₁, o₁, a₂, o₂, …, a_n, o_n)。在工具调用型智能体中，动作 a_t 通常是一个结构化调用，包含工具名与参数；观测 o_t 是工具返回。轨迹评估就是在 τ 上定义一组函数，输出可比较的分数或标签。

这里有一个容易被忽略的细节：轨迹的“步”如何切分，会直接影响评估结果。以“一次工具调用”为一步，与以“一次模型推理加一次工具调用”为一步，得到的顺序约束和长度分布完全不同。本文建议在评估规范中显式固定切分粒度，并在跨系统比较时做对齐，否则不同团队报出的“平均步数”根本不具备可比性。这是笔者在审阅多份评测报告后形成的一个实践判断，虽无统一标准，但至少应在报告内自洽。

2.3 合规性的三个层次

“合规”这个词在工程语境下至少有三个层次，混用会导致评估目标失焦。第一层是语法合规：工具名存在、参数类型正确、JSON 可解析。第二层是程序合规：调用顺序满足前置依赖，例如必须先查询再写入、必须先鉴权再访问。第三层是语义合规：每一步的意图与任务目标保持一致，没有出现与目标无关的探索性调用。绝大多数现有评估工具覆盖了前两层，第三层则高度依赖任务特定的判定逻辑，难以通用化。

本文评述：这个三层划分的价值在于解释了“合规但错误”为何常见——语法与程序合规是局部可判定的，语义合规则需要全局视角。一个智能体完全可以在每一步都语法正确、程序正确，却在整体上偏离任务目标。评估体系若只覆盖前两层，其分数与任务成功率的相关性必然存在天花板。后文第四节的成因分析，本质上都是在这个天花板上做文章。

三、三类轨迹信号的评估原理与技术路线

把行为漂移拆成三类信号，是为了让评估指标与故障类型一一对应。工具选择回答“用了什么”，调用顺序回答“怎么串起来”，停止条件回答“何时收手”。三类信号在轨迹上的可观测性不同，评估方法也不同。本节逐一展开，并在每类信号后给出可操作的指标构造方式。

3.1 工具选择：从命中率到选择合理性

最直观的工具选择指标是工具命中率：在需要调用某工具的步骤上，实际调用的工具是否落在期望集合内。这个指标实现简单，但存在两个问题。其一是期望集合的构造依赖人工标注或规则，覆盖不全时会低估性能；其二是它只惩罚“选错”，不惩罚“多选”和“漏选”。因此实践中常配合精确率与召回率一起看：把每一步的工具选择视为一次分类，精确率衡量“调用的工具里有多少是必要的”，召回率衡量“必要的工具里有多少被调用了”。

更进一步的指标是选择合理性，它不要求工具完全匹配某个标准答案，而是判断所选工具在当前状态下是否“足以推进任务”。这类判定通常借助一个独立的评判模型完成，输入是当前状态、候选工具集与所选工具，输出是合理性标签。需要强调的是，评判模型的可靠性本身需要校准，否则会把评判器的偏差误认为智能体的漂移。笔者建议在引入评判模型前，先用人工标注的小样本估计其与人类判断的一致率，一致率不足时不宜直接用于生产告警。

def tool_selection_score(traj, expected):
    tp = fp = fn = 0
    for step in traj.steps:
        used = set(step.tool_calls)
        need = set(expected.get(step.index, []))
        tp += len(used & need)
        fp += len(used - need)
        fn += len(need - used)
    precision = tp / (tp + fp) if tp + fp else 1.0
    recall    = tp / (tp + fn) if tp + fn else 1.0
    f1 = 2 * precision * recall / (precision + recall) if precision + recall else 0.0
    return {"precision": precision, "recall": recall, "f1": f1}

这段伪代码刻意保持了简单，目的是说明指标的可复现性优先于复杂度。实际系统中，expected 的构造才是难点：它可能来自人工标注、来自更强模型的蒸馏、也可能来自任务模板的静态声明。三种来源的可靠性依次下降，评估报告中应明确标注来源，否则跨报告比较没有意义。

3.2 调用顺序：依赖图与序列一致性

顺序评估的核心是把“哪些调用必须先于哪些调用”表达成可计算的结构。最常用的表示是依赖图：节点是工具调用，有向边表示前置约束。一条轨迹合规，当且仅当它的调用序列是依赖图的一个拓扑序。这个判定是多项式时间的，实现成本低，且能给出明确的违规位置，非常适合作为线上实时校验。

但依赖图只能表达硬约束。真实任务中大量顺序要求是软性的，例如“先做宽泛检索再做精确查询”通常更高效，但反过来也未必失败。对软约束，常用序列一致性指标：把参考轨迹与待评轨迹做编辑距离或最长公共子序列比对，得到顺序相似度。这里需要注意，参考轨迹本身可能不是最优的，把它当作金标准会引入偏差。本文评述：顺序评估的合理定位是“捕获硬违规、提示软偏离”，而不是给轨迹排优劣。把相似度分数直接当作质量分，是把手段当成了目的。

3.3 停止条件：终止判定与过度执行

停止条件评估关注两类错误：该停不停（过度执行）与不该停却停（过早终止）。前者表现为轨迹长度异常增长、重复调用同一工具、在已获得足够信息后继续探索；后者表现为在关键信息尚未获取时就给出最终答案。两类错误的代价不对称：过早终止通常直接导致任务失败，过度执行则消耗成本并可能引入副作用，但在部分任务中仍能收敛到正确结果。

可操作的指标包括：终止步数与任务复杂度的比值、终止前是否满足“信息充分性”条件、终止后是否出现补偿性调用。信息充分性条件需要任务特定的定义，例如“所有必填字段已获取”“所有子目标已标记完成”。工程上常把这些条件写成可执行的断言集合，在轨迹结束时逐条检查。这种做法简单有效，但断言集合的完备性决定了评估的上限，遗漏的条件会变成漏网之鱼。

停止条件是最容易被低估的一类信号。工具选择错了往往还能补救，顺序错了可能触发回滚，但停止条件错了，轨迹就直接结束了，没有补救窗口。

关于三类信号的组合，业界已有若干公开的评测框架可供参考。例如 LangSmith 的评测示例 展示了如何对轨迹做逐步打分，OpenAI Evals 提供了可复用的评测注册机制，相关技术讲座视频 也有对轨迹评估流程的演示。这些资源适合作为工程起步的参照，但需注意其默认假设（任务类型、工具集规模）与自身场景的差异。

四、合规轨迹为何仍会失败：鸿沟的五种成因

这是全文的核心章节。前文已经说明合规与正确分属不同空间，本节把“为何仍会失败”拆成五种可检验的机制。需要提前说明：这五种机制并非互斥，真实故障往往是多种机制叠加，归因时应做贡献度分析而非单点归因。

4.1 目标漂移：局部合理与全局偏离

第一种机制是目标漂移。智能体在长程任务中会基于中间观测调整计划，每一次调整在局部看都是合理的，但累积起来可能偏离原始目标。例如一个信息检索任务，原始目标是“找出满足条件 A 与 B 的记录”，智能体在检索过程中发现条件 A 的匹配很少，于是转向探索条件 B 的变体，最终返回了一批满足 B 变体但不满足 A 的记录。每一步的工具选择、顺序、停止都合规，但目标已经被悄悄替换。

这类失败难以被过程指标捕获，因为过程指标默认目标不变。可行的检测思路是在轨迹中维护一个目标状态，每一步后检查目标是否被修改，以及修改是否有依据。本文评述：目标漂移的本质是评估器缺少“目标不变性”这一维度。把目标作为轨迹的一部分显式记录，而不是当作外部常量，是弥补这一缺口的前提。

4.2 证据链断裂：信息获取与结论脱节

第二种机制是证据链断裂。轨迹中确实调用了正确的工具、获取了正确的信息，但最终结论并未建立在这些信息之上。常见表现是：检索到了关键文档却未在答案中引用，查询到了冲突数据却未做消解，获取了时间戳却按错误的时间口径计算。从过程看，信息获取环节完全合规；从结果看，结论与证据之间缺少可追溯的链接。

检测这类问题需要在轨迹中建立“证据—结论”的引用关系。一种轻量做法是要求最终答案附带来源标记，评估时检查每个关键断言是否有对应的轨迹步骤支撑。这种做法会增加输出格式的约束，但换来的是可审计性。笔者认为，对于高风险任务，这种约束是值得的；对于低风险任务，可以用抽样审计替代全量约束，以控制成本。

4.3 局部合规的全局不可达

第三种机制更隐蔽：轨迹的每一步都满足局部约束，但整条轨迹在全局上无法到达目标状态。这类似于在约束满足问题中，局部一致不等于全局可解。例如一个多步写入任务，智能体按合规顺序依次写入，但早期写入的选择使得后续必填字段无法满足，最终只能以部分完成收尾。由于每一步都合规，过程评估不会报警。

应对这类问题，需要在评估中加入可达性检查：在轨迹的每个关键节点，判断从当前状态出发是否存在一条满足约束的路径到达目标。完整可达性检查的计算成本可能很高，工程上常用近似方法，如基于领域知识的启发式剪枝、或用小规模搜索估计可达概率。近似会带来漏报，因此更适合作为离线诊断工具而非线上实时校验。

4.4 评估器与执行器的分布错配

第四种机制来自评估环节自身。当评估依赖另一个模型（评判器）时，评判器与执行器面对的分布可能不同：评判器看到的是整理后的轨迹摘要，执行器面对的是原始上下文；评判器的训练数据与当前任务领域可能存在偏差。这种错配会让评判器对某些合规轨迹给出高分，对某些实际正确的轨迹给出低分，从而削弱评估的判别力。

缓解手段包括：让评判器与执行器看到尽可能一致的上下文；在评判器中显式加入“不确定”选项，避免强制二分类；定期用人工标注样本校准评判器。本文评述：把评判器当作黑箱使用是当前实践中的普遍问题。任何用于生产告警的评判器，都应有一份可追溯的校准记录，否则其输出的可信度无法评估。

4.5 指标聚合掩盖结构性失败

第五种机制是指标聚合。把工具选择、顺序、停止三类分数加权成一个总分，会让不同类型的失败相互抵消。一条轨迹可能在工具选择上得分很高、在停止条件上得分很低，加权后总分看起来尚可，但实际失败恰恰由停止条件导致。聚合分数便于汇报，却不利于归因。

建议的做法是保留分项指标，聚合仅用于趋势监控，不用于单条轨迹的判定。若必须聚合，应使用能体现“最弱环节”的聚合方式，例如取最小值或加权几何平均，而非算术平均。这个建议看似琐碎，但在实际告警配置中影响很大：算术平均会让“一项极差、其余极好”的轨迹逃过阈值。

五、关键数据与案例：从基准到生产日志

5.1 公开基准中的过程与结果分离

近年来多个智能体基准开始同时报告过程指标与结果指标，为观察二者分离提供了素材。例如在工具调用类基准中，研究者普遍报告了“步骤级准确率”与“任务级成功率”两个口径，二者之间的差距在不同任务族上差异明显。需要说明的是，不同基准的任务构造、工具集规模、评分口径并不统一，跨基准直接比较数值意义有限，更有价值的是观察同一基准内两个口径的相对关系。

本文评述：公开基准的价值在于提供可复现的对照，而非给出普适阈值。把某个基准上的成功率当作自家系统的预期，是常见的误用。任务分布不同，合规与正确之间的鸿沟宽度也不同，阈值必须在本领域数据上重新标定。

5.2 一份模拟数据的说明

为说明分项指标与聚合指标的差异，本文构造一组模拟数据（明确标注为模拟数据，非真实实验结果）。设定 1000 条轨迹，按工具选择、顺序、停止三项分别打分（0–1），并按“三项算术平均”与“三项最小值”两种方式聚合，统计与人工判定的任务正确性之间的一致性。

这组模拟数据的含义是：最小值聚合以更低的通过率为代价，换取了更高的通过者正确率。对于告警场景，这通常更可取，因为误报的代价往往高于漏报的短期代价；对于离线诊断，算术平均能保留更多样本，便于分析。选择哪种聚合，取决于评估结果被用于什么决策，而不是哪种数字更好看。

5.3 生产日志中的典型模式

在生产环境中，轨迹评估通常以抽样方式运行。常见的模式包括：重复调用同一工具且参数几乎不变（提示停止条件失准或状态未更新）、在依赖未满足时提前调用下游工具（提示顺序约束缺失）、工具选择在任务后半段显著偏离前半段分布（提示目标漂移）。这些模式本身不是结论，而是线索，需要结合具体任务做二次确认。

关于日志处理，需要说明预处理细节：轨迹日志通常需要先做脱敏（去除用户标识、敏感参数），再做结构化（把自由文本的工具返回解析为字段），最后做对齐（统一步的切分粒度）。这三步中的任何一步处理不当，都会让后续指标失真。例如脱敏时若把参数值整体替换为占位符，基于参数相似度的重复调用检测就会失效。

六、分层评估框架与工程实施步骤

6.1 三层框架：实时校验、离线诊断、结果验证

基于前文的成因分析，本文提出一个三层评估框架。第一层是实时校验，只做语法与程序合规的硬规则检查，要求低延迟、零误报，命中即拦截或告警。第二层是离线诊断，对抽样轨迹做工具选择、顺序、停止的分项打分，并做目标漂移与证据链的专项检查，允许较高计算成本。第三层是结果验证，独立于轨迹，直接检查最终产物是否满足任务目标，作为正确性的最终裁判。

三层之间的关系是：第一层保证“不出硬错”，第二层提供“漂移预警与归因线索”，第三层给出“正确性结论”。任何一层的结论都不应越权替代其他层。实践中常见的问题是拿第二层的分数当第三层的结论，这正是前文所述鸿沟的工程表现。

6.2 实施步骤

第一步，定义任务分布与基线。明确评估覆盖哪些任务族，采集基线策略在相同分布下的轨迹，作为漂移比较的参照。第二步，固定轨迹切分粒度与字段规范，确保跨批次可比。第三步，构造依赖图与断言集合，先覆盖硬约束，再逐步补充软约束。第四步，实现分项指标，保留原始分数，聚合仅用于趋势。第五步，用人工标注样本校准评判器与阈值，记录校准时间与样本量。第六步，配置告警策略，区分“拦截级”与“观察级”，并设定复核流程。第七步，定期回看误报与漏报，迭代断言集合与阈值。

这七步的顺序不宜颠倒。尤其第一步常被跳过，导致后续所有指标缺少参照系，漂移判断变成拍脑袋。本文评述：评估体系的成熟度，很大程度上取决于基线是否被认真对待。没有基线的评估，只是给轨迹打分，谈不上检测漂移。

6.3 阈值标定与成本权衡

阈值标定的目标不是找到“正确”的数值，而是在误报与漏报之间选择一个与业务风险匹配的平衡点。可行做法是绘制分项指标与任务正确性的关系曲线，观察在哪个区间二者开始明显分离，把阈值设在该区间之前。对于高风险任务，阈值应偏保守；对于探索性任务，可以放宽，把资源留给结果验证。

成本方面，实时校验的单步开销应控制在毫秒级，离线诊断可以到秒级，结果验证可能涉及人工或强模型，成本最高。三层的采样率应据此差异化配置，而不是对所有轨迹做全量三层评估。关于工程实现的更多细节，可参考 LangSmith 文档 与 AutoGen 项目 中关于轨迹记录与回放的实现思路。

七、对比与局限：轨迹评估能做什么、不能做什么

轨迹评估的长处在于可观测、可归因、成本可控。它能在任务失败之前捕获异常模式，能把失败定位到具体步骤，能支持回归测试中的差分比较。这些能力在工程上是实打实的价值。但它也有明确的边界：它无法直接证明任务正确，无法覆盖未被断言表达的目标，无法完全消除评判器偏差，也无法处理轨迹之外的副作用（例如工具调用对外部系统造成的不可逆影响）。

与其他评估手段相比，轨迹评估介于“单元测试”与“端到端验收”之间。单元测试粒度更细但覆盖有限，端到端验收结论更硬但成本高、定位难。轨迹评估的定位应是二者的补充，而非替代。本文评述：把轨迹评估包装成“全自动正确性判定”是过度承诺，长期看会损害评估体系的可信度。诚实地说明它能做什么，反而更有利于它在工程中站稳位置。

八、结论与展望

回到标题提出的问题：轨迹“看起来合规”与“任务最终正确”之间差的是什么？本文的答案是——差的是目标不变性、证据可追溯性、全局可达性、评估器校准与指标聚合方式这五个环节。它们不在轨迹的形式约束之内，却决定了轨迹是否真的指向正确结果。把轨迹评估定位为漂移检测工具而非正确性证明工具，是理解这一落差的前提。

展望后续，有三个方向值得投入。其一是把目标状态显式纳入轨迹表示，让目标漂移可被直接观测；其二是发展轻量的证据链追踪机制，在不显著增加输出约束的前提下建立结论与步骤的关联；其三是推动评判器的标准化校准流程，让评估结论带有可追溯的置信度。这三项工作都不追求“一步到位”，而是逐步收窄合规与正确之间的鸿沟。

最后需要强调，评估体系的建设是持续过程，不是一次性交付。任务分布会变，工具集会变，模型行为也会变，任何阈值和断言都需要定期复核。把复核机制写进流程，比把阈值调得更精细更重要。

九、主要参考文献