Function Calling让 LLM 拥有双手基于 Lion-1209/AgentStudy 仓库对应代码见stage1-fundamentals/task1.2_tool_use.py和API_REFERENCE.md为什么需要 Function Calling上一篇我们用正则解析 LLM 的文本输出来获取工具调用信息。这种方式脆弱且不可靠。Function Calling 是 LLM 提供商原生支持的结构化工具调用机制定义工具SchemaLLM自动选择工具返回结构化工具调用执行工具把结果送回LLM核心优势LLM 原生理解工具接口不需要你解析自由文本。完整流程1. 你定义工具函数名 描述 参数 Schema 2. 你把工具定义和用户问题一起发给 LLM 3. LLM 返回结构化工具调用不是文本是 JSON 4. 你执行工具拿到结果 5. 把结果作为 tool 消息送回 LLM 6. LLM 生成最终回答tool_choice 四种模式速查模式值含义适用场景自动autoLLM 自己决定是否调用工具通用 Agent禁止none强制纯文本回复不调用工具纯对话场景必须required必须调用至少一个工具强制走工具流程指定{type: function, ...}强制调用指定工具路由到固定工具工具定义的三个关键要素{name:get_weather,description:获取城市天气,parameters:{type:object,properties:{city:{type:string,description:城市名如北京}},required:[city]}}描述写作技巧想象你在给一个聪明但不了解上下文的外包人员写任务说明。越具体LLM 选对工具的概率越高。tool_call_id为什么必须关联# 一条工具调用请求和它的响应必须通过 id 关联messages.append({role:assistant,content:None,tool_calls:[{id:call_abc123,...}]})messages.append({role:tool,tool_call_id:call_abc123,# 必须对应content:北京: 晴天 25°C})不关联会怎样LLM 不知道哪个结果对应哪个调用对话上下文会乱。Function Calling vs 正则解析维度正则解析文本Function Calling可靠性低LLM 输出格式变化就会失败高LLM 原生支持结构化输出解析难度需要写复杂的正则直接读取结构化字段错误处理难以区分没调用和调用失败有明确的 finish_reason 区分性能差好结论能用 Function Calling 就不要正则解析。这是可观测性的第一步——用可靠机制替代脆弱机制。学习检查清单能说清楚 Function Calling 和文本解析的本质区别吗tool_call_id 为什么不关联会出问题tool_choice 的 4 种模式分别用在什么场景知道怎么写好工具描述吗延伸阅读 完整代码stage1-fundamentals/task1.2_tool_use.py API 参考API_REFERENCE.md第 4 节️ 上一篇[02] ReAct 循环Agent 的思考引擎️ 下一篇[04] 50 行代码实现最小 Agent