目标：读完本文后，读者应该能够把任何一个 Agent 还原为“观察—决策—行动—反馈”的运行循环，并根据这条循环解释它为什么有效、为什么失败，以及外围工程组件解决了什么问题。
引言#
loop 是我们在编程语言中最熟悉的结构，在学习 C 语言的第一周就接触到了 for 和 while 循环。在 AI 应用的领域，我们也使用循环的结构。比如在 Dify 中把几个节点练成一个圈，它有循环，有状态，也会根据上一轮结果调整下一轮行为。
但它被叫做 workflow 而不是 agent，它和 Claude Code、Codex、Pi 里的 agent loop 到底有什么区别？
在过去的几年间，我们使用各种方法来增强大模型的能力，比如推理（CoT）、使用工具（Toolformer）、观察环境（WebGPT）以及它们的结合（ReAct）。
这些思路开创性使得它们在各类型 AI 工程中被广泛的使用，所以是否存在一个推理、行动和观察的循环，并不是区分 workflow 和 agent 的依据。
我认为两者的区别：是在每一轮结束后，谁决定下一步做什么？
完全固定的 Workflow ↓ 带条件和反馈的 Workflow ↓ LLM 动态路由的 Workflow ↓ 局部包含 Agent 的 Workflow ↓ 模型主导行动顺序的 Agent
这条连续谱描述的不是系统越来越“先进”，而是运行时控制权逐渐从开发者预先定义的流程，转移到了模型。
从 workflow 到 agent#
在传统 Workflow 中，开发者提前规定了状态之间的转换关系。流程可以是线性的：
输入 → 检索 → 总结 → 输出
也可以带有分支和循环：
生成报告 → 评分 → 不合格则重新生成 → 合格后输出
后一种结构已经形成了反馈闭环。前一轮的评分结果会影响后续执行，系统也会保存报告、分数和轮次等状态。但它仍然是 Workflow，因为反馈能够触发的行为已经被开发者提前限定：
评分合格 → 结束 评分不合格 → 返回生成节点
即使评分由 LLM 完成，也没有改变这一点。LLM 在这里承担的是评价器，而不是流程控制器。它决定某个预设条件是否成立，却没有决定“不合格之后具体应该做什么”。系统获得了语义判断能力，但状态转换规则仍然存在于流程图中。
当 LLM 被用于路由时，控制权开始发生转移。例如，模型可以根据用户请求，在搜索、写作和数据分析三条流程中选择一条：
用户请求 → LLM 判断 ├─ 搜索流程 ├─ 写作流程 └─ 数据分析流程
这已经不同于显式的 if-else。模型可以理解难以预先形式化的语义条件，从固定选项中选择下一步。但这种控制权仍然是局部的：可选路径由开发者提供，每条路径内部如何运行也已经确定。模型只是决定“进入哪条路”，而不是持续决定“接下来做什么”。
进一步地，Workflow 中可以嵌入一个 Agent 节点：
数据预处理 → Agent 执行研究 → 结果校验 → 格式化输出
外层流程仍然固定，但 Agent 节点内部的行动顺序无法提前确定。模型可能先搜索资料，也可能先阅读已有文件；搜索结果不足时可以修改关键词，发现事实冲突时可以交叉验证，工具失败时还可以更换策略。此时，系统中同时存在两种控制结构：
外层 Workflow： 开发者规定 Agent 在哪里开始、输入什么、何时返回
内层 Agent Loop： 模型根据每一轮反馈决定下一步行动
这类混合结构在实际系统中很常见。确定性高、适合明确表达的部分交给 Workflow；难以穷举、需要根据环境不断调整的局部任务交给 Agent。Workflow 和 Agent 并不总是互相替代，它们也可以处于不同层级。
典型的 Agent Loop 出现在模型的行动选择权能够跨多轮反馈持续存在时：
当前目标与状态 → 模型选择行动 → Runtime 执行工具 → 环境返回 Observation → 状态更新 → 模型重新选择行动
这里的关键不是模型做了一次判断，而是它在每次环境反馈之后都重新获得控制权。它可以改变工具顺序、重复某一步、放弃原有假设、选择新的搜索方向，也可以判断任务已经完成。具体执行路径不再完整地存在于流程图中，而是在运行期间逐步生成。
因此，可以把几种结构写成不同的状态转移方式：
固定 Workflow： next_step = predefined_edge(current_node)
条件 Workflow： next_step = predefined_rule(state)
LLM 路由 Workflow： next_step = model_choose(state, predefined_options)
Agent Loop： next_action = model(goal, state, available_actions)
前三种结构中，开发者提前定义了节点或候选路径；到了 Agent Loop，开发者主要定义的是目标、行动空间和边界，模型则根据当前状态生成具体轨迹。
这也解释了为什么“Dify 中把节点连成一个圈”不等于 Agent Loop。图上的圆环只表示控制流会回到此前节点。它可能仍然只是：
生成 → 评分 → 不合格 → 重新生成
每次循环都沿着同一条预定义路径执行。而 Agent Loop 中的“环”并不主要画在节点之间，而存在于状态、行动和反馈之间：
状态 → 决策 → 行动 → Observation → 新状态
前一次行动的结果不仅决定“是否再来一轮”，还会影响下一轮究竟采取什么行动。
以深度研究为例，如果流程是：
搜索资料 → 生成报告 → LLM 评分 → 不合格则重新运行同一套研究流程
它仍然主要是 Evaluator–Optimizer Workflow。评分器拥有是否通过的判断权，但没有持续的行动选择权。
如果评分不通过之后，模型能够根据具体缺口决定：
补充最新数据 验证某条事实 扩大搜索范围 缩小研究问题 寻找反方证据 修改报告结构
并在每次行动后重新观察结果、调整策略，那么研究过程内部就形成了 Agent Loop。
所以 Workflow 和 Agent 之间最值得观察的，不是有没有 LLM、工具、条件或循环，而是三件事：
控制范围： 模型只决定一个节点，还是控制整个局部任务？
控制持续性： 模型只判断一次，还是在每轮反馈后重新决策？
行动开放度： 模型只能选择预设路径，还是可以组合工具形成运行时轨迹？
这三者共同决定一个系统更接近固定 Workflow、Agentic Workflow，还是模型主导的 Agent。
从这个角度看，Agent Loop 可以被定义为：
模型在一个受限的行动空间中，根据目标和不断变化的当前状态，跨多轮环境反馈持续生成下一步行动的运行结构。
Loop 提供持续性，Observation 使它形成闭环，而模型对下一步行动的持续选择，才使这个闭环获得 Agent 式的动态控制。
循环中信息如何流动 → 循环如何被控制 → 循环如何结束与延续
Next Reads