让智能体先看再做：一项研究如何用执行前验证减少静默错误

导语

当大语言模型从“回答问题”转向操作终端、修改代码和调用工具时，真正棘手的风险不一定是系统报错。更隐蔽的情况是：命令能够运行，文件也完成了修改，但最终效果并不是用户想要的。由于执行过程没有异常，这类“静默失败”很难被发现，也更容易进入后续流程。

arXiv 论文《Look Before You Leap: Pre-Action Verification for LLM Agents》提出了一种直接的防护思路：让智能体在动作生效前先接受一个廉价、确定性的检查。验证器不必强行判断所有动作，在证据不足时可以拒绝执行，从而把静默错误转化为可重试、可恢复的问题。

核心要点

• 命令检查覆盖多个层次。 研究针对 9930 条命令和 482 个工具测试静态验证器。整体能够发现 95.8% 的无效命令，误报率为 10.0%。其中，语法检查和二进制文件检查达到零误报，并发现约一半错误；剩余误报全部来自参数检查，而参数检查受工具帮助文本覆盖范围限制。
• 代码编辑方式决定失败是否可见。 搜索/替换和差异补丁等基于内容锚定的格式，在目标内容不匹配时通常能够明确失败。相比之下，依赖行号或函数名的位置锚定方式更容易“成功执行但改错地方”。在单行偏移的测试中，行号编辑导致 99.1% 的文件被错误破坏；按函数名定位时，12.7% 的编辑命中了错误函数。
• 拒绝并不等于系统失效。 研究把“无法确认就拒绝”作为一种可调策略。选择性 grounding 在 7.0% 误报率下达到 0.958 的召回率；采用锚点并在应用前验证的编辑器，在 8320 次试验中只出现 1 次静默误应用，比例为 0.01%。

意义与影响

这项工作的重点不只是增加一个检查器，而是重新定义智能体的执行边界。传统流程往往是“模型生成动作—执行器运行—事后观察结果”，但事后结果可能无法说明动作是否真的作用在正确对象上。执行前验证则尝试先固定“正确效果”的必要条件，再允许动作进入执行阶段。

对智能体工程而言，这意味着工具调用接口不应只返回成功或失败，还应提供可验证的前置条件、目标锚点和拒绝机制。代码编辑工具尤其应优先采用内容锚定、差异补丁和上下文校验，而不是单纯依赖脆弱的行号。对命令执行来说，语法和工具存在性检查可以作为低成本基础层，参数校验则需要明确其知识覆盖边界。

当然，验证器并不能证明每个动作都符合用户的高层意图。它更擅长判断动作是否结构正确、目标是否仍然存在，以及应用过程是否发生偏移。研究的价值正在于把“不可避免的模型不确定性”转化为可控制的拒绝与重试成本：宁可暂缓一个无法确认的动作，也不要让一个看似成功的错误继续传播。

来源：arXiv