大语言模型的本质是根据上下文预测下一个 token，那它凭什么能读文件、跑命令、改代码？答案是工具调用机制——模型自己不动手，它只生成"我想调用什么工具、什么参数"的结构化请求，真正执行的是外部程序。本文从历史演进讲到三家协议差异，再讲工程落地的边界。
原生支持出现之前：约定文本格式
早期做法全靠提示词约定：告诉模型"需要查天气时输出 ACTION: get_weather("Beijing")"，应用层再用正则解析执行。能用，但三个毛病治不了——格式不可靠，模型时不时输出错工具名或畸形参数；解析成本高，容错逻辑全靠手写；行为不稳定，换个模型或改个措辞就变样。
2023 年 6 月 OpenAI 在 API 里推出原生函数调用，工具定义直接随请求下发，模型生成结构化调用信息。此后各家跟进，工具调用从"提示词工程"变成"API 能力"。
一次调用的完整闭环
四步：开发者定义工具（名称、描述、JSON Schema 参数约束）→ 模型结合用户输入决定是否调用、生成结构化请求 → 外部程序校验并执行 → 结果回传给模型生成最终回答。需要更多信息时模型继续发起新的调用，多轮循环就构成了智能体的骨架。
有个概念必须钉死：模型生成调用请求，不等于工具已被执行。执行永远是外部程序的事，个别平台的服务端托管工具只是特例，不改变机制本身。
三家协议：思路相同，格式不同
Function Calling 是通用机制，但没有统一协议。三家主流实现对比：
| 维度 | OpenAI | Anthropic | Gemini |
|---|---|---|---|
| 工具调用 | function_call | tool_use | functionCall |
| 调用参数 | arguments（JSON 字符串） | input（对象） | args（对象） |
| 执行结果 | function_call_output | tool_result | functionResponse |
两个容易踩的差异：OpenAI 的参数是 JSON 字符串，要先解析再用；Anthropic 的 input 直接是对象。而且同一家厂商的不同 API 格式也可能不一致——OpenAI 的 Chat Completions 用 tool_calls，Responses API 用 function_call。大量第三方服务声称兼容 OpenAI 格式，但高级特性（并行调用、严格模式）未必对齐，接入前逐项验证。
Schema 保证格式，不保证决策
参数符合 JSON Schema，只说明结构合法，不说明：选的工具对、理解的意图对、参数的语义对、工具能执行成功。用户随口说的地名被模型填成"Beijing"，格式无懈可击，但用户想的可能是另一个城市。严格模式（受约束解码）能提高结构可靠性，支持情况因接口而异。生产环境三件事不能省：参数校验、错误处理、权限控制。
和 MCP、Agent 框架的关系
三层各管一段：
- 工具调用机制：模型如何表达"我要做什么"；
- MCP 等集成协议：AI 应用如何标准化连接外部工具服务（MCP 还定义了资源与提示能力，不只是工具）；
- Agent 执行框架：谁维护循环、适配厂商、管理上下文、处理超时重试。
一个文件读取请求的完整链路：模型发起调用 → 执行框架解析 → MCP 客户端连到文件系统服务 → 读文件 → 结果回传。MCP 不是工具调用的替代品，两者在同一系统里协同；也不是所有工具都必须走 MCP，本地函数、HTTP API 直连同样成立。
框架层的关键设计是统一抽象：三家格式不同，用适配层把各家调用转成内部统一结构，工具执行层就不随模型替换而改动。注意适配不只是改字段名——流式输出、调用 ID 关联、并行调用的语义差异都要处理。
工程边界清单
- 工具描述写清"何时该调、何时不该调"，职责相邻的工具要划清边界，含糊描述会让模型乱选；
- 不信任模型生成的参数：路径合法性、用户权限、危险操作确认，逐项检查；
- 工具失败时把错误信息结构化回传，让模型调整重试而不是整链崩掉；
- 区分并行与顺序：两个无依赖查询并行跑，先读后写的按依赖串行；
- 给循环设上限：最大调用次数、运行时间、资源消耗；删文件、发消息这类高影响操作加人工确认。
一句话收束：机制让模型表达意图，执行环境负责把事做完。理解这条边界，智能体的各种框架和协议就都好懂了。
评论0