谈到 Agent Tool，我之前的理解一直停留在：Tool 就是定义一个函数，把函数描述交给大模型，大模型需要时生成参数，程序负责执行。
这个解释没有错，但它只描述了最短的调用路径。真实业务里的 Tool 系统还要回答更多问题：模型为什么就能找到正确的工具？调用前如何确认身份和权限？多个工具如何组成一项完整任务？请求超时后能不能重试？如何判断最后完成的是用户任务，而不只是某个接口调用？
这些问题无法靠增加几个函数解决。
本文先抛开 Function Calling、MCP 和具体代码，只从业务逻辑出发，讨论 Tool 系统为什么存在、负责什么，以及怎样判断一套 Tool 能否进入真实业务。
文中的退款流程只是用于说明问题的假设案例，不是某个实际项目的实现记录。
一、Tool 系统为什么存在
LLM 的核心能力是根据上下文生成内容。它可以理解模糊语言、判断用户意图、规划下一步，也可以根据新的信息调整方案，但它无法天然知道企业里的实时数据，更不能直接改变外部世界。
举个例子，用户说“帮我看看订单为什么还没到”，模型并不知道这个用户有哪些订单；用户说“帮我退掉昨天买的耳机”，模型也不能凭空创建退款申请。
一个可以真正完成的业务任务，通常包含四个环节：获得事实 → 作出判断 → 执行动作 → 验证结果
LLM 只能覆盖其中一部分。完整分工更接近下面这样：
| 参与者 | 主要责任 | 不应该承担的责任 |
|---|---|---|
| LLM | 理解意图、消除歧义、选择下一步、组织表达 | 决定权限、计算真实金额、凭空生成业务事实 |
| Tool | 获取数据、执行计算、调用外部系统、修改业务状态 | 自行理解用户最终目标、隐藏重要风险 |
| 业务系统 | 提供真实数据、业务规则、事务和最终状态 | 把内部复杂度全部暴露给模型 |
| Tool System | 管理工具发现、调用、权限、风险、异常和评测 | 代替业务系统成为事实来源 |
因此，Tool 的价值不只是“让模型能调用函数”，而是让 Agent 在受控条件下获取事实并执行行动。
没有 Tool，Agent 只能用 LLM 思考；接入 Tool，Agent 才可能完成任务。
二、API、Tool、Tool Set 和 Tool System
理解 Tool 系统之前，需要先把几个相近概念分开。
API：系统提供的技术接口
API 通常面向开发人员或其他程序，表达的是底层系统可以怎样被访问。例如：
查询订单记录、查询支付记录、写入售后表、修改订单状态
这些接口往往和内部服务、数据库结构以及技术边界保持一致。
Tool：面向 Agent 的业务动作
Tool 应该表达一个边界明确的业务能力，例如：
查询可退款商品、计算退款方案、创建退款申请、查询退款进度
API 关注“系统怎么操作”，Tool 更关注“Agent 可以完成什么动作”。一个 Tool 背后可以调用一个 API，也可以编排多个服务。
如果把大量底层 API 原样交给 LLM，LLM 就需要理解公司的内部数据结构，还要自己保证跨服务的一致性。LLM 漏掉一个步骤，业务状态就可能不完整。
所以，Tool 不是 API 的简单改名，而是一次面向 Agent 的业务能力重新抽象。
Tool Set：完成一类任务所需的能力集合
单个 Tool 很少能完成完整任务。以售后场景为例，一组工具可能包含：
查询订单、查询物流、检查售后资格、创建退款申请、创建补发申请、查询处理进度、转人工客服
这组能力能否闭环，比工具数量多少更重要。
Tool System：管理能力完整生命周期的系统
Tool System 不只是保存工具列表。它管理的是：
- 需要建设哪些业务能力
- 工具怎样描述、注册、被发现和下线
- 模型怎样选择工具并生成参数
- 调用前怎样完成校验、鉴权和确认
- 执行中怎样处理超时、并发和资源限制
- 执行后怎样反馈、恢复、审计和评测
- 工具升级后怎样控制兼容性和影响范围
四个概念可以压缩成：
- API：底层系统接口
- Tool：Agent 可使用的业务动作
- Tool Set：完成一类任务的能力集合
- Tool System：这些能力的设计、执行和治理体系
三、Tool 系统怎样完成一次业务任务
一次 Tool 调用并不是从“模型生成函数名”开始，也不是在“接口返回成功”时结束。完整过程可以分成六个阶段。
1. 理解任务 用户最终想完成什么？还缺哪些信息？
2. 发现与选择能力 是否需要 Tool？需要哪个 Tool 或哪组 Tool？
3. 执行前治理 参数是否合法？用户是否有权操作？是否需要确认？
4. 执行业务动作 调用外部系统，控制超时、并发、次数和成本。
5. 处理与验证结果 是成功、明确失败，还是结果未知？业务状态是否真的改变？
6. 继续决策或结束 任务是否完成？需要继续调用、换方案、补偿还是转人工？模型发出的 Tool Call 只是一个行动提议。执行权仍然应该掌握在确定性系统里。
从职责上看，一套完整的 Tool 系统至少包含以下部分：
| 阶段 | 核心责任 | 缺失后的问题 |
|---|---|---|
| 能力建设 | 从用户任务中识别需要哪些 Tool | 工具很多，但无法完成真实任务 |
| 能力描述 | 告诉模型什么时候用、怎么用 | 选错、漏选或错误组合 |
| 输入契约 | 定义参数类型、范围和必填条件 | 参数不可控，错误进入业务系统 |
| 权限与风险 | 校验身份、资源权限和确认状态 | 越权或高风险误操作 |
| 执行管理 | 控制调用、超时、并发和资源 | 任务卡死、服务过载、成本失控 |
| 结果协议 | 返回稳定、可解释的执行状态 | 模型无法判断下一步 |
| 异常恢复 | 重试、状态查询、补偿和转人工 | 重复执行或任务中断 |
| 可观测与审计 | 记录调用链、耗时、结果和责任主体 | 无法排查、追责和改进 |
| 评测与迭代 | 衡量选择、执行和任务结果 | 只能凭感觉判断系统效果 |
这些是系统必须承担的责任，但不代表每项责任都必须对应一个独立服务。
四、设计 Tool 时先拆用户任务
设计 Tool 最容易走偏的方式，是先翻接口文档，然后思考哪些 API 可以包装。
更合理的顺序是：先还原用户任务，再从任务中提取业务动作。
以“帮我退掉有杂音的耳机”为假设案例，可以依次拆成四类问题。
1. 需要获得哪些事实
- 当前用户有哪些相关订单？
- 用户说的是哪一件耳机？
- 商品是否已经签收？
- 是否已经存在售后申请？
2. 需要作出哪些判断
- 用户描述对应哪个商品，是否还需要澄清？
- 商品是否符合退款规则？
- 应该退款、换货、维修还是转人工？
- 是否需要补充图片等证明材料？
这里还要继续区分判断主体。识别“有杂音”属于质量问题，可以由 LLM 辅助理解；退款期限、退款金额、是否允许售后，必须由确定性业务规则判断。
3. 需要执行哪些动作
- 生成并展示退款方案
- 请求用户确认
- 创建退款申请
- 必要时预约退货物流
4. 如何验证任务结果
- 是否获得了真实退款单号？
- 退款金额是否与预览一致？
- 当前退款状态是什么？
- 用户下一步需要做什么？
只有把事实、判断、行动和验证拆清楚，才能推导出真正需要的 Tool Set。
五、怎样确定单个 Tool 的边界
Tool 太小，Agent 就要编排大量技术步骤。调用次数、延迟和失败概率会上升，模型也被迫理解企业内部实现。
Tool 太大，又会把过多业务决策藏在一个黑盒里。参数越来越复杂，权限范围越来越模糊，失败后也难以定位具体原因。
一个相对合理的 Tool，通常对应一个：
可描述、可授权、可执行、可验证的业务动作。
可以用五个问题检查粒度：
- 能否用一句业务语言描述它？
- 执行成功后是否有明确、可验证的结果？
- 是否拥有相对独立的权限边界？
- 失败后能否定位是哪项业务动作失败？
- 是否能够被其他任务复用？
边界确定后，还要为 Tool 建立完整的业务契约。
| 设计维度 | 需要回答的问题 |
|---|---|
| 业务目标 | 它解决用户任务中的哪一步？ |
| 使用条件 | 什么时候应该调用，什么时候不应该调用？ |
| 前置条件 | 执行前必须已经具备哪些事实和状态？ |
| 输入 | 哪些信息来自用户，哪些必须由系统生成或查询？ |
| 输出 | 成功后返回什么可验证结果？失败后返回什么状态？ |
| 副作用 | 是否会修改数据、发送消息、产生费用或影响他人？ |
| 权限 | 谁可以代表谁，对哪个资源执行这项动作？ |
| 确认 | 什么条件下必须获得用户或审批人的明确确认？ |
| 恢复 | 是否可以重试、撤销、补偿或转人工？ |
| 评测 | 如何证明它被正确选择、正确执行并产生业务价值？ |
六、多 Tool 任务由 Agent 还是 Workflow 负责
一项任务往往需要调用多个 Tool，但这不意味着所有步骤都应该交给模型自由决定。
如果流程固定、规则清楚、出错代价高，更适合用 Workflow 固定主干。例如退款可以规定：
查询订单 → 检查资格 → 生成方案 → 用户确认 → 创建退款 → 验证状态
LLM 可以负责识别用户说的是哪个商品、为什么退款，以及信息不足时怎样追问；但资格校验、金额计算、确认点和状态流转应由确定性流程控制。
如果下一步确实依赖开放环境和动态信息，才需要让 Agent 自主选择。例如开发者 Agent 在陌生代码库中排查问题，很难提前写死它应该先搜索文件、读取日志还是执行测试。
真实产品通常采用混合方式：
LLM 处理模糊性，Workflow 控制确定性主干，Tool 提供可执行能力，规则系统守住业务边界。
这比简单讨论“是否使用 Agent”更接近实际系统设计。
七、异常不是一种状态
产品级 Tool 不能只返回“成功”或“失败”。不同异常对应不同的下一步动作。
| 状态 | 示例 | 应对方式 |
|---|---|---|
| 信息不足 | 不知道用户指哪笔订单 | 向用户澄清 |
| 参数非法 | 商品 ID 格式错误 | 修正参数，不执行 |
| 业务拒绝 | 超过退款期限 | 解释规则或提供替代方案 |
| 权限不足 | 操作了其他用户的订单 | 拒绝并记录审计 |
| 等待确认 | 即将退款较大金额 | 等待明确确认 |
| 临时故障 | 下游服务短暂繁忙 | 在限制次数内重试 |
| 明确未执行 | 请求发出前失败 | 可以安全重试 |
| 执行结果未知 | 请求超时，不确定是否创建成功 | 先查询状态，禁止盲目重试 |
| 部分成功 | 退款成功但通知失败 | 保留主结果，单独补偿通知 |
| 无法自动恢复 | 特殊订单必须线下处理 | 转人工 |
其中最重要的区别是：
“执行失败”和“不知道是否执行成功”不是一回事。
假设退款系统已经成功创建申请，只是在返回响应时网络中断。调用方看到的是超时，但业务动作可能已经发生。如果直接重试，可能产生重复退款或重复售后单。
所以，有副作用的 Tool 通常需要一个唯一业务请求号。相同请求重复到达时，下游只能产生同一个业务结果。发生超时后，先根据请求号查询状态；只有明确没有执行时，才考虑重试。
对于查询操作，多执行一次通常风险较低；对于退款、支付、发送、删除等写操作，是否重试必须由业务语义决定。
异常处理因此不只是捕获程序错误，而是在定义任务怎样继续、结束或交给人工。
八、Tool 系统管理的是授权行动
表面上，Tool 系统管理的是接口；本质上，它管理的是：
在什么条件下，允许 AI 代表谁，对什么对象，执行什么动作。
每次重要行动都应该能够回答：
- 谁发起的？
- 代表谁执行？
- 操作哪个业务对象？
- 执行依据是什么？
- 是否获得确认？
- 最终结果是什么？
- 能否撤销或补偿？
高风险操作通常至少存在三层约束：
- 模型认为这项动作符合用户意图。
- 确定性业务规则允许执行。
- 用户或审批人在必要时明确确认。
LLM 的判断不能替代权限系统和业务规则。模型可以提议行动，但不能自行扩大授权范围。
九、如何评测 Tool 系统
工具接口成功返回，并不代表用户任务已经完成。Tool 评测需要从局部调用一直看到最终业务结果。
1. 能力覆盖
现有 Tool Set 是否足以完成目标场景？
- 任务覆盖率
- 因缺少 Tool 而失败的比例
- 必须转人工的任务比例
2. 工具选择
模型是否在正确的时机选择了正确的 Tool？
- 正确选择率
- 误调用率
- 漏调用率
- 多余调用率
3. 参数生成
模型提供的参数是否完整、合法并指向正确业务对象？
- 参数完整率
- 参数合法率
- 业务实体匹配率
- 虚构订单号、用户 ID 等实体的比例
4. 执行可靠性
Tool 和下游系统能否稳定完成动作？
- 执行成功率
- 超时率
- P50/P95 延迟
- 重复副作用率
- 可恢复失败比例
5. 任务结果
用户最终有没有完成任务？
- 任务完成率
- 人工接管率
- 平均完成轮数
- 平均 Tool 调用次数
- 单任务成本
- 高风险误操作率
6. 失败归因
指标只能说明系统变好或变坏，失败案例才能说明问题出在哪里。至少需要区分：
- 意图理解错误
- 工具选择错误
- 参数生成错误
- 权限或规则拒绝
- 外部系统失败
- 结果解释错误
- 工具集合不完整
- 流程设计错误
如果不做归因，优化很容易退化为反复修改 Prompt，却不知道真正的瓶颈在模型、工具还是业务流程。
十、哪些 Tool 能力可以迁移
具体 Tool 不一定能在不同公司之间直接复制。每家公司都有自己的数据模型、权限体系、审批制度和内部流程。
可以复用的能力大致分为三层。
通用能力模式
搜索与查询、创建与更新、发送与通知、上传与下载、预约与取消、审批与驳回、状态查询、撤销与补偿、转人工等模式，在很多行业都会重复出现。
行业能力模型
电商通常需要查询订单、查询物流、售后资格判断和创建售后；企业协同通常需要查找员工、查询忙闲、创建日程、发送通知和发起审批。
这些业务语义可以复用，但底层连接和规则需要适配。
Tool 系统方法论
最稳定、最值得长期积累的是：
- 从用户任务抽象 Tool 的方法。
- 输入输出、权限、确认和幂等规范。
- 异常分类、状态查询、补偿和人工兜底机制。
- Tool 级与完整任务级评测体系。
- 典型失败案例和对应的解决策略。
框架、模型和公司会变化，但这些设计问题会反复出现。这部分能力才是真正可迁移、可复利的资产。
十一、Demo 与产品的分界线
Demo 证明的是：模型能够调用一个工具。
产品需要证明的是：当信息不完整、模型可能选错、外部服务可能失败、用户权限不同、写操作可能重复时，系统依然能够完成任务，或者以可控方式失败。
两者的区别不主要在 Tool 数量，而在是否具备：
- 明确的使用边界和业务契约
- 参数校验、权限控制和确认点
- 状态管理、幂等、重试和补偿
- 超时、取消和人工接管
- 日志、Tracing 和审计
- 成本、延迟和调用次数限制
- 离线评测、线上监控和失败案例闭环
Agent 能否上线，不取决于它表现最好时能完成多复杂的任务，而取决于模型犯错、依赖失败和状态不确定时，系统能否守住边界。
结语
Tool 系统不是让模型看到更多 API，而是把企业已有能力重新整理成一组模型可理解、可选择、可执行、可约束、可恢复、可评测的业务行动。
它解决的核心问题可以概括为：
- 用户要完成什么任务？
- Agent 需要哪些事实和行动？
- 哪些交给 LLM，哪些必须由规则控制？
- AI 在什么条件下被允许执行？
- 执行失败或结果未知时怎样继续？
- 如何证明最终产生了业务价值？
把这几个问题想清楚，再去看 Function Calling、MCP、工具注册中心和执行器，技术组件才会拥有明确的位置。否则即使接入了很多工具，也可能只得到一个“会调接口”的 Demo，而不是能够交付真实任务的 Agent 系统。