大模型很聪明。

但默认情况下，它被关在文本世界里。

它不知道今天的库存。它不知道用户订单状态。它不能查数据库。也不能直接调用企业内部 API。

工具使用，就是把大模型接到真实系统上。

有了工具，Agent 不再只是回答问题。它可以查、可以算、可以检索、可以调用接口，也可以在安全边界内执行动作。

一、什么是工具使用？

工具使用，也叫函数调用。

它的核心很简单：把一个外部能力描述给模型，让模型在需要时生成结构化调用请求。

真正执行工具的，不是模型。

而是你的业务系统。

模型只负责三件事：

• 判断是否需要工具。

• 选择应该调用哪个工具。

• 生成这个工具需要的参数。

编排层负责后面的事：参数校验、权限判断、调用接口、处理异常、记录日志，再把结果回填给模型。

这就是工具型 Agent 的底层逻辑。

二、为什么 Agent 必须会用工具？

因为大模型有天然边界。

• 知识有边界：训练数据不等于实时世界。

• 上下文有边界：用户公司的私有数据不在模型里。

• 能力有边界：模型不适合做精确计算、真实下单、数据库更新。

• 责任有边界：高风险动作必须经过系统权限和人工确认。

所以，生产级 Agent 不能只靠模型。

模型负责理解和决策。工具负责获取事实和执行动作。

这也是很多 Agent 项目从“看起来能聊”，走向“真正能用”的分水岭。

三、工具调用的标准流程

一次完整的工具调用，通常不是一次请求结束。

它更像一个闭环：模型先判断要不要调工具，业务系统执行工具，模型再基于工具结果组织最终答案。

从工程角度看，这个流程至少包含六步：

• 用户提出任务。

• 模型结合工具描述，判断是否需要调用工具。

• 模型输出结构化工具调用请求。

• 业务编排层校验参数和权限。

• 工具执行，返回结构化结果。

• 模型读取结果，生成最终回复。

注意最后一句：工具结果要回填给模型。

否则模型不知道工具执行发生了什么，也就无法给出可靠回答。

四、一个好工具，要像 API 文档一样清楚

工具不是随便写一个函数就完事。

它要有清晰契约。

一个可上线的工具，至少要定义清楚这些内容：

• name：工具名称，稳定、短、语义明确。

• description：工具用途，说明什么时候用、什么时候不用。

• input_schema：入参结构，字段类型、必填项、枚举值、边界条件。

• permission：权限边界，谁能调、能查什么、能改什么。

• timeout / retry：超时、重试、熔断和降级策略。

• output_schema：返回结构，尽量短、准、结构化，最好带 trace_id。

工具描述越模糊，模型越容易乱用。

工具权限越开放，系统风险越大。

五、案例：订单查询 Agent

来看一个真实业务里很常见的场景。

用户问：我的订单 12345 到哪了？

普通聊天机器人可能会说：请稍后查看物流信息。

工具型 Agent 不会猜。

它会查。

这条链路里，模型只负责识别意图和组织回答。

真正关键的是业务系统：

• 先确认用户身份。

• 再确认订单是否属于该用户。

• 然后调用订单 API。

• 必要时继续调用物流 API。

• 最后返回可解释、可追踪的结果。

这就是工具调用在生产环境里的正确姿势。

不是让模型直接查库。

而是让模型通过受控工具访问业务能力。

六、源码级看：工具调用其实是 Agent Loop

源码层面，不要把工具调用想复杂。

它本质上就是一个循环。

这个循环里有几个关键组件：

• ToolRegistry：工具注册表，负责保存可用工具。

• ToolSchema：工具参数协议，告诉模型应该传什么。

• ToolExecutor：工具执行器，真正调用业务函数或 API。

• PolicyGuard：策略和权限层，负责鉴权、限流、危险动作拦截。

• Observation：工具返回结果，重新放回模型上下文。

• TraceLog：轨迹日志，记录每次工具调用的完整链路。

很多人写 Agent 出问题，不是模型不会。

而是这几个工程组件没做好。

七、什么时候应该用工具？什么时候不要用？

不是所有问题都要调用工具。

能直接回答的稳定知识，不要强行查库。

需要真实数据、私有数据、精确计算、业务动作时，才应该用工具。

• 适合用工具：查订单、查库存、查天气、查股价、查数据库、做计算、跑代码、发通知。

• 不适合用工具：概念解释、写普通说明、简单闲聊、没有权限的操作、高风险不可控动作。

工具调用越多，成本越高，链路越复杂，风险也越高。

生产系统里要追求“该用才用”。

八、工具使用最容易踩的坑

• 工具太多：模型不知道该选哪个。

• 描述太短：模型不知道什么时候该用。

• 参数不校验：模型填错字段也直接执行。

• 结果太长：把整段 JSON 或日志塞回模型，浪费上下文。

• 没有权限层：用户可能越权查询别人的数据。

• 没有超时：一个慢接口拖垮整条 Agent 链路。

• 没有审计：出问题后不知道模型调了什么、为什么调。

• 危险动作无确认：退款、删除、发邮件这类操作必须人工确认。

九、总结

工具使用，是 Agent 从“聊天”走向“执行”的关键一步。

没有工具，大模型只是一个聪明的文本生成器。

有了工具，它才有机会变成能处理真实业务的智能体。

但工具越强，边界越重要。

工具使用不是简单地给模型接 API。

它是一套完整工程链路：工具定义、参数校验、权限控制、执行器、异常处理、结果回填、轨迹日志。

一句话：让模型做判断，让系统做执行。

这才是工具型 Agent 能上线的核心。

---

内容来源：智能体设计模式：工具使用 Tool Use 让 Agent 从“会说”变成“会做”：功能变化与行业影响解析_热闻岛