面试官把电脑转过来屏幕上一行字手写一个 Tool Use。我盯着题目愣了两秒然后笑了这种题看起来简单实际是最容易翻车的——很多候选人能把“调用工具”四个字说出来却写不出一个能跑通的多轮闭环。Tool Use也就是工具调用本质上是让大模型在执行任务时能够调用外部函数、查询接口、操作数据的一层桥梁。它解决的是“模型只能说话、不能做事”的痛点模型本身不联网、不读数据库、不执行代码但业务场景偏偏需要它去查天气、算价格、调订单。这篇文章就用我当时的真实思路拆三种手写方案从最朴素的提示词解析到生产级的函数注册表再到 ReAct 推理循环。无论你是在准备面试还是想理解 Agent 框架里最核心的那块拼图都值得往下看。1. 先把 Tool Use 这件事想清楚1.1 面试官问 Tool Use到底在问什么先别急着写代码得先想明白面试官让你手写 Tool Use考察的根本不是你会不会调某些厂商的 function calling 接口而是你对“模型如何与外部世界协作”的理解深度。LLM 本质上是一个概率语言模型你给它输入 token它输出 token所有知识都藏在参数里。但真实的业务系统不会只让模型“聊天”更多时候需要它“做事”。比如用户说“帮我查一下最近的订单”模型自己读不到数据库它必须先产生一个“我要调用订单查询接口”的意图程序检测到这个意图后去执行真实的查询函数再把查询结果以文本形式塞回上下文模型基于真实数据组织最终回答。这一整套“意图表达 → 工具执行 → 结果回传”的闭环就是 Tool Use。面试官真正想看三件事第一你知不知道模型输出的不一定是最终答案可能只是一个调用意图。第二你知不知道工具调用是一个多轮循环而不是一问一答就结束了。第三面对工具参数非法、工具报错、模型瞎编参数这些边界情况你有没有防御意识。我当时听到题目脑子里直接冒出三条路线。最简单的是纯提示词解析标准的是函数注册表加 Schema 校验进阶的是 ReAct 式的推理循环。三种方案复杂度递增适配场景完全不同。下面一个一个拆开说。1.2 一个最小 Tool Use 闭环包含哪些环节画张图在脑子里比直接开写重要得多。一个完整的 Tool Use 系统不管用什么协议实现都逃不开五件事工具注册把外部函数的名字、描述、参数结构暴露给模型让模型知道“有哪些工具可用”。意图表达模型根据当前对话产出一个结构化的工具调用请求比如 JSON 或专门的 tool_call 对象。意图解析程序解析模型输出提取出要调用的工具名和参数但不直接信任这些参数。工具执行把参数传给真实函数拿到真实结果同时处理超时、异常等风险。结果回传把工具执行结果拼回对话上下文让模型基于结果继续推理或生成最终答案。有人会把 tool loop 理解成一次性的“模型说调用就调用、说结束就结束”这是个常见的认知误区。真实场景里一次用户问题往往要经过好几轮工具调用才能收尾。比如“帮我查一下上周的销售数据再分析同比变化”模型得先调查询接口拿数再调分析接口做处理最后才能组织出人话。所以手写实现时循环结构从一开始就要设计进去否则写到一半你会发现根本处理不了连续调用。2. 方案一提示词驱动的 JSON 输出解析最简实现2.1 思路把工具规则写进 System Prompt方案一的思路非常朴素我不依赖任何特殊协议只把可用工具用自然语言描述清楚写进 System Prompt然后硬性规定“当你需要调用工具时必须输出固定格式的 JSON”。假设只有两个工具一个是查天气的get_weather一个是查股价的get_stock_price。System Prompt 大概长这样你是一个智能助手。当用户的问题需要查询实时数据时你必须输出一个 JSON 对象格式如下 {tool: 工具名, args: {参数名: 参数值}} 可用工具 - get_weather: 查询天气参数 city城市名必填 - get_stock_price: 查询股票价格参数 symbol股票代码必填 除此之外不要输出任何多余内容。这样做的最大好处是零依赖任何只支持文本补全的模型都能跑。坏处同样明显模型经常不听话把 JSON 包进 Markdown 代码块、输出前后夹带解释文字、参数名写错、JSON 格式非法。所以方案一的重点并不在“定义规则”而在“怎么把不守规矩的输出救回来”。2.2 容错解析器正则加 JSON 修复既然模型输出不可控解析层就要皮实一点。我当时写了个很直接但好用的提取函数分三步走先剥掉 Markdown 代码块标记和首尾空白然后用正则把最内层的大括号 JSON 区域抠出来最后用降级策略一层一层试着解析。import json import re def extract_json_from_text(text: str) - dict: # 第一步去 Markdown 代码块围栏 text re.sub(r(?:json)?, , text).strip() # 第二步定位最外层大括号 match re.search(r\{.*\}, text, re.DOTALL) if not match: raise ValueError(no json found) raw match.group() # 第三步层层降级解析 try: return json.loads(raw) except json.JSONDecodeError: pass # 去掉尾逗号再试 cleaned re.sub(r,\s*([}\]]), r\1, raw) try: return json.loads(cleaned) except json.JSONDecodeError: pass # 单引号替换再试 try: return json.loads(cleaned.replace(, )) except json.JSONDecodeError as e: raise ValueError(fjson parse failed after retry: {e}) from e这个函数看着简陋但它覆盖了实际跑模型时最常撞上的两类问题Markdown 包裹和尾逗号。解析出字典之后用tool字段查一个注册表 dict找到后用args展开调用即可。2.3 双轮调用把结果拼回 Prompt 再请求一次只做“解析后调用函数、把结果打印出来”还不叫 Tool Use因为结果没回传给模型用户根本拿不到自然语言回答。正确做法是第一轮让模型输出 JSON 意图程序解析并执行工具然后把执行结果拼进对话上下文再发起第二轮请求让模型基于真实结果组织最终答案。def run_with_tool_once(user_query: str, tool_result: str) - str: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_query}, { role: user, content: f工具执行结果如下请基于该结果回答用户\n{tool_result}, }, ] # 这里调用任意的文本补全接口 return llm_chat(messages)这一步是面试中最容易被忽略的点。很多候选人写 Tool Use 只写到“我去查数据库、查到结果了”就停住没有把结果喂回给模型。面试官看到这种实现基本可以判定你对 tool loop 的理解不到位。2.4 方案一的适用边界方案一的定位是“最小可用”和“理解原理”。优点是简单、直观、兼容所有模型缺点是笨重和不稳定。工具数量超过十个、参数结构变复杂之后靠 Prompt 描述会让模型选错工具的概率明显上升而且它本质上只能支撑“一轮调用、一轮回答”很难编排多工具连续调用。面试时时间紧张先用方案一讲清楚流程、动手把代码写出来同时把“结果回传”这个环节补上就够合格了。但千万别停在这一层因为面试官大概率会追问一句“如果工具执行失败了怎么办如果模型连续调用多个工具怎么办”这两个问题正好引向后面的进阶方案。3. 方案二函数注册表 JSON Schema 调度器标准实现3.1 思路把工具的“说明书”结构化方案二是当今主流大模型 Function Calling 协议的标准做法。模型不再靠自然语言理解工具而是接收一份类似 JSON Schema 的结构化定义里面清楚写明白工具名、工具描述、参数名、参数类型、是否必填、枚举范围。模型读到这份定义后如果判断需要调用工具就会在响应里带回一个结构化的 tool_call 对象而不是一段需要正则去抠的 JSON 文本。这种做法的核心价值在于把“模型如何表达意图”这件事标准化了。模型输出自带工具名和参数解析层不需要做文本修复校验层可以直接用 jsonschema 库统一跑校验可靠性提升一个量级。3.2 工具协议与注册表设计我实现方案二时定义了三层结构ToolSpec静态说明书、ToolExecutor实际执行函数、ToolRegistry注册与分发表。核心代码如下from typing import Callable, Any class ToolRegistry: def __init__(self): self._specs: dict[str, dict] {} self._executors: dict[str, Callable] {} def register( self, name: str, description: str, parameters_schema: dict, fn: Callable, ): self._specs[name] { type: function, function: { name: name, description: description, parameters: parameters_schema, }, } self._executors[name] fn def get_schemas(self) - list[dict]: return list(self._specs.values()) def execute(self, name: str, args: dict) - Any: if name not in self._executors: raise KeyError(funknown tool: {name}) return self._executors[name](**args)这里有个面试官特别爱看的细节get_schemas返回的结构要完全对齐主流 LLM API 的tools参数格式。这样写出来的注册表可以直接塞进任意一个支持 function calling 的模型请求里不需要额外做协议转换代码的复用性一下就体现出来了。注册两个工具作为示例def get_weather(city: str, unit: str celsius): 模拟查天气实际开发时替换为真实 API 调用。 data { CityA: {celsius: 28, fahrenheit: 82}, CityB: {celsius: 30, fahrenheit: 86}, } info data.get(city, data[CityA]) return {city: city, unit: unit, temperature: info.get(unit, 28)}注意工具函数本身的 Python 签名就是第二道参数闸门。模型传参不对时fn(**args)会直接抛 TypeError你要做的是捕获它并把错误信息包装成“工具执行失败”的消息返回给模型让它自己修正而不是让整个程序崩掉。3.3 参数校验别把脏参数直接喂给业务函数模型输出的参数不一定合法可能类型不对、字段缺失、枚举越界。把这些脏参数直接传给业务函数轻则运行时异常重则在真实生产环境里触发副作用。所以在 execute 之前我会先用 jsonschema 统一校验一遍。import jsonschema def validate_args(name: str, args: dict, registry: ToolRegistry) - None: schema registry._specs[name][function][parameters] try: jsonschema.validate(instanceargs, schemaschema) except jsonschema.ValidationError as e: # 包装成工具层可识别的校验异常 raise ValueError(finvalid args for {name}: {e.message}) from eBy the way这步在面试里是明显的加分项。很多人会说“做一些参数校验”落到代码里却只是 if 判断非空。真正用 jsonschema 对着 Schema 做统一校验体现的是你对生产环境的理解工具数量一多手写一堆 if 根本维护不过来必须靠声明式校验。3.4 主循环处理多轮 tool call方案二的核心是主循环。用户请求进来后模型第一轮可能返回 tool_call也可能直接返回文本结束。如果返回的是 tool_call程序就执行对应工具把结果以 roletool 的消息追加到 messages再发起第二轮请求。循环往复直到模型不再返回 tool_call。import json def run_tool_loop(messages: list[dict], registry: ToolRegistry, max_steps: int 5) - str: for step in range(max_steps): response llm_with_tools(messages, registry.get_schemas()) if response.get(tool_calls): messages.append(response) # 完整保留模型输出含 tool_call for tc in response[tool_calls]: name tc[function][name] args json.loads(tc[function][arguments]) try: validate_args(name, args, registry) result registry.execute(name, args) error_text except Exception as e: result None error_text f {e} messages.append( { role: tool, tool_call_id: tc[id], content: f{json.dumps(result, ensure_asciiFalse)}{error_text}, } ) else: return response[content] return reached max steps这段代码有三个容易被忽略的坑必须强调。第一messages 里要追加原始 response而不是只追加解析后的工具名和参数。主流协议要求 tool_call 消息后面跟 roletool 的结果消息并且 tool_call_id 必须一一对应顺序一旦乱了模型就分不清哪个结果对应哪个调用。第二每个 tool_call 都要有独立 id。模型有时会一次返回多个 tool_call你用 uuid4 或者“工具名加时间戳”生成都行关键是不能所有调用共用一个 id否则结果回传就会错位。第三max_steps 必须存在。模型在工具循环里确实会“犯轴”反复调用同一个工具或者在工具报错后不断重试。没有一个上限一次请求就能把你请求预算和限流全部打穿。设 5 到 8 轮比较合理到顶后返回兜底回答。3.5 方案二的优势与代价方案二目前是生产环境里最主流的实现形态。表达能力强可以同时发起多个工具调用也就是 parallel tool calls多轮迭代天然支持校验清晰异常信息能回传给模型做自我修正。代价是依赖特定协议不同模型的 tool_call 输出结构会有些许差异不过只要在解析层做一层薄薄的适配封装切换模型并不麻烦。面试时方案二值得花最多时间展开。面试官看到你写出 tool loop并处理了 tool_call_id、参数校验、循环上限这三件事基本可以认定你是真正碰过 Agent 系统的人而不是只会背概念。4. 方案三ReAct 模式下的 Tool 推理循环进阶方案4.1 从 Function Calling 到 ReAct方案二很可靠但有一个前提模型厂商在 API 层内置了 tool_call 的结构化输出能力。如果有一天你要接入一个不支持 function calling 的模型或者想在极简协议下构建一个能“边推理边调用工具”的 Agent就要回到 ReAct 模式。ReAct 全称是 Reasoning and Acting核心思想是把“推理”和“行动”交替组合让模型输出固定格式的文本里面包含三段信息Thought思考我现在该做什么、Action行动调用哪个工具、Action Input行动参数。程序解析 Action 后执行工具把结果以 Observation观察结果的形式拼回上下文模型基于 Observation 继续输出下一轮 Thought如此循环直到模型输出 Final Answer。用一个生活化的类比就像人解一道复杂的数学应用题先想“这题需要用到速度公式”然后动笔算看到结果再想“下一步该求时间了”一步一步逼近最终答案。这种思考与行动交替的方式比一次性输出答案要靠谱得多。4.2 手写一个最小的 ReAct 循环如果一个模型不支持原生 function calling也不支持 JSON 模式你依然可以用 ReAct 文本协议实现 Tool Use。关键在于定义一段程序好解析、模型也好生成的文本约定。我用的是最经典的三行式Thought: 说明当前推理过程 Action: 工具名 Action Input: {参数名: 参数值}主循环长这样import json import re def run_react_loop(user_query: str, registry: ToolRegistry, max_steps: int 6) - str: messages [ {role: system, content: react_system_prompt()}, {role: user, content: user_query}, ] for _ in range(max_steps): text llm_chat(messages) # 是否已经输出最终答案 if Final Answer: in text: return text.split(Final Answer:, 1)[1].strip() # 解析 Action 和 Action Input action_match re.search(rAction:\s*(\w), text) input_match re.search(rAction Input:\s*(\{.*?\}), text, re.DOTALL) if not (action_match and input_match): # 解析失败把提示语写回让模型重新组织输出 messages.append({ role: user, content: 输出格式不符合要求请重新输出 Thought/Action/Action Input 或 Final Answer。 }) continue name action_match.group(1) try: args json.loads(input_match.group(1)) result registry.execute(name, args) observation json.dumps(result, ensure_asciiFalse) except Exception as e: observation ftool execution failed: {e} messages.append({ role: user, content: fObservation: {observation}\n请继续思考并输出下一步 Action 或 Final Answer。 }) return reach max steps, please try again这段代码里有两个细节值得单独讲。第一Observation 是作为 user 消息追加的而不是 assistant 消息。在 ReAct 文本协议里这是最常见的做法因为不支持 function calling 的模型没有“系统注入工具结果”的概念你只要把 Observation 放进对话上下文模型自然就会基于它继续推理。第二解析失败时不要直接崩溃而是发一条“格式不对请重新输出”的纠错消息。模型偶尔会漏掉 Action Input或把参数写成非 JSON给它一次纠错机会通常就能回来。真实使用中这个机制能明显提升循环的健壮性。4.3 ReAct 循环的三个防守策略ReAct 是文本协议自由度大翻车点也多。我实际用过之后总结了三个必须做的防守。第一最大轮数必须设。ReAct 循环里模型可能陷入死循环反复输出同一个 Action或在一个工具报错后翻来覆去重试。没有上限一次请求就能烧掉大量 token。6 到 10 轮是合理区间再往上不是解决问题是在纵容模型空转。第二停用词处理。部分模型输出时会不停追加不相关内容如果生成接口支持 stop token把Observation:和Final Answer:设成停止词可以避免模型把上一轮观察内容原样复述一遍也能省不少 token。第三工具副作用要可控。ReAct 常用于开放式任务模型可能会自行决定去调用任何已注册工具。因此所有工具最好实现成无状态或可重入涉及写操作、发消息、扣费这类带副作用的工具必须加二次确认防止模型在长循环里触发不该触发的动作。4.4 方案三该怎么定位方案三的代码量比方案二更大面试时未必有时间完整写完但它能体现你对 Agent 范式的理解深度。如果面试官问你“了解 ReAct 吗”“如果模型不支持 tool call 怎么办”你能直接说出 Thought/Action/Observation 的循环结构再讲清楚解析与回灌的流程就已经能压住场面。实际开发中方案三通常用来做轻量级 Agent 原型或者临时给不支持 function calling 的模型补上 Tool Use 能力。缺点也很明显输出格式靠文本约定约束解析层始终有兼容成本长对话下模型可能丢失早期 Observation需要做摘要或外部记忆。所以它更适合快速验证思路生产环境我还是优先推荐方案二。5. 三种方案对比与选型建议5.1 一张表看透差异三种方案的核心差异用一张表就能讲清楚。面试时直接讲这张表既简洁又有信息量对比维度方案一提示词 JSON方案二注册表 Schema方案三ReAct 循环模型依赖任意文本模型支持 tool call 的模型任意文本模型实现难度最低中等较高调用可靠性低需正则兜底高结构化输出中文本协议易解析失败多轮调用困难天然支持支持并行调用不支持支持多 tool_call不支持需串行错误回传修正手动拼装协议原生支持拼 Observation 实现生产推荐度原型验证推荐特殊接入场景你如果能当着面试官的面把这张表讲明白说明你不是只会写三段代码而是对 Tool Use 这一技术谱系有全局认知。5.2 实际选型的判断标准在我做过的项目里我从不一上来就选最重的方案而是按这个顺序判断如果只是做一个 Demo 或内部小工具且模型没开放 function calling用方案一半小时跑通。如果是生产服务且模型 API 支持 function calling闭眼选方案二。它是主流厂商的标准协议踩坑的人多问题基本都被人趟平了。如果正在做 Agent 框架要支持“自主规划、逐步执行”的任务方案二给工具层方案三给推理层两者并不互斥。很多成熟的 Agent 框架正是这样Function Calling 负责稳定接入工具ReAct 负责高层规划。选型的本质是在可靠性和灵活性之间做平衡。工具调用是落地动作可靠性永远优先。一个自主循环做得再花哨如果连参数校验都做不好最后跑起来就是各种报错。6. 面试现场的一点实操体会6.1 先讲原理再写代码顺序很重要那次面试大约持续了四十分钟。复盘时我最深的体会是功劳不在于某一段代码写得漂亮而在于给自己定了一个节奏——先用三分钟讲清楚 Tool Use 是什么再动手写方案二的核心循环最后用方案一和方案三展示扩展认知。面试官要的不是最终的代码产物而是你组织思路的方式。如果一上来就闷头写代码写到一半才发现没考虑结果回传场面会非常尴尬。我在模拟面试里见过太多次这种场景候选人几分钟就写出了工具执行列表却不知道怎么让模型看到工具结果最后只能硬撑。先花时间把闭环画出来代码只是对那张图的翻译心里有图写起来自然不会乱。6.2 边界处理是你的加分项“工具调用失败怎么办”基本是必问题。如果你只回答“抛异常让上层处理”面试官绝不会满意。更好的答案是捕获异常后把错误信息写进 tool 结果消息里回传让模型知道“这个工具报错了原因是什么”模型会尝试修正参数后再次调用。这个机制在方案二里只要几行代码体现的却是生产级思维。另一个加分细节是可观测性。我给主循环加过日志每次工具调用都记录工具名、入参、出参、耗时、是否异常。面试时随口提一句“生产环境没有日志就没法排查模型乱调用工具的问题”这比背十页八股文更有说服力。6.3 别掉进过度设计的坑有些候选人一上来就画架构图事件总线、任务队列、插件机制全堆上去结果代码写到一半崩了。手写 Tool Use 的考点从来不是“你能否设计一个分布式 Agent 平台”而是“你能否在短时间内跑通一个最小闭环”。我当时用方案二打底能跑通、能讲清楚就已经赢了。那些更高级的设计放到口头补充里面试官有兴趣自然会追问没必要用代码硬撑。还有一个我踩过的坑手写代码时把模型接口的参数名记混了。比如把tools写成了functions把 tool 消息的字段名写错。这种细节在面试里很致命因为报错会打断你的思路。我的习惯是对着主流 LLM API 的接口签名提前默写一遍 tools 请求结构和 tool_call 响应结构相当于把最常用的接口格式刻进脑子里到了现场才不会卡壳。那次面试最后拿到了通过的结果。我个人觉得Tool Use 看起来是一个具体的技术点实际上考察的是工程师对“大模型和外部世界如何协作”这个核心命题的理解。只要把工具注册、意图表达、执行校验、结果回传这条闭环彻底吃透不管面试官后续把问题引向 Agent、RAG 还是多轮对话编排你都能接得住。最后再分享一个小技巧面试前先在草稿纸上把工具注册表和主循环的伪代码写一遍五分钟都用不了。这个动作能帮你把接口字段名顺一遍也能让你在正式落笔时心里有底。如果你也在准备类似的面试希望你读完这篇之后能把 Tool Use 从“听说过”变成“我亲手写过”这套逻辑才是真正属于你的东西。