加载中...
大模型的工具使用（Tool Use）是大模型落地中最有价值、也最具挑战的路径之一：它让模型从"会说"跃升到"能做"，将自然语言理解与真实系统的查询、计算、执行真正连接起来。这条路径的标志性起点，是 OpenAI 在 2023 年推出的 Function Calling——模型在对话中自主决定调用哪些工具，并基于返回结果继续推理与决策。
随着 AI Agent 尝试解决的任务复杂度持续攀升（更多步骤、更长链路、海量数据、强时序依赖），工具使用范式也在快速演化。本文将这条演进路径划分为三个阶段：
欢迎关注 DataLearner 官方微信，获得最新 AI 技术推送
这条演进路径揭示了一个趋势：编排逻辑从"模型逐步决策"转向"计划驱动、代码驱动"，中间结果的处理从"全部塞进上下文"转向"执行侧预先消化"。这不仅显著提升了复杂任务的吞吐效率和成本控制，也带来了新的工程挑战——如何在可控性与灵活性之间找到平衡。
本文将通过直观的流程图和对比表，梳理这三种模式的核心差异、适用场景与工程实践要点，期待与大家探讨。
工具使用的核心思想很直观：让大模型在生成文本之外，获得与外部系统交互的能力。当用户问"今天北京天气如何"，模型不再只能说"我不知道实时信息"，而是可以调用天气 API 获取数据后再作答；当用户要求"帮我分析这份销售数据的趋势"，模型可以调用 Python 解释器执行计算，而不是凭空臆测数字。这种"理解意图 → 选择工具 → 获取结果 → 综合回答"的闭环，是工具使用的基本形态。
早期实践中，单次查询、单个工具调用就能解决大部分问题——查天气、查汇率、简单计算。但随着应用场景深入，任务复杂度迅速攀升：用户可能要求"对比过去三年的销售数据，找出增长最快的品类，并生成可视化报告"，这需要模型依次调用数据库查询、数据处理、图表生成等多个工具，甚至需要根据中间结果动态决定下一步。传统的"一问一答式"工具调用开始暴露出效率瓶颈、成本压力和可控性问题。正是这些痛点，推动了工具使用范式从简单到复杂的演进。
本文将这条演进路径归纳为三个阶段，但需要强调的是：这三个阶段并非线性替代关系，而是针对不同复杂度任务的最优解。对于简单的单步查询（如查天气、查汇率），循环式工具选择依然是最直接、成本最低的方案；对于需要明确步骤但步骤间依赖较弱的任务（如"查资料 + 总结 + 翻译"），计划驱动执行能显著提升并行效率;而对于涉及大规模数据处理、复杂过滤聚合的任务（如"从数万条日志中提取异常模式并生成报告"），程序化工具编排则能避免上下文爆炸、大幅降低延迟与成本。选择哪种模式,取决于任务的步骤数量、数据规模、依赖关系与实时性要求,而不是简单的"新技术替代旧技术"。
接下来,我们将逐一拆解这三个阶段的技术实现方式与核心特点,并通过对比表和实际案例,帮助你在工程实践中做出更合理的选择。
循环式工具选择是最直观的工具使用范式，其核心逻辑可以用一句话概括：模型决策 → 执行工具 → 模型再决策，如此循环往复。用户输入问题后，模型会收到一份可用工具清单（包含工具名称、参数描述、功能说明），然后判断是否需要调用工具。如果需要，模型会输出结构化的调用请求（比如 get_weather(city="北京", date="明天")），应用层拿到这个请求后去执行真实的 API 调用或代码运行，再把结果以文本形式追加回对话历史。模型看到新结果后继续推理，决定是调用下一个工具，还是直接生成最终答案。
OpenAI 的 Function Calling API 就是这种模式的经典实现。开发者在请求中声明工具列表，模型返回 tool_calls 字段告诉你要调哪个工具、传什么参数，你执行完把结果以 tool 角色消息送回去，模型继续处理。整个过程就像一场"乒乓对话"：你来我往，每一轮模型只能看到过去的所有对话和上一次工具的结果。
举个具体例子：用户问"帮我查一下北京明天的天气，如果会下雨就提醒我带伞"。第一轮，模型决定调用 get_weather(city="北京", date="明天")，工具返回 {"temperature": 15, "condition": "小雨"}；第二轮，模型看到这个结果，生成最终回答："北京明天15°C，有小雨，记得带伞哦"。整个过程清晰可控，调试起来也很直观。
这种模式的优势和局限都很明显。先说优势：
但局限也同样突出：
因此，循环式工具选择最适合以下场景：
典型案例包括智能客服（查订单 → 查物流）、简单的数据查询助手、代码执行与纠错等。但当任务步骤增多、数据规模增大时，这种"逐步决策"的模式就开始暴露效率问题了——这也正是阶段二"计划驱动执行"要解决的痛点。
循环式工具选择的一个核心问题在于"边走边看"：模型每次只能看到上一步的结果，然后决定下一步。这对于高度不确定的任务是优势，但对于步骤相对明确的任务却是效率杀手。比如用户要求"对比过去三年的销售数据，找出增长最快的品类，并生成可视化报告"——这个任务的步骤其实很清楚：查询数据 → 计算增长率 → 排序筛选 → 生成图表。但在循环模式下，模型必须等第一步查完数据、看到结果后，才能决定第二步；第二步算完增长率后，才能决定第三步。每一步都要完整推理一次，串行等待，延迟线性叠加。
计划驱动执行试图打破这个瓶颈：让模型先看清全局，生成一个完整的执行计划，然后再按计划执行，并支持并行调度与动态调整。具体流程是这样的：模型收到任务后，先不急着调用工具，而是基于任务需求和可用工具，输出一个结构化的执行计划（plan），明确列出需要哪些步骤、每一步调用什么工具、步骤之间的依赖关系（哪些可以并行、哪些必须串行）。应用层拿到这个计划后，交给执行引擎（executor）按依赖关系调度：没有依赖的步骤可以并行执行，有依赖的步骤等前置完成后再执行。所有步骤完成后，将结果汇总返回模型，模型基于全部结果生成最终答案——如果发现计划有问题或结果不符合预期，还可以要求模型调整计划、重新执行。
以刚才的销售数据分析为例。在计划驱动模式下：
第一阶段（Planning）：模型生成计划
1. query_database(sql="SELECT category, year, sales FROM sales WHERE year >= 2022")
2. calculate_growth_rate(data=step1.result) # 依赖步骤1
3. sort_and_filter(data=step2.result, top_n=5) # 依赖步骤2
4. generate_chart(data=step3.result, type="bar") # 依赖步骤3
第二阶段（Execution）：执行引擎按依赖关系调度，步骤1执行完后，步骤2、3、4依次执行（如果有多个无依赖步骤可以并行）
第三阶段（Synthesis）：将所有结果返回模型，模型生成最终报告："根据数据分析，过去三年增长最快的品类是电子产品（年均增长32%），以下是可视化图表……"
这种模式相比循环式的改进是显著的：
但这种模式也不是万能的，它带来了新的复杂度：
因此，计划驱动执行最适合以下场景：
典型案例包括：复杂的数据分析任务、多源信息聚合（比如对比多个电商平台的价格）、文档处理流水线等。目前不少 Agent 框架（如 LangGraph、AutoGPT）都在实现类似的计划-执行模式。
但问题还没有完全解决。当任务涉及大规模数据处理（比如"从1万条日志中提取异常模式"），即使做了并行优化，把所有中间结果都传回模型依然不现实——这就引出了第三阶段的核心思想：既然模型处理大规模数据吃力，为什么不把数据处理逻辑直接交给代码？
计划驱动执行解决了并行调度的问题，但有一个根本矛盾它始终无法回避：中间结果的上下文爆炸。想象这样一个场景：用户要求"分析过去一个月的服务器日志，找出所有响应时间超过5秒的请求，统计它们的来源IP分布，并生成top10列表"。即使你用了计划-执行模式，查询日志可能返回1万条记录，过滤后还有500条，这些数据全部传回模型会占用几十万tokens——不仅成本高昂，模型处理起来也慢且容易出错。更关键的是，这些"过滤、循环、聚合"的逻辑本身非常机械，根本不需要模型的推理能力，却在消耗大量的推理资源。
程序化工具编排的核心思想很激进：既然模型擅长理解意图和生成逻辑，代码擅长执行循环和处理数据，那就让模型生成可执行代码，把多工具调用的编排逻辑完全交给代码。具体来说，模型不再输出"调用工具A → 调用工具B → 调用工具C"这样的步骤序列，而是直接生成一段Python（或其他语言）代码，这段代码里包含了所有的工具调用、循环、条件判断、数据过滤与聚合逻辑。应用层将这段代码放到沙箱环境中执行，代码可以自由调用工具、处理大规模数据、进行复杂计算，最后只把关键的摘要结果（比如top10列表、汇总统计）返回模型。模型基于这个精简的结果生成最终答案。
还是以刚才的日志分析为例。在程序化工具编排模式下：
第一步（Code Generation）：模型生成代码
# 查询日志数据
logs = query_database("SELECT * FROM server_logs WHERE timestamp >= NOW() - INTERVAL 30 DAY")
# 过滤响应时间超过5秒的请求
slow_requests = [log for log in logs if log['response_time'] > 5]
# 统计来源IP分布
ip_counts = {}
for req in slow_requests:
ip = req['source_ip']
ip_counts[ip] = ip_counts.get(ip, 0) + 1
# 排序并取top10
top10 = sorted(ip_counts.items(), key=lambda x: x[1], reverse=True)[:10]
# 返回结果摘要
result = {
"total_slow_requests": len(slow_requests),
"top10_ips": top10,
"sample_request": slow_requests[0] if slow_requests else None
}
第二步（Execution）：代码在沙箱中执行，处理1万条日志、过滤、聚合，最后只返回一个几百字节的摘要
第三步（Synthesis）：模型收到摘要（而不是1万条原始记录），生成报告："过去30天共有327次慢请求，来源主要集中在以下10个IP……"
这种模式的改进是革命性的：
但这种模式也带来了新的挑战：
因此，程序化工具编排最适合以下场景：
典型案例包括：日志分析、大规模数据清洗与转换、批量文件处理、复杂的数学建模与仿真等。Anthropic最近推出的Extended Thinking + Tool Use、OpenAI的Code Interpreter升级版，都在朝这个方向演进。
值得注意的是，程序化工具编排并不意味着完全替代前两种模式。实际工程中，很多系统会混合使用：对于简单查询用循环式，对于多步明确任务用计划驱动，对于数据密集型任务用程序化编排。选择哪种模式，归根结底取决于任务的复杂度、数据规模、实时性需求以及你愿意承担的工程复杂度。
这里给一个简单的对比表格总结三种不同的模式：
从循环式工具选择到计划驱动执行，再到程序化工具编排，大模型的工具使用正在从"会调工具"走向"会编排系统"。这条演进路径背后的核心逻辑很清晰：把模型擅长的事情（理解意图、生成逻辑）和代码擅长的事情（执行计算、处理数据）分离开来，各司其职。循环式给了我们灵活性，让模型可以"走一步看一步"；计划驱动带来了全局视角和并行能力；程序化编排则彻底解放了上下文，让模型不再被数据规模束缚。
但需要再次强调的是：没有一种模式适合所有场景。上面的对比表不是在告诉你"应该用哪个"，而是在帮你理解"什么时候用哪个"。查个天气、问个订单状态，循环式足够了，简单高效；做数据分析、处理文档流水线，计划驱动能帮你省时间；分析海量日志、批量处理文件，程序化编排才能撑得住。实际工程中，很多优秀的 Agent 系统会根据任务特征动态选择模式，甚至在一个任务中混合使用——这才是成熟的工程实践。
工具使用的演进还远未结束。随着模型推理能力持续增强、执行环境越来越安全可靠、多模态工具逐渐成熟，我们可能会看到更激进的模式出现——比如模型直接生成完整的微服务、自主管理长期运行的后台任务、甚至跨系统的自动化编排。但无论技术如何演进，核心问题始终是那个：如何让 AI 更高效、更可靠地与真实世界交互。
| 高（需沙箱、错误处理、安全机制） |
| 适合数据规模 | 小（KB级） | 中（KB到MB级） | 大（MB到GB级，只返回摘要） |
| 典型场景 | 查天气/汇率、智能客服、代码调试等简单查询 | 数据分析流程、多源信息聚合、文档处理流水线 | 日志分析、大规模数据清洗、批量文件处理 |