Agent 学习笔记 04：工具调用是 Agent 真正行动的起点

聊天模型只能根据上下文生成内容。它不知道实时天气、订单状态，也不能凭空计算一个复杂结果。Agent 之所以能够“做事”，是因为应用把外部能力包装成了模型可以选择的工具。

Tool Use 解决了什么问题

工具调用把一次请求拆成两个角色：模型负责判断是否需要动作、选择哪个工具和填写参数；程序负责真正执行函数，并把结果返回给模型。

用户：查一下北京明天的天气
模型：调用 weather(city="北京", date="明天")
程序：访问天气服务
工具：返回温度、降雨概率和风力
模型：根据结果组织回答

这里最重要的边界是：模型提出调用请求，程序决定是否允许执行。不能因为模型生成了一个工具名，就直接把任意字符串交给系统执行。

Function Calling 不是模型直接执行函数

Function Calling 通常会让模型返回结构化的工具名称和参数，例如：

{
  "name": "search_order",
  "arguments": {"order_id": "A1024"}
}

模型并没有访问数据库。应用需要根据工具白名单找到真实函数，校验参数、检查权限，执行后再把结果作为工具消息送回模型。

这条链路可以概括为：

模型建议 -> 工具白名单 -> 参数校验 -> 权限判断 -> 函数执行 -> 结果校验

工具结果也要结构化

工具返回自然语言当然可以，但机器更难判断“成功、为空、权限不足和系统异常”之间的区别。比如订单查询最好返回：

{"status":"not_found","order_id":"A1024","message":"订单不存在"}

Agent 可以据此决定继续询问订单号，还是向用户说明没有找到结果。结构化结果还能支持日志、重试和指标统计。

工具调用中的常见错误

第一，把工具当成万能执行器，允许模型传入任意脚本。第二，没有超时和重试上限，网络工具一挂，整个 Agent 一直等待。第三，没有区分只读工具和副作用工具，导致模型可以直接修改数据。

我会把工具按风险分级：查询类工具可自动执行；创建草稿或生成报表需要预览；发邮件、删数据、付款等动作需要二次确认或人工审批。

什么时候不需要 Tool Use

如果数据已经在当前上下文中，或者任务只是改写、总结和分类，就不必为了“像 Agent”而加入工具。工具调用会带来额外延迟、成本和失败点。

工具真正有价值的场景，是模型需要访问它自己不知道的事实，或者需要触发外部动作。

这章给我的启发

Tool Use 的核心不是让模型“会调用函数”，而是把语言决策接到一个受控的执行系统上。模型负责灵活，程序负责可信；模型负责提出下一步，工具层负责决定这一步能不能发生。

后面要讨论的自定义工具、工具描述和 Harness，本质上都是在完善这条边界。