从Agent工作流到多智能体协作：吴恩达课程核心模式与落地实践

做 AI 应用这一年多我有一个越来越强烈的感受同样一个模型用“问一句答一句”的方式调用和用一套精心设计的 Agent 工作流去调用产出的质量差距可以非常大。很多人把 Agent 理解为“更聪明的聊天机器人”这其实是个误解。Agent 不是一个新的模型而是一套新的任务组织方式。它把一个复杂目标拆成多个环节每个环节交给大模型执行、检查、修正必要时再调用外部工具获取真实数据。这种模式下模型本身可能没有变强但最终交付结果却稳定得多。吴恩达Andrew Ng在 DeepLearning.AI 的系列课程里把这件事讲得非常系统。他甚至在不同场合反复表达过一个判断Agentic AI 是他目前最看好的方向之一。这套课程没有停留在概念层面而是把 Agent 拆成可以逐个动手练习的模块工作流、反射、工具调用、MCP、多智能体协作。对国内开发者来说这几乎是目前能找到的最完整的 Agent 入门到进阶路线之一。这篇文章就顺着这套课程的核心思路帮你梳理一份可落地的 Agent 知识框架并给出能直接运行的代码示例和避坑清单。不管你最终选择 LangGraph、crewAI、Dify还是自己手写一套流程这些底层设计思想都是通用的。1. 这篇文章真正要解决的问题Agent 学习路线为什么值得跟很多开发者现在处于一个尴尬阶段知道 Agent 火也知道 MCP、多智能体这些词但真要动手做一个 Agent 时脑子里没有清晰的架构图。最常见的困惑是单次调用大模型时输出不稳定换一个 Prompt 结果就漂移怎么让它稳定干活想让 AI 自动完成“查数据 → 写报告 → 发邮件”这种多步骤任务应该从哪里入手听说 Function Calling、MCP 能让模型调用工具但两者的边界在哪里多智能体协作听起来很美好实际项目里会不会只是把简单问题复杂化吴恩达这套课程的价值恰好就在于回答了这些问题。它把 Agentic AI 的常见工作流抽象成了几个核心模式反射Reflection、工具使用Tool Use、规划Planning、多智能体协作Multi-Agent Collaboration。这几个模式不是停留在理论上的分类而是可以直接对应到代码结构和系统设计里。学完这套思路后你得到的不是一个“只能跑 Demo 的玩具”而是一套能在真实项目中复用的方法论。比如你会理解为什么反思循环能提升输出质量、什么时候需要引入工具调用、为什么有些任务拆给多个 Agent 反而更高效以及为什么说 MCP 解决了工具接入标准化的真问题。这篇文章的核心目标就是把这套方法论拆开讲透配合代码让你能照着落地同时把新手最容易踩的坑提前指出来。2. Agent、Agentic AI 与工作流先把概念讲透在进入实操之前有几个基础概念必须先对齐。2.1 Agent 不是模型而是系统单次调用大模型时整个流程是线性的用户输入 → Prompt 直接发给模型 → 模型返回一次回答 → 结束。这种模式适合问答、翻译、总结等一次性任务。但遇到“帮我调研一下某个技术方向整理成报告”“按照需求写一个模块然后自我检查并修复”这类多步骤任务单次调用就撑不住了。Agent 的本质是把大模型放到一个循环中模型产出结果后系统可以继续观察结果、反馈问题、让模型重新生成甚至调用外部工具获取更多信息。吴恩达在课程里反复强调的一个观点是不要只把大模型当作“对话引擎”要把它当作一个可以反复调用、逐步推进任务的“推理引擎”。一个典型的 Agent 工作流大概是用户目标 → Agent 规划任务 → 调用模型生成中间结果 → 检查结果是否达标 → 不达标则反馈并重新生成 → 需要数据则调用工具获取 → 汇总结果 → 输出最终答案这套循环就是 Agentic AI 和传统 LLM 应用最大的区别。2.2 Agentic AI 的四种核心工作流模式这套课程把 Agentic AI 的常见设计模式归纳为四类整个学习路线也是围绕它们展开的模式一句话理解解决什么问题Reflection反射模型自己检查自己的输出发现问题后修订单次生成质量不稳定、错误多Tool Use工具使用让模型调用外部 API、数据库、代码解释器等模型无法获取实时数据、无法执行动作Planning规划把大任务拆解成子任务按顺序执行复杂任务一次性难以完成Multi-Agent Collaboration多智能体协作多个不同角色的 Agent 分工配合任务需要不同视角、不同领域知识这四种模式不是互斥的实际项目里经常组合使用。比如一个写代码 Agent内部可以先用 Planning 拆解需求再用 Tool Use 调用代码解释器执行代码最后用 Reflection 让另一个模型做代码评审。2.3 什么是 Agent 工作流工作流Workflow这个词在 Agent 语境里指的是任务从开始到结束所经过的完整流程定义。它通常包含几个要素状态当前任务进展到哪一步节点每一步调用什么能力模型、工具、条件判断数据传递上一步的输出如何成为下一步的输入终止条件什么情况下认为任务完成理解了这几个概念组合后就可以正式进入代码层面了。3. 反射模式 Reflection让 Agent 学会自我修订反射模式是这套课程里第一个值得动手实现的模式因为它足够简单而且效果立竿见影。3.1 为什么模型需要“反思”大模型单次生成的错误往往是“盲目自信”的。让它直接写一段代码它可能忽略边界条件让它写一段文案它可能不够契合主题。传统解法是不断改 Prompt但存在两个问题一是 Prompt 越写越长二是模型输出的不确定性依然存在。反射模式的思路是不追求一次生成完美结果而是把“生成”和“评估”分开让两组指令交替工作。它的工作流程可以概括为生成模型Generator完成任务产出一个初版结果。评审模型Critic用另一个视角检查初版结果指出问题。生成模型根据评审意见修改输出。重复 2 和 3直到评审通过或达到最大迭代次数。3.2 一个极简反射 Demo下面用 OpenAI 兼容接口做一个最小可运行的反射示例核心不是某个具体 API而是完整的生成-评审-修正循环。# reflection_demo.py # 最小反射示例生成 - 评审 - 修正 from openai import OpenAI client OpenAI() # 也可以配置为使用其他兼容 OpenAI 接口的模型服务 def call_llm(prompt: str) - str: resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.7, ) return resp.choices[0].message.content task 请写出一个 Python 函数判断一个整数是否为质数。 # 第一轮生成 answer call_llm(task) print( 初版结果 ) print(answer) # 第二轮评审 critic_prompt f 你是一个严格的代码评审专家。请检查下面的代码 1. 边界条件是否处理正确 2. 是否存在性能问题 3. 风格是否清晰 如果发现问题只输出问题列表如果没有问题只输出“代码合格”。 代码 {answer} review call_llm(critic_prompt) print( 评审意见 ) print(review) # 第三轮如果评审不通过则要求修改 if 代码合格 not in review: fix_prompt f 请根据评审意见修改下面的代码输出修改后的完整版本。 原代码 {answer} 评审意见 {review} final_answer call_llm(fix_prompt) print( 修正版 ) print(final_answer) else: final_answer answer print( 初版已合格 )运行这段代码后你会发现一个很直观的现象初版结果可能漏掉对n 1的处理评审模型会明确指出来修正版则会把这类边界条件补上。3.3 反射模式的关键细节反射模式实现简单但有几个设计决策会直接影响效果评审视角要和生成视角区分。如果评审 Prompt 只是简单改成“你再检查一下”模型很可能还是站在写代码的人视角看不出问题。更好的做法是让评审模型扮演一个“挑刺的测试工程师”“看到代码就想到极端输入的专家”视角差异越大发现问题越准。要设定最大迭代次数。如果不加限制生成和评审可能来回拉锯Token 消耗不可控。通常 1 到 3 轮就足够了超过 3 轮还没收敛问题往往出在任务描述或评审标准上而不是模型能力。评审的标准要可判断。“请检查代码是否有问题”太宽泛“请检查 n 为负数、0、1、2 时函数是否正确”就具体得多。给评审模型一个检查清单会让评审结果稳定性大幅提升。实际工程项目中反射模式还经常和自动化测试结合评审模型输出修改意见然后让代码解释器执行单测把失败信息喂给生成模型继续修改直到测试通过。这种“模型评审 真实执行校验”的组合效果比纯文本评审可靠得多。4. 工具使用与 MCP把 LLM 从“聊天框”里解放出来反射模式让模型“想得更周全”但如果模型只能基于训练时的知识回答问题它依然拿不到实时数据也无法执行真实动作。工具使用模式就是为了解决这个问题。4.1 工具调用让模型决定什么时候查什么工具使用的核心是 Function Calling。开发者预定义一批函数每个函数有名称、描述和参数结构模型在生成过程中判断需要用到哪个工具输出结构化的调用请求应用层执行函数并把结果返回给模型模型再基于结果继续生成。这种方式不是让模型“记住”工具而是让模型理解“有哪些工具可用、各自适合什么场景”。比如查天气模型判断用户问题需要实时天气于是调用get_weather(city)。算数学模型调用计算器工具而不是自己心算。查订单模型调用订单查询 API获取真实数据后再回答。4.2 MCP 到底是什么如果每个工具都要单独写一套接入逻辑Agent 的可复用性会非常差。MCPModel Context Protocol解决的就是这个问题。MCP 可以把 MCP 理解为“模型上下文协议”它定义了一套标准化的通信方式让大模型应用能够统一地连接外部工具、数据源和文件系统。工具提供方只需要实现一个 MCP Server任何支持 MCP 的客户端应用就能直接使用这些工具不需要为每个应用单独写对接代码。这套课程把 MCP 放在工具使用模块里讲思路很清晰先用 Function Calling 理解工具调用的本质再通过 MCP 学习如何把工具接口标准化最终落实到自己的 Agent 项目里。4.3 一个 MCP Server 结构示例下面用 MCP 官方 Python SDK 中较常见的 FastMCP 高层封装写一个简单工具服务。# mcp_server.py # MCP Server 基础结构示例SDK 版本不同时 API 可能略有差异 from mcp.server.fastmcp import FastMCP mcp FastMCP(DemoAgentTools) mcp.tool() def get_weather(city: str) - str: 查询指定城市的天气信息 # 实际项目中这里可以替换为真实天气 API 调用 return f{city} 当前天气晴25 摄氏度 mcp.tool() def add(a: float, b: float) - float: 计算两个数字之和 return a b if __name__ __main__: mcp.run()这个示例的核心价值在于工具本身只是普通函数MCP 负责把它们暴露成标准的工具服务。任何理解 MCP 协议的客户端都可以通过协议发现get_weather和add这两个工具并按照统一格式调用。当你在 Cursor、Claude Desktop 等支持 MCP 的应用里配置了本地或远程 MCP Server 后Agent 就能把这些工具当作自己的“双手”来使用。4.4 工具设计要遵循单一职责工具调用设计得好不好直接影响 Agent 的实际表现。实际项目中更推荐遵守几个原则工具粒度要小一个工具只做一件事get_weather和send_email不要合成一个函数。参数名要自解释模型是根据描述理解参数的city、start_date比arg1可靠得多。返回结果要结构化JSON 比纯文本更利于模型解析比如{city: 北京, temp: 25}。要做输入校验工具是 Agent 的外接能力不能盲信模型生成的参数生产环境必须对参数做合法性校验。5. 规划与多智能体协作从单兵作战到团队配合前两种模式解决的是“单个 Agent 如何干好一件事”。但当任务本身非常复杂时单个 Agent 容易在上下文里迷失。这时需要规划模式和多智能体协作。5.1 规划把大目标拆成小步骤规划模式的思路很朴素让模型在动手之前先形成一份任务清单再逐步执行。对比一下没有规划用户说“帮我做一个用户画像系统”模型尝试一次生成整个系统代码结果质量和一致性都很差。有规划模型先拆解成“需求分析 → 数据表设计 → 后端接口 → 前端页面 → 联调测试”然后逐个步骤执行每步完成后再进入下一步。规划模式的关键在于拆解出来的每个步骤都要“可执行”并且步骤之间的输入输出要能衔接。很多新手把规划做成一个大 Prompt 甩给模型模型依然无从下手。更合理的做法是用代码结构维护任务清单每一步单独调用模型而不是让模型在一个超长对话里自由发挥。5.2 多智能体不同角色不同职责多智能体协作更进一步把不同角色的职责拆给多个 Agent。比如写技术文章可以让一个 Agent 负责调研一个 Agent 负责写初稿一个 Agent 负责校对。每个 Agent 拥有独立的角色设定、背景知识和输出规范。为什么要拆因为单个模型在一个 Prompt 里同时扮演调研员、写手、校对的角色很容易出现角色冲突。拆开之后每个 Agent 只需要守好自己的职责边界输出质量会更稳定。下面是一个基于 crewAI 的多智能体协作示例结构# crew_demo.py # crewAI 多智能体协作示意框架版本以你安装的官方版本为准 from crewai import Agent, Task, Crew, Process researcher Agent( role行业研究员, goal搜集并归纳 MCP 协议在 Agent 开发中的主要用途, backstory你是一名经验丰富的 AI 应用研究员擅长快速定位关键信息。, ) writer Agent( role技术编辑, goal把调研结果改写成一篇面向开发者的技术文章初稿, backstory你是一名长期写技术博客的编辑讲清楚原理比堆砌术语更重要。, ) research_task Task( description整理 MCP 协议在 Agent 开发中的主要用途输出要点列表, expected_output一份包含 5 个要点的调研摘要, agentresearcher, ) write_task Task( description基于调研摘要撰写一篇技术文章的开头部分要求 300 字左右, expected_output技术文章开头, agentwriter, ) crew Crew( agents[researcher, writer], tasks[research_task, write_task], processProcess.sequential, # 顺序执行先调研后写作 ) result crew.kickoff() print(result)运行之后你会看到两个 Agent 按顺序执行研究员先产出摘要技术编辑再基于摘要写文章开头。每个 Agent 的输出边界清晰整个流程也容易定位是哪一步出了问题。5.3 多智能体不是越多越好这是多智能体协作里最容易踩的坑。很多初学者看到多智能体的 Demo 很炫就试图把一个简单任务拆给五六个 Agent结果Token 消耗翻了好几倍对话链路变长延迟明显增加Agent 之间传递信息时出现偏差错误被不断放大合理的选择是能用一个 Agent 加规划解决的任务不要用两个能用两个解决的任务不要用三个。多智能体的价值在于解决“需要不同视角或不同专业领域”的任务而不是简单地把同一个任务切碎。6. 吴恩达 Agent 教程学习路线从入门到进阶怎么走理解了四个核心模式之后再回头看这套课程的学习路线思路就会清晰很多。6.1 课程模块与学习顺序从公开资料和课程结构来看这套 Agent 教程的学习路径大致按“工作流 → 反射 → 工具/MCP → 多智能体”推进学习阶段核心内容需要掌握的技能第一阶段Agent 工作流基础理解 Agent 与普通模型调用的区别能搭起一个最小 Agent 循环第二阶段反射模式写出生成-评审-修正流程掌握多轮迭代控制第三阶段工具使用与 MCP掌握 Function Calling能编写和接入 MCP 工具第四阶段规划模式学会把复杂任务拆解成可执行的子任务第五阶段多智能体协作掌握多 Agent 的角色设计、任务编排、结果聚合这个顺序设计得很合理因为每一层都建立在前一层基础上。反射模式不需要工具调用工具调用不需要规划规划又是多智能体协作的前置条件。跟着这个顺序学不会出现在概念上“空中楼阁”的问题。6.2 如何高效利用课件代码这类课程通常会提供配套的 Notebook 课件和代码示例。使用代码材料时建议不要直接“读完所有代码再动手”而是先看代码结构猜每一步的作用。把代码跑通记录输出结果。修改关键参数比如换任务、调迭代轮数、换模型。总结哪些变量会影响最终效果。课件代码是“标准答案”但只有当你自己改过之后才知道哪一步对结果的影响最大也才能真正内化成自己的方法。6.3 学完课程之后往哪个方向深入如果只想做一个简单的业务工具学完工作流、反射、工具使用就基本够用了。如果要做更复杂的产品级 Agent建议继续深入研究LangGraph更细粒度的状态机控制适合编排复杂流程。Dify / Coze / n8n可视化工作流平台适合快速搭建业务自动化。向量数据库与 RAG让 Agent 能访问私有知识库。可观测性与评测给 Agent 加日志、Trace 和评价体系。7. 常见问题与排查思路在实践 Agent 开发时下面的问题出现频率极高整理成排查表方便对照。问题现象可能原因排查方式解决方案反射循环一直不收敛评审标准不具体生成端反复修改但没改到点上打印每轮评审意见与修改内容检查定位是否一致在评审 Prompt 中给出明确检查清单并限制最大迭代轮数模型没有调用工具工具描述不清晰或模型不支持 Function Calling查看模型请求日志确认工具列表是否传给了模型优化工具描述明确“什么场景下使用该工具”换支持工具调用的模型MCP Server 连接失败服务没有启动或协议版本不兼容先单独运行 MCP Server确认端口和日志正常检查 SDK 版本统一客户端与服务端的 MCP 版本多智能体协作结果跑偏角色职责界定不清任务描述含糊检查每个 Task 的描述和输出要求为每个 Agent 定义明确的 Goal 和 Backstory任务描述中给出输出示例Agent 输出很长但没完成核心任务任务目标不清晰Agent 在无效环节花费太多上下文查看完整对话链路定位哪一步开始偏离把大目标拆成子任务并在每步开始时重申当前目标Token 消耗过高反思轮数过多、工具返回结果过大统计各环节 Token 占比限制反思轮数、精简工具返回字段、规划时过滤无关步骤8. Agent 项目落地最佳实践课程里讲清楚了“怎么实现”但生产环境落地还需要额外注意一些工程问题。8.1 先跑通最小闭环再扩展功能很多 Agent 项目失败不是因为技术选型不对而是还没有把最小闭环跑通就开始堆功能。接一个真实业务场景时先用最简单的不带工具、不带多智能体的流程把任务跑通再逐步引入工具调用和反思循环。每一步都要验证“这一步真的有帮助”而不是为了用 Agent 而用 Agent。8.2 把反思和工具设计成独立模块反射循环和工具调用不要和业务逻辑耦合在一起。推荐的做法是workflow/ ├── agent/ │ ├── generator.py # 生成模块 │ ├── critic.py # 评审模块 │ ├── planner.py # 规划模块 │ └── runner.py # 主循环 ├── tools/ │ ├── registry.py # 工具注册 │ ├── weather.py │ └── database.py └── config.py # 模型参数、迭代轮数这样后续换模型、加工具、调整反思策略都只需要改动局部模块。8.3 日志和 Trace 必须从第一天就做Agent 应用的调试比传统应用难得多因为每一步都有模型参与输出不固定。强烈建议从项目第一天就给每一次模型调用打日志输入 Prompt输出结果消耗 Token耗时中间状态当 Agent 行为异常时这些日志就是“黑匣子”。有条件的话可以接入 LangSmith、Langfuse 这类可观测性平台或者直接在业务系统里做一套简化的 Trace 记录。8.4 对 Agent 的输出做边界校验Agent 调用了工具就相当于把一部分系统控制权交给了模型。工具在接收参数时必须做校验重要操作必须增加确认机制涉及数据变更的操作要遵循最小权限原则并保留回滚能力。不要因为结果是模型生成的就跳过人工审核或系统校验。8.5 控制成本与延迟Agent 工作流的 Token 消耗通常远高于单次模型调用。一个带反思和工具调用的任务Token 消耗可能是普通问答的 5 到 20 倍。在设计阶段就要想清楚是否每个步骤都需要最贵的模型还是一些步骤可以用轻量模型完成。工具返回结果是否做了裁剪。多智能体协作时是否复用上下文避免重复传递大量文本。9. 总结与后续学习方向从吴恩达这套 Agent 教程里最值得带走的不只是“Agent 是什么”而是那四种核心工作流模式反射、工具使用、规划和多智能体协作。它们分别解决了“输出质量不稳定”“拿不到实时数据”“复杂任务无法一次完成”“单角色视角受限”这几个 Agent 落地中最实际的问题。动手实践的优先级也很明确先实现一个最简单的生成-评审-修正循环体验反思模式的价值然后接入一两个工具理解 Function Calling 和 MCP 的用法再尝试用规划拆解一个复杂任务最后才是多智能体协作。如果连最小闭环都没有跑通不要急着把架构铺得很大否则只会增加排查难度。如果你已经能熟练使用 LangGraph、crewAI 或 Dify 搭建 Agent 流程下一步值得深入的方向是 Agent 的评测体系——不是看某一个 Demo 是否成功而是如何在不同任务集上稳定评估 Agent 的表现并持续优化。Agent 开发到现在已经不再是“会不会调用 API”的问题而是“如何设计一套可靠、可观测、可维护的智能体系统”的工程问题。这套课程能帮你完成从 0 到 1 的认知搭建但真正让技术变成能力的是回到自己的业务场景里把一个具体的任务交给 Agent 反复调试。建议把文中的几个代码示例存下来作为你的第一个 Agent 练习起点。