按理说，

一、从 Prompt 到 Function Calling：一次协议化的演进

"Act as" 时代的工具调用

在 ChatGPT 刚刚流行的 年初。工具调用完全靠 Prompt 工程实现。典型做法是 ReAct 风格：

你可以使用以下工具：
- search: 搜索网页
- calculator: 计算
再看使用格式，Thought:
Action的观点是。工具名
Action Input:
参数
Observation:
工具返回...
重复 ...
Final Answer: ...

至于使用者痛点，模型经常漏写字段、加引号、忘记闭合花括号；自由文本解析需要大量正则和纠错；话说回来，多轮调用容易"忘记协议"把 Thought 输出到生产环境。

OpenAI function_call 发布

OpenAI 在 -- 的 GPT-- / GPT--turbo- 更新中引入了 functions 参数与 function_call 返回字段。这是业界第一次把"工具调用"作为 API 一等公民：

• API 层 functions:
• 模型专门做了 SFT，把工具 schema 放在程序提示里输出固定为 {"name": ...,"arguments": "..."}
• - DevDay 升级为 tools/tool_calls,支持并行调用,旧字段保留兼容。其实，

User Pain Point: 需要在程序提示中手动插入 JSON Schema。导致维护成本高，对不同模型不兼容，需要额外适配。

演进三阶段

二、主流工具调用格式对照

tool_calls

从请求示例来看，

{
"model": "gpt-4o","messages":,"tools":,...
}

User Pain Point：要手动拼 JSON Schema； 若字段错误会导致完整流程失败； 对大型语言模型来说 token 使用量大。

tool_use / tool_result

CDF 的 content block 更接近"多模态消息序列"

{
role这方面。"assistant",content:
}
...
{"role":"user","content":}

User Pain Point：Claude 对 XML 标签要求严格，导致 SFT 时需额外工作；解析结果时需手工映射到 JSON，增加工程复杂度。

{
tools:
}
}
]
}
]}
...

User Pain Point：大小写敏感导致误差；SDK 自动转换虽方便，但若自行拼接会出现错误。