上篇博客咱们把 Agent 的“核心闭环”给扒光了现在你已经知道它本质上是个while(想 - 做 - 看)的死循环。但这里面藏着一个极其关键的问题大模型怎么“做”你直接问普通的大模型“帮我查一下今天公司的销售额”它大概率会一本正经地胡说八道或者委屈巴巴地告诉你“我只是个语言模型无法访问实时数据。” 这就是典型的大模型困境——缸中之脑。它有超越绝大多数人的知识储备和推理能力但被死死锁在一个没有网线、没有键盘的黑盒子里。今天咱们要聊的工具调用Tool Use / Function Calling就是给这个“缸中之脑”接上网线装上机械臂。它是 Agent 打破知识与行动壁垒的唯一通道。一、 核心误区大模型其实“什么都没执行”一提到“工具调用”很多刚接触 Agent 开发的同学会产生一个致命的幻觉以为是大模型顺着网线爬过去悄悄执行了你的数据库查询。大错特错。大模型永远只输出文本它不执行任何物理动作。你可以把大模型想象成一个高智商、但全身瘫痪的**“老板”而你的业务代码宿主程序是四肢健全的“实习生”**。工具调用的真实交互逻辑是这样的实习生你的代码老板我这有三个工具发邮件、查天气、搜数据库。这是它们的使用说明书Tool Schema。老板LLM看了看用户的需求又看了看说明书。然后递给实习生一张**“工单JSON格式”**上面写着“去调查天气工具参数填杭州”。实习生你的代码拿到工单转头去调用真正的天气 API拿到“晴25度”的结果。实习生你的代码回头把结果报告给老板。老板再根据这个结果组织一段好听的话回复给用户。决策与执行的绝对分离是理解工具调用最核心的前提。模型负责“决定做什么What”你的代码负责“怎么做How”。二、 灵魂伪代码签一份“API 契约”为了让老板和实习生能无缝对接我们需要定义一份标准的契约。在代码里这就是tools数组。咱们用一段极简的伪代码来看看这个“装上手脚”的过程到底是怎么跑通的Python# 1. 给老板准备的“工具说明书” (JSON Schema 格式) # 这一步极其关键模型完全靠这份说明书来理解工具 tools [ { name: query_order_status, description: 根据订单号查询电商订单的实时物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 12位的纯数字订单号} }, required: [order_id] } } ] # 2. 用户发起请求带上工具集 user_input 帮我看看单号 123456789012 到哪了 response llm.chat(promptuser_input, available_toolstools) # 3. 核心分发逻辑你的宿主代码接管 if response.has_tool_call(): # 老板下发了工单 tool_name response.tool_call.name # 拿到工具名: query_order_status tool_args response.tool_call.arguments # 拿到参数: {order_id: 123456789012} print(f准备调用本地方法: {tool_name}参数: {tool_args}) # 4. 本地代码真正执行查询可能是调内部 RPC查 MySQL 等 # 这一步大模型根本不参与 real_data my_backend_service.query_order(tool_args[order_id]) # 5. 把拿到的真实数据塞回去让老板做最终总结 final_answer llm.chat(prompt这是工具返回的结果请回答用户, historyreal_data) print(final_answer)看到没有所谓的 Function Calling本质上就是强制要求 LLM按照你预设的 JSON 格式输出决策。三、 带着泥土气息的工程体感写 Tool 的三个巨坑官方文档里的 Demo 总是跑得很完美但在真实业务里把 Tool 玩好是一门玄学。以下三个坑几乎每个搞 Agent 架构的人都踩过坑一工具描述Description就是你的命很多人写 description 特别敷衍比如description: 搜索数据。 这就好比你给老板的说明书上写“能找东西”。当用户问“今天天气怎么样”时模型可能也会跑去调你的数据库搜索工具。工程解法把description当成高精度的 Prompt 来写。必须包含能做什么、不能做什么、在什么业务场景下使用。 比如用于查询 2024 年以后的内部员工财务报销记录不支持查询业务销售数据。描述越精准模型抓取工具的准确率越高。坑二参数幻觉幻读你定义了一个参数date要求是YYYY-MM-DD格式。结果大模型一上头给你传了个明天或者next Friday。你的代码一执行直接报Type Mismatch崩溃。 更可怕的是“参数瞎编”。用户根本没提供订单号模型为了“完成任务”强行捏造了一个order_id000000传给你。工程解法1. 在 parameters 的 description 里写死格式规约例如必须严格符合 YYYY-MM-DD 格式不要返回相对时间。 2. 宿主代码里必须做强校验。不要信任模型传过来的任何参数把它当成外部不可信用户的输入一样加上 try-catch 和正则校验。坑三上下文撑爆The Too Much Info Bomb你写了个fetch_webpage的工具让大模型去抓取一篇新闻。结果你的代码实诚地把整个 HTML 源码几万个 Token包含无数的 CSS 和 JS 标签当成 observation 扔回给了大模型。 只听“砰”的一声上下文窗口撑爆了或者模型因为长文本注意力涣散彻底忘了最初要干嘛。工程解法给工具套一层“滤网”。你的宿主代码在拿到结果后先用 BeautifulSoup 剔除 HTML 标签或者干脆起一个小模型做个 500 字的 Summary然后再把“脱水”后的精简信息喂给大模型。四、 进阶视界万物皆可 Tool理解了上面这些你的思路就可以彻底打开了。只要你能用代码封装成函数的逻辑全都可以变成 Agent 的手脚查数据库封装一个execute_sql()。物理世界交互封装一个turn_on_smart_light()去调物联网 API。执行代码封装一个python_interpreter()让它自己写代码解决数学题这也是数据分析 Agent 的底层逻辑。当“大模型的常识推理”遇上“无限扩展的外部 API”我们实际上在构建一种全新的软件交互范式Software 2.0。你不再需要为每一个功能画 UI 按钮大模型就是最强大的中央路由它会自主思考帮你调动整个数字世界的资源。