深度解析智能体工作流 (Agentic Workflows)：Agent、传统编程与Workflow的本质区别

关于这个系列

我是 Lynxe（原 JManus）的作者，在课余时间持续打磨这个 Func-Agent 框架的过程中，对 ReAct-Based Agent 有了更深入的理解。

之所以想系统地分享这些经验，是因为这个项目的初衷正是探索 Agent 领域的前沿最佳实践。如今，Lynxe 已经初见成效，能够解决我自身面临的 80% 以上的问题。我认为，将这些经过验证的有效方法整理出来，可以帮助大家更快地入门和上手。

欢迎访问Lynxe (菱科斯)查看详细的源代码，学习 Agent 开发的最佳实践。这是一个功能完备、可直接用于生产环境的 Func-Agent 框架。

系列计划

• 什么是 ReAct Agent？
• 深度解析智能体工作流 (Agentic Workflows)：Agent、传统编程与Workflow的本质区别(本篇）
• 工具toolcall/mcp管理的最佳实践
• 上下文管理的一些实践
• 并行执行的最佳实践与我走过的弯路
• 其余 想到或得到反馈在写

正文开始

在上一篇文章中，我们探讨了 ReAct Agent 的基本概念。接下来，我们将深入分析一个更为实际的问题：Agent 与传统编程及工作流模式之间究竟存在哪些本质差异？以及，为何我们需要引入 Agent 这一范式？

一句话总结：
传统编程和 Workflow 都是人在做决策、提前设计好所有逻辑，而 Agent 是 AI 在做决策，能够解决原有写程序不能解决的问题，因此更容易做出差异化的体验，也因此更适合作为下一代的用户交互新范式。
就像目前大家都在用的coding agent 一样，未来会有更多面向不同领域的agent涌现。

三种方式的对比

先看一个直观的对比表：

这个表格可能看起来有点抽象，让我用更具体的方式来解释这三种方式的本质区别。

传统编程：一切都要提前想好

传统编程就像建房子，你得先把所有图纸都画好，所有材料都准备好，然后严格按照图纸施工。一旦遇到图纸上没有的情况，就得重新设计。

实际例子

假设你要做一个"根据天气推荐穿衣"的功能：

传统编程方式：

def get_weather_recommendation(city): # 1. 查询天气 weather = query_weather_api(city) temperature = weather['temperature'] condition = weather['condition'] # 2. 根据温度判断 if temperature < 10: return "建议穿厚外套" elif temperature < 20: return "建议穿薄外套" elif temperature < 25: return "建议穿长袖" else: return "建议穿短袖" # 3. 如果API返回错误怎么办？需要写异常处理 # 4. 如果数据格式不对怎么办？需要写数据验证 # 5. 如果用户想要更详细的建议怎么办？需要修改代码

这种方式的问题很明显：

• 硬编码规则：所有逻辑都是提前写死的，遇到新情况就得改代码
• 异常处理复杂：各种边界情况都要提前考虑，代码会变得很复杂
• 修改成本高：改一个小逻辑，需要开发、测试、部署，整个流程走一遍

Workflow 工作流：流程固定，但更灵活一些

Workflow 工作流就像搭积木，你可以用图形化的方式把不同的"积木"（节点）连接起来，形成固定的流程。比传统编程灵活一些，但本质上还是固定的路径。

实际例子

同样的"根据天气推荐穿衣"功能，用 Workflow 的方式：

[开始] -> [查询天气API] -> [判断温度] -> [返回建议] -> [结束] ↓ (如果失败) [错误处理节点]

这种方式比传统编程好一些：

• 可视化：不需要写代码，拖拽就能完成
• 模块化：每个节点是独立的，可以复用
• 但问题依然存在：
  • 流程是固定的，如果用户想要"先查天气，再查穿衣建议，最后保存到文件"，就需要重新设计整个流程
  • 条件判断有限，复杂的逻辑还是需要写代码
  • 复杂流程维护难度也会变大
  • 修改流程仍然需要开发人员参与

Agent：边走边看，动态调整

Agent 就像一个有经验的向导，你告诉他目标，他会根据实际情况动态调整路线。不需要提前把所有情况都想好，遇到问题就解决，走不通就换条路。

实际例子

同样的"根据天气推荐穿衣"功能，用 Agent 的方式：

你只需要告诉 Agent："帮我查一下北京今天天气怎么样，适合穿什么衣服，然后保存到文件。"

Agent 会自己决定：

1. 先调用天气查询工具
2. 根据天气结果，决定调用穿衣建议工具
3. 获取建议后，决定调用文件写入工具
4. 如果某个工具失败了，会自动尝试其他方法

整个过程是动态的，不需要提前设计好所有步骤。

本质区别：谁在做决策？

这三种方式最本质的区别在于：谁在做决策？

• 传统编程：程序员在做决策，把所有可能的情况都提前想好，写成代码
• Workflow：产品/开发在做决策，设计固定的流程路径
• Agent：AI 在做决策，根据实际情况动态调整策略

也因为决策者不同，所以对于技能的要求就不同：传统编程需要掌握编程语言、算法、系统设计等专业知识，门槛很高；Workflow 需要理解编程原理和图形化工具，门槛中等；而 Agent 只需要会用自然语言描述需求即可，显而易见的 Agent 极大降低了门槛。同时，这也带来了修改和维护成本的巨大差异：传统编程需要多角色瀑布协作（几天到几周），Workflow 只能节省部署环节，而 Agent 可以实现业务自闭环，从发现问题到解决问题只需要几分钟。

实际场景对比

让我们用一个更复杂的场景来对比："帮我分析一下最近一周的销售数据，找出异常订单，生成报告并发送给团队"

传统编程方式

需要：

1. 写代码连接数据库
2. 写 SQL 查询销售数据
3. 写算法分析异常（定义什么是异常）
4. 写代码生成报告
5. 写代码发送邮件
6. 处理各种异常情况（数据库连接失败、邮件发送失败等）
7. 测试、部署

可能需要：1-2 周开发时间，涉及后端开发、数据分析、运维等多个角色。

Workflow 方式

需要：

1. 设计流程：查询数据 -> 分析数据 -> 生成报告 -> 发送邮件
2. 配置各个节点
3. 写一些扩展函数处理复杂逻辑
4. 测试、上线

可能需要：1~3 天，需要技术人员参与。

Agent 方式

只需要：

1. 告诉 Agent："帮我分析一下最近一周的销售数据，找出异常订单，生成报告并发送给团队"
2. Agent 自动完成所有步骤
3. 如果结果不对，继续用自然语言调整："异常订单的定义改一下，订单金额超过平均值的 3 倍才算异常"

可能需要：几分钟到几小时，运营人员自己就能完成。

什么时候用哪种方式？

虽然 Agent 看起来很强大，但并不是所有场景都适合用 Agent。三种方式各有适用场景：

传统编程适合：

• 性能要求极高的场景（高频交易、实时游戏等）
• 需要精确控制的场景（安全系统、金融系统等）
• 逻辑非常固定、不会变化的场景

Workflow 适合：

• 业务流程相对固定，但需要可视化管理的场景
• 需要非技术人员参与流程设计的场景
• 需要流程审计和版本管理的场景

Agent 适合：

• 需求经常变化的场景
• 需要处理不确定性的场景
• 需要快速迭代和试错的场景
• 非技术人员需要自主完成任务的场景

总结

综上所述，Agent 代表了一种更具前瞻性的应用范式，非常值得我们去深入探索和实践。

其核心优势在于：Agent 能够创造出显著不同的“新体验”，从而更容易被终端用户直接感知和认可。

相比之下，Workflow 和传统编程模型的核心变化，主要是在既定的流程框架内融入 AI 能力。抛开这一点，它们在本质上仍是程序驱动的流程执行，二者之间更多是替代关系。这种替代关系在 AI 时代之前就已存在并经过了充分的竞争，最终，编码方案因其卓越的复用性和可扩展性而成为主流。

Agent 的运作模式则截然不同。它将决策权交给了 AI 代理（Agent）和提示词（Prompt），使其能够应对传统编程难以解决的挑战——例如处理不确定性、动态调整执行策略以及深度理解自然语言意图。因此，Agent 并非对传统编程的简单升级或替代，而是一种蕴含巨大潜力的全新范式。

具体到应用场景：

• 对于需要为现有系统增强 AI 功能的情况，采用“代码 + ToolCall”的方式是最佳选择，它能提供最优的效果和可靠的准确性，尤其适用于对精确控制和性能要求高的场景。

• 如果目标是打造一个能让用户明显感受到 AI 驱动的创新型产品，那么 AI Agent 无疑是更优的路径。它特别适合那些需求多变、需要快速试错，并且希望让非技术人员也能独立完成复杂任务的场景。

归根结底，关键在于深刻理解每种方法的本质。只有这样，才能根据具体的业务需求，选择最合适的解决方案。Agent 的真正价值，在于它开启了全新的可能性，让 AI 从单纯的执行者，跃升为真正的决策者。