AI Agent 基础概念全景：从 LLM 本质到架构模式与关键挑战

⚠️ 重要：本文包含 LLM 本质与 Token 原理、Agent 核心概念与 ReAct 模式、四种 Agent 架构模式（Router / Tool-calling / Multi-Agent / Hierarchical）、Agent 开发六大关键挑战（幻觉、成本、延迟、工具可靠性、安全护栏、上下文限制）。

文中涉及的相关代码示例地址：https://github.com/m12305/Langchain-LangGraph-agent — Langchain/LangGraph 学习项目
相关项目推荐：https://github.com/m12305/hello-FastAPI — FastAPI 学习项目

在动手构建 Agent 之前，必须回答三个核心问题：LLM 的本质是什么？Agent 凭什么比纯 LLM 强？不同场景该选什么架构？本文从底层原理到上层架构，一次性讲透。

---

一、LLM 的本质：下一个 Token 预测器

1.1 LLM 到底在做什么？

所有 LLM（GPT-4o、Claude、Gemini……）本质上做的是同一件事：给定前面的文本，预测下一个最可能出现的 Token。

输入:  "今天天气真"
  ↓ LLM 计算每个可能 token 的概率分布
输出概率: "好" (0.42)  "热" (0.18)  "不" (0.12)  "冷" (0.08) ...
  ↓ 根据 temperature 采样
输出: "好"

LLM 并不是真正"理解"了你的问题——它是在统计意义上做概率预测。理解这一点，是理解幻觉、Prompt Engineering、上下文窗口等一切后续概念的地基。

1.2 Token 化：LLM 的最小处理单位

Token 既不是单词，也不是字符，而是介于两者之间的"语言原子"：

事实	说明
英文 ~0.75 词 = 1 token	“The weather is nice” ≈ 5 tokens
中文 ~0.5–1 字 = 1 token	分词效率低于英文
常见词 = 1 token	“the”、“is”、“hello” 各自是一个 token
罕见词 > 1 token	专业术语可能被拆分为多个 token
上下文窗口 = Token 预算	GPT-4o: 128K, Claude 3: 200K, Gemini: 1M+

⚠️ 硬限制：每次调用，input + output 都必须在上下文窗口内。超出的部分必须裁剪——这是 Agent "失忆"的根源。

1.3 自回归生成：一个 Token 接一个 Token

Step 1: "法国"  → 模型计算 → 输出 "的"
Step 2: "法国的" → 模型计算 → 输出 "首"
Step 3: "法国的首" → 模型计算 → 输出 "都"
Step 4: "法国的首都" → 模型计算 → 输出 "是"
Step 5: "法国的首都是" → 模型计算 → 输出 "巴黎"
...直到遇到 <|endoftext|> 停止

每个 Token 的生成都依赖于之前所有的 Token——正因为如此：

• 模型不能"跳回去修改"已生成的内容
• 一个错误会连锁影响后续输出
• 流式输出天然适合（因为本就是逐 Token 生成的）

Temperature 的控制就在这个环节起作用：贪婪解码（temperature=0）每次都选概率最高的 Token，输出确定但缺乏变化；概率采样（temperature=0.7）从概率分布中随机选取，输出更丰富但也可能不连贯。

1.4 LLM 的能力与局限

局限	说明	Agent 中的应对
幻觉	编造不存在的事实	RAG 检索验证、工具调用
无状态	不记得之前的对话	记忆管理
无外部知识	只知道训练数据	工具调用
Token 窗口有限	不能无限塞上下文	上下文工程
推理链断裂	复杂推理可能出错	LangGraph 结构化编排
无法行动	只能输出文本	Agent 工具调用

这就是为什么需要 Agent：LLM 是"大脑"，但它没有眼睛（不能搜索）、没有手（不能执行）、没有记忆（不记得你）。Agent = LLM + 工具 + 记忆 + 决策循环。

---

二、Agent 核心概念：从 ReAct 到 Tool-use

2.1 什么是 Agent？

Agent (智能体) = 一个能够自主感知环境、推理决策、执行行动以完成目标的 AI 系统。

普通 LLM 调用和 Agent 的本质区别：

普通 LLM 调用:
  用户 → 提问 → LLM → 回答 → 结束
  (单轮, 无工具, 无记忆, 无决策)

Agent:
  用户 → 提问 → LLM分析 → 决定用哪个工具 → 调用工具
       → 观察结果 → 继续推理 → 可能再用工具
       → ... 循环 ... → 最终回答 → 结束
  (多轮, 有工具, 有记忆, 有决策)

2.2 Agent 的核心三要素

         ┌──────────────────┐
         │     大脑 (LLM)    │  ← 推理引擎：分析·规划·决策
         └──────┬───────────┘
                │
    ┌───────────┼───────────┐
    ▼           ▼           ▼
┌───────┐  ┌───────┐  ┌───────┐
│ 工具   │  │ 记忆   │  │ 规划   │
│ 搜索、API │  │ 短期、长期 │  │ 拆解、编排 │
│ 代码、数据 │  │ 对话、知识 │  │ ReAct、P&E │
└───────┘  └───────┘  └───────┘

要素	作用	为什么不可或缺
大脑 (LLM)	理解指令、推理、决策	没有大脑，Agent 就是空壳
工具 (Tools)	与外部世界交互	没有工具，LLM 永远活在训练数据里
记忆 (Memory)	记住历史、积累知识	没有记忆，每次对话都是"第一次见面"
规划 (Planning)	拆解任务、编排步骤	没有规划，复杂任务无从下手

2.3 ReAct 模式 —— Agent 的经典范式

ReAct = Reasoning + Action，是 AI Agent 最经典的运行模式。它定义了一个无限循环：

┌──────────────────────────────────────────────┐
│                  ReAct 循环                    │
│                                               │
│   ┌──────────┐     ┌──────────┐              │
│   │  THOUGHT │────▶│  ACTION  │              │
│   │  思考     │     │  行动     │              │
│   └──────────┘     └──────────┘              │
│         ▲                │                    │
│         │                ▼                    │
│         │          ┌──────────┐              │
│         │          │OBSERVATION│              │
│         │          │  观察     │              │
│         │          └──────────┘              │
│         │                │                    │
│         └────────────────┘                    │
│            (循环直到得到最终答案)               │
└──────────────────────────────────────────────┘

一个真实的 ReAct 执行过程：

用户: "帮我查一下 OpenAI 最新发布的模型，并和 GPT-4 做个对比"

🤔 思考: 用户想知道最新模型，我需要搜索
🔧 行动: web_search("OpenAI latest model 2025")
👁️ 观察: "OpenAI 发布 GPT-5，支持多模态..."

🤔 思考: 现在需要 GPT-4 的规格做对比
🔧 行动: web_search("GPT-4 specifications parameters")
👁️ 观察: "GPT-4: 1.76万亿参数..."

🤔 思考: 信息足够了，可以制作对比表格
💬 最终回答: (生成对比表格)

2.4 Tool-use / Function Calling —— Agent 的"手"

现代 LLM 的 Function Calling 机制让 Agent 真正获得了行动能力：

1. 你告诉 LLM：“你有一个 get_weather(city) 工具”
2. LLM 分析用户输入后，不输出文本，而是输出一个 JSON：{"name": "get_weather", "arguments": {"city": "北京"}}
3. 你的代码执行该函数，把结果返回给 LLM
4. LLM 基于结果生成最终回复

从 2022 年手写 ReAct Prompt + 正则解析，到 2024 年原生支持并行多工具调用 + 流式混合模式，Tool-use 的演进是 Agent 走向成熟的核心推动力。

2.5 自主 Agent vs 辅助 Agent

辅助 Agent (Copilot) ────────────自主性增加────────────→ 自主 Agent (Autonomous)
  人类主导决策，Agent 提供建议                             Agent 自主决策并执行
  例: GitHub Copilot                                    例: AutoGPT 自规划自修正
  风险低，效率提升有限                                    效率高，但需要安全护栏

维度	辅助 Agent	自主 Agent
决策者	人类	Agent
风险	低	需要护栏
Human-in-the-Loop	默认嵌入	需显式设计
适用场景	代码辅助、写作辅助	自动化工作流、智能客服

---

三、四种 Agent 架构模式与选型指南

3.1 架构全景图

复杂度 ↑
 │
 │    ┌──────────────────────────────┐
 │    │  Hierarchical Agent          │  ← 企业级: 层级委派
 │    │  (管理者 → 专家 Agent)        │
 │    ├──────────────────────────────┤
 │    │  Multi-Agent Collaboration   │  ← 团队协作: 多Agent对话
 │    │  (Agent A ⇄ Agent B ⇄ Agent C)│
 │    ├──────────────────────────────┤
 │    │  Tool-calling Agent          │  ← 核心: ReAct + 多工具
 │    │  (LLM 自主选择工具)           │
 │    ├──────────────────────────────┤
 │    │  Router Agent                │  ← 入门: 按意图分发
 │    │  (意图识别 → 分发)            │
 │    └──────────────────────────────┘

3.2 Router Agent（路由型）—— 入门级

核心思想：识别用户意图 → 路由到对应的处理逻辑。本质是一个分类器。

用户输入 "我想退货"
    │
    ▼
┌──────────┐
│ 意图分类  │ ← LLM: 这是售后类问题
└────┬─────┘
     │
┌────┼────┬────┐
▼    ▼    ▼    ▼
售前  售后  技术  投诉
Agent Agent Agent Agent

• ✅ 适用：智能客服、意图分发、低延迟场景
• ❌ 不适用：复杂多步骤任务、需要动态工具调用的场景

3.3 Tool-calling Agent（工具调用型）—— 最核心

这是最常用的 Agent 架构。LLM 自主决定：要不要用工具、用哪个工具、传什么参数。

from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI

tools = [get_weather, web_search, calculator]
llm = ChatOpenAI(model="gpt-4o")
agent = create_react_agent(llm, tools)

result = agent.invoke({
    "messages": [{"role": "user", "content": "北京今天天气如何？"}]
})

工具调用的决策流：

用户输入 → LLM 分析 Prompt + 可用工具列表
  ├── 不需要工具 → 直接输出文本回复
  └── 需要工具 → 输出 tool_call JSON
                    → 执行工具函数
                    → 结果返回 LLM
                    ├── 信息够了 → 输出最终回复
                    └── 信息不够 → 再调用工具 (循环)

3.4 Multi-Agent（多智能体协作）—— 团队级

多个专业 Agent 各自独立运行，通过消息传递协作完成复杂任务。

两种模式：

模式	原理	优点	缺点
Supervisor（调度者）	一个调度 Agent 分配任务给 Worker	可控、有序	单点瓶颈
Swarm/Peer（去中心化）	Agent 之间直接通信，谁空闲谁接	弹性、无单点	协调复杂

典型 Supervisor 模式:
  用户: "写一份产品发布会PPT，包括市场分析和产品介绍"
                    │
              ┌─────┴─────┐
              │ Supervisor │ ← 调度者
              └──┬─────┬──┘
         ┌───────┘     └───────┐
         ▼                     ▼
  市场调研 Agent          内容撰写 Agent
  (工具: web_search)      (工具: 文档生成)
         │                     │
         └─────────┬───────────┘
                   ▼
              审核 Agent ← 质量把关
                   │
                   ▼
              最终 PPT 输出

3.5 Hierarchical Agent（层级型）—— 企业级

将复杂任务层层拆解，上层 Agent 将子任务委派给下层 Agent，形成树状结构。

              CEO Agent ← 顶层: "写市场分析报告"
             /    |    \
    调研总监    分析总监    撰写总监
    /    \        |        /    \
  搜索  爬虫   统计分析   排版  润色

与 Supervisor 模式的区别：Supervisor 是2 层扁平协作，Hierarchical 是树状多层委派。

3.6 选型决策树

1. 任务是否单一明确？
   Yes → Router Agent
   No  → 继续

2. 是否需要外部工具 (搜索、API、数据库)?
   Yes → Tool-calling Agent (ReAct)
   No  → 可能不需要 Agent，普通 Chain 就够了

3. 任务是否太大，单一 Agent 处理不了?
   Yes → 继续
   No  → Tool-calling Agent 就够了

4. 子任务是否可以独立并行?
   Yes → Supervisor Multi-Agent
   No  → 继续

5. 任务是否有多层级依赖?
   Yes → Hierarchical Agent

场景	推荐架构	原因
智能客服	Router Agent	意图明确，分发简单
个人助手 (可搜索)	Tool-calling Agent	需要工具 + 灵活决策
研究报告生成	Supervisor Multi-Agent	调研+分析+撰写协作
企业工作流自动化	Hierarchical Agent	复杂多层任务
代码生成助手	Tool-calling Agent	需要执行代码、读文件

---

四、Agent 开发的六大关键挑战

4.1 全景总览

┌───────────┐  ┌───────────┐  ┌───────────┐
│   幻觉     │  │  推理成本  │  │   延迟     │
│  编造事实  │  │  Token 巨大│  │  用户等不了│
│  ⚠️⚠️⚠️    │  │  ⚠️⚠️      │  │  ⚠️⚠️      │
└───────────┘  └───────────┘  └───────────┘

┌───────────┐  ┌───────────┐  ┌───────────┐
│ 工具可靠性 │  │  安全护栏  │  │ 上下文限制 │
│ 选错/死循环│  │  执行危险  │  │ 窗口不够用 │
│  ⚠️⚠️      │  │  ⚠️⚠️⚠️    │  │  ⚠️        │
└───────────┘  └───────────┘  └───────────┘

4.2 幻觉 (Hallucination) — ⚠️⚠️⚠️ 致命

幻觉不是 bug，是 LLM 的固有特性。四种常见形态：

1. 事实捏造：“2025 诺贝尔奖得主是张三”——完全胡编
2. 引用虚构：引用不存在的论文、书籍、法律条文
3. 数字虚构：“全球有 3,847 家 AI Agent 公司”——看起来很精确，实际是编的
4. 过度自信：即使简单数学也可能在特定 temperature 下出错

核心应对策略：

策略	原理
RAG (检索增强)	先从知识库检索事实，再生成回答
工具调用	让 LLM 调用 API 获取实时数据而非猜测
低 Temperature	减少随机性，降低幻觉概率
Grounding	要求 LLM 引用来源，让编造无处遁形
Human-in-the-Loop	金融、医疗等关键决策由人审核

4.3 推理成本 — ⚠️⚠️ 严重

Agent 为什么贵？因为它不是一次 LLM 调用，而是多次：

普通 LLM: 1 次调用 → ~$0.01
Agent:   5-10 次调用 + 多次工具调用 → ~$0.05-0.15
Agent "迷路" (无限循环): 50 次调用 → ~$1.50 且无结果！

成本控制三板斧：

1. 设置最大步数：config = {"recursion_limit": 10}，防止无限循环
2. 模型分级：规划用强模型（GPT-4o），摘要/分类用弱模型（GPT-4o-mini）
3. 缓存重复查询：同一搜索 query 不重复调用 API

4.4 延迟 — ⚠️⚠️ 严重

典型 Agent 调用时间分布：

1.5s  第一次 LLM 调用 (思考)
0.8s  工具 1 (搜索)
1.2s  第二次 LLM 调用 (分析)
1.5s  工具 2 (API 调用)
2.0s  第三次 LLM 调用 (生成回答)
─────────────────────────
~7s  用户等得很焦虑

优化策略：

• 流式 + 状态提示：让用户看到进度（“🤔 正在分析…” → “🔍 正在搜索…” → “💬 正在生成…”），降低感知延迟
• 并行工具调用：能同时做的绝不串行——asyncio.gather(search_a, search_b)
• 流式响应 + 渐进式呈现：不等 Agent 完全结束，先展示中间结果

4.5 工具调用可靠性 — ⚠️⚠️ 严重

六种常见故障模式：

问题	示例	后果
选错工具	想搜索却调了计算器	得到无关结果
参数格式错误	get_weather("")	API 报错
参数幻觉	get_weather("北境")	API 返回空
死循环	查 A → 不满意 → 再查 A → 还不满意 → …	浪费 Token
过早放弃	查了 1 次没结果 → 告诉用户"不知道"	不该放弃的放弃了
结果误读	把 JSON 的 A 字段当 B 字段	错误回答

提升可靠性的核心方法：

# 1. 工具描述写清楚——这是最关键的一步
def search(query: str) -> list[dict]:
    """搜索互联网获取最新信息。用于查找实时数据、新闻、事实。
    参数: query - 使用关键词，不超过 100 字。英文搜索效果更好。
    返回: 最多 5 条结果，每条含 title, snippet, url。
    """

# 2. 工具返回结构化 + 友好的错误信息
# 3. 设置最大工具调用次数
# 4. 在 Agent 输出前加校验节点

4.6 安全护栏 — ⚠️⚠️⚠️ 致命

Agent 比普通 LLM 更危险，因为它真的可以执行操作：

危险场景:
  用户: "帮我清理 /tmp 目录下的临时文件"
  Agent: "好的" → ShellTool("rm -rf /tmp/*")  ❌

  用户: "帮我给所有客户发邮件"
  Agent: "好的" → email_api(send_to="all_customers")  ❌

四道防线：

1. 工具白名单：安全工具随便用，危险工具（shell、email_send、db_write）需审批
2. 参数校验：过滤 rm -rf、format 等危险模式
3. Human-in-the-Loop：关键操作（发邮件、删数据）必须人工确认
4. 内容安全过滤：拦截越狱、Prompt 注入等攻击

4.7 上下文窗口限制 — ⚠️ 中等

Agent 对话越长，上下文占用越多——最终超出窗口 → 必须裁剪 → Agent “失忆”。

应对策略	原理
对话摘要	定期将长对话压缩为摘要
滑动窗口	只保留最近 N 轮
向量化长期记忆	重要的存入向量库，需要时检索
Prompt Caching	缓存不变部分，省钱
上下文压缩	自动裁剪低信息量内容

---

五、本章核心知识地图

                    ┌─────────────────────────────────────┐
                    │           AI Agent 知识地基           │
                    └─────────────────────────────────────┘
                                       │
           ┌───────────────────────────┼───────────────────────────┐
           │                           │                           │
           ▼                           ▼                           ▼
   ┌───────────────┐         ┌───────────────┐         ┌───────────────┐
   │  理解 LLM      │         │  理解 Agent    │         │  理解挑战      │
   │               │         │               │         │               │
   │ • Token 预测器 │         │ • 大脑+工具+记忆│         │ • 幻觉→RAG     │
   │ • 自回归生成   │         │ • ReAct 循环   │         │ • 成本→分级    │
   │ • 上下文窗口   │         │ • Tool-use 机制│         │ • 延迟→流式    │
   │ • 无状态本质   │         │ • 自主vs辅助   │         │ • 可靠性→校验  │
   └───────────────┘         └───────────────┘         │ • 安全→护栏    │
                                                       │ • 上下文→压缩  │
                                                       └───────────────┘
                                       │
                                       ▼
           ┌─────────────────────────────────────────────────────────┐
           │                    四种架构选型                           │
           │                                                         │
           │  Router ──→ Tool-calling ──→ Multi-Agent ──→ Hierarchical │
           │  (简单分发)   (ReAct核心)      (团队协作)      (层级委派)   │
           │                                                         │
           │  复杂度: ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │
           └─────────────────────────────────────────────────────────┘

---

总结

模块	核心洞察
LLM 本质	它是一个"下一个 Token 预测器"，不是真正在理解——这决定了它的所有能力和局限
Agent 概念	Agent = LLM + 工具 + 记忆 + 规划，ReAct 是让这套组合运转起来的基础范式
架构模式	从简单路由到层级委派，选型的关键标准是：任务复杂度 × 工具需求 × 协作深度
关键挑战	六大挑战中，幻觉和安全是"致命"级，必须从架构层面解决而非事后修补

理解了这些，就拿到了进入下一阶段——真正动手构建 LLM 应用——的钥匙。下一站：LangChain 基础与 Prompt Engineering 🚀

---

本文基于"AI Agent 学习项目"第 1 阶段（大模型与 Agent 基础概念）整理，覆盖 1.1 LLM 本质、1.2 Agent 概念、1.3 Agent 架构模式、1.4 关键挑战 四个章节。