AI Workflow Runtime

Agent 和 Workflow 的区别:企业 AI 落地为什么需要可控执行

Agent 和 Workflow 的核心分界不是是否用了大模型,而是谁控制下一步。对企业生产环境而言,纯 Agent 往往过度自由,纯 Workflow 又难以处理模糊任务;iAgent 的优势在于把两者拆分到正确位置。

作者: davyhung&codex

摘要

Agent 和 Workflow 经常被放在一起讨论,因为二者都可能包含大模型、工具调用、外部系统集成和多步骤任务编排。但它们的核心分界并不是“有没有模型”,也不是“有没有工具”,而是:下一步由谁决定

当流程路径由代码、规则、状态机或人工配置提前定义时,它更接近 Workflow;当模型在运行时根据上下文自主决定下一步做什么、调用什么工具、是否继续迭代时,它更接近 Agent。Anthropic 在《Building effective agents》中也给出了类似的架构区分:workflow 是 LLM 与工具沿预定义代码路径被编排的系统,而 agent 是由 LLM 动态指导自身流程与工具使用的系统。[1]

这个区别直接影响企业 AI 产品的投产方式。Agent 更灵活,适合开放式、难穷举、需要模型持续判断的任务;Workflow 更稳定,适合确定性流程、审批链路、跨系统写入、可审计任务。iAgent 的产品优势正在于此:它不是把所有任务都交给一个黑箱 Agent,而是把确定性控制交给 runtime,把模糊判断交给模型,把高风险动作交给人工审批,把失败恢复和审计留在工作流状态中。[13]

1. 问题背景:Agent 热潮之后,企业开始重新重视 Workflow

Agent 的吸引力来自一个简单承诺:给模型一个目标,让它自己拆解任务、调用工具、观察结果、继续执行,直到完成。这种范式在 ReAct 等研究中已经被系统化讨论:模型可以在推理轨迹和行动之间交替,通过外部环境反馈更新计划。[2]

但企业生产环境并不只看“能不能做”,还要看“是否稳定、是否可控、是否可解释、是否能复盘”。自主循环越多,系统就越容易出现成本放大、路径漂移、工具误用、无法复现和审计困难。关于 Agent 系统效率的研究也开始强调,复杂 Agent 设计需要面对明显的效果-成本权衡,不能把更多模块、更多循环、更多工具调用等同于更好的生产结果。[6]

因此,企业 AI 的核心问题已经从“要不要 Agent”转向“Agent 应该被放在流程中的什么位置”。在多数场景里,最稳妥的架构不是纯 Agent,也不是纯规则 Workflow,而是:Workflow 做骨架,Agent 做局部判断,runtime 负责状态、权限、审批、恢复和审计

2. 核心概念与边界:谁控制下一步

2.1 Workflow:路径预定义,执行可预测

Workflow 指由开发者、业务专家或流程设计器预先定义路径的任务系统。它可以包含 LLM 节点,也可以完全不使用 LLM。关键在于:分支、顺序、重试、审批、失败处理等控制逻辑主要由系统设计决定。

典型 Workflow 包括提示链、路由、并行处理、审批流、数据同步、文件处理、订单处理、工单流转等。Anthropic 将 prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer 等模式都归入常见 workflow 模式。[1]

2.2 Agent:路径运行时生成,模型拥有更多控制权

Agent 指模型在运行时根据目标和环境反馈决定下一步动作的系统。它可能选择调用搜索、数据库、浏览器、代码执行器、本地文件、企业 API 或其他工具;也可能在结果不足时继续规划、修正和迭代。OpenAI Agents SDK 将 agent 表述为“带有指令和工具的 LLM”,并提供 agent loop、handoffs、guardrails、sessions、human-in-the-loop、tracing 等能力来支撑这类应用。[3]

Agent 的优势是灵活,代价是可预测性下降。它适合那些无法提前穷举路径的问题,例如复杂故障归因、跨来源研究、代码修改、多文件分析、开放式信息搜集等。

2.3 一张表说明关键区别

维度WorkflowAgent
决策权代码、规则、状态机、人工配置模型在运行时动态决定
路径形态预定义、可测试、可复盘动态生成、依赖上下文和模型判断
成本更可预测可能随循环和工具调用放大
调试容易定位到节点和分支需要 trace、状态快照和运行轨迹
适应性适合已知流程适合未知路径和开放式任务
风险控制容易加审批、权限、幂等与回滚需要额外 guardrail、沙箱和人工检查
投产形态主流程、审批流、跨系统自动化局部推理、探索、归因、复杂判断

这张表可以归结为一句话:Workflow 让任务更可控,Agent 让任务更有弹性。生产系统需要的不是二选一,而是把控制权分配到正确的位置。

3. 架构机制:纯 Agent、纯 Workflow 与混合架构

纯 Workflow 的结构比较清晰。每个节点的输入、输出、下一步、异常处理和审批逻辑都是显式定义的。

输入DE节点 1:分类 / 提取验证C完成 / 归档

纯 Agent 的结构则是一个循环。模型不断观察环境、制定下一步、调用工具、读取结果,直到它判断任务完成。

目标模型计划工具调用环境反馈

在企业场景中,更常见的目标架构是混合式:Workflow 管住主路径,Agent 只在需要语义判断和不确定推理的地方发挥作用。

用户目标 / 业务事件Workflow Runtime确定性节点:输入校状态 / 日志 / 事件历史权限 / 策略 / 审批门Trace / Metrics / AuditAgent 节点:理解与归因确定性节点:工具执人工审批:高风险动验证与归档完成

这种架构的关键不是让 Agent 消失,而是限制 Agent 的边界。模型可以判断“这是什么问题”“应当调用哪类知识”“如何解释异常”“修复建议是什么”,但不应天然拥有无限工具权限、无限循环次数和无限写入能力。

LangGraph、Temporal、OpenAI Agents SDK 等系统都在不同层面处理这个问题。LangGraph 强调 durable execution、human-in-the-loop、persistence、debugging 等底层 agent orchestration 能力;Temporal 强调故障后从中断位置继续执行;OpenAI Agents SDK 则提供 guardrails、sessions、human-in-the-loop、tracing 与 sandbox agent 等机制。[3][4][5]

4. 企业落地中的关键挑战

4.1 成本与延迟:Agent 自主循环会放大调用链

Agent 的成本不只来自一次模型调用,而来自多轮规划、多次工具调用、反复读取上下文、失败重试和中间结果压缩。研究者已经开始从 cost-of-pass 等角度评估 Agent 系统的性能-成本权衡,说明“更复杂的 Agent 设计”并不自动等于“更优的整体效率”。[6]

Workflow 的成本通常更可预测。即使流程里包含多个 LLM 节点,调用次数、上下文范围、工具顺序和最大重试次数也可以被事先限制。对每天运行成百上千次的企业任务而言,可预测成本本身就是产品能力。

4.2 可复现性:Agent 的错误不一定能重放

Agent 错误常见于动态路径:同一个输入在不同时间可能选择不同工具、走不同分支、产生不同中间判断。OAgents 的实证研究也指出,当前 agent 研究实践存在标准化与可复现性不足的问题,开放式 agent 框架之间的公平比较并不容易。[7]

企业系统不能只保存最终答案,而要保存运行轨迹:输入、输出、模型版本、提示词版本、工具参数、外部返回、审批记录、失败节点、重试次数。没有这些证据,问题定位只能依赖聊天记录和人工猜测。

4.3 安全与权限:Agent 的风险是“做错事”,不是只“说错话”

当模型只能回答问题时,风险主要是内容错误;当模型可以调用工具时,风险变成动作错误。OWASP 在 LLM 应用风险中将 excessive agency 列为关键风险之一,强调给 LLM 过多自主动作能力可能带来可靠性、隐私和信任问题。[9] OWASP 针对 Agentic Applications 的风险框架进一步说明,agentic 系统需要专门处理身份、权限、工具调用、任务边界和人类监督等问题。[10]

MCP 的规范也明确指出,工具代表任意代码执行路径,需要谨慎对待;主机应在调用工具前获得用户明确同意,并让用户理解每个工具会做什么。[8] 这意味着企业 AI 的安全边界不能只写在 prompt 里,而必须写进 runtime、权限、审批和日志系统里。

4.4 合规与治理:AI 系统必须留下证据链

NIST AI RMF 及其生成式 AI Profile 强调,应在 AI 产品和系统的设计、开发、使用和评估中纳入可信性与风险管理考虑。[11] 对企业 Agent 来说,这意味着系统需要能回答:模型看到了什么、为什么这么做、谁批准了动作、工具执行了什么、失败如何恢复、数据是否被最小化发送。

OpenTelemetry 提供 traces、metrics、logs 等可观测性基础能力,适合成为 AI workflow runtime 的工程底层之一。[12] 但可观测性只是一部分,真正的生产要求还包括业务级审计、节点级恢复、审批记录和权限回收。

5. 适用场景与不适用场景

5.1 更适合 Workflow 的场景

Workflow 更适合以下场景:

  • 流程步骤清楚,例如数据同步、报表生成、审批流、文件处理。
  • 错误容忍度低,例如财务、人事、法务、客户资料修改。
  • 需要审计留痕,例如合同审批、发票处理、工单流转。
  • 有明确外部系统写入,例如 CRM 更新、ERP 写回、邮件发送。
  • 需要失败恢复,例如长任务、多文件处理、跨系统批处理。
  • 运行频率高,需要控制成本与稳定性。

这些场景的共同点是:灵活性不是第一优先级,稳定、可控、可复盘才是核心。

5.2 更适合 Agent 的场景

Agent 更适合以下场景:

  • 输入类型难以穷举。
  • 任务路径依赖运行时信息。
  • 需要跨多个来源探索。
  • 需要模型综合判断。
  • 没有固定 SOP,或者 SOP 只覆盖一部分情况。
  • 允许在沙箱中多轮尝试和纠错。

典型例子包括复杂故障归因、跨文档研究、代码库修改、开放式数据调查、异常模式分析等。

5.3 更适合混合架构的场景

多数企业 AI 场景最终会落在混合架构中。例如告警处理:告警收集、去重、派发、审批和归档适合 Workflow;根因判断、相似案例检索、处置建议生成适合 Agent。再如合同审阅:文件解析、版本记录、审批链和归档适合 Workflow;条款风险解释和修改建议适合 Agent。

混合架构的原则是:让 Agent 处理不确定性,让 Workflow 管住确定性和后果。

6. 选型与实施建议

企业选择 Agent 或 Workflow,可以用以下问题判断:

判断问题更偏 Workflow更偏 Agent
输入类型能否提前列出很难
下一步路径是否固定固定取决于运行时判断
是否涉及写入、发送、删除、覆盖是,需要控制只在审批后局部使用
失败后是否必须局部恢复需要 runtime 承接
是否需要审计Agent 不能独立承担
成本是否敏感敏感可接受较高探索成本
是否允许结果不完全一致不允许可接受
是否需要长时间运行需要与 Workflow/runtime 结合

实施上应避免两个极端。

第一个极端是把所有任务都做成纯 Agent。这样短期演示效果好,但一旦进入真实业务,就会暴露权限、成本、审计、恢复和调试问题。

第二个极端是把所有 AI 能力都压成固定流程。这样虽然稳定,但无法处理模糊输入和复杂判断,最终只能回到人工处理。

更稳妥的路线是分层建设:

  1. 先把高频、确定性流程做成 Workflow。
  2. 在需要语义理解和复杂判断的位置加入模型节点。
  3. 对开放式问题引入 Agent,但限制工具、轮次、预算和边界。
  4. 对高风险动作加入人工审批。
  5. 对所有节点记录状态、输入、输出、工具结果和审计事件。
  6. 用评估集和真实运行 trace 持续优化节点,而不是只优化 prompt。

7. iAgent 语境下的产品优势

iAgent 的定位不是“更自由的 Agent”,而是“稳定的 workflow agent runtime”。从公开页面可以看到,iAgent 的核心表达是:把一个工作请求转成可审阅、可重跑的 workflow;代码处理确定性执行,模型处理模糊性,人审批高风险动作,runtime 记录状态、验证和恢复。[13]

这一路线正好回应了 Agent 与 Workflow 的分界问题。

7.1 Code controls certainty:确定性不交给模型即兴发挥

在企业流程中,很多步骤不需要模型自由发挥,例如文件是否存在、字段是否完整、接口是否成功、审批是否通过、结果是否归档。这些确定性逻辑更适合由代码、规则和 runtime 控制。iAgent 强调 state、permissions、tool execution、persistence、logs、verification、recovery 由代码负责,而不是由模型 improvisation 控制。[13]

这可以降低纯 Agent 的路径漂移风险,也让流程更容易测试、复盘和维护。

7.2 Models handle ambiguity:模型只处理真正需要判断的部分

模型擅长理解、抽取、解释、归因、生成建议和修复提示。但模型不适合无边界地控制全部流程。iAgent 将模型限制在“处理模糊性”的节点中,让 LLM 负责理解与建议,而不是拥有整个控制流。[13]

这种设计保留了 Agent 的灵活性,同时避免把所有动作都交给 Agent 自主决定。

7.3 People approve risk:高风险动作进入人工审批

发送、删除、覆盖、写入、提交等动作会产生真实后果。iAgent 公开页面明确强调,write、overwrite、send、delete 和 high-impact actions 会暂停,直到人审阅输入、输出和风险后批准。[13]

这比“让 Agent 自己谨慎一点”更适合企业环境。审批不是附加功能,而是 Agentic Workflow 的控制面。

7.4 Node-level recovery:失败不是从头再来

纯 Agent 失败时,常见处理是重新运行整段任务。但真实业务中,前面步骤可能已经写入外部系统,不能简单重跑。iAgent 将失败定位到具体节点,保留 input、output、error 和 impact,并支持在审阅修复后从节点重跑。[13]

这与 durable execution 的工程思想一致:生产系统应该从失败处恢复,而不是依赖人工记忆和聊天上下文。[5]

7.5 Local-first:敏感任务优先在本地执行

很多企业任务发生在桌面、本地文件、内部系统和半结构化资料中。纯云端 Agent 往往需要上传更多上下文,增加数据治理压力。iAgent 公开页面强调默认 local-first processing,仅模型节点发送该步骤所需的最小有用上下文。[13]

对合同、表格、客户材料、财务文件、内部运营文档等场景而言,local-first 不是性能偏好,而是产品信任基础。

结论

Agent 和 Workflow 的区别,本质上是控制权的区别。Workflow 的控制权主要在代码、规则、状态和人工配置中;Agent 的控制权更多交给模型在运行时动态决定。前者稳定、可预测、易审计;后者灵活、适合开放式判断,但成本、调试、安全和治理压力更高。

企业 AI 不应盲目追求“纯 Agent”。真正可投产的系统通常是混合架构:Workflow 控制主流程,Agent 负责局部不确定判断,human-in-the-loop 管住高风险动作,runtime 负责状态、权限、恢复、日志和审计。

iAgent 的优势在于,它把 Agent 的灵活性放进 Workflow 的控制结构中。模型不再是黑箱执行者,而是某些节点上的判断能力;流程不再是一次性聊天结果,而是可审阅、可测试、可暂停、可恢复、可追踪的业务运行时。对企业生产环境而言,这种结构比“更自由的 Agent”更接近可靠落地。

参考文献

[1] Anthropic. Building effective agents. Anthropic Engineering, 2024-12-19. https://www.anthropic.com/engineering/building-effective-agents

[2] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629, 2022/2023. https://arxiv.org/abs/2210.03629

[3] OpenAI. OpenAI Agents SDK. OpenAI Documentation, 访问日期:2026-06-12. https://openai.github.io/openai-agents-python/

[4] LangChain. LangGraph overview. LangChain Documentation, 访问日期:2026-06-12. https://docs.langchain.com/oss/python/langgraph/overview

[5] Temporal Technologies. Temporal Docs: Build applications that never fail. Temporal Documentation, 访问日期:2026-06-12. https://docs.temporal.io/

[6] Ningning Wang, Xavier Hu, Pai Liu, He Zhu, Yue Hou, Heyuan Huang, Shengyu Zhang, Jian Yang, Jiaheng Liu, Ge Zhang, Changwang Zhang, Jun Wang, Yuchen Eleanor Jiang, Wangchunshu Zhou. Efficient Agents: Building Effective Agents While Reducing Cost. arXiv:2508.02694, 2025. https://arxiv.org/abs/2508.02694

[7] He Zhu, Tianrui Qin, King Zhu, Heyuan Huang, Yeyi Guan, Jinxiang Xia, Yi Yao, Hanhao Li, Ningning Wang, Pai Liu, Tianhao Peng, Xin Gui, Xiaowan Li, Yuhui Liu, Yuchen Eleanor Jiang, Jun Wang, Changwang Zhang, Xiangru Tang, Ge Zhang, Jian Yang, Minghao Liu, Xitong Gao, Jiaheng Liu, Wangchunshu Zhou. OAgents: An Empirical Study of Building Effective Agents. arXiv:2506.15741, 2025. https://arxiv.org/abs/2506.15741

[8] Model Context Protocol. Model Context Protocol Specification, Version 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18

[9] OWASP GenAI Security Project. 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps. OWASP, 2025. https://genai.owasp.org/llm-top-10/

[10] OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications for 2026. OWASP, 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[11] Chloe Autio, Reva Schwartz, Jesse Dunietz, Shomik Jain, Martin Stanley, Elham Tabassi, Patrick Hall, Kamie Roberts. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, 2024. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

[12] OpenTelemetry. OpenTelemetry Documentation. OpenTelemetry, 访问日期:2026-06-12. https://opentelemetry.io/docs/

[13] iAgent Labs. iAgent - Stable workflow agent runtime. iAgent Official Website, 访问日期:2026-06-12. https://www.iagent7.com/