引用：Writing effective tools for agents — with agents
这篇文章讲的是一个很容易被低估的事实，给智能体做工具，不是在 API 外面再包一层壳，而是在重新设计“人和系统之间的契约”。工具名怎么起、参数怎么收、返回什么上下文、评测怎么做，这些看起来像边角料的部分，最后会直接决定智能体到底是靠谱，还是只会一本正经地乱按按钮。
原文要点
- 原文强调工具设计对象已从“人类开发者”扩展到“非确定性智能体调用方”。
- 有效工具不仅要定义参数，还要明确失败路径、上下文回传与可评测行为。
- 建议用真实任务回放与 transcript 分析反向优化工具定义与返回结构。
我的判断
我基本同意这篇文章的主线判断，但我最在意的不是“怎么把工具调得更强”，而是另一句潜台词，工具设计正在从“写给工程师看”转向“写给模型用”。这不是措辞变化，而是软件接口思维的一次硬切换。
过去写 API（程序接口），默认前提是调用方稳定、理性、可预期。一个函数拿到参数，就会按约定执行。最差的情况，无非是文档差一点，开发者多试几次也能摸清规则。但模型不是这种调用方。它会误解你的命名，会在缺信息时瞎猜，会因为返回结果太薄而重复调用，也会因为上下文被污染，在错误方向上越走越远。原文把这件事说得很直白，工具面对的不是 deterministic system（确定性系统，也就是输入固定时结果可预期），而是 non-deterministic agent（非确定性智能体，也就是同样任务也可能走出不同路径）。我觉得这句话应该直接钉在所有 agent 项目的墙上。
这也是为什么我很认同文中对评测的强调。很多团队做智能体工具，最大的问题不是工具写不出来，而是写完以后根本不知道它到底好不好用。于是大家只能凭体感调 prompt（给模型的指令文本），看到一次成功演示就误以为系统可用了。原文提出的办法很朴素，先做真实任务驱动的 evaluation（评测，用真实任务验证工具是否好用），再让模型自己分析 transcript（交互记录），继续反推工具描述、参数设计和返回结构哪里有问题。我喜欢这个思路，因为它把“智能体表现不稳定”从玄学拉回工程。
不过我也想补一句，很多人看到这类文章，最容易误学成另一种形式主义，开始疯狂堆描述、堆示例、堆字段，以为只要把 schema（参数结构定义）写得足够细，模型就会更听话。未必。给模型看的文档，不是越长越好，而是越可判别越好。名字是否清楚，边界是否明确，失败时返回什么，成功时最关键的上下文是什么，这些比一大段礼貌说明重要得多。模型不是在读产品白皮书，它是在几秒钟里做动作选择。写得啰嗦，只会把真正重要的约束淹掉。
所以这篇文章最有价值的地方，在我看来不是几条具体技巧，而是它逼人承认一个现实，工具本身就是 prompt 的一部分。你以为自己在设计接口，其实你也在设计模型的注意力。一个名字含混的工具，会把模型推向错误假设。一个返回空洞结果的工具，会诱导模型二次试探。一个分页、筛选、错误提示都模模糊糊的工具，最后消耗掉的不只是 token（模型处理上下文的消耗单位），更是系统对任务方向的控制力。
如果再往前推一步，我甚至觉得很多 agent 产品的竞争力，以后未必先输在模型层，而是先输在工具层。模型差一点，也许还能靠策略补；工具歪了，整个系统会从地基开始偏。你会看到它“很忙”，但那只是高频错误地忙。
结论很简单，这篇值得读，尤其适合那些已经开始接工具、却还把接口设计当成普通后端工作的团队。它提醒我们，别再把工具当成智能体外面的附件了。工具不是外设，工具就是智能体认知的一部分。谁先把这件事想明白，谁的 agent 才有机会从 demo 变成真正能交付结果的系统。
保留意见
工具设计改进可以显著提升稳定性，但它并不能单独解决模型能力边界、数据时效性和策略错误这三类问题。将“工具可用”误读为“系统可靠”仍是常见风险。