LLM 推理与智能体：从一次请求到 Agent 循环

同一个模型，既可以是"你问我答"的聊天机器人，也可以是自己查工具、应对意外的智能体——差别不在权重，而在它周围的系统：模型服务怎么把一次请求变成 token、提示词怎么不训练地改变行为、工具调用怎么让模型决定"下一个看到什么"。本文导读耶鲁大学《机器学习导论》课程 "LLM Inference and Agents" 讲义，把这条主线逐段拆开，并衔接本站推理章节的实战文章。

1. 为什么需要 Agent：让模型决定自己看到什么

1.1 聊天机器人与智能体：同样的权重，两种布置

	Chatbot（指令模型）	Agent
数据流向	prompt → model → answer，用户写下一个 prompt	prompt → model → tool call → observation → 回到模型
谁决定下一步看什么	用户	模型（调用工具并读取结果）
应对意外	无法	可以：模型决定它接下来看到的数据

判断：两者的权重完全相同，区别只是"怎么摆"。智能体模式里模型可以决定下一步读什么数据，这正是它能从意外中恢复的原因——回答错了，它自己能看到工具返回、自己修正。

1.2 一个具体形态：OpenClaw

讲义用 OpenClaw 举例：WhatsApp / Telegram / Discord 等消息应用把指令送到用户机器上的 OpenClaw（一个模型 + 一个循环 + 已安装的技能），它能跑终端代码、读写搜索文件、收发邮件和消息，全部以用户自身的权限执行。

OpenClaw 把 LLM 后端连接到外部世界。架构参见 Bitdefender《Technical Advisory: OpenClaw Exploitation in Enterprise Networks, 2026》。

1.3 为什么企业都在做 Agent：数据飞轮

Anthropic 在 Claude Code 上的收入曲线是"为什么做 Agent"最直接的注脚（公司自家公告数据）：

时间节点	里程碑
2025-02	研究预览（research preview）
2025-05	全面可用（general availability）
2025-11	年化运行收入 $1B（2025-12-03 公告）
2026-02	年化运行收入超 $2.5B（2026-02-12 公告）

背后的机制是数据飞轮：在企业自有任务上部署 Agent → 它干活、每次运行留下痕迹 → 按任务是否成功给痕迹分级 → 用跑通的数据训练 → 再部署。每转一圈，下一个 Agent 在自家任务上就更强。这就是"企业全都做 Agent"的收益闭环。

1.4 Agent 由什么构成

按 Lilian Weng《LLM Powered Autonomous Agents》(2023) 的拆解，一个 Agent 大致是：served model（被服务的模型）+ tools + actions + chain of thought（本讲重点），外围还有 memory 与 planning（reflection / subgoals / self-critique）。

本节要点：Agent 不是新模型，而是"同一个模型 + 工具 + 循环 + 提示系统"的组装；模型权重全程固定，本文不涉及训练。

2. 模型服务：一次请求从进入到返回

2.1 服务形态：吞吐来自共享一次前向传播

很多用户、prompt 长度悬殊、一份权重副本跨多张 GPU 驻留内存且不变。服务器把到达的请求拼成一个 batch，整个 batch 一起穿过权重——吞吐来自共享一次前向传播。

2.2 一次请求里装的是什么：整个对话

一次请求 = 到目前为止的完整对话，按角色打标，外加解码设置：

{
  "messages": [
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "What is the weather in New Haven?"},
    {"role": "assistant", "tool_calls": [
      {"name": "get_weather", "arguments": {"city": "New Haven"}}
    ]},
    {"role": "tool", "name": "get_weather", "content": "41F, clear"},
    {"role": "user", "content": "Should I bring a jacket?"}
  ],
  "temperature": 0.2, "max_tokens": 300
}

• system：开发者的指令；user：已认证用户的请求；assistant：模型此前的输出；tool：程序返回的结果——工具结果就是一条普通消息；
• 四类角色最终都变成一条 token 串，格式本身并不强制 system 消息生效；
• 服务端在调用之间不保存任何状态："模型记得"是客户端的性质——客户端重发历史。

2.3 服务端的三步

1. 应用聊天模板：把消息列表展平成一条 token 串（字符串处理）；
2. Prefill + Decode：先预填整条串、再解码到停止 token（唯一跑网络的步骤）；
3. 解析：把生成的 token 恢复成一条消息（字符串处理）。

工程要点：第 2 步是成本所在，后面的大半内容都在讲它；第 1、3 步是纯字符串操作，但正是它们让模型变得像一个能用的聊天机器人。

2.4 聊天模板：角色是约定，不是网络的特性

聊天模板把 system/user/assistant 的对话扁平化，用特殊 token 标记轮次（如 <|im_start|> / <|im_end|>）：

<|im_start|>system
You are a course assistant.<|im_end|>
<|im_start|>user
How many meetings are left?<|im_end|>
<|im_start|>assistant
Nine.<|im_end|>
<|im_start|>user
What is meeting 25 about?<|im_end|>
<|im_start|>assistant

• 角色是模板约定，不是网络特性；服务器做扁平化，模型只看到右侧那条串；
• 后训练教会模型在结束标记处停止——服务器据此知道回复结束；
• 解码产出的 <|im_start|>assistant 41°F and clear.<|im_end|>，取标记之间的内容即得到 {"role": "assistant", "content": "41°F and clear."}——格式本身承载消息。

3. Prefill 与 Decode：同一个权重，两种算账方式

• Prefill（预填充）：整个 prompt 一次前向，所有 token 位置并行处理。因果掩码（本站 分布式训练 有讲）让所有位置同时计算，长 prompt 就是一次宽矩阵乘法；每个位置都会算出下一个 token 的分布，但只有最后位置的分布被用作解码起点；
• Decode（解码）：逐 token 生成，每个 token 需要一次完整前向，且必须等前一个 token 选完，无法并行。

成本口径：2000 token 的 prompt = 1 次前向；500 token 的回答 = 500 次前向。用户等的是输出长度。

工程要点：两阶段共享权重、跑法完全不同，对硬件的压力差异很大（prefill 是计算密集的宽矩阵乘，decode 是访存密集的逐 token 前向），大规模部署因此会把 prefill 和 decode 拆到不同机器——检索 "PD disaggregation"（Prefill/Decode 分离）。

4. 高效服务的三大件：KV Cache、Paged Attention、Continuous Batching

Decode 是花钱的大头，几乎全部实际收益来自下面三个系统级思路——它们改变服务成本，不改变输出分布（来源：Kwon et al. 2023, vLLM, arXiv:2309.06180）。

4.1 KV Cache：把"算过的"存下来

注意力在位置 t 用查询 $q_t$ 对比前面每个位置的键、并加权平均其值：

$$\text{Attn}(q_t) = \sum_{s \le t} \alpha_{ts}\, v_s, \qquad \alpha_{ts} \propto \exp\{q_t^\top k_s / \sqrt{d}\}$$

$(k_s, v_s)$ 不依赖 $t$：算一次、之后每一步读回——这就是 KV Cache。

• 内存口径：$2 \times (\text{layers}) \times (\text{width}) \times (\text{bytes}) = 128\ \text{KiB/token}$；
• 以 Llama-3 8B 为例：一次 8k token 对话的缓存 ≈ 1 GiB，对比权重 16 GiB——缓存才是限制同时容纳多少用户的关键；
• 它省什么：无缓存时每个 decode 步都要重算整个上下文的 K/V；有缓存后每步只新增一对，单步成本不再随对话变长而增长。

4.2 Paged Attention：虚拟内存式的显存分配

静态分配的问题是：每个请求按最大长度（如 2048 token）预留一整段连续显存，而典型回复只有几百 token——大部分预留从未写入，且因为是连续的、空出来的部分也无法给别人用。

PagedAttention 改为非连续分配：每个请求仍然"看到"一个连续缓存，但**块表（block table）**把它的块映射到共享固定大小槽位池中的任意位置——和虚拟内存同一套间接寻址，随用随占，不按永远不会达到的长度预留。

4.3 Continuous Batching：请求做完就腾位

Decode 每步要读一遍全部权重才能产出一个 token，单个请求会浪费几乎整次读取——所以把多个请求凑成 batch 锁步前进：每个步一次前向、批内每个请求各得一个新 token。

静态批处理在开始时固定成员，请求在不同步数结束、多数槽位空转；连续批处理让完成的请求退出、等待的请求立刻补位。

4.4 三者关系

技术	解决的问题	效果
KV Cache	decode 每步重算整个上下文	步成本不随上下文增长
Paged Attention	静态预留浪费、碎片不可复用	显存利用率接近实际用量
Continuous Batching	批成员固定、槽位空转	吞吐接近满批次

5. 采样：为什么不要长尾

模型下一个 token 的分布是重尾的：头部是少数合理的延续，尾部是数万个各带一点概率质量的 token（示例中合计约 30% 的质量）。忠实采样会时不时抽到尾部，模型随后基于抽中的内容继续生成——后面的句子从"它自己绝不会写"的地方长出来。

工程上因此引入截断采样：

• top-k：保留概率最高的 k 个 token，然后重新归一化（k=5 → 保留 5 个）；
• top-p：保留累计概率达到 p 的最小集合，然后重新归一化（p=0.90 → 保留 25 个）；
• temperature：先对 logits 做缩放再采样——固定数量（top-k）与固定质量（top-p）给出的集合可以不一样，二者需要配合校准。

判断：对话/生成默认 top-p（p≈0.9）+ temperature（T≈0.7-1.0）；需要确定性的场景用贪心。成本上，采样策略本身几乎不加计算，真正影响成本的是输出长度与"多次采样取优"（= 推理算力翻倍）。详见本站 输出采样账。

6. 提示工程：不训练地改变行为

权重固定、请求是一条 token 串——应用能控制的一切，都在这条字符串里。本讲进入的是思维链（chain of thought）盒子：模型在作答之前写下的文本。

讲义的原话："Prompting is an art." 同样的权重，因请求的措辞不同而答得好或答得差；从业者会收集"恰好有效"的短语——"take a deep breath"、"let's solve this step by step"、"you are an expert"——并反复替换试错。

工程要点：提示词是产品的一部分，值得像代码一样版本化、沉淀、A/B；这不改变权重，但直接决定线上回答质量（衔接 LLM 服务 SRE）。

7. 工程启示与交付清单

1. 判断要不要做成 Agent：先问是否需要"模型在循环里读取外部结果"、是否接受模型决定下一步看什么。Agent 的价值 = 能从意外恢复；成本 = 循环里多次服务调用、更长的端到端延迟；
2. 服务端无状态是铁律：历史与工具结果必须由客户端重发；工具结果就是一条普通消息，格式天然支持；
3. 吞吐来自共享前向：同一份权重、batch 越满越省；上线前先按 128 KiB/token 量级算 KV Cache 预算，再谈并发上限（详见 KV 缓存压缩账）；
4. 显存优化顺序：KV Cache（必做）→ 换 PagedAttention / Continuous Batching 的服务框架（如 vLLM）→ 采样参数校准；
5. 关注 prefill/decode 的硬件错配：高并发或超长 prompt 场景考虑 PD 分离；TTFT 与吞吐分别由 prefill 和 decode 主导（推理基准方法）；
6. 提示词产品化：沉淀有效短语、版本化、A/B 上线，和模型服务一起纳入 SRE 治理。

8. 阅读链与来源

• 延伸阅读：vLLM 原理解析 · KV 缓存压缩账 · 输出采样账 · 长上下文推理 · vLLM 生产化部署 · LLM 服务 SRE · 科学智能体部署
• 本文依据：耶鲁大学《机器学习导论》（Introduction to Machine Learning）课程讲义 "LLM Inference and Agents"（经微信公众号"论智谈芯"于 2026-11-01 整理转发）；Agent 架构图参考 Lilian Weng《LLM Powered Autonomous Agents》(2023, lilianweng.github.io)；PagedAttention 与 Continuous Batching 源自 Kwon et al. (2023)《Efficient Memory Management for Large Language Model Serving with PagedAttention》, arXiv:2309.06180；Anthropic 收入数据来自其 2025-12-03 与 2026-02-12 官方公告。本文为学习笔记式整理，无第一手实验数据，公式与数字均转述自上述来源，具体版本与实测以现场为准。

---

本文为本站整理耶鲁大学公开讲义要点后撰写，用于知识库学习交流；公式与算例为讲义内容转述，具体版本与实测数据以现场为准。