三种 AI Workflow 架构：从纯 Agent 到 Workflow + LLM 的取舍

当我们把 AI 引入工程流程时，真正难的问题往往不是“要不要用 Agent”，而是“Agent 应该拥有多大的自由度”。自由度越高，系统越像一个能自我判断和自我修复的智能体；自由度越低，系统越像一个稳定、可控、成本明确的自动化流水线。

因此，AI Workflow 的架构设计，本质上是在三个目标之间做权衡：智能性、稳定性和成本。

本文把常见方案拆成三类：纯 Agent、Workflow 脚本 + 节点 Agent、Workflow + LLM。它们不是谁更先进的问题，而是分别适合不同的不确定性等级。

一、纯 Agent：把流程交给智能体自主推进

纯 Agent 架构的核心思路是：把 Workflow 写成 skill 或规则说明，由 Agent 自主理解目标、拆解阶段、调用工具、检查结果，并决定下一步行动。

在这种模式下，Workflow 不再是一个硬编码状态机，而更像是一组可被 Agent 使用的操作规范。Agent 既负责执行，也负责判断当前处于哪个阶段，以及是否需要回退、修复或补充信息。

优点

纯 Agent 最大的优势是自由度高。

当任务本身不确定、阶段产物也不稳定时，提前写死流程反而会限制系统能力。Agent 可以根据执行过程中的观察结果动态调整路径，比如发现页面异常后主动排查原因，发现测试失败后继续定位代码，或者在缺少上下文时自行检索和补全信息。

这种模式也更容易形成“自我进化”的闭环。Agent 可以在执行中归纳问题、沉淀经验，把常见错误、修复方式、工具使用方法更新到 skill 或知识库里。对于变化快、问题形态分散的场景，这一点很有价值。

缺点

纯 Agent 的代价同样明显。

首先是成本高。流程编排、外部环境探索、问题排查、修复验证都会消耗大量 token。尤其当 Agent 需要频繁读取页面、日志、代码和历史上下文时，成本会快速放大。

其次是不稳定。Agent 可能陷入无效探索，也可能错误判断任务阶段，甚至在长时间运行中因为上下文膨胀而偏离目标。因此纯 Agent 往往需要额外的兜底机制，例如 cron、watchdog、超时中断、阶段性检查点等。

最后是长任务不友好。一个任务执行时间越长，上下文越容易爆炸。上下文过大不仅增加成本，也会降低模型对关键状态的把握能力。

适用场景

纯 Agent 更适合短周期、高不确定性的任务。

典型例子包括 Bug 排查、D2C 还原、复杂页面问题定位等。这类任务的阶段边界往往不清晰，产物也不完全固定，需要 Agent 根据外部反馈不断调整策略。

如果一个任务需要大量主观判断，并且执行周期不长，纯 Agent 是合理选择；如果任务周期很长、状态很多、结果要求稳定，就需要引入更强的流程控制。

二、Workflow 脚本 + 节点 Agent：流程由系统控制，判断交给 Agent

第二种架构是折中方案：主流程由 Workflow 脚本管理，每个阶段由一个或多个节点 Agent 执行。

在这种模式下，Workflow 负责推进状态机，例如“需求分析 -> 页面访问 -> 代码修改 -> 验证 -> 发布”。Agent 只在具体节点中发挥智能能力，比如根据上一个阶段的产物继续分析、访问页面、修改代码或处理异常。

优点

这种架构保留了 Agent 的灵活性，同时显著降低了系统不可控性。

流程推进由 Workflow 管理，客观、重复、固定的部分可以用脚本完成。例如文件准备、状态记录、产物落盘、重试策略、通知机制、阶段切换等都不需要消耗模型上下文。

成本也会明显下降。相比纯 Agent，脚本承担了编排职责，Agent 只处理真正需要智能判断的节点。这样既减少 token 消耗，也降低了 Agent 在长任务中迷失方向的概率。

稳定性也更好。Workflow 可以维护清晰的状态机，并通过 watchdog 定期检查状态。如果某个阶段长时间没有更新，就可以判断节点 Agent 可能异常，再通过提醒、重试或中断来推动流程继续。

另一个重要优势是支持长时间任务。每个阶段可以是独立 session，阶段产物落盘后再进入下一阶段，避免把所有上下文都塞进同一个对话里。

缺点

这种模式要求阶段产物和主流程相对明确。

如果连任务应该分成哪些阶段都无法判断，或者阶段之间没有稳定的输入输出，那么 Workflow 脚本会变得很难设计。脚本越想覆盖不确定性，就越容易膨胀成复杂且脆弱的状态机。

同时，要让这种架构既稳定又低成本，需要认真做上下文管理。哪些信息要进入 Agent 上下文，哪些信息只需要作为文件引用，哪些状态应由脚本保存，都需要提前设计。

适用场景

这种架构适合“阶段明确，但阶段内部需要智能探索”的任务。

例如 D2C 和 Framer 迁移。整体流程可以被拆解为页面抓取、结构分析、代码生成、样式修复、浏览器验证等阶段；但每个阶段内部仍然需要 Agent 使用 Playwright、读取 DOM、观察截图、定位差异并做判断。

如果任务既需要 Agent 处理开放问题，又需要长时间稳定执行，这通常是最均衡的方案。

三、Workflow + LLM：流程和产物都由脚本管理

第三种架构进一步降低 Agent 自由度：Workflow 不仅管理流程，还负责拼接上下文、调用 LLM、解析回复，并把结果落地成固定产物。

这里的 LLM 更像一个文本生成或判断函数。它不直接操作工具，不主动探索外部环境，也不决定流程走向。系统给它明确输入，它返回明确输出。

优点

这种模式的成本最低。

由于不需要 system prompt、工具描述、长链路上下文和多轮探索，LLM 调用可以非常轻量。脚本负责控制输入输出，也避免了 Agent 在工具调用中产生额外成本。

稳定性也最高。流程、产物格式、校验规则都由代码控制，LLM 只负责回答问题或生成内容。系统可以对输出做结构化校验，不符合要求就重试或降级。

安全性也更强。因为 LLM 没有工具权限，无法直接修改文件、访问外部系统或执行危险操作。它只能在限定上下文中给出结果。

缺点

这种模式的前提是流程必须非常明确，产物也必须相对固定。

如果任务需要大量主观判断，或者需要根据外部环境动态探索，Workflow + LLM 就会显得僵硬。它不会主动发现异常，也不会自己调整策略。

此外，系统不会自然进化。产物质量主要依赖人工编写的 prompt、模板和规则。如果想提升效果，通常需要工程师持续优化 prompt 和数据处理逻辑。

适用场景

Workflow + LLM 适合流程完全固定、输入输出清晰、不需要 Agent 主观判断的场景。

比如 PSEO 内容生成。系统可以固定关键词、标题、结构、参考资料和输出格式，LLM 只负责在约束内生成内容。此时使用 Agent 反而会增加成本和不确定性。

如何选择：看任务的不确定性

选择架构时，可以先问三个问题。

第一，任务阶段是否明确？如果阶段不明确，优先考虑纯 Agent；如果阶段明确，可以用 Workflow 管理主流程。

第二，阶段内部是否需要探索？如果需要访问页面、读取日志、运行工具、根据反馈修复问题，就适合使用节点 Agent；如果不需要探索，只是生成固定产物，则 Workflow + LLM 更合适。

第三，任务是否需要长时间运行？如果任务时间长，就不应该把所有上下文压进一个 Agent session。更稳妥的方式是让 Workflow 保存状态，让 Agent 只处理单个阶段。

可以把三种方案理解为一个光谱：

结语

AI Workflow 架构没有唯一最优解，只有和任务不确定性匹配的解。

当任务需要开放探索时，给 Agent 更多自由度；当流程变长、状态变多时，用 Workflow 接管编排；当输入输出足够固定时，把 LLM 降级为一个可控的生成函数。

真正稳定的 AI 系统，不是把所有事情都交给 Agent，而是清楚知道哪些部分需要智能，哪些部分应该由工程系统兜底。