为什么？
因为这两种回答都掉进了非黑即白的二选一陷阱。
先看纯工作流，他的致命缺陷就是太死板。工作流完全由预设的条件驱动，一旦用户说出一句复杂的提示词，比如“帮我查下周三下午北京到上海最便宜的航班，不要早班机，高铁时间差不多也行”，工作流可以就会当场卡死在分支判断里，无法处理这种模糊、动态且带有多重偏好的输入。
如果走向另一个极端，完全放权给自主 Agent，在真实业务里同样是灾难。订机票涉及查票、验价、锁座、扣款和出票等高确定性的流程。自主 Agent 依靠大模型自主规划，不仅耗时长、Token 消耗多，最致命的是偶发幻觉。一旦大模型理解出现偏差，未获授权就直接调用扣款接口订错票，或者算错退票改签的手续费，由此引发的资金损失和客服投诉没有任何企业能承受得起。
那真实业务里的大厂架构到底是怎么做的？
答案很简单。交互用 Agent，交易用工作流。
先说用 Agent 做意图识别和参数的智能抽取。
用户的提示词可能有歧义甚至前后不一致。Agent 依托大模型的语义理解和多轮记忆能力，能耐心地和用户沟通，完成意图分类，比如提取出准确的出发地、目的地、时间、舱位和乘机人的信息。遇到信息遗漏，Agent 还能主动追问；用户中途改口说“周三不行，换周四上午”，Agent 可以在上下文中平滑切换参数，直到所有必填信息校验完毕。
那聪明的你肯定想到了：参数收集齐全之后，该怎么处理？
一旦 Agent 将参数提取完整，系统控制权必须立即移交给状态机驱动的确定性工作流。民航订票有严格的时间窗口和状态转移规则，绝不能让大模型自由发挥。从并发查票、核验规则、生成预订记录并临时锁座，到超时自动解座与事务补偿，全部由严密的代码逻辑掌控。工作流具备绝对的幂等性与可审计性，从底层杜绝了重复扣款和订错座位的风险。
那聪明的你肯定又要问了：支付、退票、改签这种高敏感操作，到底由谁来触发？
关键节点必须有人机协同。
整套架构中，支付、退票、改签、扣款等不可逆的接口，必须封装成受限的 Tools。大模型不能拥有扣款的终审权。后台工作流完成临时锁座后，系统会主动挂起，弹出包含航班号、起降时刻、乘机人、总价与退改规则的结构化确认卡片。模型负责生成订单摘要，最终支付必须由用户显式点击或者生物识别完成二次授权。确认无误后，工作流才能调用支付网关进行扣款。
那好学的你肯定要问，GitHub上有没有优秀的开源项目可以照着学啊？
有，必须得有。
拥有 4.2 万星标的 LangGraph，是构建状态机 Agent 的标杆项目。它把线性流水线升级为状态图，原生支持 Checkpoint 机制，支付等敏感节点可主动暂停等待外部输入。
突破 15.7 万星标的 Dify，是应用最广的企业级可视化工作流编排平台。它支持在画布上将大模型、自定义代码、条件分支和第三方接口自由拖拽组合，并提供权限管理。
拥有 3.6 万星标的 LlamaIndex，其 Workflows 模块摒弃了可视化界面，采用了纯 Python 的事件驱动状态机设计，通过声明步骤和发出事件就能完成整个流程编排。
突破 6.1 万星标的 AutoGen，是微软主导的多 Agent 协作神器。其 0.4 版本全面拥抱 Actor 模型和事件驱动内核，支持让多个专业角色进行复杂协作，并内置了安全代码沙箱。
面试官如果追问：“如果用户在最后的确认扣款步骤突然反悔，要求临时更改目的地，系统该如何响应？”
告诉他，状态机会在检测到取消后立即触发安全中断，释放临时锁定的座位，并将控制权交回 Agent；Agent 会保留已提取的姓名、证件号等有效信息，仅对发生变动的目的地与时间重新发起确认，避免让用户从头再来一遍。
这道题你学会了吗？想解锁更多 Agent 面试题的源码级拆解，点赞关注，我是二哥，咱们下期见！