当前位置：首页 > news >正文

LLM 只是开始，Agentic Workflow 才是生产力的真正解锁方式

news 2026/5/24 19:16:24

LLM 只是开始，Agentic Workflow 才是生产力的真正解锁方式

作者：软件工程师视角的技术博主
更新时间：202X年X月X日
阅读时长：预计45-60分钟
前置知识：了解大语言模型（LLM）的基础概念、Prompt Engineering 入门、Python基础（可选进阶部分需）

引言：从“问答工具”到“工作伙伴”的范式跃迁

1.1 痛点引入：LLM 时代的“天花板焦虑”

如果把2022年底ChatGPT的横空出世比作“AI的iPhone时刻”，那么在短短两年后的今天，我们已经集体进入了“LLM产品过剩”的阶段——从通用对话类的Claude、Gemini、文心一言，到垂直领域的代码助手GitHub Copilot、文档分析Notion AI、文案生成MidJourney + Claude 3.5 Sonnet的组合拳，几乎每个打工人的电脑/手机里都至少装了3个以上的LLM工具。

但你是否有过这样的LLM“天花板”体验？

场景1：需求拆解的“心累循环”

假设你是一家创业公司的产品经理，需要写一份202X年第三季度的用户留存提升方案：

你先给GPT-4o发了个100字左右的需求：“帮我写一份SaaS产品Q3的用户留存提升方案”
GPT-4o给了你一份框架很全、但完全没有贴合你们公司用户画像、竞品数据、现有运营策略的“通用模板式方案”
你不得不花30分钟补充一堆Prompt约束：“我们公司是做个人知识管理的，目标用户是25-35岁的互联网打工人，活跃率现在是18%，7日留存22%，30日留存5%，上个月试了积分签到但效果平平，竞品有Notion AI个人版、语雀空间、飞书多维表格的个人页……”
这次GPT-4o给的方案稍微好一点，但缺少具体的落地细节，比如积分体系改版的具体规则、A/B测试的分组逻辑、预算分配的比例
你又要拆成N个小问题一个个问，中间还要不断切换上下文、粘贴之前提到过的数据，问了大概20个问题，花了2个多小时，终于攒出了一份能看的初稿——但这时候你已经累得不想再改了，而且初稿里还有几个数据前后矛盾的地方

场景2：多工具协作的“断点困境”

再假设你是一位自由摄影师兼内容创作者，需要做一套“秋季人像摄影教程”的小红书图文：

用MidJourney v6生成了10张符合“治愈系、暖色调、林间小道、手持桂花茶、北京密云水库周边”要求的参考图
把参考图导出到Lightroom Classic调色，调了大概2个小时，保存了预设但忘记命名
打开Notion AI，让它根据生成的参考图和调色思路，写一篇800字左右的小红书图文文案，加了一堆话题标签
用Canva把参考图、文案、自己拍的一张实景演示图拼在一起，中间因为尺寸调整、文字排版又花了1个小时
最后发布到小红书的时候，发现话题标签格式不对（比如加了中文空格、重复了），预设也找不到了——整套流程下来，花了5个多小时，但真正“有创造性”的部分（比如确定风格、实景拍摄）只占了1个小时，剩下的4个小时全是在做重复的、机械的、跨工具的衔接工作

场景3：复杂任务的“执行缺失”

如果你是一位数据分析师，需要完成一份“202X年Q2公司电商平台的销售漏斗分析报告”：

你给GPT-4o SQL Expert写了一堆自然语言的查询要求，比如“帮我查询202X年4-6月，天猫、京东、拼多多三个渠道的UV、PV、加购率、转化率、客单价”
GPT-4o SQL Expert生成了一段SQL代码，你复制到公司的BigQuery里执行，结果报错说表名不对（因为公司最近刚把表名从sales_data改成了ecommerce_sales_202X）
你把报错信息和正确的表名告诉GPT-4o SQL Expert，它重新生成了代码，这次执行成功了，但导出的CSV文件太大（10GB），没法直接用Excel打开
你又问GPT-4o Python Expert怎么处理大文件，它给了你一段用Pandas分块读取的代码，你复制到PyCharm里，结果报错说缺少pandas和numpy的依赖
你安装了依赖，重新运行代码，这次成功把10GB的CSV文件压缩成了10MB的汇总Excel，但汇总的维度又不对（比如没有按“地区-城市-区县”三级拆分）
你又要改代码、重新运行、重新汇总，前前后后花了3个多小时，终于拿到了正确的数据——但这时候你已经没有精力去做深度的数据分析和可视化了，只能匆匆忙忙画了几个柱状图、折线图交差

1.2 核心问题：为什么LLM alone 无法真正解锁生产力？

上述三个场景，其实反映了当前LLM应用的三个核心局限性：

上下文窗口有限+多轮对话效率低：虽然GPT-4o的上下文窗口已经扩展到了128K tokens（Claude 3 Opus甚至达到了200K tokens），但对于复杂的跨工具、跨多轮、跨数据源的任务来说，128K/200K tokens仍然不够用——而且即使上下文窗口够大，多轮对话的效率也非常低：你需要不断切换上下文、粘贴数据、解释规则，LLM也需要不断理解新的约束、修正之前的错误，整个过程就像“挤牙膏”一样
缺乏“自主决策+自主执行”的能力：当前的LLM本质上只是一个“概率语言模型”，它只能根据输入的Prompt生成“最可能的下一个token”，无法像人类一样设定目标、拆解任务、规划步骤、选择工具、执行任务、监控进度、修正错误、总结反思——也就是说，它只是一个“执行者”，而不是一个“决策者”，更不是一个“自主工作者”
跨工具、跨数据源的“断点协作”问题：当前的LLM工具大多是“孤岛式”的——GitHub Copilot只能写代码，Notion AI只能处理文档，MidJourney只能生成图像，Canva只能做设计，BigQuery/PyCharm只能处理数据……要完成一个复杂的任务，你需要在这些工具之间不断切换、复制粘贴、手动衔接，而这些“断点工作”往往占据了整个任务80%以上的时间

1.3 解决方案概述：什么是Agentic Workflow？

要解决上述三个核心局限性，我们需要的不是“更大、更强的LLM”，而是一套能够让LLM“自主决策、自主执行、自主协作”的工作流——这就是Agentic Workflow（代理工作流）。

1.3.1 核心概念（通俗版）

通俗来讲，Agentic Workflow就是把LLM变成一个“会思考、会干活、会协作的虚拟员工”：

你只需要给它一个清晰的、可量化的目标（比如“帮我生成一份SaaS产品Q3的用户留存提升方案，要求有具体的落地细节、预算分配、A/B测试计划，字数控制在5000字以内”）
它会自动设定子目标、拆解任务、规划步骤、选择合适的工具（比如文档数据库、代码编辑器、数据分析工具、设计工具等）、执行任务、监控进度、修正错误、总结反思
最后它会给你一个完整的、符合要求的交付成果——中间所有的“断点工作”“挤牙膏式的多轮对话”“跨工具协作”都由它自动完成

1.3.2 核心概念（学术/技术版）

从学术/技术的角度来看，Agentic Workflow是由一个或多个LLM Agent（代理）组成的、能够自主完成复杂任务的闭环工作流。

其中，LLM Agent（代理）是Agentic Workflow的核心单元，它通常由以下四个核心组件组成（我们会在后面的章节详细展开）：

LLM Core（大语言模型核心）：作为Agent的“大脑”，负责理解目标、生成决策、执行推理
Memory System（记忆系统）：作为Agent的“大脑皮层+硬盘”，负责存储短期记忆（当前任务的上下文）、长期记忆（历史任务的经验、规则、数据等）
Tool Use（工具使用）：作为Agent的“手脚”，负责与外部世界交互——比如调用API、读写文件、执行代码、操作数据库、使用设计工具等
Planning & Reflection（规划与反思）：作为Agent的“思维闭环”，负责设定子目标、拆解任务、规划步骤、监控进度、修正错误、总结反思

而Agentic Workflow（代理工作流）则是将一个或多个LLM Agent通过某种方式（比如串联、并联、层次化、协作化等）组织起来，形成一个能够自主完成复杂任务的闭环系统。

1.4 最终效果展示：Agentic Workflow vs LLM alone 的对比

为了让大家更直观地感受到Agentic Workflow的威力，我们先来看一个简化版的对比示例（后面的章节会有完整的、可复现的实战案例）：

1.4.1 任务目标

帮我生成一份202X年Q2公司电商平台的销售漏斗分析报告，要求：

查询202X年4-6月，天猫、京东、拼多多三个渠道的UV、PV、加购率、转化率、客单价、复购率
按“地区-城市-区县”三级拆分数据
处理大文件（原始数据约10GB）
用Python的Matplotlib和Seaborn生成可视化图表（柱状图、折线图、漏斗图、热力图）
写一份3000字左右的分析报告，包含数据解读、问题发现、优化建议
将所有内容打包成一个PDF文件

1.4.2 LLM alone 的执行流程（耗时约8小时）

如场景3所述，整个流程需要：

拆成N个小问题，多轮对话（约20轮）
手动切换工具（BigQuery → PyCharm → Excel → Canva → Word → PDF转换器）
手动修正错误（约5次）
手动衔接数据（约10次）
手动生成可视化图表（约1小时）
手动写分析报告（约2小时）
手动打包成PDF（约10分钟）

1.4.3 Agentic Workflow 的执行流程（耗时约30分钟）

而使用Agentic Workflow的话，整个流程只需要：

打开一个基于Agentic Workflow的工具（比如AutoGPT、GPT-4o with Advanced Data Analysis + Custom Tools、LangChain Agent、CrewAI等）
给它一个清晰的、可量化的目标Prompt（大概200字左右）
点击“开始执行”按钮
30分钟后，它会自动给你一个打包好的PDF文件，包含所有要求的内容——中间所有的“断点工作”“挤牙膏式的多轮对话”“跨工具协作”都由它自动完成

1.5 价值主张：为什么Agentic Workflow 是生产力的真正解锁方式？

从上述对比示例可以看出，Agentic Workflow 相比 LLM alone，具有以下三个核心价值：

效率提升10-100倍：将“断点工作”“挤牙膏式的多轮对话”“跨工具协作”的时间从80%以上降低到10%以下，让你把更多的时间花在“有创造性”的部分
质量大幅提升：Agentic Workflow 具有“规划与反思”的能力，能够不断监控进度、修正错误、总结反思，避免了LLM alone 容易出现的“前后矛盾”“数据错误”“框架不全”等问题
降低使用门槛：你不需要再学习“Prompt Engineering 的高级技巧”“SQL的语法”“Python的数据分析库”“设计工具的操作”——只需要给Agent一个清晰的、可量化的目标，它就能自动完成所有的工作

1.6 文章脉络：本文的讲解思路和结构

本文是一篇深度剖析+问题解决型的技术博客，我们将按照以下思路和结构进行讲解：

引言：从LLM时代的“天花板焦虑”入手，引出核心问题，介绍什么是Agentic Workflow，展示最终效果对比，提出价值主张，梳理文章脉络
基础概念篇：详细解释Agentic Workflow的核心概念——包括LLM Agent的四个核心组件、Agentic Workflow的四种常见架构模式、Agentic Workflow与其他相关概念（比如RAG、Prompt Engineering、AutoML等）的区别与联系
核心原理解析篇：深入探讨Agentic Workflow的核心原理——包括LLM Core的推理机制（Chain-of-Thought、Tree-of-Thought、Graph-of-Thought等）、Memory System的设计与实现（短期记忆、长期记忆、向量数据库等）、Tool Use的设计与实现（Function Calling、ToolFormer、ReAct等）、Planning & Reflection的设计与实现（Goal Decomposition、Step Planning、Self-Correction、Iterative Refinement等）
实战案例篇：通过三个完整的、可复现的实战案例，手把手教你如何使用Agentic Workflow——包括使用AutoGPT完成“电商平台销售漏斗分析报告”、使用LangChain Agent完成“个人知识管理系统的搭建与优化”、使用CrewAI完成“秋季人像摄影教程的小红书图文制作”
最佳实践与常见问题篇：分享Agentic Workflow的10个最佳实践，解答10个常见问题，分析Agentic Workflow的优缺点与适用场景
行业发展与未来趋势篇：梳理Agentic Workflow的发展历史（从早期的专家系统到现在的LLM Agent），分析当前的行业现状，展望未来的发展趋势
总结与展望篇：回顾文章的核心内容和关键步骤，总结Agentic Workflow的核心价值，展望Agentic Workflow的未来发展前景，提供相关的学习资源和链接

基础概念篇：拆解Agentic Workflow的“四梁八柱”

在引言部分，我们已经对Agentic Workflow有了一个初步的了解——通俗来讲，它就是把LLM变成一个“会思考、会干活、会协作的虚拟员工”；从学术/技术的角度来看，它是由一个或多个LLM Agent组成的、能够自主完成复杂任务的闭环工作流。

在这一篇章中，我们将深入拆解Agentic Workflow的“四梁八柱”——包括LLM Agent的四个核心组件、Agentic Workflow的四种常见架构模式、Agentic Workflow与其他相关概念的区别与联系。

2.1 核心概念：什么是LLM Agent？

LLM Agent（代理）是Agentic Workflow的核心单元，也是Agentic Workflow能够“自主决策、自主执行、自主协作”的关键。

2.1.1 LLM Agent的定义（学术版）

在2023年发表的一篇名为《The Rise and Potential of Large Language Model Based Agents: A Survey》的综述论文中，作者对LLM Agent给出了一个非常严谨的学术定义：

LLM Agent（基于大语言模型的代理）是一种以大语言模型（LLM）为核心控制器的计算系统，它能够感知外部环境、存储和检索记忆、使用各种工具、制定和执行计划、与其他代理或人类交互，从而自主完成一个或多个复杂的目标。

2.1.2 LLM Agent的定义（通俗版）

为了让大家更容易理解，我们可以把LLM Agent比作一个**“刚入职的虚拟实习生”**：

LLM Core（大语言模型核心）就是这个虚拟实习生的“大脑”——它具备一定的知识储备、推理能力、沟通能力，但没有任何“工作经验”
Memory System（记忆系统）就是这个虚拟实习生的“大脑皮层+工作日志+公司知识库”——大脑皮层存储短期记忆（比如今天的任务目标、刚才和老板的对话内容），工作日志存储长期记忆（比如之前完成的任务、犯过的错误、学到的经验），公司知识库存储一些通用的规则、流程、数据等
Tool Use（工具使用）就是这个虚拟实习生的“手脚+办公设备”——它可以使用电脑、打印机、Excel、Word、Python、API等各种工具，来完成具体的工作
Planning & Reflection（规划与反思）就是这个虚拟实习生的“思维闭环”——它可以先理解老板的需求，然后制定一个工作计划，接着按照计划一步步执行，执行过程中如果遇到问题，它会主动想办法解决，或者向老板请教，最后完成任务后，它会写一份工作总结，反思自己在任务中做得好的地方和做得不好的地方，以便下次做得更好

2.1.3 LLM Agent的四个核心组件详解

在引言部分，我们已经提到了LLM Agent的四个核心组件——LLM Core、Memory System、Tool Use、Planning & Reflection。现在，我们将对这四个核心组件进行更详细的解释（后面的章节会有更深入的原理剖析和代码实现）。

2.1.3.1 LLM Core（大语言模型核心）

LLM Core是LLM Agent的**“大脑”，也是整个Agentic Workflow的“中央处理器”——它负责所有的理解、推理、决策、生成**工作。

LLM Core的核心功能包括：

目标理解：理解用户输入的目标（自然语言或结构化语言），将其转化为Agent能够执行的指令
推理生成：使用Chain-of-Thought（思维链）、Tree-of-Thought（思维树）、Graph-of-Thought（思维图）等推理机制，生成决策、执行步骤、反思内容等
工具调用决策：根据当前的任务状态，决定是否需要调用工具、调用哪个工具、如何调用工具
记忆检索决策：根据当前的任务状态，决定是否需要检索记忆、检索哪些记忆、如何检索记忆
交互生成：生成与其他代理或人类交互的内容（自然语言或结构化语言）

LLM Core的常见选择包括：

闭源LLM：比如OpenAI的GPT-4o、GPT-4o mini、GPT-3.5 Turbo，Anthropic的Claude 3 Opus、Claude 3.5 Sonnet、Claude 3 Haiku，Google的Gemini 1.5 Pro、Gemini 1.5 Flash，百度的文心一言4.0，阿里的通义千问4.0等
开源LLM：比如Meta的Llama 3、Llama 3.1，Mistral AI的Mistral 7B、Mixtral 8x7B、Mixtral 8x22B，Microsoft的Phi-3，Zephyr等

选择LLM Core的核心指标包括：

推理能力：比如MMLU、GSM8K、HumanEval等基准测试的得分
上下文窗口大小：比如128K tokens、200K tokens、1M tokens等
工具调用能力：比如是否支持Function Calling、ToolFormer等
生成速度：比如每秒生成多少个tokens
成本：比如每1K tokens的输入/输出价格
安全性：比如是否有内容过滤、隐私保护等功能
可定制性：比如是否支持微调、LoRA、QLoRA等

2.1.3.2 Memory System（记忆系统）

Memory System是LLM Agent的**“大脑皮层+硬盘”——它负责存储和检索短期记忆、长期记忆、通用知识**，解决了LLM Core“上下文窗口有限”“无法记住历史任务的经验”“无法获取实时/私有知识”的问题。

Memory System的核心功能包括：

记忆存储：将LLM Core生成的内容、工具调用的结果、外部环境的信息等存储到记忆系统中
记忆检索：根据LLM Core的请求，从记忆系统中检索相关的内容
记忆更新：根据LLM Core的反思内容，更新长期记忆中的经验、规则、数据等
记忆压缩：对短期记忆进行压缩，避免占用过多的上下文窗口
记忆遗忘：对长期记忆中不重要的内容进行遗忘，避免占用过多的存储空间

Memory System的常见分类包括：

短期记忆（Short-Term Memory, STM）：也称为“工作记忆（Working Memory）”，存储当前任务的上下文——比如用户输入的目标、之前的推理步骤、工具调用的结果、外部环境的最新信息等。短期记忆的容量通常比较小（比如相当于LLM Core的上下文窗口大小），而且只能存储较短的时间（比如当前任务完成后就会被清空）。短期记忆的常见实现方式包括：直接使用LLM Core的上下文窗口、使用FIFO（先进先出）队列、使用滑动窗口等。
长期记忆（Long-Term Memory, LTM）：存储历史任务的经验、规则、数据等——比如之前完成的任务、犯过的错误、学到的经验、用户的偏好、公司的知识库等。长期记忆的容量通常非常大（几乎不受限制），而且可以存储很长的时间（比如几年、几十年）。长期记忆的常见实现方式包括：向量数据库（Vector Database）、关系型数据库（Relational Database）、文档数据库（Document Database）、图数据库（Graph Database）等。
通用知识记忆（General Knowledge Memory）：存储LLM Core已经预训练过的通用知识——比如历史、地理、科学、技术、文化等。通用知识记忆通常不需要单独实现，因为它已经内置在LLM Core中了。
实时/私有知识记忆（Real-Time/Private Knowledge Memory）：存储LLM Core预训练时没有的实时/私有知识——比如今天的新闻、公司的最新财报、用户的私人数据等。实时/私有知识记忆通常需要通过RAG（Retrieval-Augmented Generation，检索增强生成）技术来实现，我们会在后面的章节详细展开RAG与Agentic Workflow的区别与联系。

Memory System的常见技术包括：

向量嵌入（Vector Embedding）：将文本、图像、音频等非结构化数据转化为高维向量（比如1024维、2048维、4096维等），以便进行相似度计算和检索。常见的向量嵌入模型包括：OpenAI的text-embedding-3-small、text-embedding-3-large，Anthropic的Claude Embeddings，Google的Gemini Embeddings，Meta的Llama Embeddings，Sentence-BERT等。
向量数据库（Vector Database）：专门用于存储和检索高维向量的数据库——它支持快速的相似度搜索（比如Top-K搜索、余弦相似度搜索、欧氏距离搜索等）。常见的向量数据库包括：Pinecone、ChromaDB、FAISS（Facebook AI Similarity Search）、Weaviate、Milvus、Qdrant等。
RAG（Retrieval-Augmented Generation）：将向量检索与LLM生成结合起来的技术——它首先从向量数据库中检索与当前任务相关的内容，然后将检索到的内容与用户的输入一起输入到LLM Core中，最后LLM Core根据检索到的内容和用户的输入生成输出。RAG技术解决了LLM Core“无法获取实时/私有知识”“容易产生幻觉（Hallucination）”的问题。

2.1.3.3 Tool Use（工具使用）

Tool Use是LLM Agent的**“手脚”**——它负责与外部世界交互，解决了LLM Core“无法执行具体的操作”“无法获取实时/私有知识”“无法处理非结构化数据”的问题。

Tool Use的核心功能包括：

工具定义：将外部工具（比如API、函数、数据库、设计工具等）的功能、参数、返回值等定义为LLM Core能够理解的格式（比如JSON Schema、OpenAPI Schema等）
工具调用决策：LLM Core根据当前的任务状态，决定是否需要调用工具、调用哪个工具、如何调用工具
工具执行：根据LLM Core的决策，执行对应的工具调用
工具结果处理：将工具调用的结果转化为LLM Core能够理解的格式（比如自然语言、JSON等），然后存储到记忆系统中

Tool Use的常见类型包括：

数据处理工具：比如SQL查询工具、Python代码执行工具、Excel处理工具、CSV处理工具等
信息检索工具：比如Google搜索工具、Bing搜索工具、维基百科搜索工具、新闻API工具等
文件操作工具：比如文件读取工具、文件写入工具、文件删除工具、文件压缩工具、文件解压工具等
API调用工具：比如OpenAI API工具、Anthropic API工具、Google Maps API工具、GitHub API工具、电商平台API工具等
设计工具：比如MidJourney API工具、Stable Diffusion API工具、Canva API工具、Figma API工具等
其他工具：比如翻译工具、语音识别工具、语音合成工具、代码格式化工具、代码调试工具等

Tool Use的常见实现方式包括：

Function Calling（函数调用）：OpenAI、Anthropic、Google等闭源LLM厂商提供的官方工具调用功能——它允许LLM Core生成一个JSON格式的函数调用请求，然后你可以根据这个请求执行对应的函数，最后将函数的返回值输入到LLM Core中。Function Calling是目前最简单、最常用的Tool Use实现方式。
ToolFormer：Meta在2023年发表的一篇名为《ToolFormer: Language Models Can Teach Themselves to Use Tools》的论文中提出的Tool Use实现方式——它通过微调的方式，让LLM Core学会自己决定是否需要调用工具、调用哪个工具、如何调用工具。ToolFormer的优点是不需要依赖闭源LLM厂商的Function Calling功能，可以使用开源LLM实现；缺点是需要进行微调，成本较高。
ReAct（Reasoning + Acting）：Google在2022年发表的一篇名为《ReAct: Synergizing Reasoning and Acting in Language Models》的论文中提出的Tool Use实现方式——它将推理（Reasoning）和行动（Acting）结合起来，让LLM Core在执行每一步行动之前，先进行推理，然后根据推理的结果执行行动，最后根据行动的结果进行下一步的推理。ReAct的优点是可以提高LLM Core的推理能力和工具调用的准确性；缺点是生成速度较慢，成本较高。
LangChain Tools：LangChain框架提供的一套标准化的Tool Use实现方式——它封装了大量的常用工具（比如Google搜索工具、Python代码执行工具、SQL查询工具等），并提供了一套统一的接口，让你可以轻松地将这些工具集成到LLM Agent中。