先说结论Workflow 是“设定好的流水线”Agent 是“能自己做决定的任务执行器”。这两年在 AI 应用开发圈里Agent和Workflow几乎成了必聊概念。尤其是大模型能力上来之后经常听人说“用 Workflow 编排多个 Agent 做了一个多智能体系统”也有人说“我的流程用 Workflow 做得挺稳没必要上 Agent”。乍一听好像都对真到自己设计系统时却容易卡在同一个问题上同一个需求到底应该画成固定流程还是交给 Agent 自主决策这篇文章不讲抽象概念直接从工程视角拆。先给一张对照表然后分别用代码演示同一任务在两种模式下的实现差异再聊多智能体系统、成本控制、性能观察和排查思路。看完你至少能回答三个问题它们到底区别在哪、实际项目里怎么选、怎么避免把 Agent 用成昂贵的 if-else。1. Agent 和 Workflow 核心区别速览先把最关键的信息放到最前面后面所有分析都围绕这张表展开。对比维度Workflow工作流Agent智能体本质预先定义好的固定流程自主决策的闭环循环流程控制开发者写死按步骤执行模型根据目标动态决定下一步确定性高相同输入基本得到相同执行路径低相同目标可能走不同路径灵活性弱新增场景需要改代码强可以处理边界情况和意外输入是否依赖 LLM不一定每一步可以由固定规则实现核心是 LLM 决策通常由 LLM 驱动循环工具调用在每个节点显式调用工具模型自主判断“要不要调用工具、调用哪个、参数是什么”错误处理节点结果判断写到分支里模型重试或换方案类似人的纠错可控性高输出路径可预期低需要加护栏和约束调试难度低每步结果可复现高需要日志追踪决策链成本通常较低LLM 调用次数可控通常较高一次任务可能多次调用 LLM适合场景流程固定、规则明确、要求稳定需求开放、信息不确定、需要动态拆解典型例子文档解析 - 分段 - 摘要 - 导出给定一个业务目标自主搜索、写代码、跑测试、修订与 MAS 的关系可用于编排多 Agent 的执行顺序多个 Agent 配合可组成多智能体系统(MAS)一句话总结Workflow 是“按剧本走”Agent 是“带着目标自己想办法”。2. 为什么这两个概念总是被混在一起很多人分不清 Agent 和 Workflow原因是实际项目里它们经常一起出现。比如一个“智能客服系统”里面可能有一个 Workflow先识别用户意图再决定走退款流程还是咨询流程而“退款流程”内部又可能由一个 Agent 负责和用户对话、查订单、调用退款接口。在这个例子里Workflow 是骨架Agent 是骨架上的执行单元。但混在一起不等于没有区别。判断一个系统是 Workflow 还是 Agent只需要看一个关键特征执行路径是不是在执行前就完全确定。Workflow执行路径在运行前已经写死。步骤 A - 步骤 B - 如果条件成立 - 步骤 C。哪怕有分支判断分支的条件和顺序也是开发者提前定义的。Agent执行路径在运行时由模型决定。模型拿到目标后先规划再行动然后观察结果再调整计划直到完成目标。这个“规划 - 行动 - 观察 - 再规划”的循环通常被称为 Agent Loop。更直白地理解Workflow 像餐厅后厨的固定出餐流程洗菜 - 切菜 - 炒制 - 装盘每一步都是标准操作。Agent 像一个临时雇来的厨师你告诉他“做一桌客人满意的菜”他自己决定买什么菜、用什么做法、什么时候调整口味。这就是本质区别Workflow 的智能在设计时已经注入Agent 的智能在运行时由模型动态发挥。3. 再往下拆Workflow 到底由什么组成3.1 一个典型 Workflow 的组成部分以“把一篇 PDF 转成结构化 Markdown 笔记”为例这个 Workflow 通常是PDF 上传 - 文本抽取 - 按标题切分 - 逐段调用 LLM 生成摘要 - 合并摘要 - Markdown 导出流程图可以描述成输入节点PDF 文件 - 文本抽取节点本地 OCR / 解析库 - 分段节点按章节标题正则切分 - LLM 摘要节点每段调用一次模型 - 组装节点拼接标题、摘要、原文关键信息 - 输出节点写入 .md 文件这里每一步都是预先定义的每一步用什么函数开发者写死。每段文本调用多少次 LLM开发者算好。摘要格式是什么通过 Prompt 约定好。这就是 Workflow 的优势可控、稳定、每一步都能单独调试。如果某一步失败只需要看那个节点。比如“分段节点”输出的标题不对那问题大概率出在正则表达式上而不是模型上。3.2 Workflow 的局限在哪里Workflow 最大的问题是它只能处理开发者已经想到的情况。举个真实感很强的例子。假设你写了一个“文章自动发布”Workflow读取草稿 - 生成封面图 - 发布到博客平台这个流程跑得很顺。但某天草稿里出现了一个 Markdown 表格封面图生成模型又不支持表格数据流程就卡住了。因为开发者没有预设“检测到表格时怎么处理”这个分支系统就只能报错。要解决这个问题通常的做法是继续加分支读取草稿 - 检测是否含表格 - 如果含表格先转成图片 - 再生成封面图 - 发布但现实世界的输入不会只有“有表格”和“没有表格”两种。还有“草稿里有敏感词”“图片生成接口超时”“博客平台拒绝了特定格式”等各种情况。每加一种情况分支就多一层Workflow 的维护成本开始快速上升。这时候就需要 Agent 介入了。4. Agent 的技术拆解它到底比 Workflow 多了什么从工程实现角度看Agent 并不是什么神秘技术。一个最小可用的 Agent 通常包含以下模块模块作用对应 Workflow 里的角色LLM 决策核心根据目标和当前状态决定下一步动作没有对应通常是写死的逻辑工具注册表提供给模型可调用的函数列表对应显式调用的工具节点记忆Memory保存历史信息支持多轮决策对应流程中的全局变量循环控制让 Agent 不断“思考-行动-观察”直到完成没有对应Workflow 是线性/分支执行安全护栏限制 Agent 可执行的操作范围对应流程中的权限判断节点4.1 一个最小的 Agent Loop 伪代码def run_agent(task: str, max_steps: int 10): messages [ {role: system, content: 你是任务执行助手可以调用工具来完成任务。}, {role: user, content: task} ] for step in range(max_steps): # 1. 思考让模型决定下一步 response llm.chat(messages, toolsTOOL_SCHEMAS) messages.append(response) # 2. 判断模型是否认为任务已完成 if response.finish_reason stop and response.content: return response.content # 3. 行动模型可能请求调用某个工具 if response.tool_calls: for tool_call in response.tool_calls: tool_name tool_call.function.name tool_args json.loads(tool_call.function.arguments) result tools[tool_name](**tool_args) # 执行工具 messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) raise TimeoutError(Agent 执行超过最大步数)这段代码就是 Agent 和 Workflow 最核心的差异程序没有告诉模型必须先做什么、再做什么而是让模型自己决定。4.2 Agent 的“自主”体现在哪里用上面这个伪代码跑一个任务“从 10 个网页里找出去年发布的所有关于 AI Agent 的文章整理成表格。”Workflow 会按固定顺序执行访问第 1 页 - 提取内容 - 访问第 2 页 - 提取内容……Agent 则会这样工作第 1 轮模型思考“我需要先搜索相关页面”调用搜索工具。 第 2 轮模型看到搜索结果思考“结果里有 10 个链接先打开前 3 个看看”调用浏览器工具。 第 3 轮模型发现其中一个页面没有去年时间标注思考“换个来源”调用搜索工具重新查询。 第 4 轮模型收集到足够信息调用表格工具生成 Markdown 表格。 第 5 轮模型认为任务已完成输出最终结果。这就是 Agent 的核心价值面对不确定性时它能像人一样动态调整策略。当然这种灵活性是有代价的。同样的任务Workflow 可能只调用 12 次 LLMAgent 可能调用 20 次甚至更多而且 Agent 可能走错路需要日志追踪决策链才能定位问题。5. 同一个任务Workflow 和 Agent 的两种实现为了把区别落到代码层面下面用同一个任务“将一段用户反馈分类并生成回复草稿”来演示两种实现。5.1 Workflow 实现显式分支def feedback_workflow(feedback_text: str): # 第 1 步调用 LLM 进行分类 classification llm.call( 请将以下用户反馈分类为技术故障 / 产品建议 / 售后服务 / 其他。\n f反馈内容{feedback_text}\n 只输出分类名称。 ).strip() # 第 2 步根据分类走不同分支 if classification 技术故障: draft llm.call( 用户反馈了技术故障。请生成一段礼貌的回复 告诉用户已记录问题并转交技术团队。\n f反馈内容{feedback_text} ) return {category: classification, reply: draft} elif classification 产品建议: draft llm.call( 用户提出了产品建议。请生成一段回复感谢用户建议 说明会反馈给产品团队评估。\n f反馈内容{feedback_text} ) return {category: classification, reply: draft} elif classification 售后服务: draft llm.call( 用户需要售后支持。请生成一段回复请用户提供订单号 和详细问题并说明会安排专人跟进。\n f反馈内容{feedback_text} ) return {category: classification, reply: draft} else: draft llm.call( 请为这条反馈生成一段通用回复。\n f反馈内容{feedback_text} ) return {category: 其他, reply: draft}这个实现的问题很明显所有分支都是提前写死的。如果用户反馈同时包含“技术故障”和“产品建议”这个 Workflow 只能选择主要分类无法同时处理两个诉求。5.2 Agent 实现工具化决策tools { classify_feedback: classify_feedback, # 把用户反馈分成多个标签 generate_order_lookup_hint: generate_order_lookup_hint, generate_tech_reply: generate_tech_reply, generate_suggestion_reply: generate_suggestion_reply, generate_general_reply: generate_general_reply, } def feedback_agent(feedback_text: str): system_prompt ( 你是客服回复助手。你可以使用分类工具、多种回复模板工具。 你的目标是根据用户反馈内容生成一条专业、友好的客服回复。 如果反馈中同时包含多个问题请分别处理并合并到一条回复中。 ) messages [ {role: system, content: system_prompt}, {role: user, content: feedback_text} ] for _ in range(8): response llm.chat(messages, toolslist(tools.values())) messages.append(response) if response.tool_calls: for tool_call in response.tool_calls: tool_name tool_call.function.name tool_args json.loads(tool_call.function.arguments) result tools[tool_name](**tool_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) else: return response.content return Agent 达到最大步数请检查日志。当用户反馈是“我的订单一直显示配送中但我没收到货另外希望你们能增加夜间配送选项”Agent 会怎么做它会发现这段文本同时包含配送问题偏售后/技术和建议夜间配送。模型可能先调用classify_feedback分类再同时调用generate_order_lookup_hint和generate_suggestion_reply最后把两部分合并成一条完整回复。这种“动态识别并分别处理”的能力Workflow 需要开发者提前写死而 Agent 是模型自己判断出来的。5.3 两种实现的取舍实现方式优点缺点适用情况Workflow可预期、省 token、易调试需要枚举所有情况用户反馈类型固定、处理规则明确Agent能处理复杂和意外情况成本高、需要日志追踪反馈类型多变、需要动态拆解多重诉求一个更稳妥的工程策略是外层用 Workflow 做粗粒度路由内层用 Agent 处理每个路由下的复杂分支。比如先判断“这个反馈是否包含多种诉求”如果只有单一诉求走固定模板如果有多种诉求交给 Agent 动态处理。6. 多智能体系统MAS和 Workflow 不是一回事热词里经常出现“多智能体系统MAS”它的定义是用 Prompt 和 Workflow 把多个角色、多种工具的 Agent 组合起来协同完成一个复杂目标。很多人会误以为“多个 Agent 串联起来就是一个 Workflow”这是最常见的误区。一个 Workflow 可以编排 Agent但 Workflow 本身不等于 Agent也未必等于 MAS。区别在于Workflow是执行骨架描述“谁在什么时候执行什么”。单个 Agent是自主决策单元能自己决定怎么做。多智能体系统MAS是多个 Agent 的协作网络它们之间可能存在分工、竞争、协商、结果传递。从架构上看MAS 通常有两种常见实现方式6.1 编排式 MAS用 Workflow 串联多个 Agent用户输入 - 意图分析 Agent判断任务类型 - 资料收集 Agent调用搜索工具收集信息 - 内容生成 Agent基于资料写初稿 - 质量审查 Agent检查事实和格式 - 最终输出在这种模式里每个 Agent 只负责一个环节Agent 与 Agent 之间通过 Workflow 定义的顺序或条件衔接。这个系统既包含 MAS又包含 Workflow但决定整个流程走向的是 WorkflowAgent 只是在各自环节里自主发挥。6.2 路由式 MASAgent 之间动态协作主管 AgentPlanner - 拆解目标分配子任务 - 工作 Agent A执行子任务 1 - 工作 Agent B执行子任务 2 - 汇总 Agent合并结果检查是否满足目标 - 如果不满足重新分配这种模式更接近“真正的 MAS”没有固定的执行顺序主管 Agent 根据实际情况动态决定让谁做什么、要不要返工。6.3 工程建议如果目标是“多个环节的任务”优先用 Workflow 编排多个 Agent简单、可控、易排查。如果目标是“一个开放任务需要动态拆解”可以考虑路由式 MAS但要提前设计好 Agent 间的通信协议、上下文传递方式和终止条件。不建议一上来就搭 10 个 Agent 的超级系统。Agent 数量越多上下文越长token 成本越高出错的概率也越大。7. 资源占用、性能观察与成本控制Agent 和 Workflow 的另一个显著差异体现在资源占用上。这里的“资源”不只是显存或 CPU更重要的是大模型 API 的调用次数和 Token 消耗。7.1 从哪些指标判断系统是否健康指标Workflow 特征Agent 特征LLM 调用次数固定每步调用 1 次不固定随任务复杂度波动单任务 Token 消耗可预估可能翻倍甚至更多延迟稳定波动大模型思考越久延迟越高成功终止率接近 100%只要不触发异常可能陷入死循环或达到 max steps可追踪性每个节点可定位需要记录每轮决策日志7.2 如何观察推荐在 Agent 系统里加入结构化日志记录以下信息import json import datetime def log_agent_step(agent_id, step, action, tool_name, tool_args, result_preview, token_usage): log_entry { agent_id: agent_id, step: step, action: action, tool_name: tool_name, tool_args_preview: str(tool_args)[:200], result_preview: str(result_preview)[:200], timestamp: datetime.datetime.now().isoformat(), token_usage: token_usage } print(json.dumps(log_entry, ensure_asciiFalse))部署时建议给 Agent 设置三个上限max_steps最大循环次数防止死循环。max_tokens_per_call单次模型输出上限防止输出过长导致延迟飙升。max_total_tokens整个任务累计 Token 上限控制成本。7.3 如何降低 Agent 成本优先用固定 Prompt 代替模型判断。如果某个分支用正则或关键词就能判断不要为了“智能”去调用一次 LLM。工具返回结果做截断。工具返回内容太长会使上下文膨胀导致后续调用成本上升。可以在返回前只保留关键字段。引入“退出条件”。明确告诉 Agent “当用户确认满意时直接输出最终结果不要额外解释”。缓存常用结果。对于相同的查询、相同的输入先查缓存再调用 LLM。8. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 频繁调用同一个工具陷入死循环缺少终止条件或模型没有从工具结果中获得足够信息查看 Agent 日志观察每轮工具参数是否重复增加“已尝试过该结果请换一种方式”的约束或设置max_stepsWorkflow 某一步突然失败输入数据格式不符合预期打印该节点输入检查字段是否有 None增加输入校验和默认值同一个任务Agent 有时成功有时失败模型决策不稳定对比多轮日志看决策路径差异改用 Workflow 固定关键步骤只在分支点保留 AgentAgent 输出的工具参数格式错误模型生成的 JSON 不合法记录原始 tool_calls 消息在解析 JSON 时增加容错或使用更明确的工具 Schema 描述Token 消耗远高于预期上下文过长或 Agent 执行过多轮查看每次调用的 prompt token 和 completion token对上下文做摘要压缩限制工具返回长度Workflow 和 Agent 结果不一致两者对同一输入的中间处理不一致分别记录中间结果统一预处理逻辑比如分词、清洗、分类规则Agent 调用外部 API 超时外部服务不稳定查看网络请求日志增加重试机制和超时时间必要时把外部调用移到 Workflow 节点中加可靠处理多 Agent 之间信息传递丢失上下文未正确传递检查 Agent 返回结构是否包含关键字段定义统一的 Agent 输出 Schema并在 Workflow 层做字段校验9. 最佳实践与使用建议9.1 先画流程再决定用 Workflow 还是 Agent动手写代码之前先把任务拆成一个“流程图”。如果每个节点的输入输出都是明确的直接上 Workflow如果某个节点会面对大量不确定性比如“判断用户意图”“决定下一步搜索什么”这个节点才适合引入 Agent。9.2 用 Workflow 做骨架用 Agent 做分支处理这是目前最稳妥的组合方式。开发初期把主流程用 Workflow 固定下来保证系统 80% 的路径稳定可控然后在容易变化的节点设计成一个 Agent 接口后续可以随时替换实现不影响整体流程。9.3 所有 Agent 都必须有演练和日志在上线前给 Agent 准备一套测试用例集包括正常输入、边界输入、恶意输入。运行时必须记录完整决策链。否则 Agent 一旦出现问题你很难判断是模型问题、工具问题还是 Prompt 没有约束好。9.4 控制成本不是减少 Agent 数量而是减少无效决策比较理想的做法是能用规则判断的不让模型决策能用一次调用解决的不让 Agent 循环多轮。成本控制的核心是“减少无效的 LLM 调用”而不是机械地限制 Agent 数量。9.5 涉及真实数据、用户隐私、第三方接口时注意合规如果 Agent 会读取用户消息、调用支付或订单接口、下载网页、处理涉及个人信息的内容必须明确授权范围对敏感字段做脱敏对外部 API 调用设置频率限制并保留操作审计日志。不要因为“只是测试”就跳过这些边界。10. 总结与下一步用一个明确的判断标准收尾如果你的系统在执行前已经知道完整流程它就是 Workflow如果它在执行中还在决定下一步做什么它就是 Agent。实际项目里两者不是对立关系而是组合关系。工程上的正解通常是确定性路径用 Workflow 保证稳定不确定性分支用 Agent 保持灵活。建议第一次动手时这样做选一个真实的小任务比如“把一条用户反馈转成工单”。先写一版纯 Workflow 实现观察它哪里卡住。把卡住的部分替换成 Agent观察决策效果和 Token 消耗。对比两版的稳定性和成本再决定最终架构。这套流程走下来你对 Agent 和 Workflow 的理解会比只看概念要扎实得多。下一步可以继续研究的方向LangChain 的 Agent 框架、Harness 与 Agent 的关系、Agent 记忆机制、多智能体系统的通信协议。这些问题比“区别是什么”更接近工程落地也更容易踩坑。建议先把本文的代码和排查清单跑一遍再往深水区走。