Agent 怎么用工具：描述怎么写，边界画在哪

工具是模型碰到真实世界的唯一通道。这一篇讲怎么装，以及装的时候该在哪儿画线。

先破一个误解

模型不执行工具。

真实流程是：模型输出一段结构化文本说「我想调 search，参数是这些」→ 你的代码执行 → 结果作为一条消息塞回对话。

模型自始至终没碰过任何东西。 它只是在生成一种约定格式的文本。

这个认识推出三条规矩。

规矩一：工具描述是杠杆，不是文档

有实验把工具描述从一行摘要扩成写清前置条件和相互作用的完整说明。结果：同一个模型同一个任务，正确率从 17.1% 涨到 61.0% —— 43.9 个百分点，零训练成本。

同一篇里还有更狠的：3B 模型配好描述，比 7B 配差描述高 14.1 个点。 原文的结论是harness 的选择可以盖过模型容量的影响。

所以描述里至少要有四样：

这个工具干什么
什么时候该用它
每个参数的含义和取值范围
什么时候不该用它 ← 最常被漏掉

第四条特别值钱，因为模型的典型失败不是「不会用」，是「在不该用的时候用了」。

规矩二：安全边界在你这边

模型说要删，删不删是你的代码决定的。所以不可逆的动作要有一道显式的门：删除、支付、发布、对外发消息。

拦下来之后有个细节：不能静默跳过。「做了」「做失败了」「被拦下没做」是三个状态 —— 混成两个就会出现假绿灯。

还有一条更结构性的：凭据不要和执行环境放在一起。Anthropic 拆 brain/hands 的一个直接理由就是，原来的设计里 agent 生成的不可信代码和凭据跑在同一个容器里。

规矩三：解析层迁就模型

模型不会严格按你的字段名回话。真实见过的偏差：字段名换个说法、该给数组给了对象、整个回复是个裸数组。

每一种都能再写一版提示词去纠正，但那是把成本压在每一次调用上；写在解析层只付一次。

schema 迁就模型，比让模型迁就 schema 划算。结构化输出的校验和重试下一篇细说。

顺带说一个我自己实测到的反直觉现象，和 schema 相关：要结构化输出的时候我第一反应是打开 JSON 模式。同一份提示词，带这个参数，服务端返回 []，三个 token 就结束；把它去掉，同一个模型给出五个状态、四条迁移、六百多个 token。 因为那个模式只保证语法合法，而 [] 也是合法 JSON —— 它成了最短的合法答案。我的经验和判断是：别用 JSON 模式当护栏 —— 护栏得是 schema 校验加带样例的重试。

但有边界：解析层的宽容是给「模型换了个说法」用的，不是给「我没定义清楚」用的。如果一个字段认下了五种叫法，该反过来问提示词是不是根本没说清。

工具不是越多越好

三个理由：

一、选错的概率上升。 相似的工具互相干扰。

二、工具返回的内容本身就是攻击面。 AgentDojo 专门为这件事造了个环境：97 个真实任务配 629 个安全测试用例，做法是往外部工具返回的数据里埋指令。它的结论有两句，第二句更值得记：前沿模型在没有攻击的情况下就已经做不好很多任务，而现成的注入攻击能打破一部分安全属性，但不是全部。

这两句合起来的意思是：别把「模型没被骗到」当成安全 —— 它可能只是这次没做对而已。

三、描述的质量成为瓶颈。 工具越多，把每个描述都写好越难。

所以「接了几十个工具」不是成就，是需要被管理的成本。 按场景分组、按需加载比一次全塞实际。

一个容易忽略的入口

工具描述是文本，而文本可以携带指令。

接一个第三方工具，意味着让它的描述进入你的上下文。这是提示词注入的一个真实入口，而且比「用户输入」那个入口隐蔽得多 —— 没有人会怀疑一份工具描述有敌意。 挡它要靠结构性的防御 —— 凭据和执行环境分开，而不是在提示词里叮嘱一句。

边界与代价

那 43.9 个百分点来自特定基准。 环境是工具边界清晰的具身任务。你的场景如果工具语义更模糊，杠杆未必这么大。可以拿它论证「先把描述写好」，不能拿它推算你能涨多少。

详细的描述也有代价： 更长的 prompt、更贵、更慢。这笔账在本地小显存上跑的时候会直接改变结论。

工具设计的错误很难被发现。 一个描述写得含糊的工具，表现是「模型偶尔用错」—— 而这看起来像模型不行。排查的时候先怀疑描述，再怀疑模型。