最近我也在思考 Workflow 和 Agent 到底什么关系，我的一个初步想法： Workflow 本质上是工具，只是工具中用到了 AI 能力，所有能被定义成 Work Flow 的就应该能被做成工具。 Agent 更像是 AI，它能主动规划、去调用工具，Workflow 应该是 Agent 的一个可以被调用的工具。 你怎么看？

之前在团队内讨论时写的一段话：Agentic 和 Workflow 不是非黑即白的开关，而是一个连续的光谱。我们的架构要提供可持续的迭代能力，从而在 LLM 能力足够的地方更自主化，在 LLM 还不太擅长的地方通过固定编排把专家经验固定下来，随着模型的进化可以低成本的替换节点实现逻辑。

现实中最靠谱的路径就是 agent 和 workflow 就是这种组合优化。 哪里擅长自动就让模型顶上，哪里风险高就继续靠规则兜底，这才是可持续演化的方式。 但也点出了未来智能系统架构的演进：以编排承载的经验最终会被模型逐步吞噬。

其实吧，workflow 才是 agent 的高级和成熟形式。 不要想着拿现在已有的workflow和agent来对比，都还处在不成熟的阶段。我描述的不是目前已有的场景。 这两者也没有什么取代关系，谁比谁更高级，但从原本的定义，以及我们人类解决问题的方式来讲，workflow就是我们以agent的形式横冲直撞，吃过无数亏总结出来的高效的面对一些特定问题的快速解法。 还是那句话，不要拿现有的我们人类编排的那些东西去看待未来的workflow，从复杂度和能力上都不是一个量级的东西。 我说的 workflow 是业务的高效解法，近乎最优解，无需试探，已经成熟的业务流程。 而这本来就是 agent 试图达到的目的。 也可以理解成，未来我们仍然需要专家系统，只不过他不再是我们需要手动精心的编排才能达到。我们很可能让大量的代理自己跑出这样的解法，并把这个解法固定下来，成为一个确定的工作流。 这个世界上的问题，有很多答案也是开放式的，但这并不影响他们中间有一些固定的范式、高效的解法，这些就是我理解的 workflow。

「Multi-Agent, Reasoning」论文 FlowReasoner: Reinforcing Query-Level Meta-Agents 轻云顺风即变，FlowReasoner 使 multi-agent workflow 随query应变于瞬息之间。 这篇论文十分精彩，作者瞄准“one system per user query”的目标：为每一条用户 query 即时推理出一个专属的multi-agent 工作流（one workflow per query）。 首先什么是 workflow ？ 在 Code Interpreter 场景下，不同 agent 各司其职，例如： Code Generator：生成候选代码 Ensemble：整合多路候选 Review：静态审查 Revise：依据反馈重写 Code Test：执行单元测试并返回结果 在工程实践中，我们会排列组合上述agent任务，形成工作流workflow，如以下几种： Generate → Test ： G → T Generate → Test ↻ Revise ： G → T → (Revise → T)… Generate → Review → Revise： G → Review → Revise Ensemble： G₁,G₂,G₃ → Ensemble 不同的workflow使用于不同的task，例如G → T适合最简单的边界清晰的函数级算法题，而Generate → Test ↻ Revise适合容易漏掉边界条件或有隐藏 corner case 的任务。 传统 multi‑agent workflow 往往是task‑specific的，需要工程师手动搭建，很难跟随用户的 query 实时调整。FlowReasoner 通过 推理 SFT + GRPO 强化学习，让模型学会根据执行反馈动态改写 workflow： Reasoning SFT：用 DeepSeek‑R1‑671B 生成的 1 400 条“推理‑工作流”示例微调 Distill‑Qwen‑7B/14B。 GRPO RL：在真实执行环境中，用 Pass@1、AST 复杂度、Distinctness 等多目标奖励逐轮优化推理链。 值得注意的是，FlowReasoner仅适用“code‑Interpreter”场景，因为它们依赖 Python 执行和单元测试。 也就是说，workflow泛化了，但仅在定义的具体场景中泛化。跨场景迁移时，必须重选/新建agent 任务，并为每个agent绑定相应的外部工具与奖励信号。 但依然非常一颗赛艇！ FlowReasoner 的方法，其实可以把multi-agent workflow泛化迁移到检索、数据分析、多模态等更广阔的领域。

以让agent买机票为例， 一个正常的流程是，用户跟agent说你帮我订一张下周五去London，下下周三返回的经济舱，直飞机票。 主agent收到后，首先像一堆agent 发消息，谁能查票？ 一堆agent返回说，我我我。 主agent把消息扔给说可以查票的agent。 然后等各家回消息。 主agent按照一定规则过滤排序了一堆行程。最好选了一个。 然后主agent再给一对子agent问你们谁能出票？是jcb的卡，要发票。 然后一堆子agent又去问孙agent，你们能支持jcb的卡。 然后一层一层agent配合起来，把一个任务完成。最后主agent把票的信息推给主人。 agent之间是相互调用协同操作。 但是主agent的这些query和执行就是一套workflow。

在这里不能讨论 狭义or前LLM时代workflow：定义死的一段流程，和agent差别很大。 但后llm时代这俩可难以分清了。 虽然@宝玉 提到的根据anthropic定义，一个是定义好的流程中用到agent，一个是让agent自由发挥。 但 @马东锡 NLP 提到论文的论文里最重要的一个：针对每个query即时定制一个workflow，这恐怕也能算agent的自由发挥。 我觉得workflow迟早会内化进agent的概念里。

试着以回答一组问题的方式，来阐述对agent/workflow的看法。缘起是这个 https://x.com/eraera/status/1949902260785598475… 问题1.文档的目的是什么。文档是人类的外存，很多文档都有记录当前状态的功能，相当多的文档还包括执行指令，也就是从当前状态迁移到下一个状态的指令。

非常棒的讨论。必须要mark。 agent和workflow并不互斥，可以并存，我倾向于是嵌套的关系，agent>workflow，确定性的、经常重复的过程可以固化下来成为workflow，为agent解决问题所用。 我觉得随着llm的生成能力的提升，完全可以由agent来生成workflow。类似flowreasoner的方向。 本质上有点类似现在LLM的混合走向，在自然语言预训练的LLM中通过RL发展形式规则语言能力如coding、math。 这和人类使用语言的演化过程一样。