关于行业 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 的落地。

聊下 AI Agent 的上下文记忆和遗忘

最近 DeepSeek 的 OCR 论文里有个有趣的想法：用光学压缩来模拟人类的记忆遗忘机制。

这个思路很巧妙。他们注意到人类记忆和视觉感知都有个共同特点：距离越远，信息越模糊。一小时前的事记得清楚，一年前的事几乎忘光；10 厘米的东西看得清楚，20 米外的东西就模糊了。

DeepSeek 把这个生物学现象转化成了工程实现：近期对话用高分辨率保存，一周前的对话降到中等分辨率，久远的记忆压缩到最小。信息随时间自然衰减，就像人类遗忘一样。

这让我想到 Agent 记忆系统设计的本质问题。

1. 为什么 Agent 需要记忆

上下文窗口和记忆是两码事。

上下文窗口只是让模型一次看到更多对话，像是扩大了工作台。但记忆不同，它让 Agent 能保存、更新和选择性回忆信息。没有记忆，Agent 就像得了失忆症，每次对话都从零开始。

现在大家都在追求更大的上下文窗口，从 8K 到 32K，再到 128K、1M。但这种暴力扩张有个问题：计算成本呈二次方增长。处理 100K tokens 的成本是 10K tokens 的百倍。而且，把所有信息一股脑塞给模型，反而可能让它迷失在细节中。

记忆系统的价值在于选择性保留。

不是所有信息都值得记住，也不是所有信息都需要同样的精度。

2. Agent 记忆的层次结构

AI Agent 的记忆系统可以分成几个层次：

短期记忆（工作记忆）
这是 Agent 的记事本，保存当前对话和正在处理的任务。典型容量在几千到几万 tokens。没有它，Agent 会在对话中途失去思路，问你刚才说了什么。

长期记忆
这是跨会话的持久化存储。用户下次回来，Agent 还记得之前的交互。长期记忆又可以细分：

  • 事实记忆：保存确定的信息，比如用户姓名、偏好、角色定义。这些信息需要随情况更新，保持”当前真实状况”。
  • 情景记忆：记录具体经历，什么时候发生了什么，结果如何。这给 Agent 一种时间连续感，能回顾过去的决策。
  • 语义记忆：组织概念和关系的知识网络。让 Agent 理解”数据库慢”和”查询延迟高”是相关问题。

3. 遗忘机制是有用的

人类会遗忘，不是大脑容量不够，而是遗忘让我们更高效。

想象一下，如果你记得生活中的每个细节：每顿饭的味道、每次呼吸的感觉、路过的每个行人的脸。这些信息会淹没真正重要的记忆。遗忘是一种过滤机制，帮我们保留有价值的信息。

Agent 也需要这种机制。随着交互增加，历史数据会无限增长。如果不加选择地保存所有内容，会面临几个问题：

  1. 存储成本：每个用户的历史数据都完整保存，存储需求会爆炸式增长。
  2. 检索效率：在海量历史中找到相关信息越来越慢。
  3. 注意力分散：太多无关信息会干扰 Agent 的决策。
  4. 隐私风险：永久保存所有对话增加了数据泄露的风险。

4. 用分辨率模拟时间衰减

DeepSeek 的做法是：把历史对话渲染成图像，然后用不同的分辨率来编码。

近期对话用高分辨率（Gundam 模式，800+ tokens），保留完整细节。

一周前的对话用中等分辨率（Base 模式，256 tokens），保留主要内容。

久远的历史用低分辨率（Tiny 模式，64 tokens），只留个大概印象。

这样做的好处是：

  1. 不需要丢弃历史信息，所有对话都保留着
  2. 但远期信息自然”淡化”，占用的 token 越来越少
  3. 模拟了人类记忆的衰减曲线

具体实现上，他们会：

  1. 把超过一定长度的历史对话渲染成图像
  2. 第一次压缩，让 token 减少 10 倍
  3. 上下文再次超长时，进一步降低分辨率，再压缩 10 倍
  4. 随着时间推移，图像越来越小，内容越来越模糊，模型也就逐渐”读不清”了

这种方式不是简单的截断或删除，而是让信息随时间衰减——就像人类记忆一样。

5. 理论上无限的上下文

如果这个思路走通了，就能实现”理论上无限的 context window”。

这里的无限不是真的无限，而是通过分层压缩，让历史信息的存储成本趋近于常数。

我们不需要保持所有信息的高保真度，只需要让信息按重要性和时效性衰减。

最近的对话，全保留。
一周前的，压缩一次。
一个月前的，再压缩一次。
半年前的，只留个印象。

这样，计算资源始终聚焦在最重要的”近期”信息上，而久远的历史虽然还在，但只占用很少的 token。

从成本角度看，这比无脑扩大上下文窗口要合理得多。

6. 记忆管理的工程实践

在实际的 Agent 系统里，记忆管理通常分几个层次：

会话级记忆——当前对话的上下文，存在内存里，对话结束就清空。这部分可以直接用模型的上下文窗口。

用户级记忆——持久化存储，用向量数据库或 KV 存储。每次对话时，根据当前问题检索相关的历史记忆，注入到 prompt 里。

全局知识库——所有用户共享的知识，比如产品文档、技术规范、FAQ。这部分通常用 RAG（检索增强生成）来处理。

关键是如何在这些层次之间做好信息流转和优先级管理。

比如，用户刚说过的话，优先级最高，直接放在 prompt 前面。一周前的对话，需要检索后才注入。一个月前的，可能只保留摘要。

这种分层策略，和 DeepSeek 的分辨率衰减思路是一致的——让资源消耗和信息重要性成正比。

7. 遗忘不是丢失

这里需要明确的是，遗忘不等于删除。

人类的遗忘，是提取变难了，不是信息消失了。在特定的提示下，很多”遗忘”的记忆还能被唤起。

Agent 的记忆也应该这样设计。

低分辨率的历史对话，在大部分场景下不会被激活，但如果用户明确提到某个时间点的事情，系统可以重新加载那段历史的高分辨率版本。

这需要一个索引机制，能根据时间、主题、关键词快速定位到历史片段。

像 Manus 所使用的文件系统就是这样一种索引机制。

遗忘是常态，召回是特例。这样才能在效率和完整性之间找到平衡。

8. 什么值得记住

并不是所有对话都需要长期保存。

大量的对话是重复的、临时的、没有上下文依赖的。比如简单的问候、重复的确认、无关紧要的闲聊。

这些内容可以在会话结束后直接丢弃，不需要进入长期记忆。

真正值得记住的，是那些包含决策、偏好、关键信息的交互。

比如：

  • 用户明确表达的需求和偏好
  • 重要的决策节点和原因
  • 反复出现的问题和解决方案
  • 用户的角色、职责、技术栈等基础信息

这需要在记忆写入时做判断和过滤。可以用一个小模型或规则引擎，评估每轮对话的重要性，决定是否持久化。 Gemini Code 就是这么干的。

不是所有东西都值得记住，筛选本身就是一种优化。

9. 记忆的更新和冲突

长期记忆不是只写不改的日志，它需要能更新。

用户的偏好会变，角色会变，之前的信息可能过时或错误。

比如用户之前说喜欢中古风的家具，后来又说喜欢北欧风，这个信息需要更新，而不是简单地追加一条新记录。

如果只追加不更新，记忆会越来越冗余，甚至出现矛盾。

一个好的记忆系统，需要能识别冲突，做合并和覆盖。

这可以通过实体识别和关系抽取来实现。把对话内容结构化成三元组（主体-关系-客体），然后在写入时检查是否和已有记忆冲突。

如果冲突，可以根据时间戳、置信度等因素决定是更新还是保留多个版本。

记忆管理的复杂度，不亚于写一个小型数据库。

10. 压缩不只是技术问题

回到 DeepSeek 的光学压缩思路，它的价值不只是技术实现，更重要的是提供了一个思维框架。

我们习惯于把上下文长度当作硬指标——越长越好。但这个论文提醒我们，长度和质量不是一回事。

有时候，适度的遗忘反而能提升系统的整体表现。

有如下的好处：

  1. 减少了无关信息的干扰
  2. 降低了计算成本
  3. 让模型专注于最相关的内容

这和人类的认知机制是一致的。我们不会带着所有历史记忆去做每一个决策，而是根据当前情境激活最相关的那部分。

Agent 应该学会做同样的事。

11. 成本和效果的平衡

从成本角度看，无限扩展上下文是不可持续的。

假设一个 Agent 系统，每天处理 1000 次对话，每次对话平均 10 轮，每轮 500 tokens。

如果所有历史对话都全量保留，一个月下来，单个用户的上下文就会达到 1500k tokens。

如果有 1000 个活跃用户，每次推理都带上完整上下文，token 消耗会是天文数字。

但如果用分层记忆 + 遗忘机制：

  • 最近 3 天的对话，全保留
  • 一周到一个月的，压缩 50%
  • 一个月以上的，压缩 90%

token 消耗可能降低到原来的 10%-20%，而对实际效果的影响很小。

因为大部分场景下，用户关心的就是最近的对话。

12. 记忆应该是系统能力

很多团队把记忆功能当作一个独立的我来开发——加个数据库，存一下历史，检索一下注入。

但这样做的效果往往不好。

因为记忆不是一个功能模块，而是整个 Agent 系统的底层能力。

它需要和 prompt 设计、工具调用、推理链路、错误处理深度集成。

比如：

  • Prompt 需要为记忆预留位置和格式
  • 工具调用的结果需要写回记忆
  • 推理过程中需要动态检索记忆
  • 错误发生时需要回溯历史上下文

记忆管理做得好，Agent 的整体表现会有质的提升。做得不好，就只是一个会话机器人。

13. 一些建议

以下是一些可以尝试落地的建议：

1. 不要把所有历史都塞进 prompt

很多团队的做法是，每次调用都把所有历史对话拼接到 prompt 里。这在对话轮数少的时候没问题，但规模上去后会成为瓶颈。

改成检索式注入——根据当前问题，从历史记忆里检索最相关的几条，而不是全量加载。（这里就会考量检索的能力了）

2. 区分会话记忆和持久记忆

当前对话的上下文，存在内存里就行，不需要持久化。

只有那些需要跨会话保留的信息，才写入数据库。

这样可以大幅减少存储和检索的开销。

3. 给记忆加上过期时间

就像缓存一样，记忆也可以有 TTL（Time To Live）。

一般性的对话，可以设置 7 天或 30 天过期。重要的信息，可以标记为永久保留。

定期清理过期记忆，防止数据无限膨胀。

4. 用好向量数据库

向量检索是目前最适合做语义记忆的技术。

把历史对话做 embedding，存到向量数据库里，每次根据当前问题做相似度检索。

但要注意，向量检索的召回率不是 100%，需要结合关键词索引和时间过滤。

5. 记忆要能解释

用户问”你为什么这么回答”，Agent 应该能说清楚是基于哪段历史记忆做的判断。

这需要在记忆检索时保留溯源信息——这条记忆来自什么时间、什么对话、可信度如何。

可解释性不仅是用户体验问题，也是调试和优化的基础。

14. 最后

上下文记忆和遗忘，本质上是资源分配问题。

我们只有有限的 token 预算，有限的计算资源，有限的响应时间，需要在这些约束下做出最优决策。

无限扩展上下文听起来很美好,但实际上不可行。

真正的解决方案，是学习人类的记忆机制——让重要的信息留下来，让次要的信息自然衰减。

DeepSeek 的光学压缩思路提供了一个很好的启发：遗忘不是缺陷，而是一种优化策略。

如果能把这个思路落地到 Agent 系统里，不仅能降低成本，还能提升整体的智能水平。

因为真正的智能，不是记住所有东西，而是知道什么值得记住，什么可以忘记。

关于 AI Agent 的思考：大模型边界和工作流

最近在体验一些 AI Agent 的产品，有一个比较感受：大多数的 AI Agent 最终都是一个或多个工作流，原本我们想象的那种完全自主、能够独立思考和决策的 AI Agent 很少。

从而也就无法看到一句话就完成所有的事情，需要有专业的人在旁边盯着。

甚至出现了一个新的名词：大模型善后工程师

并且那种自动多的 AI Agent ，面对的大多数是对于幻觉，有一定容错的场景，如自动化报告生成，陪伴语聊。

那些无法容错的场景， AI Agent 就必须要人工审核或者带审计的工作流来完成。

为什么在准确性要求比较高的 AI Agent 都变成了工作流？

看一下我们常见的 AI Agent 逻辑：

收到用户输入 → 判断意图 → 调用对应的模块 → 整理输出 → 返回结果

这跟我们想象中的 Agent 差距很大。理想中的 Agent 应该像一个真正的助手，能理解复杂的需求，自主规划执行路径，遇到问题能灵活调整策略。但现实是，大部分产品都在用固定的流程来约束 AI 的行为。

为什么会这样？核心原因是大模型本身的特性决定的。

大模型的能力边界在哪里

大模型确实很强大，但它有明确的能力边界。

第一个边界是可靠性。大模型的输出本质上是概率分布，每次生成都有不确定性。同样的输入，可能得到不同的输出。这种不确定性在聊天场景下可以接受，但在准确率要求比较高的生产环境中就是个大问题。比如一个财务报表分析的 Agent，我们是无法接受它今天说利润率是 15%，明天又说是 18%。

第二个边界是准确性。大模型的训练数据是有截止时间的，而且它没有实时获取信息的能力。更重要的是，它会产生幻觉——看起来很有道理，但实际上是错的。一个合同审核的 AI Agent，引用了一条根本不存在的法律条款，差点出事。

第三个边界是执行能力。大模型本质上是一个文本生成器，它不能直接操作系统、调用 API、访问数据库。所有这些能力都需要额外的工程实现。而一旦涉及到外部系统的调用，就必须有明确的权限控制和错误处理，这又把我们拉回到工作流的思路上。

第四个边界是成本。完全放开让大模型自主决策，意味着大量的 token 消耗。一个复杂任务可能需要多次推理、多次调用，成本会急剧上升。在我们做 AI Agent 之初，成本问题就是一个要着重考虑的问题。我最近用得比较多的编程 Agent，就因为成本问题，把之前的收费逻辑做了颠覆式的变化，作为一个用户，最直观的感受就是费用暴增。

使用工作流是一种现实

面对这些边界，工作流成了一个自然的选择。

工作流解决了可控性问题。通过预设的流程，我们能确保 AI 的行为在可控范围内。每一步该做什么、不该做什么，都有明确的定义。这对企业应用来说至关重要。没有哪个企业敢把关键业务交给一个完全不可控的系统。

工作流解决了准确性问题。在工作流的每个节点，我们可以加入验证和校准机制。比如在数据查询环节，直接调用数据库而不是让大模型猜测；在关键决策点，加入人工审核环节。这样既利用了大模型的能力，又避免了它的短板。

工作流还解决了成本问题。通过流程优化，我们可以精确控制大模型的调用次数和方式。简单的任务用小模型或规则引擎处理，复杂的任务才调用大模型。这种分层处理大大降低了运营成本。

更重要的是，工作流让产品可以迭代优化。每个环节的表现都可以监控和改进，哪里出问题就改哪里，而不是面对一个黑盒束手无策。

如何设计一个好的工作流 Agent

既然工作流是当前的现实，那怎么设计一个好的工作流 Agent？

  1. 任务拆解。把复杂的任务拆解成多个简单、明确的子任务。每个子任务都有清晰的输入输出定义。比如一个智能客服 Agent，可以拆解为：意图识别、信息提取、知识检索、答案生成、对话管理等模块。
  2. 模块化设计。每个模块独立开发和优化，通过标准接口连接。这样的好处是可以灵活替换和升级。今天用规则引擎的地方，明天可以换成机器学习模型；现在用 GPT-4 的地方，以后可以换成更合适的专用模型。
  3. 状态管理。工作流需要维护整个对话或任务的上下文状态。这不仅包括用户的历史输入，还包括中间结果、系统状态等。良好的状态管理是实现复杂交互的基础。
  4. 异常处理。每个环节都可能出错，需要有完善的异常处理机制。比如大模型返回了不合预期的结果怎么办？外部 API 调用失败怎么办？这些都需要提前考虑。
  5. 人机协同。在关键环节保留人工介入的接口。这不是技术不行，而是业务需要。很多场景下，人工审核是合规要求，也是质量保证。总得有人背锅不是，毕竟 AI 背不了锅。

工作流的局限性

工作流虽然解决了很多问题，但也有明显的局限性。

第一是灵活性不足。预设的流程很难应对所有情况，遇到流程外的需求就无能为力。这也是为什么很多 Agent 给人感觉很”笨”的原因——它只会按照固定的套路来。

第二是开发成本高。设计一个完善的工作流需要深入理解业务逻辑，每个流程都需要大量的开发和测试。而且业务变化时，工作流也需要相应调整，维护成本不低。

第三是用户体验的割裂感。用户能明显感觉到自己在跟一个程序打交道，而不是一个智能助手。特别是当工作流设计不够自然时，这种割裂感会更强。

预想可能的发展

尽管当前工作流是主流，但技术还在快速发展。

模型能力在提升。新一代的大模型在准确性、稳定性上都有改进。特别是针对特定领域的专用模型，表现越来越好。比最新上的 Qwen3-Max 就针对工作流，工具调用有了特别的优化。这为减少工作流的约束提供了可能。

工具调用能力在增强。Function Calling、Tool Use、MCP，以及最新的 SKILLS 等技术让大模型能更好地与外部系统交互。虽然本质上还是工作流，但流程可以更动态、更智能。

多模态融合带来新可能。不只是文本，图像、语音、视频等多模态信息的处理能力都在提升。这让 Agent 能处理更复杂的任务，提供更自然的交互。

强化学习和自主学习是长期方向。让 Agent 从交互中学习，不断改进自己的策略。虽然现在还不成熟，但这是实现真正自主 Agent 的关键。

产品化的思考

做 AI Agent 产品，技术只是一部分，更重要的是产品思维。

首先要明确定位。你的 Agent 是要解决什么问题？为谁解决？解决到什么程度？不要试图做一个万能的 Agent，那样最后什么都做不好。现在很火的小鹏的机器人，其有 80 个控制点，相对于宇树的 20 个控制点，其灵活性肯定要高一些，但是其场景和定位是完全不一样的，成本也不一样。

其次是场景选择。选择那些容错率相对高、价值明确的场景。比如内容创作辅助就比财务决策更适合当前的技术水平。在合适的场景下，即使是工作流 Agent 也能创造很大价值。

然后是预期管理。不要过度承诺，要让用户清楚产品的能力边界。与其说这是一个智能助手，不如说这是一个智能工具。合理的预期能减少用户的失望，提高满意度。

还要重视数据积累。每一次用户交互都是宝贵的数据。通过分析这些数据，我们能发现工作流的不足，找到优化的方向。数据驱动的迭代是产品成功的关键。

最后是成本控制。AI Agent 的运营成本不低，必须找到合理的商业模式。是订阅制还是按量付费？是 To B 还是 To C？这些都需要根据产品特性和市场情况来决定。

实践中的几个关键点

基于这段时间的观察和实践，有几个点特别重要。

第一，不要迷信技术。大模型很强大，但它不是银弹。很多问题用传统方法解决更高效、更可靠。关键是找到合适的技术组合。

第二，重视工程实现。一个好的想法到一个可用的产品，中间有大量的工程工作。提示词优化、结果解析、错误重试、性能优化，这些看似琐碎的工作往往决定产品的成败。

第三，持续迭代。AI Agent 产品很难一步到位，需要不断根据用户反馈来改进。建立快速迭代的机制，小步快跑，逐步逼近理想状态。

第四，关注安全和合规。AI 的不可控性带来了新的安全风险。数据隐私、内容安全、决策可解释性，这些都需要提前考虑。特别是在企业级应用中，合规往往是第一要求。

第五，建立评估体系。怎么衡量一个 Agent 的好坏？准确率、响应时间、用户满意度、成本效率，需要建立全面的评估指标。只有能量化，才能持续优化。

写在最后

做 AI Agent 产品这段时间，最大的感受是理想与现实的差距。我们都希望做出科幻电影里那样的 AI，但现实的技术约束让我们不得不妥协。

但这未必是坏事。工作流让 AI 变得可控、可靠、可用。在当前的技术条件下，一个设计良好的工作流 Agent，往往比一个不受约束的”智能” Agent 更有价值。

关键是要认清现实，在约束中寻找创新的空间。大模型的边界是客观存在的，但边界之内仍然有广阔的天地。工作流不是终点，而是通向更智能的 Agent 的必经之路。

技术在进步，产品在迭代，市场在成熟。今天的工作流 Agent，可能就是明天自主 Agent 的雏形。重要的不是等待完美的技术，而是用现有的技术创造价值，在实践中推动进步。

这个领域还很年轻，充满了可能性。无论是技术突破还是产品创新，都有大量的机会。保持理性的乐观，脚踏实地地推进，相信我们能做出真正有用的 AI Agent 产品。

毕竟，每一个伟大的产品，都是从不完美开始的。

以上。