手写Tool Use面试题：从函数到生产级工具调度系统

1. 面试现场的真实压力：当“手写 Tool Use”成为临场能力试金石

“请手写一个 Tool Use 实现。”

这句话从面试官嘴里说出来的时候，我正端着一次性纸杯喝第三口温水——不是因为紧张，而是前两轮算法题刚结束，嗓子发干。但这句话一落，手指下意识在膝盖上敲了两下节奏，像在调试一段没跑通的代码。这不是考 API 调用熟不熟，也不是问你用没用过 LangChain 或 LlamaIndex；这是在测你脑子里有没有一套可拆解、可组装、可验证的工具调用心智模型。

很多人听到“Tool Use”，第一反应是抄一段@tool装饰器，或者粘贴个 OpenAI 的function calling示例。但面试官要的不是复制粘贴能力，而是你在没有框架兜底、没有文档提示、甚至没有联网查资料的 15 分钟内，能否从零构建出一个语义可理解、结构可扩展、错误可捕获、结果可回传的工具调度闭环。它本质上是一道“微型系统设计题”：输入是自然语言指令，输出是结构化动作+可信结果，中间必须经过意图识别、参数校验、执行隔离、响应归一四个不可跳过的环节。

我后来复盘过几十份真实面经，发现“手写 Tool Use”高频出现在三类岗位的终面环节：大模型应用层工程师（偏 RAG/Agent 构建）、智能客服中台开发者、以及面向垂类场景（如金融报告生成、医疗问诊摘要）的 Prompt 工程师。它们的共性是——不能只懂 prompt，也不能只懂 backend；得在语义与逻辑的夹缝里，搭一座能扛住用户乱输、参数错填、服务超时的桥。

这次我交了三版答案。第一版是“能跑就行”的最小可行体，第二版补上了健壮性骨架，第三版则把工具生命周期管理、上下文感知调用、多工具协同这些隐性需求全显性化了。这三版不是递进优化，而是三种不同抽象层级的解法：有人适合从函数开始建模，有人必须看到类结构才安心，还有人需要明确的注册-发现-路由-熔断链路才能建立掌控感。下面我就按当时白板书写的真实顺序，把每版怎么想、为什么这么写、哪里容易被追问，掰开揉碎讲清楚。

提示：面试中不要一上来就画类图或写装饰器。先问清约束——是否允许引入第三方库？是否要求支持异步？是否需处理工具返回非 JSON？这些看似细节的问题，往往直接决定你该选哪条技术路径。我第一版就因没确认“是否允许用dataclass”，被追问“如果只能用原生 dict 怎么保证字段一致性”，当场补了一段字段校验逻辑。

2. 第一版：纯函数式实现——用最朴素的 Python 拆解 Tool Use 的原子操作

很多候选人卡在第一步：不知道“Tool Use”到底要解决什么问题。其实把它拉回最原始的交互场景，就是三个动作：

1. 识别用户想调用哪个工具（比如“查北京今天天气” →get_weather）
2. 提取并校验工具所需参数（{"city": "北京", "unit": "celsius"}）
3. 安全执行工具，并把结果塞回对话流（{"temperature": 24, "condition": "晴"}）

第一版我选择用纯函数实现，不定义类、不注册中心、不抽象路由，就用三个独立函数加一个调度主函数。目的很明确：向面试官证明——我清楚每个环节的职责边界，且能用最基础的语言特性完成核心链路。

2.1 工具定义：用字典描述比用装饰器更暴露本质

# 不用 @tool，而用 dict 显式声明 WEATHER_TOOL = { "name": "get_weather", "description": "根据城市名和单位获取实时天气信息", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市中文名，如'上海'"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius"} }, "required": ["city"] } } # 真实工具函数（模拟网络请求） def get_weather(city: str, unit: str = "celsius") -> dict: # 这里本该是 requests.get(...)，面试中直接 mock return { "city": city, "temperature": 26 if unit == "celsius" else 79, "condition": "多云" }

为什么不用装饰器？因为装饰器会隐藏“工具元信息”和“执行函数”的分离关系。而面试官想看的，恰恰是你是否意识到：Tool Use 的核心不是执行，而是对执行意图的结构化表达与约束。用 dict 描述 schema，强制你思考required字段、enum枚举、default默认值这些设计细节——这些正是后续参数校验的依据。

22 参数解析：用 Pydantic v2 的BaseModel做轻量校验（不引入完整框架）

from pydantic import BaseModel, ValidationError class WeatherParams(BaseModel): city: str unit: str = "celsius" def parse_params(tool_name: str, raw_args: dict) -> dict: """根据工具名映射到对应参数模型，做类型+约束校验""" tool_map = {"get_weather": WeatherParams} try: model = tool_map[tool_name] validated = model(**raw_args) return validated.model_dump() except ValidationError as e: raise ValueError(f"参数校验失败：{e}") # 测试 parse_params("get_weather", {"city": "杭州"}) # ✅ 返回 {"city": "杭州", "unit": "celsius"} parse_params("get_weather", {"city": 123}) # ❌ 抛 ValueError

这里有个关键取舍：我用了 Pydantic，但只用它的BaseModel做参数校验，没用@tool装饰器或Tool类。原因有三：

• 第一，Pydantic 的校验逻辑清晰可见，错误信息友好，面试官能一眼看出你对数据契约的理解；
• 第二，model_dump()直接返回标准 dict，避免后续处理还要.dict()或.json()；
• 第三，如果面试官问“不用 Pydantic 怎么办”，我能立刻切到if isinstance(raw_args, dict)+ 手动key in required校验——这说明我清楚底层逻辑，不是靠框架遮羞。

注意：实际面试中，我写完这段后主动补了一句：“如果环境禁止第三方库，我会用typing.get_type_hints()+isinstance()组合做运行时类型检查，虽然代码长些，但原理完全一致。” 这句话让面试官点头了——他要的不是你会不会用库，而是你知不知道库在替你做什么。

2.3 调度主函数：把三步串成可测试的流水线

def dispatch_tool(tool_name: str, raw_args: dict) -> dict: """Tool Use 主调度函数：识别→校验→执行→包装""" # Step 1: 工具存在性检查（简单用 dict 查找） tool_def = {"get_weather": WEATHER_TOOL}.get(tool_name) if not tool_def: raise ValueError(f"未注册工具：{tool_name}") # Step 2: 参数校验 params = parse_params(tool_name, raw_args) # Step 3: 执行（这里用函数名字符串映射，非 eval） func_map = {"get_weather": get_weather} if tool_name not in func_map: raise RuntimeError(f"工具函数未实现：{tool_name}") result = func_map[tool_name](**params) # Step 4: 包装为标准 Tool Response 格式 return { "tool_name": tool_name, "arguments": params, "result": result, "status": "success" } # 调用示例 dispatch_tool("get_weather", {"city": "深圳"}) # → {"tool_name": "get_weather", "arguments": {"city": "深圳", "unit": "celsius"}, ...}

这个函数看似简单，但埋了三个考察点：

• 安全性：用func_map字符串映射而非eval()或getattr()，杜绝任意代码执行风险；
• 可观测性：返回结构包含arguments和result，方便调试和日志追踪；
• 可替换性：func_map和tool_def分离，意味着你可以把get_weather替换成真正调用气象 API 的函数，无需改调度逻辑。

我写完这版时，面试官问：“如果用户说‘查北京和上海的天气’，你怎么处理？” 我答：“第一版不处理，因为单次调用只支持一个工具。但这个问题指向了更深层需求——工具编排。这正好是我第二版要解决的。”

3. 第二版：面向对象重构——用类封装解决工具注册、发现与生命周期管理

第一版跑通了，但暴露了硬伤：所有工具定义、参数模型、执行函数全散落在全局作用域，无法动态增删，不支持工具分组，更没法做调用统计或熔断。面试官这时往往会说：“假设现在要接入 20 个内部工具，且每个工具由不同团队维护，你怎么设计才能让新工具接入成本最低？”

第二版我转向类设计，核心目标就一个：把“工具”变成可实例化、可注册、可发现的一等公民。我不追求大而全的 Agent 框架，而是聚焦三个刚需：注册中心、类型安全的调用接口、统一的错误处理策略。

3.1 Tool 类：把元信息、参数模型、执行逻辑打包成对象

from abc import ABC, abstractmethod from typing import Dict, Any, Optional, Type class Tool(ABC): name: str description: str parameters: Dict[str, Any] # OpenAPI-style schema @abstractmethod def execute(self, **kwargs) -> Dict[str, Any]: """执行工具，返回结构化结果""" pass def validate_params(self, raw_args: Dict[str, Any]) -> Dict[str, Any]: """默认参数校验逻辑（可被子类重写）""" # 此处可集成 Pydantic 或自定义校验 required = self.parameters.get("required", []) for key in required: if key not in raw_args: raise ValueError(f"缺少必需参数：{key}") return raw_args class WeatherTool(Tool): name = "get_weather" description = "根据城市名和单位获取实时天气信息" parameters = { "type": "object", "properties": { "city": {"type": "string"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} }, "required": ["city"] } def execute(self, city: str, unit: str = "celsius") -> Dict[str, Any]: return { "city": city, "temperature": 26 if unit == "celsius" else 79, "condition": "多云" }

对比第一版，这个Tool类的价值在于：

• 契约显性化：name/description/parameters成为强制字段，任何新工具都必须实现；
• 执行与校验解耦：execute()专注业务逻辑，validate_params()专注数据契约，便于单独测试；
• 可继承可扩展：比如DatabaseQueryTool可以重写validate_params()加入 SQL 注入检测。

3.2 ToolRegistry：解决“20 个工具谁来管”的核心枢纽

class ToolRegistry: def __init__(self): self._tools: Dict[str, Tool] = {} def register(self, tool: Tool) -> None: """注册工具，同名覆盖（便于测试）""" self._tools[tool.name] = tool def get(self, name: str) -> Optional[Tool]: """安全获取工具，返回 None 而非抛异常""" return self._tools.get(name) def list_all(self) -> Dict[str, str]: """返回 {name: description} 映射，供 LLM 工具发现""" return {name: tool.description for name, tool in self._tools.items()} def call(self, name: str, **kwargs) -> Dict[str, Any]: """统一调用入口：查工具→校验→执行→包装""" tool = self.get(name) if not tool: raise ValueError(f"工具未注册：{name}") try: validated = tool.validate_params(kwargs) result = tool.execute(**validated) return { "tool_name": name, "arguments": validated, "result": result, "status": "success" } except Exception as e: return { "tool_name": name, "arguments": kwargs, "error": str(e), "status": "error" } # 使用示例 registry = ToolRegistry() registry.register(WeatherTool()) # 模拟 LLM 输出的工具调用请求 llm_output = {"name": "get_weather", "arguments": {"city": "广州"}} response = registry.call(**llm_output)

这个ToolRegistry是第二版的灵魂。它解决了第一版的全部痛点：

• 动态注册：registry.register()让新工具接入只需一行代码；
• 安全发现：list_all()返回的字典可直接喂给 LLM 的tools字段，实现自动工具发现；
• 错误隔离：单个工具执行崩溃不会影响整个 registry，且错误结构统一，方便前端展示；
• 无状态设计：registry 本身不保存调用历史，符合函数式原则，易于水平扩展。

实操心得：我在某次模拟面试中故意让WeatherTool.execute()抛出TimeoutError，然后观察面试官反应。他立刻追问：“如果这个超时是网络问题，你如何避免阻塞整个 Agent 流程？” 我答：“第二版还没加熔断，但第三版我会用concurrent.futures.TimeoutError包装执行，并在call()中捕获后返回降级结果——比如缓存天气或提示‘服务暂时繁忙’。” 这个预判让他笑了，因为这说明我清楚架构演进的路径。

3.3 工具调用链路可视化：用日志还原真实决策过程

面试官常要求“演示一次完整调用”。我不会只写registry.call(...)，而是手绘一个带时间戳的调用链：

[0ms] LLM 输出: {"name": "get_weather", "arguments": {"city": "成都"}} [2ms] registry.get("get_weather") → 找到 WeatherTool 实例 [5ms] WeatherTool.validate_params({"city": "成都"}) → ✅ 通过 [8ms] WeatherTool.execute(city="成都") → 调用模拟函数 [12ms] 返回 {"city": "成都", "temperature": 25, "condition": "晴"} [15ms] registry.call() 包装为标准响应格式

这种写法传递两个信号：

• 我关注性能关键路径（毫秒级耗时）；
• 我把工具调用当成可观测系统，而非黑盒函数。

后来我才知道，某公司 Agent 平台的监控面板，就是按这个粒度打点的——他们真正在意的，不是你能不能写出来，而是你脑子里有没有“可观测性”这根弦。

4. 第三版：生产级增强——加入上下文感知、多工具协同与熔断降级

前两版解决了“能用”和“好管”，但离“能扛住线上流量”还差一层。第三版我聚焦三个生产环境刚需：

• 上下文感知调用：用户说“再查下昨天的”，工具需自动补全日期参数；
• 多工具串联：用户说“先查北京天气，再订明天的酒店”，需支持 pipeline；
• 稳定性保障：工具超时/报错时，不崩流程，有降级策略。

这版我不再手写全部代码，而是用伪代码+关键设计说明，重点讲清“为什么这么设计”和“线上踩过什么坑”。

4.1 上下文感知：用 ConversationState 管理跨轮次参数推导

用户很少说完整参数。典型场景：

• 第一轮：“查北京天气” →{"city": "北京"}
• 第二轮：“那上海呢？” → 应自动继承unit="celsius"，仅替换city

第一、二版都要求 LLM 每次输出完整参数，这既增加 LLM 负担，又易出错。第三版我引入ConversationState：

class ConversationState: def __init__(self): self.last_tool_result: Optional[Dict] = None self.user_preferences: Dict[str, Any] = {"unit": "celsius"} # 用户偏好 def infer_arguments(self, tool_name: str, partial_args: Dict) -> Dict: """根据历史结果和用户偏好，补全缺失参数""" full_args = self.user_preferences.copy() full_args.update(partial_args) # 特殊逻辑：如果工具是天气，且没传 date，则默认 today if tool_name == "get_weather" and "date" not in partial_args: full_args["date"] = datetime.now().strftime("%Y-%m-%d") return full_args # 调用时 state = ConversationState() state.infer_arguments("get_weather", {"city": "杭州"}) # → {"unit": "celsius", "city": "杭州", "date": "2024-06-15"}

这个设计的价值在于：把参数补全逻辑从 LLM 卸载到系统层。我们做过 AB 测试：开启上下文感知后，LLM 的arguments字段错误率下降 63%，因为 LLM 不再需要记忆“用户上次选的是华氏度”。

注意：面试中我强调，“上下文感知”不是万能的。比如用户说“把刚才的订单取消”，你得先判断“刚才”指哪个工具调用。所以ConversationState必须记录last_tool_call的完整 trace_id，而不是简单存结果。这点我被追问了两次，都答上来了。

4.2 多工具 Pipeline：用 ToolSequence 支持有序依赖执行

单工具调用是常态，但复杂任务需要编排。用户说：“帮我分析竞品 A 的财报，再对比我们 Q2 数据。” 这隐含两个工具调用：extract_financial_data→compare_quarterly，且后者依赖前者输出。

第三版我设计ToolSequence：

class ToolSequence: def __init__(self, steps: List[Dict[str, Any]]): # steps = [ # {"tool": "extract_financial_data", "args": {"company": "A"}}, # {"tool": "compare_quarterly", "args": {"baseline": "{step_0.result.revenue}"}} # ] self.steps = steps def execute(self, registry: ToolRegistry, state: ConversationState) -> List[Dict]: results = [] for i, step in enumerate(self.steps): # 解析 args 中的占位符，如 {step_0.result.revenue} resolved_args = self._resolve_placeholders(step["args"], results) # 调用工具 result = registry.call(step["tool"], **resolved_args) results.append(result) # 如果某步失败，是否继续？由 policy 决定 if result["status"] == "error" and not self.continue_on_error: break return results # 关键：_resolve_placeholders 如何实现？ def _resolve_placeholders(self, args: Dict, history: List[Dict]) -> Dict: # 递归替换 {step_i.field.subfield} 为 history[i]["result"]["field"]["subfield"] # 使用 jsonpath-ng 库或手动字符串解析 pass

这个设计直击要害：Pipeline 的核心不是执行，而是参数依赖解析。很多候选人写 pipeline 时直接result1 = call(...); result2 = call(..., data=result1)，这无法处理“取 result1 的某个字段”或“多个 result 合并”等场景。而ToolSequence强制你思考数据流的拓扑结构。

4.3 熔断与降级：用 CircuitBreaker 封装工具执行，拒绝雪崩

生产环境中，工具服务不可用是常态。第三版我加入熔断器：

import time from enum import Enum class CircuitState(Enum): CLOSED = "closed" # 正常调用 OPEN = "open" # 熔断中，直接返回降级 HALF_OPEN = "half_open" # 尝试恢复 class CircuitBreaker: def __init__(self, failure_threshold=5, timeout=60): self.failure_threshold = failure_threshold self.timeout = timeout self.failure_count = 0 self.last_failure_time = 0 self.state = CircuitState.CLOSED def call(self, func, *args, **kwargs): if self.state == CircuitState.OPEN: if time.time() - self.last_failure_time > self.timeout: self.state = CircuitState.HALF_OPEN else: return self._fallback() try: result = func(*args, **kwargs) self._on_success() return result except Exception as e: self._on_failure() raise e def _on_success(self): self.failure_count = 0 self.state = CircuitState.CLOSED def _on_failure(self): self.failure_count += 1 self.last_failure_time = time.time() if self.failure_count >= self.failure_threshold: self.state = CircuitState.OPEN def _fallback(self): return {"error": "服务暂时不可用，请稍后再试", "status": "fallback"} # 在 registry.call() 中集成 def call(self, name: str, **kwargs) -> Dict[str, Any]: tool = self.get(name) breaker = self._circuit_breakers.get(name, CircuitBreaker()) try: result = breaker.call(tool.execute, **kwargs) return {"tool_name": name, "result": result, "status": "success"} except Exception as e: return {"tool_name": name, "error": str(e), "status": "error"}

这个熔断器虽简，但覆盖了生产核心：

• 状态机驱动：CLOSED → OPEN → HALF_OPEN闭环，避免误熔断；
• 可配置阈值：failure_threshold和timeout可按工具重要性分级设置；
• 降级可控：_fallback()可返回缓存数据、静态文案或空结果，而非裸抛异常。

我分享一个真实教训：在某次压测中，天气工具因第三方 API 限频，1 分钟内失败 50 次，导致整个 Agent 流程卡死。上线熔断后，失败率归零，用户体验从“一直转圈”变成“提示服务繁忙”，NPS 提升 22 点。

5. 面试官最可能追问的 5 个致命问题及应答逻辑

写完三版，面试官大概率不会说“很好”，而是抛出几个直击设计盲区的问题。以下是我在 12 场同类面试中被问到频率最高的 5 个问题，附上我的应答思路——不是背答案，而是展示思考路径。

5.1 “你的 ToolRegistry 是单例吗？多线程下安全吗？”

这是典型的“从单机到分布式”思维跃迁题。我的回答分三层：

• 现状承认：当前版本是单例，但ToolRegistry本身无状态（不存 session、不改 internal dict），call()方法是纯函数式，天然线程安全；
• 隐患指出：唯一风险点是register()修改_tools字典，但注册通常在启动时完成，运行时极少调用；
• 方案升级：若需热加载，我会用threading.RLock()包裹register()，或改用concurrent.futures.ThreadPoolExecutor管理工具执行，registry 只负责路由。

关键话术：“线程安全不是目标，而是手段。我的目标是让工具调用延迟稳定在 50ms 内，所以优先用无锁设计；只有压测证明注册成为瓶颈时，我才加锁。”

5.2 “如果工具返回 HTML 或图片，你怎么塞进文本对话流？”

这题考的是多模态数据归一化。我的回答：

• 协议层：约定所有工具返回{"type": "text/json/image/html", "content": ...}结构；
• 渲染层：前端根据type字段决定渲染方式（文本直接显示，图片转<img>，HTML 用 iframe 沙箱）；
• 安全层：HTML 工具必须开启sanitize=True参数，用bleach库过滤 script 标签。

我补充：“曾有个工具返回富文本邮件，我们最初直接content.replace('<', '&lt;')，结果破坏了样式。后来改用html2text库转纯文本备选，确保降级可用。”

5.3 “LLM 有时会虚构工具名，比如调用不存在的get_stock_price，你怎么防？”

这是防御性编程考点。我的方案是三级拦截：

1. 前置拦截：在 LLM 输出解析阶段，用registry.list_all().keys()做白名单校验，不在列表中则拒掉；
2. 中置拦截：registry.get()返回None时，不抛异常，而是返回{"status": "unknown_tool", "suggestion": "您是否想查天气？"}；
3. 后置学习：收集所有unknown_tool请求，聚类分析（如“stock”高频出现），反哺 LLM 的 tools 列表更新。

实操技巧：我建议把list_all()的 description 做关键词提取（TF-IDF），当用户说“查股价”，自动匹配get_stock_price并提示“是否要查股票价格？”，转化率提升 40%。

5.4 “工具执行耗时 5 秒，但用户等不了，你怎么优化？”

这是用户体验与工程权衡题。我的回答结构化为：

• 异步化：用asyncio.to_thread()包装同步工具，避免阻塞事件循环；
• 流式响应：天气工具可先返回{"status": "running", "progress": "0%"}，再推送最终结果；
• 客户端超时：前端设 3 秒 timeout，超时后显示“后台处理中”，用户可继续对话；
• 结果缓存：对get_weather?city=北京这类请求，用redis缓存 10 分钟，命中率 82%。

我强调：“优化不是一味提速，而是管理预期。我们测过，用户对‘正在处理’的耐心是 8 秒，对‘已提交’的耐心是无限——所以优先做状态透出。”

5.5 “这三版代码，哪版你会放上生产？为什么？”

这是终极价值观题。我的答案毫不含糊：

• 第一版：仅用于 PoC 或教学，因为它把所有东西耦合在函数里，改一个参数要动三处；
• 第二版：是我们的灰度发布基线，ToolRegistry已支撑 37 个工具，日均调用 200 万次；
• 第三版：正在 A/B 测试中，ConversationState和CircuitBreaker已上线，但ToolSequence因复杂度高，只对 VIP 客户开放。

最后我补一句：“没有银弹版。我们用第二版保稳，用第三版探新，用第一版快速验证——这才是工程思维。”

6. 给正在准备面试的你的三条硬核建议

写完这三版，我回头看了眼白板，上面密密麻麻全是箭头、括号和被划掉的变量名。这不像在写代码，更像在画一张作战地图：每个函数是据点，每个类是防线，每个设计取舍都是资源调配。面试官要的从来不是完美代码，而是你脑子里那张图是否清晰、是否经得起推演。

基于这十几场实战，我给你三条不废话的建议：

第一条：永远先问约束，再写代码。
别急着炫技。开口第一句应该是：“请问这次手写，对第三方库、异步支持、错误处理粒度有什么要求？” 这句话能帮你避开 70% 的无效劳动。我见过太多人埋头写 Pydantic，结果面试官说“只能用原生 dict”，最后 10 分钟狂删重写。

第二条：用注释代替代码，展示设计意图。
白板空间有限，与其写满try...except，不如在关键行旁标注// 这里做熔断，防止下游雪崩。面试官看的是你的系统观，不是语法熟练度。我第三版的熔断器只写了 15 行核心逻辑，其余用注释说明状态流转条件，反而拿了最高分。

第三条：准备一个你踩过的坑，讲清根因和修复。
比如：“我们曾用eval()动态调用工具，结果用户输入__import__('os').system('rm -rf /')，直接删了日志目录。后来改成白名单函数映射，加了沙箱进程隔离。” 这种故事比任何设计都真实有力——它证明你写的不是玩具，而是真刀真枪干过的活。

最后说句掏心窝的：手写 Tool Use 不是考你多厉害，而是考你多诚实。诚实面对自己的知识盲区，诚实承认设计的 trade-off，诚实说出“这部分我还没实践过，但我的思路是……”。真正的资深，不是无所不知，而是知道边界在哪，并有跨越边界的路径。