AI Workflow v.s. AI Agent v.s. Agentic Workflow 与应用建议

目录

AI Agent v.s. AI Workflow

2025 年作为公认的 “智能体元年”，相关的技术和概念依旧在高速发展中。所以，至今为止业界依旧没有达成关于 AI Agent 和 AI Workflow 的统一定义。本文尝试通过两者特性的不同进行区分：

• AI Agent：一个由 LLM 来动态规划任务执行路径和工具使用的系统，强调探索性、泛化性和灵活性。
• AI Workflow：一个由人类来静态地预定义任务执行路径、工具使用以及 LLM 编排的系统，强调顺序性、可靠性和可重复性。

	Workflow	Agent
执行路径	具有确定的、可预测的、可重复的、一致性的任务执行路径。	不确定的任务执行路径。
探索性	需求较低，作为确定性任务执行路径之上的不确定场景的补充。	需求较高，需要探索效率更高的新路径。
泛化性	需求较低，功能场景相对固定，侧重场景化定制能力。	需求较高，利用通用智能体需要将能力泛化到各种场景。
归纳性	因为场景较固定，可以进行基于先验的模式和规律的归纳总结。	因为场景多，所以可归纳性差。
灵活性与稳定性	侧重稳定性。	侧重灵活性。
应用场景	需要稳定性和效率的场景。	需要大规模灵活性和模型驱动的决策的场景。

但值得注意的是，AI Workflow 和 AI Agent 并非互斥，随着技术发展现在两者的融合探索的方向就是 Agentic Workflow。实际上，不管是 AI Workflow 还是 AI Agent，都是一种模式，而不是规范或标准，开发者可以组合和改造这些模式来实现自己的 AI system。

Agentic Workflow = AI Agent + AI Workflow

Workflow 一直是 “企业数字化转型” 的最佳实践，因为 “Workflow = SOP = 企业流程” 符合大多数人类的线性逻辑思维。所以目前来看相较于 AI Agent 而言，AI Workflow 是如今 toB 落地较好的一种产品形态，更易于结合企业现有的 SOP 工作流程，符合平滑演进的策略。

今天往回看可以将企业级 Workflow 应用程序分为 3 个阶段：

1. 自动化工作流：将繁杂的企业工作流程化，引入 IT 信息化系统，但不具有 AI 能力，强调的是企业信息化转型以支撑业务发展。是企业数字化转型过程中的一个环节。（注：数字化转型还要求业务的创新以及商业竞争力的建设。）

2. AI 工作流：是一种演进的方式。在传统工作流的基础上引入了 “LLM 智能”，比如原有的某个环节中增加 AI 能力，从而进一步提升技术效益，探索 “智能化转型” 的落地实践。目前工业界主要还处于 AI Workflow 阶段的落地实践，典型产品有百度千帆 AppBuilder、扣子、Dify、LangGraph 框架等，通过不同的图结构来编排 LLM 决策过程，从而实现更复杂、更可靠的执行路径。

3. 代理化工作流：是一种革新的方式。对工作流制定者角色进行切换，由人类制定的静态工作流，切换为由 AI Agent 制定的动态工作流，而人类只需要 Review 这些工作流是否符合预期。强调使用 “AI 系统的自主性” 来重构原有的工作流程，引入基于 AI 的持续优化和创新能力。如下图所示。

Agentic Workflow 得以实现的底层技术支撑是推理型 LLM 的 Flow 规划能力。以 OpenAI o1 为例，它演示了一种能够将复杂的知识文档转化为可操作工作流的能力。如下图所示。这意味着，拥有大量知识库文档的企业可以不微调 LLM 的前提下，即刻尝试探索 Workflow 的重构设计。

增强型 LLM 应用建议

当我们在使用 LLM 技术来构建应用程序时，首先我会建议尽可能采用最简单的技术方案，例如 LLM 加上 Prompt Engineering、RAG、in-context examples 等技术通常可以解决大部分的问题，这有助于我们积累有效的 Prompt System 以及理解各个商业化 LLM 的技术特点。

只有当问题真的复杂时，再根据实际需求增加应用程序的复杂性，例如引入 AI Workflow 或 AI Agent，因为两者都具有更高的访问延迟和成本投入，因此需要权衡利弊。以 AI Workflow 为例，首先需要开发者人为的对工作流程进行任务拆解，并且为了灵活地编排这些任务，就需要开发者掌握图知识、任务编排、编程框架等概念和技术。总的来说，AI Workflow 的下限很低，对开发者的能力要求较高。所以 AI Workflow 的企业落地依旧需要面对多种挑战。

简而言之，如无必要建议先不要基于引入 AI Agent 或 AI Workflow。而当我们必要去构建时，可以选择使用成熟的框架，例如：

• LangChain & LangGraph
• Amazon Bedrock’s AI Agent framework
• Rivet, a drag and drop GUI LLM workflow builder; and
• Vellum, another GUI tool for building and testing complex workflows.
• etc

但需要注意的是，这些框架为了简化开发者的编码工作，使用户更容易入门，往往会进行额外的抽象和封装层（如 LLM 连接器、Prompt 模版、工具集合等）。但这可能会导致底层的提示词和响应变得难以调试，增加了不必要的复杂性和未知的故障域。

因此建议：

1. 首选直接使用 LLM API，实际上许多问题几行代码就能实现；
2. 如果确实要用框架，要确保理解这些框架的底层代码。对底层代码的错误假设是常见的问题来源。

而对于框架的选择，建议：

1. 不是所有功能都需要用上，而应该根据你的实际需求，只保留最必要的部分。
2. 尽量使用那些文档完善的组件，否则就是给自己挖坑。

增强型 LLM 应用程序的成功关键不在于构建复杂的系统，而是构建符合需求的系统并科学衡量系统的性能。从简单的 Prompt 开始，不断评估和优化，只有当简单的方案不可时，再考虑引入 multi-step agentic systems。从最简单的 LLM API 用起是一个明智的选择。