2026 年的今天，AI 已经足够聪明，你应该把它当个"人"来对待了——至少也是条聪明的"边牧"。

基础概念

Token（常被机翻为"令牌"，但这个译名并不好）：Token 是模型处理文本的最小单位。你可以粗略理解为"字词的碎片"——中文里一个汉字通常对应 1～2 个 Token，英文单词可能被拆成好几个。它是衡量输入输出长度、也是计费的基本单位。

一般调用 LLM 的链路：

1
用户 → App → LLM 服务

你平时用的 ChatGPT、Kimi、豆包，都是 App。App 负责把你的话打包成请求发给背后的 LLM 服务，再把 LLM 的回复展示给你。你并不是在直接和模型对话。

LLM 的运行过程

每一次请求，模型内部分为两个阶段：

1. Prefill（预填充）

模型读取并理解你发来的所有内容。这个阶段不会产生任何输出，你会看到界面上光标在转圈——不是卡了，而是模型在"想"。

这段等待时间叫 TTFT（Time To First Token），即"从发送到冒出第一个字"的耗时，通常 1～5 秒。

2. Decode（解码/生成）

模型开始逐字往外吐内容。每生成一个 Token 的间隔叫 TPOT（Time Per Output Token），通常 10～50 毫秒——所以你会看到文字是"打字机式"一个一个蹦出来的。

Thinking（思考）

部分模型（如 Claude、DeepSeek-R1）支持 thinking 模式。模型会先输出一段思考过程，再给出正式回答。对模型来说，thinking 的内容和普通输出没有区别，都属于 Decode 阶段；只是 App 在界面上把它折叠起来单独展示而已。

端到端时长（E2E Latency）

了解了两个阶段，一次完整请求的总耗时就很好算了：

1
2
总耗时 = TTFT + TPOT × 输出 Token 数
         （想的时间）  （写的时间）

举个例子，假设模型回复了 500 个 Token：

阶段 耗时 说明
TTFT 2s 模型读题、思考
Decode 50ms × 500 = 25s 逐字输出
合计 ≈ 27s 你从发送到看完完整回复的时间

所以你会发现：短回复的瓶颈在 Prefill（等第一个字慢），长回复的瓶颈在 Decode（写得慢）。

这也解释了一个日常体感——问 AI 一个简单问题，感觉"想了好久才开口，但一开口秒答完"；让它写一篇长文，第一个字来得还行，但要等很久才写完。

如果模型开启了 Thinking，thinking 的内容也是 Decode 输出的一部分，会实实在在地占用生成时间，E2E 会明显变长。这就是"深度思考"模式更慢的原因——不是因为用了更厉害的模型，而是它真的多写了一大段思考过程。

Cache（上下文缓存）

一个关键事实：每次你发消息，App 实际上把整个对话历史都发给了模型，而不是只发你最新这一条。

这意味着随着对话变长，每轮发送的 Token 数越来越大——第 1 轮发 100 token，第 2 轮发 300，第 3 轮发 600……总消耗是累加增长的，账单也会越来越贵。

缓存就是为了解决这个问题：服务端把之前已经处理过的上下文缓存下来，下一轮 Prefill 时跳过这些部分，既省时间，也省钱。这就是为什么很多平台对"缓存命中"的 Token 收费更低。

从 Prompt 工程到 Agent

Prompt Engineering（提示词工程）

输入给 LLM 的内容叫 Prompt。早期模型没那么聪明，想让 AI 按预期干活，需要反复调整措辞、格式、示例，这个过程就叫 Prompt Engineering。一度还催生了专门的岗位——Prompt 工程师。

Agent（智能体）

以前的模式是：你问 AI 怎么做 → AI 告诉你步骤 → 你自己动手。

Agent 的思路是：让 AI 自己想，自己动手。 做一个程序，自动问 AI"下一步做什么"，然后根据 AI 的回答自动执行操作——让电脑操作自己。

更进一步，你可以定义多个 Agent 各司其职——产品经理 Agent、程序员 Agent、架构师 Agent、测试 Agent——让它们协作完成任务。这就是所谓的 Multi-Agent，也是"AI 驱动公司"概念的雏形。

Tool Call（工具调用，以前叫 Function Call）

AI 的输出本质上是不确定的纯文本，但很多场景需要确定性的、结构化的操作。Tool Call 就是给 AI 提供一套"工具菜单"，让它在需要时按规定格式发起调用。

比如在 App 中定义一个工具：

1
2
3
4
5
{
  "tool": "查询天气",
  "输入": { "地点": "string" },
  "输出": { "气温": "number" }
}

当 AI 判断用户想知道天气时，它不会瞎编一个温度，而是输出：

1
{ "tool": "查询天气", "地点": "上海" }

注意：AI 只是表达"我认为现在该查天气了"，真正去调用天气接口的是 App。 AI 负责判断，App 负责执行。

MCP（Model Context Protocol，模型上下文协议）

Tool Call 有个前提：你得自己定义工具。但如果你不知道怎么查天气呢？天气服务商有 API 文档，但普通用户看不懂怎么办？

MCP 解决的就是这个问题：让服务商把工具打包好，放到一个标准化的 MCP Server 上；用户只需要添加这个 Server，就自动获得一系列可用的工具。

比如添加"彩云天气"的 MCP Server 后，你的 AI 就自动拥有了 5 个工具：

# 工具名 功能
1 get_realtime_weather 查询实时天气
2 get_hourly_forecast 查询逐小时预报
3 get_weekly_forecast 查询一周预报
4 get_historical_weather 查询历史天气
5 get_weather_alerts 查询天气预警

你不需要写任何代码，AI 也不需要额外的提示——工具自描述，即插即用。

一个真实的例子：Claude Code

说了这么多，Agent 到底长什么样？拿 Claude Code 举例——它是一个跑在终端里的代码 Agent。

假设你对它说：

“登录页面点击按钮后没反应，帮我修一下”

接下来发生的事情：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
┌─ 你（一句话描述任务）
│
│  ┌─ Claude Code 的循环 ──────────────────────────┐
│  │                                                │
│  │  1. 思考：登录相关代码在哪？                      │
│  │     ↓                                          │
│  │  2. 调用工具：搜索代码库，找到 login.tsx           │
│  │     ↓                                          │
│  │  3. 调用工具：读取 login.tsx 内容                 │
│  │     ↓                                          │
│  │  4. 思考：onClick 里调了接口但没 await，找到 bug   │
│  │     ↓                                          │
│  │  5. 调用工具：编辑 login.tsx，加上 await           │
│  │     ↓                                          │
│  │  6. 调用工具：运行 npm test                       │
│  │     ↓                                          │
│  │  7. 思考：测试全过了，任务完成                      │
│  │                                                │
│  └────────────────────────────────────────────────┘
│
└─ Claude Code：已修复，原因是 onClick 中缺少 await

整个过程的关键在于——你只说了一句话，剩下的全是 AI 自己在循环：

环节 谁在干活 在做什么
思考 LLM 判断下一步该做什么
调用工具 Claude Code（App） 根据 LLM 的判断去执行（读文件、改代码、跑命令）
观察结果 LLM 看工具返回了什么，决定是否继续

这就是 Agent 的核心模式：思考 → 行动 → 观察 → 再思考，不断循环直到任务完成。

你可能注意到了——这里面的"调用工具"就是前面说的 Tool Call。Claude Code 内置了一系列工具（搜索文件、读写代码、执行命令、访问网页等），LLM 在需要时自己决定调哪个。

所以 Agent 并不是什么新技术，而是 LLM + Tool Call + 循环 的组合。把"人问一次 AI 答一次"变成了"AI 自己问自己、自己干、干到完"。