认识 AI Agent：概念、架构、设计模式与主流框架

你让一个普通的 AI 助手“帮我整理本周的项目周报”，它多半回你一份周报模板，然后结束。换成 Agent，它会自己去查项目文档、提取关键信息、按模板生成摘要，甚至主动推送到协作群。差别在于：普通 AI 是你问一句、它答一句；Agent 是你给一个目标，它自己想办法完成。这篇文章从 Agent 是什么讲起，到它的架构、特性、常见设计模式，最后梳理主流的 Agent 框架。

1. Agent 是什么

1.1 带大脑、有手脚、有计划

在 AI 的语境下，Agent（智能体）是一种能够感知环境、进行自主决策、并调用工具去完成特定任务的智能系统。简单说，就是一个“带大脑、有手脚、有计划”的数字助手。

对照着看会清楚很多。以“学生准备社团活动”为例：

• 传统 AI 像复读机：你问“怎么写活动策划”，它给你一份模板，然后结束。
• Agent 像社团负责人：先调用日历 API 查空闲场地，再拆解出“定场地、发通知、拉赞助”几个步骤；自动发邮件联系场地管理员，用搜索工具找潜在赞助商名单；原场地被占了就自动查备用场地并重新协调；还记得你上次对音响不满意，这次自动在需求单里注明。

1.2 问答模式与任务驱动模式

两者的核心区别在交互模式：传统 AI 是“问答模式”，你推一下它动一下；Agent 是“任务驱动模式”，你给个目标，它自己想办法完成。

这里要分清一件事：不是所有用了大模型的应用都叫 Agent。判断标准在于它有没有“自主规划并调用工具”的能力。一个只会按固定提示词回答的聊天机器人不是 Agent；一个能自己决定“先查什么、再调哪个工具”的才是。

2. Agent 的基本架构

2.1 核心公式

一个典型的 Agent 以大型语言模型（LLM）为核心，围绕它构建三个组件：规划（Planning）、记忆（Memory）、工具使用（Tool Use）。业界公认的一个经典公式：

Agent = LLM（大脑）+ 规划（策略）+ 记忆（经验）+ 工具（手脚）

2.2 四个组件拆解

• LLM（大脑）：核心，负责逻辑推理、意图识别和语言生成。Agent 的所有行动指令都源于 LLM 对当前任务的理解。
• 规划（Planning）：依赖 LLM 分析当前任务状态、拆解目标、生成思考路径，决定下一步动作。
• 记忆（Memory）：分短期记忆（上下文历史，保持对话连续）和长期记忆（外部知识库，如向量数据库、知识图谱），防止遗忘历史信息、从经验中学习。
• 工具使用（Tool Use）：真正执行动作的模块，调用搜索引擎、计算器、代码解释器、第三方 API 等，突破模型自身的能力边界。

用“晚上下班回家”的场景串起来：你对智能音箱说“我回来了”。大脑理解“回来”意味着恢复居家环境；规划自动拆成三步，开客厅灯、开空调、放轻音乐；记忆记得你平时喜欢白光、空调 24℃、钢琴曲音量 30%；工具依次给智能灯泡、空调、音乐播放器发指令。

2.3 Agent 与 Workflow 的区别

这是最容易混淆的一对概念。

工作流（Workflow）是一系列预定义的、有序的步骤，按固定流程自动执行。开发者提前写好所有路径：发生 A 就执行 B，失败就走 C。同样的输入永远得到同样的执行路径，像一条工业流水线。

Agent 是给定目标后，根据当前情况临时决定每一步做什么，执行路径不确定，会根据环境反馈不断调整。

一个类比：工作流像跟团游，8 点集合、9 点到博物馆、12 点开饭，行程表是死代码，博物馆闭馆也会把你拉到门口；Agent 像背包客，目标是“去西安感受历史”，发现博物馆排队太长，就查附近古迹、先去吃个肉夹馍避开高峰。

实际开发中两者经常配合使用，形成“基于工作流的智能体”：工作流提供约束，防止 AI 乱跑、无限循环或产生幻觉，保证核心步骤不出错；Agent 提供智能，在具体环节里处理复杂、非结构化的数据。

3. Agent 的基本特性

一个合格的 Agent 通常具备五个特性，用旅行规划 Agent 的例子逐条对照：

1. 自主性（Autonomy）：能在没有直接干预的情况下运作，对自身行动有控制权。你只说“帮我规划五一去云南的 4 天行程”，它自己决定查机票、酒店、景点顺序。
2. 反应性（Reactivity）：能感知环境变化并及时反应。发现 5 月 1 日昆明机票售罄，立刻调整方案，改建议飞丽江或改日期。
3. 主动性（Proactiveness）：不仅响应需求，还主动规划中间步骤以达成隐含的高阶目标。主动比较航班价格、计算总预算、推荐最优路线。
4. 学习能力（Adaptability）：能从历史交互中提取抽象偏好并用于后续任务。你反馈“不喜欢太赶的行程”，它下次自动留出更多自由时间。
5. 社交能力（Social Ability）：多个 Agent 之间能通信协作。它能与专门的机票预订 Agent、酒店预订 Agent 协作，通过标准协议相互询问、协商。

4. 常见设计模式

Agent 不是一拍脑袋想出来的，业界沉淀了几种经典设计模式。理解它们，就理解了 Agent“怎么思考”。

4.1 ReAct：推理与行动的循环

两种“半成品”模式

ReAct 是由 Google Research 在 2022 年提出的推理框架，核心是把推理（Reasoning）和行动（Acting）结合起来。在它之前，模型要么只推理、要么只行动，各有各的坑：

纯推理（Reasoning-Only）：只在内部推演，不调用外部工具。问“今天北京天气，给穿衣建议”，它凭“4 月北京平均 15℃”推理，得出“晴朗、建议薄外套”。实际当天是 8℃ 有雨，答案完全错误。问题在于它依赖过时的平均数据，产生了幻觉。

纯行动（Action-Only）：只生成行动指令，不解释为什么。问“今天天气如何，晴天就推荐几个公园”，它机械执行：查天气得到“8℃、沙尘暴”，判断“不适合户外”，却仍然推荐公园列表。问题在于缺乏“思考”环节做条件判断，明知不适合户外还一路往下走。

ReAct 的 TAO 循环

ReAct 把两者结合起来，按照“思考 → 行动 → 观察”循环迭代，简称 TAO 循环：

还是那个天气问题，ReAct 的做法是：

Thought 1: 需要先查天气，再根据天气决定是否推荐公园。
Action: get_weather(city="Beijing")
Observation: {"temp": 8, "condition": "沙尘暴"}

Thought 2: 沙尘暴不适合户外，用户要求晴天才推荐公园，改为推荐室内场馆。
Action: recommend_indoor_places(city="Beijing")
Observation: ["国家博物馆", "首都图书馆"]

Final Answer: 今天 8℃ 有沙尘暴，不建议去公园，推荐国家博物馆或首都图书馆。

每一步都先思考、再行动、再根据观察结果决定下一步，既拿到了真实数据，又避免了机械执行。

优势与劣势

优势：动态适应（根据上一步结果即时调整策略）；可解释性强（Thought→Action→Observation 轨迹清晰可追溯）；显著降低而非杜绝幻觉。工具观察提供了事实锚点，但如果工具返回的数据本身有误，模型仍可能基于错误信息继续推理。

劣势有四条：易陷入循环或跑偏（缺乏全局计划，可能忘记原始目标）；无法并行（必须串行执行，同时查天气、股价、新闻要轮流调三次工具）；不适合长周期任务（必须阻塞等待，启动 10 小时模型训练会让会话超时）；工具调用次数不可控（反复试错导致成本飙升）。

落地时的修正

实际落地几乎没人直接用原生的 ReAct 循环，业界通常做四件事：引入双层架构，顶层规划器输出任务清单，底层执行器对每个子任务跑 ReAct，防止跑偏；独立子任务直接并行调用；长周期任务下发消息队列不阻塞会话；设置最大迭代步数控制成本。

4.2 Plan & Execute：先规划后执行

Plan & Execute 是另一种设计模式：先由规划器（Planner）生成高层多步骤计划，再由执行器（Executor）按序执行，执行中可基于中间结果触发重新规划。它不像 ReAct 那样“每走一步都全局思考下一步”，而是“先画施工蓝图，再按图施工，遇到地质变化时修改图纸”。

优点：不易跑偏（全局计划像施工图纸）；可并行执行（无依赖的步骤同时运行）；效率高成本低（任务分解的推理集中在规划阶段完成，执行阶段多为固定工具调用）。

缺点也明显：异常分支处理薄弱（计划一旦生成就难应对中途的新信息）；计划出错则全盘失败（遗漏关键步骤或顺序错误）；不适合探索性任务（“帮我找个有意思的 GitHub 项目”，“有意思”无法提前编码进计划）。

修正思路：主流框架采用 Planning + ReAct 混合模式，执行器在局部循环里自治；计划生成后先检查步骤顺序、分段执行勤存盘、哪步坏了只修哪步；探索性任务改用“探索-评估”循环，把主观目标转成可计算的满意度分数。

4.3 Reflection：生成-反思的闭环

Reflection 是让同一个（或不同）模型对自身输出进行审视、批评并迭代改进的模式，核心是“生成 → 反思”的闭环。

举个例子，写一条节约用水用电的公告。初稿“请大家节约用水用电，不要乱扔垃圾”太笼统、像喊口号；第一轮反思后改成具体行为“离开教室关灯关风扇，洗手后拧紧水龙头”；第二轮反思再加正面鼓励，最终版本更有感染力。这就是“生成-反思-优化”的循环。

优点：质量更高（生成者与批判者自我博弈）；不依赖别人（无需构建双模型）；减少返工（把错误前置到 AI 自己的推理过程中）。

缺点：费时间（每轮反思都要完整重读和重新生成，3 次反思约 4 倍 token 成本）；容易改过头（过度修改让内容变得刻板）；自己可能有盲区（评判标准来自模型自身，数学不好的模型检查不出自己的逻辑漏洞）。

修正思路：快照对比加强制早退，设置最大反思轮次（通常 1-3 次），引入外部校验（代码跑测、事实核查、用户反馈）。

4.4 ReAct 与 Reflection 的对比

两者不互斥，经常互补：主体用 ReAct 调用工具执行动作，任务完成后或失败时外挂一个 Reflection 模块监控质量、分析错误。这样 Agent 既能高效“行动”，又能聪明“成长”。

5. 主流 Agent 框架

理解了原理，再看怎么落地。主流框架大致分两类：一类是代码库（Library），开发者用代码组装 Agent；一类是平台（Platform/SaaS），可视化拖拉拽搭建。

5.1 代码库类框架

5.2 平台类框架

5.3 怎么选

选框架不是看谁名气大，而是看场景。要快速验证一个 Bot 想法、面向非程序员，用 Coze、Dify 这类平台更合适；要做精细控制、接入现有工程、构建生产级复杂工作流，用 LangGraph、AutoGen、CrewAI 这类代码库。Java 技术栈有 Spring AI、LangChain4j；.NET 有 Semantic Kernel。还要注意一点：一旦用某个框架构建了核心智能体生态，后续会面临“框架锁定”，这也是 A2A（Agent-to-Agent）协议要解决的问题之一，即让不同框架的 Agent 能互相通信。

结语

把整条线串起来：Agent 之所以区别于普通 AI，是因为它把 LLM 从“答题者”变成了“执行者”，大脑负责推理，规划拆解目标，工具真正动手，记忆积累经验。ReAct、Plan & Execute、Reflection 三种设计模式，对应“边想边做”“先想再做”“做完再改”三种做事方式。至于选哪个框架，代码库框架让你能够掌控全局，平台类框架让你能够快速上手。理解了这个从“是什么”到“怎么思考”再到“用什么做”的脉络，再去上手任何一个 Agent 框架，都不会觉得陌生了。