我的应用场景到底该用 Agent，还是 Workflow

最近，很多人开始把 LLM 接到自己的工作流里。

一开始，大家最熟悉的形态还是 chatbot。国外有 ChatGPT、Gemini，国内有 DeepSeek、Qwen。用起来也简单：打开一个对话框，把问题发过去，等模型回答。

chatbot 是最早跑通大规模商业应用的大模型产品形态。它满足的需求很直接：让人可以用自然语言和机器交流。

早期的 chatbot 主要负责文字问答，能写一段文案、解释一个概念、翻译一段内容，就已经足够惊艳。后来模型能力越来越强，工具调用、代码执行、联网检索、文件处理、多模态输入陆续变成常见能力，chatbot 也开始发生变化。

它开始从问答工具，变成任务执行的入口。

比如读一份文档，整理会议纪要，修改代码，调用 API，操作网页，甚至连续执行一个比较长的任务。到了这个阶段，chatbot 和 Agent 的边界就开始变得模糊。

但这也带来了一个新的问题：

我的应用场景到底应该做成 Agent，还是做成 Workflow？

这个问题比“我要不要用 AI”更具体，也更直接影响系统上线后的稳定性和成本。

先别急着上 Agent

LLM 落地到具体业务里，通常有两条路线：Workflow 和 Agent。

Workflow 的特点是流程相对固定。LLM、工具、业务逻辑都按预先设计好的步骤运行。模型可以参与判断、生成、提取、总结，但它什么时候被调用、调用什么工具、结果交给谁，基本由程序控制。

Agent 则把更多控制权交给模型。任务怎么往下走，主要由 LLM 决定。它会根据当前环境和反馈判断下一步做什么、调用什么工具、是否需要调整计划，以及什么时候结束任务。

Workflow 是程序在调度模型，Agent 是模型在调度程序。

真正的差别就在这里。

很多团队一看到 Agent 的演示，很容易想：既然模型已经能规划、能调用工具、能自己循环执行，那是不是所有复杂任务都应该直接交给 Agent？

我的看法正好相反。

多数场景应该先从 Workflow 开始。只有当 Workflow 明显不够用时，再考虑 Agent。

原因很简单：Workflow 更容易控制，也更容易验收。

业务系统里最怕的不是能力不够强，而是行为不稳定。一个系统今天能跑通，明天因为输入略有变化就换一条流程，后天又因为工具返回异常开始自我发挥，这些不确定性很快就会抵消 AI 带来的效率提升。

所以，判断一个场景该不该上 Agent，第一步不是问“这个任务复杂不复杂”，而是问：

这个任务能不能被稳定拆成一组相对固定的步骤？

如果可以，通常应该先做 Workflow。

Workflow 不是低配方案

很多人会下意识觉得 Workflow 不如 Agent 高级。好像 Workflow 只是传统自动化，Agent 才代表未来。

这个理解不太准确。

在工程系统里，确定性本来就是重要收益。只要业务路径可以被清晰描述，Workflow 往往比 Agent 更可靠、更便宜，也更容易排查问题。

常见的 Workflow 设计方法，已经足够支撑不少实际需求。

第一类是提示链。

也就是把任务拆成一组固定步骤，每一步调用一次 LLM，并把上一轮输出作为下一轮输入。比如先从用户需求中提取关键信息，再生成结构化方案，然后检查遗漏，最后输出成固定格式。

这种方式适合任务边界清晰、步骤顺序稳定的场景。它的好处是每一步的任务都更窄，模型不需要一次性记住全部要求，也方便在中间环节做校验。

第二类是路由处理。

先用一个分类器或者 LLM 判断输入属于哪一类，再分发到对应的处理链路。比如客服系统里，退款问题走退款流程，物流问题走物流流程，技术问题走工单流程。

路由的价值在于把复杂问题拆散。每条路径只处理自己覆盖的输入类型，提示词、工具权限、校验规则都可以单独设计。

第三类是并行化。

有些任务天然可以拆成多个互不依赖的子任务。比如分析一份产品反馈时，可以同时抽取用户痛点、功能建议、情绪倾向和竞品线索。也可以让模型多次生成不同候选答案，再用投票或评分机制选出更可靠的结果。

并行化适合两类情况：要么是为了提升速度，要么是为了从不同角度交叉检查，降低单次模型输出的偶然性。

第四类是指挥官模式。

一个 LLM 先负责拆解任务，生成子任务列表；再把子任务分给不同模型或工具链处理；最后由汇总环节整合结果。

它已经比普通 Workflow 更灵活，但仍然保留了比较明确的结构。适合那些目标明确、但子任务数量和内容不太固定的场景。比如调研一个技术选型，可能需要查资料、对比方案、整理风险、形成建议，这些子任务不一定每次完全相同，但仍然可以放在受控流程里。

第五类是生成-评估循环。

一个模型负责生成结果，另一个模型或者规则系统负责评估、打分、指出问题，然后再回到生成环节做修改。

这种方式适合有明确评估标准的任务。比如代码补全能不能通过测试，摘要是否覆盖关键事实，文案是否满足品牌语气，配置文件是否符合 schema。

这些都不是“简单方案”。相反，它们是在工程系统中使用 LLM 的成熟做法。

如果一个需求能用这些 Workflow 稳定解决，就没有必要急着把它做成 Agent。

什么时候 Workflow 不够用

当然，Workflow 不是万能的。

当任务路径高度开放，步骤数量无法提前确定，或者执行过程中必须根据环境反馈不断调整策略时，Workflow 的维护成本会迅速上升。

典型表现是：流程图越画越大，分支越来越多，异常处理越来越零散，提示词越来越长，最后系统维护成本比任务本身还高。

这时候就该认真考虑 Agent。

Agent 的核心不是“会聊天”，而是循环：

observe -> think -> act -> observe

它读取当前状态，决定下一步动作，调用工具或执行操作，再根据新反馈继续调整。这个循环让 Agent 能处理一些难以硬编码的开放性问题。

比如一个复杂的决策流程，里面有大量例外情况，需要结合上下文做判断。你可以把所有规则都写进 Workflow，但规则越写越多，系统就越容易因为例外情况失效。Agent 反而可以结合上下文和工具反馈，在一定范围内做更灵活的处理。

再比如制度规则非常细、变化又频繁，人工维护成本很高。企业内部的审批、合规、报销、采购，经常会出现大量“满足 A，但不满足 B，C 又属于例外”的情况。完全硬编码当然可以，但每次制度变化都要改流程，长期看未必划算。

还有一种常见场景是高度依赖非结构化数据。

比如阅读合同，分析邮件往来，从一堆文档里找证据，和用户多轮沟通后完成一次业务处理。这里的输入不是规整字段，而是自然语言、图片、附件、上下文和隐含意图。Workflow 可以处理其中一部分，但很难提前穷举所有路径。

在这些场景里，Agent 的优势会更明显。

它可以先读懂当前材料，再按反馈逐步调整计划：调用不同工具，发现错误后重试，必要时改变路径。换句话说，它适合解决那些“你无法提前写死每一步”的问题。

Agent 的代价是控制权

选择 Agent，意味着把一部分控制权交给模型。

这不是坏事，但这一点必须先说清楚。

Agent 越自主，团队越需要提前想清楚几个工程问题：

• 它可以调用哪些工具？
• 每个工具的权限边界是什么？
• 它最多可以循环多少轮？
• 什么情况下必须停下来问人？
• 工具调用失败后怎么恢复？
• 输出结果如何验证？
• 关键行为是否有日志可查？

如果这些问题没有设计清楚，Agent 很容易变成一个表面能跑、出了问题却很难定位和追责的自动化系统。

尤其是在生产系统里，答错只是风险的一部分；真正麻烦的是它执行了错误动作。

回答错一段话，用户可能还能识别。调用错一个接口、误删一份文件、把敏感信息发给不该访问的服务，后果就完全不同。

所以我并不建议把 Agent 当成 Workflow 的加强版，直接接进业务系统。它应该被看成一个能执行动作的系统组件，而且需要配套的权限、审计和防护机制。

为 Agent 添加防护机制

Agent 可以灵活，但不能无限自由。

更稳妥的做法是设计分层防护。

第一层是输入相关性判断。先判断用户请求是否属于当前系统的职责范围，不相关的请求直接拒绝或转交其他流程。

第二层是安全分类。涉及隐私、违法、越权、危险操作的请求，应该走更严格的流程，不能让 Agent 自己决定是否执行。

第三层是工具分级。读取、搜索、写入、支付、删除这些工具的风险等级完全不同。高风险工具应该要求更严格的参数校验、权限控制，必要时还要人工确认。

第四层是输出验证。Agent 生成的结果不能默认可信。结构化输出要过 schema，代码要跑测试，财务金额要做规则校验，面向用户的内容要做事实检查和合规检查。

第五层是日志和回放。一次 Agent 执行过程中，模型看到了什么、做了什么判断、调用了什么工具、工具返回了什么、最后为什么结束任务，都应该尽量留下记录。没有日志，就没有可靠的排障和责任边界。

这些机制会让系统看起来没那么“智能”，但也会让它更接近一个能在生产环境里运行的工程产品。

一个简单的选择标准

能用 Workflow 稳定解决的问题，不要急着上 Agent；当分支、异常和上下文复杂度让 Workflow 难以维护时，再引入 Agent。

这是一笔工程成本的账。

Agent 的价值在于处理不确定性。如果任务本身没有那么多不确定性，强行引入 Agent 反而会增加调试、验收和风控成本。

最后：选择的是自主权，不是概念

Agent 和 Workflow 不是谁替代谁的问题。

它们更像同一条轴上的两个端点：一端是确定路径、程序调度、强约束；另一端是动态规划、模型主导、适应性更强。

真实系统里，两种方式往往会混用。

外层用 Workflow 约束主流程，里面某些开放环节交给 Agent。或者 Agent 负责探索和规划，关键动作仍然回到 Workflow 里执行。再或者，日常任务用 Workflow 批量处理，只有异常情况才交给 Agent。

最终，我们选择的不是某个听起来更新的概念，而是把多少自主权交给模型，以及如何在工程系统里管住这些自主权。