聊天机器人只能告诉你"怎么订机票"；Agent 能真的去查、去比价。让 Agent 从"说"跨越到"做"的关键技术，叫工具调用。
前面两篇讲了 Agent 的循环和上下文。今天讲循环里最关键的"行动"环节------工具调用（Tool Use / Function Calling）。
它解决的是一个核心问题：大模型只会输出文本，但真实世界靠文本动不了。
要让 Agent 真的干活，必须给它一双手。
一、从"告诉我"到"帮我做"
你问 ChatGPT"今天北京天气怎么样"，它可能会说"我无法获取实时天气数据"。
如果你给 Agent 接上一个天气 API 工具，它就可以：
- 思考：用户问天气 →
- 决定调用天气 API →
- 拿到实时数据 →
- 组织语言回复你。
这个"调用天气 API"的动作，就是工具调用。
工具调用让模型不再只输出文字，而是输出"我要调用某个函数、参数是这些"。 真正执行这个函数的，是外部代码。
二、工具调用的机制
工具调用的流程其实不复杂：
- 开发者定义工具：给一个 JSON Schema，说明工具名称、作用、需要什么参数、返回什么。
- 模型决定调用：LLM 看到工具列表，在思考时决定"我现在该调哪个"。
- 宿主程序执行：框架或你的代码，实际去调工具（调 API、查数据库、跑代码）。
- 结果写回上下文：把工具返回塞进上下文，模型基于新信息继续推理。
- 循环往复：直到任务完成。
关键点是：模型其实不直接动手。 它只负责"建议调用"，真正的执行权在开发者手里。
这意味着两件事：
- 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）。