AFAgent Field Notes会员账号
知识目录选择核心方向与细分内容
Q39高级原理约 13 分钟

结果与轨迹的双重验收

最终结果正确,Agent 轨迹还需要评测吗?如何避免误判不同的正确路径?

用结果后置条件、必要事件的偏序和禁止行为评测轨迹,不强制所有工具调用完全一致。

轨迹评测工具调用偏序可观测性

知识内容核对 2026-10-03 · 原题来源核对 2026-10-02

本题目录

READ · UNDERSTAND · TRANSFER

阅读理解,按需巩固

我的笔记与复习 ↗

先沿着原理、问答和迁移案例阅读。需要检查理解时,再切换巩固练习或展开个人记录。

作答与个人记录

每次修改后的提交会保留为独立历史。掌握程度由你对照标准自评。

核心知识 · 结果与轨迹的双重验收

先理解核心原理

先备概念:调用日志、并发依赖、权限校验

结果回答任务最终变成了什么,轨迹回答哪些动作造成该结果。验收应约束必要事实与因果关系,允许不影响约束的合法路径变化。

为什么正确结果也会失败

余额查询返回了正确数字,仍可能读过另一个人的账户;创建工单成功,仍可能重复创建。结果快照看不到所有过程风险,所以必须检查真实工具事件与受保护资源。反过来,工具列表完全符合预期也不证明最终计算正确。

从固定序列改成依赖条件

两个已授权检索可并行,缓存和数据库都可提供同一版本资料。正确规则是每次读取之前已有针对该主体、资源和动作的有效授权,以及回答引用本次允许的证据;不是强制缓存之后一定再查数据库。用事件标识和父子依赖表达偏序,墙钟只辅助排障。

留出证据缺口

工具开始事件不等于完成回执,模型说“已经验证”也不等于真实调用。缺失关键日志时,要把“无法判定”与“已发现违规”区分,同时按任务风险决定是否阻断发布。以下路径和事件设计是学习推演,没有模拟真实并行运行。

回到问题:怎样回答?

需要。结果评测回答任务是否完成,轨迹评测检查为什么完成以及是否越权、重复执行或浪费资源。但轨迹不应默认逐字匹配一条标准调用序列,因为缓存、并行和不同合法检索路径可能都正确。用必需步骤、禁止步骤、参数约束和先后依赖定义允许路径;硬政策违反直接失败,步骤质量可给部分分。采集真实工具事件与业务状态,失败案例回归到节点,不能把模型自述的计划当执行证据。

实现与取舍

正确结果可能掩盖错误执行

Agent 可能碰巧得出正确余额,却读取了错误账户;报告最终正确,却在过程中多次提交了重复工单。只评最终回复无法发现这些问题。轨迹提供真实工具名、参数、返回状态、重试原因、授权决策及因果关系,用来定位错误和成本来源。反过来,走过预期步骤也不意味着结果正确,检索成功后仍可能做错计算。因此结果验收和轨迹验收互补,不能相互替代。

用允许路径而不是单一标准序列

LangSmith 文档指出 exact trajectory 有局限,因为可能存在多条正确路径。工程上把规则分为必须发生、不得发生、参数须满足、事件 A 先于 B。比如授权必须先于读取,引用证据必须来自本次允许结果,写入必须使用审核后的操作键。读取可以来自数据库或授权缓存,互不依赖的两个查询可以并行。比较工具名称的集合会忽略次数与参数;比较固定顺序又会把合理并行误判。偏序与状态条件能更贴近真实业务。

轨迹采集需要可信事件和因果标识

每个事件记录 event_id、run_id、step_id、parent_id、tool、输入摘要或受控参数、开始结束时间、状态和资源用量。请求开始不等于业务成功,超时可能是结果未知,业务对账事件应独立记录。敏感参数脱敏但保留可以核验权限的资源标识;日志缺失不能自动评分通过。并行任务的事件需要按因果关系分析,单靠时钟排序可能错判。模型生成的“我已经查了三次”不是工具执行证据。

部分分用于诊断,硬约束用于阻断

可以计算检索步骤完成度、无效调用次数、重复读写和正确参数比例,帮助定位偏差;越权读取、未经批准发送等禁止动作仍直接失败。先用规则检测稳定边界,再人工或语义评审开放式决策。下面代码允许数据库读取和缓存读取两条路径,并检查授权先于读取及禁止删除;它只适用于串行列表样例,生产并行轨迹应使用事件 DAG 表达 happens-before,还需校验资源参数和最终业务后置条件。不要为了“轨迹更像答案”强制多余调用,也不要把不可观测的内在思考当成可验收日志。

代码示例

接受两条合法轨迹,拒绝先读后授权

Python 标准库可运行。仅演示串行偏序,authorize 未校验主体或资源;生产必须验证参数、权限决定、事件因果及业务结果。

def score(events):
    tools = [e['tool'] for e in events]
    reads = [i for i,t in enumerate(tools) if t in {'db_read','cache_read'}]
    auth = [i for i,t in enumerate(tools) if t == 'authorize']
    return {
        'authorized_before_read': bool(auth and reads) and all(any(a < r for a in auth) for r in reads),
        'no_delete': 'delete' not in tools,
        'has_answer': bool(tools) and tools[-1] == 'answer',
    }
for names in [('authorize','db_read','answer'), ('authorize','cache_read','answer'), ('db_read','authorize','answer')]:
    checks = score([{'tool': n} for n in names])
    print(all(checks.values()))

预期输出

True
True
False

工程推演

场景
假设工程场景:查询 Agent 有数据库直读和已授权缓存两条实现路径。
设计决策
结果都核对同一数据快照,轨迹门禁允许两种读取,但要求当前授权先于访问。
验证目标
验收目标是缓存优化不会因调用路径不同被误判,先读后授权仍判失败。
适用边界
示例不处理缓存陈旧、主体与资源授权匹配,也不证明并发事件顺序。

连续追问与解答

沿着问题的前提和约束继续向下读。先理解参考解答,再尝试收起答案,用自己的话解释因果和取舍。

举一反三:条件变了,怎样推导?

先找出改变的条件,再判断原方案中哪些前提仍成立。下面的案例是教学推演,便于将原理迁移到新问题。

缓存替代一次数据库读取

改变的条件:执行路径变短,但授权与数据版本目标保持。

延伸问题:少了一次查询应判轨迹失败吗?

推导与参考解答

若缓存记录同样携带数据版本、授权范围并能验证未失效,则查询来源可以变化。把规则写成“读到允许版本的资料”,而不是“必须调用 SQL 工具”;最终结果仍需检查一致性。缓存权限不明时不能放宽。

保持不变的原理:允许实现路径变化,保留资源与授权约束。

两个发布分支并行

改变的条件:从只读并行变成两个可能重复外发的分支。

延伸问题:只检查最终有一篇报告够吗?

推导与参考解答

不够。两个分支应共享同一业务发布键或通过唯一发布状态协调;轨迹检查两次尝试是否产生一次效果,并核对目标记录。依赖图可允许生成并行,发布仍受批准版本与去重约束。

保持不变的原理:过程约束和业务终态同时成立才是成功。

易错点

  • 要求唯一工具调用序列,惩罚合法替代路径
  • 只比工具名,忽略参数、次数和副作用
  • 把工具请求开始视为业务已经成功
  • 将模型自述当成真实执行轨迹

参考资料

依据公开技术资料设计;参考资料支持技术机制,场景与评分标准为本站设计,不代表某公司面试原题。 新增问答与迁移案例用于原理讲解,来源核查与案例运行验证分别记录。

检查自己理解到哪一步

读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评;需要进一步验证时,再完成下方小任务。

基础达标
知道结果正确仍可能执行了危险或多余动作。
中高级信号
按允许与禁止动作、因果顺序检查轨迹。
资深信号
容许多种正确路径,衡量轨迹规则误报并用反例校准。

查看独立示例的校验记录

巩固练习 按需完成 · 建议 15 分钟

比较两条不同但合法的工具轨迹与一条结果正确的越权轨迹。

展开验收要求与检查点
  • 合法替代路径不误判
  • 越权不会因结果正确而放行
  • 规则有明确适用范围

重点检查

  • 能区分业务结果与执行过程的评测价值
  • 能说明精确轨迹匹配对合法替代路径的误判
  • 能用偏序表达授权先于受保护读取等依赖
  • 能识别参数错误、缺失日志与不可信自述