为什么现在值得写
上周五晚上十点半，有个读者发来微信，说他在一家头部大厂的 AI 岗一面挂了，心情很郁闷。
他觉得自己项目经验挺丰富，RAG 也讲得头头是道，结果栽在了一个看似基础的点上：Tool Calling。
面试官让他现场设计一个查询积分并处理异常的流程，他支支吾吾画了个流程图，却被追问得冷汗直流，最后连自己都不知道在画什么。
异常直接甩脸上了
Tool Calling 就像给一辆法拉利装了个自行车刹车——跑得是快，但停不下来，还容易翻车。很多候选人以为会调 API 就算掌握，但在面试官眼里，这恰恰是区分“调包侠”和“工程师”的分水岭。
现在的 AI 岗位市场，一面通过率低得离谱。半年前，你会调 OpenAI 的接口可能就能过初筛；现在，面试官要的是工程化落地能力，是你在系统出问题时能不能兜底的底气。
Tool Calling 作为 Agent 与现实世界交互的核心触手，自然成了必考题。如果你还没把它的工程边界想清楚，现在的每一次面试，其实都是在碰运气。
拆开讲透
问题：那个让很多人挂在一面的问题
面试官放下简历，看着你的眼睛，抛出了那个问题：
“如果我要你设计一个 Tool Calling 流程，用于查询用户积分，并且在查询失败时进行异常处理，你会怎么设计？请详细描述参数传递和错误重试的逻辑。”
听起来不难，对吧？不就是写个函数让大模型调一下吗？
但魔鬼藏在细节里。面试官不是在考你怎么写 Python 函数，而是在考你有没有“边界感”。他想知道的是：当 LLM 开始胡说八道时，你的系统能不能活下来；
当接口超时的时候，你的重试机制会不会把数据库搞崩。
很多候选人一上来就开始写代码，完全忽略了结构化的设计。这就像还没看地图就猛踩油门，方向错了，开得越快死得越快。
标准答案：不仅仅是调用函数
要接住这一招，你得先明白 Tool Calling 的本质：它不是让 LLM 直接干活，而是让 LLM 生成“干活的指令”。
真正的执行权永远在你的应用层手里。一个标准的 Tool Calling 闭环，其实就三步：结构化参数生成、应用层执行、结果回传。
首先，LLM 根据你的提示词和工具描述，生成一个结构化的 JSON 对象，里面包含了要调用的函数名和参数。注意，这里只是生成，不是执行。
锅先背上，工先继续打
LLM 就像个只会写便利贴的指挥官，真正的活儿还得靠下面的兵（你的代码）去干。
其次，你的应用层拿到这个 JSON，解析它，校验它，然后执行真正的函数调用。这一步是工程化的核心，也是最容易出bug的地方。
最后，把执行结果（或者报错信息）再扔回给 LLM，让它组织自然语言回复给用户。
看看下面这段简化的请求体，你就知道这玩意儿长什么样了：
{
"model": "gpt-4o",
"messages": [
{"role": "user", "content": "查询用户 12345 的积分"}
],
"tools": [
{
"type": "function",
"function": {
"name": "query_user_points",
"description": "查询指定用户的当前积分余额",
"parameters": {
"type": "object",
"properties": {
"user_id": {
"type": "string",
"description": "用户唯一标识 ID"
}
},
"required": ["user_id"]
}
}
}
]
}
为什么一面必问：考察你的工程边界感
面试官为什么要在一面问这个？因为这是考察你“工程边界感”最高效的方式。
大模型是个黑盒，它不可控。你永远不知道它下一秒是给你一个完美的 JSON，还是突然开始给你背唐诗。Tool Calling 的难点，从来不在调用本身，而在防御。
第一，JSON Schema 校验。LLM 生成的参数格式不对怎么办？user_id 传了个中文怎么办？
如果你不做校验直接丢给数据库，这就是一个潜在的 SQL 注入漏洞。面试官想看的是，你有没有在应用层加一把锁。
第二，上下文管理。Tool 的描述也是要占 Token 的。如果你一股脑把几十个工具全塞进 Prompt，还没开始干活，上下文窗口就爆了。怎么动态选择工具，怎么精简描述，这都是实打实的工程取舍。
第三，安全性控制。有些操作是不能让 LLM 随便调的，比如“删除数据库”。你有没有权限控制？有没有“人工确认”的环节？
这些都不是算法问题，是系统设计问题。面试官问 Tool Calling，其实是在问你：如果系统挂了，你知道它会在哪里挂，以及怎么挂得体面吗？
还没解释就先被安排转身背锅时的表情
常见追问：连环炮怎么接
如果你答完了上面那些，以为这就结束了？太天真了。面试官的连环炮才刚刚开始。
追问一：如果 LLM 生成的参数格式错误，你的系统怎么处理？
这里有个坑。很多人会说“报错返回”。但更好的做法是，把错误信息回传给 LLM，让它自己修正。
这就像你让实习生填表，填错了你骂他一顿没用，你得把表扔回去告诉他哪里错了，让他重填。这就是 Self-Correction（自我修正）机制。
追问二：如果有多个工具都可以解决问题，LLM 怎么选择？
这考察的是你对 Tool 描述的精细化程度。LLM 选工具全靠看描述。如果两个工具描述差不多，它就会“精神分裂”。你得通过更精准的描述，或者引入一个 Router 层来分发任务。
追问三：Tool Calling 和 RAG 结合时，上下文怎么管理？
这是高阶题。RAG 检索回来的文档可能很长，再加上 Tool 的定义，上下文很容易溢出。你需要做取舍：是截断文档，还是只保留 Tool 的关键参数定义？
这取决于你的业务场景是更依赖检索结果，还是更依赖工具调用的准确性。
易错点：别把 LLM 当数据库
最后说两个典型的“自杀式回答”。
第一，混淆执行主体。很多人在描述流程时，会说“LLM 查询数据库”。大错特错。
LLM 永远不会直接碰你的数据库，它只是生成了一个查询指令，真正去查的是你的后端代码。这个概念如果不清晰，面试官直接就会把你归类为“不懂架构”。
第二，Tool 描述过于复杂。恨不得把整个业务逻辑都写在 description 里。结果 LLM 被绕晕了，动不动就幻觉。
好的 Tool 描述应该像好的 API 文档：简单、清晰、无歧义。写太长，不仅费 Token，还费脑子。
写在最后
Tool Calling 这块硬骨头，早晚得啃下来。它不仅是面试的必考题，更是你从“玩模型”走向“做系统”的第一步。
别光盯着 API 文档看，自己动手写一个 Demo，故意传错参数，故意制造超时，看看你的系统能不能优雅地报错。工程能力，都是在翻车现场练出来的。
你在 Tool Calling 上踩过最惨的坑是什么？欢迎在评论区分享你的翻车故事。
参考文献
OpenAI Platform Documentation: Function Calling
LangChain Docs: Tools and Toolkits
《Building LLM Apps: A Guide to Tool Use》
如果你想继续追更，欢迎在公众号 计算机魔术师 找到我。后续的新稿、精选合集和阶段性复盘，会优先在那里做串联。
