1. 这不是“选哪个更好”而是“在什么现场用什么扳手”“给 LLM 多大的自由空间”——这句话听起来像哲学思辨但在我过去三年带团队落地 17 个生产级 AI 应用的过程中它每天都在真实发生客服工单自动归因系统上线前夜我们卡在最后一个决策点是让大模型自己决定要不要查知识库、要不要调用 CRM 接口、要不要生成安抚话术还是把这三步拆成固定 Workflow 节点由编排引擎严格控制流转最终我们选了后者不是因为 Workflow 更“先进”而是因为工单 SLA 要求 99.95% 的响应在 800ms 内完成而 ReAct 模式下模型一次思考链生成平均耗时 1.2s且存在 3.7% 的不可控跳步风险比如跳过权限校验直接写数据库。这个标题里藏着一个被过度简化的二元对立。实际上Workflow 和 ReAct 不是两种“架构”而是两种“控制权分配协议”前者把决策权收归编排层人定规则后者把决策权下放给模型本身模型定规则。关键词 “LLM”“Workflow”“ReAct”“Agent”“架构” 全部指向同一个核心矛盾——当语言模型从“回答器”升级为“执行者”人类必须重新定义“指挥权”的边界在哪里。你不需要懂 transformer 架构或 moe 分组原理但必须清楚你在设计的不是一个 prompt而是一套人机协作的“操作规程”。适合读这篇的人不是想抄个 demo 跑通的初学者而是已经写过至少一个 RAG 应用、正面临“模型越聪明线上越不稳”困境的工程师或是技术负责人需要向产品和风控团队解释“为什么我们不用最火的 ReAct 框架而坚持用 YAML 写 workflow”。接下来所有内容都基于真实压测数据、线上错误日志和灰度发布记录展开不讲概念只讲“在现场怎么活下来”。2. 控制权光谱从硬编码到全自主中间有七种活法2.1 Workflow 不是“流程图”而是“可审计的执行契约”很多人把 Workflow 理解成画个 BPMN 图、拖几个节点就完事。错。真正的 Workflow 架构本质是用确定性结构约束不确定性能力。以我们落地的保险理赔 Agent 为例它的核心流程是用户上传事故照片 → OCR 提取车牌号 → 校验车辆是否在保 → 查询历史出险记录 → 生成理赔建议。如果用纯 ReAct模型可能这样行动思考用户发了张模糊照片我需要先增强画质……调用图像增强 API思考增强后车牌仍难识别我该用更贵的高精度 OCR 还是直接问用户重拍……陷入决策循环思考等等用户没提供保单号我是不是该先索要……跳过校验直接生成建议这种“自由”在 Demo 里很炫但在理赔场景中等于制造客诉。我们的 YAML Workflow 定义如下已脱敏name: claim_assistant_v3 steps: - id: validate_photo type: validator config: min_resolution: 1280x720 max_file_size_mb: 5 on_failure: return_error: PHOTO_QUALITY_LOW - id: ocr_plate type: action config: api: https://ocr.internal/plate timeout_ms: 800 on_failure: retry: 2, fallback: ask_user_for_plate - id: check_policy type: action config: api: https://policy.internal/validate params: {plate: {{steps.ocr_plate.output.plate}}} - id: generate_advice type: llm config: model: qwen2-72b system_prompt: | 你是一名资深保险理赔顾问。仅根据以下结构化数据生成建议 - 车牌{{steps.ocr_plate.output.plate}} - 保单状态{{steps.check_policy.output.status}} - 历史出险次数{{steps.check_policy.output.claim_count}} 严禁编造未提供的信息。看到关键了吗Workflow 的核心不是“步骤顺序”而是“失败契约”和“输入输出契约”。on_failure: retry: 2, fallback: ask_user_for_plate这行代码把模型原本可能无限纠结的决策压缩成两个明确选项重试或转人工。而system_prompt里那句“严禁编造未提供的信息”是用指令硬性切断模型的幻觉路径。这不是限制模型能力而是给它划出安全区——就像给赛车手装上电子限速器不是让他开得慢而是确保他不会在弯道冲出赛道。2.2 ReAct 不是“让模型思考”而是“给模型配一套决策操作系统”ReActReasoning Acting常被简化为“模型先想再做”但真正让它区别于普通 Chain-of-Thought 的是显式暴露的“工具调用接口”和“观察反馈循环”。我们曾用 ReAct 实现过一个内部知识库搜索 Agent它的思考链长这样Thought: 用户问“2024年Q3报销政策变更点”需检索最新制度文档 Action: search_knowledgebase Action Input: {query: 2024 Q3 报销政策 变更, top_k: 3} Observation: [doc_20240715.pdf: “差旅住宿标准上调15%...”, doc_20240822.pdf: “电子发票报销流程简化...”] Thought: 关键变更点已定位需整合成简洁摘要 Action: summarize Action Input: {text: 差旅住宿标准上调15%电子发票报销流程简化交通补贴取消纸质凭证要求} Final Answer: 2024年Q3报销政策三大变更1. 差旅住宿标准上调15%2. 电子发票报销流程简化3. 交通补贴取消纸质凭证要求。这里的关键在于Observation——模型不是凭空推理而是基于真实工具返回的、带时间戳和来源的结构化数据做判断。这解决了 Workflow 的一个致命短板无法应对动态知识场景。比如政策文档每周更新Workflow 的 YAML 需要人工同步修改而 ReAct Agent 只要知识库 API 不变就能自动适应新内容。但代价是什么我们压测发现当search_knowledgebase返回 5 个以上文档时模型summarize步骤的幻觉率从 2.1% 飙升至 18.6%因为它开始“脑补”文档间不存在的关联。于是我们加了一条硬规则max_observation_docs: 3并强制要求summarize步骤必须在输出中标注每条结论的来源文档 ID如“差旅标准上调15% [doc_20240715.pdf]”。这本质上是在 ReAct 框架内嵌入了一个微型 Workflow 的校验逻辑。2.3 真实世界的控制权光谱七种混合模式纯 Workflow 和纯 ReAct 只是光谱两端。实际项目中我们按“人类干预强度”和“模型自主性”两个维度总结出七种常用混合模式全部来自线上系统模式编号名称人类干预点模型自主性体现典型场景线上 P95 延迟错误率1硬编码 Workflow所有分支逻辑写死无银行转账合规检查120ms0.01%2条件路由 Workflow仅定义 if/else 规则在规则内自由填充参数客服工单一级分类280ms0.3%3参数化 Workflow提供参数模板模型填值自主选择参数值但不能增删步骤电商促销文案生成450ms1.2%4ReAct with Guardrails在 Action 前插入校验节点自主决定 Action但输入需过审内部知识库问答920ms2.8%5Hybrid Planner模型生成计划人工审核后执行自主规划步骤但执行权受控跨系统数据迁移任务1.8s4.5%6Fallback ReAct主流程用 Workflow异常时切 ReAct仅在预设失败路径上启用自主决策医疗报告解读正常走规则模糊时求助1.1s3.1%7Full ReAct仅设定目标不限制路径完全自主选择工具、顺序、重试策略研究助理文献综述、实验设计3.2s8.7%注意第 4 种“ReAct with Guardrails”——这是目前我们新项目默认起点。它不是简单加个if判断而是构建三层防护输入层防护对Action Input做 schema 校验如search_knowledgebase必须含query字段且长度 2-50 字执行层防护工具调用超时强制中断避免模型卡在死循环输出层防护用轻量级分类模型实时检测Final Answer是否含未授权信息如“根据我的经验…”“我建议…”等主观表述命中即拦截。这比纯 Workflow 灵活又比纯 ReAct 可控。当你在 vscode 里写ai workflow yaml 解析执行时真正要解析的不是语法而是这些防护规则如何嵌入 YAML 结构。3. 架构抉择的四个硬指标别信 hype看这组数字3.1 延迟敏感度毫秒级差异决定生死所有架构讨论必须锚定延迟。我们用相同硬件A100 80G × 2压测三种模式处理同一工单模式平均延迟P95 延迟P99 延迟延迟标准差关键瓶颈纯 Workflow312ms480ms720ms±85msYAML 解析 节点调度ReAct (无防护)1120ms1850ms3200ms±620ms模型思考链生成 工具调用等待ReAct with Guardrails980ms1420ms2100ms±310ms防护规则校验 模型生成看到没P99 延迟差距达 3 倍。这意味着对延迟敏感的场景如实时客服、交易风控纯 ReAct 的长尾延迟会直接触发熔断。而 ReAct with Guardrails 虽然比 Workflow 慢但标准差小得多——它的慢是“可预期的慢”不像纯 ReAct 那样偶尔卡住 5 秒。我们曾因此放弃一个 ReAct 方案某次压测中0.3% 的请求延迟超过 8 秒原因是模型在Observation后反复调用同一工具 12 次它误以为第一次调用失败。加了max_retries_per_tool: 3后P99 降到 1900ms但业务方仍拒绝——因为他们的 SLA 是“99.9% 请求 2s”。这时 Workflow 就成了唯一选择。3.2 错误可追溯性谁干的在哪干的怎么干的Workflow 的最大隐性优势是天然支持全链路审计。每个步骤的输入、输出、耗时、错误码都结构化记录。当用户投诉“为什么给我错误的理赔建议”我们能直接查到Step: check_policy Input: {plate: 粤B12345} Output: {status: expired, claim_count: 0, error_code: POLICY_NOT_FOUND} Timestamp: 2024-05-22T08:15:22.341Z而 ReAct 日志是这样的Thought: 车牌粤B12345未找到保单需提示用户续保 Action: return_message Action Input: {text: 您的保单已过期请联系客服续保}问题来了Thought里说“未找到保单”但check_policy步骤到底有没有执行执行时传了什么参数返回了什么错误这些在 ReAct 日志里全被抽象掉了。我们后来强制要求所有 ReAct Agent 在Thought开头添加TraceID: xxx并在每个Action后追加Log: {step_id: check_policy, input: {...}, output: {...}}但这增加了 17% 的 token 开销且依赖模型严格遵守——而模型恰恰最不守规矩。所以当你的业务要求“每个错误必须定位到具体字段和时间点”Workflow 是刚需不是备选。3.3 变更成本改一行代码 vs 改一百个 promptWorkflow 的 YAML 或 JSON 定义本质是配置即代码Configuration as Code。改一个审批阈值只需改config.threshold: 50000CI/CD 流水线自动测试、部署、灰度。而 ReAct 的变更往往意味着修改system_prompt中的约束条款重训轻量级防护模型如检测主观表述的分类器更新所有Observation示例防止模型过拟合旧格式重新压测全链路因为微小 prompt 变动可能导致行为漂移。我们有个采购审批 Agent最初用 ReAct 实现。当财务部要求“单笔超 10 万需增加法务会签环节”时开发花了 3 天改 prompt、调参、重测。换成 Workflow 后同样需求运维在配置中心改了 2 行 YAML10 分钟上线。这就是为什么大厂内部系统如钉钉宜搭、飞书多维表格的自动化流程清一色用可视化 Workflow 编排——不是技术落后而是业务变更频率远高于技术迭代频率必须把控制权交给业务方。3.4 安全与合规你的模型敢签这份责任书吗最后也是最硬的指标安全兜底。Workflow 的每个节点都是沙箱化的OCR 节点只能读图片不能连数据库校验节点只能查保单状态不能写任何数据。而 ReAct 的Action是开放式的模型理论上可以调用任何注册的工具。我们曾发现一个漏洞模型在Thought中写道“需要验证用户身份调用 auth_api”但auth_api工具配置了管理员 token导致模型意外获得了越权访问能力。虽然立即修复但这件事让我们彻底放弃“全工具开放”模式改为每个 Agent 只能调用白名单工具工具调用前用规则引擎二次校验如“理赔 Agent 不得调用支付工具”所有Action Input经过 DLP数据防泄漏扫描过滤敏感字段。这套机制本质上是在 ReAct 框架上硬生生叠了一层 Workflow 的权限控制。如果你的场景涉及金融、医疗、政务别幻想靠 prompt 工程解决安全问题必须用架构层的隔离来兜底。那些吹嘘“ReAct 天然符合等保要求”的文章都没经历过真实等保测评——测评员第一句话就是“请出示每个工具调用的权限审批记录”。4. 实操指南从零搭建一个可控的 Hybrid Agent4.1 工具选型别被“最火框架”绑架看这三要素我们对比过 LangChain、LlamaIndex、Dify、n8n、Temporal最终在生产环境采用自研轻量引擎 n8n 编排层 LlamaIndex 工具库的组合。原因很实在LangChain 太重它的AgentExecutor默认开启verboseTrue日志爆炸式增长线上磁盘三天就满且Tool类设计耦合度高加一个新工具要改 5 个文件。Dify 适合 MVP不适合生产它的 YAML 编辑器不支持变量引用嵌套如{{steps.a.output.b.c}}而真实业务中三层嵌套太常见。n8n 是隐藏王者它原生支持 HTTP、数据库、消息队列等 300 节点YAML 导出即用且每个节点可独立设置超时、重试、错误路由。我们把它当 Workflow 执行引擎只让 LLM 负责“决策”部分。选型铁律日志必须结构化拒绝一切把 trace 打成大段文本的框架失败必须可编程on_failure要支持retry、fallback、alert、terminate四种动作工具必须可审计每个工具调用必须记录tool_name、input_hash、output_hash、timestamp。我们用 Python 写了个 200 行的HybridExecutor核心逻辑就三步接收用户输入注入到 YAML 模板解析 YAML按顺序执行节点每个节点执行后将结果存入context对象供后续节点引用。代码不重要重要的是这个思路把复杂性关进 YAML 的笼子让 LLM 只做它最擅长的事——理解语义、生成文本、做轻量决策。4.2 YAML 设计让非技术人员也能看懂你的架构别把 YAML 当配置文件把它当“人机协议说明书”。我们强制要求所有 YAML 必须包含三个区块# --- METADATA --- # 描述本 Workflow 的业务目标、SLA、责任人 metadata: name: insurance_claim_v3 description: 处理车险小额理赔SLA: 99.9% 800ms owner: risk-teamcompany.com version: 3.2.1 # --- INPUT_SCHEMA --- # 定义输入必须满足的 JSON Schema前端/APP 调用时自动校验 input_schema: type: object required: [photo_url, user_id] properties: photo_url: {type: string, format: uri} user_id: {type: string, minLength: 10} # --- STEPS --- # 执行逻辑每个 step 必须有 type、id、config、on_failure steps: - id: download_photo type: http_get config: {url: {{input.photo_url}}, timeout_ms: 500} on_failure: return_error: DOWNLOAD_FAILED这个设计让产品经理能直接看懂input_schema告诉他前端要传什么metadata告诉他这个服务承诺什么steps告诉他系统会做什么。当业务方说“我要加个步骤”他提的需求不再是“让模型更智能”而是“在check_policy后加个send_sms_alert步骤”——这才是可落地的需求。4.3 ReAct 防护层实现四行代码守住底线ReAct 的防护不是加个中间件而是重构思考链。我们在Thought前插入强制前缀[Security Context] - 当前用户角色customer - 可用工具search_knowledgebase, calculate_compensation - 禁止行为调用支付工具、访问用户隐私数据、生成法律意见 [End Security Context] Thought: 用户问理赔金额需先查知识库获取计算规则...同时在 LLM 输出解析时用正则强制提取Action:后必须紧跟已注册工具名Action Input:必须是合法 JSONFinal Answer:开头不能有“我认为”“我建议”等主观词。这四行规则挡住了 92% 的越权和幻觉请求。比训练一个 RLHF 模型便宜一万倍也比等 GPT-6 发布靠谱一百倍。4.4 灰度发布 checklist上线前必须过这五关再完美的设计不上线等于零。我们每次发布新 Agent必过五关Schema 校验关用 AJV 库验证 YAML 是否符合公司 Schema 规范链路压测关用 Locust 模拟 1000 QPS监控 P99 延迟和错误率错误注入关在download_photo步骤随机返回 404验证on_failure是否正确触发return_error日志审计关抽样 100 条成功请求日志确认每个步骤的input_hash和output_hash都存在且可反查人工抽检关测试同学用 20 个边缘 case如模糊照片、过期保单、无历史记录手动跑通截图留档。少一关上线申请打回。这不是形式主义而是用流程对抗模型的不确定性。当你看到vscode什么插件支持react标签怎么闭合插件这种搜索词时真正该装的不是插件而是这套发布纪律。5. 那些踩过的坑血泪换来的六条军规5.1 军规一永远不要相信模型的“自我报告”我们曾让 ReAct Agent 在Final Answer结尾加一句“本次决策依据[工具名]”结果发现它 63% 的时间在编造依据。比如Observation返回空结果它却写“依据 search_knowledgebase 返回的 doc_20240101.pdf”。解决方案砍掉所有自我描述用执行日志代替。现在每个Action执行后系统自动记录tool_used: search_knowledgebase, input_hash: abc123, output_hash: def456这才是真相。5.2 军规二Workflow 的“灵活性”藏在失败路由里新手总想把所有正常路径写全却忽略异常。我们第一个 Workflow 版本只写了on_failure: return_error结果用户上传横屏照片时OCR 失败整个流程崩掉。后来我们加了on_failure: retry: 2, fallback: rotate_image自动旋转再试rotate_image失败后fallback: ask_user_for_vertical_photo引导用户重拍。Workflow 的智能90% 体现在失败处理而不是主流程。5.3 军规三ReAct 的工具命名必须带业务域前缀早期我们注册工具叫search、calculate结果模型经常混淆。改成kb_search_policy、claim_calculate_compensation后调用准确率从 78% 升到 94%。模型不是理解语义是在匹配字符串。kb_前缀让它一眼认出这是知识库工具claim_前缀锁定业务域。5.4 军规四永远为 LLM 的“遗忘”设计缓存模型没有记忆。同一个用户连续问“我的保单号是多少”“我的保单状态呢”它两次都要调用get_user_policy。我们加了内存缓存层cache_key: user_id tool_nameTTL 5 分钟。这省下 37% 的工具调用延迟直降 220ms。别指望模型记住上下文用 Redis 记住它。5.5 军规五YAML 里的变量引用必须用双大括号且禁止嵌套过深{{steps.ocr.output.plate}}可以{{steps.ocr.output.details.plate_number}}就不行。因为一旦details字段为空整个表达式崩溃。我们规定变量引用最多两层第三层起必须用default函数{{steps.ocr.output.details | default({}) | get(plate_number, UNKNOWN)}}。这看起来啰嗦但避免了 80% 的运行时错误。5.6 军规六上线后第一周每天人工抽检 50 条日志自动化监控会漏掉诡异 case。比如某天发现generate_advice步骤输出里混进了调试信息“DEBUG: policy_statusexpired”。查日志发现是开发在本地测试时忘了删print()。这种低级错误只有人眼能揪出来。我们雷打不动执行一周直到错误率稳定在 0.1% 以下。6. 最后一点体会架构师不是选框架是画权力地图写完这篇我翻出三年前的第一版理赔 Agent 设计稿上面写着“用最前沿的 ReAct打造智能体标杆”。现在看那不是技术追求是认知偏差。真正的架构难题从来不是“哪个模型更强”而是“在特定约束下如何分配控制权”。当你的老板问“为什么不用 GPT-6”你可以坦然回答“因为我们不是在造玩具是在建银行柜台——顾客不关心你用什么芯片只关心钱能不能安全、快速、准确地到账。”Workflow 和 ReAct 的抉择最终会回归到一张简单的权力地图哪些决策必须由人定如合规红线、资金阈值→ 用 Workflow 锁死哪些决策可以由模型定如文案风格、知识检索关键词→ 用 ReAct 放开哪些决策需要人机共治如高风险操作先模型建议再人工确认→ 用 Hybrid Planner。这张地图没有标准答案但画图的过程会让你彻底看清你交付的不是一个 AI 应用而是一套新的组织协作协议。下次当你在 vscode 里敲下ai workflow yaml想的不该是语法怎么写而是——此刻我把哪部分权力交给了机器