为什么这么多智能体工具只是1:1的API封装？

我花了很多时间研究调用CRM、日历、工单系统以及类似API的智能体。我不断看到，模型因为工具设计方式导致的问题而受到指责。假设智能体需要在CRM中保存联系人。如果你给它search_contact、create_contact和update_contact这些工具，它必须先搜索、解释结果、选择下一个工具，再构建另一个请求。这看起来很灵活，但你却把一个普通的if/else分支推给了系统中确定性最差的部分。一个upsert_contact工具要更可靠，因为搜索/创建/更新逻辑留在了代码里。我开始在其他地方也使用同样的规则：传递你已经掌握的信息，比如当前用户、工作区ID，不要让智能体每次都自己去获取。工具只返回智能体需要的字段，而不是提供商的整个响应对象。在工具代码中，在输入到达外部API之前进行校验。返回结构化错误，而不是通用的500错误。只有在工具与当前工作流相关时才提供它们。面向编码的智能体或内部工具仍然适合端点形态的工具，因为在那里广度很重要，而且有人员在监督。对于面向客户、执行真实操作的智能体，我更倾向于暴露更少的任务形态工具。你们在生产环境中使用的是宽泛的、提供商形态的工具，还是最终把它们压缩成了更小的、任务专用的工具？