[]
在第二部分中，我们已经说明，AI Workflow的本质，是将人类已经验证过、可以标准化的解题路径预先编排成确定性的处理流程，再把AI放进其中最适合它的环节。它并不追求像Agent那样围绕目标持续自主规划，而是强调在清晰边界内，让AI承担分类、抽取、总结、生成和判断等认知型工作。因此，AI Workflow的核心挑战，并不在于“如何让AI更自由”，而在于“如何把AI稳妥地嵌入既有软件系统”。
这也意味着，AI Workflow的架构设计重点，与狭义Agent并不完全相同。对于架构师而言，真正需要优先想清楚的，通常不是某一个模型参数规模是否足够大，而是四个更加基础的问题：
工作流究竟应该运行在客户端还是服务端？
该如何组织决定其效果上限的上下文工程？
当工作流进入企业生产环境后，如何对其进行测试、发布、评估和持续治理？
在一条完整的工作流中，大模型与小模型各自应该承担什么角色？
看似只是几个工程问题，实际上却决定了一个AI Workflow项目能否长期稳定地运行下去。
在传统企业软件中，“逻辑放前端还是放后端”一直是架构设计里的基本问题。到了AI Workflow时代，这个问题并没有消失，反而变得更加重要。原因很简单，AI Workflow虽然看上去只是多了一次或几次模型调用，但它往往会同时涉及用户输入、企业数据、模型服务、工具调用、上下文管理、日志审计和权限控制。部署位置不同，整个系统的风险边界、响应速度、可治理能力和实施复杂度都会随之变化。
因此，AI Workflow运行在客户端还是服务端，并不是一个纯粹的技术偏好问题，而是一个与安全、成本、体验和治理密切相关的架构问题。更进一步说，它往往决定了这套能力最终会停留在“个人助理型应用”的层面，还是演进为真正的“企业级业务能力”。
所谓客户端运行，是指工作流的主要执行逻辑位于用户侧应用之中，例如桌面端、浏览器端、移动端，或某种嵌入式前端容器中。用户输入首先在本地被组织成本次任务的上下文，再由客户端直接调用模型或中转服务，并在本地完成一部分结果编排、渲染和交互控制。
这种方式最直接的优势，是交互体验通常更自然，尤其是运行在iOS或Android的原生App中。因为工作流离用户最近，所以它更容易做到即时反馈、流式输出、多轮补充和前端态的细粒度控制，而无需依赖网络连接。对于那些强调个人体验、强调对话连续性、强调本地文档处理或强调弱联网环境的场景，客户端运行往往具有吸引力。比如轻量级内容生成插件，或者面向单一员工的小范围桌面自动化（文本分类、图片识别等），这类场景通常更适合把部分逻辑放在客户端。
但客户端方案的局限也非常明显。首先，它天然不利于统一治理。不同终端版本、不同环境配置、不同缓存状态，都会让同一条Workflow在不同设备上的表现产生差异。其次，它不利于强权限控制和集中审计。只要涉及企业内部数据访问、跨系统调用、规则校验和高风险操作，客户端本身通常不应成为最终的执行边界。再次，客户端工作流也更难沉淀为企业级共享能力。因为一旦逻辑过多地下沉到前端，后续复用、运维和统一升级都会变得复杂。
换句话说，客户端更适合承载“交互”，却不适合承载“治理”。如果把企业级AI Workflow的大部分核心逻辑都下沉到客户端，短期看交互会更灵活，长期看治理成本却往往会迅速上升。这也是为什么客户端方案在ToC或个人效率场景中更常见，而在真正的企业级系统建设中，通常只承担交互层或补充层的角色。
图：客户端中运行的Workflow（离线场景）
需要指出的是，上述分析是基于网络连接稳定的企业环境。在网络不稳定或必须离线工作的场景下（如野外作业、现场执法），客户端不仅承载交互，更成为唯一的执行层。此时，架构设计需转向‘离线优先’模式，重点解决本地模型能力（端侧模型）、数据同步策略和恢复联网后的结果上报与审计对齐等问题。
与客户端方案相比，服务端运行是目前企业级AI Workflow更主流的选择。这里所说的服务端，并不只是一个简单的API中转层，而是完整承载工作流编排、上下文管理、工具调用、结果校验、日志留痕和版本治理的中心执行层。
它之所以成为主流，不是因为服务端天然“更先进”，而是因为企业级工作流天生需要统一治理。AI Workflow一旦进入生产环境，通常就会牵涉多个系统、多个角色、多类数据和多重约束。这些约束包括用户身份、接口权限、字段权限、流程顺序、业务规则、人工审批和审计留痕等。把工作流放在服务端，本质上是把这些规则收回到企业可控范围内，让每次执行都能被记录、被重放、被验证、被追踪。
图：服务端运行的Workflow，使用活字格低代码开发
从工程角度看，服务端运行还有几个非常现实的优势：
便于统一接入模型服务、向量库、规则引擎和外部工具，减少客户端重复建设
便于统一实施缓存、限流、重试、熔断和降级等基础能力
可以让工作流沉淀为共享能力，使其从“某个界面上的一个按钮”升级为“企业软件平台中的一个稳定模块”
更容易与现有的身份体系、权限体系和日志体系集成，从而形成真正可审计、可回放、可追踪的生产级链路。
这并不意味着服务端方案没有代价。它的主要代价在于初期建设成本更高，在性能、会话状态和异步执行上做更多设计。但对于多数ToB项目而言，这恰恰是值得的，因为企业真正需要的，不是某一次演示时的流畅感，而是长周期运行中的可靠性和可控性。
为便于在设计阶段快速判断，这里给出一个简化的对比表：
对比维度 | 客户端运行 | 服务端运行 |
|---|---|---|
主要优势 | 响应链路更短，不依赖网络 | 统一治理能力更强，便于复用和审计 |
适合场景 | 离线场景、轻量级辅助功能 | 企业知识库、审批流、数据查询、跨系统业务流程 |
权限控制 | 较弱，通常需要依赖后端再校验 | 较强，便于统一接入权限体系 |
审计留痕 | 分散，难以统一 | 集中，便于追踪和复盘 |
版本管理 | 容易受终端版本影响 | 更容易统一发布和回滚 |
共享复用 | 较弱 | 较强 |
企业推荐度 | 适合作为交互层补充 | 适合作为主执行层 |
但是，在实际项目中客户端还是服务端，往往并不是一个非此即彼的选择。更常见、也更稳妥的架构，是前端负责交互，服务端负责执行。也就是说，用户界面、会话展示、流式反馈和局部表单控制保留在客户端，而工作流的核心编排、上下文组织、工具调用、权限校验和结果治理集中在服务端。
这种分工与传统企业软件的分层设计完全一致，也更符合AI Workflow的工程特征。客户端负责把用户问题组织成可提交的请求，并把中间状态和最终结果友好地呈现给用户；服务端则负责把这个请求放入标准化工作流中执行，并确保过程中所有关键动作都处于统一治理之下。对于大多数企业来说，这种“交互在前、执行在后”的方式，通常是AI Workflow最现实、也最稳妥的部署答案。
AI Workflow虽然不依赖Agent那样持续自主规划，但它依然高度依赖上下文工程。因为模型不会凭空理解业务，它只能基于当前看到的信息做出判断。工作流设计得再清楚，如果每一个AI节点看到的上下文是残缺的、混乱的、冗余的，最终结果仍然会不稳定。反过来说，即使模型能力并非最强，只要上下文组织得足够精准，很多Workflow场景也能达到非常好的效果。
因此，在AI Workflow中，上下文工程并不是一个附属环节，而是核心能力本身。它决定的不是“模型会不会回答”，而是“模型是否能在正确的信息范围内完成它被分配的那一步任务”。从某种意义上说，工作流设计解决的是“步骤如何排列”，而上下文工程解决的则是“每一步究竟基于什么来思考”。
企业级AI Workflow中的上下文通常可以分为4层：用户输入、记忆、相关知识和结构化输出。
很多团队在设计AI Workflow时，最容易低估的就是用户输入。表面上看，用户只说了一句话，但对系统来说，这句话往往只是任务的起点，而不是完整上下文。
真正可用于工作流执行的输入，通常要包括以下内容：
用户身份与组织角色
操作入口（如从某个特定的单据出发，还需要包含当前业务单据状态）
会话历史
任务目标（用户的输入内容通常在这里）
例如，同样一句“帮我看看这个订单能不能退”，在客服系统、售后系统和管理驾驶舱中的含义就可能完全不同。如果系统只把自然语言原文交给模型，而忽略了订单号、用户身份、当前页面状态和退货政策版本，那么模型即便“听懂了句子”，也很难真正做出正确判断。也就是说，用户输入在工作流语境下从来不只是自然语言文本，而是一组与任务强相关的信号集合。
因此，AI Workflow设计的第一步，通常不是直接调用模型，而是先把用户输入结构化。哪些字段应当从界面直接获取，哪些字段应当由会话上下文补齐，哪些字段必须再次向用户确认，这些都属于输入层的上下文工程。
输入组织得越完整、越精准，后面的每一步就越稳定。
在第一部分中，我们了解到记忆是所有AI系统的基础设施。但在工程实践中，Workflow与Agent使用记忆的方式有本质区别。Agent倾向于开放式、探索性地使用记忆，而Workflow更强调受控记忆。
在最简单的场景中，Workflow至少需要会话级记忆。也就是说，系统要知道用户刚才问过什么，前一步节点产出了什么结果，哪些中间变量已经被确认，哪些结论还只是候选。没有这类短期记忆，多步工作流就无法稳定推进，模型每到一个节点都只能“重新开始理解问题”，这显然会带来大量误差和冗余消耗。
而在更复杂的企业场景中，Workflow还可能需要有限的长期记忆。例如保存用户偏好、保留高频业务规则、记录某一类典型问题的处理摘要等。需要强调的是，Workflow中的长期记忆通常不应无边界扩张，而应以“可检索、可更新、可删除、可追踪”为前提。否则，记忆很快会从帮助系统理解业务，变成干扰系统判断的噪声源。
因此，对于AI Workflow而言，记忆系统的设计重点不在于“存得尽可能多”，而在于“只把当前节点真正需要的历史信息放进来”。这是它与开放式Agent系统在记忆使用方式上的一个重要区别，也是一条非常重要的工程原则。
过多、过旧、过散的记忆，并不会提升质量，反而更容易稀释模型对关键事实的注意力。
如果说用户输入和记忆回答的是“当前发生了什么”，那么相关知识回答的就是“这件事在业务上意味着什么”。这也是为什么大多数企业级AI Workflow最终都会走向某种形式的知识增强。
这里的知识，不一定都来自向量数据库，也不一定都必须是RAG。它可能是规章制度文档、FAQ知识库、产品手册、标准操作程序、术语解释表、结构化规则表，甚至可能只是工作流节点中一段经过人工整理的说明文字。关键不在于知识来自哪里，而在于模型在进入某一步推理之前，是否看到了完成这一步所必须知道的业务背景。
以报销审核为例，模型真正需要知道的，往往不是“什么是报销”这种通用概念，而是“当前公司关于差旅、餐补、住宿标准和审批层级的具体规则”。再例如售后问答，模型真正需要知道的，也不是“什么是物流”，而是“这家公司当前的退换货政策、地区差异和特殊商品例外规则”。这些知识如果不能被准确加载，模型再强也只能给出通用答案，而无法给出企业真正可用的结果。
这也是为什么AI Workflow中的知识工程，通常比通用聊天产品更强调精确性和边界感。企业并不需要一个“什么都能聊”的模型，而是需要一个“在这个节点上只看该看的材料”的模型。
上下文工程的最后一层，也是最容易被低估的一层，是结构化输出。很多团队会把结构化输出理解成“为了方便程序解析的一个格式要求”，但对于AI Workflow而言，它的意义远不止如此。结构化输出实际上是把概率性的模型结果接回确定性软件流程的关键接口。比如，通过下方的提示词，要求LLM返回一个JSON数组，而非自然语言的文本。
输出为一个JSON数组，每个元素包含id、rating和comment三个属性，数组按照rating降序排列。
- id：整数，来自岗位描述的id属性，必须和岗位描述中的id属性完全一致
- rating： 整数，从0到5的整数描述简历与岗位的匹配度，越匹配，数值越大
- comment：文本，打分原因和写给面试官的面试建议，不允许有换行
示例：[{"jd":2,"rating":4,"comment":"xxx"},{"jd":1,"rating":3,"comment":"xxx"}]在大部分企业软件系统中，下游节点通常不接受模糊表达，它需要明确字段、明确状态、明确参数。工作流中的AI节点如果只返回一段自然语言，那么后续节点就必须再次用模型去理解这段自然语言，或者由程序做大量脆弱的字符串处理。这样一来，不确定性就会被一层层放大。相反，如果AI节点直接输出结构化结果，例如分类标签、意图字段、参数对象、判断状态、置信说明等，那么整个Workflow就能重新回到软件工程熟悉的确定性轨道上。
这也是为什么函数调用、JSON Schema、Typed Output、结构化槽位填充等技术，在AI Workflow中会比在通用聊天场景中更重要。它们并不只是“让模型更规范”，而是在本质上降低了模型输出与业务系统对接时的摩擦成本。
许多团队在第一次做AI Workflow时，容易把重点全部放在“如何把链路跑通”上。这当然重要，但对企业项目来说，跑通只意味着原型成立，并不意味着可以长期运行。因为只要系统已经进入真实业务场景，它面对的就不再只是单次调用是否成功，而是质量是否稳定、版本是否可回退、策略是否可调整、问题是否可定位、效果是否可量化。
也正因为如此，AI Workflow一旦进入生产环境，就必须进入工程治理周期。它不再只是一个提示词加几个接口的组合，而是一个需要被持续测试、持续发布、持续监控和持续优化的软件资产。对于企业来说，真正的难点从来不是把一条链路临时跑通，而是如何让它在高并发、多版本、强权限和长周期运行的条件下，依然保持稳定。
AI Workflow的测试，首先仍然应当继承传统软件工程的方法。每个非AI节点都应当有清晰的输入输出断言，每条流程分支都应当经过单元级和集成级验证。这一点没有变化，也不应该变化。真正新增的部分，是那些由模型承担的节点，它们无法仅靠字符串相等来判断对错。
因此，AI Workflow的测试通常要分成两层。第一层是节点测试，重点检查每个AI节点是否在典型上下文下输出了符合预期的结构和语义结果。例如分类是否正确、字段是否完整、格式是否稳定、拒答是否合理。第二层是端到端测试，重点检查整条工作流在一组真实或模拟任务下能否稳定完成目标。这一层评估的，不再只是单个模型输出，而是完整流程的最终效果。
在具体方法上，LLM-as-a-Judge已经逐渐成为行业中的主流手段之一。它的价值，不是替代人工，而是帮助团队在大量样本上快速完成初步评估。尤其对于回答正确但措辞不同、结论部分正确但表达方式不同、格式合规但细节遗漏等场景，LLM-as-a-Judge通常比简单规则更接近真实评价方式。但它也不能被神化，企业仍然需要用人工标注的黄金样本去校准评估模型本身，确保评判标准没有偏离业务目标。
图：LLM as a Judge的基础流程
对于企业级AI Workflow来说，测试还应当尽量前移到日常开发过程中。也就是说，在每次修改提示词、替换模型、调整检索范围或新增流程节点时，都应自动触发一轮最小化回归测试。这样做的意义在于，把问题尽可能发现于上线前，而不是等到用户投诉后再去追溯。很多团队一开始把AI Workflow当作“配置型能力”来维护，结果忽视了自动化测试，最后才发现提示词和知识源的小改动也会引发明显行为变化。从这个角度讲，AI Workflow虽然表现为自然语言处理系统，但它仍然应该遵守和传统软件相同的持续集成纪律。
在传统软件项目中，版本管理的对象主要是代码。而在AI Workflow项目中，真正需要被版本化管理的，往往不只是代码，还包括以下内容：
流程编排定义
提示词模板
知识源配置（如语义知识库、文件夹等）
结构化输出Schema
模型路由策略（含大模型的版本）
评估基准数据集
关键业务规则
这是因为工作流效果的变化，很多时候并不是由代码修改引起的。也许只是提示词改了一段，也许只是召回知识范围变了，也许只是模型从一个版本切到了另一个版本，最终结果就可能出现明显差异。如果这些变化没有被纳入统一版本管理，那么后续排查问题时就会非常困难。团队可能知道“今天结果不对了”，却不知道究竟是哪个因素导致了变化。
因此，AI Workflow更适合采用“配置、流程、模型、知识、评估”统一纳管的版本策略。每次发布，都不只是发布一段代码，而是发布一个完整的工作流版本包。这个版本包中包含了足以重现当前行为的全部关键要素。只有这样，回滚、灰度和对比评估才有真正意义。
在版本管理之外，网关（Gateway）也会成为生产级AI Workflow的重要组成部分。它的作用并不只是做流量转发，更重要的是把认证、鉴权、限流、配额、审计日志、租户隔离和策略控制集中起来。对于企业而言，模型服务、知识服务、工具服务和工作流编排层之间，最好不要以完全散乱的方式直接互连，而应通过统一入口来管理访问边界。这样做的直接好处是，即使底层模型、服务提供商或工具实现发生变化，上层业务工作流仍然可以保持相对稳定，同时也便于在网关层统一实施IP白名单、接口熔断、调用审计和成本配额管理等策略。
此外，考虑到不同的资源更新频率不同，版本管理通常会选择不同技术方案。如流程定义、大模型路由、评估基准、关键业务规则等，变更频率很低，通常选择和源代码类似的版本管理机制，使用Git管理，纳入DevOps流程；而提示词模板、结构化输出Schema等变更频率较高，会选择存放到数据库中，每次运行时，先从数据库中读取这些内容。
图：从数据库中读取提示词模板，实时完成拼接
AI Workflow进入生产环境后，监控的重点也会发生变化。传统软件更关注是否报错、是否超时、接口是否成功；AI Workflow除了这些，还必须关注模型节点是否稳定、知识召回是否异常、结构化输出是否失真、某类任务的最终质量是否下降。
这就意味着，AI Workflow的可观测性不能只停留在API调用层，而要延伸到工作流轨迹层。每一步看到的上下文是什么，调用了哪个模型，命中了哪一组知识，返回了什么结构化结果，后续节点为何走向了这条分支，这些都需要被记录下来。只有把“结果”和“路径”同时记录，团队才能真正理解系统为什么成功，也才能在失败时迅速定位根因。
从实践经验来看，这种轨迹级观测往往比单纯统计调用次数更有价值。因为企业最难处理的问题，往往不是“完全失败”，而是“看起来成功了，但结果不够好”。而要处理这种问题，仅有错误日志是不够的，必须能够回看它的整条执行链。
在观测体系的设计上，企业通常至少需要同时具备日志、指标和追踪三类能力。日志回答“发生了什么”，指标回答“整体运行状态如何”，追踪回答“这次请求是怎么一步步走到现在的”。把三者结合起来，AI Workflow才能真正建立起与传统分布式系统相当的可观测性。例如某类任务的平均延迟突然升高，仅靠日志很难一眼看出原因，但如果有完整追踪，就可以快速发现是检索变慢、模型响应变慢，还是下游系统超时重试导致链路拉长。
进一步说，监控对象也不应只局限于技术指标。除了延迟、错误率、吞吐量、Token消耗、缓存命中率之外，企业还应关注工作流级别的业务指标，例如成功完成率、转人工率、人工纠错率、结构化输出有效率、知识命中率和用户满意度。这些指标虽然不像CPU使用率那样“硬”，但它们更接近工作流真正的业务价值。如果缺少这一层监控，团队往往会陷入一种假象：系统技术上运行正常，但业务结果并不理想。
在真实的企业环境中，AI Workflow几乎不可能永远一帆风顺。模型服务可能超时，外部知识库可能暂时不可用，内部API可能返回脏数据，下游系统可能限流，甚至用户本人也可能在流程进行到一半时撤回请求。因此，容错设计不是附加项，而是生产级AI Workflow的基本能力。
其中最常见的第一个问题是超时。AI节点的超时与传统接口超时并不完全相同，因为模型调用往往既受到上下文长度影响，也受到供应商侧负载、输出长度和工具调用链路影响。因此，企业在设计超时时，通常不能只给整条Workflow设置一个总超时，而应同时设置节点级超时、阶段级超时和全链路超时。节点级超时用于快速识别单个模型调用或工具调用是否异常，阶段级超时用于限制某个流程段不会无限拖长，全链路超时则用于保证用户体验和系统资源占用都处于可控范围之内。
第二个常见问题是重试。对于临时性失败，例如短暂网络抖动、偶发限流、外部服务瞬时不可用，重试通常有效；但对于确定性错误，例如参数缺失、权限拒绝、格式错误、知识源为空，盲目重试只会放大成本。因此，AI Workflow中的重试不应是无条件的，而应当建立在错误分类之上。什么错误可以重试，最多重试几次，重试前是否需要退避等待，是否需要抖动时间窗口，是否要切换备用模型或备用知识源，这些都需要在架构阶段就提前定义清楚。
第三个问题是错误回退。很多团队在第一次实现工作流时，默认所有节点都必须成功，任何一个节点失败就整条流程报错退出。但企业用户并不总是接受这种“全有或全无”的体验。更现实的做法是，为工作流设计分层回退策略。例如，首选知识库不可用时，是否可以退回到FAQ库；主模型超时时，是否可以切换到更快的小模型先返回一个简化结果；结构化输出解析失败时，是否可以进入一次受控的格式修复流程；高风险操作无法自动完成时，是否可以转人工审批或进入待办队列。回退的目的，不是掩盖失败，而是在保证边界清晰的前提下，为系统提供合理的服务连续性。
第四个问题是补偿。只要AI Workflow涉及有副作用的操作，例如创建工单、更新订单状态、写入审批记录、推送通知或触发外部系统动作，就必须考虑补偿机制。因为一条多步流程中，前几步可能已经成功提交，后几步却失败了。如果没有补偿，系统就会留下不一致状态。传统分布式工作流中常见的做法，是使用“先执行、后补偿”的思路，也就是在必要时为每个关键动作准备反向操作。例如已经创建的草稿单据能否撤销，已经写入的临时状态能否回滚，已经触发的外部消息能否标记失效。AI Workflow虽然引入了模型节点，但一旦它与业务系统发生写操作，补偿设计就必须回到严格的软件工程范畴。
最后还要强调一个容易被忽略的问题：幂等性。模型调用本身通常无副作用，但工作流中的工具调用却未必如此。如果同一个请求因为重试而被执行两次，系统是否会重复创建记录、重复发送邮件、重复发起审批，必须在设计阶段就明确处理办法。最常见的方法，是为每次业务动作绑定幂等键，并在真正落库或触发下游前进行去重校验。很多AI Workflow问题，并不是出在模型本身，而恰恰是因为这类最传统的工程问题被忽略了。
此外，AI Workflow的容错设计还需特别关注语义层面的软失败。不同于接口超时，模型节点可能返回格式正确但内容答非所问、关键信息遗漏或事实错误的输出，这种现象更具隐蔽性。成熟的Workflow会在关键节点后增设置信度检查或语义校验环节（例如，对结构化输出中的关键字段进行规则校验，或使用轻量级模型快速验证输出与上下文的一致性）。当检测到低置信度或语义矛盾时，系统可触发预设回退策略，如使用备用模型重新生成、请求人工介入，或在风险可控时先采用降级方案推进流程，确保系统在出现软失败时拥有明确的处置闭环。
AI Workflow的治理最终并不是为了“发现问题”，而是为了形成持续优化闭环。测试提供基线（如LLM as a Judge的评分），版本管理提供可回滚能力，观测提供问题定位能力，评估提供量化反馈能力。这几者结合起来，才能真正支撑工作流从一次性原型演进为长期可复用的软件资产。
在这个过程中，一个非常重要的原则是：不要把优化目标只放在模型本身。很多时候，Workflow质量的提升并不是靠换一个更强的模型，而是靠改善输入组织、补充关键知识、收紧结构化输出、减少无关上下文、优化节点拆分方式，或者把某个原本交给模型的步骤重新收回到规则逻辑中。也就是说，AI Workflow的优化，本质上仍然是一种系统工程优化，而不只是模型优化。
在很多企业讨论中，提到AI Workflow时，常常会默认整条链路只对应一个大模型。但从工程现实看，这往往不是成本最优、也不是效果最稳定的方案。原因在于，工作流中的不同节点，对模型能力的要求其实差异很大。有些节点需要强推理能力，有些节点只需要快速分类，有些节点适合小模型做预处理，有些节点则应当交给大模型完成最终生成。如果把所有任务都压给同一个高成本模型，系统当然可以跑起来，但运行代价和性能波动都会明显放大。
也正因为如此，AI Workflow天然适合多模型协同。它的流程是预定义的，所以开发者可以在设计阶段非常明确地为每个节点分配最合适的模型角色，而不必把所有能力都寄托在单一模型之上。这与Agent不同。Agent因为路径动态生成，很多时候更依赖一个较强的主模型持续决策；而Workflow由于路径稳定，反而更容易实现模型分工。
从当前主流实践看，大模型更适合承担那些真正需要综合理解、复杂推理和高质量生成的节点。例如对多个候选材料进行整合解释、生成正式回复、完成复杂判断、在多条规则之间做权衡等。换句话说，大模型更适合被放在工作流中“最像人思考”的位置上。
相比之下，小模型更适合承担那些高频、标准化、边界清晰的环节。例如意图分类、文本清洗、关键词补全、结构化字段抽取、简单重写、候选打分、风险初筛等。这些任务的共同特点是路径稳定、结果格式清晰、推理深度要求有限，但调用频率通常很高。如果全部交给大模型，不仅成本高，而且未必更稳定。把这些节点下沉给响应更快、价格更低的小模型，往往可以带来非常明显的性价比提升。
图：包含小模型（意图识别）和大模型（参数识别）的AI Workflow
从当前主流实践和性价比角度出发，一条颇具指导意义的原则是让大模型聚焦需要深度综合理解、复杂推理和高质量生成的节点，而将意图分类、文本清洗、简单抽取等高频、标准化、边界清晰的环节交给更轻量的小模型或传统算法。当然，最终选择取决于具体需求，例如在生成量巨大且质量要求苛刻的核心业务节点，由大模型大规模承担标准任务也是一种选择，但需权衡其成本。”
一旦承认不同节点适合不同模型，那么模型路由就不再是一个可有可无的优化技巧，而会变成AI Workflow设计的一部分。所谓模型路由，本质上就是在工作流中明确：什么任务交给什么模型，什么情况下可以切换模型，什么情况下必须回退到默认模型。
路由方式主要可以分为静态路由和动态路由，处理策略不同。
静态路由：在设计阶段就规定好，分类节点用小模型，最终生成节点用大模型，结构化校验节点用更便宜的模型。这种方式最容易治理，也最符合Workflow本身强调确定性的特点。
动态路由：在运行时，根据上下文中某个或某几个参数，决定调用哪个模型。例如，当输入长度超过某个阈值时切换到长上下文模型，当主模型超时时切换到备用模型，当问题复杂度较低时优先使用低成本模型。
需要强调的是，即使采用动态路由，其切换规则也应在设计阶段由开发者明确写清（例如：‘当主模型超时时，切换到备选模型X’），而不是把‘选择哪个模型’本身作为一个开放目标交给AI去自由判断。这正是Workflow与Agent在模型选择上的根本区别：前者在设计时预设切换路径，后者可能在运行时自主决定调用哪个模型作为工具。保持这一原则，才能守住确定性流程的优势。
在AI Workflow中选择模型，重点通常不是追求单项能力最强，而是在质量、速度和成本之间找到最适合当前节点的位置。某个节点如果每天被调用几十万次，那么哪怕每次只节省很少的Token成本，全年下来都可能形成巨大差异。反过来，一个虽然调用不高频、但直接影响最终用户感知的关键节点，就值得投入更强的模型能力。
因此，企业在设计AI Workflow时，更合理的方式通常不是先问“哪个模型最强”，而是先问“这个节点最需要什么”。是需要高准确率，还是低延迟；是需要严格结构化，还是需要更自然的生成；是需要更强的推理，还是只需要快速过滤。只有把节点需求想清楚，模型选型才不会变成盲目的参数崇拜。
AI Workflow看上去像是在传统流程中加入了几次模型调用，但真正决定其成败的，始终是软件架构本身。它运行在客户端还是服务端，决定了系统的治理边界；它如何组织用户输入、记忆、相关知识和结构化输出，决定了模型节点的效果上限；它如何进行测试、版本管理、网关治理、监控评估以及超时、回退、补偿等容错设计，决定了这套工作流能否长期稳定地运行在生产环境中；而它是否能合理使用大模型与小模型协同，又决定了系统最终能否在质量、速度和成本之间取得平衡。
对于企业而言，AI Workflow最重要的价值是用一种工程上可控的方式，把模型能力稳定地接入既有业务系统之中。只有当部署方式清晰、上下文工程扎实、治理体系完整时，AI Workflow才能真正从演示功能，演进为企业级的软件能力。也只有在这一基础上，工作流范式所强调的确定性、可解释性和成本优势，才能真正转化为企业级生产力。