最近我在整理某高校AI系统课程CS329Z的第四讲资料时，把“工具使用与函数调用”这个主题从头到尾重新捋了一遍。说实话，这一讲在我看来是整个AI应用开发里最容易被低估的章节——很多人觉得函数调用不就是让模型输出一段JSON吗，但真正落地过的人都知道，从“模型会输出参数”到“系统稳定地帮用户把事办了”，中间隔着一整条工程链路。这一讲的核心命题是：大语言模型如何从“只会生成文本”变成“真的能执行操作”。比如用户说“帮我把某城市明天的天气整理成出行建议”，模型不能只靠训练数据里的常识硬编，它需要知道该调用哪个天气接口、需要生成什么参数、拿到返回结果后该怎么组织语言。这就是工具使用与函数调用的价值——把模型的能力边界从“内部知识”扩展到“外部世界”。适合正在做AI应用、Agent系统，或者准备入门大模型应用开发的读者，这一讲值得反复看。为什么大模型需要“工具使用”——先从边界说起1.1 语言模型天生缺的三样东西我把这讲反复看了两遍，发现整讲都在回答一个朴素问题：模型什么都能聊，为什么做不了实事？根源在于三点。第一，知识有截止时间。模型训练时用的语料是过去的，你问它最新资讯、实时股价、明天的天气，它只能根据历史规律“编一个像样的答案”，这在很多场景下是不可接受的。第二，精确计算不擅长。它本质上是在做概率预测，不是真的在按数学规则演算，算个复杂点儿的表达式就容易出错。第三，它碰不到外部系统。就算模型知道该查数据库、该发请求、该调内部服务，它也没有“手”去操作。我习惯用一个类比：把大模型想成一个知识渊博但被绑在椅子上、没手机也没网络的专家。你问他任何知识性问题，他都能答得头头是道；但你说“帮我把这份报表发出去”，他就只能干瞪眼。工具使用就是给这位专家松绑，给他递手机、递电脑、递各种能实操的“外挂”。1.2 从“直接回答”到“动手执行”的范式变化早期大家解决这个问题的方式很笨：把外部信息直接塞进提示词，比如搜到的资料、查到的结果，让模型基于这些内容回答。这种方式叫检索增强，但它是一次性的、单向的，模型没有“按需再查”的能力。后来出现了插件机制，模型可以触发特定插件。但插件体系往往比较封闭，新增一个插件就要做大量适配。函数调用不太一样——它不关心工具内部是怎么实现的，只约定一个输入输出接口。模型说“我要调用get_weather，参数city=某城市”，应用层去执行这个函数，把结果拿回来。这就像给专家一本工具箱目录，他看目录就知道哪个工具能干什么、需要什么参数，具体工具内部是什么原理，不用他操心。这种范式转移的核心变化是：从“模型尽力猜答案”变成“模型决定找谁帮忙”。猜答案会错，但调用正确工具之后拿到的真实结果，基本不会错。1.3 第四讲在整个课程里的位置CS329Z这门课前面几讲讲了基础模型能力、上下文工程什么的，第四讲直接进入“行动层”。我的理解是，前面的内容都在讲模型怎么理解输入、怎么生成输出，这一讲开始让模型“动手做事情”。在整个智能体系统里，工具调用就是行动层的基础设施——没有它，后面讲的规划、多步推理都无从落地，因为规划完了你得能执行才行。这一讲的内容不深，但实操密度很高。它默认你懂基本的API调用，也默认你写过Python，但不会要求你有深度学习背景。跟着走一遍，基本能理解“一个带工具的Agent是怎么跑起来的”。函数调用的原理拆解：一次调用背后发生了什么2.1 工具Schema本质上是一份“使用说明书”函数调用最关键的概念不是“函数”，而是“工具描述”，也就是Schema。每个工具要用一段结构化描述说清楚三件事：这个工具叫什么、它是干什么的、调用它需要什么参数。我在这讲里看到最核心的示例就是一个天气查询工具的Schema，简化后长这样：{ "name": "get_weather", "description": "查询某城市在指定日期的天气情况，返回温度、降水概率、风力等", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如北京、上海" }, "date": { "type": "string", "description": "日期，格式为YYYY-MM-DD" } }, "required": ["city", "date"] } }你可能觉得这没啥技术含量，但实际用起来，这段描述的质量直接决定模型调用得准不准。我见过一个经典的坏例子：某个工具描述写得特别含糊，只写了一句“查询信息”，结果模型什么鸡毛蒜皮的小问题都调它。描述写得越具体，模型越能判断“什么时候该用、什么时候不该用”。这就像你给一个实习生安排任务，你说“帮我处理一下数据”，他肯定一脸懵；你说“把这份Excel里销售额大于一万的订单筛选出来，按日期排序输出”，他就知道怎么干了。2.2 一次函数调用的完整旅程这一讲把整个调用流程拆成了五个环节，我在项目里也是这么走的：第一步，用户输入自然语言请求。第二步，应用层把可用的工具列表以结构化形式放进请求里，模型看到“有哪些工具可用、各自什么能力”。第三步，模型内部判断：这个问题需要调用工具吗？如果需要，它会输出一个结构化的调用请求，比如“调用get_weather，city=某城市，date=明天”。注意，到这一步模型并没有真的执行任何东西，它只是“提出调用申请”。第四步，应用层接收到这个结构化请求，解析参数，真正去执行对应的函数，拿到真实返回值。第五步，把返回值拼回对话上下文，再次交给模型，模型基于真实结果生成面向用户的最终回答。这个流程里最反直觉的地方是：模型不是在“一步”里完成回答的，而是至少经历了两次生成。第一次生成决定“要不要调用、调用哪个、参数是什么”，第二次生成是基于调用结果的“收尾回答”。很多刚接触函数调用的人容易在这里犯迷糊——以为模型自己就把工具结果算出来了，其实模型只负责“说”，真正干活的是你的应用代码。2.3 训练侧和推理侧是怎么支撑这件事的有人可能会问：凭什么模型就能输出符合格式的调用请求？这讲也解释了，这是训练时喂了大量“带工具调用的对话样例”的结果。训练数据里包含这样的模式：用户提问→模型输出工具调用指令→系统返回工具结果→模型基于结果回答。模型见得多了，自然就学会“遇到这类问题，应该输出这种格式的调用”。推理侧也有约束。为了尽量保证模型输出的调用请求是合法JSON，应用层通常会在解析时加容错，甚至会做格式校验、参数校验。这也是函数调用比让模型“自由发挥”更可靠的原因——它不是靠模型自觉，而是靠协议约束。2.4 三种工具调用范式怎么选这讲对比了几种不同做法，我整理成一个表：范式优点缺点适用场景函数调用结构稳定、参数明确、易于校验工具定义需要提前写好生产环境、复杂业务系统JSON模式生成灵活，不需要预定义工具校验弱、容易输出无关字段快速原型、自由格式输出代码执行能力上限最高、能做任意计算安全风险大、资源管理复杂数据分析、科学计算、需要高自由度场景我的经验是：能用函数调用解决的就别用自由JSON，能用JSON就别直接让模型写代码执行。每多一层自由，就多一层不可控，这在生产环境里是致命的。一个最小可运行的“工具型Agent”实现3.1 准备三个有代表性的工具纸上谈兵没意思，我照着这讲的思路，用Python写了一个最小可运行的Demo。工具集选了三个有代表性的：天气查询、精确计算、数据库查询。为什么选这三个？因为它们分别对应模型最不擅长的三件事：时效性信息、精确运算、访问私有系统。# 工具1：天气查询（模拟） def get_weather(city: str, date: str) -> str: """模拟查询天气""" data = { ("某城市", "2025-06-01"): "晴，28°C，降水概率10%", ("某城市", "2025-06-02"): "多云，25°C，降水概率30%", } return data.get((city, date), "暂无数据") # 工具2：精确计算 def calculator(expression: str) -> str: """执行数学表达式计算""" import ast try: # 仅允许最基本的表达式，避免任意代码执行 tree = ast.parse(expression, mode="eval") return str(eval(compile(tree, "", "eval"), {"__builtins__": {}}, {})) except Exception as e: return f"计算错误: {e}" # 工具3：数据库查询（模拟只读） def query_database(sql: str) -> str: """执行只读SQL查询，返回结果集摘要""" # 实际项目中这里应连接真实数据库，并确保账号只读、超时控制 # 这里仅作模拟 sample = { "SELECT COUNT(*) FROM orders": "128393", "SELECT * FROM orders LIMIT 1": "[{order_id: 1, amount: 99.9, status: 'paid'}]", } return sample.get(sql.strip(), "查询无结果，请检查表名和语法")每个工具都用自己的函数实现了，并且我刻意在注释里标出了安全注意事项，比如计算器只允许eval模式其实还不够安全，真实生产应该用沙箱。这讲里也强调了，工具能不能安全执行，是工程侧的责任，不能指望模型自觉。3.2 构造工具描述并发送给模型接下来把这些工具转换成前面说的Schema格式，然后用一个抽象接口模拟请求模型。我故意没用具体的模型厂商SDK，是为了让你专注理解机制本身：tools = [ { "name": "get_weather", "description": "查询某城市指定日期的天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"}, "date": {"type": "string", "description": "日期YYYY-MM-DD"} }, "required": ["city", "date"] } }, { "name": "calculator", "description": "执行数学表达式计算，输入一个表达式字符串", "parameters": { "type": "object", "properties": { "expression": {"type": "string", "description": "数学表达式，如 (1.09**12)"} }, "required": ["expression"] } }, { "name": "query_database", "description": "执行只读SQL查询", "parameters": { "type": "object", "properties": { "sql": {"type": "string", "description": "只读SQL语句"} }, "required": ["sql"] } } ] def simulate_llm_with_tools(messages, tools): """模拟一个支持工具调用的LLM响应""" # 在真实项目中，这里调用模型API，并把tools传入 # 为了演示，我们用规则模拟模型决定调用哪个工具 user_request = messages[-1]["content"] if "天气" in user_request: return { "role": "assistant", "content": None, "tool_calls": [ { "name": "get_weather", "arguments": {"city": "某城市", "date": "2025-06-01"} } ] } if "计算" in user_request or "多少" in user_request: return { "role": "assistant", "content": None, "tool_calls": [ { "name": "calculator", "arguments": {"expression": "1.09 ** 12"} } ] } if "订单" in user_request or "数据库" in user_request: return { "role": "assistant", "content": None, "tool_calls": [ { "name": "query_database", "arguments": {"sql": "SELECT COUNT(*) FROM orders"} } ] } return {"role": "assistant", "content": "这个问题不需要调用工具，我可以直接回答。"}这段代码的核心是：模型输出中有个tool_calls字段，里面是它想要调用的工具和参数。真实模型也是这么设计的，只是内部决策基于概率而非规则。为了让你跑通理解，我用规则代替了模型判断。3.3 编排主循环：识别、执行、回填工具型Agent的核心是一个循环：拿到模型输出，如果有工具调用就执行，把结果回填，再交给模型。import json def run_agent(user_query): messages = [{"role": "user", "content": user_query}] max_rounds = 3 for _ in range(max_rounds): # 第一次请求：带工具列表 response = simulate_llm_with_tools(messages, tools) # 情形一：模型不再调用工具，直接回答 if not response.get("tool_calls"): return response["content"] # 情形二：模型请求调用工具 tool_results = [] for call in response["tool_calls"]: tool_name = call["name"] args = call["arguments"] if tool_name == "get_weather": result = get_weather(args["city"], args["date"]) elif tool_name == "calculator": result = calculator(args["expression"]) elif tool_name == "query_database": result = query_database(args["sql"]) else: result = f"未知工具: {tool_name}" # 把工具调用和结果都回填到消息里 messages.append({ "role": "assistant", "content": None, "tool_calls": [call] }) messages.append({ "role": "tool", "tool_call_id": tool_name, "content": str(result) }) tool_results.append(result) # 再次进入循环，让模型基于工具结果生成回答或继续调用 messages.append({"role": "user", "content": "请基于工具返回结果继续回答"}) return "已达到最大调用轮数，停止。" print(run_agent("帮我查一下某城市2025年6月1日的天气")) print(run_agent("计算1.09的12次方等于多少"))跑一下这几行代码就能看到完整链路。这个Demo麻雀虽小五脏俱全：有工具定义、有模型决策、有执行、有回填。真实生产里要替换的只是simulate_llm_with_tools这一部分——换成真正的模型API调用，其他框架思路完全复用。3.4 工程侧的几个关键参数这讲末尾提了三个工程参数，我在实际项目里也踩过，展开说一下。第一是轮数上限。模型可能陷入循环，比如工具返回错误后它反复重试，所以必须设置最大调用轮数，一般是3-5轮，超过就终止。第二是token预算。工具返回结果可能很大，比如数据库查询返回几千行，直接拼进上下文马上超限。要做截断、摘要，只回填前N行。第三是超时控制。单个工具执行可能很慢，尤其外部API，要给每个工具设置超时，整体也要有总超时，避免用户等半天没响应。三种高频实战场景拆解4.1 实时信息查询：内建知识靠不住的地方第一个场景最典型：天气查询。模型训练时不可能知道明天的天气，所以必须走工具。实际操作中你会发现一个有意思的现象：模型即使有工具可用，偶尔也会尝试“直接回答”。比如你问它“某城市今天气温多少”，它可能直接说“今天某城市气温约28度”，而不会先调工具。这是因为训练数据的惯性让它觉得“自己知道答案”。我在项目里解决这个问题有几个手段：一是在系统提示词里明确“涉及实时信息必须调用工具，禁止凭记忆回答”；二是如果工具返回空或失败，宁可告诉用户获取不到，也不要让模型编一个数字；三是给工具描述加“时效性声明”，例如“本工具返回最新实时数据”。这讲里强调的核心观点我特别认同：对于事实性问题，宁可有条件地拒绝，也不要让模型自信地胡编。因为用户一旦发现数据是假的，整个系统的信任就崩了。4.2 精确计算与代码执行器：别让模型当计算器第二个场景是精确计算。看起来很简单，但这是模型最典型的短板。我之前做过一个数学演示Demo，让模型直接回答“1.09的12次方”，它经常会算错，有时候答案是3.09，有时候是3.08，误差不大但就是不准。更麻烦的是，它自己算错的时候还特别自信。正确做法是给模型配一个计算器工具，或者更进一步，配一个代码执行器。模型负责把问题转成代码，比如1.09**12，再调用执行器算出来，结果精确且可复核。这讲对这种场景的建议是：能用工具就别让模型硬算，因为模型的价值在于理解和推理，不在于数值精确。不过代码执行器引入的安全风险也大——模型生成的代码不能直接放开跑，必须有沙箱、资源隔离、执行时间限制。如果只是简单运算，用我之前写的calculator那样做表达式白名单校验就够了。4.3 数据库查询与报表生成：NL2SQL的完整闭环第三个场景是数据库查询。这是我认为函数调用最核心的生产级应用之一，把用户的自然语言问题转成SQL，执行后返回结果，再生成报表。我在某个内部数据分析项目里就是这么做的，流程和这一讲几乎完全一致。用户问“上个月退货率最高的三个产品是什么”，模型会先判断需要查数据库，生成一条SQL，比如SELECT product_name, return_rate FROM monthly_returns WHERE month = '2025-05' ORDER BY return_rate DESC LIMIT 3，应用层执行这条SQL，把结果回填，模型再根据结果用自然语言回答，甚至生成一个表格。但这里有几个必须做的工程约束。第一，数据库账号必须是只读的，绝不能让模型生成的SQL能改数据。第二，所有查询必须在事务里跑，加上超时，防止模型生成了全表扫描这种恐怖查询。第三，对敏感字段要脱敏，比如用户手机号、身份证号，模型能看到数据不代表应该看到全部数据。第四，最好限制模型只能查特定的库和表，这可以在Schema层面就约束清楚。高频踩坑与排查技巧实录5.1 问题一：模型输出的JSON不合法这是我用函数调用以来遇到最频繁的问题。明明要求输出JSON，结果可能多了个逗号、注释没删干净、字符串引号错误。我的排查三步法：先看是不是模型版本的问题，有些模型对复杂工具定义格式支持不好；再看是不是上下文示范太少，在提示词里加一个正确示例往往见效最快；最后兜底方案是在代码里做容错解析，比如用宽松的解析逻辑，把代码块先剥离出来再转JSON。一个小技巧：给模型的工具示例不要太多，每个工具最多一两个，因为示例太多会挤占上下文空间，反而增加输出混乱概率。5.2 问题二：模型陷入工具调用死循环我遇到过一个经典场景：模型调用了一个工具，工具返回“参数错误”，模型看懂了，又原样调用了一次，还是“参数错误”，继续调用，一直循环到超时。原因是模型不知道“同样的错误应该换个方式处理”。解决手段有三个：设置最大轮数、对完全相同的调用做去重、连续两次工具执行失败就强制终止并让模型基于已有信息回答。核心原则是：工具调用必须有个“刹车机制”。5.3 问题三：参数幻觉，编造不存在的字段模型在调用工具时可能生成不存在的参数。比如数据库工具明明只有orders表，它却生成了SELECT * FROM users，看起来像模像样，实际一执行就报错。解决思路是：在工具Schema里尽量用枚举约束，比如在描述里写明“可用表：orders, products, customers”；在应用层做严格参数校验；当工具返回“表不存在”时，把可选表清单带回去，让模型基于真实信息重新生成。这一步非常关键，模型不擅长凭空猜出你系统里有什么，但很擅长在你给它清单之后做出正确选择。5.4 问题四：上下文被工具结果撑爆工具返回的数据量通常远超你想象。比如数据库查询，模型生成了一条不带LIMIT的SQL，结果返回10万行，直接塞进上下文，第二次模型请求大概率直接超过token上限。方案是统一的回填截断策略：默认只回填前10条或20条，并附上“如需更多数据请再次查询”。还可以让模型自己控制粒度：在工具描述里要求它必须写LIMIT，否则工具就报错。让工具自己有防御性，比事后截断更可靠。5.5 常见问题速查表症状原因解法JSON解析失败格式不规范、转义错误容错解析、提示词加示例反复调用同一工具模型陷入测试循环轮数上限、相同调用去重调用成功但结果不对参数幻觉、字段名错误Schema枚举约束、返回字段清单请求超时工具结果过大截断回填、强制LIMIT模型直接回答不调工具系统指令不明确强调实时/计算类问题必须调用工具5.6 安全边界：工具能调用不代表能随便调用这讲虽然没有大篇幅谈安全，但我在实际项目中体会很深。函数调用相当于把“手”交给了模型，这个手能摸到哪些东西，完全由你控制。最低要求是权限最小化：数据库只读、外部API白名单、删除操作一律禁止。更严格一点，敏感操作要加人工审批流程。我在某个项目里就做过一个“发邮件工具”，工具本身只负责生成邮件草稿，真正的发送动作必须人工确认。这个设计牺牲了一点自动化程度，但换来了非常高的安全边际。另外，工具返回的外部内容一律视为不可信数据，直接拼接给用户前要做清洗，防止意外注入。最后：我对函数调用方向的实际体会把这一讲的笔记整理完之后，我最大的感触是：工具使用能力决定了整个Agent系统的上限。模型本身的水平是底座，但底座再强，如果工具层定义混乱、调用过程不稳，最后效果一定拉胯。很多开发者在做Agent时，70%的badcase其实出在工具定义不清晰——描述模棱两可、参数约束缺失、返回格式混乱。把这些工程细节打磨好，效果往往比换一个更大的模型还要明显。另外我特别想提醒的是，做工具调用之前，先把可观测性做好。我在某项目里把工具调用链路全量打了日志，每个工具入参、出参、耗时都记录在案，后面定位问题简直是救命级的功能。模型这种非确定性系统，你没法靠“看代码猜行为”，必须靠日志回放。函数调用正在成为AI应用的一种标准基础设施，它不像大模型训练那么玄学，也不像前端交互那么琐碎，更像是在“给模型建造可靠的双手”。如果你正在规划自己的智能体应用，我建议把这一讲的机制彻底搞透——它值得你花一个下午亲手跑一遍，再花很长时间在真实场景里打磨。
最近我在整理某高校AI系统课程CS329Z的第四讲资料时，把“工具使用与函数调用”这个主题从头到尾重新捋了一遍。说实话，这一讲在我看来是整个AI应用开发里最容易被低估的章节——很多人觉得函数调用不就是让模型输出一段JSON吗，但真正落地过的人都知道，从“模型会输出参数”到“系统稳定地帮用户把事办了”，中间隔着一整条工程链路。这一讲的核心命题是：大语言模型如何从“只会生成文本”变成“真的能执行操作”。比如用户说“帮我把某城市明天的天气整理成出行建议”，模型不能只靠训练数据里的常识硬编，它需要知道该调用哪个天气接口、需要生成什么参数、拿到返回结果后该怎么组织语言。这就是工具使用与函数调用的价值——把模型的能力边界从“内部知识”扩展到“外部世界”。适合正在做AI应用、Agent系统，或者准备入门大模型应用开发的读者，这一讲值得反复看。为什么大模型需要“工具使用”——先从边界说起1.1 语言模型天生缺的三样东西我把这讲反复看了两遍，发现整讲都在回答一个朴素问题：模型什么都能聊，为什么做不了实事？根源在于三点。第一，知识有截止时间。模型训练时用的语料是过去的，你问它最新资讯、实时股价、明天的天气，它只能根据历史规律“编一个像样的答案”，这在很多场景下是不可接受的。第二，精确计算不擅长。它本质上是在做概率预测，不是真的在按数学规则演算，算个复杂点儿的表达式就容易出错。第三，它碰不到外部系统。就算模型知道该查数据库、该发请求、该调内部服务，它也没有“手”去操作。我习惯用一个类比：把大模型想成一个知识渊博但被绑在椅子上、没手机也没网络的专家。你问他任何知识性问题，他都能答得头头是道；但你说“帮我把这份报表发出去”，他就只能干瞪眼。工具使用就是给这位专家松绑，给他递手机、递电脑、递各种能实操的“外挂”。1.2 从“直接回答”到“动手执行”的范式变化早期大家解决这个问题的方式很笨：把外部信息直接塞进提示词，比如搜到的资料、查到的结果，让模型基于这些内容回答。这种方式叫检索增强，但它是一次性的、单向的，模型没有“按需再查”的能力。后来出现了插件机制，模型可以触发特定插件。但插件体系往往比较封闭，新增一个插件就要做大量适配。函数调用不太一样——它不关心工具内部是怎么实现的，只约定一个输入输出接口。模型说“我要调用get_weather，参数city=某城市”，应用层去执行这个函数，把结果拿回来。这就像给专家一本工具箱目录，他看目录就知道哪个工具能干什么、需要什么参数，具体工具内部是什么原理，不用他操心。这种范式转移的核心变化是：从“模型尽力猜答案”变成“模型决定找谁帮忙”。猜答案会错，但调用正确工具之后拿到的真实结果，基本不会错。1.3 第四讲在整个课程里的位置CS329Z这门课前面几讲讲了基础模型能力、上下文工程什么的，第四讲直接进入“行动层”。我的理解是，前面的内容都在讲模型怎么理解输入、怎么生成输出，这一讲开始让模型“动手做事情”。在整个智能体系统里，工具调用就是行动层的基础设施——没有它，后面讲的规划、多步推理都无从落地，因为规划完了你得能执行才行。这一讲的内容不深，但实操密度很高。它默认你懂基本的API调用，也默认你写过Python，但不会要求你有深度学习背景。跟着走一遍，基本能理解“一个带工具的Agent是怎么跑起来的”。函数调用的原理拆解：一次调用背后发生了什么2.1 工具Schema本质上是一份“使用说明书”函数调用最关键的概念不是“函数”，而是“工具描述”，也就是Schema。每个工具要用一段结构化描述说清楚三件事：这个工具叫什么、它是干什么的、调用它需要什么参数。我在这讲里看到最核心的示例就是一个天气查询工具的Schema，简化后长这样：{ "name": "get_weather", "description": "查询某城市在指定日期的天气情况，返回温度、降水概率、风力等", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如北京、上海" }, "date": { "type": "string", "description": "日期，格式为YYYY-MM-DD" } }, "required": ["city", "date"] } }你可能觉得这没啥技术含量，但实际用起来，这段描述的质量直接决定模型调用得准不准。我见过一个经典的坏例子：某个工具描述写得特别含糊，只写了一句“查询信息”，结果模型什么鸡毛蒜皮的小问题都调它。描述写得越具体，模型越能判断“什么时候该用、什么时候不该用”。这就像你给一个实习生安排任务，你说“帮我处理一下数据”，他肯定一脸懵；你说“把这份Excel里销售额大于一万的订单筛选出来，按日期排序输出”，他就知道怎么干了。2.2 一次函数调用的完整旅程这一讲把整个调用流程拆成了五个环节，我在项目里也是这么走的：第一步，用户输入自然语言请求。第二步，应用层把可用的工具列表以结构化形式放进请求里，模型看到“有哪些工具可用、各自什么能力”。第三步，模型内部判断：这个问题需要调用工具吗？如果需要，它会输出一个结构化的调用请求，比如“调用get_weather，city=某城市，date=明天”。注意，到这一步模型并没有真的执行任何东西，它只是“提出调用申请”。第四步，应用层接收到这个结构化请求，解析参数，真正去执行对应的函数，拿到真实返回值。第五步，把返回值拼回对话上下文，再次交给模型，模型基于真实结果生成面向用户的最终回答。这个流程里最反直觉的地方是：模型不是在“一步”里完成回答的，而是至少经历了两次生成。第一次生成决定“要不要调用、调用哪个、参数是什么”，第二次生成是基于调用结果的“收尾回答”。很多刚接触函数调用的人容易在这里犯迷糊——以为模型自己就把工具结果算出来了，其实模型只负责“说”，真正干活的是你的应用代码。2.3 训练侧和推理侧是怎么支撑这件事的有人可能会问：凭什么模型就能输出符合格式的调用请求？这讲也解释了，这是训练时喂了大量“带工具调用的对话样例”的结果。训练数据里包含这样的模式：用户提问→模型输出工具调用指令→系统返回工具结果→模型基于结果回答。模型见得多了，自然就学会“遇到这类问题，应该输出这种格式的调用”。推理侧也有约束。为了尽量保证模型输出的调用请求是合法JSON，应用层通常会在解析时加容错，甚至会做格式校验、参数校验。这也是函数调用比让模型“自由发挥”更可靠的原因——它不是靠模型自觉，而是靠协议约束。2.4 三种工具调用范式怎么选这讲对比了几种不同做法，我整理成一个表：范式优点缺点适用场景函数调用结构稳定、参数明确、易于校验工具定义需要提前写好生产环境、复杂业务系统JSON模式生成灵活，不需要预定义工具校验弱、容易输出无关字段快速原型、自由格式输出代码执行能力上限最高、能做任意计算安全风险大、资源管理复杂数据分析、科学计算、需要高自由度场景我的经验是：能用函数调用解决的就别用自由JSON，能用JSON就别直接让模型写代码执行。每多一层自由，就多一层不可控，这在生产环境里是致命的。一个最小可运行的“工具型Agent”实现3.1 准备三个有代表性的工具纸上谈兵没意思，我照着这讲的思路，用Python写了一个最小可运行的Demo。工具集选了三个有代表性的：天气查询、精确计算、数据库查询。为什么选这三个？因为它们分别对应模型最不擅长的三件事：时效性信息、精确运算、访问私有系统。# 工具1：天气查询（模拟） def get_weather(city: str, date: str) -> str: """模拟查询天气""" data = { ("某城市", "2025-06-01"): "晴，28°C，降水概率10%", ("某城市", "2025-06-02"): "多云，25°C，降水概率30%", } return data.get((city, date), "暂无数据") # 工具2：精确计算 def calculator(expression: str) -> str: """执行数学表达式计算""" import ast try: # 仅允许最基本的表达式，避免任意代码执行 tree = ast.parse(expression, mode="eval") return str(eval(compile(tree, "", "eval"), {"__builtins__": {}}, {})) except Exception as e: return f"计算错误: {e}" # 工具3：数据库查询（模拟只读） def query_database(sql: str) -> str: """执行只读SQL查询，返回结果集摘要""" # 实际项目中这里应连接真实数据库，并确保账号只读、超时控制 # 这里仅作模拟 sample = { "SELECT COUNT(*) FROM orders": "128393", "SELECT * FROM orders LIMIT 1": "[{order_id: 1, amount: 99.9, status: 'paid'}]", } return sample.get(sql.strip(), "查询无结果，请检查表名和语法")每个工具都用自己的函数实现了，并且我刻意在注释里标出了安全注意事项，比如计算器只允许eval模式其实还不够安全，真实生产应该用沙箱。这讲里也强调了，工具能不能安全执行，是工程侧的责任，不能指望模型自觉。3.2 构造工具描述并发送给模型接下来把这些工具转换成前面说的Schema格式，然后用一个抽象接口模拟请求模型。我故意没用具体的模型厂商SDK，是为了让你专注理解机制本身：tools = [ { "name": "get_weather", "description": "查询某城市指定日期的天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"}, "date": {"type": "string", "description": "日期YYYY-MM-DD"} }, "required": ["city", "date"] } }, { "name": "calculator", "description": "执行数学表达式计算，输入一个表达式字符串", "parameters": { "type": "object", "properties": { "expression": {"type": "string", "description": "数学表达式，如 (1.09**12)"} }, "required": ["expression"] } }, { "name": "query_database", "description": "执行只读SQL查询", "parameters": { "type": "object", "properties": { "sql": {"type": "string", "description": "只读SQL语句"} }, "required": ["sql"] } } ] def simulate_llm_with_tools(messages, tools): """模拟一个支持工具调用的LLM响应""" # 在真实项目中，这里调用模型API，并把tools传入 # 为了演示，我们用规则模拟模型决定调用哪个工具 user_request = messages[-1]["content"] if "天气" in user_request: return { "role": "assistant", "content": None, "tool_calls": [ { "name": "get_weather", "arguments": {"city": "某城市", "date": "2025-06-01"} } ] } if "计算" in user_request or "多少" in user_request: return { "role": "assistant", "content": None, "tool_calls": [ { "name": "calculator", "arguments": {"expression": "1.09 ** 12"} } ] } if "订单" in user_request or "数据库" in user_request: return { "role": "assistant", "content": None, "tool_calls": [ { "name": "query_database", "arguments": {"sql": "SELECT COUNT(*) FROM orders"} } ] } return {"role": "assistant", "content": "这个问题不需要调用工具，我可以直接回答。"}这段代码的核心是：模型输出中有个tool_calls字段，里面是它想要调用的工具和参数。真实模型也是这么设计的，只是内部决策基于概率而非规则。为了让你跑通理解，我用规则代替了模型判断。3.3 编排主循环：识别、执行、回填工具型Agent的核心是一个循环：拿到模型输出，如果有工具调用就执行，把结果回填，再交给模型。import json def run_agent(user_query): messages = [{"role": "user", "content": user_query}] max_rounds = 3 for _ in range(max_rounds): # 第一次请求：带工具列表 response = simulate_llm_with_tools(messages, tools) # 情形一：模型不再调用工具，直接回答 if not response.get("tool_calls"): return response["content"] # 情形二：模型请求调用工具 tool_results = [] for call in response["tool_calls"]: tool_name = call["name"] args = call["arguments"] if tool_name == "get_weather": result = get_weather(args["city"], args["date"]) elif tool_name == "calculator": result = calculator(args["expression"]) elif tool_name == "query_database": result = query_database(args["sql"]) else: result = f"未知工具: {tool_name}" # 把工具调用和结果都回填到消息里 messages.append({ "role": "assistant", "content": None, "tool_calls": [call] }) messages.append({ "role": "tool", "tool_call_id": tool_name, "content": str(result) }) tool_results.append(result) # 再次进入循环，让模型基于工具结果生成回答或继续调用 messages.append({"role": "user", "content": "请基于工具返回结果继续回答"}) return "已达到最大调用轮数，停止。" print(run_agent("帮我查一下某城市2025年6月1日的天气")) print(run_agent("计算1.09的12次方等于多少"))跑一下这几行代码就能看到完整链路。这个Demo麻雀虽小五脏俱全：有工具定义、有模型决策、有执行、有回填。真实生产里要替换的只是simulate_llm_with_tools这一部分——换成真正的模型API调用，其他框架思路完全复用。3.4 工程侧的几个关键参数这讲末尾提了三个工程参数，我在实际项目里也踩过，展开说一下。第一是轮数上限。模型可能陷入循环，比如工具返回错误后它反复重试，所以必须设置最大调用轮数，一般是3-5轮，超过就终止。第二是token预算。工具返回结果可能很大，比如数据库查询返回几千行，直接拼进上下文马上超限。要做截断、摘要，只回填前N行。第三是超时控制。单个工具执行可能很慢，尤其外部API，要给每个工具设置超时，整体也要有总超时，避免用户等半天没响应。三种高频实战场景拆解4.1 实时信息查询：内建知识靠不住的地方第一个场景最典型：天气查询。模型训练时不可能知道明天的天气，所以必须走工具。实际操作中你会发现一个有意思的现象：模型即使有工具可用，偶尔也会尝试“直接回答”。比如你问它“某城市今天气温多少”，它可能直接说“今天某城市气温约28度”，而不会先调工具。这是因为训练数据的惯性让它觉得“自己知道答案”。我在项目里解决这个问题有几个手段：一是在系统提示词里明确“涉及实时信息必须调用工具，禁止凭记忆回答”；二是如果工具返回空或失败，宁可告诉用户获取不到，也不要让模型编一个数字；三是给工具描述加“时效性声明”，例如“本工具返回最新实时数据”。这讲里强调的核心观点我特别认同：对于事实性问题，宁可有条件地拒绝，也不要让模型自信地胡编。因为用户一旦发现数据是假的，整个系统的信任就崩了。4.2 精确计算与代码执行器：别让模型当计算器第二个场景是精确计算。看起来很简单，但这是模型最典型的短板。我之前做过一个数学演示Demo，让模型直接回答“1.09的12次方”，它经常会算错，有时候答案是3.09，有时候是3.08，误差不大但就是不准。更麻烦的是，它自己算错的时候还特别自信。正确做法是给模型配一个计算器工具，或者更进一步，配一个代码执行器。模型负责把问题转成代码，比如1.09**12，再调用执行器算出来，结果精确且可复核。这讲对这种场景的建议是：能用工具就别让模型硬算，因为模型的价值在于理解和推理，不在于数值精确。不过代码执行器引入的安全风险也大——模型生成的代码不能直接放开跑，必须有沙箱、资源隔离、执行时间限制。如果只是简单运算，用我之前写的calculator那样做表达式白名单校验就够了。4.3 数据库查询与报表生成：NL2SQL的完整闭环第三个场景是数据库查询。这是我认为函数调用最核心的生产级应用之一，把用户的自然语言问题转成SQL，执行后返回结果，再生成报表。我在某个内部数据分析项目里就是这么做的，流程和这一讲几乎完全一致。用户问“上个月退货率最高的三个产品是什么”，模型会先判断需要查数据库，生成一条SQL，比如SELECT product_name, return_rate FROM monthly_returns WHERE month = '2025-05' ORDER BY return_rate DESC LIMIT 3，应用层执行这条SQL，把结果回填，模型再根据结果用自然语言回答，甚至生成一个表格。但这里有几个必须做的工程约束。第一，数据库账号必须是只读的，绝不能让模型生成的SQL能改数据。第二，所有查询必须在事务里跑，加上超时，防止模型生成了全表扫描这种恐怖查询。第三，对敏感字段要脱敏，比如用户手机号、身份证号，模型能看到数据不代表应该看到全部数据。第四，最好限制模型只能查特定的库和表，这可以在Schema层面就约束清楚。高频踩坑与排查技巧实录5.1 问题一：模型输出的JSON不合法这是我用函数调用以来遇到最频繁的问题。明明要求输出JSON，结果可能多了个逗号、注释没删干净、字符串引号错误。我的排查三步法：先看是不是模型版本的问题，有些模型对复杂工具定义格式支持不好；再看是不是上下文示范太少，在提示词里加一个正确示例往往见效最快；最后兜底方案是在代码里做容错解析，比如用宽松的解析逻辑，把代码块先剥离出来再转JSON。一个小技巧：给模型的工具示例不要太多，每个工具最多一两个，因为示例太多会挤占上下文空间，反而增加输出混乱概率。5.2 问题二：模型陷入工具调用死循环我遇到过一个经典场景：模型调用了一个工具，工具返回“参数错误”，模型看懂了，又原样调用了一次，还是“参数错误”，继续调用，一直循环到超时。原因是模型不知道“同样的错误应该换个方式处理”。解决手段有三个：设置最大轮数、对完全相同的调用做去重、连续两次工具执行失败就强制终止并让模型基于已有信息回答。核心原则是：工具调用必须有个“刹车机制”。5.3 问题三：参数幻觉，编造不存在的字段模型在调用工具时可能生成不存在的参数。比如数据库工具明明只有orders表，它却生成了SELECT * FROM users，看起来像模像样，实际一执行就报错。解决思路是：在工具Schema里尽量用枚举约束，比如在描述里写明“可用表：orders, products, customers”；在应用层做严格参数校验；当工具返回“表不存在”时，把可选表清单带回去，让模型基于真实信息重新生成。这一步非常关键，模型不擅长凭空猜出你系统里有什么，但很擅长在你给它清单之后做出正确选择。5.4 问题四：上下文被工具结果撑爆工具返回的数据量通常远超你想象。比如数据库查询，模型生成了一条不带LIMIT的SQL，结果返回10万行，直接塞进上下文，第二次模型请求大概率直接超过token上限。方案是统一的回填截断策略：默认只回填前10条或20条，并附上“如需更多数据请再次查询”。还可以让模型自己控制粒度：在工具描述里要求它必须写LIMIT，否则工具就报错。让工具自己有防御性，比事后截断更可靠。5.5 常见问题速查表症状原因解法JSON解析失败格式不规范、转义错误容错解析、提示词加示例反复调用同一工具模型陷入测试循环轮数上限、相同调用去重调用成功但结果不对参数幻觉、字段名错误Schema枚举约束、返回字段清单请求超时工具结果过大截断回填、强制LIMIT模型直接回答不调工具系统指令不明确强调实时/计算类问题必须调用工具5.6 安全边界：工具能调用不代表能随便调用这讲虽然没有大篇幅谈安全，但我在实际项目中体会很深。函数调用相当于把“手”交给了模型，这个手能摸到哪些东西，完全由你控制。最低要求是权限最小化：数据库只读、外部API白名单、删除操作一律禁止。更严格一点，敏感操作要加人工审批流程。我在某个项目里就做过一个“发邮件工具”，工具本身只负责生成邮件草稿，真正的发送动作必须人工确认。这个设计牺牲了一点自动化程度，但换来了非常高的安全边际。另外，工具返回的外部内容一律视为不可信数据，直接拼接给用户前要做清洗，防止意外注入。最后：我对函数调用方向的实际体会把这一讲的笔记整理完之后，我最大的感触是：工具使用能力决定了整个Agent系统的上限。模型本身的水平是底座，但底座再强，如果工具层定义混乱、调用过程不稳，最后效果一定拉胯。很多开发者在做Agent时，70%的badcase其实出在工具定义不清晰——描述模棱两可、参数约束缺失、返回格式混乱。把这些工程细节打磨好，效果往往比换一个更大的模型还要明显。另外我特别想提醒的是，做工具调用之前，先把可观测性做好。我在某项目里把工具调用链路全量打了日志，每个工具入参、出参、耗时都记录在案，后面定位问题简直是救命级的功能。模型这种非确定性系统，你没法靠“看代码猜行为”，必须靠日志回放。函数调用正在成为AI应用的一种标准基础设施，它不像大模型训练那么玄学，也不像前端交互那么琐碎，更像是在“给模型建造可靠的双手”。如果你正在规划自己的智能体应用，我建议把这一讲的机制彻底搞透——它值得你花一个下午亲手跑一遍，再花很长时间在真实场景里打磨。