第二章：AI Agent 到底是个啥？—— 用生活场景把概念讲明白

AI Agent 到底是个啥？------ 用生活场景把概念讲明白

在上一章里，我们聊了为什么前端工程师在 AI 时代反而有优势，也打了一个"药剂师"的比方------你不需要发明新药，只需要会用现成的药来给人治病。那这一章，我们要聊一个更具体的问题：AI Agent 到底是什么东西？

说实话，我第一次听到"Agent"这个词的时候，脑子里冒出来的是电影《黑客帝国》里的特工史密斯------穿着黑西装、戴着墨镜、无所不能。后来才知道，编程世界里的 Agent 没那么玄乎，它就是一个能自己做决定、自己动手干活、还会总结经验教训的程序。

为了让你彻底搞懂这个概念，我们不用术语堆砌，而是用你最熟悉的生活场景，一步步把 Agent 拆开来看。看完这一章，你能跟任何人讲清楚 AI Agent 的原理------哪怕对方完全不懂技术。

从订机票说起------Chatbot 和 Agent 到底差在哪？

想象一个场景：你下个月要去深圳出差，需要订一张从北京出发的机票。你打开手机，有两个选择------一个普通的 AI 聊天助手（Chatbot），一个搭载了 Agent 能力的智能助手。

场景一：普通 Chatbot 的表现

你跟 Chatbot 说："帮我订一张下周三从北京到深圳的机票。"

Chatbot 想了想，回复你： "建议您提前在航空公司官网或第三方平台（如携程、飞猪）查询航班信息，通常提前预订能获得更优惠的价格。您可以在搜索时筛选出发时间、航空公司等条件。"

你看着这段回复，心里一万头羊驼跑过。它说得都对，但屁用没有。你还是要自己打开携程，自己查航班，自己比价格，自己下单。Chatbot 本质上就是个"会聊天的百科全书"------它只能给你建议，不能替你干活。

场景二：AI Agent 的表现

你跟 Agent 说了同样的话："帮我订一张下周三从北京到深圳的机票。"

Agent 没有直接回复你，而是开始了它的"内心戏"：

用户想订机票，我需要知道：出发城市（北京）、目的地（深圳）、日期（下周三）。但光有这些还不够，我还需要知道用户喜欢什么时间段、偏好什么航空公司、预算范围是多少。让我先查一下用户的历史记录，看看他以前坐过什么航班。 → 调用记忆模块，读取用户偏好... 用户以前坐过国航 CA1303，偏好早上 9 点左右的航班，预算在 1500 以内。好的，现在让我调用航班查询 API 查一下下周三有哪些航班。 → 调用航班查询工具... 查到 3 个符合条件的航班。CA1303 早上 9 点起飞，票价 1280；CA1305 下午 2 点，票价 1450；CZ3194 早上 8 点，票价 1100。用户偏好早班机，CA1303 和 CZ3194 都符合。但 CA1303 是用户坐过的，CZ3194 便宜 180 块。让我把这两个选择给用户确认一下。

然后 Agent 回复你："我帮你查到了两个合适的航班：国航 CA1303（你上次坐过的，早上 9 点，1280 元）和南航 CZ3194（早上 8 点，便宜 180 块，只要 1100 元）。你选哪个？"

你说："就 CA1303 吧。"

Agent 说："好的，我用你之前存的个人信息帮你下单。哦对了，你上次坐这个航班的时候选了靠过道的座位，这次还要靠过道吗？"

你说："对，靠过道。"

Agent 说："搞定了。CA1303，下周三早上 9 点，北京首都 T3 飞深圳宝安，靠过道座位，1280 元。订单号是 BK20240701001，已经发到你邮箱了。需要我帮你加到日历里吗？"

看出来区别了吗？

Chatbot 就像你问路边的路人"怎么去机场"------路人会告诉你坐地铁几号线、打车大概多少钱，但你自己得去执行。Agent 就像一个靠谱的私人助理------你交代一句，它自己查资料、自己做决定、自己动手干活，干完了还问你一句"要不要顺便帮你把这事也办了"。

一句话总结

Chatbot = 能聊天的知识库；Agent = 能干活的小助手。Chatbot 给你答案，Agent 给你结果。这也是为什么 2024 年被很多人称为"Agent 元年"------AI 终于从"会说"进化到了"会做"。

再举一个更贴近程序员日常的例子。假设你遇到一个 Bug，报错信息是"TypeError: Cannot read properties of undefined"。

你问 Chatbot： "Vue3 里出现了 TypeError: Cannot read properties of undefined，怎么解决？" Chatbot 会给你一段很详细的解释------"这个错误通常是因为你尝试访问一个 undefined 值的属性，检查一下你的响应式数据是否正确初始化，确保在模板中使用了可选链操作符..." 它说得头头是道，但你还是要自己去看代码、自己定位问题、自己改。

你问 Agent： "我的 Vue3 项目报错了，TypeError: Cannot read properties of undefined，帮我看看。" Agent 会说："让我看看你的代码。" 然后它自己读取你的组件文件，发现第 23 行有一个 user.address.city，但 user 初始化时 address 是 undefined。它自己改代码，加上可选链或默认值，然后跑一遍测试确认没问题，最后告诉你："修好了，是第 23 行的问题，user.address 没有初始化，我帮你加了默认值，测试也过了。"

这个差距够直观了吧？Chatbot 是"告诉你问题在哪"，Agent 是"帮你把问题解决了"。前者是搜索引擎的升级版，后者是真正的"数字同事"。

Agent 的四要素：感知、决策、行动、记忆

上面那个订机票的例子看起来挺神奇的，对吧？但你把它拆开来看，会发现 Agent 做的事其实就四件。我用一个更生活化的场景帮你理解------你妈让你去菜市场买菜。

要素详情可去我的公粽号看，后面更新章节也是在那

"思考-行动-观察"循环------Agent 是怎么工作的？

ReAct 模式的本质：把推理和行动绑在一起

在 ReAct 出现之前，AI 系统要么"只推理不行动"（比如纯文本模型，只能回答问题），要么"只行动不推理"（比如传统的自动化脚本，只能按固定流程执行）。ReAct 把两者结合起来了------让 AI 在推理中穿插行动，在行动中获取信息反过来辅助推理。

Agent 的四种设计模式

ReAct 循环是最经典、最基础的 Agent 模式，但不是唯一的。经过这几年的发展，Agent 领域涌现出了好几种不同的设计模式，每种都有自己擅长的场景。理解这些模式，能帮你在做项目的时候选对路子。

打个比方：ReAct 就像走路------最基础、最通用，去哪都能走。但如果你要去的地方很远，开车（Plan-and-Execute）更快；如果你要搬很多东西，叫几个人一起搬（Multi-Agent）更高效；如果你走错路了，回头看看地图重新规划（Reflexion）更靠谱。

模式一：ReAct（边想边做）

核心思想： 走一步看一步，每一步都根据当前的观察来决定下一步做什么。

这就像你去一个陌生的城市旅游。你没有提前做攻略，下了飞机打开手机地图，看看酒店在哪，然后决定坐地铁还是打车。到了酒店，看看附近有什么好吃的，再决定去哪家。逛完景点，看看时间，再决定是回酒店还是再去一个地方。

优点： 灵活，能应对突发情况。如果计划赶不上变化，ReAct 可以随时调整。

缺点： 效率偏低，每一步都要调用 LLM 做决策，成本较高。而且因为没有全局计划，有时候会走弯路------就像旅游没做攻略，可能会绕路。

适合场景： 开放性任务、需要灵活应对的任务。比如客服对话、信息检索、简单的日常任务。

模式二：Plan-and-Execute（先做计划再执行）

核心思想： 先花时间想清楚整体计划，然后按计划一步步执行。执行过程中如果发现计划有问题，可以返回去修改计划。

这就像你装修房子。你不会说"先买点材料，装到哪算哪"。你会先找设计师出一个完整的设计方案，确认每个房间的风格、水电走线、材料清单，然后按方案一步步施工。施工过程中如果发现某个墙不能砸，再调整方案。

┌──────────────────────────────────────────────────────┐ │ Plan-and-Execute 模式 │ ├──────────────────────────────────────────────────────┤ │ │ │ 【规划阶段】 │ │ 用户任务 → LLM 制定完整计划 → 拆解为 N 个子任务 │ │ │ │ 【执行阶段】 │ │ 子任务1 → 执行 → 观察 → │ │ 子任务2 → 执行 → 观察 → │ │ ... │ │ 子任务N → 执行 → 观察 │ │ │ │ 【重规划（可选）】 │ │ 如果某步执行失败 → 修改计划 → 继续执行 │ │ │ └──────────────────────────────────────────────────────┘

优点： 效率高，有了全局计划后执行阶段不需要反复调用 LLM 做决策，省成本。而且计划是透明的，你可以提前预览 Agent 打算做什么。

缺点： 灵活性不如 ReAct。如果实际情况和计划偏差很大，需要重新规划，反而浪费时间。

适合场景： 任务明确、步骤可预测的场景。比如代码生成、文档撰写、数据处理流水线。

模式三：Multi-Agent（多 Agent 协作）

核心思想： 一个 Agent 不够，让多个 Agent 分工合作，每个 Agent 扮演不同的角色，像一个团队一样工作。

这就像你开一家公司。你不会一个人干所有事------你招一个设计师做图、一个程序员写代码、一个运营做推广、一个客服回消息。每个人各司其职，但互相配合。CEO 不做具体的事，只负责协调和决策。

在 Multi-Agent 模式里，通常会有一个"编排 Agent"（Orchestrator）负责分配任务，其他 Agent 各司其职。比如做一个智能客服系统：

用户：我的订单怎么还没发货？ ↓ 编排 Agent：这是一个订单查询问题，交给 OrderAgent ↓ OrderAgent：查询订单状态 → 发现已发货但物流没更新 ↓ OrderAgent：需要查物流，交给 LogisticsAgent ↓ LogisticsAgent：调用物流 API → 包裹在深圳中转站 ↓ 编排 Agent：汇总结果 → 回复用户

优点： 每个 Agent 职责单一，容易维护和优化。复杂任务可以拆解给多个 Agent 并行处理，效率高。

缺点： 系统复杂度高，Agent 之间的通信和协调是个难题。如果编排 Agent 出了问题，整个系统就瘫痪了。

适合场景： 复杂业务系统、需要多角色协作的场景。比如企业级智能客服、自动化运营平台、代码审查系统。

模式四：Reflexion（反思自省）

核心思想： Agent 完成一次任务后，回头审视自己的表现，总结经验教训，下一次做得更好。

这就像你考完试后对答案。你不是考完就完了，而是把错题拿出来分析：这道题为什么错了？是知识点没掌握，还是粗心大意？下次遇到类似的题应该怎么做？然后把这些经验记下来，下次考试前复习一遍。

Reflexion 模式在 ReAct 循环的基础上，加了一个"反思环节"：任务完成后，Agent 会问自己几个问题------"我做得怎么样？有没有更好的方案？哪里可以改进？"然后把反思结果存到长期记忆里，下次遇到类似任务时直接参考。

js 复制代码

// Reflexion 模式核心逻辑
async function reflexionLoop(task: string) {
  // 1. 正常执行 ReAct 循环
  const result = await reactLoop(task)

  // 2. 反思：让 LLM 评价自己刚才的表现
  const reflection = await llm.think(`
    刚才的任务是：${task}
    我的执行过程是：${JSON.stringify(result.history)}
    执行结果是：${result.outcome}
    请评价：我做得怎么样？有什么可以改进的？
    输出 JSON：{"score": 1-10, "good": [...], "bad": [...], "lesson": "..."}
  `)

  // 3. 把经验存到长期记忆
  await memory.save('reflections', {
    task,
    reflection,
    timestamp: Date.now(),
  })

  return result
}

优点： Agent 会越用越聪明，能从错误中学习。对于重复性高的任务，效果提升明显。

缺点： 增加了额外的 LLM 调用成本，而且反思的质量取决于 LLM 的能力------如果 LLM 本身不够聪明，反思也可能是错的。

适合场景： 需要持续优化的任务、重复性高的任务。比如代码生成、内容创作、数据标注。

四种模式对比速查

模式	核心思路	LLM 调用次数	灵活性	最佳场景
ReAct	走一步看一步	多（每步都调）	最高	客服对话、信息检索、开放性任务
Plan-and-Execute	先规划再执行	少（只在规划时调）	中等	代码生成、报告撰写、数据处理
Multi-Agent	多角色分工协作	取决于子 Agent 数量	高	复杂业务系统、多角色协作场景
Reflexion	执行后反思改进	多（多了反思环节）	中等	需要持续优化的重复性任务

这个表格可以帮你快速判断：面对一个任务，选哪种模式。如果你拿不准，先选 ReAct------它最通用，出错概率最低。等项目跑起来了，再根据实际表现调整。

实际开发中怎么选？

大多数情况下，ReAct 就够用了。如果你发现 Agent 经常走弯路或者效率低，试试 Plan-and-Execute。如果你的系统有多个明确的子任务，用 Multi-Agent。如果你想让 Agent 越用越聪明，在 ReAct 上叠加 Reflexion。这些模式不是互斥的------你可以把 Plan-and-Execute 和 Reflexion 结合起来用，先规划再执行，执行完再反思。

选模式的时候，还有一个实用的判断标准：看你的任务"确定性"有多高。 任务确定性高（比如"生成一份标准的周报"），Plan-and-Execute 更高效------提前规划好"读取数据 → 分析趋势 → 生成图表 → 排版输出"的步骤，执行阶段不需要反复调用 LLM。任务确定性低（比如"帮我分析一下这个 Bug 的原因"），ReAct 更合适------你很难提前规划，因为 Bug 的原因可能有一万种，必须走一步看一步。

另外，模式之间是可以组合的，这也是目前工业界的主流做法。比如一个智能客服系统，整体架构可能是这样的：

用户提问 ↓ 编排 Agent（Orchestrator） - 用 ReAct 模式理解用户意图 - 判断问题类型：售后、咨询、投诉？ ↓ 如果是售后 → 售后 Agent（Plan-and-Execute） - 读取订单 → 查物流 → 判断退换货条件 → 生成方案 ↓ 如果是咨询 → 咨询 Agent（ReAct） - RAG 检索知识库 → 边查边回答 → 追问澄清 ↓ 如果是投诉 → 投诉 Agent（Reflexion） - 分析投诉内容 → 查历史处理记录 → 生成补偿方案 → 反思优化

这种"混合模式"看起来复杂，但每个子 Agent 都很简单，职责单一。就像微服务架构------每个服务只做一件事，但组合起来就是一个完整的系统。

Agent 和 RPA ------ 都是"自动化"，但完全不是一回事

聊到 Agent 的时候，经常有人会问："这不就是 RPA（机器人流程自动化）吗？RPA 也能自动操作软件、填表单、发邮件，跟 Agent 有啥区别？"

这个问题问得很好，因为两者的确有相似之处------都是"让程序代替人干活"。但它们的底层逻辑完全不同。我用一个比喻来帮你理解。

RPA 就像一条工厂流水线。 流水线上的每个工位做什么，都是提前设定好的------第一个工位拧螺丝，第二个工位装外壳，第三个工位贴标签。不管来的是什么产品，流程都一样。如果产品规格变了，流水线就得重新改造。

Agent 就像一个熟练的工匠。 工匠拿到一个活，会先看看要做什么，然后根据情况决定怎么做。如果是做一把椅子，他知道要用木头、锯子、钉子，步骤是锯木、打磨、拼接、上漆。如果是做一个花瓶，他换一套工具和流程。他不需要你提前告诉他每一步怎么做，他自己会判断。

用技术语言说，核心区别就两点：

对比维度	RPA	AI Agent
决策方式	规则驱动，if-else 逻辑	LLM 推理，自主决策
适应性	流程固定，改需求就要改代码	灵活应变，能处理意外情况
输入	结构化数据（表格、表单）	自然语言、非结构化数据
典型场景	发票录入、数据搬运、报表生成	智能客服、自动编程、研究分析
开发方式	拖拽式流程设计器	写代码，定义工具和提示词
容错能力	差，中间一步出错整个流程挂	强，能根据错误信息调整策略

举个例子：一个电商公司需要自动处理退货申请。RPA 的做法是：打开邮件 → 找到退货邮件 → 提取订单号 → 打开 ERP 系统 → 输入订单号 → 点击"退货"按钮 → 发确认邮件。如果某封邮件格式不对，或者 ERP 系统更新了界面布局，RPA 就挂了。

Agent 的做法是：收到退货请求 → 理解用户想退什么、为什么退 → 查询订单系统验证订单 → 判断是否符合退货条件 → 如果符合，调用退货 API 创建退货单 → 发确认邮件。如果邮件格式不对，Agent 会试着理解内容；如果退货政策变了，Agent 能根据新的规则重新判断，而不是死板地执行固定流程。

再举一个更贴近你日常开发的例子。假设你要做一个"自动部署"的流程。RPA 的做法是：连接 Jenkins → 点击"构建"按钮 → 等待构建完成 → 检查构建日志 → 如果日志里有"BUILD SUCCESS"就标记成功，否则标记失败。这个流程非常脆弱------如果 Jenkins 更新了 UI，按钮位置变了，RPA 就挂了；如果构建日志格式变了，RPA 就找不到"BUILD SUCCESS"了。

Agent 的做法是：收到部署请求 → 理解要部署哪个分支、什么环境 → 调用 Jenkins API 触发构建 → 轮询构建状态 → 读取构建日志 → 如果构建失败，Agent 会分析日志，尝试定位失败原因，然后问你要不要自动修复。如果构建成功，Agent 会调用部署 API 把产物部署到目标环境，然后发通知。整个过程里，Agent 不是在"模拟点击"，而是在"调用 API"，所以不受 UI 变化的影响；同时 Agent 能理解日志内容，而不是简单匹配字符串。

这个例子也揭示了一个重要趋势：随着越来越多的系统提供 API 接口，RPA 的"模拟点击"模式正在被 Agent 的"API 调用"模式取代。 因为 API 调用比模拟点击更稳定、更高效、更易维护。所以如果你现在要选一个自动化方案，能调 API 就调 API，别走 RPA 的"模拟点击"路线------除非那个系统确实没有 API（比如一些老旧的 ERP 系统）。

一句话总结：RPA 是"自动化流程"，Agent 是"自动化决策" 。RPA 解决的是"重复劳动"的问题，Agent 解决的是"需要动脑子"的问题。

不过，RPA 和 Agent 也不是非此即彼的关系。在实际项目中，有一种越来越流行的做法叫Agentic RPA------在传统 RPA 流程中嵌入 Agent 作为"决策节点"。比如一个发票处理流程：RPA 负责从邮件里提取 PDF 附件、OCR 识别文字、录入系统；但在"分类"这个环节------这张发票是差旅费还是办公用品？------传统 RPA 只能用规则匹配（"如果发票内容包含'酒店'，归类为差旅费"），而 Agent 能理解发票的语义，做出更准确的分类。这种"RPA 做体力活，Agent 做脑力活"的组合，正在成为企业自动化的新趋势。

Agent 和传统 if-else 程序 ------ 一个用大脑，一个用公式

另一个常见的疑问是："Agent 做的事情，我用 if-else 也能写出来啊。比如订机票，我可以写一个函数，判断用户输入里有没有'北京'和'深圳'，然后调 API 查航班，再返回结果。这跟 Agent 有啥区别？"

技术上，确实可以用 if-else 实现"看起来像 Agent"的效果。但两者之间的差距，就像计算器和 ChatGPT 的区别------计算器能算 1+1=2，但你不能问它"今天心情怎么样"。

具体来说，差距体现在这几个方面：

1. 理解能力：Agent 能理解"言外之意"

用户说"帮我订一张下周三从北京到深圳的机票"，传统程序需要你提前定义好"出发城市""目的地""日期"这些槽位，然后用正则或者 NLP 去提取。如果用户换一种说法------"下周三我要去深圳出差，从北京走，帮我看看有什么航班"------你可能要重新写正则。

更极端的情况：用户说"帮我订一张跟上次一样的机票"。传统程序完全不知道"上次"是什么。Agent 能自己查记忆，找到上次的航班信息，然后复用。

2. 灵活性：Agent 能处理"意料之外"的情况

传统程序：你写了查航班 → 推荐航班 → 下单的流程。但如果用户说"太贵了，有没有便宜点的"，你的程序就不知道怎么办了------因为"太贵了"这个分支你没写。

Agent：用户说"太贵了"，Agent 会重新思考------"哦，用户觉得价格不合适，那我重新查一下，看看有没有更便宜的航班，或者换个日期。"它不需要你提前写"if userSaysExpensive"这个分支。

3. 工具组合：Agent 能"自己决定"用什么工具

传统程序：你定义了三个工具------查航班、查用户偏好、下单。调用顺序是你写死的。

Agent：它有一个工具列表，但它自己决定什么时候用哪个工具、用什么参数、调用的顺序。甚至在执行过程中发现需要一个新的工具（比如"查天气"------如果深圳下暴雨，航班可能延误），它可以自己判断要不要加这个步骤。

4. 学习能力：Agent 能"越用越好"

传统程序：代码写完了就不会变，除非你手动改。

Agent：通过 Reflexion 模式，它可以总结每次任务的经验，下次遇到类似的场景直接应用。比如它发现用户每次都选早班机，以后查询航班时就会优先推荐早班机。

为了让你更直观地感受这个差距，我准备了一个对比表格：

维度	传统 if-else 程序	AI Agent
输入处理	只能处理预定义的格式（如 JSON、表单字段）	能理解自然语言，包括模糊表达、口语化表达
决策逻辑	手写规则，每个分支都要提前写好	LLM 推理，能处理"没遇到过"的情况
工具调用	调用顺序固定，逻辑写死在代码里	自主决定调用哪个工具、什么时候调用、用什么参数
错误处理	只能处理预定义的错误类型	能理解错误信息，尝试不同的解决策略
扩展性	加新功能需要改代码、加分支	加新工具只需注册，Agent 自己会判断什么时候用
学习能力	无，代码不会自己进化	通过反思和记忆积累经验，越用越好
开发成本	规则简单时成本低，规则复杂时成本爆炸	初始开发成本中等，维护成本低（不需要反复改规则）

这个表格揭示了一个反直觉的结论：任务越复杂、越需要灵活性，Agent 相对于传统程序的性价比越高。 一个简单的表单验证，Agent 是杀鸡用牛刀；但一个需要理解自然语言、处理各种意外情况的智能客服，Agent 的成本远低于你手写几千条 if-else 规则。

什么时候该用 Agent，什么时候用 if-else 就够了？

如果你的任务规则明确、不会变化、不需要理解自然语言------比如"每天晚上 6 点自动备份数据库"------用传统 if-else 或者 cron job 就够了，不要杀鸡用牛刀。Agent 虽然强大，但有成本：每次调用 LLM 都要花钱，而且响应速度比传统程序慢。如果简单的 if-else 能搞定，就别上 Agent。

还有一个很有意思的观点：Agent 和传统程序的关系，不是"替代"，而是"升级"。 就像汽车不是替代了马车，而是升级了马车------马车还是有用的，在某些场景下（比如景区观光）比汽车更合适。同理，传统程序在很多场景下仍然是最优解，Agent 只是在传统程序搞不定的场景下，提供了新的可能性。

作为前端工程师，你可能会发现一个有意思的现象：你写的很多业务逻辑，其实就是在做"弱化版的 Agent" 。比如你写了一个"智能搜索"组件------用户输入关键词，你根据关键词做模糊匹配、排序、高亮，然后展示结果。这个过程本质上就是"感知（用户输入）→ 决策（匹配什么、怎么排序）→ 行动（渲染结果）"。只不过你的决策逻辑是手写的 if-else 和正则，而 Agent 的决策逻辑是 LLM 推理。理解了这一点，你再去看 Agent 开发，就不会觉得陌生了------它只是把你手写的决策逻辑，换成了 LLM 自动推理。

什么场景适合用 Agent？一张总结表

聊了这么多概念，你可能会想："道理我都懂了，但回到实际项目里，我怎么判断这个功能该不该用 Agent？"

这里有一张实用的判断表。你可以把它当成一个检查清单，做技术选型的时候对着看。

场景	适合 Agent？	原因
智能客服	非常适合	需要理解自然语言、需要灵活应对各种问题、需要查知识库、需要多轮对话。Agent 的 ReAct 模式天然适合。
代码生成 / Code Review	非常适合	需要理解需求、查询文档、生成代码、运行测试、根据错误修改。Plan-and-Execute 或 Reflexion 模式效果好。
数据分析报告	适合	需要查询数据、分析趋势、生成图表、撰写结论。Plan-and-Execute 模式很适合这种"多步骤、有明确产出"的任务。
定时数据备份	不适合	规则固定，不需要理解自然语言，不需要灵活决策。用 cron job + shell 脚本就够了，上 Agent 是浪费钱。
表单验证	不适合	规则明确（手机号 11 位、邮箱格式校验），判断逻辑简单。用前端表单校验库（如 VeeValidate）更高效。
内容推荐	部分适合	如果推荐逻辑简单（按标签匹配），用传统算法。如果需要理解用户"模糊偏好"（比如"最近想看点轻松的东西"），Agent 有优势。
自动化测试	部分适合	回归测试用传统 E2E 框架（Playwright、Cypress）。探索性测试、根据页面变化自动调整测试用例，可以用 Agent。
邮件自动分类	适合	需要理解邮件内容、判断意图、提取关键信息。Agent 的正则或传统分类器更灵活，能处理"意料之外"的邮件格式。
个人日程管理	非常适合	需要理解自然语言（"明天下午跟老王喝咖啡"）、需要多工具协作（查日历、发提醒、导航）、需要记忆用户偏好。

一个简单的判断公式：如果你的任务需要"理解""判断""灵活应变"中的任意一个，就考虑 Agent。如果你的任务规则明确、输入固定、不需要动脑子，传统程序更合适。

另外，Agent 不是"全有或全无"的------你可以在传统程序里嵌入 Agent 作为其中一个环节。比如你的订单系统整体是传统架构，但"理解用户退货原因并自动分类"这个环节，可以用 Agent 来做。这种"混合架构"反而是目前最主流的做法。

说到混合架构，给你一个具体的例子。假设你在做一个电商后台管理系统（Vue3 + NestJS），里面有一个"智能运营助手"模块。这个模块的整体架构可能是这样的: s

你看，大部分功能还是传统代码在跑，Agent 只负责那些"需要动脑子"的环节。这种架构的好处是：传统部分稳定可靠（不会出现 LLM 幻觉），Agent 部分灵活智能（能处理非结构化输入），两者各司其职，互不干扰。

用 Vue3 写一个 Agent 可视化 Demo

概念讲完了，现在我们来点实际的。作为一个前端，看 Agent 的"思考过程"最好的方式是什么？当然是把它可视化出来。下面是一个 Vue3 组件，它模拟了 Agent 的 ReAct 循环，并把每一步的"思考-行动-观察"都展示在页面上。

这个 Demo 展示的是"帮用户订机票"的完整过程，你可以在浏览器里看到 Agent 每一步在想什么、做了什么、观察到了什么结果。

js 复制代码

<!-- AgentThinkingDemo.vue -->
<script setup lang="ts">
import { ref, computed } from 'vue'

// 模拟 Agent 的每一步
interface AgentStep {
  type: 'think' | 'act' | 'obs' | 'done'
  content: string
  timestamp: number
}

const steps = ref<AgentStep[]>([])
const isRunning = ref(false)
const currentStep = ref(0)

// 预定义的 Agent 执行步骤（模拟）
const agentSteps: AgentStep[] = [
  {
    type: 'think',
    content: '用户说"帮我订一张下周三从北京到深圳的机票"，我需要先搞清楚：出发城市是北京，目的地是深圳，日期是下周三（2024-07-17）。不知道用户偏好，先查一下历史记录。',
    timestamp: 0,
  },
  {
    type: 'act',
    content: '调用 getUserPreferences("user_001")，读取用户偏好设置...',
    timestamp: 1,
  },
  {
    type: 'obs',
    content: '获取到偏好：喜欢上午航班，偏好国航，预算 1500 以内，座位偏好靠过道，上次坐过 CA1303。',
    timestamp: 2,
  },
  {
    type: 'think',
    content: '用户偏好上午航班，预算 1500 以内。现在调用航班查询 API，查 2024-07-17 北京到深圳的航班。',
    timestamp: 3,
  },
  {
    type: 'act',
    content: '调用 searchFlights({ from: "北京", to: "深圳", date: "2024-07-17" })...',
    timestamp: 4,
  },
  {
    type: 'obs',
    content: '查到 3 个航班：CA1303（09:00，1280元）、CA1305（14:00，1450元）、CZ3194（08:00，1100元）。',
    timestamp: 5,
  },
  {
    type: 'think',
    content: '用户偏好上午航班，CA1303 和 CZ3194 都符合。CA1303 用户坐过，且有靠过道座位。CZ3194 便宜 180 块但座位不确定。推荐 CA1303 给用户确认。',
    timestamp: 6,
  },
  {
    type: 'act',
    content: '用户确认选择 CA1303，调用 bookFlight({ flight: "CA1303", date: "2024-07-17", seat: "aisle" })...',
    timestamp: 7,
  },
  {
    type: 'obs',
    content: '下单成功！订单号 BK20240701001，CA1303，2024-07-17 09:00，北京首都 T3 → 深圳宝安，靠过道座位，1280元。',
    timestamp: 8,
  },
  {
    type: 'act',
    content: '调用 sendEmail，发送确认邮件到 user_001@company.com...',
    timestamp: 9,
  },
  {
    type: 'done',
    content: '全部完成！机票已预订，确认邮件已发送。总耗时 3.2 秒。',
    timestamp: 10,
  },
]

const totalSteps = agentSteps.length
const progress = computed(() =>
  totalSteps > 0 ? Math.round((currentStep.value / totalSteps) * 100) : 0
)

const labelMap: Record<string, string> = {
  think: '思考',
  act: '行动',
  obs: '观察',
  done: '完成',
}

// 模拟逐步执行
async function startDemo() {
  if (isRunning.value) return
  isRunning.value = true
  steps.value = []
  currentStep.value = 0

  for (let i = 0; i < agentSteps.length; i++) {
    await new Promise(r => setTimeout(r, 800 + Math.random() * 600))
    steps.value.push(agentSteps[i])
    currentStep.value = i + 1
  }

  isRunning.value = false
}

function resetDemo() {
  steps.value = []
  currentStep.value = 0
  isRunning.value = false
}
</script>

<template>
  <div class="agent-demo">
    <!-- 标题栏 -->
    <div class="agent-demo-header">
      <span class="dot r"></span>
      <span class="dot y"></span>
      <span class="dot g"></span>
      <span>Agent ReAct 循环可视化 ------ 订机票 Demo</span>
    </div>

    <!-- 步骤展示区 -->
    <div class="agent-demo-body" ref="scrollContainer">
      <div v-if="steps.length === 0" style="color:var(--muted);text-align:center;padding:2rem;">
        点击"开始演示"查看 Agent 的完整思考过程
      </div>

      <div
        v-for="(step, index) in steps"
        :key="index"
        :class="['agent-step', step.type]"
      >
        {{ step.content }}
      </div>
    </div>

    <!-- 进度条 -->
    <div v-if="steps.length > 0" style="padding: 0 0.75rem; margin-bottom: 0.3rem;">
      <div style="display:flex;justify-content:space-between;font-size:0.7rem;color:var(--muted);margin-bottom:0.2rem;">
        <span>步骤 {{ currentStep }} / {{ totalSteps }}</span>
        <span>{{ progress }}%</span>
      </div>
      <div style="height:4px;background:var(--bg2);border-radius:2px;overflow:hidden;">
        <div
          :style="{
            height: '100%',
            width: progress + '%',
            background: 'var(--accent)',
            transition: 'width 0.3s ease',
            borderRadius: '2px'
          }"
        ></div>
      </div>
    </div>

    <!-- 控制按钮 -->
    <div class="agent-demo-controls">
      <button @click="startDemo" :disabled="isRunning">
        {{ isRunning ? '运行中...' : '开始演示' }}
      </button>
      <button @click="resetDemo" :disabled="isRunning">重置</button>
      <span
        class="status"
        :class="{ running: isRunning }"
      >
        {{ isRunning ? 'Agent 正在思考...' : steps.length > 0 ? '演示完成' : '就绪' }}
      </span>
    </div>
  </div>
</template>

这个 Demo 虽然简单，但它把 Agent 的 ReAct 循环可视化出来了。你可以很直观地看到：Agent 不是一步到位的，而是经过了"思考 → 行动 → 观察 → 再思考 → 再行动 → 再观察"的循环。每一步的观察结果都影响下一步的决策，直到任务完成。

在实际项目中，这个组件可以接入真实的 Agent 后端------通过 SSE 流式接收 Agent 每一步的思考过程，然后实时渲染到页面上。我们在第 13 章会详细讲怎么用 Vue3 做一个完整的 Agent 对话界面，包括流式输出、思考过程展示、工具调用可视化。

前端做 Agent 可视化的天然优势

Agent 的思考过程本质上是一系列"状态变化"------就像 Vue3 的响应式数据。你用 Vue3 的 ref 和 reactive 管理 Agent 的状态，用 v-for 渲染每一步的思考过程，用 watch 监听状态变化并触发 UI 更新。这套模式你每天都在用，只是以前渲染的是"用户列表"，现在渲染的是"Agent 思考步骤"。本质上没有区别。

你可以把这个 Demo 的代码拷到你的 Vue3 项目里跑一下，看看效果。你会发现，Agent 的每一步思考、每一次工具调用、每一次观察结果，都清晰地展示在页面上。这种可视化不仅对开发者有用（调试 Agent 行为），对最终用户也很有价值------用户能看到 Agent 在干什么，而不是对着一个转圈圈的加载动画干等。

在实际项目中，这个组件的 agentSteps 数组不会像 Demo 里这样写死，而是通过 SSE（Server-Sent Events）从后端实时推送过来。后端每执行一步 ReAct 循环，就向前端推送一个事件，前端收到后 append 到 steps 数组里，Vue 的响应式系统自动更新 UI。整个流程就像聊天应用里的"打字中"效果------只不过展示的不是"对方正在输入"，而是"Agent 正在思考"、"Agent 正在调用工具"、"Agent 正在观察结果"。

另外，这个 Demo 还隐藏了一个很重要的设计原则：Agent 的每一步都应该是"可展示"的。如果你的 Agent 系统是一个黑盒------用户提一个问题，等 10 秒，得到一个结果------那用户体验会很差。用户不知道 Agent 在干什么，不知道它是不是卡住了，不知道它做得对不对。把每一步都展示出来，用户就能理解 Agent 的工作过程，建立信任感。这也是为什么 ChatGPT 和 Claude 都把"思考过程"展示给用户看------不是技术限制，而是产品设计。

如果你想让这个 Demo 更真实一点，可以试着把 agentSteps 换成从后端 API 获取------比如让你的 NestJS 后端跑一个真正的 Agent，每一步通过 SSE 推送给前端。这样你就能在浏览器里看到真实的 Agent 思考过程，而不是模拟数据。我们会在第 9 章和第 13 章详细讲怎么实现这个。

本章小结

这一章我们聊了很多，从订机票的场景出发，一步步拆解了 Agent 的核心概念。现在回顾一下，你应该能回答这几个问题：

Agent 和 Chatbot 的区别是什么？ Chatbot 给你答案，Agent 给你结果。Agent 能自己动手干活，而不仅仅是聊天。
Agent 的四个核心要素是什么？ 感知（搞清楚状况）、决策（想清楚怎么干）、行动（动手干活）、记忆（吃一堑长一智）。四个缺一不可。
Agent 是怎么工作的？ 通过 ReAct 循环------思考、行动、观察，不断循环，直到任务完成。走一步看一步，动态调整。
Agent 有哪几种设计模式？ ReAct（边想边做）、Plan-and-Execute（先规划再执行）、Multi-Agent（多 Agent 协作）、Reflexion（反思自省）。每种模式有自己的适用场景。
什么时候该用 Agent，什么时候不该用？ 需要"理解""判断""灵活应变"的任务，用 Agent。规则明确、输入固定的任务，用传统程序就够了。

搞懂了这些概念，你已经有了 Agent 开发的"世界观"。从下一章开始，我们要深入到技术细节里------第一站，先聊聊 Agent 的"大脑"：大语言模型（LLM）。毕竟 Agent 再聪明，也得靠 LLM 来提供推理能力。如果 LLM 是引擎，Agent 就是整辆车，我们要先搞清楚引擎是怎么工作的，才能造出一辆好车。

思考题：检验一下你理解了多少

在进入下一章之前，给你留几个思考题。这些问题没有标准答案，但如果你能用自己的话回答出来，说明你真的搞懂了 Agent 的核心概念：

你平时用的 ChatGPT，算不算 Agent？ 提示：想想 ChatGPT 能不能自己查航班、自己下单、自己发邮件。如果不能，它缺了什么？
如果你要做一个"自动帮你点外卖"的 Agent，它的 ReAct 循环每一步大概是什么？ 试着写出"思考 → 行动 → 观察"的循环过程。
你的 Vue3 项目里，有没有哪个功能是"用 if-else 实现很痛苦，但用 Agent 实现会很舒服"的？ 试着找找看，这可能就是你第一个 Agent 应用的最佳切入点。
如果你做一个"智能代码审查"的 Agent，你选哪种设计模式？ReAct 还是 Plan-and-Execute？ 想想代码审查的流程------先看什么、后看什么、是不是可以提前规划好。
Agent 的最大风险是什么？ 提示：想想 LLM 可能产生的幻觉，以及 Agent 如果执行了错误的行动可能造成什么后果。

如果有些问题你暂时回答不上来，没关系------后面的章节会逐个深入。现在你只需要记住一件事：Agent 不是魔法，它只是把"思考、决策、行动、观察"这四个步骤自动化了。 你搞懂了这四个步骤，剩下的就是代码实现。

给前端同学的一碗"定心丸"

在结束这一章之前，我想专门跟前端同学说几句掏心窝子的话。

你可能觉得 Agent 开发离自己很远------什么 LLM 推理、工具调用、记忆管理、ReAct 循环，听起来像是另一个世界的东西。但如果你仔细想想，这些东西跟你每天在做的"组件化开发"、"状态管理"、"数据流编排"、"异步处理"到底有多大区别？

Agent 的"工具"就是前端里的"组件"------每个组件有自己的输入（props）和输出（emit），每个工具也有自己的输入（参数）和输出（返回值）。Agent 的"记忆"就是前端里的"状态管理"------Pinia Store 存全局状态，向量数据库存长期记忆，本质上都是"把数据存起来，需要的时候取出来"。Agent 的"ReAct 循环"就是前端里的"异步流程"------你写一个复杂的表单提交流程，先校验、再调接口、根据返回结果决定下一步，跟 Agent 的"思考 → 行动 → 观察"有本质区别吗？

你用 Vue3 这些年积累的工程化思维------模块化、可复用、可测试、可维护------放到 Agent 开发里，一样适用。而且因为 Agent 开发还很新，很多"最佳实践"还没形成共识，你完全有机会在这个领域里定义自己的方法论。

所以，别怕。Agent 开发不是什么高深莫测的领域，它只是软件开发的一个新分支。你连 Vue3 的响应式原理、虚拟 DOM diff 算法、Composition API 的设计哲学都能搞懂，Agent 这点东西，真的不算什么。

好了，鸡汤喝完了，干活。下一章，咱们直接开撸 LLM------看看这个"大脑"到底是怎么运转的。