智能体范式总览：从 LLM 到 Autonomous Agent 的范式跃迁

智能体的工程定义：从"调用模型"到"持续运行"

智能体（Agent）这个概念在 2023 年之后被严重稀释：任何接了一个 LLM API 的程序都被叫作 Agent。但站在工程视角，智能体与普通 LLM 调用的本质差异不在"是否调用了模型"，而在循环是否由模型自身决定何时终止。一次 `client.chat.completions.create()` 调用是 LLM 调用；把模型输出当作下一步动作的指令、再把动作结果回灌给模型、让模型决定"继续"还是"结束"，才构成一个 Agent Loop。

我们给出工程意义上的最小化定义：

> Agent 是一个三元组 $\mathcal{A} = (S, T, \pi)$，其中 $S$ 是环境状态空间，$T$ 是工具集（可执行动作），$\pi: S \to (T \cup \{\text{STOP}\})$ 是由 LLM 参数化的策略函数，且 $\pi$ 的下一次调用取决于当前累积的历史 $h_t = (s_0, a_0, o_0, \dots, s_t)$。

判断一个系统是否是 Agent，需要三个条件同时成立：

1. 状态可观察：Agent 在每一步都能读到环境的当前状态（哪怕状态只是对话历史）。 2. 动作可执行：Agent 的输出可以落到真实工具上，并改变世界或返回非平凡观测。 3. 终止可决策：Agent 自身决定何时结束循环，而不是被外部硬切。

第三个条件最关键。`if turn > 10: break` 不算 Agent 终止；模型在 ReAct 循环里写 `Final Answer:` 才是。把"何时结束"外包给工程代码，意味着系统在结构上仍是流水线（pipeline），Agent 只是流水线上的一个被调用函数。

把这个定义落到代码层面，最小可运行形态是 ReAct（Reason + Act）循环。它由 Yao et al. 在 2022 年提出（[Yao et al., ICLR 2023](https://arxiv.org/abs/2210.03629)），核心是把 Chain-of-Thought 的推理轨迹与外部工具的动作执行交错起来。下面是一次完整 trace 的简化形式：

``` Thought 1: 用户问的复合问题需要先查天气，再决定要不要带伞。 Action 1: get_weather("上海") Observation 1: 多云，降水概率 60% Thought 2: 60% 概率下雨，应该带伞。 Action 2: get_recommendation("雨天出行") Observation 2: 建议带伞并穿防滑鞋 Thought 3: 信息足够了，可以给最终建议了。 Final Answer: 上海今天降水概率 60%，建议带伞，穿防滑鞋。 ```

这个 trace 里，"带伞"这个决策不是被程序员写死的 if-else，而是模型基于 Observation 1 自行推断出来的。这就是 Agent 的不可逆价值：当业务逻辑无法在设计时穷举时，把决策权交给模型。

与传统范式对比：

• **LLM 一次性调用（Prompt → Completion）**：输入输出是 1:1 的函数映射，没有状态延续，没有动作。
• **Chain / Pipeline（如 LangChain 的 ChainLCEL）**：步骤序列由代码硬编码，每一步输入输出在设计时确定，本质是 DSL。
• **RPA（Robotic Process Automation）**：完全确定性，靠录制的 UI 脚本执行，无推理能力。
• **Bot**：通常指有状态对话系统，但状态机由开发者手写，LLM 只是 NLU 组件。
• **Agent**：状态机由 LLM 在运行时动态构造，工具集是固定的，决策边界由 LLM 决定。

因此，Agent 不是更聪明的 Bot，也不是加工具的 Chain，而是把运行时控制权部分让渡给模型的系统。这是为什么"从 Chatbot 到 Agent 的演进不可逆"——一旦你承认业务逻辑存在设计时无法穷举的分支，传统的硬编码方案就结构性失效了。

```mermaid flowchart TD Start([User Goal]) --> O1[Observe: Parse Input + Memory] O1 --> T[Think: LLM Reasoning] T --> D{Decision} D -->|Tool Call| A[Act: Execute Tool] D -->|Final Answer| Done([Return Result]) A --> R[Record Observation] R --> O1 R -.->|read/write| Mem[(Memory Store)] O1 -.->|load| Mem A -.->|invoke| Tools[External Tools/APIs] ```

图 1.1 中，实线是 ReAct Loop 的主控流，虚线是旁路交互（Memory 读写、Tools 调用）。注意 `D` 节点处的分支：Agent 真正决定走 `Act` 还是 `Final Answer`，而不是被外层代码 if-else 决定。

历史演进脉络：从 CoT 到 Tool-Use 的五年

理解 Agent 范式必须把它的演进史看清楚，否则会高估 2023 年后的"突破"、低估早期奠基工作。下面按时间线梳理关键节点，并指出每一步解决的具体问题。

2017–2020：奠基期——Prompt Engineering 的极限探索

此时 LLM 主要是 GPT-2 / BERT 级别的生成模型。Agent 概念尚未流行，但已有零样本工具学习的雏形。OpenAI 的 [WebGPT](https://arxiv.org/abs/2112.09332)（2021 年发表，2020 年开始研发）让模型学会浏览网页并引用来源，这是 Tool-Use 的最早工程范本。

2022 年 1 月：Chain-of-Thought（CoT）

[Wei et al.](https://arxiv.org/abs/2201.11903) 证明只需在 prompt 中插入"Let's think step by step"就能在算术、常识推理上获得大幅提升。其机理是：在有限上下文窗口内，把多步推理显式展开，缓解 Transformer 的"前向-后向一致性"问题（模型在直接生成答案时容易跳过中间步骤导致错误）。

CoT 没有引入工具，但它让"模型在生成最终输出前先思考"成为可能，这是 ReAct 的前提。

2022 年 10 月：ReAct

[Yao et al.](https://arxiv.org/abs/2210.03629) 把 CoT 与动作执行合并为统一轨迹：`Thought → Action → Observation → Thought → ...`。该论文在 HotpotQA、Fever 等基准上首次证明：在少量示例（few-shot）条件下，Reasoning + Acting 联合训练比单独使用任一者都更强。

ReAct 的工程意义远大于其学术意义：它给出了一个通用接口规范——只要你的工具能用自然语言描述输入输出，模型就能在 trace 里使用它。这是后续 AutoGPT、BabyAGI 的设计原型。

2023 年 3 月：Toolformer

[Schick et al. (Meta AI)](https://arxiv.org/abs/2302.04761) 用自监督方法让模型学会在何处插入工具调用。与 ReAct 的提示工程路线不同，Toolformer 把工具使用"烧进"了模型权重。代价是训练成本极高，且每增加一个工具需要重新微调。这条路线后来演变为 OpenAI 的 Function Calling（2023 年 6 月 GA）和 Anthropic 的 Tool Use——它们都是"用结构化输出模拟 Toolformer"，但训练成本低得多，且可以动态增加工具。

2023 年 4 月：AutoGPT 与 BabyAGI

[AutoGPT](https://github.com/Significant-Gravitas/AutoGPT) 和 [yoheinakajima/babyagi](https://github.com/yoheinakajima/babyagi) 几乎同时开源，标志着"自主 Agent"概念进入公众视野。它们的核心模式：

``` while not task_done: plan = llm.decompose(goal, history) next_task = plan.pick_next() result = execute(next_task) history.append(next_task, result) ```

AutoGPT 把任务列表当 Memory，BabyAGI 用向量数据库存任务。两者的失败模式惊人一致：

• 任务分解幻觉：模型把"分析 2023 Q3 财报"分解成 47 个子任务，其中 30 个是它自己想象的。
• 循环死锁：模型反复把同一个任务加入待办列表，消耗 token 不产出。
• 上下文爆炸：几小时运行后 prompt 超过上下文窗口。

这两个项目的真正贡献是暴露了自主 Agent 在生产环境中的根本缺陷——我们后面"适用性边界"一节会回到这个话题。

2023 年 7 月：Reflexion

[Shinn et al.](https://arxiv.org/abs/2303.11381) 引入"verbal reinforcement"：让 Agent 在每次失败后生成一段自然语言反思，并把反思追加到下一轮的 context。这种"反思 Memory"显著提高了 ALFWorld、HotpotQA 等任务的成功率。

Reflexion 的工程价值在于：它给出了没有真值标签时的自监督学习路径——Agent 通过自我批评而非外部奖励来改进。这条思路后来演变为 Reflexion variants（Self-Refine、CRITIC 等），并在 2024 年被纳入多个生产框架。

2023 年 11 月至今：Multi-Agent 与 Hierarchical Orchestration

进入 2024 年，主流框架从单 Agent 转向多 Agent 协作：[MetaGPT](https://arxiv.org/abs/2308.00352)、[AutoGen](https://arxiv.org/abs/2308.08155)、[CrewAI](https://github.com/joaomdmoura/crewAI) 等系统通过角色分工（产品经理、工程师、测试员）模拟人类组织结构。同期，LangGraph、LlamaIndex Workflows 等编排框架兴起，把"图"作为 Agent 拓扑的描述语言。

这条演进路径可以总结为：

``` CoT (2022.01) → ReAct (2022.10) → Toolformer (2023.02) → AutoGPT/BabyAGI (2023.04) → Reflexion (2023.07) → Function Calling GA (2023.06) → Multi-Agent (2023.11+) → Hierarchical Orchestration (2024+) ```

每一步都解决了前一步的某个具体缺陷。ReAct 解决"模型不知道什么时候用工具"，AutoGPT 解决"任务粒度过粗"，Reflexion 解决"无法从失败中学习"，Multi-Agent 解决"单个 context window 容量有限"。理解这条链才能理解今天每个工程决策的历史必然性。

三种主流 Agentic 范式

今天生产环境中的 Agent 系统可以归入三种范式。它们的拓扑结构、失败模式、成本结构截然不同，不能混为一谈。

范式一：Single-Agent Loop

单一 LLM 在固定工具集上反复运行 ReAct 循环。这是最经典、最容易工程化的形态。代表实现：LangChain 的 AgentExecutor、LangGraph 的单节点图、OpenAI Assistants API 的内置 Code Interpreter。

优点：

• 状态空间小，调试容易。所有中间产物都在一个 message list 里。
• 工具调度延迟低，单次 LLM 调用决定下一步。
• 成本可控：可以严格限制 max_steps。

缺点：

• 上下文窗口有限。复杂任务（如分析 100 份文档）会爆 context。
• 决策质量瓶颈在单一模型。无法通过分工提升质量。
• 难以并行：Agent 是单线程思考者。

适用场景：明确边界的工具编排（订机票、查数据库、跑 ETL）、单一领域问答、需要快速验证 PoC。

范式二：Multi-Agent Collaboration

多个 Agent 通过消息传递协作。每个 Agent 有自己的角色 prompt、自己的工具集、自己的 LLM（有时不同模型）。代表实现：CrewAI、AutoGen、MetaGPT。

拓扑可以是：

• **星型**：所有 Agent 围着一个 Orchestrator，适合任务分发。
• **流水线**：Agent A 的输出是 Agent B 的输入，适合链式任务。
• **辩论型**：多个 Agent 并行给方案，最后投票/裁决，适合评估场景。

优点：

• 上下文隔离：每个 Agent 只看到自己关心的信息，减少噪音。
• 角色扮演：让 LLM 模拟"产品经理""工程师"等角色可以显著提升输出质量（这是 Anthropic 在 [Role-Playing 提示工程](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-prompts-from-our-library) 中反复验证的现象）。
• 天然适合并行：独立 Agent 可以并发执行。

缺点：

• 通信开销。每个 Agent 之间传递消息需要序列化、反序列化、可能还要转换格式。
• 一致性难保证。Agent A 给 Agent B 的消息如果含糊，后续所有步骤都会偏移。
• 成本乘数。N 个 Agent 协作的成本通常是单个 Agent 的 3-5 倍（因为每个 Agent 都有自己的 system prompt 开销和 retry overhead）。

适用场景：复杂长链任务（代码生成 + 评审 + 测试）、需要多种专长协作的场景（数据分析 + 可视化 + 报告撰写）、评估场景（多模型对抗）。

范式三：Hierarchical Orchestration

有一个顶层 Orchestrator Agent 把任务分解成子任务，分发给下层 Worker Agent，最后汇总结果。这是工业界最常用、但最少被明确定义的范式。LangGraph 的多层图、AWS Bedrock Agents、Azure AI Studio 的 Agent Flows 都属于这一类。

优点：

• 可控性高。Orchestrator 可以插入人工审核节点（Human-in-the-Loop）。
• 可观测性好。每层有明确的输入输出契约。
• 渐进式自动化。可以从纯 Orchestrator + 人工 Worker 起步，逐步替换为 Agent Worker。

缺点：

• 工程复杂度高。需要定义任务描述语言、错误传播机制、超时策略。
• Orchestrator 是单点故障。Orchestrator 出错整个系统瘫痪。
• 难以跨层传递上下文。Worker 需要从 Orchestrator 的高层意图中"猜测"具体执行参数。

适用场景：企业级生产系统、需要审计和合规的场景、任务粒度差异大的场景（既有"回答客户问题"也有"重跑 ETL"）。

范式选择的决策树

实践中选哪种范式，可以参考下表：

| 任务特征 | 推荐范式 | |---|---| | 单领域、工具数 < 5、明确终止条件 | Single-Agent Loop | | 需要多视角评估、多专长协作 | Multi-Agent Collaboration | | 任务粒度差异大、需要审计 | Hierarchical Orchestration | | 响应延迟要求 < 2s | Single-Agent Loop（避免 LLM 多次调用） | | 成本预算 < $0.1 / 任务 | Single-Agent Loop | | 任务成功率要求 > 95% | Hierarchical Orchestration + Human-in-the-Loop |

Agent 适用性边界：什么时候不该用 Agent

Agent 范式被严重过誉。一个常见错误是把任何"用 LLM 做的事"都包装成 Agent，结果成本飙升、稳定性下降。下面给出清晰的边界判断。

不该用 Agent 的场景

1. 业务逻辑可以完全在设计时穷举

如果你的"智能客服"只有 5 个意图分支，硬编码 if-else + 实体识别比 Agent 便宜 100 倍、稳定 100 倍。Agent 的价值在于应对设计时未知——如果未知不存在，Agent 就是过度设计。

2. 强一致性 / 强合规要求

金融交易、医疗诊断建议、法律文书生成等场景对输出的确定性要求高。Agent 的随机性（即使是 temperature=0 也无法保证完全确定性）使其不适合直接产出最终结果。这类场景的正确做法是 Agent 生成候选，人工或规则系统审核。

3. 单次响应延迟必须 < 1 秒

一次 Agent Loop 至少需要 2 次 LLM 调用（一次决定动作，一次理解结果）。如果用 Claude Sonnet 这类较慢的模型，端到端延迟很难低于 2 秒。对延迟敏感的场景（如实时推荐），Agent 是反模式。

4. Token 预算敏感

Agent 循环每次失败都需要 retry，每次 retry 都消耗 token。一个典型的 ReAct Agent 解决 5 步任务的平均 token 消耗是