在此页面上
简短的回答
仅当所选工具、参数、授权和产生的副作用适合任务时，工具调用才是正确的。测试完整的边界：有效的语法仍然可以更新错误的记录、重复操作或执行不受信任的指令。
拿走什么
- 验证业务含义以及论证结构。
- 尽可能将授权保持在模型判断之外。
- 检查重试和部分失败后的结果状态。
已检查来源 .研究综合和 Rubrex 建议。示例和本地实验均已标记；它们不是客户结果。
最近的工具使用工作将政策与文本分开
NetInjectBench 是 2026 年 7 月的预印本，它将不受信任的操作工件与受信任的策略元数据分开。其实验在既定假设下将提示级方法与执行时间控制进行比较。这促使评估工具边界本身，而不是假设谨慎的提示可以防止不适当的操作。
定义四层正确性
工具选择询问操作是否与任务匹配。参数正确性询问标识符、单位、日期和必填字段是否正确。授权询问该用户和上下文是否允许所请求的操作。结果正确性询问实际发生了什么变化。一层的通过并不意味着下一层的通过。
为机械要求创建精确的验证器，并为受限操作创建独立的策略检查。对于不明确的实体解析，定义代理必须澄清的时间。可信的客户名称不足以作为在两个同名记录之间进行选择的证据。
围绕边界构建案例
Rubrex 建议针对有效操作、缺少参数、格式错误的工具响应、不明确的标识符、超时、重复请求和权限拒绝的情况。包含引用命令的良性文档，以便代理必须区分信息和指令。当工具可以进行更改时，使用测试数据和隔离状态。
记录被拒绝的呼叫是否被应用程序正确阻止、被座席避免或根本从未尝试过。这些是不同的观察结果。强大的权限层可以保护系统，但代理在请求规划方面仍需要改进。
| 层 | 检查示例 |
|---|---|
| 选择 | 查找请求不会成为更新 |
| 参数 | 解析的帐户标识符与预期记录匹配 |
| 授权 | 文档无法授予执行受限操作的权限 |
| 结果 | 重试后恰好存在一个预期更新 |
说明性示例：两个客户共用一个名字
销售助理被要求更新名为 Northstar 的帐户。两个帐户匹配。 API 接受任一标识符，因此模式验证本身无法确定正确性。预期的行为是在突变之前使用可用的消歧上下文或请求澄清。
添加一个控件，其中请求包含唯一的帐户标识符。代理应该在没有不必要的中断的情况下完成该任务。这种配对设计有助于将有用的谨慎与要求对每个操作进行确认的系统区分开来。
评估集成的恢复合同
对于每个操作，记录重试是否安全、是否支持幂等性密钥以及如何检查当前状态。测试确定的失败和不确定的结果。将缺陷分配给适当的层：缺失的应用程序护栏不应伪装成模型提示问题。
证据的局限性
引用的基准涉及网络操作和特定元数据假设。其报告的防御结果不能直接转移到另一个工具环境。本文提出可靠性检查，并不构成完整的安全审查。
常见问题
JSON 模式验证是否使工具调用安全？
否。它验证结构，而不验证操作是否授权或所选记录是否正确。
每个工具错误都应该触发重试吗？
否。重试行为取决于操作是否已经发生以及重复是否安全。
来源和进一步阅读
本简报背后的主要来源。来源的研究结果适用于其自身的研究条件； arXiv 上的出版物不建立同行评审。
- NetInjectBench：使用大型语言模型代理进行网络操作的工具间接提示注入基准测试 arXiv · 2026 · 预印本已审核： 摘要和出版记录.已访问 2026年9月25日.