这是笔者此前基于 DeepLearning.AI 最新课程 Agentic AI 的完整学习笔记。内容主要从 什么是 agentic 工作流 讲起一步步拆解反思、工具使用、评估、规划和多智能体协作每个模块都讲解了一些案例和可落地的设计模式。以前也做了些 Agent 相关的开发这个课程里面的有些方法论是可以思考并应用到实际工作中的我把课程里对我启发最大的内容提炼了出来加上自己的理解和实践思考整理成这篇系统性的笔记。不管你是想入门 Agentic AI还是已经在搭 agent 应用但遇到瓶颈应该都能从中找到有价值的东西本篇文章更偏向方法论。搭建一套思考框架这一模块给我的感觉是它不是在教 “一个又一个酷炫 demo”而是在搭一套思考框架 ——遇到一个任务时先想能不能把它变成一个有节奏的 agentic 工作流再去想模型、多 agent 协作这些更花哨的东西。先说明两个在文中频繁出现、容易混淆的英文词agentic形容词粗略理解为“像 agent 一样工作、有多步决策和行动能力的”。“agentic 工作流”指的是整套多步骤、可迭代的工作流程。agent名词可以理解为“在这套 agentic 工作流里扮演某个角色的实体”通常由一个 LLM加上一些工具、记忆、状态组成比如 research agent、customer service agent 等。在下面的笔记里我刻意保留 agentic / agent 这两个英文单词只在中文里解释它们做了什么事而不再把它们翻译成“智能体”“代理”这样和课程原文更一致也方便以后在其他地方复用这些概念。什么是 Agentic AI先说 “什么是 Agentic AI”。课程一开始对比了两种写文章方式传统用法是对 LLM 说“写一篇关于 X 的文章”模型从第一句写到最后一句过程里不能 “退格”这其实不是人类写作的真实样子。更像人的方式是先列一个大纲再想好要查什么资料上网搜索、筛选几个页面然后写一个初稿最后自己读一遍看看哪里薄、哪里逻辑不顺再去补材料、改结构。agentic 工作流本质上就是把这套步骤显性化让 LLM 负责大纲、搜索词、草稿和反思让工具负责网络搜索、PDF 转文本之类的操作。research agent 那个例子挺典型它可以围绕 “如何创建一家与 SpaceX 竞争的火箭公司” 自动规划搜索、抓多源网页、整合成一份结构化的 Markdown 报告明显比 “一条 prompt 要一篇文章” 更有深度。一个典型写作型 agentic 工作流可以概括为用户给出写作主题 ↓ LLM 生成大纲 研究问题 ↓ 调用网络搜索工具抓取多篇相关网页 ↓ LLM 基于材料写出初稿 ↓ LLM 或第二个“评审 agent”做反思找出薄弱/不一致之处 ↓ 补充检索或修改草稿得到改进后的版本agent 的自主程度接着是 “自主程度” 这个话题也就是 agent 究竟要多 “聪明”。课程用红、灰、绿三种框来画图红框是用户输入比如问题或一封邮件灰框是 LLM 调用绿框是工具或代码网络搜索、PDF 转文本、数据库 API、代码执行等agent 自主程度的大致三层可以这样理解1. 低自主 agentLess Autonomous步骤顺序完全由工程师预先写死例如发票 → PDF 转文本 → LLM 抽字段 → 写数据库记录LLM 的主要职责是“根据输入生成文本”不负责决定下一步做什么。好处是行为稳定、易评估但灵活性较低。2. 半自主 agentSemi-Autonomous人类定义好大致流程框架LLM 在框架内做选择。例如写黑洞文章时由 LLM 决定先查新闻、还是先查百科、还是先搜论文需要抓多少网页材料是否还要追加一次搜索这类系统在可控和灵活之间找到平衡也是课程中最被推荐的落地形态。3. 高度自主 agentHighly AutonomousLLM 自主决定要走什么步骤序列甚至在需要时生成新函数、新工具。理论上可以处理更开放、更复杂的任务但行为更难预测、也更难严格评估。课程的态度比较务实高自主当然酷但也更难控制今天大多数真正落地的系统集中在“人定骨架 模型做局部决策”的半自主区间。为什么要用 agentic 工作流为什么要折腾 agentic 工作流而不是直接换个更大的模型HumanEval 的例子给了我一个挺直观的刻度GPT‑3.5 直接写代码大概只能做对 40% 的题GPT‑4 能做到 67%。但如果给 GPT‑3.5 包一层 agentic 工作流让它先写代码、再让自己或另一个 agent 审查、用工具运行代码、再根据报错修改整体表现可以和“裸用 GPT‑4”拉得很近甚至更好。这说明把任务拆开、反复迭代带来的收益不一定比 “换个更大的模型” 少。再加上 agentic 工作流天然支持并行比如同时抓多批网页和模块化搜索引擎、新闻源、LLM 模型、解析工具都可以替换整体就像搭流水线而不是赌一次性输出。典型应用场景梯度中间几节通过一条 “难度梯度” 把应用场景串起来最简单的是发票处理发票 PDF 先转成文本然后让 LLM 判断是不是发票如果是就抽取 “账单方、地址、金额、到期日” 这些固定字段再调用工具写一条数据库记录。这种任务有清晰的 SOP 和稳定字段非常适合做成高可靠的 agent。稍微复杂一点的是基础订单查询从客户邮件里抽出姓名、订单号和问题调用订单数据库查记录然后起草一封回复邮件并通过“请求审查”工具把草稿送到人工队列让客服确认后再发出去。再往上一层是更泛化的 customer service agent——不只是查“我这单到了没”还要回答“有没有某种商品”“退货规则是什么”等问题这类任务的步骤序列事先并不完全固定agent 需要自己规划多次数据库查询。最难的则是所谓 “computer-use agent”agent 要自己在浏览器里点开美联航网站或者 Google Flights填表、点击、等待网页加载最后确认从 SFO 到 DCA 的某趟航班有没有座位。课程也坦诚地说这一类目前还是容易迷路、频繁失败的研究前沿。任务分解与构建块要让这些系统真正好用关键在于任务分解和评估。任务分解这节给我一个很直接的 checklist先问自己“如果这事让我这个人干我会怎么拆步骤”把一、二、三步写下来再逐条检查这一步能不能交给 LLM如果不能是不是可以写成一小段代码或者做成一个工具课程用 research agent、订单查询和发票处理三个例子反复示范这个过程。research agent从直接生成文章→大纲搜索撰写→大纲搜索初稿审查修改逐步细化。客户订单查询提取信息→查询数据库→发送回复每步都可由LLM配合工具完成。发票处理提取字段→更新数据库简洁高效。在构建 agentic 工作流时会拥有许多构建块要知道如何区分构建块这里主要指的是 AI 模型、工具的区分。一个很重要的点是当输出浅、散、不连贯时先怀疑自己的工作流是不是拆得太粗而不是一味去调 prompt。比如写文章时可以把 “写文章” 拆成 “写初稿→读初稿、标注要修改的部分→按标注改稿”每一步都可以单独看结果、单独调。我自己的“任务分解小模板”可以写成1. 写出人类版本的 SOP这事我会怎么做 2. 对每一步标记适合 LLM / 适合工具 / 适合代码 / 必须人工 3. 对 LLM 步骤再细化输入和输出的格式方便后面评估 4. 如果某一步效果明显不稳就考虑把这一步再拆成两三步评估与错误分析评估和错误分析则是另一条主线。课程建议不要一开始就花很多时间设计复杂 eval而是先让工作流跑起来读一批真实输出看看它在真实环境里会犯什么错。客服代理乱提竞争对手就是一个典型案例有的回答会写 “我们比 CompCo 好得多” “与 RivalCo 不同我们退货更容易”这在很多公司都是绝对不能出现的。发现问题之后就可以给它配一个简单直接的 eval维护一张竞争对手黑名单写程序扫描输出只要出现这些名词就计数用来跟踪“提到竞争对手”这个严重错误是否被逐渐消灭。对于“研究报告质量”这种更主观的指标可以暂时让另一个 LLM 来打 1–5 分虽然不完美但总比完全不量化要好。后续模块会系统讲“端到端评估”和“组件级评估”的区别但这一节已经把闭环的大致形状讲清楚了阅读中间轨迹做错误分析 → 把典型错误抽象成 eval → 持续追踪数值变化。四个常用设计模式最后一部分是四个常用设计模式反思、工具使用、规划、多 agent 协作。反思模式里LLM 会先写一段代码再把这段代码交给自己或另一个“批评 agent”检查正确性、风格、效率然后根据批评修改如果再结合“运行单测”的工具就可以不断用真实报错推动改进。工具使用模式强调要把网络搜索、代码执行、数据库读写、文件操作、PDF 解析等都包装成工具交给模型调用把 LLM 从“只能说话”升级到“能查、能算、能写”。规划模式用 HuggingGPT 的例子展示面对“按照男孩姿势生成女孩图片并配语音描述”这种任务LLM 会自己规划先调用姿态识别模型、再调用图像生成/编辑模型、最后调用 TTS 模型的顺序。多 agent 协作则用 ChatDev 和“研究员 写手 编辑”这类团队结构说明复杂项目可以由不同“角色”的 agent 分工对话完成。行动总结对我个人来说这一模块最直接的两个行动点是第一以后做任何基于 LLM 的功能都先画出一个大致的工作流把“哪些步骤交给模型、哪些步骤交给工具或代码、哪些步骤必须有人工”想清楚再去写提示词第二从一开始就把 “评估 错误分析” 当成开发的一部分尽可能留下中间轨迹早一点去发现真实错误模式用简单可执行的 eval 把它量化而不是等上线后靠直觉感受好坏。反思设计模式
Agentic AI 从入门到落地，精华整理全在这了！
发布时间：2026/5/20 4:38:07
这是笔者此前基于 DeepLearning.AI 最新课程 Agentic AI 的完整学习笔记。内容主要从 什么是 agentic 工作流 讲起一步步拆解反思、工具使用、评估、规划和多智能体协作每个模块都讲解了一些案例和可落地的设计模式。以前也做了些 Agent 相关的开发这个课程里面的有些方法论是可以思考并应用到实际工作中的我把课程里对我启发最大的内容提炼了出来加上自己的理解和实践思考整理成这篇系统性的笔记。不管你是想入门 Agentic AI还是已经在搭 agent 应用但遇到瓶颈应该都能从中找到有价值的东西本篇文章更偏向方法论。搭建一套思考框架这一模块给我的感觉是它不是在教 “一个又一个酷炫 demo”而是在搭一套思考框架 ——遇到一个任务时先想能不能把它变成一个有节奏的 agentic 工作流再去想模型、多 agent 协作这些更花哨的东西。先说明两个在文中频繁出现、容易混淆的英文词agentic形容词粗略理解为“像 agent 一样工作、有多步决策和行动能力的”。“agentic 工作流”指的是整套多步骤、可迭代的工作流程。agent名词可以理解为“在这套 agentic 工作流里扮演某个角色的实体”通常由一个 LLM加上一些工具、记忆、状态组成比如 research agent、customer service agent 等。在下面的笔记里我刻意保留 agentic / agent 这两个英文单词只在中文里解释它们做了什么事而不再把它们翻译成“智能体”“代理”这样和课程原文更一致也方便以后在其他地方复用这些概念。什么是 Agentic AI先说 “什么是 Agentic AI”。课程一开始对比了两种写文章方式传统用法是对 LLM 说“写一篇关于 X 的文章”模型从第一句写到最后一句过程里不能 “退格”这其实不是人类写作的真实样子。更像人的方式是先列一个大纲再想好要查什么资料上网搜索、筛选几个页面然后写一个初稿最后自己读一遍看看哪里薄、哪里逻辑不顺再去补材料、改结构。agentic 工作流本质上就是把这套步骤显性化让 LLM 负责大纲、搜索词、草稿和反思让工具负责网络搜索、PDF 转文本之类的操作。research agent 那个例子挺典型它可以围绕 “如何创建一家与 SpaceX 竞争的火箭公司” 自动规划搜索、抓多源网页、整合成一份结构化的 Markdown 报告明显比 “一条 prompt 要一篇文章” 更有深度。一个典型写作型 agentic 工作流可以概括为用户给出写作主题 ↓ LLM 生成大纲 研究问题 ↓ 调用网络搜索工具抓取多篇相关网页 ↓ LLM 基于材料写出初稿 ↓ LLM 或第二个“评审 agent”做反思找出薄弱/不一致之处 ↓ 补充检索或修改草稿得到改进后的版本agent 的自主程度接着是 “自主程度” 这个话题也就是 agent 究竟要多 “聪明”。课程用红、灰、绿三种框来画图红框是用户输入比如问题或一封邮件灰框是 LLM 调用绿框是工具或代码网络搜索、PDF 转文本、数据库 API、代码执行等agent 自主程度的大致三层可以这样理解1. 低自主 agentLess Autonomous步骤顺序完全由工程师预先写死例如发票 → PDF 转文本 → LLM 抽字段 → 写数据库记录LLM 的主要职责是“根据输入生成文本”不负责决定下一步做什么。好处是行为稳定、易评估但灵活性较低。2. 半自主 agentSemi-Autonomous人类定义好大致流程框架LLM 在框架内做选择。例如写黑洞文章时由 LLM 决定先查新闻、还是先查百科、还是先搜论文需要抓多少网页材料是否还要追加一次搜索这类系统在可控和灵活之间找到平衡也是课程中最被推荐的落地形态。3. 高度自主 agentHighly AutonomousLLM 自主决定要走什么步骤序列甚至在需要时生成新函数、新工具。理论上可以处理更开放、更复杂的任务但行为更难预测、也更难严格评估。课程的态度比较务实高自主当然酷但也更难控制今天大多数真正落地的系统集中在“人定骨架 模型做局部决策”的半自主区间。为什么要用 agentic 工作流为什么要折腾 agentic 工作流而不是直接换个更大的模型HumanEval 的例子给了我一个挺直观的刻度GPT‑3.5 直接写代码大概只能做对 40% 的题GPT‑4 能做到 67%。但如果给 GPT‑3.5 包一层 agentic 工作流让它先写代码、再让自己或另一个 agent 审查、用工具运行代码、再根据报错修改整体表现可以和“裸用 GPT‑4”拉得很近甚至更好。这说明把任务拆开、反复迭代带来的收益不一定比 “换个更大的模型” 少。再加上 agentic 工作流天然支持并行比如同时抓多批网页和模块化搜索引擎、新闻源、LLM 模型、解析工具都可以替换整体就像搭流水线而不是赌一次性输出。典型应用场景梯度中间几节通过一条 “难度梯度” 把应用场景串起来最简单的是发票处理发票 PDF 先转成文本然后让 LLM 判断是不是发票如果是就抽取 “账单方、地址、金额、到期日” 这些固定字段再调用工具写一条数据库记录。这种任务有清晰的 SOP 和稳定字段非常适合做成高可靠的 agent。稍微复杂一点的是基础订单查询从客户邮件里抽出姓名、订单号和问题调用订单数据库查记录然后起草一封回复邮件并通过“请求审查”工具把草稿送到人工队列让客服确认后再发出去。再往上一层是更泛化的 customer service agent——不只是查“我这单到了没”还要回答“有没有某种商品”“退货规则是什么”等问题这类任务的步骤序列事先并不完全固定agent 需要自己规划多次数据库查询。最难的则是所谓 “computer-use agent”agent 要自己在浏览器里点开美联航网站或者 Google Flights填表、点击、等待网页加载最后确认从 SFO 到 DCA 的某趟航班有没有座位。课程也坦诚地说这一类目前还是容易迷路、频繁失败的研究前沿。任务分解与构建块要让这些系统真正好用关键在于任务分解和评估。任务分解这节给我一个很直接的 checklist先问自己“如果这事让我这个人干我会怎么拆步骤”把一、二、三步写下来再逐条检查这一步能不能交给 LLM如果不能是不是可以写成一小段代码或者做成一个工具课程用 research agent、订单查询和发票处理三个例子反复示范这个过程。research agent从直接生成文章→大纲搜索撰写→大纲搜索初稿审查修改逐步细化。客户订单查询提取信息→查询数据库→发送回复每步都可由LLM配合工具完成。发票处理提取字段→更新数据库简洁高效。在构建 agentic 工作流时会拥有许多构建块要知道如何区分构建块这里主要指的是 AI 模型、工具的区分。一个很重要的点是当输出浅、散、不连贯时先怀疑自己的工作流是不是拆得太粗而不是一味去调 prompt。比如写文章时可以把 “写文章” 拆成 “写初稿→读初稿、标注要修改的部分→按标注改稿”每一步都可以单独看结果、单独调。我自己的“任务分解小模板”可以写成1. 写出人类版本的 SOP这事我会怎么做 2. 对每一步标记适合 LLM / 适合工具 / 适合代码 / 必须人工 3. 对 LLM 步骤再细化输入和输出的格式方便后面评估 4. 如果某一步效果明显不稳就考虑把这一步再拆成两三步评估与错误分析评估和错误分析则是另一条主线。课程建议不要一开始就花很多时间设计复杂 eval而是先让工作流跑起来读一批真实输出看看它在真实环境里会犯什么错。客服代理乱提竞争对手就是一个典型案例有的回答会写 “我们比 CompCo 好得多” “与 RivalCo 不同我们退货更容易”这在很多公司都是绝对不能出现的。发现问题之后就可以给它配一个简单直接的 eval维护一张竞争对手黑名单写程序扫描输出只要出现这些名词就计数用来跟踪“提到竞争对手”这个严重错误是否被逐渐消灭。对于“研究报告质量”这种更主观的指标可以暂时让另一个 LLM 来打 1–5 分虽然不完美但总比完全不量化要好。后续模块会系统讲“端到端评估”和“组件级评估”的区别但这一节已经把闭环的大致形状讲清楚了阅读中间轨迹做错误分析 → 把典型错误抽象成 eval → 持续追踪数值变化。四个常用设计模式最后一部分是四个常用设计模式反思、工具使用、规划、多 agent 协作。反思模式里LLM 会先写一段代码再把这段代码交给自己或另一个“批评 agent”检查正确性、风格、效率然后根据批评修改如果再结合“运行单测”的工具就可以不断用真实报错推动改进。工具使用模式强调要把网络搜索、代码执行、数据库读写、文件操作、PDF 解析等都包装成工具交给模型调用把 LLM 从“只能说话”升级到“能查、能算、能写”。规划模式用 HuggingGPT 的例子展示面对“按照男孩姿势生成女孩图片并配语音描述”这种任务LLM 会自己规划先调用姿态识别模型、再调用图像生成/编辑模型、最后调用 TTS 模型的顺序。多 agent 协作则用 ChatDev 和“研究员 写手 编辑”这类团队结构说明复杂项目可以由不同“角色”的 agent 分工对话完成。行动总结对我个人来说这一模块最直接的两个行动点是第一以后做任何基于 LLM 的功能都先画出一个大致的工作流把“哪些步骤交给模型、哪些步骤交给工具或代码、哪些步骤必须有人工”想清楚再去写提示词第二从一开始就把 “评估 错误分析” 当成开发的一部分尽可能留下中间轨迹早一点去发现真实错误模式用简单可执行的 eval 把它量化而不是等上线后靠直觉感受好坏。反思设计模式
