觉醒的序章：从大模型到智能体

觉醒的序章：从大模型到智能体

凌晨两点十七分，深圳南山区科技园的一间办公室里，屏幕的蓝光打在陈昊的脸上。他盯着眼前的监控仪表盘——CPU 使用率 12%，内存正常，请求响应时间 87 毫秒。一切看似平稳。然而他知道，真正的危机不在屏幕上。

一个月前，他和合伙人创办的「灵犀科技」推出了一款基于大模型的客户支持助手。第一周，数据漂亮得让人眩晕：响应速度比人工快 40 倍，客户满意度从 78% 跳到 91%。投资人发来贺电，三个 VC 的 Term Sheet 当天就到了邮箱。

但从第二周开始，问题像地下水一样渗透出来。

用户问"我的订单为什么还没到？"，助手答得头头是道："通常情况下，物流延迟可能由多种原因导致……"——唯独不去查订单系统。用户问"能帮我改一下配送地址吗？"，助手说"请联系人工客服"，然后结束对话。用户问"上个月我退的那件衣服退款到账了吗？"，助手回答"根据公开信息，退款通常在 3–5 个工作日内到账"——可真实的退款状态就在它的指尖能触及的数据里。

陈昊坐在会议室的白板前，画了一张图：左边是一根直线，代表"用户提问 → LLM 回答 → 对话结束"；右边是一个圆环，代表"用户提出目标 → Agent 持续行动 → 目标达成"。他在圆环正中心写下三个字：自主决策。

那一刻，他知道自己的产品需要一次彻底的蜕变——从"问答工具"变成"能够自主完成任务的数字员工"。这不是一次版本号的迭代，而是一次物种的进化。

这个故事，正是本书要回答的核心问题：究竟什么是 AI 智能体？它和普通的大模型应用有何本质区别？

---

为什么 LLM 不等于 Agent？——传统 Prompt 模式的根本局限

在开始定义「Agent」之前，我们有必要先看清楚被它所超越的那个东西。

2022 年底，ChatGPT 横空出世，几乎所有人都在做同一件事：把一个强大的大语言模型（LLM）塞进产品里。做法也基本一致——前端收集用户输入，拼接进一个精心设计的 prompt，后端调用 LLM API，把回答吐回前端。这就是「Prompt + LLM」模式，它统治了过去两年绝大多数 AI 产品的形态。

但只要运营过这种产品，你迟早会撞上三堵墙。

第一堵墙：一问一答的单次交互结构。 Prompt + LLM 模式本质上是「无状态」的——每一次请求对模型来说都是孤岛。你问"我上周定的咖啡机呢？"，模型根本不知道"上周"对它意味着什么，它没有对话历史，没有用户档案，没有订单系统访问权。你就算把上下文塞进 prompt，也只能塞进去几段文字，远远不够承载一个完整的业务流程。

第二堵墙：模型只能"说"，不能"做"。 当用户问"把发货地址改成上海市浦东新区张江路 88 号"，模型给出的最佳回答永远是"建议联系人工客服修改"。它愿意改、知道怎么改、给得出正确的 SQL 语句——但它没有改的权限。在软件架构里，这叫「只读权限」；在产品逻辑里，这叫"美丽的废话"。

第三堵墙：没有"目标"概念。 LLM 的核心能力是「给定上文，预测下一个 token」。它对"目标是否已经达成"没有任何内生的判断机制。你让它写一篇 3000 字的文章，它可以写到第 500 字就戛然而止；让它解一道数学题，它可以在最后一步计算出错但依然自信地说"答案是 42"。这不是"懒"，这是它的本质属性。

把这三堵墙叠在一起看，我们就看清楚了 Prompt + LLM 模式的本质：它是一个"语言接龙高手"，但不是一个"任务执行者"。

而 Agent 之所以被称为"智能体"，正是因为它把上面三个短板逐一拆掉了。它不再是「回答问题的机器」，而是「带着目标去行动的实体」。

---

Agent 的定义与四大特征：自主性、反应性、主动性、社会性

要给 Agent 下定义并不容易。这个词从 1970 年代的人工智能教科书里一路走来，在不同时代被赋予了不同的内涵。我们这一轮浪潮中谈的 AI Agent，可以从能力特征角度归纳为四件事：自主性、反应性、主动性、社会性。这四个特征来自经典 AI 理论，但在 2024 年前后的大模型语境下被赋予了全新的实现方式。

自主性：你的智能体拥有"自己做决定"的权力

自主性（Autonomy）指的是 Agent 能够在没有人类逐步指令的情况下，自主决定要做什么、怎么做。它不是机械地执行预设脚本，而是能根据当前状态选择下一步动作。

举个具体的例子。一个传统 chatbot 收到"查一下我上周买的东西有没有到货"，它执行的是开发者写死的流程：识别意图 → 调用订单接口 → 渲染结果。而一个具备自主性的 Agent 收到同样的问题时，会自己判断：第一步要不要先查订单？订单里有没有物流单号？有没有物流单号要不要去调物流接口？用户问的是单一订单还是全部订单？——这些问题，开发者没有替它写死，它自己决定。

自主性背后，是 Agent 拥有「选择行动空间」的能力。它手里有一组工具（Tool），它可以根据目标自行决定调用哪一个、以什么顺序。

反应性：对环境变化做出实时响应

反应性（Reactivity）强调 Agent 能感知环境变化并做出及时反应。这里的"环境"，可能是用户的实时输入、工具的返回结果、外部系统的状态变化，也可能是另一个 Agent 的消息。

对比来看：传统程序是"事件驱动"的——来了请求就处理，不来就睡觉。Agent 也是事件驱动的，但它的"事件类型"更丰富。它不仅响应用户的输入，还响应工具返回错误、文件内容发生变化、定时器到期等等。

这种反应性听起来平平无奇，但它是 Agent 能"持续运行"的核心前提。一个没有反应性的系统只能跑一条预设的主线；一个具备反应性的系统能在意外来临时调整轨道。

主动性：不仅"响应"还要"主动推动"

主动性（Pro-activeness）是反应性的"升级版"。反应性是"环境变了，我动"；主动性是"我看到机会，我自己动"。

举例来说：一个反应式的 Agent 会在用户问"我账户里的钱够吗？"时去查账户余额。一个主动式的 Agent 会在用户还没问的时候，先观察到"用户本月信用卡还款日是明天，而账户余额不足"，主动发一条提醒："检测到您的账户余额不足以覆盖明天的信用卡还款，建议今天充值。" 它主动采取了行动，而不是被动等指令。

主动性的实现依赖于 Agent 对"长期目标"的理解——它不仅知道用户当前的问题是什么，还知道用户在更长时间尺度上关心什么（保持账户健康、不超支、按期还款……），从而提前布局。

社会性：和其他 Agent 或人类协作

社会性（Social Ability）指的是 Agent 能与其他 Agent（或者人类）通过某种"通信语言"交互，协商、协作甚至竞争完成任务。

在 Multi-Agent 系统中，这一点体现得最明显。比如一个软件开发团队 Agent 系统里，可能有"产品经理 Agent"、"架构师 Agent"、"程序员 Agent"、"测试 Agent"。产品经理 Agent 提出需求，架构师 Agent 评估可行性，程序员 Agent 写代码，测试 Agent 跑用例——它们通过结构化消息互相协作，最终交付一个完整的产品。

社会性是 2024 年 Agent 领域的最大变量。它把 Agent 从"单体智能"推向了"群体智能"的范式。

把这四个特征放在一张表里会更清晰：

| 特征 | 核心问题 | 典型表现 | | --- | --- | --- | | 自主性 | 该做什么、怎么做？ | 自己选择工具、规划步骤 | | 反应性 | 环境变了怎么办？ | 根据工具返回调整下一步 | | 主动性 | 还有什么该做？ | 主动提醒、主动预判 | | 社会性 | 和谁一起做？ | 多 Agent 协作、消息通信 |

值得注意的是，这四个特征并不是非黑即白的开关，而是程度上的差异。一个简单的 Query Agent 可能只有少量自主性、几乎无主动性；而一个复杂的 Multi-Agent 系统则在四个维度上都有较高表现。正是这四个特征在"度"上的跃迁，让 Agent 区别于普通的 LLM 应用。

---

从"一次问答"到"持续行动"：Perceive-Think-Act 循环

如果说四个特征是 Agent 的"质"，那么 Perceive-Think-Act 循环就是 Agent 的"形"。

任何运行中的 Agent，你都可以把它抽象成这三个动作的循环往复：

1. Perceive（感知）：Agent 从环境中读取信息。环境可能是用户的对话、工具的返回值、数据库的内容、另一个 Agent 发来的消息，甚至是时钟触发的"伪环境"。 2. Think（思考）：Agent 基于感知到的信息，决定下一步要做什么。这里的 Think 通常由 LLM 完成，它读懂目标、判断状态、规划子任务。 3. Act（行动）：Agent 把"想清楚的事"变成具体的动作——调用一个工具、写一段代码、发送一条消息，或者抛出一个结构化的 JSON 给上游调度器。

一个动作完成后，环境发生了变化，Agent 又进入下一轮 Perceive → Think → Act。这个循环一直持续到 Agent 判断"目标已经达成"或者"无法继续"为止。

我们用一张图把这个循环画出来：

```mermaid flowchart LR Env[Environment] --> P[Perceive] P --> T[Think] T --> D{Target\nachieved?} D -- No --> A[Act] A --> Tools[Tools /\nMemory /\nOther Agents] Tools --> Env D -- Yes --> End[Stop] ```

这张图看起来简单，但它隐含了几个关键设计点：

第一，循环是有终点的。 不是所有 Agent 都要永远跑下去——Target achieved 节点决定了它何时终止。一个没有终止条件的 Agent 会陷入无限循环，把 LLM 配额烧光。一个好 Agent 必须能识别"这事我做完了"。

第二，每一轮 Think 都依赖 LLM，但不一定都调用最强模型。 在一个生产级 Agent 系统里，简单的"我下一步该调哪个工具"判断可以用小模型甚至规则引擎，复杂的"用户这段话到底想表达什么"才交给 GPT-4 或 Claude。这种分层模型调度是控制成本的关键——我们会在第 7 章详细展开。

第三，工具调用（Tool Call）是 Act 的核心载体。 大模型本身不善于精确计算、不善于访问实时数据、不善于执行写操作。Agent 通过调用外部工具把这些短板补齐。可以说：LLM 是 Agent 的大脑，Tools 是 Agent 的手脚。 二者缺一不可。

第四，记忆（Memory）让循环有"上下文连续性"。 没有记忆的 Agent 每轮都是失忆的——它不知道之前尝试过什么、失败在哪里。一个合格的 Agent 必须有短期记忆（当前任务的中间结果）和长期记忆（跨任务的用户偏好、历史行为）。这也是 Agent 和"单次 LLM 调用"最直观的区别。

把 Perceive-Think-Act 循环再升一个维度，我们可以把它和「思维链（Chain of Thought）」区分开。思维链是 LLM 内部的一次性推理：拿到 prompt → 在内部"自言自语"一番 → 输出答案。Perceive-Think-Act 循环是 Agent 外部的多次迭代：每一轮都会和环境发生真实的交互，而不是只在脑子里空想。真正的智能不是想出来的，是干出来的——这个观点，是 Agent 范式的灵魂。

---

三种范式的边界：Agent vs Workflow vs RAG

谈到 Agent，一个绕不开的争议是：它和工作流（Workflow）、RAG（Retrieval-Augmented Generation）到底什么关系？

这是初学者最容易混淆的地方——很多人把"接入 LLM 的业务流程"统统叫 Agent，结果在选型时一脸茫然。我们来一次彻底厘清。

RAG 是"给模型配一本外置字典"

RAG 的核心动机只有一个：弥补 LLM 的知识滞后和幻觉问题。它的工作流是：用户提问 → 把问题向量化 → 去向量数据库里找相关文档 → 把文档和问题拼成 prompt → 喂给 LLM → LLM 基于这些真实文档生成回答。

RAG 不做"决策"——它只是给 LLM 提供了"参考资料"，然后让 LLM 基于这些资料回答。它没有工具调用能力（除了检索），没有循环，没有目标概念。

适用场景：问答系统、客服 FAQ、企业知识库、文档摘要。

Workflow 是"流程编排器"

Workflow 在大模型时代之前就已经存在——它是软件工程里的"流程图"。在大模型语境下，Workflow 通常指用代码编排好步骤，部分步骤交给 LLM 处理的系统。

典型例子：一个内容生成工作流可能是这样的： 1. 用户输入主题 2. 调用 LLM 生成大纲 3. 调用 LLM 根据大纲写第一段 4. 人工审核 5. 调用 LLM 根据大纲写第二段 6. 合并输出

每一步是固定的，但具体"写哪句话"由 LLM 决定。这不是 Agent，因为 LLM 没有"下一步该干啥"的选择权——流程是工程师写死的。

适用场景：结构清晰的任务，每个子任务有明确输入输出。

Agent 是"把决策权下放给 LLM"

而 Agent 把 Workflow 里的"流程决策权"也一并交给了 LLM。Agent 不再是"脚本里某一步调用 LLM"，而是"LLM 决定整个调用序列"。

二者的根本差异可以用一句话概括：Workflow 是"代码编排 LLM"，Agent 是"LLM 编排工具"。

| 维度 | RAG | Workflow | Agent | | --- | --- | --- | --- | | 核心动作 | 检索增强 | 步骤编排 | 自主决策循环 | | 工具调用 | 仅检索 | 按脚本调用 | 按需调用 | | 循环结构 | 无 | 一般无 | 必备 | | 决策主体 | LLM 生成 | 工程师预设 | Agent 自身 |

但这并不意味着我们要在三者之间二选一。实际产品中，RAG 经常作为 Agent 感知阶段的一部分；Workflow 可以作为复杂 Agent 的高层框架——比如一个 Multi-Agent 系统本身就是一个 Workflow，只不过每个节点换成了 Agent。它们不是替代关系，而是不同抽象层次的组合。

一个简单的判断标准可以帮你选型：任务是否需要"动态决策"？如果所有路径都能提前画出来，用 Workflow；如果有大量分支和意外，让 Agent 处理。 当然，二者结合往往是更现实的方案。

---

2023—2024 Agent 发展脉络：从 Toolformer 到 AutoGPT 到 Multi-Agent

要在产品里用好 Agent，仅仅理解概念不够，还需要看清它走过的路。下面这条脉络上的每一个节点，都对应着 Agent 范式的一次跃迁。

2023 年初：Toolformer —— 让模型学会"用工具"

2023 年 2 月，Meta 发布 Toolformer。这篇论文的核心贡献是用自监督的方式让 LLM 学会在生成文本时插入工具调用。比如模型遇到"特朗普出生在哪一年"时，会自动插入一个 Wikipedia 查询动作，把真实答案填进来。

Toolformer 第一次把"工具调用"从人类硬编码的 prompt 中解放出来——模型自己决定何时调用工具、调什么工具。这是 Agent 的早期萌芽。

2023 年中：ReAct —— 让模型学会"边想边做"

2023 年 6 月，Princeton 和 Google 的研究者发布 ReAct（Reasoning + Acting）框架。这个范式的核心是让 LLM 在每一步既输出"想法"（Thought），也输出"动作"（Action），然后根据动作的返回（Observation）继续下一步。

ReAct 的精髓在于：让模型的推理过程外化成可观测、可调试、可干预的步骤。 这比让模型在内部"自言自语"（Chain of Thought）更可控，也更容易和外部工具对接。

ReAct 范式今天几乎成了 Agent 框架的事实标准。LangChain、LlamaIndex、BabyAGI 等几乎所有主流框架的内部循环，本质上都是 ReAct 的变体。

2023 年下半年：AutoGPT 与 BabyAGI —— 让 Agent 自己"立目标"

2023 年 4 月，Significant Gravitas 发布了 AutoGPT。它的标志性创新是：让 Agent 自己拆解长期目标。 用户输入一个宏大目标（"帮我创立一个在线 AI 课程"），AutoGPT 会自己拆出子目标（"研究竞品"、"写课程大纲"、"找讲师"、"定价"……），逐项推进。

AutoGPT 引发了 Agent 热潮，但也很快暴露了问题：自主性极强的 Agent 容易"跑偏"、"无限循环"、"代价失控"。但它证明了自主规划这个方向是可能的。

同期出现的 BabyAGI 做了类似探索，但更轻量、更稳定。

2024 年：Multi-Agent 协作 —— 从"单体智能"到"群体智能"

进入 2024 年，Agent 的下一个自然演进是把多个 Agent 组织起来。代表项目包括：

• **AutoGen（Microsoft）**：提出"对话即编程"，用多 Agent 对话来完成复杂任务。
• **CrewAI**：基于"角色扮演"的多 Agent 框架，每个 Agent 有明确分工。
• **ChatDev（OpenBMB）**：模拟一家虚拟软件公司，让 PM、程序员、测试员等 Agent 协作开发软件。
• **MetaGPT**：引入了"SOP（标准作业流程）"作为多 Agent 协作的骨架。

Multi-Agent 系统让"社会性"这个特征真正落地。它也带来新问题：通信开销、共识机制、错误传播——这些会是后续章节要讨论的。

2024 年下半年至今：Agent + 工作流的融合

2024 年下半年开始，整个行业出现一个明显的回归信号：纯自主 Agent 在生产环境里并不稳定，主流框架开始引入更多的"控制"。比如 LangGraph 强调图结构的状态机、AutoGen 加入可控的工作流、Anthropic 提出