工具调用：让 Agent 从“说”到“做”

聊天机器人只能告诉你“怎么订机票”；Agent 能真的去查、去比价。让 Agent 从“说”跨越到“做”的关键技术，叫工具调用。

前面两篇讲了 Agent 的循环和上下文。今天讲循环里最关键的“行动”环节——工具调用（Tool Use / Function Calling）。

它解决的是一个核心问题：大模型只会输出文本，但真实世界靠文本动不了。

要让 Agent 真的干活，必须给它一双手。

一、从“告诉我”到“帮我做”

你问 ChatGPT“今天北京天气怎么样”，它可能会说“我无法获取实时天气数据”。

如果你给 Agent 接上一个天气 API 工具，它就可以：

1. 思考：用户问天气 →
2. 决定调用天气 API →
3. 拿到实时数据 →
4. 组织语言回复你。

这个“调用天气 API”的动作，就是工具调用。

工具调用让模型不再只输出文字，而是输出“我要调用某个函数、参数是这些”。 真正执行这个函数的，是外部代码。

二、工具调用的机制

工具调用的流程其实不复杂：

1. 开发者定义工具：给一个 JSON Schema，说明工具名称、作用、需要什么参数、返回什么。
2. 模型决定调用：LLM 看到工具列表，在思考时决定“我现在该调哪个”。
3. 宿主程序执行：框架或你的代码，实际去调工具（调 API、查数据库、跑代码）。
4. 结果写回上下文：把工具返回塞进上下文，模型基于新信息继续推理。
5. 循环往复：直到任务完成。

关键点是：模型其实不直接动手。 它只负责“建议调用”，真正的执行权在开发者手里。

这意味着两件事：

• Agent 的能力边界，取决于你给它的工具。 你给搜索引擎，它就能查；你给 SQL 工具，它就能查库；你给代码执行环境，它就能跑脚本。
• 工具的安全性由你控制。 模型可能想调用“删库”工具，但你的代码可以拒绝。

三、工具有哪些形态

几乎任何能被代码封装的能力，都可以变成工具：

• 查数据库、调 REST API
• 读本地文件、写日志
• 执行 Python/SQL/Shell 脚本
• 发送邮件、消息通知
• 调用搜索引擎、知识库检索
• 操作浏览器、网页自动化

也就是说，Agent 不是被模型限制，而是被你的工具生态限制。 你能封装多少能力，Agent 就能干多少活。

四、设计好工具是门学问

工具不是“有就行”，设计不好，Agent 就调不对。几个原则：

1. 描述写清楚

模型靠工具描述来选。你写“search”就不如“search_recent_news”准确，后者让模型知道这是搜近期新闻。

2. 参数 Schema 要严谨

参数类型、必填项、枚举值都要明确。模型最容易犯的错就是参数格式不对，举几个例子比讲再多都有效。

3. 工具粒度适中

太粗：一个工具干太多事，模型不好控制。太细：一次任务调几十个工具，容易乱。

4. 返回结果要“模型友好”

别返回原始 HTML 或超大 JSON，要做结构化摘要，方便模型理解。

五、给普通人的建议

如果你要做 Agent，别一上来就研究大模型。先问自己：

• 我需要它完成什么真实动作？
• 这些动作能不能用代码封装成工具？
• 工具的输入输出是否清晰、安全？

工具设计清楚了，Agent 才有“手”，如果工具设计的很重，那他的通用性，效率又有影响，这时候就可以考虑使用skills，这些后面再细说。

下篇文章

今天跳过了第三章的知识库和记忆，先讲的工具，就是为了先把LLM+上下文+工具 这个框架先搭起来。接下来继续补充扩展能力，下篇讲：Memory 与 RAG。

---

参考

• 李博杰《深入理解 AI Agent》第 4 章 工具使用

---

本文首发于我的微信公众号「BigDataLab」（每周一个 AI 工具实操 · 大模型 · 大数据）。

后续系列（React 运行范式、上下文工程、工具调用、Memory 与 RAG）会先在公众号更新，感兴趣的同学可以搜索「BigDataLab」关注阅读。

转载请注明出处：作者 Silas ｜ 本文基于 DeepSeek 系列实测（2026-11）。