🔬 深度原理 · 2025-2026 最新概念
理解 Agent 的
第一性原理
不是教你调 API，而是拆解 Agent 为什么能工作。从注意力机制的数学推导，到 Context Engineering、Harness Engineering、12 Factor Agents——覆盖 2025-2026 年全部前沿概念。
10
原理章节
10+
前沿术语
20+
数学公式
3
知识层次
CHAPTER 01 · 基石
语言模型的数学本质
要理解 Agent，首先要理解它的"大脑"——语言模型。这不是魔法，而是一个极其庞大的概率函数。本节从数学角度拆解它到底是什么。
核心定义：下一个 token 的概率
语言模型的数学定义极其简洁——给定前面的 tokens（词元），预测下一个 token 的概率分布：
语言模型的基本定义
P(x₁, x₂, ..., xₙ) = ∏ᵢ₌₁ⁿ P(xᵢ | x₁, ..., xᵢ₋₁)
这叫自回归分解（Autoregressive Factorization）。一个句子"今天天气真好"的概率，被分解为：
P(今天) × P(天气|今天) × P(真|今天天气) × P(好|今天天气真)
语言模型的全部能力，都来自学习这个条件概率分布 P(xᵢ | context)。所谓的"生成"，就是从分布中采样。
💡 关键洞见
LLM 不"理解"语言——它计算的是概率。但由于训练数据包含人类所有的知识、推理、逻辑，学到的概率分布恰好编码了人类思维的统计规律。概率足够精确时，看起来就像在思考。
训练：最大似然估计
模型怎么学习这些概率？答案是最大似然估计（MLE）——让训练数据出现的概率最大化。等价地，最小化交叉熵损失：
训练目标：最小化交叉熵损失
L = -∑ᵢ log P(xᵢ | x₁, ..., xᵢ₋₁; θ)
这里 θ 是模型的参数（GPT-4 约有 1.8 万亿个参数）。训练就是找到一组参数 θ*，让训练文本中每个词的预测概率尽可能高。优化方法是梯度下降：
θ ← θ - η · ∂L/∂θ
η = 学习率，每步沿损失下降最快的方向更新参数
生成的本质：从概率分布中采样
生成文本时，模型每步输出一个概率分布（词表中每个词的概率），然后从中选一个 token。循环这个过程直到结束：
生成过程：
输入: [今, 天, 天, 气] → 模型前向传播
↓
输出 logits → softmax → 概率分布
真(0.85) 好(0.78) 差(0.03) 棒(0.65) ...
↓
按温度采样 → 选 "真"
↓
输入: [今, 天, 天, 气, 真] → 重复...
→ "生成" = 反复执行"预测→采样→追加"循环
温度参数 T 的数学意义
P(tokenᵢ) = exp(logitᵢ / T) / ∑ⱼ exp(logitⱼ / T)
温度对概率分布的影响：
T → 0 : argmax，总是选最高概率 → 确定性、保守、适合代码
T = 1 : 原始概率分布 → 平衡
T → ∞ : 均匀分布 → 完全随机 → 发散
│██▁▁▁ │▆▄▃▂▁ │▃▃▃▃▃
│██▁▁▁ T=0.1 │▆▄▃▂▁ T=1.0 │▃▃▃▃▃ T=3.0
│██▁▁▁ 尖锐 │▆▄▃▂▁ 平衡 │▃▃▃▃▃ 平坦
└──────── └──────── └────────
⚠️ 关键区分
语言模型是确定性的函数：相同输入 + 相同参数 + 相同随机种子 → 相同输出。"随机性"只来自采样步骤的 temperature 控制。Agent 的"创造力"本质上是概率采样。
为什么模型大了就"聪明"了？
参数从 1 亿（GPT-2）增长到 1.8 万亿（GPT-4），能力发生了质的飞跃。这背后的原理是标度律（Scaling Laws）：
Kaplan 标度律 (2020)
L(N) ∝ N^(-0.076)
损失 L 随参数量 N 的幂律下降
损失 L 随参数量 N 的幂律下降
损失越低，模型对下一个 token 的预测越精确。当精确度跨过某个阈值，模型开始展现出训练数据中隐含的推理能力——这就是"涌现"（Emergence）。
涌现曲线（示意）：
能力
│ ╱──────── ← 推理、代码
│ ╱
│ ╱
│ ╱╱ ← 翻译、摘要
│ ╱╱╱╱
│ ╱╱╱╱╱ ← 语法、流畅性
│╱╱╱╱╱
└──────────────────────────────── 参数量
10⁸ 10⁹ 10¹⁰ 10¹¹ 10¹²
→ 不是线性提升，而是到达阈值后"突然"获得新能力
→ 这就是为什么小模型做不到 Agent 级别推理
CHAPTER 02 · 基石
注意力机制：Transformer 的心脏
上一章我们知道了模型在学什么（条件概率），但没说它怎么学。这需要理解 Transformer 的核心——自注意力机制（Self-Attention）。它是 Agent 一切能力的底层结构。
核心问题：词与词之间的关系怎么编码？
考虑句子："银行利率太低了，换一家银行吧。" 两个"银行"含义相同，但在不同语境中词义可能完全不同（河岸 vs 金融银行）。注意力机制让每个词"看到"句子中所有其他词，根据相关性加权聚合信息。
Q、K、V：查询、键、值
每个 token 被投影为三个向量：
| 向量 | 类比 | 数学含义 |
|---|---|---|
| Query (Q) | "我在找什么" | 当前 token 想获取什么信息 |
| Key (K) | "我有什么" | 当前 token 能提供什么信息 |
| Value (V) | "我的实际内容" | 如果被选中，传递的信息 |
注意力计算公式
缩放点积注意力 (Scaled Dot-Product Attention)
Attention(Q, K, V) = softmax(Q·Kᵀ / √dₖ) · V
逐步拆解这个公式的每一层含义：
注意力计算的四步：
步骤 1: Q·Kᵀ — 点积计算"关注度分数"
每个 token 对所有 token（包括自己）的相关性
scores[i][j] = 第 i 个 token 对第 j 个 token 的关注程度
步骤 2: /√dₖ — 缩放
点积随维度增大而增大，不缩放会让 softmax 趋向 one-hot
√dₖ 是一个"温度调节器"，保持梯度稳定
步骤 3: softmax — 归一化为概率分布
每行求 exp 后归一化，使所有关注度之和 = 1
attn[i][j] = P(第 i 个 token 关注第 j 个 token)
步骤 4: · V — 加权聚合
每个 token 的新表示 = 所有 token 的 Value 的加权和
关注度越高的 token，其 Value 贡献越大
结果: 每个 token 的表示融合了整个句子的信息
融合的比例由注意力权重决定
具体例子：理解"苹果"在不同上下文中的含义：
句子 A: "我吃了一个苹果"
苹果[吃] 通过 Q 匹配到 "吃" 的 K → 注意力高 → 聚合"吃"的语义
→ 最终表示偏向"水果"语义
句子 B: "苹果发布了新手机"
苹果[发布] 通过 Q 匹配到 "发布" 的 K → 注意力高 → 聚合"发布"的语义
→ 最终表示偏向"公司"语义
→ 同一个词在不同上下文中获得不同的向量表示
→ 这就是"理解上下文"的数学本质
多头注意力：从不同角度观察
一个 attention head 只能学到一种关系模式。Transformer 使用多个头并行，每个头学习不同维度的关系：
Head 1
可能学到了语法关系（主谓宾）
Head 2
可能学到了指代关系（"他"指谁）
Head 3
可能学到了语义关系（同义/反义）
Head 4
可能学到了数值/量级关系
GPT-4 有 96 个注意力层，每层 96 个头，总计约 9216 个注意力头并行工作。每个头关注不同维度的信息，最终拼接形成每个 token 的丰富表示。
Causal Masking：为什么 Agent 能"自回归"生成
在注意力计算中加一个因果掩码（Causal Mask）——下三角矩阵，让每个位置只能看到它之前的 token，不能"偷看"未来：
注意力掩码（1=可见, 0=遮蔽）:
Position: 1 2 3 4 5
Token 1 → [ 1 0 0 0 0 ] 只能看到自己
Token 2 → [ 1 1 0 0 0 ] 能看到 1, 2
Token 3 → [ 1 1 1 0 0 ] 能看到 1, 2, 3
Token 4 → [ 1 1 1 1 0 ]
Token 5 → [ 1 1 1 1 1 ] 能看到所有
→ 这就是 GPT（Generative Pre-trained Transformer）
→ 自回归生成的底层保证：只能根据过去预测未来
💡 为什么这解释了 Agent 的能力
注意力机制让模型对每个词的理解依赖于整个上下文。这意味着当你在提示词中提供工具描述、示例、规则时，模型在计算每个输出 token 的概率时，都"注意到了"这些约束。提示词工程本质上是在操控注意力分布。
CHAPTER 03 · 基石
Token 与概率分布
LLM 不处理文字，它处理的是数字。理解 token 化和概率分布的形状，是理解 Agent 行为（如为什么会产生幻觉、为什么需要精确提示）的关键。
Token 化：文本如何变成数字
文本被切分为 token（通常是子词），每个 token 映射为一个整数 ID。GPT-4 的词表约 10 万个 token：
文本 → Token → ID 的过程
"你好，世界！Hello World!"
切分: [你] [好] [，] [世] [界] [!] [Hello] [ World] [!]
ID: 5765 1039 11 6805 4917 0 15496 2159 0
关键: 一个中文字 ≈ 1-2 tokens
一个英文单词 ≈ 1-3 tokens
1 万亿训练数据 ≈ 约 7500 亿 token
⚠️ Token 边界影响 Agent 行为
Token 化方式直接影响模型的理解。比如 "2+2" 可能是 3 个 token，但 "12345678" 可能被切分为 ["123", "45", "678"]，模型看到的不是完整数字！这解释了为什么 LLM 在大数运算上容易出错——它感知到的不是你输入的数字。
Logits：概率分布的原始形态
模型对每个位置输出一个 vocab_size 维的向量（logits），表示每个 token 作为下一个输出的"分数"。通过 softmax 转换为概率：
Softmax 将 logits 转为概率分布
P(tokenᵢ) = exp(logitᵢ / T) / ∑ⱼ exp(logitⱼ / T)
Top-k 与 Top-p：截断采样
词表有 10 万个 token，但大部分概率极低。采样时只从高概率候选中选：
采样策略对比：
原始分布: Top-k=5: 只留最高5个
┌─────────────────┐ ┌─────────────────┐
│▇▅▃▂▁▁▁▁▁▁▁▁▁... │ → │▇▅▃▂▂ │ 截断尾部噪声
└─────────────────┘ └─────────────────┘
Top-p=0.9: 累积概率达90%的最小集合
┌─────────────────┐
│▇▅▃▂▁ │ 动态数量：分布尖锐时少选，平坦时多选
└─────────────────┘
→ Top-k 固定数量，Top-p 固定概率质量
→ Agent 通常用 Top-p=0.9~1.0 + 温度 0~0.7
幻觉的数学解释
为什么 Agent 会"一本正经地胡说八道"？因为模型总是从概率分布中输出——它不会说"我不知道"，除非"我不知道"恰好是概率最高的 token。
幻觉的概率本质
P(错误答案) > 0 在任何情况下都成立
P(错误答案 | 知识不足时) 可能很高
因为训练数据中类似模式导致高分 → 采样到错误 token
P(错误答案 | 知识不足时) 可能很高
因为训练数据中类似模式导致高分 → 采样到错误 token
💡 减少幻觉的原理
提供精确的上下文（文档、约束、示例），能改变注意力的分布，使正确答案的概率提升。这就是 RAG（检索增强生成）的本质——不是给模型"知识"，而是通过上下文调整概率分布，让正确 token 的概率高于幻觉 token。
CHAPTER 04 · 推理
涌现与推理
这是最核心的问题。一个只学了"预测下一个 token"的模型，为什么能做数学题、写代码、做逻辑推理？本章从表征学习和组合泛化的角度回答这个问题。
推理 = 学到的隐含计算结构
训练数据中包含大量推理模式的文本（数学证明、代码逻辑、论证过程）。模型学习这些文本的概率分布时，被迫学到了推理的结构：
训练数据中的推理链：
"因为 A，所以 B。又因为 B，所以 C。因此 A→C。"
模型学习到的概率模式：
P("所以" | "因为...") → 很高（学到了因果关联词模式）
P("B" | "因为 A, 所以") → 取决于 A 和 B 在训练中的共现频率
P("C" | "因为 A→B, 又因为 B") → 学到了传递性推理的模式
→ 模型不是在"推理"，而是在"复现推理的语言模式"
→ 但当模式足够精确时，输出与真正的推理不可区分
Chain-of-Thought 的数学基础
CoT（思维链）是 Agent 推理的关键技术。它的原理可以用计算复杂度来解释：
直接回答 vs CoT 的计算深度
直接回答: P(答案 | 问题)
CoT: P(步骤₁ | 问题) × P(步骤₂ | 问题,步骤₁) × ... × P(答案 | 全部步骤)
CoT: P(步骤₁ | 问题) × P(步骤₂ | 问题,步骤₁) × ... × P(答案 | 全部步骤)
直接生成答案时，模型只有一次前向传播的计算量来得到答案。而 CoT 把推理过程展开为多个 token 序列，每个 token 都经过完整的注意力计算——等于增加了计算深度。
CoT 的计算本质：
直接回答（计算深度 = 1）:
问题 ──[1次前向传播]──→ 答案
↑ 模型必须在一步内完成所有推理 → 复杂问题容易出错
CoT（计算深度 = N）:
问题 → 步骤₁ → 步骤₂ → ... → 步骤ₙ → 答案
↑ 每步都是一次独立的前向传播
↑ 每步有独立的注意力计算来"验证"上一步
↑ 等效于增加了 N 层"推理深度"
类比 CPU: 更多时钟周期 = 能执行更复杂的计算
→ CoT 将 O(1) 深度的计算 → O(n) 深度
💡 CoT 的有效条件
研究表明（Wei et al. 2022），CoT 只在参数量 > ~60B 的模型上显著有效。小模型即使被要求"一步步思考"，输出也是浅薄的。这说明 CoT 不是"技巧"，而是解锁了大模型已学到但未被直接激活的推理能力。
In-Context Learning：为什么给几个例子就会了
给 LLM 几个输入-输出示例，它就能模仿这种模式处理新的输入。这就是上下文学习（ICL）。它的原理与注意力机制密切相关：
In-Context Learning 的注意力解释
对于新输入 x_new:
attention(x_new, examples) → 提取模式 → 生成对应的 y_new
attention(x_new, examples) → 提取模式 → 生成对应的 y_new
示例在上下文中起到了锚点作用。新输入通过注意力机制"检索"最相似的示例，然后模型按照这个示例的映射关系生成输出。这类似于一个"单层的前向推理"。
推理的边界：什么做不了
- 需要精确搜索的问题：NP-hard 问题（如复杂组合优化），概率采样无法替代系统搜索
- 需要长链条精确推理：每步推理都有误差，误差累积导致长链推理失败率高
- 超出训练分布的问题：模型只能"复现"见过的模式，全新的推理类型能力有限
- 需要符号操作的问题：精确的数学证明、形式逻辑推演（需要外部工具辅助）
CHAPTER 05 · 现代 Agent 工程
Context Engineering
2025 年最重要的认知转变：Prompt Engineering 已死，Context Engineering 当立。这不是改名，而是对 Agent 工程的重新定义。
定义
权威定义 (Harrison Chase, LangChain, 2025-06)
Context Engineering 是构建动态系统，以正确的格式在正确的时机提供正确的信息和工具，使 LLM 能够合理地完成任务。
Prompt Engineering → Context Engineering 的范式转移
Prompt Engineering（旧范式）:
┌────────────────────────────────────────┐
│ 核心信念：措辞决定一切 │
│ 方法：反复调试一段静态 prompt 的措辞 │
│ 适用：单轮 LLM 调用 │
└────────────────────────────────────────┘
Context Engineering（新范式）:
┌────────────────────────────────────────┐
│ 核心信念：LLM 的表现取决于进入上下文的 │
│ 所有信息 │
│ 方法：构建动态系统，管理多来源上下文 │
│ 适用：多步、多工具的 Agent 系统 │
└────────────────────────────────────────┘
关系: Prompt Engineering ⊂ Context Engineering
措辞优化仍是子集，但不再是全部
上下文的六大来源
Agent 每次调用 LLM 时，上下文不是单一的 prompt，而是六个来源的动态汇聚：
| 来源 | 由谁提供 | 内容 | 动态性 |
|---|---|---|---|
| System Instructions | 开发者 | 角色设定、行为规则、约束 | 静态/半静态 |
| User Input | 用户 | 任务描述、问题 | 每次不同 |
| Tool Definitions | 开发者 | 可用工具的 schema 和描述 | 动态选择 |
| Short-term Memory | 系统 | 当前会话的对话历史 | 持续增长 |
| Retrieved Context | RAG 系统 | 从向量库/数据库检索的相关文档 | 按需检索 |
| Long-term Memory | 记忆系统 | 用户偏好、过往交互摘要 | 渐进积累 |
Context Engineering 的核心挑战是：在有限的上下文窗口中，从这六个来源中选择、格式化、组装最优的信息组合。
"能不能合理地完成任务？" —— 核心检验标准
Context Engineering 的定义中有一个关键的检验问题：Given this context, can the LLM plausibly accomplish the task?
Agent 失败的两种原因：
原因 A: 模型能力不足
→ 即使上下文完美，模型也做不到
→ 解法: 换更强的模型 / 微调
原因 B: 上下文不足 ← 更常见！
→ 模型有能力，但你没给它足够的信息
→ 解法: Context Engineering
判断方法:
"如果把这个上下文交给一个人类专家，他能做到吗？"
不能 → 问题在上下文（原因 B）
能但 LLM 做不到 → 问题在模型（原因 A）
⚠️ 为什么模型变好了，Agent 还是不行
随着 GPT-4o、Claude Sonnet 4 等模型能力飞跃，原因 A（模型不足）越来越少。大部分 Agent 失败是原因 B——上下文工程没做好。这就是为什么 2025 年行业共识是：Context Engineering 是 AI 工程师最重要的技能。
Context Engineering 的实践原则
- Own your context window（12 Factor Agents Factor 3）：不要把上下文管理交给框架，你要完全控制每次 LLM 调用看到什么
- 格式即信息：同样的数据，结构化的 JSON 比纯文本效果好得多。工具返回的结果格式直接影响注意力分布
- 动态 > 静态：prompt 模板应该根据任务动态构建，不是写死一段
- 压缩旧上下文：对话变长时，用摘要替代原始历史——保持相关信息密度
- 错误也是上下文（Factor 9）：工具执行失败时，把错误信息紧凑地传回上下文，而不是崩溃
CHAPTER 06 · 现代 Agent 工程
Harness Engineering
如果 LLM 是马，那 Harness（马具） 就是围绕它的一切——缰绳、马鞍、马镫。Harness Engineering 指的是围绕 LLM 构建的所有非模型本身的工程：上下文管理、工具编排、控制流、错误处理、状态持久化。
核心洞察：Agent 失败 ≠ 模型失败
Agent 的组成：
┌─────────────────────────────────────────────┐
│ Agent 系统 │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ LLM (模型) │ │
│ │ ← 你无法改变这部分 │ │
│ │ ← 只能选不同的模型 │ │
│ └─────────────────────────────────────┘ │
│ │
│ 以上全部是 "Harness"（你可以工程化的部分）: │
│ • 上下文组装逻辑 │
│ • 工具定义和执行 │
│ • 控制流 (循环/分支/重试) │
│ • 状态管理 (暂停/恢复/持久化) │
│ • 错误处理 │
│ • 人机交互接口 │
│ • 评估和监控 │
└─────────────────────────────────────────────┘
关键认知: 大部分 Agent 改进空间在 Harness，不在模型
换更强的模型 = 被动等待
改进 Harness = 主动控制
Harness 的核心组件
Context Manager
管理每次 LLM 调用的上下文：组装、压缩、截断、注入检索结果
Tool Runtime
工具的注册、路由、执行、结果格式化、超时处理
Control Flow
Agent 循环、条件分支、并行/串行、最大步数限制
State Layer
执行状态的持久化、暂停/恢复、checkpoint
Error Handler
工具失败的优雅降级、重试策略、错误信息注入上下文
Human Interface
人机交互——何时请示人类、如何中断、如何传递审批
Model Engineering vs Harness Engineering
| 维度 | Model Engineering | Harness Engineering |
|---|---|---|
| 改什么 | 模型参数（训练/微调） | 模型周围的所有代码 |
| 谁来做 | ML 研究员 | 软件工程师 |
| 反馈周期 | 天/周（需要训练） | 秒/分钟（改代码即可） |
| 成本 | 极高（GPU + 数据） | 低（工程时间） |
| 2025 趋势 | 模型能力趋于收敛 | 成为核心差异化 |
✅ 为什么 Harness Engineering 是 2025 的关键
模型之间的差距在缩小（GPT-4o vs Claude 4 vs Gemini 2.5 能力趋同）。真正区分好的 Agent 和差的 Agent 的，不再是"用了哪个模型"，而是 Harness 工程的质量——上下文管理得多好、工具设计得多精、控制流多可靠。这就是"12 Factor Agents"等方法论兴起的原因。
"Own Your Stack" 原则
12 Factor Agents 提出了一个反直觉的观点：大多数生产级 Agent 不使用黑箱框架。成功的团队往往"拥有自己的全部栈"：
黑箱框架（如 CrewAI、AutoGen）:
┌──────────────────────────────┐
│ 你的代码 │
│ ┌────────────────────────┐ │
│ │ 框架（黑箱） │ │
│ │ ┌──────────────────┐ │ │
│ │ │ LLM │ │ │
│ │ └──────────────────┘ │ │
│ └────────────────────────┘ │
└──────────────────────────────┘
问题: 你不知道框架给 LLM 传了什么
你无法控制上下文的精确构成
调试困难（黑箱内部不透明）
Own Your Stack（12 Factor 主张）:
┌──────────────────────────────┐
│ 你的代码（全部可见） │
│ • 你的 prompt │
│ • 你的上下文组装逻辑 │
│ • 你的控制流 │
│ • 你的工具 │
│ ┌──────────────────┐ │
│ │ LLM │ │
│ └──────────────────┘ │
└──────────────────────────────┘
优势: 完全控制、完全透明、可调试
框架只是工具库，不是黑箱
CHAPTER 07 · 现代 Agent 工程
12 Factor Agents
2025 年最具影响力的 Agent 工程方法论。灵感来自经典的 "12-Factor App"（Heroku, 2011），由 HumanLayer / Dex Horthy 提出。它不是框架，而是构建生产级 Agent 的 13 条原则。
为什么需要 12 Factor？
Agent 开发的典型陷阱：
阶段 1: "我要做 Agent！"
→ 找一个框架（CrewAI / LangChain / AutoGen）
→ 给一个 prompt + 一堆工具 + while 循环
→ Demo 跑通了！🎉
阶段 2: "上线吧"
→ 80% 场景正常，20% 出问题
→ 不知道为什么出错（黑箱）
→ 无法暂停/恢复
→ 无法持久化状态
→ 无法接人工审批
→ 状态管理和业务逻辑耦合混乱
阶段 3: 要么推倒重来，要么...
→ 逆向工程框架
→ 发现 "生产级 Agent 都是自己写栈的"
12 Factor Agents = 阶段 3 的经验总结
= 让你直接跳到正确做法
13 条原则总览
| # | 原则 | 一句话解释 |
|---|---|---|
| 1 | Natural Language → Tool Calls | Agent 的输入是自然语言，输出是结构化的工具调用 |
| 2 | Own Your Prompts | 不要让框架替你写 prompt，你的 prompt 是核心竞争力 |
| 3 | Own Your Context Window | 完全控制每次 LLM 调用的上下文构成 |
| 4 | Tools = Structured Outputs | 工具调用本质上是结构化输出的一种 |
| 5 | Unify Execution & Business State | 执行状态和业务状态统一管理，不分两套 |
| 6 | Launch / Pause / Resume | Agent 可暂停、可恢复，用简单 API 实现 |
| 7 | Contact Humans with Tool Calls | 人机交互也是一种工具调用——统一抽象 |
| 8 | Own Your Control Flow | 不要让框架决定执行流程，你写控制流 |
| 9 | Compact Errors into Context | 错误信息压缩后注入上下文，不是抛异常崩溃 |
| 10 | Small, Focused Agents | 不要做万能 Agent，做专精的小 Agent |
| 11 | Trigger from Anywhere | Agent 可被 webhook、cron、消息队列、用户消息触发 |
| 12 | Stateless Reducer | Agent = 纯函数 (state, action) → new_state |
| 13 | Pre-fetch Context | 在 LLM 调用前，预先拉取可能需要的上下文 |
深入关键原则
Factor 3: Own Your Context Window
这是 Context Engineering（第 5 章）的核心实践。大多数框架会自动管理上下文——决定保留哪些历史、如何截断、注入什么。但 12 Factor 认为：你必须自己控制这些。
框架管理上下文（不推荐）:
LLM 调用 ← [框架自动组装上下文]
↑ 你不知道里面有什么
↑ 调试时完全不透明
你自己管理上下文（推荐）:
1. 显式构建 messages 列表
2. 决定保留哪些对话历史
3. 注入检索到的文档
4. 格式化工具结果
5. 然后传给 LLM
→ 每次调用完全透明、可调试、可优化
Factor 7: Contact Humans with Tool Calls
人机交互（Human-in-the-Loop）不是特殊的代码路径，而是另一种工具调用：
传统方式（不推荐）:
Agent 执行 → 需要人类确认 → 特殊中断逻辑 → 等待 → 恢复
（复杂的异步状态管理）
统一为工具调用（推荐）:
Agent 执行 → 调用 ask_human(question) 工具
↓
人类回答 → 结果注入上下文
↓
Agent 继续推理
→ 人和工具用同一套抽象
→ 无需特殊的 HITL 代码路径
→ ask_human 和 get_weather 本质相同
Factor 9: Compact Errors into Context
工具执行失败时，不要抛异常崩溃。把错误信息压缩成上下文，让 Agent 自己决定怎么处理：
传统方式: 工具失败 → 抛异常 → Agent 崩溃
12 Factor 方式:
工具失败 → 返回 {"error": "API 超时", "suggestion": "重试或换方案"}
→ 注入上下文 → Agent 看到错误 → 自主决定下一步
→ Agent 可能重试 / 换工具 / 通知用户 / 放弃
→ 这就是 "Compact Errors into Context"
→ 错误也是信息，不是终止信号
Factor 12: Make Your Agent a Stateless Reducer
这是最深刻的原则：Agent 应该是一个纯函数（reducer）：
Agent as Stateless Reducer
new_state = agent_reducer(current_state, action)
输入: 当前状态 + 新的动作（用户消息/工具结果/定时触发）
输出: 新状态 + 要执行的副作用（LLM 调用/工具执行）
Agent 本身无状态 → 可序列化 → 可暂停/恢复 → 可回放调试
输入: 当前状态 + 新的动作（用户消息/工具结果/定时触发）
输出: 新状态 + 要执行的副作用（LLM 调用/工具执行）
Agent 本身无状态 → 可序列化 → 可暂停/恢复 → 可回放调试
💡 Reducer 模式的威力
如果 Agent 是纯函数，那么：状态 = 输入的确定性函数。给定相同的状态和动作，结果永远相同。这意味着你可以回放任何一次执行（用于调试）、快照任何时刻的状态（用于暂停/恢复）、并行运行多个 Agent（状态不冲突）。
CHAPTER 08 · 现代 Agent 工程
Workflow vs Agent：你到底需要哪种？
2025 年 Anthropic 在 "Building Effective Agents" 中做了一个被广泛引用的区分：Agentic Workflow ≠ Autonomous Agent。混淆这两者是 Agent 项目失败的最常见原因。
核心区分
| 维度 | Workflow（工作流） | Agent（自主智能体） |
|---|---|---|
| 控制流 | 开发者预定义的代码路径 | LLM 自主决定路径 |
| LLM 角色 | 流程中的特定步骤 | 流程的指挥者 |
| 可预测性 | 高（路径固定） | 低（每次可能不同） |
| 成本控制 | 容易（步骤已知） | 困难（步数不确定） |
| 适用场景 | 结构化、重复性任务 | 开放式、探索性任务 |
| 类比 | 流水线上的工人 | 独立承包商 |
Anthropic 的五种 Workflow 模式
不是所有任务都需要完整的自主 Agent。Anthropic 定义了五种渐进的 Agentic 模式，从简单到复杂：
模式 1: Prompt Chaining（提示链）
[输入] → LLM步骤1 → LLM步骤2 → LLM步骤3 → [输出]
例: 翻译流水线
中文 → [LLM: 翻译成英文] → [LLM: 润色] → [LLM: 校对] → 最终英文
→ 固定路径，每步用不同的 prompt
→ 最可控、最便宜
→ 适合流程明确的任务
模式 2: Routing（路由分发）
┌→ [LLM: 技术专家] → [输出]
[输入] → [LLM: 分类器] ─┼→ [LLM: 客服] → [输出]
└→ [LLM: 销售] → [输出]
→ 先分类，再路由到不同处理链
→ 每条路径可以有不同的 prompt 和工具
→ 适合多领域客服/支持系统
模式 3: Parallelization（并行）
┌→ [LLM: 审查安全性] ─┐
[输入] ────┼→ [LLM: 检查事实] ─┼→ [汇总] → [输出]
└→ [LLM: 评估语气] ─┘
两种变体:
Sectioning: 同时做不同子任务，合并结果
Voting: 同一任务跑 N 次，投票取多数
→ 适合需要多角度分析的任务
→ 延迟 = max(各步) 而非 sum(各步)
模式 4: Orchestrator-Workers（编排者-执行者）
[LLM: Orchestrator]
╱ | ╲
[Worker1] [Worker2] [Worker3]
╲ | ╱
[LLM: Orchestrator] ← 合成
→ Orchestrator 动态分解任务、分配给 Worker
→ Worker 各自处理后，Orchestrator 合成结果
→ 这是多 Agent 分工模式的 Workflow 版本
→ 与自主 Agent 的区别: 控制流仍由开发者定义
模式 5: Evaluator-Optimizer（评估-优化循环）
[输入] → [LLM: 生成] → [LLM: 评估] ──合格──→ [输出]
↑ │
└──不合格─── 修正
→ 生成-评估-修正循环
→ 不是自主 Agent（路径固定：生成→评估→修正）
→ 但有循环（不是纯线性）
→ 适合写作、代码生成等需要迭代改进的任务
什么时候用 Workflow？什么时候用 Agent？
⚠️ Anthropic 的核心建议
能用 Workflow 就不要用 Agent。Workflow 更可预测、更可靠、更便宜、更易调试。只有当任务路径无法预先定义、需要 LLM 自主决策下一步时，才使用自主 Agent。
| 用 Workflow | 用 Agent |
|---|---|
| 任务步骤可预先拆解 | 任务步骤无法预测 |
| 需要高可靠性 | 需要灵活性和探索性 |
| 成本敏感 | 效果优先于成本 |
| 生产环境大规模部署 | 原型开发、研究探索 |
| 合规要求高（路径可审计） | 开放式问题求解 |
现实：大部分"Agent"产品其实是 Workflow
行业真相 (来自 12 Factor Agents):
"很多号称 'AI Agent' 的产品其实不太 agentic。
它们大部分是确定性代码，
只在恰当的位置点缀了 LLM 步骤来制造魔法体验。"
→ 这不是坏事！
→ Workflow + LLM = 可靠的 AI 产品
→ 纯自主 Agent = 难以控制的实验品
最佳实践:
1. 先用 Workflow 解决 80% 的场景
2. 只在确实需要自主决策的 20% 用 Agent
3. 两者混合：Workflow 为主，Agent 为辅
CHAPTER 09 · 现代 Agent 工程
Eval-Driven Development
传统软件用单元测试保证质量。Agent 时代，由于 LLM 输出的非确定性，传统测试方法失效。取而代之的是 Eval-Driven Development（评估驱动开发）——用 LLM-as-Judge 和自动化评估替代断言测试。
为什么传统测试对 Agent 失效
传统软件测试:
assert add(2, 3) == 5 ← 确定性：永远成立
assert login("user") == True ← 确定性：永远成立
Agent 测试:
result = agent.chat("帮我订一张北京到上海的机票")
assert result == ??? ← 输出每次不同！
← 无法断言精确文本
← 甚至步骤数都不固定
→ 断言式测试对 Agent 几乎无用
→ 需要新的质量保证范式
LLM-as-Judge：用 AI 评估 AI
核心思路：用一个 LLM（通常是更强的模型）来评估另一个 LLM 的输出质量：
LLM-as-Judge 的基本结构
score = judge_llm(question, answer, rubric)
question: 原始问题
answer: 被评估 Agent 的回答
rubric: 评分标准（如"准确性、完整性、简洁性"）
score: 0-100 分或 pass/fail
question: 原始问题
answer: 被评估 Agent 的回答
rubric: 评分标准（如"准确性、完整性、简洁性"）
score: 0-100 分或 pass/fail
LLM-as-Judge 的工作流：
测试集 (N 个问题)
↓
┌─────────────────────────────────────┐
│ 对每个问题: │
│ │
│ 问题 → [被测 Agent] → 回答 │
│ │
│ 问题 + 回答 + 评分标准 │
│ → [Judge LLM] → 分数/评价 │
└─────────────────────────────────────┘
↓
汇总: 通过率 87%, 平均分 7.2/10
↓
分析失败案例 → 改进 Context/Harness → 重新评估
→ 这就是 Agent 开发的核心循环
→ 不是 "写测试 → 跑测试 → 修 bug"
→ 而是 "建评估集 → 跑评估 → 改 Harness → 跑评估"
Eval 的三个层次
| 层次 | 评估什么 | 方法 |
|---|---|---|
| Step-level | 单步工具调用是否正确 | 工具参数是否符合 schema、调用的工具是否合理 |
| Trajectory-level | 推理路径是否合理 | 步骤数是否过多、是否走了弯路、是否重复调用 |
| Outcome-level | 最终结果是否正确 | LLM-as-Judge 或人工审核 |
Agent 可观测性（Observability）
除了评估，你还需要看到 Agent 在做什么。这就是 Agent Observability——对每次 LLM 调用、工具调用、决策点的完整追踪：
Agent 执行追踪 (Trace):
[用户] "北京到上海的机票"
│
├── [LLM 调用 #1] context=[system+user] → 决定调用 search_flights
│ └── 耗时: 1.2s tokens: 850
│
├── [Tool: search_flights] params={from:"北京",to:"上海"}
│ └── 结果: 5个航班选项 耗时: 0.8s
│
├── [LLM 调用 #2] context=[+航班结果] → 决定调用 format_results
│ └── 耗时: 0.9s tokens: 1200
│
└── [输出] "为您找到5个航班..."
→ 每一步都可追溯
→ 看到每次 LLM 调用的完整输入/输出
→ 发现: 哪步耗时最长？哪步上下文有问题？哪步决策错误？
→ LangSmith / Langfuse / Phoenix 等工具提供此能力
从 Eval 到持续改进
Agent 持续改进循环
收集真实案例 → 建立评估集 → 自动评估
→ 分析失败 → 改进 Context/Harness → 重新评估
→ 加入新案例 → 扩大评估集 → ↻
→ 分析失败 → 改进 Context/Harness → 重新评估
→ 加入新案例 → 扩大评估集 → ↻
💡 Eval 是 Agent 的"测试套件"
就像传统软件的 test suite 给你信心做代码重构一样，Eval 集给你信心做 Harness 改进。没有 Eval 集，任何改动都是盲目的——你不知道改了 prompt 后是否在其他场景引入了退化。
CHAPTER 10 · 综合
完整原理推导：从数学到工程
把全部 9 章串联成一条因果链：从 Transformer 的数学，到 Agent 工程方法论。
五层因果链
AI Agent 的完整知识体系：
┌────────────────────────────────────────────────────────────┐
│ 第一层：数学基石 │
│ │
│ Token → 条件概率 P(xₙ|x₁..xₙ₋₁) → 自回归生成 │
│ 注意力机制: softmax(QKᵀ/√dₖ)V → 每个词"看到"全部上下文 │
│ 训练: 交叉熵损失 + 梯度下降 → 万亿参数的统计模型 │
└─────────────────────────┬──────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────┐
│ 第二层：能力涌现 │
│ │
│ 参数量 > 阈值 → 推理、指令遵循、代码能力涌现 │
│ CoT → 增加计算深度 → 激活隐含推理模式 │
│ In-Context Learning → 注意力锚定 → 模仿示例 │
│ Token 边界影响理解 → 幻觉 = 概率采样的固有属性 │
└─────────────────────────┬──────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────┐
│ 第三层：现代 Agent 工程 ← 2025 核心认知 │
│ │
│ Context Engineering: 动态构建最优上下文（六来源汇聚） │
│ Harness Engineering: 模型周围的全部工程才是差异化关键 │
│ 12 Factor Agents: 13 条生产级 Agent 原则 │
│ Workflow vs Agent: 能用 Workflow 就不用自主 Agent │
│ Eval-Driven Dev: LLM-as-Judge + 可观测性 = 质量保证 │
└─────────────────────────┬──────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────┐
│ 第四层：架构模式 │
│ │
│ Agent 循环 = 图灵机 (纸带=上下文, 读写头=LLM) │
│ 记忆 = 信息论压缩管道 (历史→检索→注入) │
│ 多 Agent = 角色分化 (不同 system = 不同概率空间) │
│ 人机交互 = 工具调用的一种 (Factor 7 统一抽象) │
└────────────────────────────────────────────────────────────┘
术语速查表
| 术语 | 一句话定义 | 替代了什么 |
|---|---|---|
| Context Engineering | 动态构建最优 LLM 上下文的系统工程 | Prompt Engineering |
| Harness Engineering | 模型周围所有非模型本身的工程 | "调 API"的朴素认知 |
| 12 Factor Agents | 生产级 Agent 的 13 条构建原则 | 黑箱框架依赖 |
| Agentic Workflow | 开发者预设路径 + LLM 在特定步骤 | "一切皆 Agent"的误解 |
| Own Your Context Window | 完全控制每次 LLM 调用的输入 | 框架自动管理上下文 |
| Stateless Reducer | Agent = 纯函数 (state, action)→new_state | 有状态的 Agent 对象 |
| Compact Errors | 错误信息注入上下文而非崩溃 | 异常抛出和终止 |
| LLM-as-Judge | 用 LLM 评估 LLM 输出质量 | 传统断言测试 |
| Eval-Driven Dev | 评估集驱动的迭代改进循环 | Test-Driven Development |
| Observability | 每次调用的完整追踪 | 日志打印 |
一句话理解 Agent
🎯 2025 视角的第一性原理总结
LLM 是一个学到了人类语言统计规律的巨大概率函数。注意力机制让它将上下文中的一切融入每次预测——这就是为什么 Context Engineering（管理进入上下文的信息）比 Prompt Engineering（调措辞）更重要。模型周围的所有工程——工具、控制流、错误处理、状态管理——构成了 Harness，而 Harness 的质量才是 Agent 好坏的关键差异化。12 Factor Agents 告诉我们：拥有自己的栈、管理你的上下文窗口、把人和工具统一抽象、让 Agent 成为可回放的无状态 reducer。最后，Eval-Driven Development 用 LLM-as-Judge 替代传统测试，成为 Agent 质量保证的新范式。
模型趋于收敛，工程成为壁垒。这就是 2025-2026 年 Agent 领域的核心认知。
推荐深入阅读
- Anthropic "Building Effective Agents" — Workflow vs Agent 的五种模式
- LangChain "The Rise of Context Engineering" (Harrison Chase, 2025-06) — Context Engineering 权威定义
- HumanLayer "12 Factor Agents" (Dex Horthy) — 13 条生产级 Agent 原则
- "Attention Is All You Need" (Vaswani et al., 2017) — Transformer 原始论文
- Andrej Karpathy "Let's build GPT" — 从零构建 GPT