DoneHub

System Prompt 工程：动态组装与缓存优化

发表于 2026-04-06 分类于 Claude Code Valine：

Claude Code 的系统提示词不是一个静态字符串，而是一个动态组装的管道。通过分层构建、缓存边界、Section 类型等设计，实现了跨会话的缓存复用，大幅降低了延迟和成本。这是 Prompt 工程的教科书级案例。

阅读全文 »

Claude Code 为什么更强：超越 Prompt 的 Agent 运行时

发表于 2026-04-06 分类于 Claude Code Valine：

导读：同样的模型，不同的体验

主流 Code Agent 竞品一览

当前市面上主流的 AI Code Agent 产品可分为三类：

产品	公司	形态	特点
Claude Code	Anthropic	CLI	Agent 运行时框架，MCP 扩展
Codex CLI	OpenAI	CLI	同类型竞品，GPT 模型驱动
Cursor	Anysphere	AI 原生 IDE	VS Code fork，深度上下文感知
Trae	字节跳动	AI 原生 IDE	国内版”扣子”，自适应学习
GitHub Copilot	Microsoft	IDE 扩展	行业先驱，生态成熟
Qoder	阿里云	IDE 扩展	通义灵码，阿里云生态集成

Claude Code 与 Codex CLI 是同类型产品——都是终端型 CLI 工具，直接操作文件系统。其他产品则是 IDE 形态，交互方式不同。

核心体验差异

用 GPT-4 模型 + OpenAI 自家的 Codex CLI，效果还行；
用 GPT-4 模型 + Anthropic 的 Claude Code，效果竟然更好。

这颠覆了常识——为什么自家模型搭配自家 Agent，效果反而不如搭配竞争对手的 Agent？

答案在于：Claude Code 不是”Claude 模型的专属工具”，而是一个通用的 Agent 运行时框架。它的架构设计让任何模型都能发挥更大潜力。

很多人猜测是”Prompt 更好”，但这只是表象。Claude Code 源码泄露后，真相浮出水面——它不是一个 Prompt 工具，而是一个完整的 Agent 运行时框架。

这个框架做了什么？它”懂”模型的能力边界，”懂”工具的执行风险，”懂”上下文的压缩策略，”懂”用户的意图流转。模型只是大脑，Claude Code 是躯体。

一、架构对比：状态机 vs ReAct

1.1 市面主流 Code Agent 架构

大多数 Code Agent 采用 ReAct（Reasoning + Acting） 模式：

┌─────────────────────────────────────────────────────────────┐
│                    ReAct 循环                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Thought → Action → Observation → Thought → Action → ...   │
│                                                             │
│  问题：容易陷入死循环                                        │
│  ├─ 模型反复"思考"但无法推进                                 │
│  ├─ 工具失败后没有恢复机制                                   │
│  └─ 上下文无限膨胀直到截断                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

1.2 Claude Code 的状态机架构

Claude Code 选择了一条不同的路——Async Generator 状态机：

// 核心循环不是 Thought→Action→Observation
// 而是 state = next 的状态推进

while (true) {
  const next = await step(queryContext)
  state = next  // 状态推进，不是循环
  
  if (state.type === 'end') break
  if (state.type === 'error') {
    state = recover(state)  // 有恢复机制！
  }
}

优势对比：

特性	ReAct	Claude Code 状态机
死循环风险	高	低（状态推进有边界）
错误恢复	无	有（6 种恢复策略）
流式交互	困难	原生支持（Generator）
上下文管理	简单截断	四级压缩
模型控制	被动	主动（state 驱动）

二、工具生态对比

2.1 工具数量对比

Code Agent	内置工具	扩展机制
Claude Code	48+	MCP 协议（无限扩展）
Codex CLI	~20	有限扩展
Cursor	~15	IDE 内嵌，无扩展
Trae	~15	IDE 内嵌，无扩展
GitHub Copilot	~10	IDE 生态，有限
Qoder	~10	阿里云生态，有限

MCP 协议是 Claude Code 的杀手级特性——任何开发者都可以用任何语言编写 MCP Server，扩展 Claude Code 的能力。相比之下，其他产品的扩展性都受限。

大多数 Code Agent 的工具执行是”裸奔”的：

1	调用工具 → 执行 → 返回结果

Claude Code 的工具执行有 七步管道：

1	查找 → 解析 → 验证 → 钩子 → 权限 → 执行 → 后处理

关键差异：

管道步骤	Claude Code	其他 Agent
验证	Schema 校验 + 业务规则	通常无
钩子	PreToolUse/PostToolUse 可拦截	无
权限	五层决策链	简单开关
后处理	结果渲染 + 错误恢复	直接输出

三、上下文管理对比

3.1 市面常见做法

大多数 Code Agent 的上下文管理是暴力截断：

1
2
3

if (tokens > limit) {
  截断最早的消息
}

问题：

重要信息可能丢失
模型”忘记”之前的上下文
长任务无法完成

3.2 Claude Code 的四级压缩

┌─────────────────────────────────────────────────────────────┐
│                   四级上下文压缩                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Level 1: Snip                                              │
│    └─ 快速裁剪：删除空白、重复内容                           │
│                                                             │
│  Level 2: Micro                                             │
│    └─ 微压缩：保留 tool_use ID，删除详细参数                 │
│                                                             │
│  Level 3: Collapse                                          │
│    └─ 块压缩：合并相邻消息，生成摘要                         │
│                                                             │
│  Level 4: AutoCompact                                       │
│    └─ 深度压缩：调用子代理生成完整摘要                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

效果对比：

场景	暴力截断	四级压缩
长对话	信息丢失	关键信息保留
复杂任务	无法完成	可以完成
模型理解	“忘记”之前	“记住”要点
Token 消耗	高	低（智能压缩）

四、多代理协作对比

4.1 单 Agent 的局限

大多数 Code Agent 是单 Agent 设计：

1	一个模型 + 一套工具 = 完成所有任务

问题：

复杂任务难以分解
单一模型容易”思维固化”
无法并行处理

4.2 Claude Code 的多代理架构

Claude Code 有 四种 Agent 类型：

┌─────────────────────────────────────────────────────────────┐
│                    四种 Agent 类型                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Subagent（子代理）                                          │
│    └─ 短生命周期，完成子任务后汇报                           │
│                                                             │
│  Fork（分叉代理）                                            │
│    └─ 独立上下文，不污染主对话                               │
│                                                             │
│  Teams（团队代理）                                           │
│    └─ 邮箱通信，任务分发，并行执行                           │
│                                                             │
│  Remote（远程代理）                                          │
│    └─ MCP 协议，扩展到外部服务                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

协作场景示例：

任务	单 Agent	Claude Code 多代理
重构大型模块	容易迷失	Fork + Subagent 分解
并行调研	无法并行	Teams 并行执行
跨项目操作	困难	Remote MCP 扩展
长时间任务	上下文爆炸	Teams 邮箱通信

五、安全机制对比

5.1 市面常见做法

大多数 Code Agent 的安全机制是简单开关：

1	allowDangerousCommands: true/false

问题：

无法精细控制
一旦开启，所有危险操作都允许
用户无法审批具体操作

5.2 Claude Code 的分层权限模型

Claude Code 有 五层决策链：

1	规则检查 → 模式检查 → 钩子检查 → 分类器检查 → 用户确认

精细控制示例：

操作	其他 Agent	Claude Code
`git status`	允许/拒绝	允许（Git 白名单）
`rm -rf node_modules`	允许/拒绝	确认（危险命令）
`rm -rf /`	允许/拒绝	拒绝（永远禁止）
写入 `.git/config`	允许/拒绝	拒绝（敏感路径）
运行测试	允许/拒绝	允许（安全操作）

六、Memory 系统：其他 Agent 没有

6.1 跨会话记忆

大多数 Code Agent 每次对话从零开始：

1	新对话 → 模型不知道你是谁 → 重新解释需求

Claude Code 的 Memory 系统：

┌─────────────────────────────────────────────────────────────┐
│                    Memory 系统                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  User Memory（用户画像）                                     │
│    └─ 记住你的角色、技能水平、偏好                           │
│                                                             │
│  Feedback Memory（行为反馈）                                 │
│    └─ 记住你对 Claude 工作方式的纠正                         │
│                                                             │
│  Project Memory（项目动态）                                  │
│    └─ 记住项目的决策、截止日期、正在进行的工作               │
│                                                             │
│  Reference Memory（外部引用）                                │
│    └─ 记住外部系统指针：仪表板、工单系统                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

效果：

场景	无 Memory	有 Memory
新对话	重新解释	Claude 知道你是谁
编码风格	每次指定	Claude 记住偏好
项目决策	重复解释	Claude 记住背景
团队协作	不知道队友	Claude 知道分工

七、远程控制：Channel 系统

7.1 其他 Agent 的局限

大多数 Code Agent 只能在本地终端交互：

1	你必须坐在电脑前 → 才能让 Agent 工作

7.2 Claude Code 的 Channel 系统

┌─────────────────────────────────────────────────────────────┐
│                    Channel 系统                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  手机 Telegram → 发消息给 Claude Code                        │
│      ↓                                                      │
│  Claude Code 在你的电脑上工作                                │
│      ↓                                                      │
│  结果回复到你的 Telegram                                     │
│                                                             │
│  六层访问控制确保安全：                                       │
│  ├─ 能力声明                                                 │
│  ├─ 运行时开关                                               │
│  ├─ OAuth 认证                                               │
│  ├─ 组织策略                                                 │
│  ├─ 会话白名单                                               │
│  └─ Marketplace 验证                                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

体验差异：

场景	其他 Agent	Claude Code
外出时	无法使用	Telegram 远程控制
紧急修复	必须回电脑	手机审批操作
监控进度	无法监控	IM 实时反馈

八、Terminal UI：React + Ink

8.1 其他 Agent 的界面

大多数 Code Agent 的界面是简单输出：

1 2	stdout.print("模型回复") stdout.print("工具结果")

问题：

信息密集时难以阅读
无法交互式选择
无法可视化复杂内容

8.2 Claude Code 的 Terminal UI

Claude Code 用 React + Ink 构建 Terminal UI：

┌─────────────────────────────────────────────────────────────┐
│                    React + Ink TUI                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  组件化 UI                                                   │
│    ├─ Header（标题栏）                                       │
│    ├─ MessageList（消息列表）                                │
│    ├─ ToolBar（工具栏）                                      │
│    ├─ ContextPanel（上下文面板）                             │
│    ├─ InputBox（输入框）                                     │
│    └─ PermissionDialog（权限对话框）                         │
│                                                             │
│  Flexbox 布局（Yoga 引擎）                                   │
│  双缓冲渲染（避免闪烁）                                       │
│  交互式组件（键盘导航）                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

体验对比：

特性	简单输出	React + Ink
信息密度	低	高（布局优化）
可读性	一般	好（结构化展示）
交互性	无	有（键盘导航）
权限审批	全部允许/拒绝	可选择 Allow/Deny

九、System Prompt 工程

9.1 其他 Agent 的做法

大多数 Code Agent 的 System Prompt 是静态字符串：

1	SYSTEM_PROMPT = "你是一个 AI 编程助手..."

问题：

无法动态适应环境
无法缓存，每次都发送
无法合并多来源指令

9.2 Claude Code 的分层 System Prompt

┌─────────────────────────────────────────────────────────────┐
│                 分层 System Prompt                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  静态可缓存区域                                              │
│    ├─ 角色定义                                               │
│    ├─ 系统规则                                               │
│    ├─ 工具说明                                               │
│    └─ 任务指导                                               │
│                                                             │
│  ─────────── 缓存边界 ───────────                            │
│                                                             │
│  动态可变区域                                                │
│    ├─ 当前日期                                               │
│    ├─ 项目结构                                               │
│    ├─ Git 状态                                               │
│    ├─ MCP 指令                                               │
│    └─ CLAUDE.md（用户指令）                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

效果：

特性	静态 Prompt	分层 Prompt
Token 消耗	高（每次全量）	低（缓存复用）
响应延迟	高	低（缓存命中）
指令优先级	单一	多级合并
用户定制	困难	CLAUDE.md 支持

十、总结：Claude Code 的核心竞争力

Claude Code 比其他 Code Agent 更强，不是因为”Prompt 更好”，而是因为它是一个完整的 Agent 运行时框架：

10.1 七大核心优势

┌─────────────────────────────────────────────────────────────┐
│                Claude Code 七大核心优势                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. 状态机架构                                               │
│    └─ 替代 ReAct，避免死循环，支持流式交互                   │
│                                                             │
│  2. 工具生命周期                                             │
│    └─ 七步管道：验证、钩子、权限、后处理                     │
│                                                             │
│  3. 四级上下文压缩                                           │
│    └─ 智能压缩，保留关键信息，实现"伪无限对话"               │
│                                                             │
│  4. 多代理协作                                               │
│    └─ 四种 Agent 类型，Teams 邮箱通信，并行执行              │
│                                                             │
│  5. 分层权限控制                                             │
│    └─ 五层决策链，精细控制每个操作                           │
│                                                             │
│  6. Memory 系统                                              │
│    └─ 跨会话记忆，Claude"记住"你是谁                         │
│                                                             │
│  7. 分层 System Prompt                                       │
│    └─ 缓存优化，降低 Token 消耗和延迟                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

10.2 一句话总结

Claude Code 是一个”懂”模型的 Agent 平台：

懂模型的能力边界 → 状态机架构
懂工具的执行风险 → 七步管道 + 权限控制
懂上下文的压缩策略 → 四级压缩
懂任务的分解协作 → 多代理架构
懂用户的长期意图 → Memory 系统

其他 Code Agent 只是模型的”简单包装”，Claude Code 是模型的”完整躯体”。这就是为什么同样的 Claude 模型，配合 Claude Code 使用效果更好的根本原因。

系列文章导航：

系列起点：Claude Code 源码揭秘：整体架构概览

工具系统设计：从定义到执行的七步管道

发表于 2026-04-06 分类于 Claude Code Valine：

Claude Code 有 48+ 个内置工具，每个工具都是一个完整的生命周期管理单元。从定义到执行，工具要经过七步管道：查找、解析、验证、钩子、权限、执行、后处理。这个设计使得每个工具都是自描述、自验证、自渲染的——框架不需要了解工具的内部逻辑，只需调用标准接口。

阅读全文 »

MCP 要死了吗

发表于 2026-04-03 更新于 2026-04-28 分类于 MCP Valine：

背景

最近，关于 AI Agent 如何与外部系统交互的讨论非常热烈，尤其是围绕 MCP 和 CLI 的争论。很多人认为 MCP 因为成本高、效率低而即将被淘汰。但就在四月二十二日，MCP 的”亲爹”Anthropic 发布了一篇重磅博客，为我们揭示了一个全新的视角。本文将深入解读这篇文章，探讨 MCP 的现状挑战以及它真正的未来。

一、社区对 MCP 的三大”罪状”

1.1 成本太高

根据 ScaleKit 的严格测试，在相同操作下：

方案	成本对比
CLI	基准成本
MCP	17倍于 CLI

这意味着使用 MCP 的成本是 CLI 的 17 倍，这是一个巨大的差距。

1.2 上下文占用严重

Perplexity 的 CTO 直言他们内部正在远离 MCP，原因惊人：

1	MCP 占用了高达 72% 的宝贵上下文窗口

对于需要长上下文的复杂任务，这几乎是不可接受的。

1.3 Schema 过于臃肿

以 GitHub 的 MCP 为例：

数据项	数值
工具数量	43 个
单工具描述 Token	4026 Token
每次交互	全部 43 个工具定义都要发给模型

每次交互都要把 43 个工具的”说明书”全部发给模型，光工具定义就占用了大量 Token，这无疑是巨大的浪费。

二、官方回应：三种连接方式，各有其场

面对这些批评，Anthropic 并没有直接反驳，而是给出了一个更宏观的框架。

2.1 Agent 连接外部系统的三种方式

方式	适用场景	优势	劣势
直连 API	简单场景	直接、快速	扩展性差，陷入 M×N 集成噩梦
CLI	本地环境	高效、灵活	无法在云端运行
MCP	云端环境	标准化、跨平台	成本较高

2.2 Anthropic 承认 CLI 的优势

Anthropic 大方承认：CLI 在本地环境确实高效。但他们强调了一个关键趋势：

1	越来越多的生产级 Agent 正在云上运行

在云端环境中：

没有本地文件系统
无法执行 CLI 命令
如 Claude 网页版、移动端 App

MCP 的价值就体现出来了：它提供了一个标准化的远程连接层，能统一服务于各种客户端。

2.3 MCP 的全新定位

Anthropic 为 MCP 找到了一个全新的、也是它最该待的地方：

1	云端 Agent 的标准化接入层

无论是网页版的 Claude，还是集成在 VS Code 里的 Cursor，都可以通过一个统一的 MCP 服务器来访问后端服务。这个定位非常清晰。

2.4 市场数据印证

时间节点	MCP SDK 月下载量
早期	1 亿
当前	3 亿

短短几个月内下载量翻了 3 倍，这说明开发者们正在积极拥抱这个标准。

三、核心解法一：Tool Search（工具搜索）

Anthropic 提出了两个核心技术解法来解决 Token 消耗问题。

3.1 传统方式的痛点

1
2
3

传统方式：
每次交互 → 把一整本厚厚的说明书（全部工具定义）塞给模型
         → 巨大的 Token 消耗

3.2 Tool Search 的思路

1
2
3

Tool Search 方式：
模型先告诉系统它想做什么 → 系统去"书架"上找到对应的那几页说明书
                         → 只把相关工具定义发给模型

核心理念：工具应该围绕用户意图来组织，而不是简单地按 API 来划分。

3.3 效果数据

指标	效果
工具定义 Token 减少	超过 85%
工具选择准确率	保持不变

这种”按需加载”的方式能直接砍掉超过 85% 的工具定义 Token，而且工具选择的准确率并没有降低。

四、核心解法二：程序化工具调用

第二个解法思路非常巧妙，它改变了工具返回结果的处理方式。

4.1 传统方式的问题

1 2	传统方式：工具返回大量原始数据 → 直接涌入模型的上下文 → 上下文爆炸

4.2 程化调用的思路

1
2
3

程序化调用方式：
模型在安全的代码沙箱里写一小段代码 → 处理数据（过滤、计算、整合）
                                    → 只把精炼后的结果返回给模型

核心理念：别让模型当搬运工，让它写代码。

4.3 效果数据

任务类型	Token 减少幅度
复杂任务	约 37%

根据官方数据，这个方法在处理复杂任务时能额外减少约 37% 的 Token 消耗。

五、两个解法的综合效果

拿之前 ScaleKit 的测试数据来算一笔账：

5.1 原始差距

1 2	原始情况下： MCP Token 消耗 = CLI 的 32 倍

这是一个巨大的鸿沟。

5.2 应用解法后

方案	Token 消耗估算
原始 MCP	约 32000 Token
Tool Search 后	约 10000 Token
CLI	约 1000 Token

差距从 32 倍缩小到约 7 倍。

5.3 成本合理性分析

虽然 MCP 还是比较 CLI 更贵，但这个差距已经不再是不可逾越的了。在云端环境下，MCP 带来的：

标准化
安全性
跨平台能力

其价值完全可以覆盖这部分成本差异。

六、实战案例：Cloudflare 的聪明做法

理论说再多不如看一个实际案例。Cloudflare 是 MCP 的深度用户。

6.1 他们面临的挑战

1	需要通过 MCP 开放约 2500 个 API 端点

如果按传统方式，这简直是一场灾难。

6.2 聪明的解决方案

Cloudflare 的做法非常聪明：

设计	说明
对外暴露工具数	只有 2 个
工具名称	`search` + `execute`

6.3 工作流程

1
2
3

Agent 工作流程：
1. 用 search 找到需要的 API
2. 通过 execute 在服务端执行操作（像写脚本一样）

6.4 效果

指标	数值
工具定义 Token	约 1000 Token

这个案例完美诠释了 Anthropic 的理念：MCP 服务器应该像 CLI 一样设计，让 Agent 通过代码来编排和控制。

七、MCP 与 Skills 的生态融合

除了解决技术问题，Anthropic 还在推动生态的融合。

7.1 MCP 与 Skills 的关系

角色	职责	类比
MCP	连接各种服务，提供”能力”	工具箱
Skills	告诉 Agent 如何使用能力完成任务	操作手册

7.2 Claude 数据插件案例

Claude 的数据插件是一个典型例子：

组成	数量
Skills	10 个
MCP 服务器	8 个

用户可以轻松地分析来自不同数据库的数据。

7.3 第三方服务商跟进

像 Canva、Notion 这些第三方服务商也开始效仿：

1	发布 MCP 服务器 + 配套 Skills

这标志着一个更加成熟和协同的 Agent 生态正在形成。

八、总结：未来的分工格局

Anthropic 的这篇博客，并非对社区批评的简单反驳，而是一次深刻的自我进化和战略澄清。

8.1 针对三大痛点的解决方案

痛点	解决方案
成本太高	Tool Search（减少 85% 工具定义 Token）
上下文占用	程序化调用（减少 37% 结果 Token）
Schema 臃肿	代码编排模式（Cloudflare 案例）

同时，Anthropic 也大方承认了 CLI + Skills 模式的价值，并将 Skills 正式纳入了官方最佳实践。

8.2 MCP 的主战场

1	云端和跨平台环境 → MCP 是目前唯一合理的标准化解决方案

8.3 未来的分工格局

环境	最佳实践
云端生产环境（面向用户的 SaaS）	MCP + Skills
开发者本地环境	CLI + Skills
简单任务	直连 API

不存在一个万能的解决方案，Agent 时代的连接层正在走向多元化和专业化。

附录：关键数据汇总

数据项	来源	数值
MCP vs CLI 成本差距	ScaleKit 测试	17 倍
MCP 上下文占用	Perplexity CTO	72%
GitHub MCP 工具数	官方 Schema	43 个
Tool Search Token 减少	Anthropic	85%+
程序化调用 Token 减少	Anthropic	37%
MCP SDK 月下载量	npm 数据	3 亿
Cloudflare 工具定义 Token	实战案例	1000

结论

MCP 并没有死，它只是找到了属于自己的战场。Agent 时代的连接层正在走向多元化和专业化。作为技术从业者，我们需要理解不同工具的适用场景，并根据自己的业务需求做出最合适的技术选型。

参考资源：

Chrome DevTools MCP 入门实战：让 AI 助手操控浏览器

发表于 2026-04-01 更新于 2026-04-03 分类于 AI Valine：

一、前言：为什么需要这个工具？

你有没有遇到过这样的场景：

想让 AI 帮你调试网页，但它只能”纸上谈兵”，给建议却不能动手
需要自动化测试网页功能，写脚本太麻烦
想分析网页性能瓶颈，但看不懂 DevTools 里的各种指标
希望让 AI 帮你截取网页截图、提取页面内容

Chrome DevTools MCP 就是解决这些问题的神器。它让 AI 助手（如 Claude Code、Cursor、Copilot）能够直接操控浏览器，像一个真正的开发者一样干活。

二、核心概念：MCP 是什么？

2.1 MCP 协议简介

MCP（Model Context Protocol） 是 Anthropic 在 2024 年底提出的一个开放协议。简单理解，它是 AI 助手与外部工具之间的”通用插座”。

打个比方：

没有 MCP 时，AI 像是”被困在盒子里的聪明人”——只能聊天，不能动手
-有了 MCP，AI 像是”长了手脚的助手”——能连接数据库、操控浏览器、读写文件

2.2 MCP 的架构

┌─────────────┐     MCP 协议     ┌─────────────────┐
│   AI 助手   │◄──────────────►│   MCP Server    │
│ (Claude等)  │                 │ (工具提供者)     │
└─────────────┘                 └─────────────────┘
                                       │
                                       ▼
                              ┌─────────────────┐
                              │   外部资源       │
                              │ (浏览器/数据库等)│
                              └─────────────────┘

MCP Server 是关键组件，它：

暴露工具（Tools）给 AI 调用
提供资源（Resources）供 AI 读取
发送提示（Prompts）引导 AI 使用

2.3 Chrome DevTools MCP 的定位

chrome-devtools-mcp 是官方提供的 MCP 服务器，它把 Chrome 浏览器的 DevTools 能力 暴露给 AI 助手。

这意味着 AI 可以：

打开网页、点击按钮、填写表单
查看控制台日志、网络请求
截图、分析性能
提取 DOM 元素、调试 JavaScript

三、核心功能一览

3.1 主要能力分类

类别	功能	典型用途
浏览器控制	打开页面、导航、刷新、关闭	自动化浏览
页面交互	点击、输入文本、滚动、等待	自动化测试
调试分析	控制台日志、网络请求、错误追踪	问题排查
性能分析	录制性能追踪、分析加载时间	性能优化
视觉捕获	截图、获取元素坐标	文档记录
DOM 操作	获取元素、查询选择器	内容提取

3.2 Slim 模式 vs 完整模式

Chrome DevTools MCP 提供两种运行模式：

模式	工具数量	适用场景	启动参数
Slim 模式	约 10 个	基础浏览任务	`--slim --headless`
完整模式	约 30+ 个	调试、性能分析	默认

新手建议先用完整模式，熟悉后再根据需求切换。

四、安装配置：Claude Code 实战

4.1 环境要求

在开始之前，请确保你有：

要求	版本	检查方法
Node.js	v20.19+	`node -v`
npm	最新版	`npm -v`
Chrome	最新稳定版	浏览器设置查看
Claude Code	最新版	`claude --version`

4.2 方法一：CLI 快速安装（推荐）

打开终端，执行一行命令：

1	claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

这会自动添加到你的用户级配置中。

4.3 方法二：手动配置

如果你想手动配置，找到 Claude Code 的配置文件：

Windows:

1	C:\Users\<你的用户名>\.claude\settings.json

Mac/Linux:

1	~/.claude/settings.json

在 mcpServers 部分添加：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

4.4 配置参数详解

你可以通过参数定制行为：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--headless",           // 无头模式（不显示浏览器窗口）
        "--slim",               // 精简模式（减少工具数量）
        "--no-performance-crux" // 禁用 CrUX 数据收集
      ]
    }
  }
}

常用参数说明：

参数	作用	建议场景
`--headless`	无界面运行	CI/CD、自动化脚本
`--slim`	只加载基础工具	简单浏览任务
`--no-usage-statistics`	禁用使用统计	隐私敏感场景
`--browser-url=...`	连接已有浏览器	调试特定实例

4.5 验证安装

重启 Claude Code 后，输入以下命令验证：

# 查看已安装的 MCP 服务器
claude mcp list

# 查看 MCP 服务器详情
claude mcp get chrome-devtools

如果看到 chrome-devtools 在列表中，说明安装成功！

五、使用实战：从零开始

5.1 基础操作示例

安装成功后，你可以直接在 Claude Code 中用自然语言操控浏览器。

示例 1：打开网页并截图

1	请打开 https://example.com，然后截取整个页面的截图

AI 会自动调用 MCP 工具：

browser_navigate - 打开网页
browser_screenshot - 截取屏幕

示例 2：提取页面内容

1	打开 https://news.ycombinator.com，获取首页所有新闻标题

AI 会：

打开 Hacker News
用 DOM 选择器提取标题元素
返回标题列表

示例 3：自动化表单填写

1	打开 https://example.com/login，填写用户名 "test@example.com"，密码 "password123"，然后点击登录按钮

5.2 调试实战

示例 4：检查控制台错误

1	打开我的项目 http://localhost:3000，检查是否有控制台错误

AI 会查看 console 日志，找出红色错误信息并分析原因。

示例 5：分析网络请求

1	打开 https://myapi.example.com，查看所有 API 请求的响应时间

AI 会：

捕获网络请求
分析每个请求的耗时
找出慢请求并给出优化建议

5.3 性能分析实战

示例 6：页面性能诊断

1	分析 https://mysite.com 的加载性能，找出瓶颈

AI 会：

录制性能追踪（Performance Trace）
分析关键指标（FCP、LCP、CLS）
给出具体优化建议

关键性能指标解释：

指标	全称	含义	理想值
FCP	First Contentful Paint	首次内容绘制	< 1.8s
LCP	Largest Contentful Paint	最大内容绘制	< 2.5s
CLS	Cumulative Layout Shift	累积布局偏移	< 0.1
TTI	Time to Interactive	可交互时间	< 3.8s

六、进阶技巧

6.1 连接已有的浏览器实例

如果你已经在调试某个页面，可以让 MCP 连接到现有浏览器：

步骤 1：以调试模式启动 Chrome

Windows:

1	"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

Mac:

1	/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

步骤 2：修改 MCP 配置

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222"
      ]
    }
  }
}

这样 MCP 会连接到你已有的浏览器，而不是启动新实例。

6.2 禁用数据收集（隐私考量）

Chrome DevTools MCP 默认会收集使用统计数据。如果你在意隐私：

1	"args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]

或设置环境变量：

1	export CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1

6.3 在 CI/CD 中使用

自动化测试场景建议配置：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--headless",
        "--no-usage-statistics"
      ],
      "env": {
        "CI": "true"
      }
    }
  }
}

七、常见问题排查

7.1 MCP 服务器启动失败

症状： Claude Code 提示 “Failed to start MCP server”

排查步骤：

检查 Node.js 版本：
1
node -v # 需要 v20.19+
手动测试 MCP 服务器：
1
npx chrome-devtools-mcp@latest
检查网络连接（npx 需要下载包）

7.2 浏览器连接失败

症状： 提示 “Cannot connect to browser”

解决方案：

确保 Chrome 已安装且是最新版
如果使用 --browser-url，确保 Chrome 以调试模式启动

检查端口是否被占用：

# Windows
netstat -ano | findstr 9222

# Mac/Linux
lsof -i :9222

7.3 工具调用超时

症状： 操作网页时长时间无响应

可能原因：

页面加载缓慢
网络问题
复杂页面导致操作卡住

建议：

使用 --headless 模式减少资源占用
给 AI 明确的等待指令：”等待页面完全加载后再…”
分步操作，不要一次性执行太多

7.4 Windows 特殊配置

Windows 用户可能遇到启动超时，建议添加环境变量：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "chrome-devtools-mcp@latest"
      ],
      "env": {
        "SystemRoot": "C:\\Windows",
        "PROGRAMFILES": "C:\\Program Files"
      },
      "startup_timeout_ms": 20000
    }
  }
}

八、最佳实践总结

8.1 使用建议

建议	说明
明确指令	告诉 AI 具体要做什么，不要模糊
分步执行	复杂任务拆成多个步骤
善用等待	让 AI 等待页面加载完成再操作
验证结果	让 AI 截图确认操作是否成功
保存日志	调试时让 AI 保存控制台日志供分析

8.2 安全注意事项

重要提醒： MCP 会将浏览器内容暴露给 AI 助手。

不要在浏览器中打开敏感页面（银行、密码管理器等）
不要填写真实密码或个人信息
CI/CD 环境建议禁用使用统计
定期检查 MCP 配置，移除不需要的服务器

8.3 与其他工具对比

工具	类型	优点	适用场景
Chrome DevTools MCP	AI+浏览器	AI自主操控、智能分析	调试、分析、自动化
Puppeteer	Node.js库	精细控制、成熟稳定	自动化脚本
Selenium	自动化框架	跨浏览器、生态丰富	E2E测试
Playwright	自动化框架	现代、快速、多浏览器	现代Web测试

九、总结

Chrome DevTools MCP 打通了 AI 助手与浏览器之间的壁垒，让 AI 从”只能聊天”进化为”能动手干活”。

核心价值：

零代码自动化 - 用自然语言操控浏览器
智能调试 - AI 分析问题，给出解决方案
性能洞察 - 自动识别性能瓶颈
开发提效 - 减少手动重复操作

学习路径建议：

第1天：安装配置，尝试打开网页、截图
第2天：调试实战，检查控制台、网络请求
第3天：自动化测试，填写表单、点击按钮
第4天：性能分析，了解 Web Vitals 指标
第5天：进阶使用，连接已有浏览器、CI集成

参考资料

中国显卡自研之路：追赶二十年差距，还要走多久？

发表于 2026-04-01 更新于 2026-04-14 分类于 AI Valine：

写在前面

2026 年 4 月，中国。

你想订阅一个 Coding Plan？那得费老鼻子劲了。

这不是个例。2026 年，中国的 AI 算力供应紧张到了”抢号”的地步。

背后的原因很简单：高端 GPU 被禁售，国产替代跟不上。

这篇文章，聊聊中国显卡自研的进度、挑战，以及算力危机暴露出的深层问题。

一、现状：2026 年的国产 GPU

1.1 华为昇腾：国产 AI 算力的主力

华为昇腾是目前国产 AI 算力最有希望的产品线：

产品	制程	状态	性能对标
昇腾 910B	7nm (中芯N+2)	已量产	约 A100 水平（2020年）
昇腾 910C	7nm	小规模量产	约 A100/A800 水平
昇腾 910D	7nm+	2025H2量产，2026部署	目标对标 H100

时间差距评估：

如果昇腾 910D 成功对标 H100（2022 年产品），那么：

性能对标：    昇腾 910D ≈ H100 (2022)
              ↙               ↘
时间差距：   2026年达到 → 2022年水平 = 落后 4 年

但同时 NVIDIA 已演进到：
              B200/B300 (2024-2025) + Rubin (2026)
              ↘
              仍领先 2-3 代

1.2 其他国产 GPU 厂商

厂商	产品	制程	状态	定位
海光	DCU 系列	7nm	已量产	CUDA 兼容，持续迭代
壁仞科技	BR100 改版	7nm	小规模	转型推理、边缘计算
摩尔线程	MTT S80/S4000	7nm	已量产	全功能 GPU，消费级+专业级
天数智芯	天垓 100	7nm	已量产	AI 推理

共同特点： 全部停留在 7nm 制程。

二、硬件瓶颈：制程封锁是核心困境

2.1 光刻机：无法获得的”关键设备”

高端 GPU 需要先进制程。而先进制程依赖光刻机。

制程	生产方	中国可获得性
3nm	TSMC、三星	❌ 完全封锁
4nm/4NP	TSMC	❌ 禁止出口中国
5nm	TSMC、三星	❌ 禁止出口中国
7nm	TSMC、三星、中芯	⚠️ 中芯可做，但产能有限
14nm+	中芯、华虹等	✅ 成熟量产

2026 年实际差距：

NVIDIA 制程演进:
  2022: H100 @ 4nm
  2024: B200 @ 4NP (改进4nm)
  2026: Rubin @ 3nm
  
中国可获得的最佳制程:
  2026: 7nm (中芯 N+2，DUV 多重曝光)
  
制程差距: 3nm vs 7nm = 2-3 代差距

2.2 EUV vs DUV：光刻机的代际差距

EUV（极紫外光刻机） 是制造 7nm 以下芯片的关键设备，由荷兰 ASML 生产，被美国禁止出口中国。

中芯国际只能用 DUV（深紫外光刻机） 做 7nm，需要”多重曝光”：

指标	EUV 单次曝光	DUV 多重曝光
步骤数	1次曝光	3-4次曝光
良率	80-90%	30-50%
成本	基准	2-3 倍
产能	基准	限制较大

这意味着：

同样生产一块 7nm GPU，中国成本更高、良率更低
实际可用芯片数量有限，无法大规模量产
7nm 是天花板，无法突破到 5nm/3nm

2.3 HBM 内存：另一个短板

高端 AI 训练需要 HBM（高带宽内存）：

GPU	内存规格	带宽
H100	80GB HBM3	3.35 TB/s
B200	192GB HBM3e	8 TB/s
昇腾 910D	估计 HBM2e	估计 1-2 TB/s

HBM 由韩国 SK 海力士、三星主导，技术门槛极高。国产 HBM 还在研发阶段，差距明显。

三、软件瓶颈：CUDA 的二十年差距

3.1 CANN vs CUDA：软件栈差距

华为昇腾使用 CANN（Compute Architecture for Neural Networks）作为软件栈：

CUDA 生态层级              CANN 生态层级
┌─────────────────┐        ┌─────────────────┐
│  PyTorch/TF     │        │  MindSpore      │ ← 华自研框架
├─────────────────┤        ├─────────────────┤
│  cuDNN/cuBLAS   │        │  ACL/OP API     │ ← 适配层
├─────────────────┤        ├─────────────────┤
│  CUDA Runtime   │        │  CANN Runtime   │
├─────────────────┤        ├─────────────────┤
│  NVIDIA GPU     │        │  昇腾 NPU       │
└─────────────────┘        └─────────────────┘

差距对比：

维度	CUDA (2026)	CANN (2026)
开发周期	20 年	约 6-7 年
开发者数量	500 万+	估计 15-20 万
算子库数量	3000+	估计 500-600 个
文档完善度	极其详尽	相对不足
bug 修复速度	全球团队支持	依赖华为内部团队

3.2 深度学习框架的适配困境

主流框架对 CUDA 是”原生级”支持，对昇腾是”适配级”：

PyTorch 官方支持优先级：
├── CUDA: 原生支持，性能最优，bug 优先修复
├── ROCm (AMD): 次级支持，问题较多
└── CANN (昇腾): 通过 torch_npu 扩展适配，非官方原生

这意味着：

PyTorch 新特性永远先在 CUDA 上实现
昇腾适配永远慢一步
很多算子没有优化实现
开源社区贡献几乎为零

3.3 算子移植的巨大工作量

一个深度学习模型可能有 数百个算子：

对比	数量
PyTorch CUDA 算子	超过 2000 个
昇腾已适配算子	估计 500-800 个
差距	超过 1200 个算子需要移植

每个算子都需要：

针对昇腾架构重新实现
性能优化调优
bug 测试修复

这是一项巨大且持续的工作。

四、人才瓶颈：GPU 专家在哪里？

4.1 GPU 架构设计人才稀缺

需要的人才类型	全球分布
GPU 微架构设计	主要在 NVIDIA、AMD，中国极少
并行计算编译器	CUDA 团队深耕 20 年，中国刚起步
高性能算子优化	需要硬件+算法双重知识，人才稀缺

现实： 全球 GPU 核心人才集中在 NVIDIA 和 AMD。中国需要”从零培养”或”海外引进”，但顶尖人才很难回国。

4.2 开发者转向成本

即使硬件做出来了，谁来用？

中国 AI 开发者 90%+ 使用 CUDA
学习 CANN 需要重新理解：编程模型、内存管理、性能优化策略
企业没有动力让员工学习新平台（除非强制）

五、追赶悖论：永远差几步

5.1 时间差距的变化

时间差距变化：
  2024: 昇腾 910B vs H100 = 落后约 6-8 年
  2026: 昇腾 910D vs B300 = 落后约 3-4 年
  
如果保持追赶速度：
  2028: 可能落后 2-3 年
  2030: 可能落后 1-2 年
  
但前提是：
├── 制程不被进一步封锁
├── 软件生态持续投入
└── NVIDIA 不加速迭代

5.2 NVIDIA 也在前进

更残酷的是：你追上今天的 NVIDIA，但 NVIDIA 又进化了。

2026 年时间线：

NVIDIA:
├── H100 (2022) ─────→ 成熟稳定，大规模部署
├── B200/B300 (2024-2025) ─→ 大规模出货
└── Rubin R100 (2026H2) ─→ 下一代发布

华为昇腾:
├── 910B (已量产) ─────→ 对标 A100 (2020)
├── 910C (小规模) ─────→ 对标 A100/A800
└── 910D (2026部署) ───→ 目标对标 H100 (2022)

差距：4 年（但 NVIDIA 还有 B300、Rubin）

六、挑战排序：从难到易

                    ┌─────────────────────────────────┐
                    │   中国 GPU 自研挑战金字塔       │
                    └─────────────────────────────────┘

Level 5: 生态网络效应（差距扩大）
         ├── CUDA 20 年，开发者 500 万+
         ├── 学术界默认 CUDA，论文难复现
         └── 全球开源社区全部绑定 CUDA

Level 4: 软件栈深度（差距缩小但仍明显）
         ├── 算子库 3000+ vs 600
         ├── PyTorch 适配约 70% 主流算子
         └── 调试工具、profiler 差距大

Level 3: 人才知识积累（持续投入）
         ├── 20 年培养的 GPU 专家
         ├── 编译器团队规模差距
         └── 性能优化经验积累

Level 2: 制造工艺差距（核心瓶颈）
         ├── 3nm vs 7nm，差 2-3 代
         ├── EUV 光刻机完全封锁
         └── HBM 内存技术落后

Level 1: 硬件架构设计（已有突破）
         ├── 昇腾 910D 架构设计成熟
         ├── 部分指标接近 H100
         └── 资金投入可解决

排序结论：

硬件设计（Level 1）：已有突破，可追赶
制造工艺（Level 2）：核心瓶颈，短期难以突破
人才积累（Level 3）：需要持续投入 5-10 年
软件栈（Level 4）：差距明显，但正在缩小
生态效应（Level 5）：差距扩大，最难跨越

七、算力危机：暴露了哪些问题？

7.1 表层问题：供应不足

2026 年，Coding Plan 抢不到，直接原因是：

问题	说明
NVIDIA GPU 禁售	H100、B200 等高端产品无法进口
国产 GPU 产能不足	7nm 良率低，产能有限
需求爆发式增长	大模型训练需求远超供给

7.2 深层问题：技术依赖

更深层的问题是技术依赖：

依赖类型	说明
硬件依赖	高端 GPU、光刻机、HBM 都依赖进口
软件依赖	CUDA 生态绑定，开发者只会 CUDA
人才依赖	GPU 核心人才在海外
生态依赖	学术论文、开源项目全部绑定 CUDA

一句话：AI 技术栈的每一层，都依赖海外技术。

7.3 更深层问题：战略误判

回顾过去十年，有哪些战略误判？

误判	后果
低估 AI 算力重要性	2022 年大模型爆发时，措手不及
低估制裁风险	没有”囤货”预案，禁售后严重短缺
高估国产替代速度	认为几年就能追上，实际差距仍大
忽视软件生态	只关注硬件，软件生态投入不足

八、未来展望：什么时候可以缓解？

8.1 短期（2026-2027）

方面	预期
昇腾 910D 部署	2026 年大规模部署，缓解部分需求
国家强制替代	政企、国企强制使用国产算力
算力共享平台	建立公共算力平台，提高利用率

缓解程度： 部分缓解，但高端需求仍紧张。

8.2 中期（2028-2030）

方面	预期
昇腾下一代	目标对标 B300，差距缩小到 2-3 年
软件生态成熟	CANN 算子适配 90%+，MindSpore 完善
7nm 产能提升	中芯产能提升，良率改善

缓解程度： 基本需求可满足，高端训练仍有限制。

8.3 长期（2030+）

方面	预期
制程突破？	取决于光刻机技术突破，不确定性高
生态建立	国内开发者形成规模，可能突破 50 万
差异化路线	不追求通用 GPU，聚焦特定领域优化

缓解程度： 取决于技术突破和持续投入。

8.4 关键变量

什么时候可以缓解，取决于三个变量：

变量	影响
美国制裁力度	制程封锁是否会进一步加强
软件生态投入	CANN、MindSpore 能否持续迭代
国内需求增速	大模型需求是否会放缓

九、可能的破局路径

9.1 短期：强制替代

国家强制推动：
├── 政务系统 → 强制使用国产算力
├── 国企央企 → 强制使用国产算力
├── 高校科研 → 优先使用国产算力
└── 互联网公司 → 部分强制替代

优点： 快速提升国产 GPU 需求，加速迭代
缺点： 效率损失，短期内性能不如 CUDA

9.2 中期：场景突破

不追求”通用 GPU”，聚焦特定场景：

场景	策略
推理场景	不需要顶级算力，国产 GPU 可胜任
边缘计算	功耗要求高，国产 GPU 有优势
特定行业	政务、金融、医疗，可以定制优化

9.3 长期：生态建设

开源社区建设：
├── 投资开源项目 → 让开发者愿意贡献
├── 建立开发者社区 → 提供培训、文档、支持
├── 学术合作 → 让高校用国产 GPU 做研究
└── 企业扶持 → 帮助企业迁移到国产平台

这是最难但最根本的路径。

十、总结：路还要走多久？

回到开头的问题：Coding Plan 抢不到，什么时候可以缓解？

答案取决于视角：

视角	时间估计
基本需求缓解	2026-2027（昇腾 910D 部署）
高端需求缓解	2028-2030（取决于技术突破）
追上 NVIDIA	可能需要 10-15 年
建立完整生态	可能需要 20 年

更关键的问题：

算力危机暴露的不仅是”供应不足”，而是整个 AI 技术栈的依赖：

硬件依赖：光刻机、GPU、HBM
软件依赖：CUDA 生态
人才依赖：GPU 专家稀缺
生态依赖：学术界、开源社区

这不是”买买买”就能解决的问题，而是需要 10-20 年持续投入的系统性工程。

写在最后

中国显卡自研之路，注定是一条艰难的路。

硬件层面：制程封锁是核心瓶颈，短期难以突破。

软件层面：CUDA 的二十年差距，需要持续追赶。

生态层面：开发者、学术界、开源社区的绑定，是最难跨越的障碍。

但好消息是：

昇腾 910D 如果成功量产，将大幅缩短差距
CANN/MindSpore 正在快速迭代
国产替代需求 正在加速推动技术进步

中国 GPU 自研，不是”能不能”的问题，而是”要多久”的问题。

短期（2-3 年）：基本需求缓解。
中期（5-8 年）：高端需求部分满足。
长期（10-15 年）：可能追上 NVIDIA。

但前提是：制裁不加剧、投入不中断、生态持续建设。

参考资料

CUDA：英伟达的二十年护城河，是怎么一步步挖出来的？

发表于 2026-04-01 更新于 2026-04-14 分类于 AI Valine：

从抢购算力开始

2026 年，想买个 Coding Plan 太难了。。。

中国的算力紧张，根源在哪？答案很简单：算力要靠显卡，显卡要买英伟达。

显卡是怎么制约算力发展的？为了搞清楚这个问题，我研究了很多方面，但始终绕不开英伟达这家企业。

很多人知道英伟达卖显卡，但不知道 CUDA 是什么。更不知道，CUDA 是英伟达最重要的一段护城河，以及这道护城河是怎么花了二十年一步步挖出来的。

这篇文章，就来聊聊 CUDA 的故事。

一、先搞清楚：CUDA 到底是什么？

CUDA = Compute Unified Device Architecture，翻译过来是”统一计算设备架构”。

听起来很抽象？用一个类比：

类比	说明
GPU 是”肌肉”	专门做大规模并行计算，力量惊人
CUDA 是”大脑”	指挥 GPU 怎么干活，把计算任务调度到各个核心

没有 CUDA，GPU 就只是个画图的机器——只能渲染游戏画面，不能做 AI 训练、科学计算这些”正经事”。

有了 CUDA，GPU 才变成了一台通用计算设备——可以跑任何需要大规模并行计算的程序。

这就是 CUDA 的核心价值：让 GPU 从”画图专用”变成了”万能计算器”。

二、起源：黄仁勋的一场豪赌

2.1 2006 年之前的 GPU 世界

在 2006 年之前，GPU 只有一个用途：打游戏。

想用 GPU 做科学计算？你得把计算任务”伪装”成画图任务：

你想计算：矩阵乘法
你得告诉 GPU：我要画一堆三角形，颜色就是计算结果

这就像：
你想请厨师做饭
但你只能用"点菜"的方式告诉他
"我要一盘红色的、方形的、味道像矩阵乘法的菜"

这种”骗 GPU 干活”的方式叫 GPGPU（General Purpose GPU）。极其痛苦，效率极低。

2.2 黄仁勋的”押注公司”时刻

2006 年，英伟达 CEO 黄仁勋做了一个决定：

投入 100 亿美元，开发 CUDA 平台

这是什么概念？当时英伟达的市值也就几百亿美元。华尔街疯了：

“你一个卖游戏显卡的公司，为什么要烧钱搞什么通用计算平台？”
“这钱烧下去，什么时候能赚回来？”

黄仁勋的回答很简单：“GPU 不应该只用来打游戏。”

G80 架构（GeForce 8800 GTX）是第一款支持 CUDA 的显卡。它实现了”统一着色器架构”——让 GPU 的所有核心可以执行任意计算任务，而不是只能画三角形。

2.3 漫长的黑暗期

CUDA 发布后，遭遇了长达 6-7 年的冷遇：

时间	状态
2006-2008	几乎无人问津，只有少数科研人员用
2008-2010	学术界开始关注，产业界无动于衷
2010-2012	股价低迷，投资者持续质疑

这期间，英伟达默默做了三件事：

免费开放 CUDA 工具包——任何开发者都可以下载使用
资助大学教育——让 CUDA 进入计算机课程
持续迭代硬件——Fermi、Kepler、Maxwell，每一代都优化 CUDA 性能

这就像种树：前六年只浇水不结果，但根系在悄悄扎深。

三、转折：2012 年 AlexNet

2012 年，ImageNet 图像识别竞赛，一个叫 Alex Krizhevsky 的研究生用两块 GTX 580 训练了一个深度神经网络。

结果：碾压全场。

对比	AlexNet	传统方法
错误率	15.3%	26%+
训练时间	几周	数月甚至数年
硬件成本	几千美元	数百万美元

关键点：AlexNet 的实现深度依赖 CUDA。

这让全世界 AI 研究者意识到一个公式：

GPU + CUDA + 深度神经网络 = AI 的未来

从这一天开始，CUDA 从”没人用的玩具”变成了”AI 研究的标配”。

四、发展：二十年迭代，从 1.0 到 14.x

CUDA 的发展不是一蹴而就，而是持续二十年的迭代：

CUDA 时间线（2006-2026）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2006      2012       2016       2022       2024       2026
  │         │          │          │          │          │
CUDA 1.0  AlexNet    Volta      H100       B200       Rubin
  │         │          │          │          │          │
  │         │          │          │          │          │
冷启动期  AI起飞     生态成熟   大模型爆发  主流出货   下一代

CUDA 版本	年份	关键特性
1.0	2006	基础编程模型
2.0	2008	双精度浮点支持
4.0	2011	动态并行
6.0	2014	统一内存
8.0	2016	Volta 架构优化
10.0	2018	Turing 架构、Tensor Core
11.0	2020	Ampere 架构、多实例 GPU
12.0	2022	Hopper 架构、H100
14.x	2026	Rubin 架构适配

二十年积累，意味着：

维度	2026 年数据
开发者数量	500 万+
CUDA 版本	14.x
算子库数量	3000+
GitHub 项目依赖	数千万
学术论文依赖	95%+

五、护城河：CUDA 是怎么”锁死”竞品的？

5.1 护城河的本质

护城河不只是”技术先进”，而是让竞争对手根本无法入场。

CUDA 的护城河是一个多层嵌套的陷阱：

                    ┌─────────────────────────────────────┐
                    │       CUDA 护城河层级               │
                    └─────────────────────────────────────┘

Level 5: 生态网络效应（最难跨越）
         ├── 全球 500 万开发者，都只会 CUDA
         ├── 学术论文默认 CUDA，想发 paper 必用 CUDA
         └── 开源项目全部绑定 CUDA

Level 4: 软件栈深度（很难）
         ├── 3000+ 高度优化的算子库
         ├── cuDNN、cuBLAS、NCCL 等核心库
         └── TensorRT、RAPIDS 等工具链

Level 3: 人才知识积累（难）
         ├── 20 年培养的 GPU 专家
         ├── 编译器、架构设计团队
         └── 性能优化经验

Level 2: 硬件制造差距（困难）
         ├── 3nm 制程领先 2-3 代
         ├── HBM3e 内存技术领先
         └── NVLink 高速互联

Level 1: 架构设计（相对可追赶）
         ├── 有公开论文可参考
         ├── 有人才储备
         └── 资金可投入

5.2 软件栈锁定

英伟达的软件栈是一个层层嵌套的体系：

┌─────────────────────────────────────────────┐
│   PyTorch / TensorFlow / JAX 等框架         │  ← 开发者直接接触
├─────────────────────────────────────────────┤
│   TensorRT / RAPIDS / Numba                  │  ← 性能优化工具
├─────────────────────────────────────────────┤
│   cuDNN / cuBLAS / NCCL / cuSPARSE           │  ← 核心计算库
├─────────────────────────────────────────────┤
│   CUDA Runtime / CUDA Driver API             │  ← 编程接口
├─────────────────────────────────────────────┤
│   NVIDIA GPU 硆件                            │  ← 物理基础
└─────────────────────────────────────────────┘

每一层都只对 NVIDIA 硬件优化：

层级	英伟达专有	竞品状态
深度学习框架	PyTorch 对 CUDA 优化最完善	AMD ROCm 支持残缺
计算库	cuDNN 性能碾压其他实现	AMD 没有对标库
通信库	NCCL 多卡通信成熟稳定	AMD 的 RCCL bug 满天飞
开发者	500 万 CUDA 程序员	ROCm 开发者寥寥无几

5.3 开发者锁定

假设你是一家 AI 公司的技术负责人，想迁移到 AMD：

挑战	具体内容
代码资产	你有 50 万行 CUDA 代码，全要重写
人才储备	你的团队精通 CUDA，需要重新培训
基础设施	CI/CD 全基于 NVIDIA GPU，要重建
第三方依赖	开源库都绑定 CUDA，迁移兼容性差
迁移风险	迁移期间 bug 多、性能下降

结论：迁移成本太高，几乎不可能。

这就是开发者锁定的本质：不是 CUDA 技术有多好，而是换一套生态的代价太大。

5.4 学术界锁定

更可怕的是学术界锁定：

AI 研究流程：
论文作者 → 写了 CUDA 代码 → 论文发表 → 代码开源

后续研究者 → 想复现论文 → 必须用 CUDA → 又写了更多 CUDA 代码

循环强化 → 所有论文都默认 CUDA → 学术界被绑定

95% 的 AI 论文默认使用 CUDA。想发 paper、想复现别人的结果、想用开源模型？你必须有 NVIDIA GPU。

六、竞品困境：AMD 和英特尔为什么追不上？

6.1 AMD 的 ROCm

AMD 推出了 ROCm（Radeon Open Compute）试图对标 CUDA：

对比维度	CUDA	ROCm
发布时间	2006	2016（晚10年）
开发者数量	500万	估计不足5万
算子库	3000+	约200个
稳定性	极高	经常出 bug
框架支持	原生级	适配级（残缺）

ROCm 的问题：

起步太晚——CUDA 已经 10 年积累，ROCm 才开始
兼容性差——很多 CUDA 代码无法直接迁移
文档缺失——开发者找不到资料
社区冷淡——没人愿意贡献代码

6.2 英特尔的 oneAPI

英特尔 2020 年才推出 oneAPI：

问题	说明
起步更晚	比 CUDA 晚 14 年
硬件不给力	英特尔 GPU 性能跟不上
开发者不学	没人愿意学一套新 API
市场份额低	几乎没有实际部署

6.3 追赶悖论

更残酷的是：你追上今天的 CUDA，但 CUDA 又进化了。

如果 AMD 今天追上 CUDA 2022 年的水平：
├── CUDA 已经是 2026 年的 14.x 版本
├── NVIDIA 已经发布 Rubin 架构
└── AMD 仍然落后 4 年

追赶速度：
├── NVIDIA 每年迭代一次
├── AMD 每年追赶一点
└── 差距永远存在

七、硬件护城河：不只是软件

很多人以为 CUDA 只是软件，其实硬件也是护城河的一部分：

7.1 制程领先

NVIDIA GPU	制程	发布年份
H100	4nm (TSMC)	2022
B200	4NP (TSMC)	2024
B300	4NP (TSMC)	2025
Rubin R100	3nm (TSMC)	2026H2

台积电最先进的制程，优先给 NVIDIA。

7.2 HBM 内存领先

高端 AI 训练需要高带宽内存（HBM）：

GPU	内存规格	带宽
H100	80GB HBM3	3.35 TB/s
B200	192GB HBM3e	8 TB/s
B300	192GB+ HBM3e	8 TB/s+

HBM 由 SK 海力士、三星生产，技术门槛极高。NVIDIA 有优先供应权。

7.3 NVLink 互联领先

多卡训练需要高速互联：

互联技术	带宽	状态
NVLink 4.0	900 GB/s	NVIDIA 专有，成熟稳定
NVLink 5.0	1.8 TB/s	2026 年推出
AMD Infinity Fabric	~400 GB/s	性能落后，稳定性差

八、总结：护城河是怎么挖出来的？

回到开头的问题：CUDA 的护城河是怎么一步步挖出来的？

答案：二十年持续投入 + 多层嵌套锁定。

第一步：2006 年，投入 100 亿，发布 CUDA
        ↓ 让 GPU 可以做通用计算

第二步：2006-2012，免费开放 + 大学教育
        ↓ 培养第一批开发者

第三步：2012 年，AlexNet 证明 GPU+CUDA=AI 未来
        ↓ 学术界开始绑定 CUDA

第四步：2012-2022，持续迭代 + 构建软件栈
        ↓ cuDNN、TensorRT、NCCL 等核心库

第五步：2022-2026，大模型爆发
        ↓ CUDA 成为"空气"，无处不在

结果：五层护城河，竞品无法入场

核心逻辑：

护城河类型	形成方式
技术护城河	20 年迭代，3000+ 算子库
生态护城河	500 万开发者，学术界绑定
经济护城河	迁移成本太高，换不起
硬件护城河	制程、HBM、NVLink 领先

一句话总结：

CUDA 的护城河，不是某个天才的设计，而是二十年持续投入的结果。

它像一条河，起初只是一条小溪，没人注意。但英伟达持续挖了二十年，终于变成一条竞品无法跨越的大河。

参考资料

大模型幻觉深度解析：为什么会一本正经胡说八道

发表于 2026-03-28 更新于 2026-04-28 分类于大模型幻觉 Valine：

背景

如果你问大模型：”明朝第一位皇帝是谁？”它会自信地回答：”朱元璋。”

但如果你问：”朱元璋的第三任妻子叫什么名字？”它可能回答：”马皇后。”——等等，马皇后是朱元璋的正妻，不是第三任妻子。模型编了一个看似合理、实则错误的答案。

这就是大模型的幻觉（Hallucination）：一本正经地胡说八道。

面试时如果只回答”因为它是个概率模型”，会被追问：概率模型怎么了？概率模型就一定会编东西吗？

今天我们从五个层面拆解这个问题，每一层都能让你的理解更有深度。

第一层：训练目标 ≠ 说真话

这是最根本的一层。大模型的训练目标，从一开始就不是”说真话”，而是”预测下一个最可能的 token”。

听起来差不多？差别很大。

训练信号的本质

模型在训练过程中，从未接受过这样的监督信号：

1 2	这句话是事实 ✓ 这句话是编的 ✗

它只知道：在这段文本里，前面出现了这些词，下一个词最可能是什么？

输入: "明朝开国皇帝是"
训练目标: 预测下一个词是 "朱"（概率最高）
         然后是 "元"（基于"朱"之后）
         然后是 "璋"（基于"朱元"之后）

模型学的是语言的统计规律，不是世界的真实知识。

流畅 ≠ 正确

从训练目标来看，模型追求的是流畅连贯，不是事实正确。

大多数情况下，流畅连贯的文本恰好也是真实的。所以大部分场景下，模型看起来在说真话。

但一旦”说得通”和”说得对”发生冲突：

问题: "林黛玉倒拔鲁智深的故事发生在哪一回？"
模型可能回答: "发生在《红楼梦》第X回..."
              ↑
              编造了一个看似合理、实则完全不存在的故事

为什么？因为”林黛玉倒拔鲁智深”本身是个荒谬的问题，但模型会硬着头皮让它”说得通”——生成一个符合语言规律的回答，而不是指出这个问题本身是错的。

第二层：不知道自己不知道什么

人类面对不确定的问题，会有”自知之明”：

1 2	问: "量子力学中薛定谔方程的第三种推导方式是什么？" 人: "我不确定，这个我不太懂。"

但大模型没有这个能力。

训练时的”强制回答”约束

模型训练时被要求必须生成一段通顺的回答，而不是可以选择”我不知道”。

训练数据里很少有这种模式：

1 2	问题: XXX（超出知识范围）回答: 我不知道 / 这个问题我无法回答

即使有，比例也极低。模型学到的是：有问题 → 必有回答。

硬着头皮编

所以，哪怕模型对问题毫无头绪，也会生成一段看似合理的内容：

问: "《三体》中章北海的第四个孩子叫什么？"
模型: "章北海的第四个孩子叫章XX..."
      ↑
      语气自信，实则章北海根本没有四个孩子

越是不确定的问题，模型越可能编造——因为它没有”我不确定”这个选项。

第三层：知识是”压缩”的，不是”精确存储”的

大模型不是把所有知识像数据库一样一字不差存下来。

知识的存储方式

模型把海量文本压缩成参数里的统计模式。这个过程类似于：

方式	特点
数据库存储	精确、可检索、一字不差
模型参数存储	模糊、统计性、细节易混淆

就像人记东西，只会记个大概，细节会模糊、会混淆。

压缩带来的问题

模型学到的是模糊的关联、大概的规律，而不是精确的事实：

模型可能学到的:
- 朱元璋 → 明朝 → 开国皇帝 → 南京 → 马皇后（模糊关联）
- 朱元璋 → 某年某月某日登基（大概规律）

模型不太可能学到的:
- 朱元璋的第三任妻子具体叫什么名字
- 某个具体事件发生的精确日期

一旦需要精准细节（具体日期、数据、人名），就容易张冠李戴、脑补编造。

第四层：训练数据本身有”坑”

模型的知识全部来自训练数据。但互联网数据本身充满问题。

数据质量问题

问题类型	例子
错误信息	谣言、虚假新闻
偏见信息	带倾向性的观点
过时信息	2023年的新闻，2026年问就不对了
随意编造	网友随口胡说的内容

这些都是模型的”教材”。模型分不清对错，只会把学到的”错误规律”当真话说。

垃圾进，垃圾出

训练数据中有: "诸葛亮发明了原子弹"（某个网友编的段子）
模型可能学到: 诸葛亮 → 发明 → 原弹（统计关联）
问: "诸葛亮发明了什么？"
答: "诸葛亮发明了原子弹..."
    ↑
    模型把段子当事实了

这不是模型”蠢”，而是训练数据本身就有问题。

第五层：生成时的”概率采样”容易跑偏

大模型生成答案，不是逻辑推理，而是按概率”猜”下一个词。

一步步”猜”的问题

每一步都选”最可能的词”，但一步错，步步错：

第1步: 选对了 → 上下文正常
第2步: 选对了 → 继续正常
第3步: 选了个"次优"选项 → 小偏差
第4步: 基于小偏差继续 → 偏差放大
第5步: ... → 大错误

小偏差会累积成大错误，尤其是遇到模糊、冷门、矛盾的问题时。

概率分布越乱，越容易跑偏

1
2
3

常见问题: 概率分布集中 → 选对的概率高
冷门问题: 概率分布分散 → 选错的概率增加
模糊问题: 多个候选概率接近 → 容易选到错误的那个

五层原因的叠加效应

幻觉不是单一原因造成的，而是五层叠加：

第1层: 训练目标追求流畅而非正确
   ↓ 基础设定偏离
第2层: 没有自知之明，不知道边界
   ↓ 硬着头皮回答
第3层: 知识压缩存储，细节模糊
   ↓ 精确信息易错
第4层: 训练数据本身有错
   ↓ 学到错误内容
第5层: 概率采样容易跑偏
   ↓ 小错累积成大错
   ↓
最终输出: 一本正经胡说八道

如何缓解幻觉？

了解了原因，才能针对性地解决。

用户层面的技巧

技巧	作用
追问细节	让模型暴露不确定的地方
要求引用来源	逼迫模型承认”不知道来源”
设置温度参数为 0	减少随机性，让模型更保守
明确告知”如果不知道就说不知道”	给模型一个”放弃”的选项

技术层面的方案

方案	原理
RAG（检索增强生成）	先检索真实资料，再基于资料回答
知识图谱 grounding	把回答锚定到可验证的知识节点
多模型交叉验证	让多个模型回答同一问题，对比差异
置信度输出	让模型输出对答案的置信程度
事实核查模块	对模型的回答做二次验证

这些方案各有优劣，但核心思路都是：引入外部真实信息，弥补模型内部的缺陷。

总结

大模型”一本正经胡说八道”，不是它故意骗你，也不是它笨，而是底层设计、训练目标、知识存储、数据质量、生成机制五层原因叠加的必然结果。

用一个公式概括：

1	幻觉 = 训练目标偏差 + 无自知之明 + 知识压缩 + 数据污染 + 概率跑偏

理解了这一点，你就会明白：大模型是一个流畅的语言生成器，不是精准的事实数据库。

用模型时，把它当作一个能快速整理思路、启发想法的助手，而不是权威的知识来源。关键事实，还是要自己核实。

参考资源：

AI Agent 工程师的核心能力

发表于 2026-03-21 更新于 2026-05-21 分类于 AI Valine：

前几天看到一个视频在技术群里被转发，讲 AI Agent 工程师的 4 个核心技能：编程功底、Prompt Engineering、系统思维、领域知识。评论区一堆人收藏说”太对了”。

我不否认这个框架，但实际做了几个 Agent 项目上线之后，我发现真正卡脖子的能力，那视频压根没提。

阅读全文 »

大模型 Function Calling：底层原理与训练机制

发表于 2026-03-21 更新于 2026-04-29 分类于 Function Calling Valine：

背景

“Function Calling 的原理是什么？”，很多人的理解是这样的：

“模型读懂了用户的意图，判断出需要调用工具，然后决定生成一段调用指令……”

听起来很合理？但实际上，这些词——读懂、判断、决定——都是危险的词。

为什么危险？因为它们暗示模型有某种”理解”和”决策”能力，仿佛模型真的在”思考”。但大模型的本质从来没变过：Next Token Prediction（预测下一个词）。

Function Calling 并没有引入什么神秘的”推理机制”，它只是让模型学会了在特定情况下切换输出格式——从自然语言切换成结构化的 JSON。

今天我们就来拆解 Function Calling 的底层原理，看看模型到底是怎么”学会”调用工具的。

一、核心原理：没有魔法，还是预测

先说结论：Function Calling 没有引入任何新的推理机制，底层仍然是 Next Token Prediction。

1.1 模型到底在做什么？

无论是否启用 Function Calling，模型的计算过程都是一样的：

1	输入 → Transformer 计算 → 在整个词表上做概率分布 → 采样下一个 Token

区别只在于：启用 Function Calling 后，模型的词表里多了几个特殊 Token，训练数据里多了”工具调用”的样本。

1.2 一个形象的比喻

想象你训练了一只鹦鹉，它会模仿人类说话：

普通模式：你教它说”你好”、”谢谢”、”再见”，它学会在合适场合说这些话
Function Calling 模式：你额外教它一套”暗号”，比如听到”几点了”就说 [CALL:get_time]

鹦鹉并不知道”几点了”是什么意思，也不知道 get_time 真的会获取时间。它只是学会了：听到 X，就说 Y。

Function Calling 的本质也是这样：模型学会了在特定上下文下，输出特定格式的文本——只是这个文本恰好是 JSON 格式的工具调用指令。

二、两阶段训练：如何教会模型”调用工具”

模型是怎么学会 Function Calling 的？主要通过两个阶段的训练。

2.1 SFT 阶段（监督微调）

这个阶段，模型通过大量标注样本，学会三件事：

学习内容	训练样本示例
什么时候切换输出模式	用户问”今天天气怎么样？” → 模型输出 `[tool_call]` 开始标签
怎么写调用指令	`[tool_call]{"name": "get_weather", "args": {"city": "北京"}}[tool_call_end]`
怎么处理工具返回结果	工具返回 `{"temp": 25, "condition": "晴"}` → 模型输出”今天北京天气晴朗，气温25度”

训练数据的结构大致如下：

{
  "messages": [
    {"role": "user", "content": "今天北京天气怎么样？"},
    {"role": "assistant", "content": "[tool_call]{\"name\": \"get_weather\", \"args\": {\"city\": \"北京\"}}[/tool_call]"},
    {"role": "tool", "content": "{\"temp\": 25, \"condition\": \"晴\"}"},
    {"role": "assistant", "content": "今天北京天气晴朗，气温25度。"}
  ]
}

模型通过大量这样的样本，学会了一个模式匹配：

1	用户问题涉及"可调用的工具" → 输出 [tool_call] → JSON 格式的调用指令

2.2 RL 阶段（强化学习）

SFT 阶段学会了”基本操作”，但还有很多边界情况需要精调：

边界情况	RL 阶段的优化
该调工具时没调	增加奖励，强化正确行为
不该调工具时调了	减少奖励，抑制错误行为
参数填错	调整参数生成的准确性
调用错工具	优化工具选择的准确性

这个阶段的核心是：让模型学会”分寸感”——知道什么时候该调用，什么时候不该调用。

三、特殊 Token 的作用：给外部系统的信号

Function Calling 的关键设计之一，是引入了特殊 Token。

3.1 什么是特殊 Token？

特殊 Token 是专门添加到词表中的”标记”，比如：

1
2
3

[tool_call]     → 工具调用开始
[/tool_call]    → 工具调用结束
[tool_result]   → 工具返回结果

这些 Token 不是普通的文本，而是专门设计的信号。

3.2 为什么需要特殊 Token？

如果没有特殊 Token	有了特殊 Token
模型输出 `get_weather(北京)`	模型输出 `[tool_call]{"name":"get_weather"}[/tool_call]`
外部系统需要解析自然语言	外部系统只需检测 `[tool_call]` 标签
解析容易出错、歧义	解析简单、确定性高

特殊 Token 的本质作用：给外部系统一个确定性的信号。

当模型输出 [tool_call] 时，外部系统就知道：接下来要截获这段文本，解析 JSON，执行调用，然后把结果返回给模型。

3.3 不同厂商的特殊 Token 设计

厂商	开始标签	结束标签	特点
OpenAI	`<function_call>`	`</function_call>`	XML 风格
Claude	`<tool_use>`	`</tool_use>`	XML 风格
某些国产模型	`[TOOL_CALL]`	`[/TOOL_CALL]`	方括号风格

虽然形式不同，但核心逻辑一样：给外部系统一个明确的”截获点”。

四、推理过程：概率如何决定输出

让我们看看模型在推理时到底发生了什么。

4.1 整个词表上的概率分布

模型在生成每个 Token 时，会在整个词表上计算概率分布。假设词表有 5 万个 Token，模型会计算每个 Token 的”可能性”：

用户输入: "今天北京天气怎么样？"

Token 概率分布（简化示例）：
- "今天" : 0.15
- "北京" : 0.08
- "天气" : 0.12
- [tool_call] : 0.45  ← 最高！
- "我" : 0.05
- ...

在这个例子中，[tool_call] 的概率最高，所以模型会输出它。

4.2 上下文如何影响概率

上下文会强烈影响概率分布：

上下文 1: 用户问"今天北京天气怎么样？" + 工具列表包含 get_weather
→ [tool_call] 概率飙升 → 输出工具调用

上下文 2: 用户问"今天北京天气怎么样？" + 工具列表为空
→ "今天" 概率最高 → 输出自然语言回答

上下文 3: 用户问"你好"
→ [tool_call] 概率很低 → 输出自然语言

这就是为什么工具描述很重要：工具描述会被注入到上下文中，”暗示”模型在什么情况下应该调用什么工具。

4.3 概率飙升的机制

可以把这个过程类比为：

模型就像一个"概率调节器"：
- 工具描述 = "暗示信号"
- 用户问题 = "触发条件"
- 当两者匹配 → [tool_call] 的概率被"推高"

模型并没有”决定”调用工具，只是概率计算的结果恰好是 [tool_call]。

五、外部执行：模型只生成，不执行

这是一个关键概念：模型本身不执行函数，只生成文本。

5.1 完整的执行流程

┌─────────────────────────────────────────────────────────────┐
│                        用户提问                               │
│                   "今天北京天气怎么样？"                        │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                       大模型生成                              │
│            输出: [tool_call]{"name":"get_weather"}[/tool_call]│
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                     外部系统截获                               │
│         检测到 [tool_call] → 解析 JSON → 执行函数              │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                       函数返回结果                             │
│                  {"temp": 25, "condition": "晴"}              │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                    结果注入回上下文                            │
│      模型看到工具结果 → 生成最终回答："今天北京天气晴朗..."       │
└─────────────────────────────────────────────────────────────┘

5.2 为什么设计成外部执行？

如果模型内部执行	外部执行的设计
模型需要”知道”所有工具的实现细节	模型只需”知道”工具的描述和参数格式
新增工具需要重新训练模型	新增工具只需更新描述，无需重训练
安全风险：模型可能执行危险操作	外部系统可以做权限控制、审计
无法处理实时数据	外部系统可以查询最新数据

外部执行的核心优势：模型只负责”说”，外部系统负责”做”。

六、四种失败模式

Function Calling 不是万能的，模型会犯错。常见的失败模式有四种：

6.1 调用错工具

用户: "帮我查一下明天的股票行情"
工具列表: [get_weather, send_email, search_web]

模型输出: [tool_call]{"name": "get_weather", "args": {...}}[/tool_call]
                    ↑ 应该调用 search_web，却调用了 get_weather

原因：工具描述不够清晰，或者模型对工具功能的理解有偏差。

6.2 参数填错

用户: "帮我订一张明天从北京到上海的机票"
工具: book_ticket(from_city, to_city, date)

模型输出: [tool_call]{"name": "book_ticket", "args": {"from_city": "上海", "to_city": "北京"}}
                                                      ↑ 起点终点搞反了

原因：模型对参数的”填充”是基于上下文的语义理解，而不是精确的逻辑推理。

6.3 该调工具时没调

用户: "现在几点了？"
工具列表: [get_current_time]

模型输出: "现在是2024年..." ← 编造了一个答案，没有调用工具

原因：工具描述不够突出，或者模型”自信”地认为自己知道答案。

6.4 不该调工具时调了

用户: "讲一个关于时间的故事"
工具列表: [get_current_time]

模型输出: [tool_call]{"name": "get_current_time"}[/tool_call]
                    ↑ 用户只是想听故事，不需要真的查时间

原因：模型”过度积极”，看到”时间”相关词汇就触发工具调用。

6.5 失败模式总结

失败模式	典型原因	缓解方法
调用错工具	工具描述不清晰	优化工具描述，增加示例
参数填错	语义理解偏差	参数校验，增加约束
该调没调	模型过度自信	提示词引导，RL 优化
不该调调了	过度积极触发	工具描述加”适用场景”

七、不同厂商的差异

虽然 Function Calling 的核心原理相同，但不同厂商在实现上有差异：

7.1 特殊 Token 设计

厂商	设计风格	特点
OpenAI	XML 风格标签	可读性好，易于解析
Claude	XML 风格标签	支持多工具并行调用
部分国产模型	方括号风格	与系统提示词更统一

7.2 工具描述注入方式

方式	说明	优点	缺点
System Prompt 注入	工具描述放在 System Prompt	灵活，易于调试	占用上下文
特殊字段注入	API 有专门的 `tools` 字段	结构清晰，便于管理	需要解析
混合方式	部分在 System Prompt，部分在 API	兼顾灵活和结构	可能冲突

7.3 并行调用支持

# OpenAI：支持并行调用多个工具
response = client.chat.completions.create(
    model="gpt-4",
    messages=[...],
    tools=[
        {"type": "function", "function": {"name": "get_weather"}},
        {"type": "function", "function": {"name": "get_stock"}}
    ]
)
# 模型可以一次性输出多个工具调用

# 部分模型：只支持串行调用
# 需要先调用一个工具，返回结果后，再决定是否调用下一个

7.4 强制/禁止调用控制

控制方式	说明
`tool_choice: "auto"`	模型自动决定是否调用工具（默认）
`tool_choice: "required"`	强制模型必须调用某个工具
`tool_choice: "none"`	禁止模型调用工具
`tool_choice: {"name": "xxx"}`	强制调用指定的工具

八、总结：理解 Function Calling 的五个要点

最后，用五个要点总结 Function Calling 的底层原理：

要点一：没有新机制

Function Calling 没有引入新的推理机制，底层仍然是 Next Token Prediction。

模型只是学会了在特定上下文下，输出特定格式的文本——只是这个文本恰好是 JSON 格式的工具调用指令。

要点二：两阶段训练

1 2	SFT 阶段：教会模型"基本操作"（何时调用、怎么写、怎么处理结果） RL 阶段：精调"分寸感"（边界情况的处理）

要点三：特殊 Token 是信号

特殊 Token 不是给模型”理解”的，而是给外部系统截获的确定性信号。

要点四：外部执行

模型只生成文本，不执行函数。 外部系统负责：截获指令 → 执行调用 → 返回结果。

要点五：概率决定一切

模型没有”决定”调用工具，只是概率计算的结果恰好是 [tool_call]。上下文（包括工具描述）会影响概率分布，从而影响输出。

写在最后

理解 Function Calling 的底层原理，更重要的是：

知道它的局限性：模型会犯错，需要外部校验
知道怎么优化：工具描述、提示词设计、参数校验
知道怎么调试：当模型调用错误时，从概率角度分析原因

“Function Calling 的底层原理是 Next Token Prediction，没有引入新的推理机制。模型通过 SFT 和 RL 两阶段训练，学会了在特定上下文下输出特殊 Token 标记的 JSON 格式调用指令。特殊 Token 是给外部系统的信号，外部系统负责截获、执行和返回结果。”

这个回答，比”模型读懂了意图、判断需要调用工具、决定生成调用指令”要准确得多。

参考资源：