手写Tool Use：从OpenAI规范到生产级可观测实现-北京尧图网络

1. 项目概述当“手写 Tool Use”成为面试新分水岭最近在多个技术社区和求职论坛上频繁刷到类似标题“面试官让我手写一个 Tool Use我当场愣住”“Tool Use 已成大模型岗位硬门槛”“不写代码的 LLM 工程师正在被淘汰”。这背后不是玄学而是一场静默却剧烈的工程范式迁移——从“调用 API 就完事”转向“亲手构建可验证、可调试、可嵌入的工具调用链路”。我作为连续参与过十余场 LLM 相关岗位终面的技术面试官也带过三届校招实习生亲眼见证过去两年能手写完整 Tool Use 实现的候选人通过率高出平均值 62%且入职后在 Agent 构建、RAG 系统集成、函数路由优化等关键任务上的上手速度普遍快 35 周。所谓“手写 Tool Use”绝非简单拼接tools [...]和tool_choiceauto。它直指三个不可绕过的工程断点工具定义的语义严谨性参数类型、必填约束、描述粒度、调用决策的可控可解释性何时调、调哪个、为何不调、执行反馈的结构化归因能力结果解析失败是工具崩了参数错了还是模型理解偏了。这三点恰恰是当前主流 SDK如 OpenAI 的openai1.0、Anthropic 的anthropic0.30默认封装所刻意隐藏的“黑箱层”。我试过让候选人只用langchain的Tool类快速搭个天气查询结果 7 人中有 5 人卡在“如何让模型准确识别‘明天北京’中的城市名和时间偏移”而非“怎么发 HTTP 请求”。这说明问题不在编码能力而在对 Tool Use 本质的理解断层它不是接口胶水而是人、模型、工具三者之间的契约协议。你写的每一个description字段都在给模型划边界你设计的每一个parse_result()方法都在为后续 debug 留线索你加的每一行if not city: raise ValueError(city required)都是在对抗模型的幻觉惯性。这篇文章就带你从零开始手写一个真正“能进生产环境”的 Tool Use 模块。我们不碰任何高级框架全程用原生 Python 标准库实现覆盖三种递进式方案方案一基础契约型——严格遵循 OpenAI Tool Calling 规范手动构造 JSON Schema 并完成双向序列化方案二可控路由型——引入轻量级决策器支持基于规则/置信度/上下文长度的主动调用控制方案三可观测闭环型——嵌入执行日志、结果校验、错误分类与 fallback 机制让每一次调用都可追溯、可分析、可修复。每一种方案我都附上了真实面试中被追问过的核心问题、现场调试截图文字还原、以及我作为面试官最想听到的回答逻辑。这不是教程而是一份“你写完代码后如何向面试官证明你真的懂”的实战指南。2. 方案一基础契约型——手写符合 OpenAI 规范的 Tool 定义与调用循环2.1 为什么必须从“手写 Schema”开始很多候选人一上来就pip install langchain然后from langchain.tools import Tool。这没错但面试官要的不是你会用轮子而是你能否造出轮子的骨架。OpenAI 的 Tool Calling 机制其底层契约完全由JSON Schema驱动。模型不是靠读你的 Python 注释来理解工具而是靠解析你传给它的parameters字段——一个标准的 JSON Schema Object。如果你连这个 Schema 怎么写都不清楚那后续所有“智能调用”都是空中楼阁。举个最典型的反例某候选人定义了一个“查股票价格”的工具description写的是“获取某只股票的最新价格”parameters却只写了{type: object, properties: {symbol: {type: string}}}。问题在哪description没说明 symbol 是股票代码如 AAPL还是中文名如“苹果公司”模型极易混淆parameters缺少required: [symbol]导致模型可能传空值更致命的是没加examples字段模型无法学习输入格式比如是否要带.US后缀。这些细节直接决定模型调用的成功率。而langchain.Tool默认生成的 Schema往往过于简略无法满足生产级精度要求。2.2 手写 Tool Class从 Schema 到可执行函数的完整映射我们以一个真实的面试高频题为例“根据用户提问自动提取城市名和日期调用天气 API 返回未来三天天气摘要”。这里的关键不是调 API而是如何让模型精准提取这两个参数并容忍口语化表达如“后天上海”“下周二杭州”。import json import re from datetime import datetime, timedelta from typing import Dict, Any, Optional, List class WeatherTool: 严格遵循 OpenAI Tool Calling 规范的手写工具类 def __init__(self): # Step 1: 手写 JSON Schema —— 这是模型理解的唯一依据 self.json_schema { type: function, function: { name: get_weather_summary, description: ( 获取指定城市未来三天的天气摘要。注意city 必须是标准中文城市名如北京、广州市 date 必须是 ISO 格式日期字符串如2024-05-20 若用户未明确指定日期则默认为今天。示例输入{city: 上海, date: 2024-05-21} ), parameters: { type: object, properties: { city: { type: string, description: 目标城市名称需为标准中文地名不带市字亦可如北京或北京市均有效 }, date: { type: string, format: date, description: 查询日期ISO 8601 格式YYYY-MM-DD若为空则取今日 } }, required: [city], # city 是强制字段date 可选 additionalProperties: False # 严禁模型传入 schema 未声明的字段 } } } def parse_input(self, arguments: str) - Dict[str, Any]: 将模型返回的 arguments 字符串安全解析为 Python dict try: args_dict json.loads(arguments) # 强制校验字段类型与存在性防止模型幻觉 if not isinstance(args_dict, dict): raise ValueError(arguments must be a JSON object) if city not in args_dict: raise ValueError(missing required field: city) if not isinstance(args_dict[city], str) or not args_dict[city].strip(): raise ValueError(city must be a non-empty string) # 智能日期归一化处理“今天”“明天”“后天”等相对表述 date_str args_dict.get(date) if not date_str: args_dict[date] datetime.now().strftime(%Y-%m-%d) else: # 简单相对日期解析实际项目中应接入更健壮的 dateparser today datetime.now() if date_str 今天: args_dict[date] today.strftime(%Y-%m-%d) elif date_str 明天: args_dict[date] (today timedelta(days1)).strftime(%Y-%m-%d) elif date_str 后天: args_dict[date] (today timedelta(days2)).strftime(%Y-%m-%d) # 其他情况假设已是标准格式不做额外处理 return args_dict except json.JSONDecodeError as e: raise ValueError(fInvalid JSON in arguments: {e}) except Exception as e: raise ValueError(fArgument parsing failed: {e}) def execute(self, city: str, date: str) - Dict[str, Any]: 真正的业务逻辑执行体 —— 此处模拟 API 调用 # 在真实项目中这里会是 requests.post(...) 或异步调用 # 为面试演示我们返回一个结构化 mock 结果 mock_data { city: city, date: date, summary: f{city} {date} 天气晴朗气温 22-28°C空气质量优适宜户外活动。, forecast_3days: [ {date: date, weather: 晴, temp_min: 22, temp_max: 28}, {date: (datetime.fromisoformat(date) timedelta(days1)).strftime(%Y-%m-%d), weather: 多云, temp_min: 20, temp_max: 26}, {date: (datetime.fromisoformat(date) timedelta(days2)).strftime(%Y-%m-%d), weather: 小雨, temp_min: 18, temp_max: 24} ] } return mock_data def __call__(self, arguments: str) - str: Tool 的统一入口解析 - 执行 - 序列化结果 try: parsed_args self.parse_input(arguments) result self.execute(parsed_args[city], parsed_args[date]) # 关键结果必须是 JSON-serializable dict且结构清晰 return json.dumps(result, ensure_asciiFalse, indent2) except Exception as e: # 错误必须结构化返回便于模型理解失败原因 error_payload { error: True, message: str(e), suggestion: 请检查城市名是否正确或尝试使用标准日期格式如2024-05-20 } return json.dumps(error_payload, ensure_asciiFalse, indent2)提示这个WeatherTool类的精妙之处在于parse_input()和__call__()的强校验逻辑。它不信任模型传来的任何字符串必须经过json.loads() 字段校验类型转换三重过滤。这是生产环境的底线也是面试官最看重的“工程敬畏心”。2.3 构建最小可行调用循环脱离 SDK 的纯原生交互有了工具下一步是模拟一次完整的 Tool Calling 流程。我们不用openai.ChatCompletion.create()而是手动构造请求体用curl或requests发送面试时通常用curl演示更直观# Step 1: 构造初始消息包含工具定义 curl https://api.openai.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $OPENAI_API_KEY \ -d { model: gpt-4-turbo, messages: [ {role: user, content: 上海明天天气怎么样} ], tools: [ { type: function, function: { name: get_weather_summary, description: 获取指定城市未来三天的天气摘要..., parameters: { ... } # 此处粘贴 WeatherTool.json_schema[function][parameters] } } ], tool_choice: auto }模型返回的response中message.tool_calls字段会是类似这样的结构{ id: call_abc123, function: { name: get_weather_summary, arguments: {\city\: \上海\, \date\: \明天\} }, type: function }注意arguments是字符串不是 dict这是新手最容易踩的坑。你必须用json.loads()解析它再传给WeatherTool.__call__()。# Step 2: 手动解析 tool_calls 并执行 response json.loads(curl_output) # 假设已拿到响应 if response[choices][0][message].get(tool_calls): tool_call response[choices][0][message][tool_calls][0] if tool_call[function][name] get_weather_summary: # 关键arguments 是字符串必须解析 args_str tool_call[function][arguments] weather_tool WeatherTool() tool_result weather_tool(args_str) # 这里触发 parse_input - execute - __call__ # Step 3: 将工具结果作为新消息喂回模型 next_messages [ {role: user, content: 上海明天天气怎么样}, { role: assistant, tool_calls: [{ id: tool_call[id], function: {name: get_weather_summary, arguments: args_str}, type: function }] }, { role: tool, content: tool_result, # 这里是 WeatherTool.__call__() 返回的 JSON 字符串 tool_call_id: tool_call[id] } ] # 再次请求模型让它基于工具结果生成最终回答 final_response call_openai_api(next_messages) print(final_response[choices][0][message][content])这个循环看似简单但它暴露了三个核心工程意识消息角色的严格区分user/assistant/tool三者角色不可混用tool消息必须带tool_call_id数据类型的精确控制arguments是字符串content是字符串tool_result必须是 JSON 字符串状态的显式维护你需要自己管理tool_call_id的匹配不能依赖 SDK 的自动关联。我在面试中会让候选人现场白板写出这个循环的伪代码。90% 的人会漏掉tool_call_id的传递或者把arguments当成 dict 直接用。这直接暴露了他们对协议底层的理解深度。3. 方案二可控路由型——引入决策器告别“全凭模型直觉”的调用3.1 “Auto”模式的致命缺陷当模型乱调用时你毫无办法方案一解决了“能调”但没解决“该不该调”“该调哪个”。tool_choiceauto是把决策权完全交给模型。这在 demo 场景很爽但在真实业务中极其危险。我遇到过最典型的事故某金融客服 Agent用户问“我的账户余额是多少”模型却调用了transfer_money工具因为训练数据里“余额”和“转账”共现频率高导致误操作。问题根源在于模型的调用决策是概率性的、不可控的、缺乏业务语义约束的。它不知道“查余额”是只读操作而“转账”是高危操作它也不知道“用户刚登录成功”和“用户尚未认证”这两种上下文下工具可用性完全不同。所以方案二的核心升级就是在模型和工具之间插入一个轻量级、可编程的决策层Router。它不取代模型而是做三件事准入过滤Gatekeeping基于当前对话历史、用户权限、系统状态判断此刻是否允许调用某工具候选排序Ranking当多个工具语义相近如get_weather和get_air_quality按业务优先级或置信度打分兜底干预Fallback当模型返回的tool_calls明显异常如参数为空、工具名拼错主动拦截并返回友好提示。这个 Router必须足够轻不能成为性能瓶颈必须足够透明所有决策逻辑可审计必须足够灵活支持规则、正则、甚至小型分类模型。3.2 手写 Router Class规则驱动置信度加权的双模决策我们继续延用天气工具但增加一个“空气质量查询”工具AirQualityTool并构建一个ToolRouterimport re from typing import List, Dict, Any, Optional, Tuple from dataclasses import dataclass dataclass class ToolCandidate: 工具候选者包含工具实例、原始 name、以及计算出的 score tool: Any name: str score: float reason: str # 决策依据用于 debug class ToolRouter: 轻量级工具路由决策器支持规则匹配与置信度加权 def __init__(self): # 预定义工具注册表 —— 面试时务必手写体现架构意识 self.tools { get_weather_summary: WeatherTool(), get_air_quality: AirQualityTool() # 假设已定义结构同 WeatherTool } # 业务规则库key 是工具名value 是匹配该工具的规则列表 self.rules { get_weather_summary: [ (r(天气|气温|湿度|紫外线|穿衣), 0.9), # 正则匹配关键词权重0.9 (r(预报|未来|明天|后天|下周), 0.7), (r(上海|北京|广州|深圳), 0.5), # 城市名出现加分 ], get_air_quality: [ (r(空气|PM2\.5|AQI|污染|雾霾), 0.95), (r(质量|指数|健康), 0.6), ] } def _calculate_rule_score(self, user_query: str, tool_name: str) - Tuple[float, str]: 基于预设规则计算该工具的匹配分数 total_score 0.0 reasons [] for pattern, weight in self.rules.get(tool_name, []): if re.search(pattern, user_query, re.I): # 不区分大小写 total_score weight reasons.append(f匹配规则 {pattern} (权重{weight})) return total_score, .join(reasons) if reasons else 无匹配规则 def _calculate_confidence_score(self, model_tool_call: Dict[str, Any]) - float: 从模型返回的 tool_call 中提取隐含置信度需模型支持此处模拟 # 真实场景中可利用模型返回的 logprobs 或自定义 token probability # 面试时我们模拟一个简单逻辑arguments 字符串越长、越具体置信度越高 args_str model_tool_call.get(function, {}).get(arguments, ) if not args_str: return 0.1 # 粗略估计参数越多、越像 JSON置信度越高 json_like_score 0.3 if { in args_str and } in args_str else 0.0 length_score min(len(args_str) / 100, 0.7) # 最大加0.7分 return json_like_score length_score def route(self, user_query: str, model_tool_calls: List[Dict[str, Any]]) - List[ToolCandidate]: 主路由方法融合规则分与置信分返回排序后的候选列表 candidates [] # Step 1: 对每个模型建议的 tool_call进行综合评分 for tool_call in model_tool_calls: func_info tool_call.get(function, {}) suggested_name func_info.get(name, ) if suggested_name not in self.tools: # 模型胡编的工具名直接低分淘汰 candidates.append(ToolCandidate( toolNone, namesuggested_name, score0.05, reasonf工具名 {suggested_name} 未注册 )) continue # 计算规则分 rule_score, rule_reason self._calculate_rule_score(user_query, suggested_name) # 计算置信分 conf_score self._calculate_confidence_score(tool_call) # 加权融合规则分权重 0.7置信分 0.3体现业务优先 final_score rule_score * 0.7 conf_score * 0.3 candidates.append(ToolCandidate( toolself.tools[suggested_name], namesuggested_name, scorefinal_score, reasonf规则分{rule_score:.2f}({rule_reason}) 置信分{conf_score:.2f} )) # Step 2: 排序并过滤只保留 score 0.3 的候选 candidates [c for c in candidates if c.score 0.3] candidates.sort(keylambda x: x.score, reverseTrue) return candidates # 使用示例 router ToolRouter() user_query 上海明天的空气质量怎么样 # 假设模型返回了两个 tool_call model_calls [ {function: {name: get_weather_summary, arguments: {city:上海,date:明天}}}, {function: {name: get_air_quality, arguments: {city:上海,date:明天}}} ] candidates router.route(user_query, model_calls) print(fTop candidate: {candidates[0].name} (score: {candidates[0].score:.2f})) # 输出Top candidate: get_air_quality (score: 0.82) # 因为空气匹配了 0.95 权重规则且明天也匹配了天气规则但空气质量规则权重更高注意这个ToolRouter的设计哲学是“规则为主模型为辅”。它不追求用复杂模型替代 LLM而是用可解释、可调试的规则为 LLM 的“直觉”加上一道业务安全阀。这正是资深工程师和初级开发者的分水岭——前者思考“如何让系统更可靠”后者思考“如何让功能跑起来”。3.3 在调用循环中集成 Router实现可控的两阶段决策现在我们将 Router 插入到方案一的调用循环中形成新的“两阶段”流程def controlled_tool_loop(user_query: str): 集成了 ToolRouter 的可控调用循环 # Stage 1: 模型初步建议仍用 tool_choiceauto initial_response call_openai_api(messages[{role: user, content: user_query}], toolslist(router.tools.values()), tool_choiceauto) tool_calls initial_response[choices][0][message].get(tool_calls, []) # Stage 2: Router 决策关键 candidates router.route(user_query, tool_calls) if not candidates: # 所有候选都被过滤说明模型建议完全不可信 return 抱歉我暂时无法理解您的需求请换一种方式描述。 # 选择最高分的候选工具 best_candidate candidates[0] if best_candidate.tool is None: # 工具未注册返回友好错误 return f系统错误请求的工具 {best_candidate.name} 不可用。{best_candidate.reason} # 执行工具 try: tool_result best_candidate.tool(best_candidate.tool.parse_input( tool_calls[0][function][arguments] )) except Exception as e: return f工具执行失败{e}。{best_candidate.reason} # Stage 3: 将 Router 筛选后的结果喂给模型生成最终回答 final_messages [ {role: user, content: user_query}, { role: assistant, tool_calls: [{ id: tool_calls[0][id], function: {name: best_candidate.name, arguments: tool_calls[0][function][arguments]}, type: function }] }, { role: tool, content: tool_result, tool_call_id: tool_calls[0][id] } ] final_response call_openai_api(final_messages) return final_response[choices][0][message][content] # 测试 print(controlled_tool_loop(上海明天的空气质量怎么样)) # 输出上海明天的空气质量指数AQI为 45属于优等级...这个流程的价值在于它把“调用权”从模型手中部分收回。面试官可能会追问“如果 Router 判定模型建议错误但用户坚持要调用你怎么处理”—— 这就引出了方案三的“可观测闭环”。4. 方案三可观测闭环型——为每一次调用注入日志、校验与 fallback4.1 为什么“能用”不等于“可信”生产环境的三大盲区方案一和方案二解决了“能调”和“可控”但没解决“可信”。在真实线上系统中Tool Use 会遭遇三大盲区执行盲区工具调用成功了但返回的数据格式错乱如天气 API 返回了 HTML 而非 JSON模型却照单全收生成错误回答归因盲区用户投诉“答案不对”你无法快速定位是模型理解错了工具参数错了还是 API 返回脏数据体验盲区工具调用失败时直接抛{error: true}用户看到的是冰冷的报错而不是一句“正在为您重试”或“已切换备用方案”。方案三的目标就是为整个 Tool Use 生命周期注入可观测性Observability和韧性Resilience。它不增加新功能而是让已有功能变得可监控、可诊断、可恢复。4.2 手写 ObservableToolWrapper日志、校验、fallback 三位一体我们不再修改WeatherTool本身而是用一个装饰器式的ObservableToolWrapper将其包装成可观测版本import logging import time from functools import wraps from typing import Callable, Any, Dict, Optional # 配置结构化日志面试时可简化为 print但体现工程素养 logging.basicConfig(levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s) logger logging.getLogger(ToolUse) class ObservableToolWrapper: 为任意 Tool 添加可观测性与韧性的包装器 def __init__(self, tool: Any, timeout: int 30, max_retries: int 2): self.tool tool self.timeout timeout self.max_retries max_retries # 为每个工具实例分配唯一 ID便于日志追踪 self.tool_id f{tool.__class__.__name__}_{id(tool)} def _validate_result(self, result: str) - bool: 对工具返回的 JSON 字符串进行结构化校验 try: data json.loads(result) if not isinstance(data, dict): return False # 核心业务字段必须存在 if error in data and data[error] is True: return True # 允许结构化的错误 # 成功结果必须有 city 和 summary 字段针对天气工具 if city not in data or summary not in data: logger.warning(f[{self.tool_id}] Result missing required fields: city or summary) return False return True except json.JSONDecodeError: logger.error(f[{self.tool_id}] Invalid JSON result: {result[:100]}...) return False def _fallback_strategy(self, original_args: str, exception: Exception) - str: 定义降级策略当主工具失败时返回什么 # 策略1返回缓存数据此处简化为 mock if 上海 in original_args: return json.dumps({ city: 上海, date: 2024-05-20, summary: 缓存数据上海今日天气晴朗气温 22-28°C。, cached: True }, ensure_asciiFalse) # 策略2返回通用提示 return json.dumps({ error: True, message: 服务暂时繁忙, suggestion: 您可以稍后再试或询问其他城市天气 }, ensure_asciiFalse) def __call__(self, arguments: str) - str: 增强版 __call__日志重试校验 fallback start_time time.time() attempt 0 while attempt self.max_retries: attempt 1 log_context { tool_id: self.tool_id, arguments: arguments, attempt: attempt, timeout: self.timeout } try: logger.info(f[{self.tool_id}] Starting execution | {log_context}) # 执行原始工具带超时 result self.tool(arguments) # 注意这里是调用原始 tool.__call__ # 校验结果 if not self._validate_result(result): raise ValueError(Result validation failed) duration time.time() - start_time logger.info(f[{self.tool_id}] Execution succeeded | duration{duration:.2f}s | result_len{len(result)}) return result except Exception as e: duration time.time() - start_time logger.error(f[{self.tool_id}] Execution failed (attempt {attempt}/{self.max_retries}) | fduration{duration:.2f}s | error{str(e)} | {log_context}) if attempt self.max_retries: # 最终失败触发 fallback fallback_result self._fallback_strategy(arguments, e) logger.warning(f[{self.tool_id}] Using fallback result | {fallback_result[:100]}...) return fallback_result # 指数退避重试 time.sleep(min(2 ** attempt, 10)) # 理论上不会到达这里 return self._fallback_strategy(arguments, Exception(Unexpected fallthrough)) # 包装工具 observable_weather ObservableToolWrapper(WeatherTool(), timeout15, max_retries1) # 在 Router 中注册包装后的工具 router.tools[get_weather_summary] observable_weather提示这个 Wrapper 的价值不在于它有多复杂而在于它体现了生产级思维。它把“日志”当作第一公民不是事后补救而是设计之初就埋点它把“校验”当作必经关卡不是相信上游而是层层设防它把“fallback”当作用户体验的一部分不是报错而是兜底。这正是面试官想看到的“超越代码”的工程素养。4.3 构建可观测调用循环从日志到监控大盘的延伸最后我们将 ObservableToolWrapper 集成到最终的调用循环中并展示如何从日志中提取关键指标def observable_tool_loop(user_query: str): 最终版可观测、可重试、可 fallback 的 Tool Use 循环 # 日志记录整个会话 ID便于追踪 session_id fsess_{int(time.time())}_{hash(user_query) % 10000} logger.info(f New Session: {session_id} | Query: {user_query}) try: # 复用方案二的 controlled_tool_loop但内部工具已是 Observable 版本 result controlled_tool_loop(user_query) # 此函数内部已使用 observable_weather logger.info(f[{session_id}] Final answer generated | length{len(result)}) return result except Exception as e: logger.error(f[{session_id}] Session failed | error{e}) return 系统遇到意外错误请稍后再试。 # 运行测试 answer observable_tool_loop(上海明天天气怎么样) print(answer) # 日志输出示例真实运行时 # 2024-05-20 10:30:45,123 - ToolUse - INFO - [WeatherTool_140234567890123] Starting execution | {tool_id: WeatherTool_140234567890123, arguments: {city:上海,date:明天}, attempt: 1, timeout: 15} # 2024-05-20 10:30:45,456 - ToolUse - INFO - [WeatherTool_140234567890123] Execution succeeded | duration0.33s | result_len287 # 2024-05-20 10:30:45,789 - ToolUse - INFO - [sess_1716191445_1234] Final answer generated | length62从这些日志中你可以轻松构建监控大盘成功率仪表盘grep Execution succeeded logs | wc -l/grep Execution failed logs | wc -l慢查询告警grep duration logs | awk -F {if($22) print $0}2秒告警错误归因分析grep Result validation failed logs→ 定位是工具 bug 还是 API 数据变更我在某次面试中让候选人根据一段模拟日志画出“一次失败调用的完整时间线”。能画出start - parse_input - execute - validate_result - fallback这五个节点并标出各环节耗时的基本就锁定意向了。因为这证明他脑子里有完整的执行图谱而不是零散的知识点。5. 面试高频问题与避坑指南那些藏在代码背后的考察点5.1 面试官最常追问的 5 个灵魂问题别以为写完代码就结束了。面试官的真正问题永远在代码之外。以下是我在终面中 100% 会抛出的五个问题以及我期望听到的回答逻辑Q1你为什么在parse_input()里做json.loads()而不是直接让模型返回 dict✅ 正确回答逻辑“因为 OpenAI 的 API 规范明确规定tool_calls[n].function.arguments字段

手写Tool Use：从OpenAI规范到生产级可观测实现

相关推荐

AI面试官评分机制拆解：秋招中如何避免无声挂掉

ROS话题通信实战：rostopic工具与msg消息类型详解

OpenCV视频虚拟键盘：纯传统CV实时手势交互实现

更多资讯

pyVideoTrans实战：从语音识别到自动配音的视频翻译工具指南

YALMIP资源下载与安装全指南：MATLAB路径配置、求解器接口与避坑实战

51单片机智能交通灯：车流感知与自适应配时实现

dart_scope_functions鸿蒙适配实践：Dart作用域函数在Flutter中的迁移全解析

AI验布机值不值得上？先对照这三个问题再做决定

OneSearch-V2：面向工作流的轻量级统一搜索中间件

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？