完整题目
请系统阐述大语言模型实现外部工具调用（Tool Use / Function Calling）的主要技术路径与架构方案，包括提示工程、微调、代理框架等方法的典型流程、适用场景、优劣对比，并分析其在构建智能Agent中的核心作用及面临的关键挑战。
本文目录
一、三大技术路径对比
| 方法 | 核心机制 | 适用场景 | 优劣势 |
|---|---|---|---|
| 提示工程 | 在prompt中嵌入工具描述（JSON Schema），靠ICL能力生成调用 | 工具少、调用简单、快速上线 | 零成本，但复杂场景易幻觉、格式不稳定 |
| 微调增强 | 用<tool_call>标注数据SFT，训练模型输出结构化调用 | 工具多、领域专用、高稳定性要求 | 准确率高，但需标注数据、灵活性差 |
| 代理框架 | ReAct/Plan-and-Execute循环，LLM作为推理引擎决策 | 多步推理、动态规划、复杂Agent | 可解释性强，但延迟高、成本高 |
二、Function Calling标准流程
用户Query → 工具描述注入Prompt → LLM生成调用JSON
→ 解析参数 → 执行工具 → 结果回传 → LLM整合输出关键设计点：
- Schema设计：name/description/required/properties四要素，description质量直接决定调用准确率
- 并行调用：支持一次返回多个tool_calls数组，提升效率
- 错误处理：区分参数错误（重试生成）、工具异常（降级回答）、超时（熔断）
三、在Agent中的核心作用
工具调用是Agent的**"行动器官"**，实现：
- 感知-行动闭环：打破LLM知识边界，实时获取信息（搜索、DB、API）
- 能力扩展：代码执行、文件操作、第三方服务集成
- 自主决策：结合ReAct实现"思考→行动→观察"的自主循环
四、关键挑战
- 幻觉调用：模型虚构不存在的工具或参数 → 严格Schema校验+拒识机制
- 上下文爆炸：多轮调用历史累积 → 工具结果摘要压缩、滑动窗口
- 安全边界：工具权限管控、沙箱执行、敏感操作人工确认
- 延迟成本：同步调用阻塞响应 → 异步流式返回、工具预执行
选型建议：简单场景提示工程起步，生产环境关键路径上微调，复杂Agent必用框架编排。
学习建议
建议从Prompt设计入手，理解Function Calling格式定义，再结合LangChain等框架实践Agent工作流，最后通过项目对比不同技术路径的优缺点。
换一种问法，检查是否真正理解
场景切入
假设你要做一个智能客服，用户问“帮我查一下上周的订单”，你需要调用订单API。你怎么让模型知道该调用哪个工具、传什么参数？如果工具很多，怎么保证它不出错？
层层追问
你怎么让大模型去调用外部工具？……提示工程够用吗？……如果工具一多就不稳定了，你怎么办？……那再进一步，要是涉及多步推理，比如先查库存再下单，你打算怎么设计整个流程？
直球架构
请系统说一下大模型实现工具调用的几种技术路径，比如提示工程、微调、代理框架，每种的核心流程、适用场景和优缺点，以及它们在构建Agent中的作用和关键挑战。
练习口述回答 · 约4分钟
- 一句话定位：工具调用是Agent的桥梁
- 三大路线：提示工程、微调、框架
- 业务落地举例：客服退款场景
- 关键挑战与取舍
- 给出可延伸点：MCP协议
这道题其实在问，怎么让大语言模型真正动起来，不光会聊天，还能调用外部工具去干活。本质上，是把LLM从纯语言模型变成能执行动作的[[Agent]]，这里的技术路线可以分成三大类，各有各的适用边界，而且真正落地时往往是混着用的。
先说最简单的，提示工程。就是在system prompt里把工具描述写成JSON Schema，靠模型的[[In-Context Learning]]能力让它自己决定什么时候调用、传什么参数。好处是零成本，改个prompt就能上线，但问题也很明显，模型容易[[幻觉]]，可能编造不存在的工具名或者参数格式，而且复杂场景下输出不稳定，经常抽风。所以它特别适合工具少、调用简单、快速验证的场景，比如一个天气查询API，或者简单的计算器。
再一个就是微调。用标注好的<tool_call>数据做[[SFT]]，让模型学会输出结构化的调用指令。这招准确率高，尤其当工具数量多、或者有领域专用工具时，微调后的模型几乎不会瞎调用。但代价也大，需要高质量的标注数据，而且灵活性差，加一个新工具就得重新微调。所以，它更适合生产环境里那些高频、固定的关键路径，比如电商的库存查询、支付接口这类。
最后是代理框架，典型的就是[[ReAct]]或者Plan-and-Execute循环。LLM只当推理引擎，每一步决定下一步要调用什么工具、解析结果、再思考下一步。可解释性强，能看到它每一步的推理过程，但延迟和成本都高，因为每一步都得调一次模型。适合复杂多步任务，比如智能客服要查订单、退款、通知物流，这种需要拆成好几个动作的。
举个例子，客服退款场景。用户说“我买的东西没收到，要退款”。如果只用提示工程，模型可能直接调用退款API，但没查订单状态，如果订单是已签收状态，退款就会失败。用代理框架的话，模型先调用订单查询工具，发现状态是“运输中”，然后调用客服备注工具，最后才决定是否发起退款。每一步都有推理，更稳健。但实际落地时，我通常会把高频、确定性的操作（比如查订单状态）做微调，保证速度和准确率；复杂的多步决策交给框架去编排。说白了，提示工程管快，微调管准，框架管复杂。
这里有个坑要特别注意：工具调用的上下文爆炸。多轮调用下来，每次返回的结果都塞进prompt里，很快就把上下文窗口撑爆了。我的做法是对工具返回结果做摘要压缩，或者用[[Sliding Window]]只保留最近几轮的关键信息。另外，安全边界也得提前想好，工具权限要最小化，敏感操作比如退款、删除数据，必须加人工确认。
所以，我会把工具调用看成Agent的“行动器官”，没有它，LLM就是个纸上谈兵的参谋。选型上，我的经验是：简单场景用提示工程快速验证，生产环境的关键路径上微调，复杂Agent必用框架。如果面试官你感兴趣，还可以聊聊最近比较火的[[MCP]]协议，它试图标准化工具定义和调用流程，解决多工具、多Agent协作的问题。