上一篇文章我介绍了工作流（Workflow）的5种核心模式，相信大家对工作流有了初步的认识。在这篇文章中，我将介绍智能体（Agent）的核心工作机制，即推理-行动循环（Reasoning-Action Loop，简称ReAct）。在介绍智能体之前，我会先用天气助手这个实际案例，带大家更深入地理解工作流的局限性，并由此引出智能体的解决方案。

一、用工作流实现天气助手

1.1 设计工作流天气助手

        工作流的核心在于执行路径固定、步骤明确。用工作流设计天气助手，可以采用提示链模式，整体结构如图1所示。

图1：工作流天气助手

        这是一个三节点的线性工作流：

        1. LLM解析节点：利用LLM从用户输入中提取需要查询天气的城市名称。通过系统提示词约定提取规则：

        2. 天气查询工具节点：调用高德地图API，查询指定城市的温度、湿度、风向、风力等信息。

        3. LLM整理输出节点：将工具返回的原始数据整理成符合人类语言习惯的自然回答，比直接输出JSON更友好。

system_prompt = """你是一个城市名提取助手。你的任务是从用户输入中提取所有需要查询天气的城市名称。 规则： 1. 只输出一个 JSON 数组，格式如：["城市1", "城市2"] 2. 不要输出任何其他解释文字 4. 只提取明确需要查询天气的城市 示例： 输入："帮我查一下北京的天气" → ["北京"] 输入："查杭州和上海的天气" → ["杭州", "上海"] 输入："杭州天气怎么样" → ["杭州"] """

工作流天气助手的代码不在此处展示，感兴趣的读者可以借助AI工具自行实现或者线下交流。

1.2 测试工作流天气助手

        测试时间为2026年5月8日下午5点左右。

        测试一：

用户输入	请帮我获取杭州和北京的天气情况。
天气助手回答	好的，帮你查到了杭州和北京的天气情况： **杭州**：阴天，气温20°C，湿度29%，东北风4级。 **北京**：晴，气温25°C，湿度21%，西南风5级。 两地的体感都比较舒适，不过北京风力稍大，出行注意防风。

        测试二：

用户输入	南京今天热吗？
天气助手回答	今天南京22°C，阴天，不热，还挺凉爽的。出门可以带件薄外套，风力稍大，注意防风哦。

        到目前为止，工作流天气助手表现得很好。但接下来的测试将暴露它的局限性。

        测试三：

用户输入	帮我查一下北京的天气。另外，如果北京下雨，顺便也查一下天津的天气。
天气助手回答	北京的天气是晴，没有下雨，所以按您说的条件，本来不需要查天津的天气。不过系统已经顺便查到了，我也一起告诉您： - **北京**：晴，25°C，湿度21%，西南风5级。 - **天津**：晴，25°C，湿度18%，西南风4级。 两地天气都不错，没有雨～

1.3 问题分析

        测试三的回答乍看没问题，但仔细分析就会发现工作流的结构性缺陷。

        按照用户的真实意图，只有当北京下雨时才需要查询天津的天气。北京是晴天，天津的查询不应该发生。但天气助手的回答中仍然包含了天津的天气，甚至在回答中“道歉式”地解释了这一矛盾。

        问题出在哪里？我们追踪一下工作流中每个节点的实际行为：

节点	发生了什么	问题所在
LLM解析节点	LLM读懂了用户的“条件性意图”，但它陷入两难：如果只输出["北京"]，万一北京下雨，后续节点没有机会再去查天津；如果输出["北京","天津"]，至少不会遗漏。最终它选择了后者。	LLM被迫为工作流的固定结构“兜底”。
天气查询工具节点	这是一个死板执行节点——上游输出几个城市，它就查几个城市。
LLM整理输出节点	LLM读懂了矛盾，但已经无法挽回。它只能尽力“圆话”——“按您说的条件，本来不需要查天津……”	问题在上游已经注定，下游只能用“圆话”来补救。

        测试三暴露的核心问题：工作流的执行路径是固定的，无法根据运行时获取的信息（如北京的天气）来动态调整后续步骤。

        理想的执行逻辑应该是：先查北京的天气，然后判断是否下雨，再有条件地查天津的天气。但这个工作流不具备条件分支能力。虽然可以通过增加判断节点来改造，但每增加一种条件逻辑，工作流的复杂度就会上升，而且我们也无法预知所有可能的条件逻辑——这正是智能体要解决的问题。

二、智能体的核心工作机制

2.1 推理-行动循环

图2：智能体的推理-行动循环

        智能体最核心的工作机制是推理-行动循环，如图2所示。为了聚焦核心概念，图2做了简化。实际生产环境中的智能体通常还包含记忆模块、工具注册表、安全护栏等组件，这些组件在后续的文章中会逐一介绍。

        推理-行动循环的工作原理：

        1. 推理：LLM根据用户问题和当前上下文进行推理，判断是否需要调用工具；

        2. 行动：如果需要调用工具，LLM输出结构化的工具调用指令（工具名称+参数）；

        3. 观察：智能体执行工具调用，将返回结果反馈给LLM；

        4. 循环：LLM根据观察结果再次推理，决定下一步行动。

        循环持续，直到满足终止条件——要么LLM获得了足够的信息可以回答用户，要么达到预设的最大迭代次数（防止无限循环）。

        与工作流的关键区别：工作流的每一步都是预先确定的；而智能体的每一步都是上一步的结果决定的。执行路径不是“规划”出来的，而是“探索”出来的。

三、用智能体实现天气助手

3.1 设计智能体天气助手

图3：智能体天气助手

        用智能体的推理-行动循环机制设计的天气助手如图3所示（图中展开了一次完整的循环过程，实际运行时同一LLM和同一工具在多轮迭代中复用）。

        同样，智能体天气助手的代码不在此处展示，感兴趣的读者可以借助AI工具自行实现或者线下交流。

3.2 测试智能体天气助手

        使用同样的测试用例，测试时间为2026年5月8日下午5点左右。

        测试一：

用户输入	请帮我获取杭州和北京的天气情况。
天气助手回答	以下是 **杭州** 和 **北京** 的天气情况： - **杭州** 目前是阴天，温度19°C，湿度30%，风向是东北风，风力4级，体感较凉爽，建议带件外套出门。 - **北京** 则是晴朗，温度25°C，湿度25%，风向是西南风，风力5级，体感舒适宜人，适合户外活动。 如果还有其他城市需要查询，随时告诉我哦！

        测试二：

用户输入	南京今天热吗？
天气助手回答	今天南京温度21°C，是非常舒适的温度，不冷不热，体感很宜人。不过因为是阴天，可能感觉会稍微凉快一些，建议出门可以带件薄外套，穿得舒适就好～

        测试三：

用户输入	帮我查一下北京的天气。另外，如果北京下雨，顺便也查一下天津的天气。
天气助手回答	查询结果显示，北京现在的天气是 晴天，温度25°C，没有下雨哦！ 所以按照您说的，北京没有下雨，就不需要再查天津的天气了。 以下是北京天气的详细信息： - 天气状况：晴 - 温度：25°C - 湿度：21% - 风向：西南风 - 风力：5级 北京今天是个好天气，适合出行活动！

        智能体天气助手在三个测试中都表现得很好。特别是测试三中，智能体天气助手不再查询天津的天气状况，解决了工作流天气助手中的问题。

3.3 智能体如何解决工作流的问题

        测试三中，智能体的执行过程如下：

循环轮次	推理	行动	观察
第1轮	用户要求有条件地查天津，我需要先知道北京是否下雨	调用天气查询工具，参数为为"北京"	北京：晴，25°C，无雨
第2轮	北京没有下雨，条件不满足，不需要查天津，可以直接回答	无工具调用，输出最终回答

        关键差异：智能体不是一次性决定“查哪些城市”，而是先查北京，根据结果再决定是否查天津。这种“边看路边找路”的能力，正是工作流所不具备的。

四、工作流与智能体的核心区别

        基于以上案例，我们可以总结出两者的本质差异：

维度	工作流	智能体
执行路径	编译时固定，高预测性	运行时动态生成，低预测性
LLM的角色	被调用的信息提取器/生成器，无决策权	决策中枢
中间结果的用途	仅作为下一步骤的输入，不参与决策	影响下一次循环的推理与行动
对条件性任务的响应	需预先设计所有分支，否则会出错	运行时自动判断条件并调整

一个延伸思考：工作流也有循环，但它和推理-行动循环一样吗？

        细心的读者可能会发现：工作流中的生成器-评估器模式也包含循环——生成器生成答案，评估器判断是否通过，不通过则反馈给生成器重新生成。

        这种循环和智能体中的推理-行动循环有什么区别？

        区别在于循环的驱动者：

        生成器-评估器：循环由外部代码驱动。生成器被调用à评估器做出判断à不满足条件à再次调用生成器。LLM在整个过程中没有“我该怎么做”的元认知，只是被动响应每一次调用。

        推理-行动循环：循环由LLM自身的推理驱动。LLM主动判断“当前信息够不够”和“下一步该做什么”，它是在执行一个决策序列，而不是被动响应外部调用。

        生成器-评估器是“试错循环”——错了再试，试到对为止，但试什么、怎么试由外部逻辑决定。推理-行动循环是“决策循环”——每一步自己判断状态、决定下一步行动。

五、小结

        通过天气助手这个案例，我们可以看到：

        工作流适合确定性高、步骤可预先定义的任务。当任务逻辑线性、没有条件分支时，工作流是更简单、更可控的选择；

        智能体适合需要根据中间结果动态调整的任务。当任务中存在“如果A则B，否则C”这类条件逻辑，且条件依赖运行时获取的信息时，智能体几乎是唯一的选择。

        但需要强调的是：智能体并非工作流的“升级版”。智能体带来了灵活性，也带来了不确定性——LLM的决策可能出错、可能陷入死循环、可能产生不可预测的行为。在实际落地中，更常见的做法是：能用工作流解决的问题，优先用工作流；只有工作流确实搞不定的场景，才引入智能体。

        下一篇文章，我将深入探讨智能体的内部架构——包括工具调用是如何实现的？LLM如何输出结构化的工具调用指令？推理-行动循环在生产环境中还需要哪些组件？敬请期待。

六、参考文献

1. Building effective agents. anthropic.com/engineering/building-effective-agents, 2024

2. Jiacheng Liu, Xiaohan Zhao, Xinyi Shang, Zhiqiang Shen. Dive into Claude Code: the design space of today’s and future AI agent system, 2026

作者：徐宏勤
版权声明：本文为原创内容。如需转载，请务必在文章开头标注作者和来源，并保持文章完整，否则视为侵权。