AI Agents 是什么？Jeff Su 超 400 万播放视频深度拆解

2025 年 4 月，Jeff Su 在 YouTube 发布了 AI Agents Clearly Explained，截至 2026 年 9 月播放量约 489 万。以下基于该视频及配套文章，拆解 AI Agent 的三层进化路径。

2025 年 4 月 8 日，Jeff Su 发布了一支 10 分 09 秒的视频，配了一篇面向非技术读者的说明文章。它出圈不是靠新概念，而是把三个被营销话术搅浑的概念重新排了顺序——LLM、AI Workflow、True Agent。

很多入门文章把"能调工具"和"能自主决策"混为一谈，初学者以为接上 RAG、加几个 API、套一个框架，就已经做出了 Agent。Jeff Su 的讲法更朴素：差别在于谁决定下一步。

先看结论：差别在谁决定下一步

视频的完整时间线是：00:00 引入 “AI vs. AI Agents”，01:04 讲 Level 1（LLM），02:17 讲 Level 2（Workflow），05:26 讲 Level 3（Agent），07:48 用一个实例收尾，09:10 做总结。Jeff Su 的三层划分可以浓缩成一张表：

最关键的一列是"谁决定下一步"。如果下一步永远由人预先写死，例如先查日历、再查天气、再生成邮件，它更接近工作流；如果模型能根据当前结果判断该查什么、该不该重试、该不该换工具、是不是已经完成目标，它才进入 Agent 的语境。

在 Jeff Su 的讲法里，RAG 属于工作流能力：先查资料，再作答。放到更广义的工程实践里，RAG 当然可以成为 Agent 的子能力，但"会检索"不等于"会自主决策"。

Level 1：LLM 为什么还不算 Agent

视频位置：01:04 起。

Jeff Su 把起点放在大语言模型上——大多数人第一次接触 AI 都是通过 ChatGPT、Claude 或 Gemini 这样的对话界面。

LLM 的基本模式是"输入变输出"。你给它一个提示，它基于训练数据生成回复。这类系统已经足够强大，能写邮件、改文案、总结会议纪要，但仍有两个天然边界：

• 它不知道你的私有世界。你的日历、公司内部文档、CRM 数据、私有 API，不会自动出现在模型上下文里。
• 它本身是被动的。没有新的输入，它不会主动去查资料、执行动作、验证结果。

Jeff Su 给这一层贴的标签是 “passive systems”。他在配套文章里写得很直白：“LLMs are passive—they wait for your prompt and then respond."（大语言模型是被动的：等你给提示，然后作答。）只根据一个 prompt 生成文字的模型，仍然是一个更强的输入输出系统，算不上能围绕目标持续推进任务的执行体。

一个常见误解是：很多产品里的聊天模型已经能调工具了，但那通常是外层产品为模型补上了工具层、权限层和执行层，不等于基础模型天然具备了行动能力。想清楚这层边界，后面看 workflow 和 agent 才不会混淆。

Level 2：AI Workflow 已经很有用，但决策者仍然是人

视频位置：02:17 起。

视频第二层讲的是 AI Workflow。Jeff Su 的判断：工作流能连上外部工具、能访问外部信息、也能完成多步任务，但路径仍然是人预先写好的。

他在配套文章里演示了一个自己照 Helena Liu 教程、用 make.com 搭的内容生产工作流：先在 Google Sheets 里汇总新闻，再用 Perplexity 摘要，再让 Claude 按他定制的提示词起草 LinkedIn 和 Instagram 帖子，每天早上 8 点定时运行。他还特意补了一句：如果最终帖子不满意——比如不够有趣——他必须手动去改给 Claude 的提示词，试错迭代发生在人身上，不在系统里。这套自动化很有价值，但它仍然不是 Agent：执行顺序、分支条件和失败后的处理方式，都是人提前规定好的。

控制逻辑写在人手里，系统再复杂，也还是 workflow。

RAG 也适合放在这里理解。Jeff Su 把它描述为帮模型在回答前"把东西查一遍"的过程，并明确说 RAG 本质上是一种 AI workflow。这个定位对入门者很友好。但要看到，RAG 并不等于完整记忆系统，它更像一个检索能力：

• 它擅长把外部知识在回答前拉回上下文。
• 它不天然等于跨会话长期记忆。
• 它当然可以被嵌入 Agent，但单独存在时更像一条检索增强工作流。

Workflow 已经足以解决大量真实问题，没必要因为"Agent"这个词更热，就把所有自动化都往 Agent 上靠。

Level 3：True Agent，把"下一步怎么做"交给模型

视频位置：05:26 起。

Jeff Su 对 Agent 的定义并不复杂：给系统一个目标之后，模型自己决定如何拆解任务、何时调用工具、是否需要迭代，直到目标完成或达到停止条件。

这比"能不能调 API"更接近工程实质。决策权一旦从人手里转到模型手里，会出现三个变化：

• 它不再只能沿着一条预设路径走下去，而是会根据中间结果选择下一步。
• 它会把工具调用当成解决问题的一部分，而不是固定脚本中的一个节点。
• 它需要在循环里判断任务是否完成、是否失败、是否需要重试。

Jeff Su 用 Andrew Ng 展示过的视觉代理示例来解释：用户只给出一个目标——找出视频里出现滑雪者的片段——系统要自己判断什么是滑雪者、如何搜索、如何筛选、如何索引，最后再返回结果。这里真正发生变化的，是模型开始在工具和环境之间做决策。

这也是 ReAct 框架被反复提及的原因。ReAct 论文的标题就很直接：ReAct: Synergizing Reasoning and Acting in Language Models。它强调的是把推理轨迹和动作交替组织起来，让模型一边根据上下文更新判断，一边与外部环境交互。

不过要避免拟人化。说 Agent"会思考"很顺嘴，但工程上更准确的说法是：模型在 prompt、状态和工具反馈的约束下，交替生成推理痕迹与行动决策。把它说成自主意识，没有必要，也不准确。

把视频里的关键词放回技术语境

Jeff Su 的视频适合作为第一层认知框架，但真要往下做，几个关键词还得说得更细。RAG 和 ReAct 视频里都点了名，tool use 是三层框架里 Agent 的动手部分；memory 和多智能体是往下走马上会遇到的词，视频没有展开。下面挨个说清。

ReAct 的重点：推理和行动交替成一条轨迹

ReAct 论文（Yao et al., 2022）把"推理"和"行动"拆进同一条循环，每一步交替走三个环节：

1. Thought（推理）——模型解释自己现在为什么做这一步，以及上一步结果意味着什么。
2. Action（行动）——模型选一个工具、填好参数，触发一次调用。
3. Observation（观察）——工具返回的结果，重新喂回上下文，驱动下一轮推理。

循环反复，直到模型判断目标已完成，或达到停止条件。它不只是"会调用工具"的别名——推理和动作放进同一条轨迹，才有了可追踪、可回放的过程记录。

# 一个去掉细节的 ReAct 示意循环
while True:
    thought = model.generate(thought + action + observation)   # 想
    action = parse_action(thought)                              # 决定调用什么
    if action == "finish":
        break
    observation = execute_tool(action.get("name"), action.get("args"))  # 观察
    context.append(observation)

这么拆，就能看出它和另外两种写法的差别。纯思维链（chain-of-thought, CoT）只做推理、不做动作，适合纯文本问答；纯规划式（先规划完再执行）遇到中间结果和预期不符时会卡住。ReAct 把两者交替起来，让模型一边根据观察修正判断，一边推进任务——这正是 Jeff Su 口中"根据中间结果选择下一步"的工程实现。

论文到工程落地还有一层差异。很多生产系统不会把完整 thought 直接暴露给用户，只保留结构化行动、关键摘要和执行日志，以降低 token 成本、泄露风险和调试噪音。这不违背 ReAct 的思想，只是工程折中——轨迹仍在，对外只露必要的部分。

Tool Use 的难点：让调用更可靠

工具调用这一层经常被讲得过于轻松。真正的难点不在于"把 API 挂上去”，而在于如何减少误选工具、错误参数和幻觉式调用。Gorilla 这类研究之所以重要，就是因为它把问题讲得很具体：GPT-4 这个量级的模型在写 API 调用时，失败集中在两处——给不准输入参数，以及幻觉出错误的调用用法。Gorilla 给出的解法是微调加文档检索器：让模型能适应测试时更新的 API 文档，幻觉问题因此明显缓解。

早一点的 Toolformer（Schick et al., 2023）换了个思路：让模型自己学会"在什么位置、调用什么工具能拿到有用信息"，用结果来验证该不该调用。它指向的事实是，工具调用不是把函数列表塞进 prompt 就完事，“什么时候该调、返回怎么用"本身就需要训练。这两条研究线合起来，说明工具层要解决的不只是接线，还有选择和校验。

到生产环境，工具层至少要补上这些东西：

• 明确的工具描述和参数模式（JSON Schema），让模型少猜参数。
• 输入校验、超时、重试和失败回退；对幂等的操作用重试，对非幂等的操作要避免重复副作用。
• 权限边界，避免模型"想调什么就调什么”——只暴露任务需要的工具。
• 记录每次调用的上下文，方便回放和评估：参数、返回、耗时、token 消耗。

其中"权限边界"和"幂等"经常被忽略，却又最容易出事。前者决定了模型失控时能造成多大损失，后者决定了网络抖动时系统会不会重复扣款、重复发消息。

Memory 不只有向量数据库

memory 在视频和配套文章里都只是一笔带过，但任何 Agent 项目做到第二步就会撞上它。把 memory 等同于向量数据库，读者容易误以为只要上了 Vector DB 就解决了记忆问题。更合理的拆法至少有三层：

向量数据库主要适合做语义检索，不是所有记忆都该往里扔。“这次任务执行到第几步了"更像状态；“这个用户偏好什么写作语气"更像长期档案；“这份规范文档的相关段落是什么"才更适合走检索。

上下文窗口再大也有限。硬把所有历史塞进去，token 成本、检索噪声和延迟都会涨。所以工程上通常不是"记不记”，而是"什么进窗口、什么进存储、什么被压缩或遗忘”。近几轮对话进窗口，跨会话的用户偏好进长期存储，中间态用摘要压缩。判断依据是：这条信息在当下这一步是否真的需要被模型看到。

Multi-Agent 不是入门默认项

Jeff Su 的视频面向初学者，没把多智能体协作当主轴，这个取舍是对的。很多任务并不需要多 Agent——单 Agent 加上几个可靠工具、清晰状态和评估回路，已经足够解决问题。

多 Agent 真正适合的是角色明显分工、任务天然并行、或需要多视角互审的场景。否则它带来的往往是更复杂的调度、更多成本和更难排查的故障链路。

Agentic Workflows 的四个可复用模式

Jeff Su 视频里引用的 Andrew Ng 例子，背后是一套被反复验证的框架。Andrew Ng 在 2024 年初的分享里，把 agentic workflow 归纳为四种模式：

1. 反思（Reflection）——让模型先产出，再自己审视、修改。多一轮"这里哪里不对"的复查，往往比一次憋出完美答案更稳。
2. 工具调用（Tool Use）——把搜索、计算、执行代码等能力交给模型，按需调用。就是前文 Tool Use 那一层。
3. 规划（Planning）——先把大目标拆成步骤，再逐步执行，遇到意外再调整。对应 Level 3 里"自主拆解步骤”。
4. 多智能体协作（Multi-agent Collaboration）——多个角色分工、互查。

这四种模式并不互斥，也不要求一次全上。单一个"反思"就能带来明显的质量提升，成本却很低。想上手的人，通常从这四种里挑一个最贴合任务的开始，比一上来拼一个完整 multi-agent 框架更划算。

从教学 Demo 到生产系统，还差四层护栏

Jeff Su 的视频把概念讲清楚了，但想把它变成可上线的系统，还要补下面这些工程约束：

其中"调试评估"最容易被拖到最后。Agent 每一步都可能不同，光靠"这次跑通了"不能证明稳定。更实际的做法是攒一个固定的评测集——几十个有标准答案的任务，每次改动模型或工具后统一跑一遍，看成功率涨还是跌，同时盯住 cost 和延迟两项硬指标。没有这组基线，所谓的优化只是感觉，不是度量。

Agent 一旦拿到决策权，系统风险也会同步上升。你不能只给它更多工具，还得给它更严格的约束、可观测性和回退路径。

如果你要自己做一个 Agent，学习顺序最好这样排

很多人一上来就想做多工具、多 Agent、带长期记忆的通用助手，这通常不是最快的切入方式。更稳的顺序：

1. 先做一个只有单目标、单工具或双工具的 workflow。
2. 只有当路径无法稳定写死时，再把"下一步怎么做"交给模型。
3. 只有当上下文明显不够、跨会话知识真的有价值时，再引入长期记忆。
4. 只有当工具生态开始变复杂时，再考虑用标准协议统一接入。

LangChain 和 MCP 可以在这里顺带理解。按官方文档当前的定位，LangChain 提供的是 create_agent——一个最小但高度可配置的 agent harness，模型、工具、提示词和中间件自由组合，更复杂的编排下沉到 LangGraph。MCP 是另一条线，解决的是"AI 应用如何用统一方式连接外部系统"，本质在降低工具接入和迁移成本。两者不冲突，甚至经常同时出现：前者偏编排，后者偏连接。

从入门成本看，原则反而很简单：先 workflow，后 agent；先单 Agent，后多 Agent；评估补齐之前，别急着加工具。

这支视频的价值与边界

Jeff Su 这支视频最实在的地方是把概念压缩得足够清楚：零基础用户能快速建立判断框架，用现实生活里的例子解释控制逻辑，而不是一上来堆框架名词。它把"模型成为决策者"这件事单独拎了出来，这是很多入门材料最容易遗漏的重点。

但它也有边界：它不是一份生产级 Agent 设计指南，没有展开权限、评估、观测、成本这些现实约束。它把 RAG、memory、tool use 都讲成了易于理解的版本，适合入门，但不适合直接拿来做架构决策。真正上手时，仍然要回到论文、官方文档和具体框架实践。

看完它，你未必会写 Agent 代码，但至少能把"会调工具"和"会自主决策"分开，知道接下来该补哪一块。

读者判断：谁该看原视频

• 读本文就够：你想建立 “LLM / Workflow / Agent” 的判断框架，或只想确认"差别在谁决定下一步"这句话为什么成立。本文已把视频三层主线抽出来，并补上了视频没展开的 ReAct、RAG、记忆分层和工程护栏。
• 建议回原视频：你想听 Jeff Su 亲口用日历、天气、内容生产的例子把三层讲一遍，或想核对他对 RAG 和 Agent 的具体措辞。视频 10 分 09 秒，时间成本不高。

延伸阅读

• Jeff Su 原视频：AI Agents, Clearly Explained
• Jeff Su 配套文章：AI Agents for Curious Beginners
• ReAct 论文：ReAct: Synergizing Reasoning and Acting in Language Models
• RAG 论文：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Toolformer 论文：Language Models Can Teach Themselves to Use Tools
• Gorilla 论文：Large Language Model Connected with Massive APIs
• Andrew Ng：What’s next for AI agentic workflows
• LangChain 官方文档总览
• MCP 介绍：What is the Model Context Protocol?

站内继续读

• easy-langent：Datawhale 出品 LangChain/LangGraph 大模型应用开发教程
• AI Agent 的技术栈拆解：从 ReAct 循环到多智能体协作
• Cognee：AI Agent 记忆引擎完全指南
• OpenViking：字节跳动开源的 AI Agent 上下文数据库
• awesome-llm-apps：LLM 应用与 Agent 项目清单

从 LLM 到 workflow，再到真正的 agent，变化最大的是"下一步应该怎么做"的决策权从人手里逐渐转移到模型手里。下次看到宣传里挂着"Agent"字样的产品，先问一句：它的下一步，由谁决定。