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 强不同场景该选什么架构本文从底层原理到上层架构一次性讲透。文章目录AI Agent 基础概念全景从 LLM 本质到架构模式与关键挑战一、LLM 的本质下一个 Token 预测器1.1 LLM 到底在做什么1.2 Token 化LLM 的最小处理单位1.3 自回归生成一个 Token 接一个 Token1.4 LLM 的能力与局限二、Agent 核心概念从 ReAct 到 Tool-use2.1 什么是 Agent2.2 Agent 的核心三要素2.3 ReAct 模式 —— Agent 的经典范式2.4 Tool-use / Function Calling —— Agent 的手2.5 自主 Agent vs 辅助 Agent三、四种 Agent 架构模式与选型指南3.1 架构全景图3.2 Router Agent路由型—— 入门级3.3 Tool-calling Agent工具调用型—— 最核心3.4 Multi-Agent多智能体协作—— 团队级3.5 Hierarchical Agent层级型—— 企业级3.6 选型决策树四、Agent 开发的六大关键挑战4.1 全景总览4.2 幻觉 (Hallucination) — ⚠️⚠️⚠️ 致命4.3 推理成本 — ⚠️⚠️ 严重4.4 延迟 — ⚠️⚠️ 严重4.5 工具调用可靠性 — ⚠️⚠️ 严重4.6 安全护栏 — ⚠️⚠️⚠️ 致命4.7 上下文窗口限制 — ⚠️ 中等五、本章核心知识地图总结一、LLM 的本质下一个 Token 预测器1.1 LLM 到底在做什么所有 LLMGPT-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 接一个 TokenStep 1: 法国 → 模型计算 → 输出 的 Step 2: 法国的 → 模型计算 → 输出 首 Step 3: 法国的首 → 模型计算 → 输出 都 Step 4: 法国的首都 → 模型计算 → 输出 是 Step 5: 法国的首都是 → 模型计算 → 输出 巴黎 ...直到遇到 |endoftext| 停止每个 Token 的生成都依赖于之前所有的 Token——正因为如此模型不能跳回去修改已生成的内容一个错误会连锁影响后续输出流式输出天然适合因为本就是逐 Token 生成的Temperature 的控制就在这个环节起作用贪婪解码temperature0每次都选概率最高的 Token输出确定但缺乏变化概率采样temperature0.7从概率分布中随机选取输出更丰富但也可能不连贯。1.4 LLM 的能力与局限局限说明Agent 中的应对幻觉编造不存在的事实RAG 检索验证、工具调用无状态不记得之前的对话记忆管理无外部知识只知道训练数据工具调用Token 窗口有限不能无限塞上下文上下文工程推理链断裂复杂推理可能出错LangGraph 结构化编排无法行动只能输出文本Agent 工具调用这就是为什么需要 AgentLLM 是大脑但它没有眼睛不能搜索、没有手不能执行、没有记忆不记得你。Agent LLM 工具 记忆 决策循环。二、Agent 核心概念从 ReAct 到 Tool-use2.1 什么是 AgentAgent (智能体) 一个能够自主感知环境、推理决策、执行行动以完成目标的 AI 系统。普通 LLM 调用和 Agent 的本质区别普通 LLM 调用: 用户 → 提问 → LLM → 回答 → 结束 (单轮, 无工具, 无记忆, 无决策) Agent: 用户 → 提问 → LLM分析 → 决定用哪个工具 → 调用工具 → 观察结果 → 继续推理 → 可能再用工具 → ... 循环 ... → 最终回答 → 结束 (多轮, 有工具, 有记忆, 有决策)2.2 Agent 的核心三要素┌──────────────────┐ │ 大脑 (LLM) │ ← 推理引擎分析·规划·决策 └──────┬───────────┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ │ 工具 │ │ 记忆 │ │ 规划 │ │ 搜索、API │ │ 短期、长期 │ │ 拆解、编排 │ │ 代码、数据 │ │ 对话、知识 │ │ ReAct、PE │ └───────┘ └───────┘ └───────┘要素作用为什么不可或缺大脑 (LLM)理解指令、推理、决策没有大脑Agent 就是空壳工具 (Tools)与外部世界交互没有工具LLM 永远活在训练数据里记忆 (Memory)记住历史、积累知识没有记忆每次对话都是第一次见面规划 (Planning)拆解任务、编排步骤没有规划复杂任务无从下手2.3 ReAct 模式 —— Agent 的经典范式ReActReasoning 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 真正获得了行动能力你告诉 LLM“你有一个get_weather(city)工具”LLM 分析用户输入后不输出文本而是输出一个 JSON{name: get_weather, arguments: {city: 北京}}你的代码执行该函数把结果返回给 LLMLLM 基于结果生成最终回复从 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 自主决定要不要用工具、用哪个工具、传什么参数。fromlanggraph.prebuiltimportcreate_react_agentfromlangchain_openaiimportChatOpenAI tools[get_weather,web_search,calculator]llmChatOpenAI(modelgpt-4o)agentcreate_react_agent(llm,tools)resultagent.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 的固有特性。四种常见形态事实捏造“2025 诺贝尔奖得主是张三”——完全胡编引用虚构引用不存在的论文、书籍、法律条文数字虚构“全球有 3,847 家 AI Agent 公司”——看起来很精确实际是编的过度自信即使简单数学也可能在特定 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 且无结果成本控制三板斧设置最大步数config {recursion_limit: 10}防止无限循环模型分级规划用强模型GPT-4o摘要/分类用弱模型GPT-4o-mini缓存重复查询同一搜索 query 不重复调用 API4.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. 工具描述写清楚——这是最关键的一步defsearch(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_toall_customers) ❌四道防线工具白名单安全工具随便用危险工具shell、email_send、db_write需审批参数校验过滤rm -rf、format等危险模式Human-in-the-Loop关键操作发邮件、删数据必须人工确认内容安全过滤拦截越狱、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 关键挑战 四个章节。