上一篇讲 Tool Calling 时我把它放回了正确位置它是模型与外部能力交互的机制普通应用、Workflow 和 Agent 都可以使用。顺着这条线继续往下真正需要比较的同层问题出现了一个多步骤任务执行到一半时到底由谁决定下一步这就是理解 Workflow工作流与 Agent智能体最有效的入口。两者都能调用模型、检索知识、使用工具、等待人工也都可能包含分支和循环。区别不在“有没有 AI”更不在界面是不是聊天框而在控制权放在哪里、路径何时确定、系统怎样停止和恢复。这篇继续使用企业报销助手案例员工希望系统判断一笔 860 元的杭州差旅打车费是否合规并在确认后提交。我们分别用 Workflow、Agent 和混合架构实现它看看哪些步骤应该交给代码、模型或人工。一、先说结论关键不是“谁更智能”而是谁拥有下一步控制权Workflow 的主要执行路径由开发者预先设计。节点可以是普通函数、规则、LLM、RAG、工具或人工审批边可以按数据条件分支也可以并行、循环和等待事件。但允许出现哪些节点、怎样连接、哪些条件可以跳转通常已经写进代码或配置。Agent 则把一部分下一步选择权交给模型。模型根据目标、当前状态、上下文和可用工具决定接下来查询什么、调用哪个工具、是否追问、是否修改计划直到产生完成结果、触发限制、遇到错误或请求人工介入。所以二者不是“传统自动化”和“AI”的区别。Workflow 可以大量使用 LLMAgent 外面也必须有代码运行时、安全策略和停止条件。更准确的说法是Workflow 让模型在预定流程中完成任务Agent 让模型在受限空间中选择任务路径。判断口诀先不要问“用了几个模型”先问“运行到这里时下一步是代码已经写好的还是模型根据现场情况选择的”二、Workflow 不是一条死板直线而是一张显式可检查的执行图很多人把 Workflow 想成 A、B、C 三步顺序脚本这会低估它。生产工作流通常由节点、边、状态、事件和运行时组成节点执行工作边描述转移状态保存业务事实事件唤醒暂停任务运行时负责重试、并发、超时和恢复。分支并不会自动把 Workflow 变成 Agent。例如金额大于 5000 元进入经理审批、票据缺失时返回补充材料、接口超时后按固定策略重试这些路径虽然在运行时才被选中但候选路径和判断规则是预先定义的。Workflow 的价值不是“没有变化”而是变化被显式建模。你可以在上线前看到所有关键路径知道哪一步会写数据在哪些位置暂停失败后从哪里恢复也能针对每个节点编写测试和服务等级目标。它特别适合合规审批、订单履约、客户开户、内容发布和数据处理等业务步骤可能很多异常也不少但组织希望关键顺序、权限和责任边界保持稳定。三、Agent 的核心是一条带状态和停止条件的模型决策循环Agent 不是“能聊天的模型”也不是“调用过工具的模型”。一个工程上可用的 Agent 至少要有目标、当前状态、模型、工具集合、观察结果、执行循环和停止条件。循环通常可以概括为读取目标和状态模型判断下一步提出行动或工具调用运行时校验并执行观察结果再更新状态并继续。模型可能在每轮改变原计划也可能发现信息不足而追问用户。真正决定它是否是 Agent 的不是循环写成while而是模型是否在循环里拥有有意义的路径选择权。如果程序固定执行“检索一次—生成一次—结束”它仍是 Workflow如果模型可以在多个工具与子任务之间动态选择、根据结果调整步骤并自行判断任务是否完成它才更接近 Agent。Agent 也不等于无限自治。生产运行时仍应限制最大轮数、时间、预算、工具范围、数据权限和可接受的最终输出。高风险动作需要人工批准连续失败、目标不清或超出能力时应停止而不是继续消耗资源。四、Workflow 与 Agent 更像一条控制权连续谱不是非黑即白真实系统很少处在两个极端。一端是完全确定性的代码和规则另一端是模型围绕开放目标动态规划与调用工具。中间可以逐步加入 LLM 分类、语义判断、局部 Agent 和子 Agent。例如用 LLM 把报销描述抽取成结构化字段下一步仍由代码决定这是Workflow LLM。让模型只能在“补材料、转人工、进入审核”三个显式分支中选择仍然是强约束 Workflow。让一个局部 Agent 自主搜集证据、比较多份制度并解释冲突再把结论交回固定审批流则是Workflow 局部 Agent。“Agentic Workflow”通常用来描述这些混合系统或更广义的智能编排并不是一个统一标准定义的独立模型类别。讨论方案时最好不要只贴这个标签而要具体写清哪些节点由模型决定哪些边由代码控制哪些动作需要人工外层是否持久化。控制权越向模型侧移动系统通常越能处理开放和模糊任务但路径波动、评估难度、成本和风险也会上升。正确目标不是把旋钮拧到最右而是把每一处控制权放给最合适的责任主体。五、同一个报销任务用 Workflow 会怎样执行对于制度明确、写入风险较高的报销流程可以把外层路径显式固定识别请求、验证身份、读取本人票据、检索有效制度、判断是否缺材料、生成草稿、等待确认、正式提交、记录审计。其中并不排斥 LLM。模型可以负责从自然语言抽取城市、金额和用途也可以基于检索证据生成合规说明但是否允许提交、金额阈值、票据归属、审批层级和写入顺序仍由规则与业务系统决定。这种设计的优势是关键路径可预测。用户拒绝确认时一定停止提交接口超时后一定先查幂等状态制度证据不足时一定进入补充或人工审核。团队可以计算每个节点成功率重放失败实例并证明高风险写入经过了审批。它的限制也很明确一旦出现大量未预见例外流程图会不断膨胀模糊材料可能需要人工来回判断跨多个知识源的调查路径不容易全部提前编码。六、同一个任务如果完全交给 Agent 会发生什么Agent 可以接收“完成这笔报销”的目标自主决定先查制度还是先找票据发现材料缺失后询问用户比较不同制度版本生成草稿再请求提交工具。面对不确定情况它比固定流程更容易调整调查顺序。但灵活性同时带来不确定性它可能选择不必要的工具、重复检索、遗漏关键证据、过早宣布完成或者在错误信息上继续规划。相同输入在模型或上下文变化后轨迹也可能不同。因此“让 Agent 完成报销”不能等于“给模型所有工具然后等待”。运行时仍要限制只读与写入能力服务端重新授权提交前冻结参数并审批设置最大轮数和预算检测重复调用并把最终成功定义为业务系统中的可验证状态。在这个案例中全自主 Agent 并不是默认优选。报销主流程已经明确而且涉及正式写入。Agent 更适合处理“制度冲突分析、缺失材料判断、异常原因调查”等局部开放问题而不是接管所有控制权。七、七个维度看清两种模式的真实取舍Workflow 与 Agent 没有抽象意义上的胜负。它们优化的是不同目标前者优先可预测、可恢复和可审计后者优先适应性、开放问题处理和动态工具选择。从控制权看Workflow 以代码和图为主Agent 以模型决策循环为主从路径看前者候选路线预先定义后者运行时形成从测试看前者更容易做节点与分支断言后者需要评估完整轨迹和结果分布。从成本和延迟看Workflow 通常更容易设定上限Agent 可能多轮调用模型和工具。Agent 并不天然更省人它只是把部分人工判断转成了模型判断同时新增评估、权限、观测和异常接管成本。从变化速度看Agent 对长尾输入更有弹性但固定规则改变时Workflow 的行为更容易准确更新。涉及财务、权限、对外发送和不可逆动作时即使使用 Agent也应让确定性策略保留最终控制权。八、四种常见组合覆盖大多数生产需求第一种是纯 Workflow节点都是代码、规则和人工适合确定性高、风险高、审计要求强的流程。第二种是Workflow LLM流程不变在分类、抽取、总结和生成节点中使用模型。第三种是Workflow 局部 Agent外层 Workflow 掌握阶段、审批和恢复Agent 只在某个边界内解决开放子任务。它通常是企业场景最实用的平衡点。第四种是Agent 子 Agent主 Agent 动态分解任务并调用专用 Agent适合研究、编码和复杂分析等路径难预测、结果可评估的任务。组合越靠后不代表技术越先进只代表把更多路径选择交给模型。若一个函数或简单流程能稳定解决问题就没有必要引入 Agent若一个局部 Agent 已能处理不确定性也不必立刻升级为多 Agent。对报销助手合理组合是固定 Workflow 管理身份、证据门槛、草稿、审批、提交和审计局部 Agent 负责查找多份制度、解释冲突和提出缺失材料清单最终业务规则和人工拥有写入决定权。九、一个系统里可以同时存在代码节点、LLM 节点、Agent 节点和人工节点混合架构不是把不同组件随意串起来而是按问题性质分配责任。格式校验、权限、金额阈值和状态检查交给代码自然语言分类、抽取和改写交给单次 LLM开放调查交给受约束 Agent价值判断和高风险批准交给人工。这里最重要的是接口契约。每个节点应声明输入、输出、错误类型和副作用Agent 节点不能直接修改外层关键状态而应返回证据、建议和结构化结果外层 Workflow 再验证结果并决定后续路径。这样做可以把模型的不确定性局部化。Agent 内部可以多轮探索但离开节点时必须满足明确出口条件例如提供带来源的制度结论、列出未解决冲突或者返回NEEDS_HUMAN_REVIEW。它不能只说“我觉得可以提交”。如果 Agent 节点失败外层流程仍知道该重试、降级、转人工还是停止。相反若让一个大 Agent 同时负责调查、授权、审批和写入任何一轮偏差都可能扩散到整个任务。十、人工介入不是一句“请确认”而是可暂停、可检查、可恢复的状态转换无论 Workflow 还是 Agent都可能需要 Human-in-the-loop人在回路。区别在于Workflow 常把人工节点放在显式位置Agent 可能在遇到高风险工具、信息不足或低置信度时动态请求人工。真正的人工介入需要持久化运行状态。系统暂停时保存当前阶段、关键参数、证据、待审批动作和版本人工可以批准、修改或拒绝恢复时验证身份、参数哈希和业务状态再从检查点继续。如果暂停期间订单、余额或制度发生变化系统不能盲目沿用旧计划。恢复节点应重新检查易变数据必要时撤销旧审批并要求再次确认。审批之前发生的副作用也必须幂等因为某些运行时会从节点边界重新执行。因此HITL 是运行时能力和业务协议不只是前端弹窗。没有 Checkpoint、审计和恢复语义的“确认按钮”无法支撑长时间等待或故障重启。十一、Workflow 关注步骤恢复Agent 还要控制轨迹失控两种模式都需要重试、超时、取消和幂等但关注点不同。Workflow 的失败通常可以定位到具体节点读取失败、审批超时、写入冲突。运行时从检查点恢复并按该节点策略重试或补偿。Agent 除了工具错误还可能出现轨迹层故障反复调用相似工具、在无证据时继续推断、计划漂移、上下文膨胀、迟迟不结束或错误判断完成。它需要最大轮数、模型调用预算、工具调用上限、重复检测、进度检查和明确退出原因。两者混合时恢复边界必须设计清楚。外层 Workflow 可以把一次 Agent 运行视为可观察节点保存输入、允许工具、轨迹摘要和结构化输出Agent 内部失败后可以有限重试超过阈值则返回外层转人工而不是无限自救。无论哪种模式写操作都不能依赖“重新跑一遍应该没事”。幂等键、业务状态查询和补偿仍由执行系统保证。十二、业务状态、Agent 上下文、长期记忆和知识库不是一回事系统一复杂最容易出现的问题之一是把所有信息都塞进聊天记录。Workflow State 保存任务当前的业务事实例如报销 ID、流程阶段、审批状态和幂等键Agent Context 保存本次决策需要的目标、观察和轨迹摘要。长期记忆保存经过选择的用户偏好或历史经验知识库则保存可检索、可更新和有来源的制度文档。它们生命周期、权限和可信度不同不应混为一个messages数组。关键业务状态必须结构化并由应用持有。模型可以读取必要字段但不能把自己生成的文字当作事实写回。Agent 上下文可以压缩但订单状态和审批结果不能因为上下文压缩而丢失制度知识更新也应走知识库版本流程而不是依赖模型记忆。把四类数据分开才能在暂停恢复、权限隔离、删除请求、审计和评估时知道每条信息来自哪里、由谁负责。十三、评估 Workflow 看路径契约评估 Agent 还要看完整轨迹Workflow 可以针对节点输入输出、分支覆盖、状态转移、超时和补偿编写确定性测试。核心问题是给定状态和事件流程是否进入允许的下一节点副作用是否恰好发生一次。Agent 评估则要覆盖目标完成、工具选择、参数质量、证据使用、路径效率、停止原因和安全策略。只看最后一句话是否正确会漏掉“先做了越权操作最后又给出正确回答”这类严重失败。生产评估应保留 Trace并建立正常任务、长尾任务和对抗任务集合。对同一任务多次运行观察成功率与方差注入工具超时、恶意结果、权限拒绝、缺失信息和用户取消确认 Agent 能停止或转人工。混合系统需要两套视角外层 Workflow 是否遵守业务契约局部 Agent 是否在授权范围内高质量完成子任务。最终还要用业务系统的真实状态验证任务是否完成而不是接受模型自行宣告成功。十四、框架名称不同但仍然要回到“谁控制下一步”LangGraph 可以同时构建 Workflow 和 Agent 图提供持久化、检查点、人工介入和长时运行能力LangChain 在更高层提供模型、工具与 Agent 循环。OpenAI Agents SDK 的 Runner 管理模型、工具、Guardrail、Handoff 和停止循环也支持由代码编排多个 Agent。Microsoft Agent Framework 同时提供 Agent、Harness 和显式图式 Workflow并强调可以在 Workflow 节点中放入 Agent。不同框架 API 会变化但底层问题一致状态在哪里节点和边由谁定义模型能选择哪些动作如何暂停恢复谁拥有最终副作用权限。因此不要因为使用了某个 “Agent Framework”就假设系统里的所有组件都是 Agent也不要因为用了图运行时就把图中的每个节点都叫 Workflow。框架是实现工具Workflow 与 Agent 是控制模式一个框架通常可以支持多种模式。选框架之前先画控制权图。否则很容易先学习 API再反过来把所有问题塞进框架默认抽象。十五、选型顺序先用代码再用 Workflow最后把必要部分交给 Agent第一问普通函数、规则或单次 LLM 能不能解决如果能就停在这里。第二问任务是否有多个已知步骤、审批、重试或长时间等待如果有使用 Workflow 显式管理状态和路径。第三问是否存在难以预先枚举的子任务且模型需要根据中间结果动态选择工具和步骤如果没有不需要 Agent如果有先把 Agent 限制在局部节点。只有当整个任务本身开放、成功标准可评估、错误可恢复且自治收益足够高时才考虑让 Agent 管理更大范围。对于企业报销助手最终建议不是二选一而是用代码处理身份、权限、金额、状态和幂等。用 Workflow 管理证据、草稿、审批、提交和恢复。用单次 LLM 处理抽取、分类和说明生成。用局部 Agent 处理制度冲突和异常调查。用人工决定高风险或价值判断无法自动化的动作。这套顺序把灵活性放在真正需要的地方也让不可逆操作保留确定性控制。成熟度判断Workflow LLM、外层 Workflow 局部 Agent、Checkpoint 和人工审批已经是生产常用模式全自主通用 Agent、多 Agent 自组织和模型自我修改流程仍应按场景谨慎采用。写在最后现在我更愿意把 Workflow 与 Agent 看成一张控制权分配图。Workflow 不是落后的固定脚本Agent 也不是更高级的 Workflow。它们分别擅长显式过程和开放决策可以组合也应该彼此约束。真正成熟的 AI 系统不是尽可能让模型决定一切而是能清楚回答这一时刻由代码、模型还是人工做决定这个决定依据什么失败后如何恢复谁对副作用负责学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】