11. LLM Agent: Tool Use / ReAct / Plan-Execute / Multi-Agent / Memory

TL;DR

LLM 单独只是"接 prompt 吐 token"的函数；要把它变成能自主完成多步任务的 agent，必须再加四件东西：循环（看结果再决定下一步）、工具（调外部世界 / 代码执行 / DB / 检索）、记忆（跨步、跨任务的状态）和反思（自己纠错）。这一章把 ReAct、Plan-and-Execute、multi-agent、code interpreter、agent 评估和安全这五个核心题型讲透——它们是 ChatGPT 插件、Claude MCP、LangChain / AutoGen / OpenAI Assistants / Claude Code 这类"生产级 agent"背后的同一组抽象。

读完应能：

1. 说清 agent 的最小骨架（LLM + loop + tools + memory + reflection），并在代码里实现一个最简 ReAct loop。
2. 区分 ReAct vs Plan-and-Execute vs Tree-of-Thoughts 各自的决策时机、长任务稳定性、适用场景。
3. 解释 OpenAI function calling / tool calling / structured output 是怎么把"自然语言指令"约束成合法 JSON 工具调用的。
4. 讲清 agent 的 memory 三层（short-term trajectory / long-term vector / structured KV）与 OS 多级存储的同构关系。
5. 在生产环境给 agent 设计沙箱、least-privilege、human-in-the-loop、prompt-injection 防御。

一、Agent 的最小骨架

1.1 从 chatbot 到 agent

Chatbot:
    prompt ──► LLM ──► answer            (一次性, 单步)

Agent:
    prompt ──► LLM ──► decision ──► tool ──► observation
                 ▲                                            │
                 └──────────── (loop) ─────────────────────────┘

四件必备品：

1.2 与传统软件的对照

见 元抽象 · 推理链：硬件层如何决定软件设计——agent 是把"控制流"从代码迁回自然语言，相当于在抽象栈上的"反汇编"。

1.3 终止条件的三种来源

• 模型显式输出 FINISH / stop 工具（ReAct 系）。
• 达步数上限 max_steps（防失控）。
• 外部评测器返回 task_complete（如 SWE-bench 跑 test pass）。

工程上几乎都要加 max_steps + watchdog timer：LLM 可能输出"我还要继续查"的循环。

二、Function Calling：把"调工具"当作结构化输出

2.1 Tool schema

{
  "name": "search_orders",
  "description": "Query the order database for a user's recent orders",
  "parameters": {
    "type": "object",
    "properties": {
      "user_id": {"type": "string", "description": "The user's ID"},
      "limit":   {"type": "integer", "default": 10}
    },
    "required": ["user_id"]
  }
}

模型看到 schema 后，输出形如：

{"name": "search_orders", "arguments": {"user_id": "u123", "limit": 5}}

host 程序解析成 function call，调真正的代码，再把结果塞回 prompt。本质是用 JSON schema 约束解码——让普通的文本模型也能装。

2.2 为什么约束解码是关键

2.3 OpenAI function calling 的演进

• 2023-06: 用 functions / function_call 字段，模型只决定是否调用。
• 2023-11: 改用 tools / tool_calls，支持并行多调用。
• 2024: 支持 structured output / strict schema，输出保证合法。

三、ReAct：Reason + Act 交替的基础骨架

3.1 ReAct（Yao et al. 2022）

Thought: 我需要先查用户的订单状态
Action: search_orders(user_id="u123")
Observation: [{order_id: "o7", status: "shipped"}, ...]
Thought: 订单已发货，可以查物流轨迹
Action: track_logistics(order_id="o7")
Observation: 包裹在 北京分拣中心
Thought: 已有足够信息回答
Action: FINISH
Final Answer: 您的订单已发货，目前在...

伪代码：

def react_run(task, tools, max_steps=20):
    history = [system_prompt(task, tools)]
    for t in range(max_steps):
        out = llm(history)                     # 输出 Thought + Action
        thought, action = parse(out)             # 解析
        history.append(out)
        if action.name == "FINISH":
            return parse_final(out)
        obs = execute(action, tools)             # 真正调工具
        history.append(f"Observation: {obs}")
    return "max steps reached"

3.2 ReAct 的失败模式

• 早终止：模型过早吐 FINISH 没查够。
• 剧情漂移：连续多步后丢失原始目标。
• 工具依赖循环：A 调 B，B 又决定调 A。
• 无效工具：模型猜了一个不存在的能力，输出格式无效。

3.3 ReAct 的适用场景

• 任务步数少且线性（< 10 步），每步几乎独立。
• 工具集小（< 10 个），模型选哪个不糊涂。
• 任务事先不知道要几步，但终点容易判断（query → answer 这类）。

四、Plan-and-Execute：先规划再执行

4.1 动机

ReAct 每一步都重新决策，长任务容易"走着走着忘了方向"。Plan-and-Execute（LangChain 的 Plan-and-Execute Agent、BabyAGI、AutoGPT）思路：

Step 1: Planner 先把任务拆成 subtasks 列表
Step 2: Executor 逐个 subtask 跑（通常用 ReAct 或工具调用）
Step 3: Replanner：每 N 步或失败时回看，重写剩余计划

def plan_and_execute(task, planner, executor, replanner, max_iter=5):
    plan = planner(task)                        # ["查产品库存", "查天气预报", "生成报告"]
    results = []
    for i, sub in enumerate(plan):
        res = executor(sub)                     # 内部可再 ReAct
        results.append(res)
        if i % 3 == 0 or res.failed:
            plan = replanner(task, plan[:i+1], plan[i+1:])   # 动态改剩余计划
    return synthesize(task, results)

4.2 ReAct vs Plan-Execute

4.3 失败模式

• planner 幻觉计划：拆出来的 subtask 根本不可执行（"先炸掉月球"）。
• subtask 之间隐含依赖丢失：planner 拆了「搜 → 排序」，但 executor 不知道哪个 subtask 需要喂给它。
• replanner 不肯悔棋：执行到一半发现开始就错了，replanner 因 context-window 限制或「保持一致性」偏置而不愿改 plan。

五、Memory：让 Agent 拥有跨步、跨任务的记忆

记忆是 agent 跨越单次 prompt 上下文窗口的能力。三类：

5.1 Short-term / Working Memory

• 当前 episode 的 trajectory：(state_t, action_t, obs_t) 序列。
• 实现就是 history 的消息队列：System → User → Assistant → Tool result → ...
• 爆炸问题：trajectory 越长 attention 复杂度 O(T²)，必须 summarization 或截断。

5.2 Long-term Memory：向量检索 + KV

• 把过往的 episode 存进向量库（embedding → similar search），下次任务前 retrieval 拼回 prompt。
• 这就是 RAG 用在 agent 上：Agent = RAG over (past episodes, knowledge, scratchpad)。
• 实现：Chroma / FAISS / Qdrant / pgvector，与 DB vector 联动。

5.3 声明式 / Structured Memory

• 类似程序的状态变量：用户偏好、长期约束、未完成 todo 用 KV 表存。
• 模型在 think 输出里直接 update_memory(key, val) 这种工具调用维护它。
• 代表：Letta（前 MemGPT）用 OS-style memory hierarchy —— main context (working context), recall (episodic), archival (vector store)。

5.4 记忆层与 OS 的同构

见 _meta/memory-hierarchy：这一层抽象在整个计算机系统里反复出现。Agent 的记忆设计本质上是把 OS 多级存储 + 调度的语义搬到 LLM 的 prompt 工程。

六、自我批判与自我重构

6.1 Self-Critique

模型先出答案 A，再被另一个 prompt（同模型或不同模型）问"这段对吗，有什么漏洞"——经典 debate / verify pattern。

Step 1: Generator: question → draft answer
Step 2: Critic:    draft + question → critique
Step 3: Generator: question + draft + critique → revised answer
（可迭代）

实现：Reflexion（verifier 反馈）、Self-Refine（LLM 反思自己输出）。

6.2 Tree-of-Thoughts / Graph-of-Thoughts

把 ReAct 的"单链 trajectory"换成树/图：每个节点是一个想法（state），分支探索，再用 LLM 自己打分搜索。对应 DSA DFS / BFS / 蒙特卡洛树搜索：

• 选下一个分支：UCT（upper confidence bound for trees）→ 与 AlphaGo 的 MCTS 同构。
• 适用于有明确奖励信号 / 可验证答案（数学、代码、拼图）的任务。

6.3 Reflexion：把"失败经历"当成记忆

Reflexion 的关键贡献：第 N 次 rollout 失败后，让 LLM 自己写一段"为什么失败、下次怎么避免"的反思塞进 memory，N+1 次成功率显著升高。这本质是在固定 π_θ 上做 Prompt-level RLHF——不更新权重，只更新软上下文。

七、Multi-Agent：分工、协作、拓扑

7.1 拓扑分类

Supervisor 模式:
  Supervisor ─── Worker A
            ├── Worker B
            └── Worker C
  Supervisor 拆任务、分发、汇总。

Swarm 模式 (Hand-off):
  A ↔ B ↔ C ↔ A
  节点间互相 hand-off，每个节点专职一个能力 (search / code / verify)。

Hierarchical (多级):
  Manager
   ├─ Submanager X
   │    ├─ Worker X1
   │    └─ Worker X2
   └─ Submanager Y
        └─ Worker Y1

7.2 与分布式系统的同构

见 distributed/README。关键洞察：multi-agent system 也是一个分布式系统——消息可能延误、节点可能产生不一致的世界观、hand-off 崩溃导致状态丢失。工程上同样要解决：消息可靠性、因果序、最终一致性、错误检测。

7.3 失败模式

• 沉默失败：Worker A 跑完没回 Supervisor，Supervisor 以为 A 还没动 → 状态不一致。
• 死锁循环：A hand off 给 B，B 决定 hand back 给 A，循环等待。
• 世界不一致：A 与 B 看到不同的 observation，合成时硬凑导致幻觉。

对策与分布式系统同源：有界重试 / 心跳超时 / central state serial log（即把 trajectory 存进外置 KV / 关系库 / 日志，再让 agent 从 log 重建）。

八、Code Interpreter 与 Tool-Use 的本质

8.1 让 LLM "调代码" 是最强的工具

让 LLM 输出一段 Python 然后真的去跑，再喂 stdout 回 prompt，这是当前最强 tool use：

Thought: 需要算 1234! 的位数, 自己不会算
Action: code_run(language="python", code="import math; print(int(math.log10(math.factorial(1234)))+1)")
Observation: 3275

为什么强：

• 表达力远高于 JSON schema 工具：Python 是图灵完备的，可以写循环、出错重试、构造任意结构。
• 工具调用 = eval() 通用编程，抽象掉工具集：不再 enumerate 几百个 API，模型自己写逻辑去组合调用。
• 反馈是客观可验证的：Python 跑出来的不是 LLM 评价的，是物理事实。

8.2 沙箱

跑外部代码 = 远程代码执行风险。工程实现：

• 浏览器端：Pyodide（WebAssembly），用户机器，不影响服务器。
• 服务端：gVisor / Firecracker / Docker with read-only fs，限制 syscalls、网络白名单、CPU/内存配额。
• 临时容器：每次新容器跑完即销。
• API 限流：拒绝 fork bomb / 死循环（CPU 时间 + wall time 都要限）。

8.3 失败模式

• 模型生成的代码语法错（解析失败 → 自动 retry）。
• 运行时错（division by zero、undefined name）。
• 不收敛（无限 print）。
• 不安全 import os 想做坏事 → 沙箱拦截。

九、Agent 的训练数据与 fine-tune

9.1 SFT on Trajectory

把成功的 trajectory 收集成数据集，在 SFT 模型上 predict next ——

• 不像 RL 是按 reward 更新参数，而是直接学人/更强模型的 trajectory 分布。
• OpenAI o1 / R1 / Claude function-calling 工具调用模型走这条路。

9.2 RL on Agent Trajectory

直接对 J(θ) = E_τ[R(τ)] 做 policy gradient——把整个 trajectory 看作一个 episode：

• 一条 trajectory τ = (state_0, action_0, obs_0, ..., state_T, action_T=FINISH)
• reward = task eval（答案对错 / 客观指标）
• 关键问题：信用分配（credit assignment）——哪一步 think-action 真正功不可没？研究热点：stepwise / process reward model。

9.3 与 §8 RLHF 的接

• §8 讲的是 token-level / response-level preference（一段短答 chosen/rejected）。
• Agent RL 是 trajectory-level + 工具调用更稀疏、长 horizon。
• 实践上常用更省钱的：Rejection sampling + SFT（rollout 一堆，保留正确的对它们 SFT），或 GRPO 在 group 内对比。

十、Agent 评估：trajectory vs end-state

10.1 三类 evals

10.2 benchmark 例子

• SWE-bench：给一个真实 GitHub issue，agent 自己改 fix，跑测试看是否通过——end-state，但 reward 是客观的（test pass）。
• AgentBench / GAIA / WebArena：跨工具、跨环境的长 task，综合测 trajectory + end answer。
• τ-bench：模拟客服 agent 的多轮工具调用，衡量"是否完成所有调整"。

10.3 易踩的坑

• 环境泄漏：测试集答案在 train 集里见过 → agent 不是真在解决问题。
• 静态 baseline：不更新的工具会让 agent 学到 overfit 工具调用模板。
• LLM judge 互评偏好：同族模型互评分数异常高，应跨家族 / human aligned。

十一、Agent 安全：把工具调用当远程代码执行

11.1 风险

11.2 防御模式

- 最小权限 (least privilege):
  每个 tool 调用要明确权限声明; agent 的工作目录 / DB 用户只限
  SELECT 或者只在 sandbox 里.

- 输入清洁消毒:
  从外部 web/retrieval 拿回的内容用 wrap 区分隔 (e.g. <untrusted>...</untrusted>)
  让模型"看见这是不可信内容" + 增加 system prompt 强化规则.

- 破坏性操作的二次确认:
  tool 上标 "destructive=true", 调用前必须 human approve.
  这就是 human-in-the-loop 的本质.

- 输出沙箱:
  code interpreter 在独立容器跑, 不连内网, 只读 fs.

- 速率/配额:
  每个 tool / 每个 agent 的调用次数, 防 doomer 循环.

11.3 与工程化实践轴接口

• git-workflow: agent 修改代码必须走 PR，不允许直接 commit。
• app-security: 工具调用通过 mTLS / RBAC 通行，同样的 OWASP Top 10 同样适用。
• testing: agent 的 reliability 用 contract testing + goldset eval。

十二、与前面章节的接口表

十三、结束 + 速查表

下一篇: 12. 多模态: 跨注意力 / Flamingo / LLaVA / BLIP-2 / 扩散多模态.