先说一个反直觉的结论
过去两年，AI 编程圈最常见的一句建议是：「在系统提示里写清楚'请谨慎调用工具'就好了。」
2026 年 7 月，一个专门测这件事的基准跑出了结论：这句话不仅没用，还可能让结果变差。
先看它测出来的东西（GuardianAgentBench，arXiv:2607.20982，2026-07-23 发布）：
580 个场景 / 6 个领域 / 3 个生产级框架（LangChain、LlamaIndex、Vectara）/ 6 个模型
81 个工具 / 1,177 次连续调用 / 182 个场景含对抗性修改
最强配置的整体准确率：74.8%
四分之一的任务失败。 而这些是当前最前沿的模型 + 成熟的编排框架。
但真正值得看的不是74.8%，是它把失败拆开之后暴露的东西。
一、★ 最贵的发现：两种相反的失败模式
评测发现，强模型和弱模型的失败方式是完全相反的：
强模型（Claude Opus 4.5 这类）
主要失败 —— 漏调该调的工具
占比 —— 漏调占其失败的 52–57%
表现 —— 明明该查，却靠自己的权重直接答
弱模型（DeepSeek-V3.2、Qwen3-Max 这类）
主要失败 —— 乱调不该调的工具
占比 —— 错选 23.6–25.3%、重复调用 28.7–32.2%
表现 —— 疯狂重试同一个工具
打个比方：
● 强模型像一个谨慎的新人——你说查一下订单号，它觉得「我应该知道」，于是不查，直接编一个给你。
● 弱模型像一个焦虑的实习生——你让它查订单，它查三遍，每遍参数都不一样，还不停换工具。
★ 关键在于：这两种失败，用同一种解法是无效的
这条是全文最值钱的地方。
如果你的护栏是「鼓励多查、别偷懒」，那对弱模型是灾难（它本来就乱调）； 如果你的护栏是「严格限制、少调用」，那对强模型是灾难（它本来就漏调）。
一条提示词不可能同时治好两种病。
评测里有个更扎心的数据——「工具调用顺序错了」只占全部失败的 0.6–4.4%，是五类失败里最少的一类。
而很多团队的 Agent 评测里，「有没有按正确顺序调工具」却是个高频指标。
我们正在用最重的权重，去考核模型做得最好的一项。
二、★ Prompt 修不了这件事
既然失败分两种，那解法必须分两种。既然解法是代码，那就得看提示词到底管不管用。
评测组做了一件很直接的事：在系统提示里加安全指令，看会怎样。
结果：
DeepSeek-V3.2 +5.5 分
Claude +0.4 分
Gemini +0.3 分
GPT-5.2 Pro −0.3 分 ← 退步
从 +5.5 到 −0.3。 也就是说，写得好的安全提示可能有用，写得一般的完全没用，写歪的还倒退。
对比一下真正管用的东西——执行时护栏（在工具执行前拦截，检查参数、必调工具、相关性/成本）：
恢复19.9% 的失败
误报率只有 0.5%
全部六个模型都涨，幅度 2.8–7.7 分
19.9% 的失败被挡住，代价是 0.5% 的误伤。 而最好的提示词是 −0.3。
架构上的结论很直接：
把工具策略当代码写，别当提示词写。
护栏应该坐在模型的决策和副作用之间，返回三种结果：通过 / 带纠正反馈重试 / 直接拦下并转人工。
三、★★ 更狠的一条：多步比多工具危险得多
如果只让我记一个数字，是这个。
以Claude Opus 4.5 为例，三种配置下的整体表现：
工具数量 1 个工具 78.2 分 → 7 个工具 62.3 分 掉 15.9 分
顺序深度 1轮 82.3 分 → 7 轮 51.2 分 掉 31.1 分
顺序深度的伤害是工具数量伤害的近两倍。
为什么？工具多顶多是选择变难；但步骤深会出现一串新问题：
● 该记的状态丢了
● 跳过前置检查
● 把被污染的中间结果一路带下去
● 最初的意图早就模糊了，还在往前冲
这里有个很容易踩的坑：
一次两步的漂亮演示，什么都证明不了。
很多团队做验证时跑通了一个 1–2 步的 happy path，就觉得「这个 Agent 上线没问题」。而 7 步的流程才是线上真实的形状。
安全测试的轮次深度应该独立于工具数量去测。
四、还有一条数据值得单独说：工具排序错误是最不重要的
前面提了，这里再说一次，因为反直觉：
五类失败的占比（Claude Opus 4.5 为例）：
漏调该调的工具 45.8–48.0%
重复调用 20.2–22.4%
错选工具（弱模型） 23.6–25.3%
★ 顺序错误 0.6–4.4% ← 五类里最少
在这个规模下——1 到 7 个工具、1 到 8 轮——「排序」这件事基本已经解决了，而「覆盖」和「选择」没有。
所以如果你的 Agent 评测还在给「有没有按正确顺序调工具」高权重，你考核的是模型做得最好的那一项。
另外还有个更反直觉的：重试次数和准确率几乎不相关。
数据显示，失败后「再试一次同一个工具」占了 44–76% 的后续动作，但重试倾向和准确率只是弱相关——重试多的模型，有的同时排在榜首，有的排在榜尾。
区别在于：你的恢复动作对不对得上真正的失败原因。如果压根不是参数问题，重试一万次也是错的。
五、那具体怎么落地
我把评测的结论翻译成几条能直接用的：
① 先测你的 Agent 属于哪种失败模式
不要一上来就写护栏。先造一批真实场景，跑一遍，看它到底是不调、乱调、还是漏调。
● 漏调为主 → 加「必调工具覆盖检查」
● 乱调为主 → 加「相关性/成本/频率控制」
② 护栏放在执行前，不放在提示词里
关键点：护栏要在完整交互上下文上判断这次调用，且必须能阻断——返回一个「不允许」，而不是只给个建议。
判定不了的时候，留一个转人工的口子。
③ 工具数控制在 15–20 以内
超过这个数，准确率掉得快。真要更多，就分层：先用一个路由模型挑出 5–10 个相关的，再让执行模型在缩减后的集合里干活。
④ 压工具链长度，别压工具数
砍工具集的收益远小于砍链路深度。把 7 步流程拆成两段，各自验证，比给 Agent 多塞 5 个工具有用得多。
⑤ 硬边界用确定性规则，别交给模型判断
租户隔离、写权限、金额上限这类，必须是代码规则，不能指望模型每次都记得。
模型只适合做上下文分类这类模糊判断。
六、最后
这篇的核心其实只有一句：
Agent 的可靠性问题，不是「模型不够聪明」，是「控制没放在正确的位置」。
那句流传最广的建议——「在提示词里写清楚要谨慎」——在实测里是 +5.5 到 −0.3 分的区间。
而真正管用的东西是：在工具执行前插一道程序，把策略写成代码。
护栏恢复了 19.9% 的失败，误报 0.5%。这个性价比，值得你今天就加一道。
顺便说一句，我把这几篇的选题和核查过程都记在笔记里了，包括我实测时踩的坑（有一版核对脚本误报了35 段，查下来全是格式差异不是内容丢失）。如果你在做类似的东西，可以对着那几条判据自查一遍。
