Agentic Workflow

Agentic workflow 的核心不是让大模型“自由发挥”而是让模型在明确目标、工具边界、状态管理和安全约束下参与并驱动一段可验证的业务流程。摘要过去几年很多团队对大模型应用的理解经历了三个阶段先是单轮问答然后是 RAG再到可以调用工具、执行多步任务的 agentic system。但在真实工程里最容易被误解的恰恰是 agentic workflow它既不是传统工作流引擎换了个名字也不是把所有决策都交给大模型。一个可上线的 agentic workflow应该同时具备四类能力能理解任务目标并将目标拆成可执行步骤能在合适的时机调用工具而不是只生成文本能保存状态、恢复执行并处理失败和重试能通过 guardrails、人审和权限控制限制风险本文会从概念边界、架构模式、系统设计、代码结构和生产治理几个角度系统梳理 agentic workflow 的完整设计方法。1. 什么是 agentic workflowOpenAI 在构建 agents 的实践指南中把 workflow 描述为一组为了完成用户目标而必须执行的步骤例如处理客服问题、预订餐厅、提交代码变更或生成报告。Agent 则是在这些步骤上具备更高独立性的系统它可以基于上下文判断下一步动态选择工具并在失败时修正或把控制权交还给用户。Anthropic 对 workflows 和 agents 做了一个很有工程价值的区分WorkflowLLM 和工具按照预定义代码路径被编排AgentLLM 在运行时动态决定流程和工具使用方式这个区分非常关键。如果所有步骤都能被规则清晰描述传统 workflow 就足够如果任务中存在大量模糊判断、异常分支、非结构化输入和工具选择才需要引入 agentic workflow。换句话说agentic workflow 不是“更高级的自动化”而是“在确定性流程中嵌入模型驱动的决策能力”。2. 为什么普通自动化不够用传统自动化适合规则明确的场景如果 A 条件成立 - 执行 B 如果 B 成功 - 执行 C 如果失败 - 报错这类流程稳定、可预测、成本低。问题在于很多真实业务并不长这样。例如一个售后退款场景用户描述可能不完整订单状态可能复杂政策规则可能存在例外客户情绪可能影响处理优先级是否退款可能需要结合历史行为、商品类型和风控信号如果用传统规则引擎实现需要维护大量 if-else、规则表和兜底逻辑。规则越写越多系统越难改。agentic workflow 的价值就在这里它可以把非结构化输入转成结构化判断把模糊问题拆成明确步骤再通过工具访问业务系统最终完成一段端到端流程。3. agentic workflow 的基本组成一个完整的 agentic workflow通常由六个部分构成。3.1 Model模型负责理解任务、推理下一步、生成结构化输出或选择工具。在工程设计中模型不是孤立存在的“大脑”而是运行在一套受控流程里的决策组件。不同任务对模型要求不同简单分类低成本模型即可多步推理需要更强推理能力代码修改需要更长上下文和工具调用能力高风险业务需要更严格的输出校验和人审3.2 InstructionsInstructions 是 agent 的行为规范。它应该描述任务目标可用工具工具使用规则输出格式异常分支禁止行为何时交给人工OpenAI 的实践指南强调高质量 instructions 对 agent 尤其关键因为它直接影响模型的决策质量和流程稳定性。3.3 ToolsTools 是 agent 和真实系统交互的接口。常见工具类型包括Data tools查询订单、读取文档、搜索知识库、获取用户信息Action tools创建工单、发送邮件、更新数据库、触发审批流Execution tools运行代码、修改文件、调用 CLI、执行测试工具设计要遵循一个原则接口要清晰、参数要结构化、权限要最小化。不要给 agent 一个“万能执行器”然后期待它永远做正确的事。工具越宽风险越大工具越明确可控性越强。3.4 MemoryMemory 用来保存任务上下文和长期偏好。它可以分为几类会话记忆当前任务已经发生了什么工作记忆当前计划、步骤、工具结果长期记忆用户偏好、项目规范、历史决策外部状态数据库、文档、工单系统里的事实需要注意的是memory 不能替代数据库。重要事实必须落到可靠存储中并有明确的数据来源和更新时间。3.5 OrchestrationOrchestration 决定 agent 如何执行 workflow。常见方式有三种单 agent 循环执行manager agent 调用多个 specialized agents多 agent 之间 handoffOpenAI Agents SDK 文档中也把 manager pattern 和 handoffs 作为多 agent 协作的两类典型方式。前者由中心 agent 控制流程后者允许专业 agent 接管对话或任务。3.6 GuardrailsGuardrails 是 agentic workflow 的安全边界。它可以发生在多个位置输入前判断用户请求是否越界工具调用前判断动作是否高风险工具调用后检查结果是否异常输出前检查是否泄露敏感信息或违反格式OpenAI Agents SDK 的 guardrails 文档明确区分了 input guardrails、output guardrails 和 tool guardrails。这个分类很实用因为真实系统里的风险往往不是只出现在最终回答而是出现在每一次工具调用上。4. 最常见的四种架构模式4.1 Prompt Tool Loop这是最基础的 agentic workflow。用户输入 - 模型理解任务 - 选择工具 - 执行工具 - 读取结果 - 判断是否继续 - 输出最终结果适合场景查询类助手简单数据分析文档检索与总结单系统内的自动操作优点是简单缺点是复杂任务容易失控。当工具数量增加、分支变多、状态变复杂时需要更明确的 orchestration。4.2 Plan-and-Execute这种模式先生成计划再逐步执行。目标 - 生成计划 - 校验计划 - 分步执行 - 每步记录状态 - 汇总结果适合场景代码修改数据迁移多文档分析复杂报告生成多系统协同任务关键点是计划必须可中断、可修改、可回放。否则计划只是模型的一段文本不是真正的 workflow。4.3 Manager Specialist Agents这种模式由一个 manager agent 负责任务分解和结果整合多个 specialist agents 负责具体能力。Manager Agent - Search Agent - Code Agent - Review Agent - Report Agent适合场景工程研发助手企业知识助手客服综合处理法务或财务多步骤审查优点是职责清晰缺点是成本和复杂度更高。如果一个单 agent 加工具就能解决问题不要过早拆成多 agent。4.4 Human-in-the-LoopHuman-in-the-loop 是生产环境中非常重要的模式。LangChain / LangGraph 的文档强调人审机制可以让 workflow 在关键工具调用前暂停等待人工批准、编辑或拒绝然后从保存的状态继续执行。适合触发人审的动作包括删除数据执行 SQL 写操作发送对外消息发起支付取消订单修改生产配置合并代码在高风险场景里人审不是降低效率而是让 agent 能进入真实业务系统的前提。5. 一个生产级 agentic workflow 应该怎么设计以“自动处理客户退款请求”为例一个可上线的 workflow 不应该只写成帮用户处理退款。而应该拆成明确的业务流程1. 识别用户意图 2. 检查用户是否提供订单号 3. 如果缺少订单号向用户询问 4. 查询订单状态 5. 查询退款政策 6. 判断是否满足自动退款条件 7. 如果满足生成退款申请 8. 如果金额超过阈值提交人工审批 9. 如果不满足解释原因并给出替代方案 10. 记录处理结果这里面只有部分步骤适合交给模型判断例如识别意图、解释政策、组织回复。而订单查询、金额判断、退款提交、审批触发都应该通过受控工具完成。一个更合理的架构是User - Intent Classifier - Refund Workflow Agent - Policy Retrieval Tool - Order Query Tool - Risk Check Tool - Refund Action Tool - Human Approval - Audit Log注意这里的重点不是“agent 有多聪明”而是每一步都有清晰边界。6. 工具设计agentic workflow 的成败关键工具是 agentic workflow 里最容易被低估的一层。如果工具设计不清楚模型会在错误的抽象层上做决策。6.1 工具应该表达业务动作不要这样设计execute_sql(sql: string)更好的设计是get_order(order_id: string) create_refund_request(order_id: string, reason: string) submit_manual_review(case_id: string, risk_reason: string)前者给了模型过大的自由度后者把行为限制在业务动作内。6.2 工具返回要结构化不推荐订单正常可以退款。推荐{order_id:O202607220001,status:DELIVERED,refund_eligible:true,max_refund_amount:89.90,requires_manual_review:false,reason:within_policy_window}结构化结果能降低模型误解也方便后续校验和审计。6.3 工具必须区分读写权限建议把工具分成三类read只读查询write_low_risk可逆或低影响写操作write_high_risk不可逆、高金额、对外发送、生产变更高风险工具调用必须经过 guardrails 或 human-in-the-loop。7. 状态管理不要让 workflow 只活在上下文窗口里很多 demo 可以只靠对话上下文运行但生产系统不行。一旦任务持续时间超过几分钟或者需要等待审批、重试、外部回调就必须有持久化状态。状态至少应该包括workflow_id当前步骤用户输入已调用工具工具返回结果中间决策待审批动作错误和重试次数最终输出一个简化的数据结构可以是{workflow_id:wf_20260722_001,status:WAITING_APPROVAL,current_step:submit_refund,input:{user_id:u_123,order_id:o_456},tool_results:[{tool:get_order,status:success}],pending_approval:{action:create_refund_request,amount:1299.00,reason:high_value_refund}}LangGraph 和 LangChain 相关文档反复强调 durable execution也就是 checkpoint、暂停、恢复和重试能力。这个能力不是锦上添花而是长任务 agentic workflow 的基础设施。8. 失败处理agentic workflow 必须默认会失败生产系统里agent 失败很正常。真正的问题不是失败本身而是失败后系统是否知道怎么办。常见失败类型包括模型误判意图工具调用失败外部系统超时返回数据冲突用户信息不足输出格式不符合 schema达到最大步骤数高风险操作被拦截对应的处理策略应该提前定义可重试错误指数退避重试不可重试错误直接进入失败状态信息不足向用户追问高风险动作等待人工审批工具异常降级或切换备用路径模型多次不稳定转人工或终止一个 agentic workflow 没有失败状态设计就像一个分布式系统没有超时设置。9. 评估体系不要只看“回答像不像”Agentic workflow 的评估不能只看最终文本质量。它至少要评估五类指标9.1 任务完成率用户目标是否真的完成而不是只生成了一个看似合理的回答。9.2 工具调用准确率模型是否选择了正确工具参数是否正确调用顺序是否合理。9.3 成本与延迟包括模型调用次数、token 成本、工具调用耗时、整体 workflow 耗时。9.4 安全性是否越权调用工具是否泄露敏感信息是否绕过审批。9.5 可恢复性中断、失败、部署重启后workflow 是否能恢复到正确状态。这些指标决定了 agentic workflow 能不能从 demo 走向生产。10. 工程落地建议10.1 先从单 agent 开始OpenAI 的实践指南建议通常应该先最大化单 agent 的能力只有当指令复杂、工具冲突或任务边界明显时再拆成多 agent。这是很务实的建议。多 agent 会带来更多上下文传递、调试成本、评估复杂度和延迟开销。10.2 把 SOP 转成 instructions不要凭空写 agent 指令。优先从已有材料开始客服话术操作手册风控规则审批流程运维 Runbook代码规范这些文档本来就是组织知识把它们转成清晰、编号化、可执行的 instructions通常比从零设计 prompt 更可靠。10.3 工具少而精不要一次性给 agent 太多相似工具。工具越多模型选择错误的概率越高。工具命名应该直接表达业务含义好query_customer_orders好submit_refund_review差call_api差execute_action10.4 高风险动作必须有审批以下动作不建议完全自动化资金变更删除数据批量发送消息修改生产配置执行不可逆操作访问高度敏感信息刚上线时可以先把这些动作全部放入人工审批。等评估数据足够稳定再逐步放宽自动化范围。10.5 让每一步可观测一个 production-ready workflow 至少要记录输入模型输出工具调用工具结果状态变化人工审批错误堆栈最终结果没有可观测性就无法做调试、审计、评估和迭代。11. 一个简化的代码骨架下面是一个抽象示例展示 agentic workflow 的基本控制循环classWorkflowState:def__init__(self,workflow_id,user_input):self.workflow_idworkflow_id self.user_inputuser_input self.stepstartself.history[]self.pending_approvalNoneself.statusrunningdefrun_workflow(state:WorkflowState):whilestate.statusrunning:decisionmodel_decide_next_step(state)ifdecision.typefinal_answer:state.statuscompletedreturndecision.outputifdecision.typeask_user:state.statuswaiting_userreturndecision.questionifdecision.typetool_call:toolresolve_tool(decision.tool_name)iftool.risk_levelhigh:state.pending_approvaldecision state.statuswaiting_approvalpersist_state(state)returnwaiting for approvalresulttool.execute(decision.arguments)state.history.append({tool:decision.tool_name,arguments:decision.arguments,result:result})persist_state(state)iflen(state.history)20:state.statusfailedreturnworkflow exceeded max steps真实系统会复杂得多但核心思路不变模型负责决策工具负责执行状态负责恢复审批负责风险控制观测负责持续改进12. 常见反模式12.1 把 agent 当成万能接口给 agent 一个自由文本输入再给它一堆高权限工具这是非常危险的设计。agent 应该运行在业务边界里而不是越过业务系统的权限模型。12.2 没有退出条件每个 agentic workflow 都应该有明确退出条件完成任务用户取消达到最大轮次工具连续失败触发安全策略等待人工处理没有退出条件就容易出现循环调用、成本失控和状态污染。12.3 只做 prompt不做系统设计Prompt 很重要但它不是全部。生产级 agentic workflow 还需要schemaqueuestate storepermission modelaudit logeval setobservabilitydeployment strategy只靠 prompt 无法支撑复杂业务。12.4 过早多 agent 化多 agent 架构看起来优雅但不一定更可靠。如果任务边界不清晰多 agent 只会把问题拆散让调试更困难。13. 总结agentic workflow 的本质是把大模型从“文本生成器”放进一套可控的业务执行系统里。它不是完全自治也不是传统流程自动化。它更像一种新的工程分层传统代码负责确定性逻辑模型负责模糊判断和动态决策工具负责访问真实系统状态机负责流程推进guardrails 和人工审批负责安全边界观测和评估负责持续迭代真正值得投入的 agentic workflow不是看起来多智能而是能在复杂、模糊、多步骤的真实业务里稳定完成任务并且每一步都可解释、可回滚、可审计。一句话总结Agentic workflow 的工程价值不在于让模型替代流程而在于让模型参与流程中最难被规则化的部分。参考资料OpenAI: A practical guide to building agentsOpenAI Agents SDK: AgentsOpenAI Agents SDK: GuardrailsAnthropic: Building effective agentsLangChain: Human-in-the-loopLangChain: The Agent Development LifecycleLangChain: The runtime behind production deep agents