Agentic AI 从入门到落地，精华整理全在这了！
这是笔者此前基于 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. 低自主 agent（Less Autonomous）
步骤顺序完全由工程师预先写死，例如：
发票 → PDF 转文本 → LLM 抽字段 → 写数据库记录LLM 的主要职责是“根据输入生成文本”，不负责决定下一步做什么。
好处是行为稳定、易评估，但灵活性较低。
2. 半自主 agent（Semi-Autonomous）
人类定义好大致流程框架，LLM 在框架内做选择。
例如写黑洞文章时，由 LLM 决定：
先查新闻、还是先查百科、还是先搜论文？
需要抓多少网页材料？
是否还要追加一次搜索？
这类系统在可控和灵活之间找到平衡，也是课程中最被推荐的落地形态。
3. 高度自主 agent（Highly Autonomous）
LLM 自主决定要走什么步骤序列，甚至在需要时生成新函数、新工具。
理论上可以处理更开放、更复杂的任务，但行为更难预测、也更难严格评估。
课程的态度比较务实：高自主当然酷，但也更难控制；今天大多数真正落地的系统，集中在“人定骨架 + 模型做局部决策”的半自主区间。
为什么要用 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 把它量化，而不是等上线后靠直觉感受好坏。