Agentic AI 智能体工作流

31 篇文章 5 个主题模块 进入文章后，左侧会展开本课程章节

01 Agentic工作流简介(Introduction to Agentic Workflows)

  1. 01 欢迎来到本课程 Welcome! 创造初衷 →
  2. 02 什么是智能体 AI？ What is agentic Al? “非智能体”工作流指的是用户通过一个单一提示（prompt），要求大型语言模型（LLM）一次性完成整个任务，这种工作流被称为“零样本”（zero-shot）工作流。 →
  3. 03 自主程度 Degrees of autonomy 过去几年，AI社区内关于“什么是智能体”的定义存在争议，有人写论文定义它，也有人否认某些系统是“真正的智能体”。已经有'agent'这个词，为什么还要创造'Agentic'? →
  4. 04 智能体 AI 的优势 benefits-of-agentic-ai 1. 性能飞跃（Much Better Performance） 2. 并行加速（Faster than Humans because of Parallelization） 3. 模块化设计（Modular: Can Add/Update/Swap Components） →
  5. 05 智能体 AI 的应用 Agentic-ai-applications - agentic-ai一种让 AI Agent 根据明确或动态的任务目标，自主调用工具、访问数据库、执行步骤并完成任务的工作模式。 - 不同于传统“输入-输出”的简单问答，它强调多步骤规划、工具使用、状态更新与决策能力。 自动化处理企业收到的发票，提取关键信息并记录到数据库，以确保及时付款。 →
  6. 06 为什么需要任务分解？ Task decomposition:Identifying the steps in a workflow? 任务分解是构建代理型AI工作流的关键技能。其核心思想是： 1. 观察人类行为: 思考如果一个人类要完成这个任务，他会怎么做？ 2. 拆解步骤: 将整个任务拆解成多个独立的、清晰的子步骤。 3. 评估可行性: 对每个子步骤，思考它是否能用大型语言模型（LLM）或某个工具（如API、函数调用）来实现。 4. 迭代优化: 如果初步分解的效果不理想，可以进一步细化某个步骤，将其拆分成更小的子步骤，直到达到满意的性能。 →
  7. 07 评估智能体 AI（评测）Evaluation agentic Al (evals) - 预测成败的关键：在团队合作中，能否有效评估工作流是区分“做得好”与“做得差”的最大因素之一。 - 驱动迭代优化：没有评估，就无法知道哪里出了问题，也无法改进。 - 避免“黑盒”陷阱：不能只看最终输出，要深入分析中间过程和错误根源。 →
  8. 08 智能体设计模式 Agentic design patterns 智能体工作流的核心思想是将复杂的任务分解为一系列基础“构建模块”（building blocks），然后通过特定的设计模式将这些模块组合、串联起来，从而构建出能够处理复杂问题的系统。 - 核心概念： 让模型对自己的输出进行检查、评估和改进。 - 工作流程： 1. 初始生成： 模型根据任务要求生成一个初步结果（如代码）。 2. 自我评估/外部评估： 将该结果作为输入，再次提示同一个或另一个模型，要求其对结果进行批判性分析（如检查正确性、风 →

02 反思设计模式(Reflection Design Pattern)

  1. 01 反思如何改进任务输出 Reflection to improve outputs of a task “反思模式”是经常使用且实现起来“出奇地简单”的一种方法。 →
  2. 02 为什么不一次直接生成？Why not just direct generation? 在“直接生成”（Direct Generation）与“反思工作流”（Reflection Workflow）之间，我们为何更倾向于要采用一个包含反思步骤的复杂工作流？这个问题直指AI应用的核心权衡：效率 vs. 质量。 虽然“直接生成”看似简单快捷，但“反思”能带来更优的结果，值得我们投入额外的计算成本。 →
  3. 03 图表生成工作流程 Chart generation workflow 如何利用“反思设计模式”结合多模态AI，将一份粗糙的图表初稿，迭代优化为清晰、美观、专业的可视化作品。 通过一个咖啡销售数据的实战案例，生动展示了AI如何像人类专家一样“审视”和“改进”自己的工作成果。 →
  4. 04 评估反思的影响 Evaluating the impact ofreflection 反思（Reflection）作为一种设计模式，能有效提升agent性能，但其代价是会略微拖慢agent速度。因此，关键在于如何科学地评估反思带来的实际收益，从而在“性能提升”与“效率损耗”之间做出明智取舍。 反思工作流 →
  5. 05 使用外部反馈（Using external feedback） 在构建AI智能体工作流时，单纯的“自我反思”存在性能瓶颈。真正的突破在于引入外部反馈（External Feedback）。这不仅能打破性能天花板，还能让系统获得全新的、更强大的信息源，从而实现质的飞跃。 - 横轴：投入在提示词工程上的时间。 - 纵轴：系统性能。 - 红色曲线（无反思）： - 初期，通过调整提示词，性能会快速提升。 - 但很快，性能增长会放缓并趋于平缓，进入“平台期”。此时，即使再花费大量时间微调提示词，也很难获得显著 →

03 工具使用(Tool Use)

  1. 01 工具使用 Tool Use 核心思想：工具即函数，模型自主决策 关键在于，模型拥有自主决策权。它不再是被动地根据内部知识库生成答案，而是能主动判断：在当前情境下，是否需要、以及应该调用哪个工具来完成任务。 就像人类借助锤子、扳手等工具能完成徒手无法做到的事情一样，语言模型通过调用“函数工具”，也能突破自身训练数据和能力的限制，变得无比强大。 例子：工具使用的运作流程 以“现在几点？”为例，清晰展示了工具使用的完整闭环： 1. 输入提示 (Input Prompt) →
  2. 02 创建工具 Creating a Tool LLM本身并不会直接执行代码或调用函数，它被训练的核心能力是生成文本。 如何让LLM学会调用函数的过程，核心思想是模型不直接调用，而是“请求”调用。工具其实就是一些代码/函数。如今的主流语言模型都经过直接训练去使用工具，没有训练就必须得写提示词来告诉模型如何使用工具。 →
  3. 03 工具调用语法 Tool Use Syntax 工具调用的本质： - LLM（大语言模型）本身不会直接调用工具。 - LLM 会“请求”开发者去调用某个工具，开发者负责执行该工具并将其结果返回给 LLM。 - 在开发社区中，人们常简化说“LLM 调用了工具”，但这在技术上并不准确，仅是一种便捷的说法。 →
  4. 04 工具使用 - 代码执行 Tool Use: Code Execution 代码执行（Code execution）是让大型语言模型（LLM）能够编写并运行代码，以解决用户提出的任务。 - 核心优势: - 强大能力: LLM生成的代码方案常常出人意料地聪明和有效，能解决各种复杂任务。 - 灵活性: 相比于为每个功能手动创建独立工具，让模型自己写代码是一种更灵活、可扩展性更强的方法。例如，一个科学计算器有大量功能按钮，不可能为每个按钮都创建一个工具。 - 提升应用性能: 许多语言模型的训练者会专门优化模型，以确保 →
  5. 05 工具使用 - MCP Model Context Protocol 定义：MCP（Model Context Protocol，模型上下文协议）是由 Entropy 提出的一个标准，旨在为大型语言模型（LLM）提供一种标准化的方式来访问外部工具和数据源。 目的：解决开发者在构建智能体式应用时，需要为每个应用重复编写代码来集成不同工具（如 Slack, GitHub, Google Drive 等）的痛点。 现状：该协议已被许多公司和开发者广泛采用，形成了一个活跃的生态系统。 →

04 构建Agentic AI的实用技巧(Practical Tips for Building Agentic AI)

  1. 01 4.1 评估（evals）(Evaluations (evals)) 写在前面 你好，我是第四/五模块的作者杨若朴，很高兴能和你学习分享这些课程。 在这两个模块中，有时你会看到像现在这句话一样，使用了markdown引用语法> 的段落。 这些段落是我在记录笔记时添加的个人想法，与课程原文内容无关，仅供参考与交流。 另外，如果读者对本课程的内容有任何勘误、建议或想法，欢迎提交issue，我们会及时回复。 也可通过邮箱联系我：simuoss@163.com 在构建Agentflow/Workflow时，如何提 →
  2. 02 4.2 错误分析与制定下一步优先级(Error analysis and prioritizing next steps) 在复杂的代理式 AI 工作流程中，通过系统性的错误分析来确定工作重点，是提高系统改进效率的关键。 →
  3. 03 更多错误分析示例 More error analysis examples 接下来，我们到一些实际案例里，看看如何做错误分析。 →
  4. 04 4.4 组件级评估(Component-level evaluations) 在上一节中，我们通过错误分析确定了要改进的单个组件，那么之后就是引入组件级评估针对性改进。 →
  5. 05 4.6 解决识别到的问题(How to address problems you identify) 在跑了评估，找到问题后，就要开始着手修改了。本节介绍的正是如何改善系统中不同组件的效果。 →
  6. 06 4.7 延迟与成本优化(Latency, cost optimization) 在系统输出质量达到要求后，下一个优化重点是：优化工作流程的延迟和成本。 →
  7. 07 4.8 开发过程总结(Development process summary) 对于我们开发者而言，在开发Agent工作流时，主要精力通常集中在以下两项活动中，并不断来回切换： →

05 高度自治智能体的模式(Patterns for Highly Autonomous Agents)

  1. 01 5.1 工作流规划(Planning workflows) 就像复杂软件系统需要工厂模式、单例模式、依赖倒置等等设计模式和原则一样，Agent系统想要实现复杂度与效率并重，也需要一些设计模式。 →
  2. 02 5.10 总结(Conclusion) 吴恩达教授在本节中，回顾了整套课程涉及到的内容。 →
  3. 03 5.2 创建与执行LLM计划(Creating and executing LLM plans) 在规划模式中，如何利用结构化输出来保证 LLM 生成的计划能够被下游代码可靠地执行，是非常重要的。 →
  4. 04 5.3 结合代码执行的规划(Planning with code execution) 在上节中，我们让LLM用JSON描述了自己的动作。但是不妨想想，与其让 LLM 输出 JSON 等结构化数据来表示计划，不如直接让 LLM 直接编写软件代码来的效果更好。LLM可以直接用代码来表达计划的多个步骤和工具调用。 →
  5. 05 5.5 多智能体工作流(Multi-agentic workflows) 尽管所有Agent可能都基于同一个底层 LLM ，并运行在同一台电脑上，但将复杂任务分解成多个独立的角色或进程是一种更有效的开发方法，就像团队协作或计算机的多线程/多进程一样。 →
  6. 06 5.7 多智能体系统的通信模式(Communication patterns for multi-agent systems) 当一个团队一起工作时，他们之间的沟通模式可能会非常复杂。类似地，设计多智能体系统的通信模式也同样复杂，而组织结构的好坏会极大影响系统的效率与结果。 →