模块 0 · 心智模型
先建坐标系。这一章不写复杂代码，但你看完应该能准确判断一个系统算不算 Agent ，以及什么时候不该做 Agent。
0.1 Agent 的最小定义
Agent = LLM + 工具 + 循环 + 终止条件
四个都得有。少一个就是别的东西：
| 缺什么 | 变成什么 |
|---|---|
| 缺工具 | 就是个 Chatbot（只能说，不能做） |
| 缺循环 | 就是一次 Function Calling（做一步就停） |
| 缺终止条件 | 就是个会烧钱的死循环 |
| 缺 LLM | 就是传统的 if-else 工作流 |
把它写成代码只有十几行------这就是整个领域的地基：
def agent(task, tools, max_steps=20):
messages = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": task},
]
for step in range(max_steps): # ← 循环 + 步数上限(终止条件之一)
resp = llm.call(messages, tools=tool_schemas) # ← LLM
messages.append(resp)
if not resp.tool_calls: # ← 终止条件之二：模型不再要工具
return resp.text
for call in resp.tool_calls: # ← 工具
result = tools[call.name](**call.args)
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result,
})
raise MaxStepsExceeded() # ← 终止条件之三：兜底这就是 ReAct，这就是 90% 的 Agent 框架剥掉包装后的样子。 后面所有模块（记忆、RAG、多智能体、评测）都是在给这十几行的某一处打补丁：
messages越来越长 → 模块 2「上下文工程」+ 模块 5「记忆」tools[call.name]选错了 → 模块 3「工具设计」for step in range()绕圈不收敛 → 模块 4「架构范式」result里塞了 10 万字 → 上下文压缩- 循环跑到一半进程挂了 → 检查点与持久化
result里藏了一句"忽略之前的指令" → 模块 11「提示注入」
记住这张映射表，你学后面每一章时都知道自己在补哪个洞。
0.2 关键认知：模型从不"执行"任何东西
这是最容易被面试问穿的一点。
模型输出的永远只是 token。所谓"调用工具"，实际是：
模型输出一段结构化文本 → 你的宿主程序解析它 → 你的程序去执行 → 你把结果拼成文本塞回上下文 → 模型继续输出 token"行动"发生在你的代码里，不在模型里。 由此推出三条硬结论：
- 权限边界在你手上 。模型说要删库，删不删是你的
tools字典说了算。所有安全防线都建在宿主侧，不能指望模型自觉。 - 模型对世界的全部认知来自上下文。它不知道刚才那个工具是否真的成功了，除非你把结果写回去。你写回什么，它就信什么------错误的观测会被后续推理放大。
- 一切问题最终都是上下文问题 。Agent 出错，八成不是"模型笨"，而是它当时看到的上下文里没有足够信息、或者有误导信息。排查 Agent bug 的第一动作永远是：把那一步完整的上下文打出来看。
0.3 三层能力谱与选型
Workflow ──────────→ Agent ──────────→ Multi-Agent
路径由人写死 路径由模型决定 路径 + 分工都由模型决定
可控性 ↑↑↑ ↓↓↓
灵活性 ↓↓↓ ↑↑↑
成本 低 中 高
可调试 容易 难 很难选型判据（一句话）：能枚举清楚分支的，就别用 Agent。
具体一点：
| 情况 | 该选 |
|---|---|
| 输入形态固定、步骤确定（如"提取发票字段→写库→发通知"） | Workflow（LLM 只做单点能力，流程用代码编排） |
| 步骤数量/顺序取决于内容，无法预先枚举（如"排查这个线上报错"） | Agent |
| 需要多种不相容的专长，且子任务之间上下文可隔离 | Multi-Agent |
| 只是想让输出更好 | 都不需要，先优化 prompt 和上下文 |
这是高频面试题，标准答法是：
Agent 的自主性是拿可控性换来的。只有当"路径无法预先枚举"这个条件成立时，这笔交换才划算。绝大多数生产系统里，Workflow 骨架 + 局部 Agent 节点的混合结构比纯 Agent 更稳。
补一句真实工程经验：很多号称 Agent 的生产系统，拆开看是 Workflow------因为团队上线后为了稳定性，一步步把模型的自由度收回去了。这不是失败，这是正常收敛。
0.4 Agent 的四个本质困难
面试问"Agent 落地难在哪"，答这四个，比说"幻觉"高级得多：
① 误差累积（Compounding Error）
单步准确率 95%，20 步任务的成功率是 0.95^20 ≈ 36%。
→ 推论：降步数比提单步精度更有效。工具做粗一点（一个工具干完三件事）常常比工具做细更好。
② 无进展检测（No-Progress Detection）
模型不知道自己在绕圈。它会反复调同一个工具、反复换措辞搜同一个东西，且每次都"觉得这次不一样"。
→ 需要宿主侧做检测：相同工具+相同参数连续调用、N 步内状态无变化 → 强制打断或注入提示。
③ 观测质量决定一切（Grounding）
模型的自我反思，如果没有外部真实信号（编译器报错、测试结果、检索命中），就是幻觉叠加幻觉。
→ 好的 Agent 场景一定自带验证信号。写代码有测试、查数据有结果集，所以这两个方向最先跑通；而"写一份好的商业计划书"这种没有客观验证信号的任务，Agent 化收益就小得多。
④ 状态与恢复
长任务必然中断------超时、崩溃、限流、用户关页面。而 LLM 调用不幂等、有副作用的工具不可重放。
→ 必须有检查点（checkpoint），且检查点要存过程不能只存结果。
0.5 能力公式
Agent 效果 = 模型推理力 × 工具设计质量 × 上下文组织 × 反馈闭环质量乘法不是加法------任一项接近 0，整体就接近 0。
实践中的资源分配建议（与直觉相反）：
- 模型推理力：你能做的最少（换个模型就完了，别在这上面耗）
- 工具设计质量：投入最高回报，工具描述写得好，弱模型也能跑对
- 上下文组织：决定天花板，也是排查问题的入口
- 反馈闭环：决定能不能自愈，没有它 Agent 只能一次性成功
新手最常见的错配：花 80% 时间调 prompt 措辞，0% 时间看"模型当时到底看到了什么"。