Dispatch-Level Instrumentation：Agentic 抽取评测的工具轨迹证据
Dispatch-Level Instrumentation：Agentic 抽取评测的工具轨迹证据
核心判断
这篇 arXiv 摘要的关键贡献是一个反直觉评测失败：某模型在 datasheet extraction 中通过 fidelity check，却从未打开 datasheet；结构化输出约束静默禁用了工具使用，模型仍给出了看似正确、但带 fabricated source text 的答案。只有 per-tool trace 暴露了问题。
它对用户重要，因为这几乎是 llm-wiki / Hermes 的同构风险：最终答案看起来忠实，不代表读取过 source；页面写得像 source-backed，不代表有 raw、hash、工具轨迹和 claim receipts。Agent-Benchmarks 必须把 dispatch-level instrumentation 当作一等证据。
机制 / 一阶原理
传统 fidelity metric 只看 extracted value 是否匹配 source。论文提出在 37 个 hand-curated claims 的 agentic benchmark 中记录每个 tool call，从 dispatch record 构建两个 instruments：rule-based failure-attribution classifier，以及 silent-failure detector。后者的规则只检查工具是否被调用，不检查 extracted value，因此可以发现“没读源却答对/编造”的静默失败。
这说明评测需要区分三件事：结果值是否正确、路径是否合规、工具层是否提供可移植可观察证据。摘要还提到 causal chamber 作为第二独立 oracle，但只能覆盖 37 个 claims 中 2 个的物理可测 envelope，提醒 verifier 也有边界。
与已有 wiki 的关系
- 与 Agent-Benchmarks：补充 silent failure detector、tool-call trace 和 oracle coverage 的概念。
- 与 Harness-Engineering：验证不应只在最终文本层，dispatch/event layer 必须可审计。
- 与 Loop-Engineering：长期 loop 的状态推进要基于工具/文件/runner receipts，而不是 narration。
- 与 Knowledge-as-Code：source-backed knowledge 需要 raw path、hash、claim-to-source markers 和写入记录共同支撑。
可执行启发
- llm-wiki radar 报告中“已读取/已保存/已更新”的 claim 必须能对应 raw file、page path、log entry 或命令输出；否则应写为 HOLD/未验证。
- 对网页抽取失败但搜索摘要可见的候选，只能进入候选摘要，不应晋升正式 source page。
- 可以为 wiki-radar 加一个轻量 silent-failure check：新 source page 的
sources:是否指向存在的 raw；raw 是否有 sha256；正文是否有写入记录；index/log 是否含对应项。
边界与失败模式
- 本轮只读取摘要，未获取全文；数据集、规则、207 clean runs / 50 planted faults 等细节需全文复核。
- Tool-call detector 能发现“没调用必须工具”的故障，但不能覆盖“调用了工具仍然错误”的情况；论文摘要也明确 detection power 未测。
- 过度依赖规则可能漏掉新的 silent failure 模式，因此规则应和随机人工审计/全文抽样结合。
写入记录
- 2026-08-31 09:00 CST：新增 dispatch-level instrumentation source page，提炼 fidelity 不足、工具轨迹、silent-failure detector 和 llm-wiki claim receipt 启发。