本系列文章基于 Lynxe 作者沈询的实战经验，深入浅出解析 ReAct Agent 的核心原理与工程价值，帮助开发者快速掌握从“写流程”到“造智能体”的关键跃迁。
关于这个系列
作为 Lynxe(原JManus）的作者，我花费了很多课余时间来完善这个Func-Agent框架，也因此对于什么是ReAct Based Agent 有了更深一些的理解。
所以想把这些内容总结出来，是因为这个项目本身核心目的就是探索Agent的前沿优秀实践，目前已经有所小成，Lynxe能解决我自己面对的80%以上的问题了，所以我觉得值得把我实验下来有效的东西写出来，方便大家快速入门。
你可以访问 Lynxe(菱科斯) 阅读详细源码来学习agent的一些优秀实践。这是一个非常完善的产品级的 Func-Agent框架。
https://github.com/spring-ai-alibaba/Lynxe
系列计划
AI Agent系列｜什么是 ReAct Agent？
深入了解智能体工作流核心：Agent vs 传统编程 vs Workflow 的本质区别(本篇)
深入解析Function Calling、MCP和Skills的本质差异与优秀实践
上下文管理的一些实践
并行执行的优秀实践与我走过的弯路
在上一篇文章中，我介绍了什么是 ReAct Agent。现在我来聊聊一个更实际的问题：Agent 和传统的编程方式、工作流方式到底有什么本质不同？为什么我需要 Agent？
一句话总结：传统编程和 Workflow 都是人在做决策、提前设计好所有逻辑，而 Agent 是 AI 在做决策，能够解决原有写程序不能解决的问题，因此更容易做出差异化的体验，也因此更适合作为下一代的用户交互新范式。就像目前大家都在用的coding agent 一样，未来会有更多面向不同领域的agent涌现。
三种方式的对比
先看一个直观的对比表：
这个表格可能看起来有点抽象，让我用更具体的方式来解释这三种方式的本质区别。
传统编程：一切都要提前想好
传统编程就像建房子，你得先把所有图纸都画好，所有材料都准备好，然后严格按照图纸施工。一旦遇到图纸上没有的情况，就得重新设计。
实际例子
假设你要做一个"根据天气推荐穿衣"的功能：
传统编程方式：
这种方式的问题很明显：
硬编码规则：所有逻辑都是提前写死的，遇到新情况就得改代码；
异常处理复杂：各种边界情况都要提前考虑，代码会变得很复杂；
修改成本高：改一个小逻辑，需要开发、测试、部署，整个流程走一遍；
例如：
# 3. 如果API返回错误怎么办？需要写异常处理
# 4. 如果数据格式不对怎么办？需要写数据验证
# 5. 如果用户想要更详细的建议怎么办？需要修改代码
Workflow 工作流：流程固定，但更灵活一些
Workflow 工作流就像搭积木，你可以用图形化的方式把不同的"积木"（节点）连接起来，形成固定的流程。比传统编程灵活一些，但本质上还是固定的路径。
实际例子
开始 -> 查询天气API -> 判断温度 -> 返回建议 -> 结束
这种方式比传统编程好一些：
可视化：不需要写代码，拖拽就能完成；
模块化：每个节点是独立的，可以复用；
但问题依然存在：
流程是固定的，如果用户想要"先查天气，再查穿衣建议，最后保存到文件"，就需要重新设计整个流程；
条件判断有限，复杂的逻辑还是需要写代码；
复杂流程维护难度也会变大；
修改流程仍然需要开发人员参与；
例如：
# 3. 如果API返回错误怎么办？需要写异常处理；
# 4. 如果数据格式不对怎么办？需要写数据验证；
# 5. 如果用户想要更详细的建议怎么办？需要修改代码。
Agent：边走边看，动态调整
Agent 就像一个有经验的向导，你告诉他目标，他会根据实际情况动态调整路线。不需要提前把所有情况都想好，遇到问题就解决，走不通就换条路。
实际例子
同样的"根据天气推荐穿衣"功能，用 Agent 的方式：
你只需要告诉 Agent："帮我查一下北京今天天气怎么样，适合穿什么衣服，然后保存到文件。"
Agent 会自己决定：
1. 先调用天气查询工具；
2. 根据天气结果，决定调用穿衣建议工具；
3. 获取建议后，决定调用文件写入工具；
4. 如果某个工具失败了，会自动尝试其他方法。
整个过程是动态的，不需要提前设计好所有步骤。
本质区别：谁在做决策？
这三种方式最本质的区别在于：谁在做决策？
传统编程：程序员在做决策，把所有可能的情况都提前想好，写成代码；
Workflow：产品/开发在做决策，设计固定的流程路径；
Agent：AI 在做决策，根据实际情况动态调整策略；
也因为决策者不同，所以对于技能的要求就不同：传统编程需要掌握编程语言、算法、系统设计等专业知识，门槛很高；Workflow 需要理解编程原理和图形化工具，门槛中等；而 Agent 只需要会用自然语言描述需求即可，显而易见的 Agent 极大降低了门槛。同时，这也带来了修改和维护成本的巨大差异：传统编程需要多角色瀑布协作（几天到几周），Workflow 只能节省部署环节，而 Agent 可以实现业务自闭环，从发现问题到解决问题只需要几分钟。
总结
综合来看，我认为 Agent 是更面向未来的、值得探索和尝试的新应用使用范式。
主要原因也非常简单： Agent能带来更明显的“新体验”，因此更易于被最终端用户感知。
Workflow 与传统编程模型 ， 其核心的变化都仅仅在于在固化的流程中适当的增加AI的能力，除了这个差异外，其他部分都是类似的，因此，他们两个从本质来说都是由程序控制的流程流转，他们其实是相互替代关系，在没有 AI 的时代就已经充分竞争过了。
竞争的结果就是写代码的方案因为其优秀的复用性和扩展性成为了更主流的选择。
而 Agent 的玩法则完全不同。它的决策权完全下放给了 Agent 和 Prompt，能够解决原有写程序不能解决的问题——比如处理不确定性、动态调整策略、理解自然语言意图等。因此，Agent 不是对传统编程的简单替代，而是一种更有机会的新范式。
从应用场景来说：
如果你是既有系统要增强 AI 能力，那么完全可以使用代码 + toolcall 来实现，效果是最好的，准确性也有保障。这种方式适合需要精确控制、高性能的场景。
如果你希望用户能明显感觉这是一个 AI 驱动的创新类产品，那么用 AI Agent 是一个更好的选择。这种方式适合需要处理不确定性、快速迭代、让非技术人员也能完成复杂任务的场景。
关键是要理解每种方式的本质，根据实际场景选择最合适的方式。Agent 的核心价值在于它开辟了新的可能性，让 AI 真正成为决策者，而不仅仅是执行者。
