模型和 Agent 的分界线
模型可以描述怎样修改代码，但只有工具能真正读取文件、应用补丁、运行测试和操作浏览器。工具层因此是 Agent 从“会说”走向“会做”的分界线。
工具并不是一个函数名。对模型而言，工具的描述、参数 schema、返回结构、失败状态和示例共同构成接口。任何一项含糊，都可能表现为错误调用。
工具越多不一定越强
重叠工具会增加选择成本。例如同时提供多种文件搜索方式，却不说明适用条件，模型会在每一步重新猜。专用工具能提升效率，但必须有清楚的路由规则。
Pi 代表较小工具面，Oh My Pi 则大量使用 AST、LSP、调试器和浏览器等专用设备。两者没有绝对优劣，差别在于简单性和专业能力之间的权衡。
权限应该贴近动作
“保持安全”太抽象。真正可执行的规则应该说明：读取是否允许、写入范围在哪里、删除是否需要确认、网络请求能访问什么、外部消息能否发送、命令超时后如何处理。
高风险动作最好在工具层和 Prompt 层同时受控。工具层提供硬边界，Prompt 层帮助模型在调用前判断意图和影响。
结果验证是工具协议的一部分
命令返回退出码不等于功能正确，写入文件也不等于页面可用。可靠 Agent 会在动作后读取新状态：构建结果、测试输出、DOM、截图或外部系统回执。
这也是为什么 Coding Agent 的 Prompt 经常规定“修改后必须验证”。它不是礼仪，而是把开放式生成变成闭环控制。
评估一个工具设计的四个问题
接口是否让模型知道何时使用；权限是否限制在必要范围；失败是否返回可行动的信息；完成后是否有可核验状态。用这四个问题阅读 Agent 两两对比，比只数工具数量更有意义。