# 智能体工具设计：名称清楚，还不够 从业务语义、输入约束、权限和错误反馈设计 AI 工具，使智能体更准确地选择并调用。 要点：工具需要说明它解决什么问题、要求哪些输入、会产生什么影响，以及失败后如何处理。企业智能体的工具设计，应减少含混动作与重叠职责。工具越容易被正确理解，执行越容易被核对。 ![在原型工作台上选择工具并检查部件（AI概念配图）](/images/unique-scenes/tools-prototype.png) ## 一个工具应表达一个可以辨认的业务意图 “处理客户”这样的名称过于宽泛，查询资料、更新联系人和发送通知可能被混在一起。更清楚的工具边界能够让智能体判断何时使用，也让审核者理解动作的影响。 输入字段应使用业务含义明确的名称，说明单位、取值范围和必填条件。对于已有正式标识的对象，优先使用标识进行操作，避免仅凭相似名称选错客户或产品。 ## 查询与改变状态，应有不同要求 读取资料和修改业务记录的影响不同。工具目录可以明确标注动作性质，并在执行层校验身份、对象范围与必要确认。不能只在提示词里写“谨慎操作”，却让工具本身接受任意目标。 涉及多个步骤时，尽量让智能体先展示拟操作对象和关键参数，再进入对应执行流程。具体是否需要人工确认，应由业务授权决定，而不是每次凭模型语气判断。 ## 错误结果也属于工具说明的一部分 工具失败时，应提供能够区分原因的信息，例如对象不存在、参数不符或状态已经变化。含混的“失败”会诱使智能体盲目重试或猜测参数。 同时避免在错误信息中暴露无关敏感数据。对允许重试的情况给出明确规则，对不可继续的情况提供合理去向。工具返回值应便于程序校验，也便于人理解。 | 工具要素 | 需要明确的内容 | | --- | --- | | 意图 | 何时适用、何时不适用 | | 输入 | 标识、条件与范围 | | 影响 | 读取还是改变状态 | | 结果 | 成功证据与失败原因 | ## 用容易混淆的任务测试工具选择 测试集可以包含相似工具、缺失输入和不应执行的请求，观察智能体是否选对动作、是否会询问关键条件。只测试工具能够成功调用，还不足以说明工具目录设计合理。 未来工具数量增加时，清楚的职责比丰富的名称更重要。一个边界明确的小工具集，往往更容易维护，也更容易让业务人员理解系统实际拥有的能力。 ## 把查询客户与修改客户拆成工具 为每个工具写出输入、单位、影响和结果证据，使用相似名称与缺失字段测试选择是否正确。写入目标、授权与当前状态由执行层检查，工具文字说明不能替代实际校验。 ## 参考来源 - [Anthropic｜Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)：工作流、工具与智能体设计原则；不作为本站产品效果证据 - [MCP 官方文档｜协议介绍](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro)：AI 应用连接外部系统的协议定义 ## 让工具的意图可以核对 - 业务动作：名称与职责明确 - 执行条件：输入、身份与范围 - 结果证据：成功状态与失败去向 ![让工具的意图可以核对](/images/guides/diagrams/agent-tool-selection.svg) ## 继续阅读 - [MCP 能给企业 AI 带来什么？连接能力与业务权限分开看](/guides/mcp-business-tools) - [AI 输出要进入业务系统，先把字段与校验说明白](/guides/structured-output) - [AI 工作流的人工审核，放在哪里才有效？](/guides/human-approval) 明确授权、处理位置与双方责任；部署、接口、定制及代运维另列技术实施。 下一步：[核对数据与合作边界](/data-boundary) 原文：/guides/agent-tool-selection 内容版本：guide:agent-tool-selection:v1 [结合企业情况咨询](/intake?source=%2Fguides%2Fagent-tool-selection&articleId=guide%3Aagent-tool-selection&versionId=guide%3Aagent-tool-selection%3Av1)