以小龙虾为例，了解AI 产品调用的完整链路是什么样的

小小程序猿~~~

928人浏览 · 2026-03-23 11:07:13

小小程序猿~~~ · 2026-03-23 11:07:13 发布

大家好，我是链上杯子（CSDN：链上杯子）。

失业一年了，天天想着怎么翻身。
最近我花了很多时间把 Grok、ChatGPT、Claude 等主流 AI 产品的底层调用链彻底拆了一遍，终于搞清楚了“用户输入一句话后，背后到底执行了些什么”。
今天这篇文章，我把最核心的调用流程完整呈现给你，并用小龙虾浏览网页的真实例子进行详细拆解（包括每次调用模型的次数和作用）。看完后，你会对现在的 AI 产品有一个系统且清晰的认知。

一、AI 产品的一次完整调用链（2026 年主流架构）

下面是目前最典型的 AI 聊天产品（Grok、ChatGPT、Claude 等）的完整调用流程：

用户输入一句话
↓
[前端界面]  ← React / Next.js / Flutter / 微信小程序 等
↓ (HTTP / WebSocket)
[网关 / 负载均衡]  ← Nginx / Cloudflare / API Gateway
↓
[后端服务层]  ← FastAPI / Node.js / Go / Java Spring 等
│
├─ 鉴权 & 限流 & 计费（token 消耗统计）
│
├─ Prompt 工程层（非常关键！）
│   ↓
│   系统 Prompt（角色设定、语气、规则） + 用户输入 + 历史对话 + 工具描述 + RAG 检索结果
│
├─ RAG / 知识库检索（可选，但现在几乎必备）
│   ↓
│   向量数据库（Pinecone / Weaviate / Milvus / Chroma / FAISS） → 语义检索 → top-k 相关 chunk
│
├─ 工具 / Function Calling（如果需要外部能力）
│   ↓
│   模型判断是否需要调用工具 → 输出 function_call JSON → 执行工具（搜索、计算、读文件、调用 API 等） → 把结果塞回 Prompt
│   可能循环多次（ReAct / Toolformer 风格）
│
└─ 大模型推理（核心）
↓
LLM 服务（推理引擎）
│
├─ 本地部署：vLLM / Ollama / llama.cpp / TGI
├─ 云端 API：OpenAI / Anthropic / Grok / DeepSeek / Moonshot / 通义 / 智谱 / MiniMax
└─ 模型本身：Llama-3.1 / Qwen2.5 / Grok-2 / Claude-3.5 / GPT-4o / DeepSeek-V3 / GLM-4 等
↓
输出 token 流式返回（streaming）或一次性返回
↓
[后端] 格式化输出 + 记录日志 + 更新 token 消耗
↓
[前端] 实时显示（流式打字效果） + 展示来源引用 / 工具调用过程（如果有）

一句话总结：
用户输入 → 后端构建完整 Prompt → 第一次调用模型（判断意图）→ 如果需要工具就执行 → 把结果塞回 → 再次调用模型 → 直到输出最终答案。

二、关键步骤拆解（每一层到底在干什么）

1. 前端界面 + 网关
用户在网页/App 上输入内容，通过 HTTP 或 WebSocket 发送到后端。网关负责鉴权、限流、防攻击。

2. Prompt 工程层（最花心思的一层）
后端会把以下内容拼成一个超级长的 Prompt：

系统角色设定
历史对话记录
RAG 检索到的知识
可用工具列表
当前用户问题

这一步决定了模型的“思考起点”。

3. RAG / 知识库检索
如果问题需要私有知识或最新信息，后端先去向量数据库检索最相关的文档片段（top-k），然后塞进 Prompt。

4. 工具 / Function Calling
模型判断是否需要外部能力：

不需要 → 直接输出答案
需要 → 输出结构化工具调用指令

后端解析指令 → 执行对应工具 → 把结果作为 Observation 塞回 Prompt → 再次调用模型（可能循环多次）。

5. 大模型推理
真正调用 Grok / GPT / Claude 等大模型，生成回复。可能多次循环。

6. 后端格式化 + 前端展示
后端整理答案，前端做流式打字效果，并可能展示工具调用过程或引用来源。

三、以小龙虾为例：它是如何操控浏览器的？（含多次 API 调用拆解）

我们用一个具体例子完整走一遍流程，标注第几次调用模型：

用户输入：
“帮我看一下 B 站最新一期****的视频简介写了什么？”

背后真实执行过程（Grok 为例）：

前端发送请求 → 后端收到。

第1次调用 Grok 模型
模型收到完整 Prompt（系统角色 + 历史 + 当前问题 + 工具列表）。
模型判断：“我没有实时视频数据，需要调用 browse_page 工具。”
输出工具调用指令：

{
  "tool": "browse_page",
  "arguments": {
    "url": "https://www.bilibili.com/video/BVxxxxxxxx",
    "instructions": "提取视频标题、UP主、简介全文、播放量、弹幕数、发布时间。"
  }
}

后端执行浏览器工具（真正干活的是服务器）
- 启动 Playwright（服务器上的浏览器）
- 打开指定的 Bilibili 视频页面
- 等待加载完成
- 执行 JS 提取标题、简介、数据
- 生成截图（用于过程展示）
- 把提取到的干净文本作为 Observation 返回
第2次调用 Grok 模型
把 Observation 塞回 Prompt，再次调用模型。
模型看到结果后，直接输出自然语言回答：
“***最新一期视频标题是《xxx》，简介主要讲了……”
前端展示
用户看到最终答案 + 可能附带几张过程截图（“正在打开页面”“正在提取内容”）。

多次调用模型的详细流程图（小龙虾浏览网页示例）：

用户输入：看 B 站某某某最新视频简介

↓

第1次调用 Grok API
  ↓
模型输出工具调用指令：
  Action: browse_page
  Action Input: url = https://..., instructions = 提取简介...

↓

后端执行 Playwright：
  - 打开页面
  - 等待加载
  - 提取标题、简介、数据
  - 返回 Observation：视频标题《xxx》，简介是......

↓

第2次调用 Grok API（带 Observation）
  ↓
模型看到结果后：
  Thought: 已经拿到信息，可以直接回答
  Final Answer: 某某某最新视频标题是《xxx》，简介主要讲了……

↓

最终回复给用户

关键结论：
小龙虾“操控浏览器”的本质是：模型只负责两次决策（第1次判断要调用工具，第2次基于结果给出答案），真正打开浏览器、加载页面、提取内容的，是后端服务器上的 Playwright 等工具。
模型本身不会操作浏览器，它只下指令，后端才是“手”。