为什么需要 Agent

先厘清一个最容易混淆的前提：大语言模型（LLM）本身不是 Agent。

LLM 的输入是一个文本序列，输出是下一个 token 的概率分布。它本质上是一个「根据上文往下接」的预测器——你给它一句话，它回你一句话。它可以很聪明地回答「Python 里怎么反转列表」，但它不会主动去打开你的终端、跑一遍、把报错抓回来再修。它隔着屏幕叫不来任何东西。

而 Agent（智能体）要解决的问题恰恰是：让模型不只是「说」，而是能「做」。它让模型拥有调用工具、查阅记忆、制定计划、自我修正的能力，从而在一个有明确目标的任务里，自主地一步步推进，直到把事情办成。

这一章我们不讲任何框架的 API，先纯粹讲清楚 Agent 的本质——它到底由什么构成、背后的运行范式是什么、和它容易混淆的几个概念有什么区别。把这段地基夯实，后面几章的实战你才能写得顺手、报错了也能自己定位。

为什么"模型会说话"不算"模型会做事"

理解 Agent 的第一步是理解它为什么被发明。

传统 API 调用的缺陷

假设你在写一个 Java 后端，想让它根据用户的一句话"帮我查一下这周支付流水里金额最大的三笔违约交易"做点什么。用传统方式，你需要：

• 写一层自然语言理解（如文本分类、槽位填充）把这句话解析成结构化参数；
• 手写一个路由，根据意图调用对应的数据库查询方法；
• 拿到结果后，再用一个模板把结果转成自然语言回给用户。

任何意图没覆盖到的表达，这个管道就开始失灵。它本质上是一个 规则引擎加 LLM 的拼盘，问法一变就断。

Agent 的破局点

Agent 换了一种思路：不让模型一次性暴露出完整决策，而是让它在一个循环里反复"看—想—做"。

它给模型手里塞了三样东西——工具（能查数据库、能写文件、能调外部 Web API 的函数）、记忆（能记住你之前说过什么）、一个目标（你要它完成的最终任务）。这三样分别对应了后文四要素里的"工具（行动/执行）“和"记忆”，而"下一步怎么做"则交给模型的规划能力。然后让它自己决定：这一轮要不要用工具、用哪个工具、工具返回后下一步做什么，直到目标完成或它确信无法完成。

这样，“查三笔违约金"不再是一个模型猜着回答的问题，而是：模型先调用"查询违约交易"工具 → 工具返回数据 → 模型基于数据做排序 → 组装结果——每一步都有据可依，模型负责"决策与综合”，工具负责"事实与执行"。

智能体的四大要素

一个完整可用的 Agent，通常由四个核心组件构成。这四个部分既是概念上的"是什么"，也是代码里"你要自己写/借框架的东西"。

回写记忆 · 反馈结果给用户

目标 ──▶ 规划(想) ──▶(需要外部信息/动作) 工具(做)
                ▲                          │
                │────────── 观察结果 / 记忆回填 ◀──┘

一个 Agent 的完整运行循环

把四要素串起来，得到一个最核心、也最普及的执行范式，叫 ReAct（Reasoning + Acting，即"思考 + 行动"）。2022 年由 Shunyu Yao 等人提出（ICLR 2023），它把模型的行为组织成循环往复的三元组：

Thought（我想） → Action（我做）→ Observation（我观察结果） → 再想 →

比方说一个"查找资料并写摘要"的 Agent：

Thought:  需要先了解这个主题的背景，搜索一下。
Action:   调用 search("LangGraph 是什么")
Observed: 返回了一组关于 LangGraph 的介绍，提到它是赋予 Agent 状态的框架。
Thought:  核心是"状态"，那我再搜它的状态管理机制。
Action:   调用 search("LangGraph 状态管理")
Observed: 返回了 StateGraph 和 reducer 的说明……
---------------------------------------------------------
最终模型综合所有 Observed 的信息，输出浓缩成报告。

这套循环的价值在于决策可以被中途纠正：模型若第一步预测错了，它会基于"观察到的结果"重新规划下一步，而不是一错到底。这也是 Agent 相比"把问题和答案一股脑丢给模型"最可靠的地方。

下面用一张图（Mermaid 版 + ASCII 兜底版）展示完整循环：

┌─────────────┐
│ 接收任务目标  │
└──────┬──────┘
       ▼
┌─────────────┐      ┌─────────────────┐
│  读取记忆     │────▶│   规划下一步      │
└─────────────┘      └───┬─────────┬───┘
                         │         │
                还需查证 │         │ 已完成
                         ▼         ▼
                 ┌──────────┐  ┌─────────────┐
                 │ 调用工具   │  │ 生成最终回答  │
                 └────┬─────┘  └─────────────┘
                      │
                      ▼
              ┌─────────────┐
              │ 观察工具结果  │─▶ 回到规划
              └─────────────┘

Agent 与易混淆概念的边界

学习时最容易卡住的是：它跟"RAG"、“Workflow”、"Chatbot"到底什么关系？我给出清晰区分：

Agent ↔ LLM（大模型）

Agent 是用 LLM 做大脑的外壳。同一个底层模型，可以被包装成三种不同的形态：聊天机器人（只会聊）、RAG（会带资料回答）、Agent（会工具 + 规划 + 记忆 + 行动）。LLM 是"硬件核心"，Agent 是"操作系统"。

Agent ↔ RAG（检索增强生成）

这是最常见的混淆。RAG 解决的是"跟不上 / 知识不全"：把外部文档切成块、向量化存入向量库，回答时先检索相关段落再让 LLM 综合。它解决的是"缺失的知识"。

而 Agent 解决的是"缺失的执行能力"。RAG 只是 Agent 工具箱里的一个工具而已。可以说：RAG 回答"这是怎么回事"，Agent 能回答"你帮我去办一下"。

Agent ↔ Workflow（工作流）

• Workflow 是预先定义好固定流程：先 A 再 B 再 C，步骤写死（如"取数→清洗→入库→发报告"），LLM 只在节点里套，流程本身不随情况变。
• Agent 是流程也由模型动态决定：下一步去哪，取决于上一步结果是"合理"还是"异常"，模型自己在运行时规划路线。

有个形象的类比：Workflow 是铁路图，车按固定轨道跑；Agent 是导航，每次根据路况实时决策。实际工程里两者常常结合——Agent 内部也可嵌入 Workflow，Workflow 里也能有 Agent 节点。

这四种概念常被混为一谈，用一张图把它们的层次和边界摆清楚——LLM 是核心、RAG 是知识补给、Workflow 是固化流程、Agent 是最外层的自主调度：

┌─────────── CORE ───────────┐
    LLM(推理) ◀──── RAG(补知识)
        ▲
   ┌───┴────────┐
   │ Agent(自主) │──调度──▶ Workflow(固定流程)
   └────────────┘──作用──▶ 外部世界

工程里为什么要写"规划"这一环

新手常犯的误区：把所有逻辑塞进一个超大 prompt 里，让模型"一次性想好所有步骤"。这在简单任务里可行，一旦遇到多工具、长任务、需要中途纠正的任务，就暴露三大问题：

• 输出不稳定：步骤一变，模型输出格式就容易乱，后续解析崩。
• 无法回头修正：一旦中途发现目标错了，模型不会"返回去改"，只能一条道走到黑。
• 成本爆炸：所有信息一次性全塞进上下文，Token 大量浪费。

ReAct / 规划分工的意义在于：把"一次巨型输出"改成"多次小幅循环"，每一步只处理当前需要的信息，让模型的每段决策都聚焦在当前动作上，也让中途出错时只纠正那条支线。

    最后说一句，技术成长不只是写代码，职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料，适合想在职场上走得更远的朋友看看。

  资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。