面试官问你："Agent 怎么知道该调用哪个工具？"如果你脱口而出"用路由规则做匹配"，那这道送分题，你就完蛋了。

为什么？

因为 Agent 根本不做工具选择。选择权在 LLM 手里。

哈喽大家好，我是二哥呀。今天用 3 分钟，带你拆透这道面试题背后的潜台词。

拿到这种题，别急着给答案。先想清楚面试官到底考什么。

他问"Agent 怎么知道调用哪个工具"，表面在问流程，实际在考察三个东西：

第一，Agent 和 LLM 之间的职责边界你清不清楚；第二，底层 Function Calling 协议的原理你懂不懂；第三，你有没有真实项目里的踩坑经验。

好，接下来给你满分回答，照着背就完事了。整个流程分七步。

第一步，工具注册。系统启动时，ToolRegistry 会把所有可用工具注册成一张列表。每个工具必须带三样东西：名称、描述、参数的 JSON Schema。比如天气查询工具，名称叫 query-weather，描述写"查询指定城市的天气"，参数就一个——城市名。

第二步，构建请求。用户问了句"北京天气怎么样"，Agent 把对话历史加上完整的工具定义列表，一起塞进 LLM 接口的 tools 字段。注意，是全量工具定义，不是只传名字。

第三步，LLM 决策。模型拿到这些信息后，自己读描述、自己判断——要不要调工具、调哪个、参数填什么。这一步完全是 LLM 在做，Agent 不参与。

第四步，返回 tool_calls。LLM 在响应里返回一个 tool_calls 数组，写得清清楚楚：工具名 query-weather，参数 city 等于"北京"。这就是 OpenAI 最早定义的 Function Calling 协议，DeepSeek、GLM、Kimi 全都兼容。

第五步，执行调用。Agent 拿到 tool_calls，从注册表里找到对应的函数，直接调，拿到结果："晴，28℃"。

第六步，回填历史。把这个结果包装成一条 role 为 tool 的消息，塞回对话历史。这一步很关键，因为 LLM 需要看到工具的返回值，才能继续往下走。

第七步，生成回答。LLM 读到工具结果，把"晴，28℃"润色成自然语言，回复用户："北京今天天气晴，气温 28 度，适合出门。"

到这里，一轮完整的工具调用就跑完了。

但如果面试官继续追问："万一 LLM 返回了一个根本不存在的工具名，怎么办？"

标准答案是这样的——ToolRegistry 在执行时会做兜底校验，找不到就返回"未知工具：xxx"。这条报错会被包装成工具消息，塞回对话历史。重点来了：LLM 下一轮看到这个报错，会自动修正，换一个正确的工具重新调用。

但如果模型反复返回不存在的工具名，那就不是兜底逻辑能解决的问题了。这时候你要自信地告诉面试官："这说明工具描述或 system prompt 本身有歧义，应该优化 prompt。"这句话一出口，面试官就知道你是真写过项目的。

最后送大家一句口诀，面试时直接说出来——Agent 只管打包注册，由 LLM 做意图决策；描述定生死，兜底看反馈，反复出错必定是 Prompt 的锅。

这道题你学废了吗？想解锁更多 Agent 面试题的源码级拆解，点赞关注，我是二哥，下期见！