企业官网建设流程全解析

本文基于 DeepLearning.AI Agentic AI 中文教程 agentic-ai 项目，用新手也能看懂的方式讲透LLM 工具调用的完整原理：从早期靠提示词"文本请求"的手动方案，到原生 Function Calling 标准协议，再到代码执行与 MCP 生态，带你搞懂"模型调用工具"与"模型请求调用工具"的本质区别。

🔧 为什么 LLM 需要工具

大语言模型的核心能力是生成文本，面对实时数据、数据库查询或复杂计算时就会力不从心。**工具调用（Tool Use）**的解法是：给模型一批函数，让它自主判断何时"请求"使用。

以"现在几点？"为例，完整闭环是：

1. 用户提问：用户问 "What time is it?"
2. 模型决策：LLM 意识到自己不知道实时时间，决定请求get_current_time()工具
3. 系统执行：程序运行该函数，返回15:20:45
4. 结果回传：执行结果作为新的上下文写回对话历史
5. 最终回答：模型结合新信息，输出 "It's 3:20pm."

需要理解的三个关键点：

• 工具即函数：工具就是一段普通 Python 代码
• 模型自主决策：模型自己决定调哪个工具、何时调用
• 条件性调用：问"绿茶含多少咖啡因"这种静态知识，模型直接靠内部知识回答，不会调用任何工具

更复杂的请求中，模型还能串联多个工具。例如"帮我找周四日历的空闲时段并和 Alice 预约"：模型先调用check_calendar()查空闲时段，再调用make_appointment()创建预约——这就是多工具协作工作流的基础。

📌 工具调用的本质：是"请求"，不是"执行"

这是整个课程最容易误解的一点：LLM 本身并不会直接执行工具，它只擅长生成文本。真实流程是：

开发者同时扮演"翻译官"和"执行者"，弥合了模型"文本生成"能力与现实世界"函数执行"能力之间的鸿沟。

✍️ 早期方案：用提示词"教"模型

早期 LLM 尚未被直接训练使用工具，开发者必须在系统提示词里写死规则：

You have access to a tool called get_current_time. To use it, return the following exactly: FUNCTION: get_current_time()

约定达成后，模型在需要时间时会输出FUNCTION: get_current_time()这样的文本，开发者程序检测到FUNCTION关键字，就提取函数名并真正调用它。

带参数时，约定只是多了一行。例如问"新西兰现在几点？"，模型输出：

FUNCTION: get_current_time("Pacific/Auckland")

程序解析出函数名与时区参数，执行后返回04:00:00，再回传给模型生成最终回答。

这种方式的缺点：

• 格式约定脆弱，模型多输出一个字符或大小写错了，解析就失败
• 每个工具都要开发者手写解析器并维护提示词
• 模型的"调用"本质是在生成一串看起来像调用的字符串，它并不真正"理解"函数结构

🚀 原生 Function Calling：标准协议时代

如今主流 LLM（OpenAI、Claude、Gemini 等）都已被直接训练了工具调用能力。开发者无需再在提示词里硬编码触发语法，只需告诉模型有哪些工具，模型会自主决定何时调用，并输出结构化请求。

以开源AI Suite库为例，把函数对象传入tools参数即可：

response = client.chat.completions.create( model="openai:gpt-4o", messages=messages, tools=[get_current_time], # 直接传入 Python 函数 max_turns=5 # 限制最大轮次，防止无限循环 )

背后发生了什么？AI Suite 会自动把函数转换成 JSON Schema 再传给模型：name取自函数名，description取自 docstring，parameters根据函数签名解析。

带参数的函数，参数类型与说明也会被纳入 Schema——模型调用get_current_time时就知道需要提供America/New_York这样的时区字符串。

这正是原生 Function Calling 与手动提示法最大的区别："约定"被写进了 API 协议层，模型输出的是结构化数据，SDK 自动完成解析与执行，开发者只写业务逻辑，不再写解析器。

💻 更进一步：代码执行

固定工具集永远有"能力盲区"：假如做了一个计算器，只建了add / subtract / multiply / divide四个工具，用户问"2 的平方根是多少？"就不得不再补新工具。但科学计算器功能按键极多，逐个建工具完全不现实。

更灵活的方案是代码执行（Code Execution）：与其给模型一堆固定按钮，不如给它一把"键盘"——让模型自己编写 Python 代码解决问题，把代码包裹在标签内，提取后放入沙盒执行，再把结果回传给模型生成最终答案。

两个关键注意点：

• 反思 + 外部反馈：代码执行报错时，把错误信息（如SyntaxError）反馈给模型，让它反思修正代码，通过迭代提升正确率
• 安全：模型生成的代码必须在沙盒环境（如 Docker、E2B）中运行，绝不应直接跑在生产系统上——课程中就分享过代码执行器误删项目 Python 文件的真实案例

🌐 面向未来：MCP 协议让工具体系标准化

如果每个应用都各自集成 Slack、Google Drive、GitHub 等工具，m 个应用 × n 个工具的工作量是m × n，大量重复造轮子。**MCP（Model Context Protocol，模型上下文协议）**把它变成客户端-服务器模式：只需开发 n 个 MCP 服务器（每个封装一个工具），再让 m 个应用接入，工作量从m × n降到m + n。

在 MCP 生态中，客户端（Cursor、Claude Desktop、Windsurf 或你自己的应用）发起请求，服务器（Slack、GitHub、PostgreSQL 或自建服务）接收请求、调用原始工具 API 并返回结果。客户端与服务器都已存在大量现成实现，接入即用。

📚 总结

一句话总结：LLM 始终是在"请求"工具调用，真正执行的是你的代码（或 SDK / 沙盒 / MCP 服务器）。理解了这一点，Agentic AI 工作流的种种设计就都水到渠成了。

📖 延伸学习资料

可沿着 agentic-ai 仓库中的原课程笔记继续深入：

• [3.1 什么是工具[What are tools].md](3. 工具使用[Tool Use]/3.1 什么是工具[What are tools].md)：工具执行流程与多工具协作
• [3.2 创建一个工具[Creating a tool].md](3. 工具使用[Tool Use]/3.2 创建一个工具[Creating a tool].md)：手动提示工程方案详解
• [3.3 工具语法[Tool syntax].md](3. 工具使用[Tool Use]/3.3 工具语法[Tool syntax].md)：JSON Schema 自动生成原理
• [3.6 代码执行[Code execution].md](3. 工具使用[Tool Use]/3.6 代码执行[Code execution].md)：沙盒安全与反思机制
• [3.7 MCP[MCP].md](3. 工具使用[Tool Use]/3.7 MCP[MCP].md)：MCP 生态与实际演示