Ai Agents Clearly Explained Jeff Su 4M Views

2026-04-29 约 5784 字预计阅读 15 分钟

title: “AI Agents 是什么？Jeff Su 超 400 万播放视频深度拆解” date: 2026-04-29T15:01:00+08:00 slug: “ai-agents-clearly-explained-jeff-su-4m-views” description: “基于 Jeff Su 的热门视频与配套文章，系统拆解 AI Agent 的三层进化路径：LLM、AI Workflow、True Agent，并补充 ReAct、RAG、记忆系统、工具调用与生产实践边界。” draft: false categories: [“视频精读”] tags: [“AI Agent”, “Jeff Su”, “ReAct”, “RAG”, “MCP”]

难度：⭐⭐⭐⭐ 类型：视频精读预计阅读时间：18 分钟适合读者：想弄清楚 “LLM、AI Workflow、AI Agent 到底差在哪” 的产品经理、开发者与重度 AI 用户核心问题：什么时候只是把模型接上工具，什么时候才算真正的 Agent？

Jeff Su 的 AI Agents, Clearly Explained 发布于 2025 年 4 月 8 日，时长 10 分 09 秒，并配有一篇面向非技术读者的说明文章 AI Agents for Curious Beginners。这套内容之所以出圈，不是因为它讲了多少新术语，而是因为它把最容易被营销话术搅浑的三个概念重新排好了顺序：LLM、AI Workflow、True Agent。

这也是这支视频最有价值的地方。很多入门文章会把 “能调工具” 和 “能自主决策” 混为一谈，导致初学者以为接入 RAG、加几个 API、套一个框架，就已经做出了 Agent。Jeff Su 的讲法更朴素，但也更实用：关键不在于系统里挂了多少能力，而在于谁决定下一步。

读完这篇文章，你应该能回答下面四个问题：

什么情况下系统只是工作流，不该硬叫 Agent？
RAG、Tool Use、Memory、ReAct 之间到底是什么关系？
一个能跑 Demo 的 Agent，离能上线的 Agent 还差哪些护栏？
如果你要自己动手，学习顺序应该怎么排？

先看结论：差别不在会不会调工具，而在谁决定下一步

Jeff Su 的三层划分可以浓缩成一张表：

层级	系统做什么	谁决定下一步	是否接外部数据或工具	是否能基于观察结果重规划
LLM	输入一段提示，输出一段结果	人	通常不直接接入	否
AI Workflow	按预设路径取数、处理、输出	人写好的控制逻辑	是	只在预先定义的分支内有限调整
True Agent	围绕目标自主拆解步骤、选择工具、迭代执行	模型在约束内决策	是	是

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

需要额外补一句的是：在 Jeff Su 的讲法里，RAG 更像一种工作流能力，也就是 “先查，再答”。放到更广义的工程实践里，RAG 当然也可以成为 Agent 的一个子能力，但 “会检索” 这件事本身，并不自动等于 “会自主决策”。

Level 1：LLM 为什么还不算 Agent

Jeff Su 先把起点放在大语言模型（LLM）上，这一步很重要，因为大多数人第一次接触 AI 都是通过 ChatGPT、Claude 或 Gemini 这样的对话界面。

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

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

这也是 Jeff Su 为什么反复强调 “passive systems”。如果只是让模型根据一个 prompt 生成文字，本质仍然是一个更强的输入输出系统，而不是能围绕目标持续推进任务的执行体。

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

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

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

他在配套文章里举了一个内容生产的例子：先把新闻链接放进 Google Sheets，再用 Perplexity 做摘要，再让 Claude 改写成社交媒体文案，最后设成每天定时运行。这已经是非常有价值的自动化系统，但它仍然不是 Agent，因为执行顺序、分支条件和失败后的处理方式，都是人提前规定好的。

工程上，这一层最重要的关键词叫 control logic，也就是控制逻辑。控制逻辑写在人手里，系统再复杂，也还是 workflow。

RAG 也适合放在这里理解。Jeff Su 把 RAG 当作 “先查资料再回答” 的典型流程，这个定位对入门者非常友好。只是再往深一点看，RAG 并不等于完整记忆系统，它更像是一个检索能力：

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

如果一句话概括 workflow 的价值，那就是：它已经足以解决大量真实问题，没必要因为 “Agent” 这个词更热，就把所有自动化都往 Agent 上靠。

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

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

这比 “能不能调 API” 更接近工程上的本质。因为一旦决策权从人手里转移到模型手里，系统能力会立刻发生三件变化：

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

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

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

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

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

Jeff Su 的视频适合作为第一层认知框架，但真要往下做，就必须把几个关键词说得更细。

ReAct 的重点不是 “神秘推理”，而是可中断的循环

ReAct 在论文里的优势有两层：一层是让模型能在每一步根据观察结果更新计划，另一层是让整个过程更容易被人类检查。也正因为如此，ReAct 不只是 “会调用工具” 的别名，而是一种把推理和动作放进同一条可追踪轨迹里的组织方式。

但从论文到工程实践，中间还隔着一层实现差异。很多生产系统不会把完整 thought 直接暴露给用户，而是只保留结构化行动、关键摘要和执行日志，以降低 token 成本、泄露风险和调试噪音。这并不违背 ReAct 的思想，只是做了工程折中。

Tool Use 的难点不是接上 API，而是让调用更可靠

工具调用这一层经常被讲得过于轻松。真正的难点不在于 “把 API 挂上去”，而在于如何减少误选工具、错误参数和幻觉式调用。Gorilla 这类研究之所以重要，就是因为它把问题讲得很具体：大模型在 API 调用场景下，常见失败点正是参数不准确、文档理解错误和错误调用不存在的接口。

所以，一个真实可用的 Agent 工具层，至少要补上这些东西：

明确的工具描述和参数模式。
输入校验、超时、重试和失败回退。
权限边界，避免模型“想调什么就调什么”。
记录每次调用的上下文，方便回放和评估。

Memory 不只有向量数据库

现稿里把 memory 基本等同于向量数据库，这会让读者误以为只要上了 Vector DB，就解决了记忆问题。更合理的拆法至少有三层：

记忆层	保存什么	常见实现
工作状态	当前步骤、临时变量、待办项	任务状态对象、工作流状态机
会话记忆	最近几轮对话、当前上下文	消息历史、摘要压缩
长期记忆	用户偏好、历史事实、外部知识	向量数据库、键值存储、知识图谱

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

Multi-Agent 不是入门默认项

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

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

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

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

能力层	教学 Demo 常见做法	生产系统至少要补什么
工具执行	直接调用函数或 API	权限控制、参数校验、超时、重试、幂等处理
循环控制	一直跑到模型说完成	最大步数、预算上限、停止原因、人工接管
记忆管理	统一塞进上下文或向量库	状态分层、保留策略、压缩与遗忘机制
调试评估	看日志、手动体感判断	Trace、离线评测、成功率、成本与延迟指标

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

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

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

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

这里可以顺带理解 LangChain 和 MCP 的位置。LangChain 当前把自己定位为 “帮助你快速构建 Agent 和应用的架构层”，更复杂的编排可以下沉到 LangGraph。MCP 则是另一条线，它解决的是 “AI 应用如何用统一方式连接外部系统”，本质上是在降低工具接入和迁移成本。两者并不冲突，甚至经常同时出现：前者偏编排，后者偏连接。

如果只从入门成本看，最值得记住的原则反而很简单：先 workflow，后 agent；先单 Agent，后多 Agent；先把评估补齐，再继续加工具。

这支视频的价值与边界

Jeff Su 这支视频最值得肯定的，不是它把 Agent 讲得多“高级”，而是它把概念压缩得足够清楚：

它适合零基础用户，能快速建立判断框架。
它用现实生活里的例子解释控制逻辑，而不是一上来堆框架名词。
它把 “模型成为决策者” 这件事单独拎了出来，这是很多入门材料最容易遗漏的重点。

但它也有明显边界：

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

所以，对这支视频最合理的使用方式不是 “看完就会做 Agent”，而是 “看完以后终于知道接下来该学什么、不该把什么混为一谈”。

站内继续读

读完后做个自测

一个系统会按固定顺序先查日历、再查天气、最后生成会议邮件。它为什么更像 workflow，而不是 agent？
为什么 “接了向量数据库” 还不等于真正做出了记忆系统？
如果一个 Agent 已经能稳定调工具，为什么上线前仍然要补最大步数、权限控制和执行追踪？
在什么情况下，多 Agent 协作会比单 Agent 更值得引入？

Jeff Su 这支视频最有用的提醒，其实非常简单：从 LLM 到 workflow，再到真正的 agent，变化最大的不是系统连上了多少 API，而是 “下一步应该怎么做” 的决策权从人手里逐渐转移到模型手里。看清这件事，再去看市面上的各种 “AI Agent” 产品，很多概念噪音都会立刻消失。

目录