你给 Claude 发一条消息。几秒后，回复出现了 —— 有时是纯文本，有时是结构化 JSON，有时是一次调用工具（跑代码、搜网页）的请求。中间到底发生了什么？
大部分"LLM 是如何工作的"文章一上来就讲 transformer 论文，读完你只会更糊涂。本文换个思路：一张图，五层结构，跟着一条 prompt 走完从你按下 Enter 到响应流回来的完整路径。如果 Claude 中途调了工具，我们也跟着这个循环走一圈。
打开 How Claude Works 完整示意图 一起看，本文按顺序讲每个 frame。
30 秒版
Claude 的运行时本质上是一个四阶段循环：
- 输入组装 —— 模型能"看到"的所有内容打包成一个 prompt
- 推理管道 —— 模型把这个 prompt 转成下一个 token 的概率分布
- 响应 —— token 流式产出，可能是文本、可能是结构化输出（工具调用、thinking 块）
- 代理循环 —— 如果响应里有工具调用，外层运行时执行工具，把结果再喂回步骤 1
其他一切 —— 具体的 transformer 架构、扩展思考、MCP 集成 —— 都是这四个阶段里的某个细节。只要把这四阶段的循环记在脑子里，几乎任何 Claude 的行为你都能推理出来。
Frame 1 —— 输入组装（模型真正看到的东西）
首先要搞清楚：Claude 并不是孤立地"看到"你这条消息。每次请求都会把六个来源的信息组装成一个 prompt：
- 系统提示词 —— 开发者或 Anthropic 设置的指令（角色、安全规则、回复格式）
- 用户消息 —— 你刚才输入的那条
- 历史对话 —— 当前的多轮对话（受上下文窗口大小限制）
- 附件 —— 你上传的文件或图片（通过视觉编码器转成 token）
- 工具定义 —— 允许模型调用的每个工具的 JSON schema
- MCP 资源 —— 通过 Model Context Protocol 从外部拉进来的上下文/提示词
这些全部在其他一切之前拼接成一个 token 序列。这就是"上下文窗口"里的"上下文" —— 不只是对话历史，而是整个组装好的 prompt。
实用推论：如果响应感觉不对劲，问题往往在 Frame 1。系统提示词过于简略、对话历史膨胀、工具 schema 太大，都在消耗同一个上下文窗口，影响模型的注意力分布。
Frame 2 —— 推理管道（模型内部）
输入组装好后，接下来五步严格顺次执行：
1. Tokenizer（分词）。 组装好的 prompt 被切成 token（英文大约 4 个字符一个 token，中日韩每个字符各占一个 token）。后面的所有环节操作的都是 token id，不是字符。
2. 上下文汇编。 Token 拼成一个序列，用特殊 token 标记角色边界（system、user、assistant）。
3. Transformer 层。 模型的核心。每层做一次 attention（每个 token 关注其他所有 token）加一次前馈网络，重复 N 次。所谓"理解"发生在这里 —— 虽然没人会真把 attention weights 叫做"理解"。
4. 扩展思考（可选）。 Claude 4 及之后的版本，模型可以在给出可见回答之前多花一些 token 做内部推理。包裹在 <thinking> 块里，API 可以选择展示或隐藏。这就是"快速答一下"和"想清楚再答"的区别。
5. 采样与解码。 最后一层输出下一个 token 的概率分布。采样参数（temperature、top-p、结构化输出约束）把这个分布转成一个具体要发出去的 token。
第 2–5 步是自回归重复的：发出一个 token → 塞回序列 → 采样下一个，直到模型产出停止信号。
Frame 3 —— 响应（吐出什么）
输出流不只是"文本"，它是一个结构化序列，含四种可能的成分：
- 流式文本 token —— 可见的响应，一个 token 一个 token 流出来
- Thinking 块 —— 扩展思考的内容，可以选择性展示给终端用户
- 工具调用（JSON） —— 一个结构化请求，带具体参数调用某个工具
- 停止原因 —— 模型为什么停下：
end_turn（做完了）、tool_use（在等工具结果）、max_tokens（token 预算用完了）
停止原因是这一步里操作层面最重要的字段。end_turn 表示响应完成；tool_use 表示运行时需要先执行工具再继续。"代理行为"的一切都取决于这个信号。
Frame 4 —— 代理循环（外层运行时）
当响应里出现 tool_use 停止原因时，控制流离开模型，进入代理循环。这是 Claude 从"文本生成器"变成"agent"的那一层。
循环有三个具体步骤：
- 决策 —— 实际上模型已经通过 emit 一个 tool call 做完这个决策了，运行时只是把它读出来。
- 执行 —— 调用工具。工具分三类：
- 内置工具（比如 web search、code execution）—— Anthropic 提供
- 用户自定义工具 —— 开发者注册的任意函数
- MCP 工具 —— 通过 Model Context Protocol 暴露能力的外部服务器。CodePic 就是其中之一 —— 让 Claude 通过调 MCP 工具来创建和编辑手绘风格的图。
- 把结果送回去 —— 工具的输出被 encode 成
tool_result消息，附加到对话历史。这就是图中"作为下一轮 turn"那条箭头的含义：结果变成一次新的用户 turn，整个循环从 Frame 1 重来。
循环在响应带 end_turn 而不是 tool_use 时终止。实际中可能是 1 次迭代（简单查询）、5 次（研究任务）、或 50+ 次（长时间运行的 agent 任务）。
为什么这个 frame 重要：你听说过的每个"agent 框架" —— LangChain、Anthropic 自己的 Agents SDK、内部自研的 harness —— 本质上都是 Frame 4 的一个具体实现。它们的区别在于如何管理循环（并行工具调用、重试逻辑、子 agent 编排），但核心形状是一样的。
Frame 5 —— 训练管道（背景，不是运行时）
上面四个 frame 描述的是每次你发消息时发生的事。但模型本身是另一条一次性（近似一次性）管道的产物：
- 预训练 —— 喂给模型海量文本，训练它预测下一个 token
- 监督微调（SFT） —— 给它人类写的"给定指令的好回答"样例
- Constitutional AI（RLAIF） —— Anthropic 版本的 RLHF，用一份写好的"宪法"引导 AI 反馈，塑造安全/有帮助的行为
- 红队测试 —— 对抗性测试找 bug、修 bug
- 部署 —— 训练好的模型通过 API、Claude.ai、Claude Desktop 提供服务
发消息时这些都不跑。训练管道决定了 Frame 2 的模型为什么这样表现，但请求时它是冻结的。所以图里 Frame 5 是灰色的、放在底部 —— 是背景，不是运行时循环的一部分。
MCP 在图中的位置（以及它为什么重要）
MCP 在图里出现两次：一次是作为输入源（Frame 1 —— 从 MCP 服务器拉资源和提示词进上下文），一次是作为工具类型（Frame 4 —— 代理循环中调用 MCP 工具）。
这种双重身份就是 MCP 的意义。传统工具调用要求开发者手写模型能调的每个工具。MCP 让工具在运行时被发现 —— 模型不需要重新训练就能获得新能力。让 Claude 客户端指向一个新的 MCP 服务器，它的工具立刻可用。
举个具体例子：CodePic 暴露了一个 MCP 服务器，让 Claude 通过调 create_diagram 或 create_from_template 来创建图。从 Claude 的角度看，这些跟其他任何工具调用一模一样。从用户角度看，"给我画个项目的思维导图"就变成了浏览器里一张真正可编辑的图 —— 因为 MCP 打通了两个系统。
再说一次扩展思考
扩展思考（Frame 2 里那个虚线框）值得单独提一下，因为它改变了响应的形状。启用后：
- 模型会在可见回答之前产出一段
<thinking>...</thinking>块 - 这个块可以任意长 —— 模型本质上在内部"出声"推理
- API 可以选择向客户端展示或隐藏这些块
- 扩展思考也算 token 预算，所以是拿成本/延迟换质量
用于难推理任务（数学、复杂多步规划）时开启。简单查询就跳过，多的 token 纯属浪费。
沿一个方向读这张图
推荐的How Claude Works 图阅读顺序：
- 沿实心箭头走 Frame 1 → 2 → 3
- 如果响应里有
tool_use，跟着虚线箭头进 Frame 4 - 走 Frame 4 里的内部箭头：决策 → 工具执行 → 结果节点
- 跟着**"作为下一轮 turn"的虚线**回到 Frame 2
- 循环，直到落到一个带
end_turn的响应 - Frame 5 在底部作为背景 —— 说明模型能力的来源，不参与请求时的流程
这就是整个运行时。任何具体的行为 —— 快速的一次性回答、20 次工具调用的长 agent 会话、图片输入请求、MCP 驱动的工作流 —— 都是在同一个形状上走一条具体路径而已。
上手试试
How Claude Works 图是一个可编辑的模板。打开它，用你跟 Claude 的某次具体交互，追踪它经过了哪些 frame。理解一次这个形状，未来所有"Claude 为什么会这么做？"的问题都会好答很多。
如果你在用 Claude 做开发 —— 通过 API、Claude Code、或 MCP —— 这张图值得钉在手边。看得清楚是哪个 frame 出问题，调试速度会快很多。
