AI Agent是什么？考生、火车、司机三个比喻讲透核心区别

AI Agent被吹成下一个风口，可它跟你天天用的ChatGPT到底差在哪？大部分人答不上来。这篇文章借用B站UP主的一套精妙比喻——考生、火车、司机，把大语言模型、AI工作流、AI Agent这三个容易混淆的概念彻底讲清楚，并通过Make平台上的真实任务对照演示，帮你建立一张能装进脑子的AI进化图。

LLM：等着发卷子的考生

我们从最熟悉的开始。ChatGPT、Gemini、Claude背后都使用大语言模型（LLM）。它非常擅长生成和改写文字——写邮件、改文案、润色，都是一把好手。这里要区分两个概念：模型是一种能力，聊天产品是把能力装进界面，产品还可能额外接入联网、日历和定时任务。

但一个没有接外部工具的单次模型调用，有两个明显限制。

第一，没有提供的信息它不会自动知道。让它写封咖啡邀请，它能写得客客气气；但再问「下一场约会是什么时候」，它就需要你的日历资料。在Make中，同一条提示词要求写不超过45字的咖啡邀请，并回答下一场约会时间。运行后，模型先写出邀请，再明确说明「我无法访问你的日历，无法确定下一场约会时间」。前一句展示协作能力，后一句说明信息边界——这正是模型没有连接日历工具时的诚实表现。

第二，它需要被触发。在单次调用里，你不发消息、也没有外部程序触发，它不会自己开始下一轮。定时提醒和后台监控需要产品或程序另外安排。

于是第一个比喻诞生了：LLM像坐在考场里等着发卷子的考生。你不发卷（不给prompt）它不会开始答题；卷子没附日历，它也不该把猜测当答案。

AI工作流：铺好铁轨的火车

那怎么让AI知道日程？答案是给它立规矩：以后一问日程，程序先去已授权的日历查一遍，把记录交给模型，再由模型组织回答。这么一套固定流程串起来，就叫AI工作流——先后顺序、调用哪个接口、数据往哪里传，都由人事先安排。它适合重复、规则明确的任务。

你可能没注意到它的局限性：如果只配置了日历工具而没有配置天气工具，你再问「那天天气怎么样」，它就无法保证答出来，可能报错或走预设兜底分支。

第二个比喻：工作流像铁轨上的火车。火车跑得再快、车厢再多，也沿着铺好的轨道走。你可以铺岔道、加条件判断，但这些路线和规则仍是人提前设计的。

这里UP主敲了一个重点：串上几百步也不能只凭复杂就叫自主Agent。要看下一步是「固定规则直接指定」，还是「模型根据目标和反馈自主选择」。

RAG：先查再答，但不等于自主

顺带解释一个常见术语——RAG（检索增强生成），大白话就是「先查再答」：找到相关资料，交给模型，再生成有依据的答案。检索增强能改善回答质量，但本身并不意味着模型会自主选择行动。比如一个新闻文案流程：查资料→模型总结→写成社交文案，每天早上8点自动出发，听起来很智能，但这些步骤仍可能全是人排好的。如果文案不好笑而流程没配置审稿修订，你还得回去手动改指令。

RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路是弥补LLM的「知识截止日期」和「私有信息缺失」两大短板。模型在训练完成后，参数就固定了，无法自动获知训练数据之后发生的事，也不知道你企业内部的文档。RAG的做法是在模型回答之前，先从外部知识库（可以是向量数据库、搜索引擎或文件系统）检索与问题相关的片段，将这些片段作为上下文一并送入模型，再由模型综合生成答案。这样模型的回答就有了可追溯的来源，幻觉（hallucination）也相对减少。

向量数据库是RAG系统中常见的检索后端：它把文本转化为高维数值向量，用相似度搜索找到语义最接近的段落，而不是简单的关键词匹配，因此即使用户的提问措辞和原文不同，也能找到相关内容。理解这一点有助于明白，为什么RAG能让模型「知道」某份内部报告里的数据——但检索策略、分块大小、向量模型的选择都会影响最终质量，并非接上就万事大吉。

AI Agent：自己看地图选路的司机

现在做一次真实对照：读取Make AI Agents介绍网页，整理三个中文要点。两套方案使用同一份资料、同一个目标，避免把题目差异误当成能力差异。

固定工作流方案连接三个模块：HTTP读取网页 → HTML转文本提取正文 → AI Toolkit生成摘要。UP主提醒：不要只看连线，还要检查每一步输入来自哪里、输出交给谁。连线存在不代表数据映射正确，引用错了也可能生成一段通顺却错误的答案。

Agent方案的关键变化是——把某些行动选择交给了模型。原来写死的下一步，现在可以根据目标、可用工具和返回结果来决定。但这不等于把所有权限都交给它：你依然给出明确目标（根据指定网页整理三个中文要点），并提供工具及用途，模型在这些工具之内选择怎样取得资料，再依据返回内容作答。

第三个比喻：Agent是自己看地图、根据路况选路线的司机。你给目的地，也划定不能去的地方，它能选路，但要遵守交通规则——也就是权限、预算和停止条件。

这里UP主给出了一个极其实用的验证原则：工具选择究竟有没有发生，要查执行记录。它说「我会查资料」和记录里真的出现读取工具调用，是两回事。不要把一段描述思考的文字，当成已经执行操作的证据。本次运行记录中确实出现了「Read Make Agent Guide」工具调用，随后才生成回答，这才证明这一轮真的使用了资料工具。

Agent（智能体）这一概念在AI领域的定义核心是「感知环境、做出决策、执行动作、观察结果、再循环」——与只做单次输入输出的模型调用形成本质区别。当前主流的LLM-based Agent架构通常包含四个组件：规划模块（将大目标拆解为子任务）、记忆模块（短期上下文窗口加长期外部存储）、工具集（可调用的外部接口，如搜索、代码执行、日历API）、行动执行模块（真正发出API请求或操作界面）。

「自主」的程度因实现而异：有些Agent只能在预设工具列表内选择调用顺序；更高级的实现可以动态生成代码或调用未见过的API。正因为自主度差异很大，评估一个产品是否真的是Agent，不能看界面是否花哨，而要看它在多步骤任务中是否真实发生了「模型根据中间结果改变后续行动」这件事，也就是文章反复强调的「查执行记录」。

ReAct：推理与行动的循环

ReAct把Reason（推理）和Act（行动）结合起来，大白话是：判断当前情况→调用工具→观察返回结果→再决定下一步。重点是循环，不是界面上写着「想」和「做」就算完成了。

遇到超时、空资料或权限不足，它可能调整，也可能该停下来请人处理——不能无限执行，更不能编造结果。可靠的实现要设置调用上限和明确的退出条件。

写审改循环：给自己配个严苛编辑

Agent还能把检查和修订纳入任务：写完第一版→调用审稿工具挑问题→读取意见修改，整个「写、审、改」循环不用你来回复制反馈。这就是第四个画面——作者给自己配了个严苛的编辑。

但满意不该是空话。审稿标准要说明：读者是谁、术语是否清楚、需不需要生活例子、什么情况下可以结束。实测中，初稿写道「AI Agent是一种以明确目标为导向、能调用工具的智能系统」，审稿反馈精准指出「缺少日常生活例子、语言偏抽象、需要更简洁」。修订版随即加入了「帮你排一天日程、自动调出地图与提醒工具」的例子。

这里有个细节值得警惕：修订稿里提到的地图与提醒，只是输出中的解释性例子，不代表本次演示真的接入了这些工具。验收时要并排看初稿、审稿意见、修订稿，检查问题是否真被修好，有没有为了通俗而改变原意。

ReAct是2022年提出的一种提示范式（出自论文《ReAct: Synergizing Reasoning and Acting in Language Models》），它的贡献在于打通了「思维链」（Chain-of-Thought）和「工具调用」之间的隔阂。纯思维链让模型一步步推理，但推理仍在模型内部进行，无法获取外部信息；而ReAct要求模型在每一轮显式输出「Thought（我现在要做什么）→ Action（调用哪个工具、传什么参数）→ Observation（工具返回了什么）」，然后基于Observation决定下一个Thought，如此循环直到任务完成或触发停止条件。

这种可见的推理-行动轨迹有两个实际意义：一是方便调试，开发者能逐步追踪模型「走错在哪一步」；二是降低幻觉风险，因为模型被迫在拿到真实返回结果之后才能继续推理，而不是凭空捏造后续步骤。文章中提到的「查执行记录」正是在验证这条Thought-Action-Observation链条是否真实发生，而非只停留在Thought层面的自述。

简单界面不应掩盖能力边界

最后一个视频检索的例子很有启发。在Vision中输入「雪中跳跃的滑雪者」，返回一组候选镜头——但返回列表只是候选，不是保证正确的答案，有些镜头只符合部分描述，你仍要核对人物、动作和环境。

UP主强调：不能只凭一个搜索框就断定后台一定是Agent。好的工具可以把复杂处理放在后台、让前台简单，但使用者仍要知道：输入是什么、资料来自哪里、实际调用了什么、结果是否经过检查。简单界面不应掩盖能力边界。

记住三个问题

回到三个比喻：考生代表根据输入生成回答的模型；火车代表按预设规则执行的工作流；司机代表围绕目标自主选择行动的Agent。而「作者与编辑」的画面提醒我们：执行之后还要检查和修订。

以后遇到号称Agent的产品，先问三个问题：

1. 能用什么工具？
2. 下一步由谁决定？（固定规则还是模型自主）
3. 结果不达标时，是自动检查调整，还是要你手动接手？

看实际执行记录，永远比看宣传语更有用。你定目标，它选步骤、用工具、检查结果再调整，重要操作由你确认——这，才是真正的AI Agent。