企业官网建设流程全解析

目录

一、核心定义

二、底层核心原理拆解

1. 前置：给模型注入函数元数据（系统提示 + 函数描述 JSON）

2. 阶段 1：推理判断 —— 模型自主决策要不要调用工具

3. 阶段 2：结构化输出 —— 强制生成标准函数调用 JSON

方案 A：Prompt 约束（通用开源方案，如 Llama、Qwen）

方案 B：预训练 + 格式约束（闭源模型：GPT、Claude、文心一言）

4. 阶段 3：本地程序拦截、解析、执行函数（最关键，模型不执行代码）

5. 阶段 4：工具结果回灌上下文，模型生成最终回答

6. 多轮循环调用（复杂场景）

三、两种主流实现架构

1. 云端厂商原生 Function Calling（GPT4、通义千问、文心一言）

2. 开源模型本地实现（Qwen、Llama、GLM）

四、底层技术细节：为什么模型能精准生成参数？

五、完整端到端流程时序图

六、典型应用场景

七、常见误区澄清

一、核心定义

Function Calling（函数调用 / 工具调用）是大语言模型与外部工具打通的能力： LLM 本身只会生成文本，无法联网、查数据库、执行代码、调用接口；通过 Function Calling，模型能识别用户需求 → 生成结构化函数调用参数 → 交给程序执行工具 → 把工具结果丢回模型 → 模型整理自然语言回答。

本质：让大模型具备调用外部能力，弥补纯文本模型无实时数据、无计算、无操作能力的短板。

二、底层核心原理拆解

1. 前置：给模型注入函数元数据（系统提示 + 函数描述 JSON）

调用前，开发者需要把可用工具列表以标准 JSON 格式传给大模型上下文，包含：

• 函数名称name
• 功能描述description（模型靠这段文字理解什么时候该用这个函数）
• 入参定义parameters：参数名、类型、说明、是否必填、枚举值

示例元数据片段：

json

{ "name": "get_weather", "description": "查询指定城市实时天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } }

同时在系统 Prompt 告知模型规则：

你可以调用下面工具，需要查询外部信息时，不要直接回答，输出固定 JSON 格式函数调用，禁止编造数据。

2. 阶段 1：推理判断 —— 模型自主决策要不要调用工具

模型读取用户问题 + 函数列表，做逻辑判断：

1. 问题仅靠自身知识库能回答 → 直接输出自然语言，不走函数调用；
2. 问题需要实时 / 外部数据（天气、日期、数据库、计算器、联网搜索）→ 进入函数生成逻辑。

关键点：判断逻辑完全由 LLM 自身推理完成，不需要额外分类模型。

3. 阶段 2：结构化输出 —— 强制生成标准函数调用 JSON

普通对话模型输出自由文本，Function Calling 通过两种方案约束输出结构化参数：

方案 A：Prompt 约束（通用开源方案，如 Llama、Qwen）

依靠强指令引导模型只输出指定 JSON，靠提示词规范格式，有概率输出错乱文本，需要做格式校验重试。

方案 B：预训练 + 格式约束（闭源模型：GPT、Claude、文心一言）

厂商在微调阶段专门学习工具调用 JSON 格式；同时底层加格式校验层，推理时限制 token 输出空间，只能生成合法 JSON，大幅减少格式错误。

模型输出的标准调用报文示例：

json

{ "name": "get_weather", "arguments": {"city": "深圳"} }

4. 阶段 3：本地程序拦截、解析、执行函数（最关键，模型不执行代码）

大模型只会生成调用指令，不会真正执行工具，完整流程必须依赖上层业务程序：

1. 业务代码接收模型返回内容，正则 / JSON 解析识别出函数调用；
2. 校验函数名、参数合法性；
3. 分发到对应本地函数 / HTTP 接口 / 数据库 / 搜索工具执行；
4. 获取工具返回结果（天气数据、计算结果、网页内容）。

举个链路： 用户问「深圳今天多少度」 模型输出{"name":"get_weather","city":"深圳"}业务代码调用天气 API → 返回{"temp":32,"weather":"晴"}

5. 阶段 4：工具结果回灌上下文，模型生成最终回答

把原始用户问题 + 刚刚的函数调用记录 + 工具返回数据拼接成完整上下文，再次丢给大模型二次推理； 此时模型拥有真实外部数据，不再需要调用工具，直接整理成通顺自然语言回复用户。

上下文示例结构：

1. 用户：深圳今天多少度
2. 模型输出工具调用：调用 get_weather (深圳)
3. 工具返回：温度 32 度，晴天
4. 传入全部历史，模型生成回答：深圳今日晴天，气温 32 摄氏度

6. 多轮循环调用（复杂场景）

如果一次工具调用拿不到完整信息，模型会连续多次调用函数： 例：「对比深圳和北京今日气温，计算温差」

1. 调用 get_weather (深圳)
2. 调用 get_weather (北京)
3. 调用 calc (a=32,b=28)
4. 汇总数据回答温差 4 度

三、两种主流实现架构

1. 云端厂商原生 Function Calling（GPT4、通义千问、文心一言）

厂商底层内置工具调用微调 + 格式强制解码器，开箱即用，API 专门区分message.role="tool_call"、message.role="tool"标准消息结构，无需自己强约束 Prompt，稳定性高。

2. 开源模型本地实现（Qwen、Llama、GLM）

无原生支持，纯 Prompt 工程实现：

1. 系统 Prompt 写明所有函数定义 + 输出格式；
2. 推理后代码捕获输出，捕获 JSON 失败则重试对话；
3. 手动封装工具执行逻辑，回传结果二次生成。

四、底层技术细节：为什么模型能精准生成参数？

1. 上下文学习 ICL：函数描述、参数说明作为上下文示例，模型通过类比理解入参对应关系；
2. 微调优化（闭源标配）：厂商用百万级「用户问题 - 函数调用」样本微调，学习映射关系；
3. 输出约束（Constrained Decoding）：推理阶段限制可生成 token 集合，只能输出 JSON 合法字符，杜绝乱码、自由文本。

五、完整端到端流程时序图

1. 用户提问
2. 业务层组装：系统提示词 + 函数定义列表 + 用户问题 → 请求 LLM
3. LLM 推理，输出工具调用 JSON
4. 业务代码解析 JSON，执行对应外部工具
5. 拿到工具返回数据，构造 tool 消息存入对话历史
6. 再次请求 LLM（带上全部对话 + 工具结果）
7. LLM 基于真实数据输出自然语言答案，返回给用户

六、典型应用场景

1. 联网搜索：调用搜索引擎获取实时新闻、资料
2. 代码 / 计算器：数学运算、数据统计
3. 数据库查询：SQL 生成并查询业务库
4. 第三方接口：天气、快递、股票、地图
5. 智能 Agent：自动多工具循环完成复杂任务

七、常见误区澄清

1. ❌ 大模型会执行函数 ✅ 模型只生成调用文本，执行永远是本地业务代码；
2. ❌ Function Calling 就是简单字符串匹配 ✅ 是模型语义推理，能自动抽取问题隐含参数；
3. ❌ 所有大模型原生支持 ✅ 开源基础模型无原生能力，需要 Prompt / 微调改造。