心智模型

上一章我们扫了 Agent 的历史。但概念太多——你听过 ReAct、CoT、ToT、Reflexion、 AutoGPT、LangGraph、orchestrator-workers……到了写代码时还是糊。这一章把所有这些 术语对齐到一张可操作的图。读完，你能对任何一段标榜 "agentic" 的代码 迅速回答：它本质是什么、属于哪种模式、复杂度有没有用对地方。

2.1最小心智模型：Augmented LLM

Anthropic 2024 年那篇Building Effective Agents提出了一个干净的底层抽象： Augmented LLM。一切复杂 Agent 系统都是它的组合。

flowchart LR
  P["prompt"] --> LLM
  subgraph LLM["Augmented LLM"]
    direction LR
    T["tools"]
    R["retrieval"]
    M["memory"]
  end
  LLM --> Resp["response"]
  T -.-> TX["工具调用
改变外部状态"]
  R -.-> RX["RAG
检索知识"]
  M -.-> MX["长期记忆
跨调用状态"]
  classDef enhance fill:#fbfaf6,stroke:#8b1538,color:#8b1538
  class T,R,M enhance

三件增强：

• Tools — 函数调用能力。让 LLM 能改变外部状态、读外部数据。
• Retrieval — 检索能力。从知识库、文档、向量库拉信息进 context。
• Memory — 跨调用持久化状态。包括短期会话记忆和长期跨会话记忆。

这三件单独看都是"工具"，但放在一起，LLM 就从"对话引擎"变成"能完成任务的引擎"。 本书后面所有抽象——Agent、Workflow、orchestrator、subagent——都是 Augmented LLM 在某种调度方式下的组合。

2.2Workflow vs Agent：关键分类

Anthropic 那篇博客最重要的贡献，是把"agentic system"切成两类：

这个区分至关重要，因为它直接影响你应该写什么代码：

• Workflow 用普通 Python 控制流：if/else、for、try/except。 每步调一次 LLM。可预测、便宜、好调试。
• Agent 必须有一个 while 循环 + 工具集 + budget 控制。 不可预测、贵、难调试，但能处理开放任务。

5 种 Workflow 模式

Anthropic 列了 5 种，我们各看一眼，因为 Hermes 内部都用到了。

① Prompt Chaining（链式提示）

把任务切成顺序步骤，每步一个 LLM 调用，输出喂下一步。

# 伪代码：写博客的 chain
outline = llm("给我一个关于 X 的提纲")
draft   = llm(f"按这个提纲写：" + outline)
polish  = llm(f"优化这段文字：" + draft)

关键：步骤之间是顺序依赖。每步的 prompt 是定死的代码，不是 LLM 自己决定的。

② Routing（路由）

用一个 LLM 当分类器，根据输入选下游 chain。比如客服系统： "用户问退款？走退款 chain。问产品？走产品 chain。"

③ Parallelization（并行化）

两种子模式：

• Sectioning：把任务切成可并发的部分，分别调 LLM，最后聚合。例：让 LLM 把长文档切 10 段，并行总结，再汇总。
• Voting：同一个问题让多个 LLM 各答一次，取多数。降低单次失误风险。

④ Orchestrator-Workers（编排者-工人）

一个"orchestrator" LLM 看任务，动态切成子任务，分给"worker" LLM 执行， 最后自己整合结果。和 Sectioning 的区别：子任务列表不是事先写死的，是 orchestrator 生成的。Anthropic 自己的代码 Agent 就是这种结构。

⑤ Evaluator-Optimizer（评估-优化循环）

一个 LLM 生成，另一个 LLM 评估，把反馈给生成者改进，迭代到达标。 代码 Agent 写完代码后跑 lint 是简化版（lint 工具替代了 evaluator LLM）。 Voyager 论文里"iterative prompting + 环境反馈"也是这类。

Agent 模式

Agent 不是某种特定模式，而是"以上 5 种的动态组合 + 循环"。 Anthropic 这样描述：

"Agents begin their work with either a command from, or interactive discussion with, the human user. Once the task is clear, agents plan and operate independently, potentially returning to the human for further information or judgment."

这就是 Hermes 的形态。一旦你用 hermes 命令开启对话， 你不再告诉它每一步该做什么——它自己决定下一步是搜索、读文件、还是问你。

2.3ReAct 模式与现代 Function Calling

让我们把第 1 章的 ReAct 重新对齐到 Augmented LLM 框架。

ReAct 的本质是给 LLM 显式 reasoning 步骤。它要求 LLM 输出顺序是：

Thought:  <为什么我要做这件事>
Action:   <工具名>[参数]
Observation: <工具结果>
Thought:  ...

而现代 Function Calling 的输出是：

content:    "我打算搜一下"      # Thought（可选）
tool_calls: [{name: "search",       # Action（结构化）
              arguments: {q: "..."}}]

下一轮 messages 里就是：

{"role": "tool", "tool_call_id": "...",
 "content": "工具结果"}            # Observation

所以"现代 Function Calling"≈ "结构化的 ReAct"。 reasoning content 字段（DeepSeek-R1、Claude Extended Thinking）则把 "Thought" 也变成了协议一等公民，不再是 content 里的散文。

2.4Chain-of-Thought 与 Reasoning Models

CoT（Chain-of-Thought，Wei et al. 2022）是 Agent 的近亲。 本质都是"让 LLM 把思考过程写出来"。但 CoT 是单次调用内的， Agent 是多轮工具调用的。区别在循环：

2024 年起 OpenAI o1 / DeepSeek R1 / Claude Extended Thinking 让 CoT 从 prompt 技巧升级成模型一等公民能力。模型在输出 final answer 前会先输出"reasoning"（不计费给用户读到），自己想清楚再说话。

对 Agent 工程的影响：

• reasoning content 不能直接喂回去给模型——某些 provider 要求严格 echo back， 不行就 echo 错就报错。Hermes 在 conversation_loop 第 2283–2334 行专门处理。
• reasoning 部分占 token，但不占用户的 context window 心智成本——它在 provider 那边被 strip 掉再发给下一轮。
• reasoning 模型在 SWE-Bench 等长程任务上比"普通对话模型 + Agent"有更高上限。 但成本也更高。

2.5Hermes 是 Workflow 还是 Agent？

把以上分类应用到 Hermes：

从最外层看 — Hermes 是 Agent。用户开启对话后，Hermes 不被 脚本路径限制，它自己决定每一步是搜索、读文件、调子 Agent、还是直接回答。

从内部子系统看 — Hermes 大量用 Workflow 模式：

• Curator 是 Routing：把 skill 按状态路由到不同处理路径。
• Context Compression 是 Prompt Chaining：触发条件 → 总结 LLM → 替换历史。
• Delegate Task 是 Orchestrator-Workers：父子 Agent 派活。
• Memory Prefetch 是 Retrieval（augmented LLM 的 R）：背景检索拼进 volatile prompt 层。

这说明Workflow 和 Agent 不是非此即彼——好的 Agent 系统内部 到处嵌套着 Workflow。第 7 章会看到 Hermes 怎么用 plugin hooks 让你也能 往任何工具调用边界塞一个小 workflow（如审计日志、内容脱敏）。

2.6什么时候用 Agent，什么时候用 Workflow

这是工程师最该问自己的问题。Anthropic 的建议：

实际指南

Pragmatic flowchart：

flowchart TD
  Start(["任务来了"]) --> Q1{"步骤能事先
列出来吗？"}
  Q1 -->|是| W["Workflow"]
  Q1 -->|否| Q2{"工具空间小？"}
  Q2 -->|是| A1["简单 ReAct
+ 少数工具"]
  Q2 -->|否| A2["完整 Agent
+ 子 Agent"]
  classDef workflow fill:#e8eff5,stroke:#2c5282,color:#2c5282
  classDef agent fill:#fbfaf6,stroke:#8b1538,color:#8b1538
  class W workflow
  class A1,A2 agent

翻译成具体决策：

1. "我要做翻译 + 总结 + 发邮件"——三步固定 → Workflow。三次 LLM 调用就够。
2. "我要做把这个 PR review 一下"——可能要看 5 个文件也可能 50 个 → 简单 Agent 配 read_file、grep、diff 工具。
3. "我要做从需求文档生成完整 Web 应用"——开放任务、要写代码、跑测试、修 bug → 完整 Agent + 子 Agent 分工 + iterative refinement。

2.7本书的概念地图

把所有概念组织成一张图。这张图你需要回来查很多次：

flowchart TD
  Root["LLM-Era Agent"]
  Root --> Aug["Augmented LLM"]
  Root --> Ctrl["控制流"]
  Aug --> T["Tools"]
  Aug --> R["RAG"]
  Aug --> M["Memory"]
  Aug --> Rs["Reasoning"]
  Ctrl --> W["Workflow"]
  Ctrl --> Ag["Agent"]
  W --> W1["Prompt Chaining"]
  W --> W2["Routing"]
  W --> W3["Parallelization"]
  W --> W4["Orchestrator-Workers"]
  W --> W5["Evaluator-Optimizer"]
  Ag --> Ag1["ReAct loop"]
  Ag --> Ag2["Subagent"]
  Ag --> Ag3["+ 自由组合
上面的 workflow"]
  classDef root fill:#f5ede0,stroke:#8b1538,color:#8b1538,font-weight:bold
  classDef branch fill:#ecf3eb,stroke:#2f5d3a,color:#2f5d3a
  classDef agent fill:#fbfaf6,stroke:#8b1538,color:#8b1538
  classDef workflow fill:#e8eff5,stroke:#2c5282,color:#2c5282
  class Root root
  class Aug,Ctrl branch
  class W,W1,W2,W3,W4,W5 workflow
  class Ag,Ag1,Ag2,Ag3 agent

Hermes 用代码实现了这张图的几乎所有节点：

• Tools: 79 个 builtin + MCP server 集成 → 第 6 章
• RAG / Memory: memory_provider ABC + FTS5 → 第 9 章
• Reasoning: 支持 reasoning content 字段 → 第 4 章
• ReAct loop: conversation_loop.py → 第 3 章
• Subagent: delegate_task tool → 第 7 章
• Workflow patterns: compaction、curator、memory prefetch → 各章节

当你读源码迷路时，问自己：我现在看的是这张图哪一块？—— 通常能立刻定位。

2.8Multi-Agent 心智模型四象限

上面讲的是单 Agent。但 2024–2026 年大量项目走向 multi-agent—— 多个 Agent 协作完成一个任务。不同 framework 选了完全不同的底层抽象。 搞清楚抽象差异比学具体 API 重要 100 倍。

四种主流抽象

Hermes 在哪

Hermes 本身是具体 Agent 产品，不属于上面任何 framework。但它内部用了 Handoff 模型——delegate_task 工具就是父 Agent 显式 hand off 给子 Agent。

这是 Anthropic 在 Building Effective Agents 里推崇的路线—— "不用 framework，用直接代码 + 简单 primitive"。 Hermes 没有 StateGraph、没有 ActorRuntime——只有一个 while 循环 + 工具字典 + delegate_task。但已经能搭出 orchestrator-workers 模式。

什么时候上 multi-agent framework

第 13 章我们详细拆这次"framework 大洗牌"的来龙去脉。这里你只需要记住： 不同 framework 的底层抽象决定了它能干什么——选 framework = 选哲学。

2.9本章带走的

• 所有 Agent 系统的底层是 Augmented LLM = LLM + Tools + Retrieval + Memory。
• 系统分为 Workflow（开发者写代码路径）和 Agent（LLM 动态决定路径）。 大多数任务 Workflow 就够了。
• 5 种经典 Workflow 模式：Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer。 Hermes 内部到处嵌着它们。
• ReAct 是 Agent 的祖宗。今天的 Function Calling 是 ReAct 的结构化升级。Reasoning Models 是 CoT 的模型内置化。
• Hermes 整体是 Agent，但内部由多种 Workflow 子系统编排。
• 这张概念地图（2.7 节）会贯穿本书。你迷路时记得回来对照。