Workflow与Agent区别详解：从控制流、成本到选型实践

Agent 和 Workflow 到底有啥区别这是很多人在设计大模型应用时第一个撞上的概念问题。简单说Workflow 是“把过程写死”Agent 是“让模型决定过程”。两者都可以调用大模型、工具和知识库但控制权、错误处理和成本模型完全不同。很多项目一开始只需要 Workflow越做越复杂之后才被逼着引入 Agent也有一些项目为了追赶热点直接上 Agent结果出现无限循环、工具误调、账单飙升。要真正回答这个问题不能只背定义需要从控制流、记忆、工具、可观测性、成本和故障恢复几个维度一起看。下面先用一个评价框架说明本质区别再用两个最小示例演示它们的执行方式之后给出混合编排、排错清单和选型建议。这样无论是做 RAG 客服、数据分析助手还是多智能体系统MAS都能快速判断当前场景到底该用哪一条路线。1. 先看本质Workflow 是固定流程Agent 是决策循环1.1 用外卖订单理解两种模式假设你在运营一个外卖平台。Workflow 的处理方式是把订单流程拆成固定步骤用户下单系统通知商家商家接单骑手取餐骑手配送用户确认收货。每一步做什么、下一步是谁全部由代码规则决定。如果用户备注“不要香菜”这个信息会作为参数传给备餐步骤但流程本身不会突然多出一个“去超市买香菜”的步骤。Agent 的处理方式则不同。你可以给智能体一个目标“把这个订单按时送到用户手里。”它会在执行过程中观察当前状态比如商家缺货、骑手迟到、用户改了地址然后自行决定下一步调用哪个工具。如果商家缺货它可能先调用库存查询工具再调用消息通知工具给用户发一条替换建议最后调用订单修改工具更新商品。从这里可以提炼出最核心的区别Workflow 把业务流程预先固化为有向图执行顺序确定适合问题空间稳定、步骤可以提前枚举的场景。Agent 把业务流程交给模型实时决策通过“感知、决策、行动、观察”的循环逼近目标适合步骤不确定、需要灵活应对异常的场景。1.2 技术定义确定性编排与自主执行循环从技术角度定义Workflow 是“确定性编排”流程的节点和边在建系统时已经定义。每个节点的输入输出由开发人员约定。大模型通常只负责单个节点的内容生成或分类不负责决定下一个节点。执行结果在相同输入下是可预期的。Agent 是“自主执行循环”系统只有一个高层目标具体计划由模型生成。模型根据当前观察结果选择要调用的工具。工具返回结果后模型再决定继续调用还是结束。整个过程会不断更新短期记忆并可能依赖长期记忆。所以不能简单以“是否调用大模型”来区分两者。RAG 管道里也会调用大模型但它是 Workflow一个通过函数调用查询天气的聊天机器人也可能只是 Workflow。只有当模型能够自主决定“下一步调什么、要不要继续”的时候才算是 Agent。1.3 一张表对比六个关键维度对比维度WorkflowAgent控制流开发人员用代码定义模型根据上下文动态决定工具调用在特定节点固定调用模型自主选择工具和执行顺序记忆通常是局部变量或上下文传递需要短期记忆和长期记忆机制错误处理按异常分支处理容易定位模型可能重试、换工具或直接编造结果可观测性每个节点可打日志链路清晰需要记录每轮工具调用和决策原因成本相对可控调用次数基本固定不确定轮数和 token 会波动这张表说明Workflow 的优势是稳定、可控、好排查Agent 的优势是灵活、能处理未知情况。代价是 Agent 引入随机性必须靠约束、观测和预算控制来兜底。2. 用两个最小案例感受执行方式差异为了直观下面用 Python 风格的伪代码演示。实际项目换成 OpenAI、Claude、Ollama 或任意兼容接口时只需要替换call_llm的实现整体编排思路不变。2.1 Workflow 的最小实现三步固定管道一个典型场景是“根据用户问题检索知识库再生成答案”。这里用 Workflow 实现每个步骤都是固定调用# workflow_example.py def classify(user_input: str) - str: # 固定调用分类模型只输出类别不决定流程 return call_llm(将问题分类为售后 / 售前 / 闲聊, user_input) def retrieve(query: str, knowledge_base) - list[str]: # 知识库检索不调用大模型 return knowledge_base.search(query, top_k3) def generate_answer(query: str, docs: list[str]) - str: context \n.join(docs) prompt f请基于以下资料回答问题\n{context}\n\n问题{query} return call_llm(prompt) def run_workflow(user_input: str, knowledge_base) - str: category classify(user_input) docs retrieve(user_input, knowledge_base) answer generate_answer(user_input, docs) # 注意这里不会因为 category 不同而动态增加工具调用 return f[{category}] {answer}这段代码的关键特征非常明显先分类再检索再生成顺序写死。分类结果只用于给答案加前缀并不影响流程走向。如果某一步失败整个流程抛异常由外层 try/except 处理。调用大模型的次数固定分类一次、生成一次共两次。这种结构适合“流程稳定、验收清楚”的场景。比如文档问答、工单内容抽取、每日新闻摘要都可以用 Workflow 完成不必引入 Agent。2.2 Agent 的最小实现模型驱动的循环同样是完成一个任务Agent 会先把任务拆解并在循环里反复调用工具。下面是最小可理解的“Agent 循环”# agent_example.py import json def call_llm_with_tools(messages, tools): # 伪代码请求大模型带上工具定义 response call_llm(messages, toolstools) return response def run_agent(task: str, memory: list[dict], tools: dict, max_steps: int 5) - str: messages [{role: system, content: 你是任务执行助手。}, {role: user, content: task}] for step in range(max_steps): response call_llm_with_tools(messages, list(tools.keys())) if response.get(tool_calls): for tool_call in response[tool_calls]: # 模型决定调用哪个工具工具名和参数都来自模型 tool_name tool_call[name] tool_args json.loads(tool_call[arguments]) result tools[tool_name](**tool_args) # 把工具结果写回 messages供模型继续决策 messages.append({ role: tool, tool_call_id: tool_call[id], content: json.dumps(result, ensure_asciiFalse) }) memory.append({step: step, tool: tool_name, result: result}) continue # 没有工具调用说明模型认为任务完成 return response[content] raise RuntimeError(Agent 超过最大步数任务未完成)如果把这个函数跑在“查询杭州本周天气并整理成出行建议”的任务上可能出现这样的执行轨迹模型调用get_weather工具参数是“杭州”。工具返回一周天气数据。模型继续调用search_poi工具查询适合雨天去的地点。工具返回景点列表。模型不再调用工具输出出行建议。每一步的选择都不是预先写死的。模型可能跳过search_poi也可能连续调用两次get_weather这取决于模型对任务的理解。2.3 两个示例的执行结果差异观察维度2.1 Workflow 示例2.2 Agent 示例执行步骤固定三步模型决定循环执行调用工具无模型选择调用模型次数稳定为 2 次1 到 max_steps 次不等失败表现异常直接抛出可能重试、换工具或输出不完整内容是否可复现是不完全可复现这个对比说明一个重要的工程判断如果任务的执行路径可以提前画出来就用 Workflow如果执行路径只能等执行时才知道才需要 Agent。最怕的是在流程稳定时强行引入 Agent导致每次执行结果都像盲盒。3. 选型判断从任务稳定性、决策成本和风险边界评估3.1 任务是否稳定可枚举先问一个问题如果把任务交给三个不同的工程师他们能写出相同的执行步骤吗如果能就用 Workflow。因为流程已经确定模型参与流程控制只会增加不确定性。如果不能比如“分析财报并给出投资建议”“处理客户投诉并给出解决方案”“根据项目描述生成可执行代码并自测”这类任务步骤高度依赖输入内容就需要 Agent。更具体地可以从下面几个信号判断输入类型是否有限比如枚举值、固定字段。是否需要根据中间结果动态创建新任务。是否经常出现“原本没有设计的异常情况”。业务上是否允许模型做出顺序决策。如果超过两个信号指向“不确定”至少应该考虑混合编排而不是纯 Workflow。3.2 决策成本和调用成本要算清楚Agent 的灵活不是免费的。模型每次决策都要消耗 token工具返回结果也会占用上下文。一个看起来简单的问题可能因为模型反复试错最终调用 10 次工具、消耗 5 万 token。建议在项目初期就做成本估算指标WorkflowAgent单任务平均模型调用次数固定可提前估算浮动需要压测单任务平均工具调用次数固定浮动可能重复上下文长度每个节点可控随着循环增长需要压缩超时时间可设置单节点超时需要设置总轮数和总时长失败重试策略由代码控制模型可能自行重试需限制实际项目里推荐给 Agent 设置三层预算最大循环次数、最大 token 数、最大执行时长。超过任一预算立即停止循环并交给降级流程。3.3 上下文和记忆机制决定 Agent 是否真有必要另一个经常被忽视的点是记忆。Workflow 的每一步输入输出都是显式传递的不需要“记忆”这个概念。Agent 则必须处理记忆短期记忆当前任务里的对话记录、工具返回结果。长期记忆跨任务保存的用户偏好、项目背景、历史结论。外部记忆通过向量数据库或结构化数据库存储和检索。如果项目根本没有长期记忆需求那么“为了记忆而上 Agent”通常是没有必要的。用一个 Workflow 把用户输入拼进上下文也能达到类似效果。3.4 安全边界和审计要求涉及订单、支付、医疗、法律等场景时可控性比智能更重要。Workflow 可以把关键动作固定在代码层不允许模型跨过审批节点Agent 则可能自主调用下单、退款、发送消息等高风险工具。在生产环境必须给 Agent 加安全围栏高危工具单独鉴权不放在 Agent 的可用工具列表里。工具调用前增加人工确认步骤。记录模型每次决策的完整工具参数和执行结果。对输出内容做敏感信息过滤和策略校验。如果业务要求每一步都必须可审计、可回滚建议先设计成 Workflow确需 Agent 时把 Agent 限制在“只建议、不执行”的辅助角色。4. 混合编排Workflow 管骨架Agent 管异常4.1 常见的混合模式实际生产项目很少是“纯 Workflow”或“纯 Agent”更常见的是混合编排外层是 Workflow负责人工审核、数据校验、结果落库。内层是 Agent负责需要动态判断的任务拆解和工具选择。部分节点也用 Workflow比如把 Agent 输出的结构化结果交给固定渲染节点。这种设计能兼顾稳定性与灵活性。下面是一个简化配置# orchestration_config.yaml pipeline: - id: validate_input type: workflow module: input_validator - id: research_and_plan type: agent description: 根据用户目标选择工具并生成执行计划 max_steps: 5 tools: - web_search - calculator - db_query memory: type: buffer max_messages: 20 - id: draft_answer type: workflow module: answer_renderer - id: risk_check type: workflow module: sensitive_word_filter这种结构下Agent 不会无边界运行它的输入来自validate_input节点的标准化结果。它在max_steps5的限制内做工具调用。它输出的产物交给draft_answer做固定渲染。最终结果还要经过敏感词过滤和人工审核。所以问题不是“Workflow 和 Agent 二选一”而是“哪些层用 Workflow 固定哪些层用 Agent 放权”。4.2 用 Workflow 约束 Agent 的范围要让 Agent 可控最简单的方式是在系统提示词里限定职责再把职责对应到你允许的工具集上。例如SYSTEM_PROMPT 你是一个研究助手。 你只能使用 search 和 summarize 两个工具。 当用户需要写邮件时你不负责直接发送只输出邮件草稿。 如果任务超过你的工具能力请直接说明不要编造结果。这类提示词不会消除模型的所有风险但能显著降低越权行为。更好的约束是代码层ALLOWED_TOOLS {search, summarize} def safe_agent_run(task, user_tools): filtered_tools {name: fn for name, fn in user_tools.items() if name in ALLOWED_TOOLS} return run_agent(task, toolsfiltered_tools)不要只靠提示词约束高风险操作。代码层的白名单、鉴权和审计日志才是可靠边界。4.3 在 Agent 中把重复子任务封装成 Skill在多智能体系统MAS里经常用“Skill”表示一个可复用的子能力。一个 Skill 可以是一个确定性函数也可以是一条小型 Workflow。Agent 的角色是判断“现在应该调用哪个 Skill”Skill 内部则不需要模型每次重新思考。举个例子Agent 判断用户需要计算订单总价。调用calculate_order_totalSkill。Skill 内部使用代码遍历明细计算结果。Agent 拿到结果后继续生成最终回复。这里的 Skill 与 Agent 的区别是Skill 是已知的固定能力Agent 是负责调度的决策者。把这一步想明白就不会把“带工具调用的 Workflow”误称为 Agent。5. 落地时最容易踩的六个坑5.1 Agent 陷入无限循环现象任务长时间不结束工具被反复调用token 消耗不断增加。原因模型没有明确判断任务完成的条件或者工具返回数据无法让模型收敛。检查方式查看每次工具调用的输入、输出和耗时。统计是否存在重复调用同一个工具且参数相同的情况。查看上下文里是否已经出现足够完成任务的信息。解决方案给run_agent增加max_steps。在系统提示词里写清“当用户问题已经回答完毕时立即停止调用工具”。对重复的工具调用做去重或告警。预防建议在 Agent 框架外增加环检测发现“同一工具、相同参数”连续出现两次时强制结束并通知开发人员。5.2 Workflow 步骤写得太死遇到异常输入直接失败现象用户输入稍微偏离预期流程就报错或返回空结果。原因Workflow 的步骤和分支基于正常流程设计没有为开放性输入预留兜底。检查方式用一批异常、口语化、多语言输入跑回归。查看每个节点的校验逻辑是否合理。观察失败发生在哪一步是解析失败还是状态不匹配。解决方案在入口增加输入标准化节点。在关键节点后增加分支无法确定后续动作时转人工或转 Agent。不要把“模型对节点的内容理解”和“流程控制”混在一起。预防建议即使是 Workflow也要为每个节点定义“成功、失败、不确定”三种出口而不是默认只有成功路径。5.3 把“工具调用”误认为 Agent现象系统只是让模型选择工具但没有循环思考和自主终止逻辑却被命名为 Agent。原因很多框架把函数调用封装得像 Agent项目里只调用了一次工具就结束。检查方式梳理一次完整任务是否包含至少一轮“模型决策 - 工具执行 - 结果回填 - 再次判断”。如果流程是“模型输出工具调用 - 程序执行 - 直接返回”那只是 Workflow 中加入了函数调用。解决方案名称上不要混用对外可以叫“AI 助手”内部架构文档里要区分 Workflow 和 Agent。如果目标是构建 Agent至少要补上循环、终止条件和记忆机制。5.4 记忆和上下文混淆现象Agent 在多轮对话里丢失用户偏好或者上下文越来越长导致费用和延迟上升。原因把 messages 全部塞进上下文没有区分短期记忆和长期记忆也没有压缩策略。检查方式查看 messages 长度和 token 分布。验证用户在多轮后是否还记得之前的信息。搜索日志中是否存在关键信息被截断。解决方案短期记忆使用对话窗口超过阈值后做摘要。长期记忆写入向量库或数据库在必要时检索注入。不要把无用的工具输出一直留在 messages 里。5.5 错误处理策略不一致现象Workflow 里出现异常就抛错Agent 里模型却可能把错误包装成正常回答。原因两种模式采用了两套错误处理逻辑没有统一规范。检查方式检查调用方是否区分“系统异常”和“模型业务失败”。查看 Agent 在工具报错后是否在回复中说“已完成”。解决方案Workflow 异常要记录错误码和上下文抛给上层处理。Agent 工具调用失败时把错误信息回传给模型但只允许有限次重试。如果重试无效必须输出“任务失败”状态而不是假装成功。5.6 成本与延迟评估缺失现象上线后才发现 Agent 单次任务消耗过高用户响应时间不稳定。原因只在理想路径上评估没有考虑重试、多轮工具调用和长上下文。检查方式用测试集统计平均调用次数、最大调用次数、token 分布。分开统计 Workflow 节点和 Agent 循环的耗时。设置预算阈值超过阈值自动熔断。解决方案在配置里限制最大步数和最大 token。优先使用小模型处理分类和摘要类节点。把高频且稳定的子任务从 Agent 循环中拆出来改成 Workflow 或 Skill。6. 生产环境选型清单与落地建议6.1 选型检查清单在决定用 Workflow 还是 Agent 时可以按下面这张清单逐项确认执行步骤能否提前绘制成流程图能优先 Workflow。输入是否可以枚举可以优先 Workflow。是否需要根据中间结果动态评估风险需要考虑 Agent。是否必须支持未知工具组合必须考虑 Agent。是否有严格的审计和回滚要求严格用 Workflow 做骨架Agent 只做建议。是否已经为超时、token、工具权限配置了预算没配不要直接上 Agent。是否有完整的日志和链路追踪没有先用 Workflow 简化排查。如果清单里大多数都是“考虑 Agent”也不要一次性把所有流程改成 Agent。建议先选一个低频、低风险场景试点观察模型决策质量和成本再逐步推广。6.2 生产落地建议无论最终选哪种模式生产环境都需要关注配置外置把模型名称、温度、最大步数、工具白名单放到配置文件或配置中心而不是硬编码。可观测性为每个节点和每次工具调用输出结构化日志至少要包含任务 ID、步骤 ID、模型返回内容和耗时。评估集准备一批真实业务样本记录 Workflow 或 Agent 的输出结果定期对比版本变化。回滚能力模型升级或提示词调整后可能导致行为漂移保留旧版本的配置和评估记录。安全护栏对用户输入做注入检测对敏感信息做过滤对高风险工具做人工审批。降级方案当模型接口超时、Agent 超过最大步数或工具不可用时需要有固定的 fallback 流程。6.3 学习路线建议如果刚开始接触这两个概念建议按下面的路径练习先用 Workflow 做一个简单的 RAG 问答要求每一步都有日志。在该 Workflow 里加入一个工具调用节点例如查询数据库或计算器。再把同一个任务改写成带max_steps的 Agent 循环观察结果差异。加入记忆、工具白名单和失败重试补上安全与审计逻辑。尝试“Agent Skill”结构把固定能力封装成 Skill让 Agent 只负责调度。最后再研究多智能体系统MAS理解多个子 Agent 之间如何用 Workflow 协议协作。这条路径的核心是让你先掌握确定性系统的可靠性再理解自主系统的灵活性最后能根据业务场景做取舍。实际项目里真正难的不是实现 Agent 循环而是为它设计边界、预算和兜底方案。Workflow 和 Agent 不是先进与落后的关系。Workflow 是骨架Agent 是大脑。稳定场景用 Workflow 控制未知场景用 Agent 探索高风险动作回到 Workflow 审核。把这个原则定下来比争论某一个框架是不是 Agent 更有价值。