关于行业 Agent 的思考：「行业 Workflow + Agent」的混合模式

过去一年，AI Agent 从狂热逐渐回归理性。在企业级应用和垂直行业落地中，我们看到了一个趋势：在行业中，纯粹依靠 Agent 自主决策的构想，正在被「Workflow + Agent」的混合模式所取代。

对于我们一线的同学来说，最重要的是要去解决实际问题。

当前我们能看到的行业 Agent 大多数实际落地的逻辑是：行业 Agent 的壁垒在于行业 Know-how，而落地的最佳路径是利用 Agent 做交互与分发，利用 Workflow 做执行与兜底。

1. 行业 Agent 是什么

很多人把 Agent 想象成一个全能的「超级员工」，指望给它一个模糊的目标（比如“帮我提升下季度销售额”），它就能自动拆解任务、调用工具、完成工作。在通用领域或简单场景下（如订机票、写周报），这或许可行。但在垂直行业（金融、制造、医疗、物流等），这种纯 Agent 模式目前是行不通的。

1.1 Agent 是交互方式，不是业务本身

Agent 在行业应用中的本质，是入口和交互。

它改变了人与系统的互动方式。以前我们需要点击菜单、填写表单、通过 SQL 查询数据库；现在我们可以通过自然语言表达意图。Agent 的核心价值在于它能“听懂”用户的意图，并将其转化为系统能理解的指令。

1.2. 真正的壁垒是行业 Know-how

大模型本身是通用的。GPT-5 或者是 Claude 4.5，它们具备的是通用的逻辑推理能力和语言能力，但它们不懂你们公司的复杂的审批流程，不懂某个特定设备的维修手册，也不懂行业内潜规则式的业务逻辑。

行业 Agent 的「行业」二字，才是重点。

  • 什么是 Know-how？ 是我们沉淀了十年的 SOP，是数据库里积累的边缘案例，是针对特定业务场景的异常处理机制。
  • Agent 的角色： 它是这些 Know-how 的「调度员」，而不是「创造者」。

如果脱离了行业 Know-how，Agent 就是一个会说话但办不成事的空壳。

2. 为什么「纯 Agent」模式在企业端走不通？

在 Demo 阶段，我们经常看到这样的演示：用户说一句话，Agent 自动规划了五个步骤，调用了三个 API，完美解决了问题。

但在生产环境中，这种全自动的「纯 Agent」模式面临三个无法回避的死结：

2.1 幻觉与确定性的冲突

企业级应用，尤其是涉及到资金、生产安全、合规的场景，稳定压倒一切。 大模型的本质是概率预测，这意味着它永远存在「幻觉」的可能性。哪怕准确率做到 99%，那剩下的 1% 的不可控对于企业核心流程来说也是灾难。

你无法向审计部门解释，为什么系统批准了一笔违规报销，仅仅因为 Agent 觉得「这看起来没问题」。

2.2 流程的黑盒化

纯 Agent 模式下，决策过程往往隐藏在模型的推理链中。当出现问题时，很难复盘和追责。企业需要的是可审计、可监控、可干预的流程。

2.3 成本与延迟

让大模型去规划每一个微小的步骤（比如“点击确认按钮”、“校验手机号格式”），是对算力的巨大浪费。这些确定性的逻辑，用传统的代码实现既快又准，用 LLM 去推理则是大炮打蚊子，且增加了响应延迟。

3. Workflow + Agent 的混合模式

既然大模型的幻觉无法根除，而传统软件的确定性又是刚需，最务实的方案就是将两者结合：Workflow + Agent。

这是一个“动静结合”的架构。

  • Workflow（工作流/RPA）： 负责“静”。它是骨架，是肌肉。它包含固定的业务逻辑、SOP、API 调用序列。它保证了核心流程的确定性和可靠性。
  • Agent（大模型）： 负责“动”。它是大脑，是神经。它负责理解非结构化的输入（自然语言），进行意图识别，然后决策应该触发哪一条 Workflow。

3.1 核心逻辑

Agent 不直接去操作底层数据库或核心系统，Agent 的输出对象是 Workflow。

  • 用户 -> 对话 -> Agent (理解意图/参数提取) -> 触发 -> Workflow (执行/校验) -> 返回结果 -> Agent (格式化输出) -> 用户

3.2 这种模式解决了什么问题？

  1. 复用历史沉淀： 企业过去十年建设的 ERP、CRM、以及各种自动化脚本（RPA），不需要推倒重来。它们被封装成一个个 Workflow，成为 Agent 的「工具箱」。
  2. 控制风险： 所有的执行动作（写库、转账、发货）都由 Workflow 控制，Workflow 内部包含严格的校验逻辑（If-Else），这是大模型无法绕过的硬规则。
  3. 降低成本： 只有在需要理解和决策的环节才消耗 Token，大量的执行环节由低成本的代码完成。

4. 如何设计混合模式

在具体落地时，我们需要构建一个分层的架构体系。

4.1 意图理解与分发

这是系统的入口。用户输入的往往是模糊的、非结构化的自然语言。 这一层的核心任务不是「解决问题」，而是「定义问题」。

  • 意图识别： 判断用户是想「查询库存」、「发起退款」还是「投诉建议」。
  • 参数提取： 从对话中提取执行 Workflow 所需的关键参数（如订单号、日期、金额）。如果参数缺失，Agent 需要反问用户进行补全。
  • 路由分发： 基于意图，将任务指派给具体的 Workflow 或下一级更专业的 Agent。

关键点： 这一层需要极强的语义理解能力，通常需要配合 RAG 来理解特定领域的术语。

4.2 动态决策与 RAG

在某些复杂场景下，直接映射到 Workflow 是不够的。 比如用户问：“我的设备报警代码是 E03，我该怎么办？”

这里不能直接触发一个“维修流程”，因为 Agent 首先需要知道 E03 代表什么。

  • RAG 的介入： Agent 调用知识库，检索 E03 对应的故障原因和处理手册。
  • 初步决策： 基于检索到的 Know-how，Agent 判断是建议用户重启（触发“重启指引 Workflow”），还是必须派人维修（触发“工单提交 Workflow”）。

关键点： RAG 在这里不仅仅是用来回答问题的，更是用来辅助 Agent 做路由决策的。

4.3 确定性执行（Workflow / RPA）

这是系统的执行层，也是“行业 Know-how”固化最深的地方。 这一层严禁幻觉。

  • 形式： 它可以是一个 API 接口，一个 Python 脚本，或者是一个复杂的 BPM（业务流程管理）实例，甚至是一个 RPA 机器人。
  • 逻辑： 这里面充满了 If-Else、Try-Catch 和数据库事务。
  • 反馈： Workflow 执行完毕后，必须返回明确的状态码和结果数据（JSON 格式），而不是一段模糊的文本。

4.4 结果综合与反馈

Workflow 返回的是结构化数据（例如：{"status": "success", "order_id": "12345", "delivery_date": "2023-12-01"}）。 Agent 的最后一步工作，是将这些冷冰冰的数据，转化为符合人类阅读习惯的自然语言，反馈给用户。

5. 多级 Agent 与 RAG 的协同

在简单的场景下，一个 Agent 配合几个 Workflow 就够了。但在复杂的行业场景（如供应链管理、大型设备运维）中，我们需要更复杂的拓扑结构。

5.1 多级 Agent 架构

不要试图训练一个全知全能的上帝 Agent。应该采用“主帅-将军-士兵”的层级结构。

  • L1 调度 Agent（主帅）： 只负责宏观分类。例如，判断是“售前咨询”还是“售后维修”。
  • L2 领域 Agent（将军）： 专注于特定领域。例如，“售后 Agent” 拥有查询保修、解读故障码、预约工程师的能力。
  • L3 执行单元（士兵）： 具体的 Workflow 或特定的单一功能 Agent。

这种结构的好处是解耦。当售后流程发生变化时，只需要调整 L2 Agent 和对应的 Workflow，不会影响到售前部分。

5.2 RAG 的逻辑化应用

传统的 RAG 主要是为了解决“回答知识性问题”。在混合模式中，RAG 的作用被放大了。

  • 动态 Prompt 注入： 在执行 Workflow 之前，系统可以根据当前的上下文，利用 RAG 从知识库中检索出相关的规则或注意事项，动态注入到 Agent 的 Prompt 中。

    • 例子： 在处理一笔“退款”请求时，RAG 检索到“该用户是 VIP 且信用极好”，将此信息注入 Prompt，Agent 可能会选择触发“极速退款 Workflow”而不是“常规审核 Workflow”。

6. 落地实战中的思考

在实施“行业 Workflow + Agent”模式时，有几个非技术性的坑需要注意。

6.1 人机协同

在很长一段时间内，Agent 不会完全取代人，而是成为人的 Copilot 在设计 Workflow 时，必须预留人工介入的节点。 当 Agent 的置信度低于某个阈值，或者 Workflow 执行遇到异常时，系统应自动升级为人工服务，并将之前的上下文完整传递给人工客服。

6.2 存量资产的价值

很多技术团队在做 AI 转型时，倾向于重构一切。这是错误的。 你们公司遗留的那些看起来陈旧的 API、跑了五年的定时脚本、甚至 Excel 里的宏，都是宝贵的资产。 Agent 的落地应当是「局部改造」而非「推倒重来」。 我们要做的，是给这些老旧的系统加上一个 AI 适配层，让 Agent 能够调用它们，而不是替换它们。

6.3 结构化数据的回流

Agent 与用户的交互过程，产生了大量高质量的数据。 不要让这些数据只停留在对话日志里。需要设计机制，将 Agent 收集到的信息（如用户的新需求、报错的高频词、Workflow 的执行结果）结构化地回流到业务系统中，用于优化 SOP 和微调模型。

7. 小结

行业 Agent 的未来，不是科幻电影里的全自动机器人，而是严谨的工程化实践。

我们不需要一个会写诗的 AI，我们需要的是一个能准确理解工单意图，并由后台的 Workflow 准确执行的系统。

  • Agent 是面子：提供极简的交互，理解复杂的意图。
  • Workflow 是里子：承载行业壁垒，保证执行的绝对可靠。
  • RAG 是底子：提供动态的上下文和知识支撑。

降本增效不是靠引入一个昂贵的大模型来实现的，而是靠大模型把过去那些难以被自动化的“非结构化需求”，转化为了可以被低成本代码执行的“结构化指令”。

这才是行业 Agent 的落地。