大模型为什么会使用工具

这篇笔记不讨论“模型是不是聪明”，只讨论一个工程事实：大模型本身只负责生成文本，工具调用把它接到真实系统上，让它能查资料、跑代码、读文件、调用 API，并根据结果继续推理。

这篇笔记怎么读

• 先看工具调用的基本闭环：模型提出调用请求，应用层执行工具，再把结果交回模型。
• 再看 Agent Loop：工具调用一旦进入多轮循环，就从“回答问题”变成“执行任务”。
• 最后看边界：工具能提高可靠性，但权限、上下文、解析错误和外部系统状态仍然需要工程约束。

工具调用解决什么问题

纯语言模型有几个稳定短板：

• 知识滞后：模型参数里的知识有截止时间，无法天然知道实时状态。
• 无法行动：模型不能自己发请求、读数据库、改文件或启动服务。
• 计算不可靠：复杂计算、格式转换和精确检索不适合只靠自然语言生成。
• 容易编造：没有外部证据时，模型可能生成看似合理但无法验证的答案。

工具调用的价值不是“让模型变成程序”，而是让模型成为一个调度者：识别任务、选择工具、组织参数、读取结果，再生成下一步判断。

一次工具调用的最小闭环

最小流程可以拆成五步：

1. 用户提出任务，例如“查一下北京今天的天气”。
2. 模型判断自己需要外部信息，生成结构化调用请求。
3. 应用层解析请求，真正调用天气 API。
4. 应用层把 API 返回结果放回上下文。
5. 模型基于真实结果组织回答。

关键点在第 2 步和第 4 步：模型并不直接访问 API，它只输出一个可被程序解析的调用意图；工具结果也不是“自动进入模型脑子里”，而是被应用层追加到下一轮上下文。

工具说明书：模型怎么知道能用什么

调用工具前，应用层会把工具列表交给模型。每个工具通常包括：

• 工具名：例如 get_weather。
• 功能描述：说明什么时候该用它。
• 参数结构：例如 location: string。
• 返回格式：让模型知道结果大概长什么样。

模型看到的不是一个真实函数，而是一份接口说明。它要做的是把自然语言任务翻译成符合接口约束的结构化请求。

Function Calling 与普通 Prompt 的区别

普通 Prompt 让模型直接生成文本；Function Calling 要求模型在合适的时候输出结构化调用。

区别主要在三点：

• 输出目标不同：普通回答面向人，函数调用面向程序解析。
• 失败形态不同：普通回答错在内容，函数调用还可能错在参数、工具选择和调用顺序。
• 工程责任不同：模型只负责提出调用请求，权限控制、执行、重试、日志和错误处理都在应用层。

因此，工具调用系统的可靠性取决于模型能力，也取决于外层工程设计。

Agent Loop：从一次调用到多步任务

当任务需要多轮执行时，系统通常会进入 Agent Loop：

1. Observe：读取当前上下文、文件、网页或错误日志。
2. Plan：判断下一步要查什么、改什么、跑什么。
3. Act：生成工具调用请求。
4. Execute：应用层执行工具。
5. Revise：根据结果修正计划，继续下一轮。

这也是 Codex、自动化浏览器、RAG Agent 等系统的共同结构。模型每一轮都只做一次局部决策，长任务靠外部循环串起来。

Tool、MCP、Skill 的边界

这几个概念容易混在一起：

• Tool：具体可调用能力，例如读文件、查网页、跑命令。
• MCP：一种把外部工具、资源和协议暴露给模型应用的标准接口。
• Skill：写给 Agent 的操作手册，告诉它在某类任务中如何组织步骤。

Tool 偏执行，MCP 偏连接协议，Skill 偏行为指导。真正的 Agent 系统往往三者都会用。

为什么工具调用仍然会失败

常见失败点有：

• 工具描述太模糊，模型不知道何时调用。
• 参数结构复杂，模型填错字段。
• 工具返回太长，关键结果被上下文淹没。
• 外部系统状态变化，例如网页改版、接口限流、文件不存在。
• 权限边界不清，模型提出了不该执行的动作。

这些问题不能只靠“换更强模型”解决，需要靠接口设计、结果压缩、日志、重试、沙箱和人工确认来兜底。

设计工具调用时的实践原则

• 工具粒度要清楚：一个工具只解决一个边界明确的问题。
• 参数尽量结构化：不要让模型在长字符串里塞复杂协议。
• 返回结果要短：只返回下一步决策需要的信息。
• 高风险动作要确认：删除、付款、发信、改生产配置都应该有人工确认。
• 失败要可见：错误码、stderr、日志摘要要进入上下文。

小结

工具调用让模型从“生成答案”进入“参与流程”。它的核心不是神秘能力，而是一个工程闭环：模型负责判断和组织，应用层负责执行和约束，外部反馈再进入下一轮推理。

真正值得关注的是闭环质量：工具说明是否清楚、执行是否可靠、结果是否可压缩、权限是否收紧、失败是否能被发现。做好这些，模型才更像一个可用的工程助手。