Agent 工作流工程化：从画布到可恢复系统
这篇不教你“拖几个节点”，而是把 AI 工作流当作一个会调用模型、工具、人工与业务系统的分布式程序来设计。面试官真正想听到的是：你如何把不确定的模型输出约束在可观测、可回放、可审批、可恢复的业务边界内。
一、先建立正确的工作流心智模型
一个生产 AI 工作流不是一张流程图，而是下列对象的组合：
触发器 -> 输入契约 -> 任务状态 -> 节点执行 -> 决策/路由 -> 外部副作用 -> 输出契约
| | |
版本/权限 事件/日志 审批/补偿- 触发器：HTTP、消息队列、定时器、表单、人工发起或上游系统事件。触发器必须带入调用方身份、租户、幂等键和追踪标识，而不是只传一句自然语言。
- 输入契约：用 JSON Schema、DTO 或事件模型描述必填字段、枚举、长度、数据等级和默认值。模型可以辅助理解，但不能替代输入校验。
- 任务状态：包括
run_id、当前节点、业务对象版本、模型与提示版本、已读工具结果、重试次数、预算、审批状态与最终结果。状态不是聊天记录的同义词。 - 节点执行：一个节点只负责一类可命名的工作，例如“解析发票”“检索制度”“调用 CRM”“生成草稿”“人工批准”。节点越单一，测试、重试和观测越清晰。
- 决策/路由：确定规则优先由程序执行；模型仅在语义分类、信息抽取、候选排序等不确定处给出受约束判断。路由输出应是枚举或结构化对象，而不是一段“我觉得应该去 A”。
- 外部副作用：写库、发邮件、下单、创建工单、更新权限都不可逆或难逆，必须拥有幂等键、授权快照、审计记录和补偿方案。
- 输出契约：把自然语言答案与业务动作分开。前者可有一定弹性；后者必须有字段、版本、状态码和可验证依据。
一句适合面试的总括：
我把工作流看成“有 LLM 节点的状态机”，不是“让 LLM 串几个 API”。模型负责受限的语义判断，状态机负责流程、权限、预算和副作用，系统记录每一次可重放的决策证据。
二、工作流、Agent、自动化三者如何分层
| 层次 | 控制流由谁决定 | 典型能力 | 最常见风险 | 生产策略 |
|---|---|---|---|---|
| 传统自动化 | 开发者/规则引擎 | 触发、ETL、同步、通知 | 配置漂移、重复执行 | 幂等、重试、死信、监控 |
| AI Workflow | 开发者预定义骨架，LLM 填语义空位 | 分类、抽取、RAG、草稿、受控工具 | 幻觉、格式漂移、成本 | Schema、gate、评测、回退 |
| Agent | LLM 根据观察动态选择下一步 | 探索、规划、工具循环、子任务委派 | 死循环、越权、不可预测 | 限步、预算、沙箱、人审、trace |
不要把“有一个 LLM 节点”误称为 Agent。报销审批、合同字段抽取、客服工单归类，流程、权限和结果字段本就能预先定义，通常应选 Workflow。代码排障、开放式调研、跨系统异常定位的路径依赖实时观察，才需要把局部任务交给 Agent。成熟系统常是混合结构：主干是确定性工作流，某一个“查找缺失证据”或“生成解决方案”节点才运行受预算约束的 Agent。
三、一个可上线工作流必须回答的十二个问题
1. 谁能启动，启动的是哪一版？
发布版本必须可定位到工作流定义、节点配置、Prompt、工具 Schema、模型路由、知识库索引版本。请求进来后将它们固化到 run_snapshot；线上后来修改画布，不能改变正在执行的任务。多租户场景还要记录主体、角色、部门和数据域。
2. 输入有没有被机器验证？
用户文字可自由，但真正进入业务节点的对象不能自由。例如“帮我给客户发报价”必须转换为 customer_id、quote_version、channel、currency、approval_required。解析失败就追问或转人工，不能以模型猜出的客户名继续写操作。
3. 每个节点能否单独重跑？
节点输入和输出应该是稳定的结构化记录。重跑“文档 OCR”不应重新创建工单；重跑“生成摘要”不应重新扣费。将纯计算、读取、写入拆开，是避免副作用扩大的一条朴素原则。
4. 失败后从哪里恢复？
要明确节点级重试、任务级重放、人工重新发起的边界。网络超时适合有限退避重试；无权限、参数无效不应盲目重试；模型输出不合格可以换模型、缩小任务或请求人工补充。恢复前先查询外部系统事实，不能只相信本地状态。
5. 写操作是否幂等且可补偿？
为每个业务动作生成稳定的 idempotency_key = tenant + business_id + action + version。执行器先检查该键是否成功，再决定跳过、继续或补偿。需要跨多个系统时使用 Saga：先预留/创建待提交对象，所有检查通过后再确认；失败走显式补偿，而不是假设数据库事务能覆盖第三方 API。
6. 哪些决策交给模型，哪些必须写死？
权限、金额阈值、字段校验、允许的工具、数据脱敏、审批链和最终提交必须由代码/策略引擎决定。模型可做意图识别、摘要、证据归纳、候选排序；但它的输出永远只是输入到下一道程序化 gate 的候选，不是授权凭证。
7. 预算如何封顶？
预算至少包含请求级 token/金额/轮数/墙钟时间、用户级配额、租户级日预算、工具级调用次数和并发数。预算状态也要进状态机：达到阈值时不是静默失败，而是选择缩短上下文、切小模型、返回部分结果、异步化或转人工。
8. 人工审批能否安全恢复？
审批不是在聊天框里回答“确认”就够了。审批卡片要展示动作摘要、参数差异、证据、风险、当前授权人和过期时间；审批结果带签名、审批版本和授权快照。恢复时重新校验权限、对象版本和幂等键，防止“批准了旧报价却发出新报价”。
9. 如何观测一次运行？
至少贯穿 trace_id -> run_id -> node_attempt_id -> tool_call_id -> business_action_id。每个节点采集开始/结束时间、输入输出摘要、模型/Prompt 版本、token、检索文档、工具参数摘要、错误分类、重试与人工决定。敏感正文应脱敏、加密或只存引用。
10. 如何评测与发布？
把节点分成确定性和生成性两类。确定性节点跑单测、契约测试、集成测试；生成节点跑黄金集、结构合法率、引用正确率、任务成功率和安全拒答集。发布时做离线门禁、灰度、在线告警和可快速回滚，而不是让运营直接编辑生产画布。
11. 如何控制数据与凭证？
工作流实例不应把第三方 Token 当变量传来传去。凭证进入 Secret Manager 或平台凭证库，由短期委托令牌/工作负载身份按节点领取。日志只记录凭证引用和授权范围；导出工作流定义时绝不连同明文密钥导出。
12. 谁能解释一次争议结果？
争议发生时，要能给出输入版本、决策节点、检索证据、模型/提示/工具版本、审批记录和外部副作用的业务回执。若不能复现，至少能说明哪些部分不可复现以及为什么。这是审计可用性，不是“存了几条日志”。
四、节点设计：从“能跑”到“可维护”
推荐一个节点契约：
type NodeResult<T> =
| { kind: 'ok'; data: T; evidence?: EvidenceRef[] }
| { kind: 'retryable_error'; code: string; retry_after_ms?: number }
| { kind: 'business_reject'; code: string; detail: string }
| { kind: 'needs_approval'; proposal: ProposalRef }
| { kind: 'fallback'; reason: string; next: 'human' | 'manual_queue' }它带来三个好处：第一，LLM 节点也必须落到结构化结果；第二，路由规则能按 kind 编写，不依赖解析自然语言报错；第三，指标可按失败类型聚合。不要让节点吞掉异常后返回“处理失败，请重试”，那会让编排器失去做正确恢复的机会。
节点粒度也不是越细越好。太粗，重试会重复昂贵或有副作用的步骤；太细，状态持久化和调用开销变高，图也难读。实务上按以下边界切：一个授权边界、一个外部副作用、一类可独立重试的失败、一个可度量的质量目标。例如“查询客户”和“更新客户标签”应分开，因为前者只读、后者需要审批和幂等。
五、低代码与代码化编排如何共存
低代码平台有价值：业务专家能够维护提示、知识库、表单、轻量路由和通知；Dify 以应用画布和节点编排模型、知识和工具，n8n 以大量系统连接器和事件自动化见长，Coze 适合快速构建与发布面向业务的 Agent/工作流体验。平台优势并不等于把关键业务控制面交给画布。
一个实用的分层是：
业务入口 / 运营配置
-> 低代码工作流：表单、FAQ、轻量草稿、通知、人工协作
-> Tool Gateway：统一鉴权、限流、Schema、审计、幂等
-> 代码化编排：长事务、复杂状态、补偿、批处理、强测试
-> 领域服务：CRM、订单、合同、知识库、权限、财务不要把“从 Dify/n8n 迁移到代码”描述成平台失败。正确做法是：PoC 用平台确认场景、Prompt、数据源和用户价值；把稳定的工作流定义、坏例、工具契约沉淀成资产；当出现复杂状态、强权限、高 SLA、长运行或跨系统事务时，把关键路径毕业到代码运行时。平台可继续承担运营配置、内部助手或非关键流程。
六、2026 面试应能说出的工作流趋势
截至本文整理时，平台的界限正在从“能否接模型”转向“能否安全运行真实业务”。不押注某个厂商的单一版本，可以把变化概括为六条能力趋势：
- 耐久执行成为默认要求：任务可以跨进程重启、等待人工或长时间工具调用；运行时需要 checkpoint、重放与幂等副作用，而不是仅保存聊天历史。LangGraph 官方将 durable execution、持久化和人机协作作为图运行时的核心能力；Temporal 的 Workflow Execution 则把长运行协调与执行历史放在工作流语义中心。
- 人审从“末尾确认”前移为运行时原语：在高风险工具调用前暂停，带结构化提案恢复；不是让模型自己说“我已征得同意”。
- 工具互联进入治理阶段：MCP、HTTP、SaaS 连接器的数量增长后，重点变成身份、能力声明、最小权限、参数验证、审计和撤权，而非再加一个工具。
- 低代码与代码协同，而非二选一：可视化画布负责业务可见性，代码运行时负责复杂状态、测试与发布；两者通过稳定事件和 Tool Gateway 接口连接。
- 评测进入工作流版本生命周期：评测对象从最终回答扩展到路由是否正确、工具是否安全、人工接管是否及时、恢复是否重复执行。
- 模型输出被当成不可信数据处理：结构化输出、Schema 验证、证据与策略 gate 取代“靠更长 Prompt 约束一切”。
七、系统设计题：设计“企业异常工单处理工作流”
需求澄清
用户上传监控告警，系统要检索 Runbook、查询 CMDB/工单、给出处理建议；影响生产的变更必须由值班工程师批准；网络波动、人员离线和重复告警不能造成重复建单或越权变更。
参考架构
Alert API -> 去重/鉴权 -> Run 创建器 -> 解析与分类(LLM)
|-> 规则路由 -> RAG Runbook
|-> 只读 CMDB / 指标工具
|-> 方案草稿 + 风险校验
|-> Human Approval
|-> 变更 Tool Gateway -> ITSM
-> 事件/Trace/评测/审计关键设计回答
- 告警指纹 + 服务 + 时间窗口生成去重键；重复告警关联已有 run，不能反复创建工单。
- 输入和工具结果先做 Schema 校验；LLM 只输出分类、候选 Runbook、证据摘要和结构化建议。
- 工具分只读与写入；写入工具仅接受审批后的
action_token，网关同时校验操作人、对象版本、策略、幂等键。 - 任务状态保存在关系库/工作流存储，事件与 trace 送观测平台；敏感告警正文和凭证不进入普通日志。
- 网络失败走有限重试，超过阈值进入待处理队列；恢复前查询 ITSM 是否已创建，以外部业务回执为准。
- 灰度时仅让建议模式自动运行，写操作仍强制审批；用历史告警回放评测分类、检索、建议、审批命中和恢复正确率。
八、项目讲法模板
我们最初把流程理解为“告警进来后让模型给处理建议”，后来把它重构为带状态的工作流。入口先做租户、来源签名和告警去重；LLM 只做意图分类和 Runbook 证据归纳，CMDB 和监控查询都是只读工具。涉及创建变更单时，我们把提案、风险、差异和证据送给值班工程师审批，再由 Tool Gateway 用一次性授权与幂等键执行。每个 run 固化工作流、Prompt、模型、知识索引和工具版本，失败可从节点恢复，并用外部 ITSM 回执避免重复建单。上线后我们以人工接管率、工具成功率、重复副作用为零、P95 时延和单 run 成本来观测效果。
九、快速面试问答
Q：为什么不能让 LLM 直接决定所有分支？ 因为权限、金额、合规和业务状态必须可解释且可测试。模型适合给出语义候选；程序和策略负责将候选限制为允许动作。
Q：工作流重试和幂等是什么关系？ 重试解决暂时失败，幂等保证重复执行不会多做一次业务动作。只做重试会造成重复扣款、重复发信；只做幂等又无法处理临时网络错误，两者缺一不可。
Q：怎么衡量一个 AI 工作流是否上线成功？ 既看业务任务成功率、人工节省时间、处理时延，也看结构合法率、工具成功率、审批拒绝率、恢复成功率、越权/重复副作用为零、token 和外部调用成本。单看“用户觉得答案不错”不够。
Q：低代码工作流为什么也要 Git、评测和灰度？ 画布、Prompt、节点变量、模型参数和工具连接本质都是生产配置。没有版本与评测，就无法解释线上变化；没有灰度与回滚，一次运营编辑就可能影响全部用户。