Function Calling / Tool Use★★
让模型不仅会说，还会做——Agent 的发动机
让 LLM 输出"该调用哪个函数、参数是什么"的结构化指令，由你的代码实际执行。
用 JSON Schema 描述一个工具：名字、做什么、需要什么参数。
auto / required / 指定特定工具——告诉模型这一轮怎么用工具。
一轮里同时调多个工具，缩短总耗时。
工具执行的输出，作为一条新消息回灌给模型。
把工具描述和实现解耦成标准协议，工具能跨 Agent 复用。
完整流程是:应用把用户问题和工具 schema 一起发给模型;模型判断是否需要工具,返回工具名和参数;应用执行真实函数并把结果再发回模型;模型基于工具结果组织最终回答。模型负责决策和参数生成,应用负责真正执行和安全控制。
- +工具参数必须做服务端校验,不能因为是模型生成的就默认可信
- +工具结果要作为新的上下文回传给模型,否则模型不知道执行结果
- +一次任务可能经历多轮工具调用,需要有超时、重试和最大步数限制
模型做的是选择工具和生成结构化参数,本质上是在输出一个可被程序解析的调用意图。真正访问数据库、发 HTTP 请求、执行 Shell 或写文件的是你的应用代码。
- +这也是为什么工具权限必须在应用层控制,不能交给模型自己决定边界
- +函数返回值最好简洁明确,避免把大量无关日志重新塞回上下文
- +把模型调用意图和程序执行结果分开记录,更方便审计和排障
工具描述会直接影响模型是否选对工具、什么时候调用、参数怎么填。好的 description 要说明工具能做什么、不能做什么、参数含义和典型使用时机,差的描述会导致误调用或漏调用。
- +工具名和字段名要语义清楚,不要让模型猜缩写或内部黑话
- +description 里可以写边界条件,比如"仅查询订单状态,不能退款"
- +多个工具能力重叠时,描述里要明确优先级和差异,减少工具选择摇摆
Function Calling 解决的是一次应用内怎么让模型调用工具;MCP 更像是工具和上下文的标准接入协议。它让不同客户端可以用统一方式连接文件、数据库、浏览器、GitHub 等能力,减少每个应用都重写一套工具适配。
- +MCP 的价值在生态和标准化,不是替代模型本身的工具调用能力
- +直接写 Function Calling 更轻量,适合少量固定工具;MCP 更适合工具多、来源多、要复用的场景
- +即使用 MCP,权限、审计和危险操作确认仍然要在宿主应用里做
好的 Tool Schema 要让模型容易填对,也让程序容易校验。字段要少而清晰,类型要具体,必填和可选要明确,枚举值能收敛就不要用自由文本。
- +不要把多个动作塞进一个万能工具,否则参数会膨胀且难以授权
- +金额、时间、地区、ID 等字段要明确格式,避免模型生成歧义值
- +Schema 设计完要用真实问题压测,看模型是否稳定选择并填对参数
涉及实时数据、私有数据、权限操作或必须可验证的事实时,应该强制或强烈引导模型调用工具。普通解释、总结、改写这类模型本身能完成的任务,可以让它自己判断是否需要工具。
- +在 Anthropic 场景里可结合 `tool_choice` 控制自动选择、指定工具或禁止工具
- +使用 `claude-sonnet-4-6` 这类具备较强工具推理能力的模型时,仍要给出清晰工具边界
- +强制工具能提高可靠性,但也会增加延迟、成本和错误处理复杂度
Tool Result 要返回完成任务所需的最小事实,不要把原始大对象、敏感字段和无关日志全丢给模型。返回前最好做结构化、脱敏和错误归一化,让模型能稳定理解成功、失败和下一步。
- +错误结果也要回传清楚,例如权限不足、记录不存在、超时,不要只给一段堆栈
- +外部工具返回内容可能被注入恶意指令,要当作数据而不是高优先级指令
- +关键工具结果建议落日志,便于复盘模型为什么做出某个回答