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 有数据库直读和已授权缓存两条实现路径。
- 设计决策
- 结果都核对同一数据快照,轨迹门禁允许两种读取,但要求当前授权先于访问。
- 验证目标
- 验收目标是缓存优化不会因调用路径不同被误判,先读后授权仍判失败。
- 适用边界
- 示例不处理缓存陈旧、主体与资源授权匹配,也不证明并发事件顺序。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答,再尝试收起答案,用自己的话解释因果和取舍。
第 1 层并行分支怎样判断授权与读取的因果顺序?
主问题允许并行合法路径,因此要定义因果而非全局序号。
参考解答
为授权决定记录 decision_id、主体、资源、动作、策略版本,并在读取事件引用它;队列消费与分支通过父事件或因果链接相连。检查依赖图上授权在读取之前且仍有效,不仅比较两个机器的时间戳。并行不相关的读取可交换顺序。
沿着这个回答继续深入
第 2 层授权后到读取前,权限发生撤销,依赖顺序正确就够了吗?
父问解决先后关系,子问增加先后之间的状态变化。
参考解答
不够。顺序只证明先检查过,要再验证授权的有效版本或有效期,并在最终读取网关执行权限判断。若权限与读取跨服务无法原子绑定,应说明允许的撤销传播窗口;敏感数据在无法判断当前权限时拒绝读取。
沿着这个回答继续深入
第 3 层离线轨迹中没有撤销版本,应该直接判越权吗?
父问要求有效授权证据,再追问缺失证据如何影响结论。
参考解答
不能仅凭缺字段断言实际越权,但也无法证明合规。记录未知及所缺证据,检查权威授权审计与读取回执是否可补齐;在敏感发布门禁中阻断未知。把真实违规率和未知比例分别报告,避免将二者混成一个成功分数。
第 1 层只比工具名称集合会漏掉哪些错误?
放宽固定顺序之后,工具集合仍不足以表达安全约束。
参考解答
集合丢失次数、参数、结果和先后依赖:读了两次和读了一次相同,读 A 租户和 B 租户也相同,先发信后审批仍包含两个工具名。至少保留调用次数、资源身份、结果状态与审批引用,再用业务状态核对效果。
第 1 层轨迹日志丢失时该判失败、未知还是继续发布?
双重验收依赖采集质量,需明确缺证据的判定。
参考解答
关键权限或写入证据缺失时,结论是未知,不能当通过。发布策略可以把未知也作为阻断项;普通低风险性能日志采样缺失不必等同违规。保留证据完整性指标和原因,补查受控审计或目标状态后重新验收。
举一反三:条件变了,怎样推导?
先找出改变的条件,再判断原方案中哪些前提仍成立。下面的案例是教学推演,便于将原理迁移到新问题。
缓存替代一次数据库读取
改变的条件:执行路径变短,但授权与数据版本目标保持。
延伸问题:少了一次查询应判轨迹失败吗?
推导与参考解答
若缓存记录同样携带数据版本、授权范围并能验证未失效,则查询来源可以变化。把规则写成“读到允许版本的资料”,而不是“必须调用 SQL 工具”;最终结果仍需检查一致性。缓存权限不明时不能放宽。
保持不变的原理:允许实现路径变化,保留资源与授权约束。
两个发布分支并行
改变的条件:从只读并行变成两个可能重复外发的分支。
延伸问题:只检查最终有一篇报告够吗?
推导与参考解答
不够。两个分支应共享同一业务发布键或通过唯一发布状态协调;轨迹检查两次尝试是否产生一次效果,并核对目标记录。依赖图可允许生成并行,发布仍受批准版本与去重约束。
保持不变的原理:过程约束和业务终态同时成立才是成功。
易错点
- 要求唯一工具调用序列,惩罚合法替代路径
- 只比工具名,忽略参数、次数和副作用
- 把工具请求开始视为业务已经成功
- 将模型自述当成真实执行轨迹
参考资料
依据公开技术资料设计;参考资料支持技术机制,场景与评分标准为本站设计,不代表某公司面试原题。 新增问答与迁移案例用于原理讲解,来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评;需要进一步验证时,再完成下方小任务。
- 基础达标
- 知道结果正确仍可能执行了危险或多余动作。
- 中高级信号
- 按允许与禁止动作、因果顺序检查轨迹。
- 资深信号
- 容许多种正确路径,衡量轨迹规则误报并用反例校准。
巩固练习 按需完成 · 建议 15 分钟
比较两条不同但合法的工具轨迹与一条结果正确的越权轨迹。
展开验收要求与检查点
- 合法替代路径不误判
- 越权不会因结果正确而放行
- 规则有明确适用范围
重点检查
- 能区分业务结果与执行过程的评测价值
- 能说明精确轨迹匹配对合法替代路径的误判
- 能用偏序表达授权先于受保护读取等依赖
- 能识别参数错误、缺失日志与不可信自述