🎬 开场 · 5 天 · 1 亿用户

旧金山一家叫 OpenAI 的小公司 · 在博客里发了一篇低调的文章 · 标题写着 “Introducing ChatGPT”。

没有发布会 · 没有大新闻 · 工程师们都以为这只是个内部测试品。

5 天后 · 100 万用户。Instagram 用了 30 个月 到这个数 · TikTok 用了 9 个月。

ChatGPT 用了 5 天。

但 ChatGPT 不是凭空出现的

那一刻看起来是”奇迹” · 其实是 OpenAI 7 年 · 一条路线的总爆发。下面这条鱼骨图 · 把这 7 年最关键的节点全摆出来 · 让你一眼看清”AI 时代”是怎么被一家公司一步步推出来的。

看出来了吗 · ⭐ 那个节点之前 · 已经有 7 年的论文 · 资本 · 失败 · 训练铺路 —— GPT-1 → GPT-2 → 微软投钱 → GPT-3 → InstructGPT 的 RLHF。ChatGPT 不是天才一闪 · 是路线坚持的终点。这个视角 · 也是你看后面所有 AI 公司的最佳镜头。

今天你会学到的概念地图

🏗 前置 · Transformer · 一切的起点

在正式开始之前 · 先 5 分钟讲清楚一件事：所有今天的 LLM · 底层都是同一个东西 —— Transformer。

ChatGPT 的 T · Claude 用的 · Gemini 用的 · DeepSeek 用的 · Llama 用的 —— 全是 Transformer。理解它 · 你就理解了 AI 这 3 年起飞的”骨架”。

故事 · 一篇 2017 年的论文 · 没人意识到改变了世界

等等 · 它跟”神经网络”什么关系？

很多同学听到 “Transformer” · “神经网络” · “深度学习” 几个词就懵了 · 它们到底什么关系？

一句话：Transformer 就是一种神经网络 · 神经网络有很多种 · Transformer 是其中最适合处理语言的那种。

下面这个 36 秒的动画用 3Blue1Brown 自己写的开源动画引擎 Manim 做的 · 用最经典的”识别手写数字”例子 · 把每一层的输入 / 输出都标清楚：

明白这个之后 · 我们再回头看：“Transformer 之前 vs 之后” 的差别就一目了然 ——

核心思想 · 一张图看懂

Transformer 之前 · AI 读一个句子像念课文 · 一个字一个字按顺序读 · 慢 · 还容易忘前面说过什么。

Transformer 之后 · AI 一眼看完整句话 · 所有词同时”互相看” · 知道哪些词跟自己有关 · 哪些不相关。

关键概念 · “注意力”（Attention）· 互动演示

Transformer 的核心机制叫 Attention（注意力）—— 每个字”看”其他字时 · 关注度不一样。

下面这个动画演示一个真实的歧义句：“他打开苹果电脑 · 吃了一口苹果” —— 同一个”苹果”出现两次 · 一次是品牌 · 一次是水果。Transformer 如何分清？切换 tab 看看它把”注意力”放在哪里：

同一个词在不同上下文里 · 含义完全不同 —— Attention 让 AI 真正”理解”上下文 · 这是 Transformer 的核心魔法。

为什么这么重要？

想深入了解 · 3 个最好的资源

💡 一句话记住 —— Transformer = 让 AI 一眼看完整句话 · 每个词同时跟所有词”对话”的架构。所有今天的 LLM 都建在它上面 · 没有它 · 没有 ChatGPT · 没有 Claude · 没有 Cursor · 没有今天的一切。

模块 A · 把 Transformer 装上规模 · 这就是 LLM

承上启下 —— 你刚学的 Transformer 是一种架构 · 一套设计图。它本身还不会做任何事 —— 就像一张电路图不是手机。要变成你今天能调用的 ChatGPT / Claude · 还需要 3 步。

Transformer ≠ LLM · 三个加号

💡 一句话 —— LLM = Transformer × 规模 × 数据 × 调教。少一个都不是你今天用的 AI。

它「看见」的世界 · 不是字母 · 是 token

回到刚才那个 Transformer 动画 —— 它处理的最小单位是什么？

不是字母 · 不是单词 · 是 token —— 模型字典里被压成数字的”片段”。

这意味着 —— LLM 从来没”看见”过单独的字母。它看到的是 ID 序列。在它的世界里 · “strawberry” 不是 10 个字母 · 是 3 个数字。

这个架构的直接后果 · 一个小实验

现在带着这个理解 · 做个实验。问任何 AI：“strawberry 里有几个 r？”

它会答错。

但这不是 AI 笨 · 是架构层面的必然 —— 它在看 [4842, 3231, 821] · 不在看字母。下面这个 demo 让你亲眼看一遍这个切分过程：

💡 泛化的力量 —— 记住这个例子 · 它能让你预测所有LLM 在”字母层”会出错的场景：拼写检查 · 押韵 · 字数限制 · 字符级反转 · 单字数数。只要任务需要 LLM 看见单字符 · 它就会失败。

站在 Transformer 之上 · LLM 怎么”预测下一个词”

你刚学的 Transformer 是个架构 · 描述的是 “N 个 token 同时通过 attention 互看”。但你按下 ChatGPT 的回车之后 · 它具体怎么用这个架构 · 一个字一个字给你回答的？拆开就 5 步：

💡 这就是 LLM 的”心跳” —— 下面 7 个根概念 · 每个都对应这个流程里的某个环节：

7 个 LLM 根概念 · 挂回流程图

记住上面那 5 步 + 自回归循环。下面 7 张卡 · 每一张都对应这个心跳里的某个位置 —— 你看完会发现 · 之前听过的所有 AI 词汇 · 突然都”挂”得上去了：

点任一卡看动画 demo：

模块 B · AI 的”能力进化史” · 3 年 7 次跳跃

故事钩子 —— 2023.6.13 OpenAI 在博客里发了 “Function Calling” · 当时工程师没在意 · 但这是 LLM 历史上第二重要的一天 —— AI 第一次”有了手”。

下面这条时间线 · 是过去 3 年 AI 能力进化的全部关键节点。点开每个节点看真实示例：

看动画 · function calling 这一跳到底发生了什么？

时间线里最关键的节点就是 2023.6 那个 function calling。下面这个动画用一个”查天气”的小例子 · 把整条链路演一遍：

揭开真相 · LLM 其实从来没有「调用」任何工具

刚刚那个动画看上去 · LLM 在”调用”weather API。但是 · 倒回模块 A 你学的那 5 步心跳 ——

LLM 只能做一件事 · 那就是预测下一个 token。

那它到底怎么”调用”任何东西的？

真相：它没有。整个 function calling 机制里 · 模型还是只在做 next-token prediction —— 只不过它学会了在某些时候输出一种特定格式的文字。真正去调 API 的 · 是你的代码。

下面 6 步把这个真相拆透。

tools: [{
name: "get_weather",
description: "查询某个城市的实时天气",
parameters: {
  city: { type: "string", description: "城市名" }
}
}]

<tool_result name="get_weather">
{"temp": 28, "rain": false, "city": "上海"}
</tool_result>

「上海今天 28°C · 没有下雨 · 适合户外活动 ✓」

那 · 如果让它「一直循环」呢？· Agent Loop

刚才那 6 步是一次 function calling 的完整流程。但很多任务做不完 —— 比如调一个 bug · 你需要：先找代码 · 再读代码 · 跑测试看错误 · 改代码 · 再跑测试验证。5 次工具调用 · 5 个 tool_result 累积进 context · 才能完成 1 个任务。

这就是 agent loop —— 把刚才那 6 步接着循环 N 次：每次模型看着之前所有 tool_result 来决定下一次要 call 什么 tool · 直到它的输出里不再包含 <tool_call> —— 那意味着模型认为任务完成了。

agent ≠ 新机制·agent = function calling × N 轮 · 直到模型不再 tool_call

下面这个动画演一次完整的 5 轮调 bug · 你能看到每一轮都对应刚才那 6 步 · 而每一轮的 think 都基于上一轮的 tool_result：

关键洞察 · 3 年 vs 30 年

3 年内 · AI 从”接龙工具”变成”能跑在 terminal 里自己干活的 agent”——这是技术史上前所未见的速度。

模块 C · AI 工具世界的「USB-C」· MCP

承上启下 —— 模块 B 的最后我们看到 · agent = function calling 反复跑。但有个问题没解决：每家 AI app 都要自己写和每个数据源（GitHub / Slack / Postgres …）的接驳代码。这就是 2024.11 Anthropic 推 MCP 想解决的问题 —— 给 AI 工具世界一个”USB-C”。

1 · 看清问题 · 为什么需要一个标准

把所有当下的 AI 应用列出来：Claude Desktop · Cursor · ChatGPT · Windsurf · Zed · Cline · Continue · Copilot Studio · Aider · Replit … 假设 M 个。

把所有想接的数据源也列出来：GitHub · Slack · Postgres · Drive · Notion · Linear · Sentry · Stripe … 假设 N 个。

问题：每家 AI app 都要为每个数据源单独写胶水代码 · 总工程量 = M × N。下面这个动画把这个数字的可怕讲清楚：

2 · 灵感来源 · IDE 世界 8 年前解决过同样的事

MCP 不是凭空发明的。它直接借鉴了 LSP（Language Server Protocol）—— 微软 2016 年为 IDE 世界搞的同款标准。

💡 同一招打两次 · 8 年前打 IDE 战 · 现在打 AI 战。LSP 的成功（VSCode 主流地位的一个核心原因）就是 MCP 的样板。

3 · 2024.11.25 · Anthropic 开源 MCP

4 · 核心架构 · 三角色 · 看动画

5 · Server 暴露给 LLM 的 3 类原语

每个 MCP server 都对 client 声明自己能提供什么。一共就 3 类：

{
name: "create_issue",
inputSchema: {
  title: "string",
  body: "string"
}
}

{
uri: "file:///docs/spec.md",
mimeType: "text/markdown"
}

{
name: "review_pr",
arguments: [
  { name: "pr_number" }
]
}

💡 关键区别 · tools 模型主动调（“do something”）· resources 模型/用户主动读（“give me data”）· prompts 用户主动触发（“use this template”）。

6 · Client 反向给 Server 的 2 类原语（进阶）

MCP 不止单向 · Client 也对 Server 暴露能力：

7 · 传输层 · 模型怎么”听”和”说”

MCP 协议归协议 · 实际跑起来需要传输层。当前两种主流方式：

8 · 一次完整工作流 · 步进式协议演示

下面这个交互组件 · 把刚才架构动画里的”一次 tool_call”拆成 8 步 · 每步都能看到真实的 JSON-RPC 报文 —— 点 step 或点 ▶ 看完整循环：

// 内部操作 · 无 JSON-RPC 消息
spawn("github-server", { stdio: true })
// 或 fetch("https://mcp.example.com/sse")

💡 看出来没？这其实就是模块 B 学的 function calling + agent loop · 只是把”tools 哪儿来”那一步用 JSON-RPC 标准化了。Step 6→7→8 = function calling 单轮 · Step 8→6 的循环 = agent loop。

9 · 生态全景 · 2026 现状

10 · 推荐资源 · 想深挖去哪

11 · 为什么 MCP 是 AI 时代的「USB-C」

💡 学完这个模块你应该能：1) 看到任何 AI 工具集成就能说出它是不是 MCP · 2) 知道为什么 Cursor 的 “MCP integration” 是个大新闻 · 3) 想给自己的产品做 AI 集成时 · 第一反应是”写个 MCP server”而不是”对接 Claude API”。

模块 D · 现代 AI 必须掌握的 3 个基本概念

承上启下 —— 模块 A/B/C 讲了模型本身的机制（next-token · function calling · MCP）。模块 D 讲怎么让模型在真实任务里”看见正确的东西” —— 这才是用 AI 的真功夫。3 个概念 · 一个比一个高维：

Level 1 · Prompt 工程 · 原理与应用

1.1 原理 · 为什么 prompt 是「第一杠杆」

回忆模块 A 那 5 步心跳：LLM 是 next-token predictor。它输出的每个 token · 都是基于当前 context 的 softmax 抽样。

你的 prompt 进入 context → 直接改变 softmax 的概率分布 → 直接改变输出。这就是为什么 prompt 工程有效 —— 它不是”心理学技巧”· 是数学影响。

1.2 5 个核心技术 · 每个都对应模型的某个机制

把这段日志按"错误类型 / 时间 / 影响范围"
分类 · 输出 markdown 表格。

输入: "苹果"   输出: { 词性: "名词", 类: "水果" }
输入: "跑步"   输出: { 词性: "动词", 类: "运动" }
输入: "蓝色"   输出: ?

问题: ...

先一步步分析 · 再给最终答案。

你是一个 senior security engineer。
回答时只列具体技术点 · 不说商业意义。
不熟的领域 · 直说"不知道"。

response_format: {
  type: "json_schema",
  schema: {
    severity: { enum: ["low","med","high"] },
    summary:  { type: "string", maxLength: 200 },
    affected: { type: "array", items: { type: "string" } }
  }
}

1.3 实战 · 同任务的 prompt 对比

写个 transfer 函数

用 Solidity 0.8.20 写一个 ERC-20 transfer 函数：

要求：
- 余额不足要 revert，错误信息 "insufficient balance"
- 转账成功 emit Transfer(from, to, amount) 事件
- to 不能是 0x0
- 返回 bool（成功 true）

只给代码，不要解释。

Level 2 · Context 工程 · 比 prompt 大一圈

2.1 原理 · prompt vs context 的区别

这是初学 AI 最容易混淆的概念。看动画一次说清：

2.2 Context 里到底装什么 · 真实场景的预算分配

光说 context “很大” 抽象。下面这个交互组件 · 用 200K tokens 的真实预算 · 看 4 种典型场景实际怎么填满：

💡 关键洞察 · 你的「user_message」在任何场景里都只占 0.1-1%。99% 的 context 是被 system / tools / history / RAG 这些别的东西吃掉的 —— 这就是为什么”我 prompt 写得很好但 AI 表现还是差”。Prompt 不是问题 · context 是。

2.3 为什么 · context 越长 · 性能反而越差

刚才 2.2 的「长 agent 跑爆」场景里看到模型性能塌方。这不是工程偷懒 · 是模型架构本身的物理限制。下面把学界共识 + 4 个底层原因讲清楚。

🔬 现象 · “Lost in the Middle” 效应

Liu et al. 2023（Stanford NLP · Percy Liang 组）做了一个经典实验：把同一段「正确答案」分别藏在 context 的开头 · 中段 · 末尾 · 测模型能不能找到。结果是反直觉的 U 形曲线：

🧠 4 个底层机制 · 为什么会发生

📊 最新发现 · advertised context ≠ effective context

2024-2025 的多个 benchmark 持续证实：标称 200K / 1M context 的模型 · 在复杂推理场景下实际可用范围远低于宣传。

💡 工程启示 · 这就是 context engineering 存在的全部理由

2.4 Context 工程的 4 个核心技术

2.5 实际应用 · Claude Code 怎么管 context

2.6 当 5 招都不够时 · 通向 RAG 的桥

把 2.5 的 5 招摆在一起看 · 它们各有专属的适用范围 · 也各有共同的盲点：

共同盲点 · 这 5 招处理的全是「已经在 context 里」的东西 · 或者「用户/agent 主动知道该读什么」的东西。

但真实业务场景里的知识 · 几乎都是反过来的 ——

这时候 5 招挨个失效：CLAUDE.md 装不下 · 用户不知道该 @ 谁 · subagent 不知道读哪个 · /compact 没东西可压 · MCP 缓存不管知识总量。

你需要的是「第 6 招」 —— 在用户问问题的那一刻 · 让系统自动从海量知识里搜出最相关的几小段 · 实时塞进 context。

💡 看清楚了 —— RAG 不是某种新机制 · 它继续做的还是 context 工程那件事 · 只是把”选什么进 context”从手工变成了向量搜索。理解了这一点 · 下面所有 RAG 技术细节都只是这个核心算法的工程实现。

Level 3 · RAG · 让 AI 动态查正确的知识

3.1 原理 · 看动画

带着刚才的揭示再看：当知识总量 > context 预算 · 用向量相似度搜索做查询时刻的自动 context 选择 —— 具体怎么做？看一遍：

3.2 RAG 的 4 个关键技术 · 实操层

3.3 真实问题 · 什么时候不该用 RAG

小数据（< 50 页） → 直接塞进 context · 别 RAG
低频访问（一次性查询） → 直接塞进 context
精确事实（数字 / 公式 / 引用） → 用 SQL 或 function call · 别 RAG
需要"全局推理" → RAG 切片会丢上下文 · 用 long-context 模型直接读

⚠️ RAG 不是万能的 —— 它适合”大语义库 · 模糊查询”的场景。其他场景往往更直接的方案更好。

三者协同 · 现代 AI app 的完整决策树

学完 module B/C/D · 你现在能区分何时用什么了 · 这是工程师才有的判断力：

💡 学完模块 D 你应该能 —— 1) 看到一个 AI 应用 · 一眼说出它用了 prompt 工程的哪几招 2) 看到一个聊久了变笨的 AI · 能猜出是 context 没管好 3) 给自己的产品做 AI 集成时 · 第一反应不是”调 OpenAI API” · 而是”我的 context 该怎么组装”。

模块 E · Multi-Agent 协作 · 让每个 agent 看少一点

承上启下 —— Module D 把 1 个 agent 的 context 工程讲透了：怎么压缩 · 怎么位置 · 怎么避开 U 曲线。但即便如此 · 单 agent 上下文总有上限 · 越复杂的任务越容易撞墙。怎么破？让 1 个 agent 变成多个 · 每个看少一点。这就是 multi-agent 协作。

1 · 单 agent 的天花板 · 为什么需要多个

回忆 Module D 的两个铁律：

破局思路 · 既然「context 满 → 性能差」是物理限制 · 那就让每个 agent 都只看自己那一小块·让总系统的智能由「多 agent 的协作」涌现出来。

一句话 · Multi-agent = context 工程从「单 agent 内」升级到「跨 agent 系统级」·所有 Module D 学的道理 · 在这里继续生效。

2 · 看动画 · 单 agent vs orchestrator-workers

下面这个动画把同一个任务 · 一边用单 agent · 一边拆给一个编排 + 4 个专精 worker · 视觉对比 context 占用和准确率 ——

3 · 5 种协作模式 · Anthropic 钦点

Anthropic 在 2024.12 的官方博客《Building effective agents》里把 multi-agent 系统拆成 5 种正交模式。它们是任何复杂 agent 系统的”乐高积木” —— 真实产品基本是这 5 种的组合：

step1 = llm("翻译: " + text)
step2 = llm("校对: " + step1)
step3 = llm("润色: " + step2)
return step3

💡 Workflow vs Agent 的关键区分 —— Anthropic 把上面 5 种分成两大类：workflow（路径固定 · 适合可预测任务 · 前 3 种）和 agent（LLM 动态决策 · 适合开放任务 · 后 2 种）。能用 workflow 别用 agent·workflow 更可控 · 更便宜 · 更可调试。

4 · 为什么这样表现更好 · 用 Module D 的工具逐条解释

Anthropic 自己的实测 · 数字会说话

5 · 主流框架 · 你能立刻上手的几个

6 · 案例研究 · Claude Code 的多 agent 协作

理论说得再多 · 不如看一个真实运行的系统。Claude Code 自己就是一个 multi-agent orchestrator · 而且把上面 5 种模式都用过。下面把它的协作方式完整解剖给你看 —— 这是你今天用的工具 · 不是抽象例子。

6.1 真实场景 · 一个开发任务的拆解

假设你给 Claude Code 发指令：“帮我加个 dark mode 切换到 settings 页”。它不会一口气把整个项目读完 + 一个 prompt 写完所有改动 —— 它会分工：

6.2 看动画 · Task tool 派出 subagent 的完整流程

下面这个动画把上面文字描述的 6 步全部演一遍 —— 包括最关键的 summary-only return 机制：

6.3 5 大设计哲学 · 工程细节

把动画里看到的设计选择 · 拆成 5 条可落地的原则：

6.4 配置示例 · 自定义你自己的 subagent

Claude Code 不只有内置 subagent · 你可以在 .claude/agents/<name>.md 里定义自己的。下面是一个典型配置：

---
name: security-auditor
description: 审查代码安全性 · OWASP top 10 + 业务逻辑漏洞
tools: [Read, Grep, Glob, WebFetch]  # 只读 · 不许改
model: opus                          # 需要深度推理
isolation: none                      # 不改文件 · 不需要 worktree
---

# 你的职责

你是一个 senior security engineer。审查给定的代码或 PR ·
找出可能的安全问题 · 但不要修复 · 只报告。

## 检查清单

1. SQL injection / NoSQL injection
2. XSS / CSRF / clickjacking
3. 鉴权 / 授权漏洞
4. 敏感信息泄露
5. 业务逻辑层面的滥用 (race · IDOR · ...)

## 输出格式

返回 JSON · 字段 = { severity, location, description, suggested_fix }

Task({
description: "Audit auth flow",
prompt: "审查 src/auth/ 里所有处理 token 的逻辑 · 重点看 race condition",
subagent_type: "security-auditor"
})

6.5 决策 · 什么时候 main 自己干 · 什么时候派 subagent

不是所有事都要派出去 —— 滥用 subagent 会拖慢任务、增加 token 成本。Claude Code 内部的经验法则：

💡 核心判断 · 「这块工作的中间过程 · main 需要看到吗？」需要 → 主 agent 自己干 · 不需要 → 派 subagent 让它自己消化·只把结论还回来。

7 · 决策树 · 什么时候才该上 multi-agent？

Anthropic 在 “Building effective agents” 的核心建议 ——

能不上就别上。先试单 LLM 调用 · 再试 workflow（前 3 种模式 · 路径固定） · 实在不行才上 agent / multi-agent。复杂度的代价是真金白银的延迟 · token · 调试痛苦。

8 · 资源 · 想深挖去哪

9 · 一句话总结模块 E

💡 学完 Module E 你应该能 —— 1) 看到任何复杂 AI 系统 · 能拆解成 5 种 Anthropic 模式之一 2) 知道 multi-agent 不是免费午餐 · 用之前先问”workflow 行不行” 3) 自己设计 AI 产品时 · 第一句话不再是”给一个 prompt” · 而是”我的 agent 怎么分工”。

模块 F · AI 时代的产品和工作

故事钩子 —— 4 个 MIT 应届毕业生（Michael Truell · Sualeh Asif · Arvid Lunnemark · Aman Sanger · 2022 届）做了 Cursor · 不和微软的 GitHub Copilot 比”AI 插件做得好” · 而是说：“我们要造 AI 长成的 IDE” · 短短几年 · 母公司 Anysphere 估值达到数百亿美元区间·史上增长最快开发工具之一。

当前 AI 世界全景 · 模型 + 产品

Cursor 只是众多 AI 时代产品之一。在开始想”你做什么”之前 · 先把全景看一遍 —— 哪些模型值得用 · 哪些产品已经做出来 · 你的想法在什么坐标里。

你的想法适合 AI 吗 · 4 特征自测

AI-first vs AI-bolted-on · 一个关键二分

AI 时代工作的 3 大转变

🎯 期末 · 你的 AI 时代行动表

概念自测 · 你都懂了吗

你的行动表

🎬 收尾 · 你建立了 AI 时代的全景认知

推荐资源 · 深挖故事