从语言模型到智能体：一场认知架构的范式转移

第 1 章：从语言模型到智能体——一场认知架构的范式转移

假设你面前有两个系统：一个是 GPT-4，另一个是一个用 50 行 Python 写出来的"小脚本"。当你说出"帮我订一家明天晚上适合四个人聚餐的餐厅"这句话时，谁更有可能真正帮你订到位置？答案会让 90% 的产品经理意外——GPT-4 大概率会输。因为这道题考察的根本不是"谁更聪明"，而是"谁拥有做事的结构"。这一章的全部任务，就是把这种"结构"拆开来看清楚：它是什么、为什么必要、为什么 2023 年之后才真正落地，以及如何用几十行代码亲手验证它的威力。

1.1 一个真实的对比实验：为什么 ChatGPT 不等于 Agent

在动手写任何代码之前，先做一个思想实验——不，思想实验不够，我们要的是"可执行的对比"。让我们把同一个任务分别交给两类系统，看看到底会发生什么。

1.1.1 任务定义

任务 T："明天晚上 7 点左右，我和三个朋友要在北京海淀区找一家适合四个人聚餐的餐厅。预算人均 200 元以内，最好有川菜或粤菜选择。请帮我完成预订，并把确认信息发给我。"

这是一个真实的、来自 Airbnb 产品经理朋友的需求。我们故意让它包含若干不确定维度：地理位置、菜系、价格区间、人数、时间，所有这些都需要外部信息才能闭环。

1.1.2 GPT-4 的回答（纯 LLM 模式）

直接把任务丢给 GPT-4 API（不使用任何 function calling、不挂载任何工具），它大概率会这样回复：

> "推荐以下几家海淀区适合四人聚餐的餐厅： > 1. 俏江南（海淀店）：人均约 180 元，川菜，地址在知春路… > 2. 点都德（海淀分店）：人均约 150 元，粤式茶点… > 3. 海底捞（中关村店）：人均约 120 元，火锅… > > 建议你通过大众点评或餐厅官方电话进行预订。建议提前 1-2 小时致电确认…"

注意它做了什么、没做什么：

• ✅ 给出了"听起来合理"的餐厅名字（其中至少 1-2 家可能根本不存在或者已关闭，俗称 LLM hallucination）。
• ✅ 提供了"听起来专业"的预订建议。
• ❌ 没有真正访问任何餐厅的可预订时段。
• ❌ 没有调用任何预订接口。
• ❌ 没有确认四人位是否还有空。
• ❌ 没有返回"确认号 / 预订凭证"。
• ❌ 没有在失败时（比如全订满）做出 Plan B。

这就是典型的 "Predict-then-Act" 模式——模型把"接下来应该发生什么"预测出来了，但预测不等于执行。LLM 是一台文字接龙机，它的输出是"在它的训练分布里最像答案的 token 序列"，而不是"对现实世界产生作用的动作序列"。

1.1.3 一个 50 行 Agent 的回答

我们把同样的任务交给一个会调用工具（tool-using）的 Agent。即使是一个非常简陋的版本，它的执行轨迹（trace）也会像下面这样：

``` Step 1 | Thought: 用户需要预订餐厅，我需要先知道海淀区有哪些合适的餐厅，且要检查可预订情况。 Action: search_restaurants(location="海淀", cuisine="川菜|粤菜", party_size=4, date="tomorrow 19:00") Observation: 返回 5 家候选餐厅及其评分、价位、营业时间。

Step 2 | Thought: 用户预算人均 200，需要筛掉超预算的。同时要检查四人位是否可订。 Action: filter_by_budget(candidates, max_per_person=200) Action: check_availability(restaurant_id="R_017", party_size=4, time="2024-05-22T19:00") Observation: R_017 在 19:00 有 4 人位剩余，R_022 显示满座。

Step 3 | Thought: R_017 满足所有约束（川菜、人均 180、可订 4 人位），直接预订。 Action: make_reservation(restaurant_id="R_017", party_size=4, time="2024-05-22T19:00", user_contact="...") Observation: 预订成功，确认号 #BX-94827。

Step 4 | Thought: 任务完成，把确认信息结构化返回给用户。 Final Answer: 已为你预订「俏江南·海淀知春路店」明天 19:00 的四人位，确认号 #BX-94827，人均 180 元。 ```

注意同样的语言模型（GPT-4）担任"大脑"，但被一个"感知-规划-行动-反思"的循环结构包裹起来之后，它获得了三种新能力： 1. 真实世界交互能力：能查询数据库、调用预订 API。 2. 状态持久能力：失败时（满座）会自动重新规划。 3. 可验证能力：每一步都基于真实 observation 而不是 hallucination。

这就是 Agent 的本质——它不是更聪明的 LLM，而是 把 LLM 放进了一个目标驱动的执行循环。

1.1.4 差异的可视化

```mermaid flowchart LR P1[User Prompt] --> P2[LLM Inference] --> P3[Text Response]

A1[Goal] --> A2[Perception] --> A3[Plan] --> A4[Action or Tool] --> A5[Observation] --> A6{Done?} A6 -->|No| A3 A6 -->|Yes| A7[Final Result] ```

上面是两种范式的核心差异：左边是一条直线（Predict-then-Act），右边是一个反馈回路（Perceive-Plan-Act-Reflect）。LLM 在两种范式里都存在，但 Agent 的关键不在"模型"，而在"回路"。这一章后面所有的内容——四要素、LLM-as-Brain、传统软件边界、技术成熟度曲线——都在回答同一个问题：这条回路是怎么搭起来的、为什么现在才搭得起来、它和传统软件有什么本质区别。

1.2 范式转移：从 Predict-then-Act 到 Perceive-Plan-Act-Reflect

1.2.1 经典定义：Russell & Norvig 的 Agent

要给 Agent 一个学术上站得住脚的定义，没有比 Russell & Norvig 的《Artificial Intelligence: A Modern Approach》更合适的来源。在他们看来：

> An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators.

翻译过来：Agent 就是任何能通过"传感器"感知环境，并通过"执行器"作用于环境的实体。注意这个定义其实不限定它是软件、机器人还是人类——你、我、一只猫、温控器，都是 Agent。这给了我们一个最宽松的概念框架。

现代 LLM Agent 显然是 Russell 定义的一个子集：它的"传感器"是文本/API 响应，它的"执行器"是工具调用。但仅仅停留在 Russell 的定义会过于宽泛——一个简单的 if-else 温控器也是 Agent。我们要更精细的模型。

1.2.2 四要素模型：感知-规划-行动-反思

回到 Yao 等人 2022 年那篇划时代的论文 *ReAct: Synergizing Reasoning and Acting in Language Models*。它第一次清晰地把 LLM Agent 的内部循环拆成了四个相互衔接的环节：

1. Perception（感知）

Agent 必须能从环境中提取出可用的信号。在 LLM Agent 里，"环境信号"通常有三类：

• **用户输入**：自然语言指令、对话历史。
• **工具返回值**：API 响应、数据库查询结果、网页抓取内容。
• **自身状态**：当前目标、已完成步骤、剩余资源（token、步数、时间）。

感知的关键不是"看到什么"，而是"看到哪些是有用的"。一个 50 行的 Agent 可能只关心工具返回的 JSON 中前 3 个字段；但一个 production-grade Agent 需要 schema 校验、噪声过滤、异常检测。

2. Planning（规划）

拿到感知数据后，Agent 需要决定"接下来做什么"。规划在 LLM Agent 中有三种典型形态：

| 规划形态 | 描述 | 典型实现 | |---------|------|---------| | ReAct | 边想边做，每步都重新规划 | ReAct paper, LangChain ReAct Agent | | Plan-and-Execute | 先一次性产生完整计划，再逐步执行 | Plan-and-Execute agents, BabyAGI | | Tree of Thoughts | 多路径并行探索，剪枝选优 | ToT paper, LangGraph |

对于"订餐厅"这种 3-5 步就能完成的任务，ReAct 最经济；对于"调研一份行业报告"这种需要 20+ 步的复杂任务，Plan-and-Execute 更稳定。规划层是 Agent "智能感"的主要来源——也是它和传统 RPA（Robotic Process Automation）的核心区别。

3. Action（行动）

规划产生决策，决策落到具体动作。在 LLM Agent 里，动作就是工具调用（tool calling）。这里要区分两个概念：

• **Tool**：Agent 可以调用的外部能力（搜索引擎、计算器、数据库、文件系统、第三方 API）。
• **Action schema**：调用工具的参数 schema，通常是 JSON 或 function-call 格式。

2023 年 OpenAI 在 GPT-3.5/4 中引入原生 function calling 是一个关键里程碑——它把"工具调用"从 prompt engineering（"请用 JSON 格式输出"）变成了模型原生能力，错误率从 ~30% 降到 ~5%。

4. Reflection（反思）

这是四要素里最容易被低估、却最关键的一环。反思解决的是"我做对了吗 / 我应该换个方法吗"。它的实现方式有三种：

• **Self-critique**：让 LLM 评估自己的输出（"这段回答是否逻辑自洽？"）。
• **External critique**：用一个 Judge Agent 或 reward model 来打分。
• **Environmental feedback**：现实世界的反馈（预订失败返回 404 → 换一家）。

没有反思的 Agent 容易陷入"自信地犯同样的错误"；有反思的 Agent 会自我修正，但代价是 token 消耗翻倍。这也是为什么 production Agent 通常会设计一个反思阈值——只在关键决策点反思，而不是每步都反思。

1.2.3 一个形式化表达

让我们用伪代码把四要素模型的形式化定义写出来，这样后面所有 Agent 实现都可以套用这个框架：

``` Agent(state): while not TerminationCondition(state): perception = Perception(state.environment) plan = Planning(state.goal, perception, state.memory) action = Action(plan, state.available_tools) observation = Environment.Step(action) state = Reflection(state, action, observation) return state.result ```

`state` 是 Agent 的内部状态，包含目标、记忆、剩余资源、已执行步骤。这个状态机的每一次循环都在问同一个问题："我离目标更近了吗？" 如果是，继续；如果不是，规划层就重新生成计划。这就是反馈回路（feedback loop）的威力——它让 Agent 不再是"一次性的预测器"，而是"持续逼近目标的控制器"。

1.3 LLM-as-Brain：语言模型为什么是天然的 Agent 大脑

把四要素模型落实，需要一个"推理核心"。过去 30 年 AI 做过多种尝试：基于规则的系统（expert system）、强化学习（DQN/PPO）、符号推理（Prolog）、概率图模型（Bayesian Network）……但 2023 年之后，几乎所有主流 Agent 框架（LangChain、AutoGen、CrewAI、LangGraph）都默认把 LLM 作为大脑。这不是偶然。

1.3.1 三个让 LLM 适合做 Agent 大脑的属性

1. 自然语言是通用的认知中间层（cognitive substrate）

传统 AI 系统的最大工程负担是"表示"——把现实世界翻译成机器能处理的结构化数据。这个翻译过程本身就要消耗 60% 的开发时间。LLM 的革命在于：它已经在人类语言这个最丰富的表示空间上预训练过了。任何任务——订餐、写代码、医学诊断——都可以先用自然语言描述，再让 LLM 在这个空间里推理。

这意味着任务定义的成本从"程序员写 schema"变成了"用户写一句话"。对于开放域任务，这是质的飞跃。

2. In-context learning 让"少样本工具使用"成为可能

LLM 不需要重新训练就能学会使用新工具，只要在 prompt 里给出工具描述和 few-shot 示例。这就是为什么一个 GPT-4 可以在同一次会话里既调用搜索引擎，又写 SQL，又生成图表——它通过上下文临时组装出了"如何使用这些工具"的知识。

相比之下，传统强化学习需要数千次 trial-and-error 才能学会一个新动作。LLM 把"学习新工具"的时间从几天压缩到几秒。

3. Chain-of-Thought 提供了可解释的推理路径

Agent 不能黑箱——我们必须知道它为什么做出某个决策。LLM 的 chain-of-thought（思维链）天然生成人类可读的推理步骤，这刚好满足 Agent 决策可审计的要求。这也是为什么 ReAct（Reasoning + Acting）会成为 Agent 范式的事实标准——它把推理和行动交织在一起，每一步都有迹可循。

1.3.2 LLM-as-Brain 的局限

把 LLM 当大脑并非没有代价。生产环境里至少有四个坑要避开：

• **幻觉（Hallucination）**：LLM 会编造不存在的 API、不存在的参数。必须有 schema 校验兜底。
• **上下文窗口限制**：再大的 context 也装不下长期记忆。需要外挂 vector store 或 memory module。
• **推理延迟**：一次 LLM 调用 200ms-2s，多步 Agent 任务的端到端延迟是用户难以接受的。
• **成本**：一次复杂 Agent 任务可能消耗 10k-100k tokens，$0.1-$2 不等。需要路由到不同模型（小模型做简单决策、大模型做关键决策）。

理解这些局限，比理解"LLM 能做什么"更重要——因为后者各家宣传都在讲，而前者决定了你的 Agent 能不能跑上线。

1.4 Agent 与传统软件：自主性 vs 可控性的张力

写到这里，一个工程师会立刻问：Agent 和传统软件到底有什么本质区别？ 毕竟传统软件也能调用 API、也能执行多步任务（比如一个订单处理的微服务）。这两者的边界在哪里？

1.4.1 一个判断框架：决策权的天平

我们可以沿着"决策权"这个维度画一根轴：

``` [传统软件] ←———————————————→ [完全自主 Agent] 决策权在程序员 决策权在系统 (compiled logic) (learned / inferred) ```

传统软件：所有可能的情况都被程序员预定义。`if user_age >= 18: ...` 是硬编码的。它极度可控，但极其脆弱——遇到没预见到的情况就崩。

完全自主 Agent：系统自己决定每一步做什么。基于 LLM 的 Agent 在 prompt 边界内是"自由"的——你无法预测它在某个具体输入下会走哪条路径。

真实系统几乎都落在中间。一个 production-grade Agent 框架会刻意设计"可控性锚点"：

• **受控的工具集**：只允许调用注册过的 5 个工具，不允许任意代码执行。
• **受控的 prompt 模板**：核心指令被严格锁定，用户只能在限定 slot 注入。
• **受控的输出校验**：每个工具调用都过 schema 校验，违规直接拒绝。
• **审计日志**：每一步 thought / action / observation 都被持久化，便于回溯。

1.4.2 自主性的代价：非确定性

传统软件的核心承诺是确定性：同一份输入，永远得到同一份输出。这让单元测试、回归测试、回放调试成为可能。

Agent 的核心承诺是通用性：用一套架构应对开放任务。但代价是非确定性——同一个 prompt，今天和明天可能走出两条不同的执行轨迹。

这给工程化带来了真实挑战。一个生产可用的 Agent 团队通常需要：

• **轨迹重放（trace replay）**：把生产环境跑过的轨迹在 staging 重放，验证修复有效。
• **A/B 测试**：不同 prompt 版本、不同模型版本在真实流量上对比