[]
在第一部分中，我们已经说明AI智能体并不只是一个更强的对话模型，而是一个能够围绕目标持续完成“思考→行动→观察”循环的系统。但当智能体真正进入企业软件建设阶段后，技术团队很快会发现，摆在面前的首要问题并不是模型的选择，而是开发范式的选型。也就是说，同样是把AI引入企业场景，究竟应该把它做成一个嵌入既有流程的能力模块，还是做成一个能够围绕任务自主规划和执行的行动主体。这一判断，会直接影响系统的成本、质量、可控性和交付方式。
从当前行业实践来看，企业级AI智能体主要存在两种开发范式。一种是 AI Workflow/工作流范式；另一种是 Agent/狭义智能体范式。前者强调由人类预先定义任务路径，再让AI在其中承担特定环节的认知工作；后者强调由人类给出目标、上下文和边界，再让AI在运行时自主决定下一步该做什么。
两种范式都已被广泛采用，也都能够创造业务价值，但它们最适用的场景并不相同。对于架构师而言，真正重要的不是抽象地争论哪一种更先进，而是准确判断出当前的业务任务中，究竟应该把确定性保留给流程，还是把灵活性释放给模型。
企业最早使用AI时，通常并不是把它当作一个完整的系统，而是把它视为一种可嵌入的软件能力。无论是图像识别、语音转写、文本分类，还是后来的内容生成、问答和摘要，本质上都是把AI放在一个预先设计好的流程节点中，让它完成某一小段人类难以用传统规则精确定义的处理任务。整个业务路径仍然由开发者控制，系统何时调用模型、输入什么、输出给谁、如何与其他环节衔接，全部由人类事先安排好。这种方式延续了传统企业软件的工程逻辑，因此天然形成了工作流范式。
图：融入业务流程的AI
但大语言模型的出现，使企业对AI的期待发生了变化。管理者不再满足于让AI只做一个局部工具，而开始希望它像员工一样理解任务、读取系统、整合信息、完成分析，并交付最终结果。也正因为如此，AI在企业中的角色，开始从“能力组件”逐步走向“行动主体”。这就是新一代智能体开发范式兴起的背景。
图：数字员工，图片来自麦肯锡
然而，企业在期待AI具备更强自主性的同时，也会立刻面对新的现实问题。传统软件之所以能够在生产环境中长期稳定运行，是因为它的路径、权限和行为边界是可设计、可验证、可审计的。一旦让AI自己决定下一步动作，系统就必须回答一系列更困难的问题：
为什么要调用这个接口
有没有权访问这份数据
是否遗漏了关键步骤
在出错时能否被及时中断
每一次操作能否留下完整记录
于是，企业级AI建设很快形成了一条非常清晰的分界线，有些问题适合通过固化流程来解决，有些问题则必须依赖自主规划来完成。从这个分歧出发，两种应用场景不同却可以有机结合的开发范式逐渐清晰了起来。但是，这两种范式的命名依然存在较大的争议，在本文中我们将其称之为AI Workflow和Agent。
所谓AI Workflow，本质上是将人类已经验证过、可以标准化的解题路径预先编排成一个确定性的处理流程，再把AI放进其中最适合它的环节。这里的关键，不在于流程中是否使用了大模型，而在于AI并不负责决定整体路径。它可以负责分类、抽取、总结、改写、生成，也可以承担部分语义判断任务，但任务的主干、顺序和边界，仍然是由人类开发者通过流程设计来控制的。
图：AI Workflow的架构示意
这种范式与第一部分中“工作流：固化成熟的解题思路”的定义是一致的。工作流的价值不在于它是否足够智能，而在于它把已经被业务验证过的经验变成了稳定的软件执行路径。也正因为如此，工作流天然具备三方面优势。
很强的可预测性，同一类任务会沿着相同或相似的路径执行，结果波动较小
较好的可解释性，因为每一步都是显式设计的，出了问题可以快速追溯到具体节点。
在成本和治理上都更加友好。模型只在少数环节参与，不需要在整条链路上持续推理，因此Token消耗更低，对模型规模和推理深度的要求也通常更低。
以企业知识库问答为例，这类场景在很多组织中已经非常常见。用户提出问题后，系统首先验证身份和权限，然后完成问题预处理，再到指定知识源中进行检索和筛选，最后把候选内容交给模型生成回答。整个过程中，真正需要AI自由发挥的，往往只是最后的少数步骤，而知识源选择、权限判断、候选排序和结果格式控制，全部来自预定义的流程逻辑。严格来说，这不是一个“完全自主”的智能体，而是一个典型的AI Workflow应用。
再例如合同信息抽取、报销单分类、工单分派、固定模板报告生成等任务，也大多属于这一类。它们的共同特点是任务结构相对稳定，输入输出边界比较清楚，路径可以在开发阶段被充分梳理出来，而且错误代价往往不低。在这种情况下，让AI去主导流程并不会带来明显收益，反而可能引入额外的不确定性。更稳妥的方式，是让流程负责稳定性，让AI负责理解和生成。
当然，AI Workflow并不是没有代价。它最大的局限在于，所有能力都需要被提前设计出来。每当业务部门提出一个新的应用场景，开发团队往往都需要重新梳理流程、确认节点、联调系统并完成测试。如果该场景是高频、稳定、长期使用的核心任务，这种投入通常是值得的；但如果它只是一个变化很快的长尾需求，或者只是某个部门临时产生的分析型任务，那么为其专门开发一条流程链路，成本就可能高于收益。
换句话说，工作流范式最擅长处理的是“已知且稳定的问题”，而不是“目标明确但路径开放的问题”。
很多企业任务虽然目标清楚，但解决过程并不固定，开发者也无法在设计阶段把所有可能分支都穷举出来。此时，更有效的做法不是继续扩展流程分支，而是把“下一步该做什么”的部分决策权交给AI。这正是Agent范式的基本逻辑。
Agent的核心，是在开发者预先设定的边界之内，让AI在运行时去自主规划和决定‘下一步该做什么’。开发者不再详细规定“先做什么、再做什么、最后做什么”，而是为AI提供任务目标、必要上下文、可调用工具和明确边界，让它在运行时自己决定下一步动作。这里的“自主”并不是无约束地自由发挥，而是在约束条件之内围绕目标持续推进任务。也就是说，Agent的本质不是放弃控制，而是把控制方式从“预先写死路径”改为“预先定义边界”。
从运行机制上看，Agent完全符合第一部分已经介绍过的六步循环。它接收任务后，会先感知环境、收集上下文，再进行推理，形成局部计划，然后调用工具执行动作，观察返回结果，再基于新信息继续判断下一步。这个过程会不断重复，直到初始目标被认为已经达成。与Workflow相比，Agent最大的不同就在于：前者是在设计时决定路径，后者是在执行时生成路径。
图：Agent的架构示意
这使得Agent特别适合处理那些目标明确、但步骤不固定的任务。比如，用户提出“请结合当前库存、历史销售和近期趋势，给出下季度补货建议，并输出为Excel方案”。这种任务本身并不复杂到无法理解，但它往往跨越多个系统，路径也会随着企业数据结构、用户偏好和当前业务状态变化而变化。此时，如果仍然坚持用工作流把所有可能路径全部预先写出来，开发和维护成本都会非常高。相反，如果系统具备合适的工具、足够清晰的上下文，以及可靠的边界约束，那么由Agent在运行时逐步规划和执行，通常会更具经济性。
从企业实践角度看，Agent最突出的价值，是对长尾场景的覆盖能力。很多业务需求并不是没有价值，而是不值得单独开发一套完整的软件流程。它们往往是低频的、变化快的、探索性的，甚至带有明显的阶段性。但正因为以往缺乏合适的方法，这类需求长期只能依赖人工完成，或者依赖业务人员绕过企业系统，直接使用外部通用AI工具“硬做”。这会带来准确性、权限和审计上的隐患。Agent的意义，就在于为这些长尾需求提供一种更灵活、但仍然可治理的解决路径。
同时，Agent通常支持多轮交互，这一点在企业场景中非常重要。用户在任务执行过程中可以追加条件、纠正理解偏差、要求改变结果形式，甚至可以中途终止任务或转交人工确认。与固定路径的多轮交互不同，Agent特别适合那些目标在交互中不断清晰、步骤需动态调整的探索性任务。用户可以在任意环节提出新的约束、纠正理解偏差或调整结果方向，这种高度的可修正性是Agent在交互上的核心优势。
图：在Agent中，人工纠正AI的理解偏差
但Agent的代价也必须被正视。它更依赖模型的推理能力，需要更精细的上下文工程，也往往伴随更高的Token消耗和更复杂的测试方法。更重要的是，如果缺乏明确的权限边界、工具约束和审计机制，自主性很容易演变为不可控。因此，企业中的Agent从来不应该被理解为一个完全自由行动的“超级AI”，而应该被理解为一个在清晰边界之内自主行动的系统。
从架构视角看，AI Workflow与Agent的本质差异，最终可以归结为一个非常简单的问题：下一步由谁决定。
AI Workflow：下一步由人类开发者决定。开发者在设计阶段就把流程主干、节点顺序、异常处理和边界条件写清楚，AI负责在既定节点上完成特定认知任务。因此，系统整体表现更接近一个“带有AI能力的软件流程”。
Agent：下一步由AI在运行时决定。开发者并不提前写死完整路径，而是提供目标、规则、工具和上下文，让AI在执行中持续判断最合理的动作。因此，系统整体表现更接近一个“具备自主规划能力、但受到治理约束的数字行动者”。
这种差异会带来一系列连锁影响。工作流的主要成本集中在前期设计和编排阶段，一旦路径稳定，后续运行效率较高，结果波动较小，也更容易纳入传统测试体系。Agent的前期开发反而可能更快，因为它不需要为每一个长尾场景分别造流程，但它会把复杂度转移到模型推理、上下文管理、行为约束、评估体系和生产治理上。工作流的测试方法更接近传统软件工程，可以逐节点验证；Agent的测试则更接近行为评估，需要综合观察任务完成度、工具调用正确率、过程合理性和最终结果质量。
因此，二者之间并不存在简单的优劣关系。工作流更像是一套已经固化好的最佳实践，适合高频复用；Agent更像是一名可被约束的数字员工，适合处理尚未完全收敛的问题。前者的重点是稳定和可控，后者的重点是灵活和覆盖范围。企业真正要做的，不是选边站，而是把两种能力放在正确的位置上。
现实中的企业任务，极少是纯粹的。一个完整业务过程里，往往既有必须严格遵循的确定性环节，也有需要根据上下文灵活判断的开放性环节。因此，在多数真正成功的企业项目中，Workflow与Agent并不是替代关系，而是分工关系。前者负责构建任务的骨架，后者负责补足任务中的弹性部分。这也正是第一部分中已经提出的“分层设计”思想。
这种分层设计之所以重要，是因为它恰好回应了企业在AI落地中的核心矛盾：一方面，企业希望AI具备足够的灵活性，能够覆盖那些过去难以自动化的复杂任务；另一方面，企业又必须保证关键环节可控、可审计、可回滚。AI Workflow 提供稳定骨架，Agent 提供柔性能力，把两者结合起来，才有可能在真实业务中同时满足创新与治理两方面要求。
例如在贷款审批场景中，身份核验、征信查询、额度计算、报告生成等关键步骤，通常必须严格遵守既定流程，这些部分更适合由Workflow承担。但当客户情况较为复杂，需要综合判断是否进一步查询历史还款详情、是否分析债务收入比、是否补充调取其他辅助信息时，这一段又明显更适合交给Agent。再例如企业知识库，本身通常就是一个由检索、重排序和生成组成的工作流应用，但它完全可以被封装成Agent可调用的一项工具，在更复杂任务中被重复利用。此时，Workflow不是Agent的对立面，反而是Agent最可靠的组成能力之一。
图：Agent与AI Workflow的分层协同
从这个意义上讲，企业真正落地的“广义智能体”，往往并不是一个完全自由行动的纯Agent，而是一个把Workflow、Agent、知识库、业务系统和权限体系组合在一起的复合系统。它既保留了传统软件工程的确定性，又引入了大模型在理解、规划和生成上的灵活性。这种混合架构，才是当前最符合行业共识、也最符合企业现实的智能体形态。
对于高级IT技术人员来说，范式选型的关键不在于抽象讨论哪一种更先进，而在于判断当前任务更需要确定性，还是更需要灵活性。如果任务结构清晰、流程稳定、分支可枚举、错误代价较高，那么应优先考虑Workflow；如果任务目标明确，但路径高度依赖上下文，执行过程中需要多轮修正和临场判断，那么更适合采用Agent。
交互模式也是一个非常重要的信号。如果用户通常希望单轮提交、单轮返回，而且更关心答案是否稳定一致，那么工作流通常更合适。如果用户希望在执行过程中不断补充要求、审查中间结果、纠正偏差，那么Agent会更自然。再往下看，还需要考虑成本和治理要求。工作流通常成本更低，便于规模化运行；Agent通常更灵活，但对模型能力、上下文工程和治理能力要求更高。至于那些同时兼具两类特征的任务，最佳策略往往不是强行归类，而是进行拆分，把确定性部分下沉到Workflow，把需要自主判断的部分交给Agent。
因此，企业在规划智能体项目时，最稳妥的路径通常不是一开始就建设一个“无所不能”的通用Agent平台，而是先把高频、稳定、价值清晰的场景用Workflow做扎实，再逐步把跨系统、多轮交互、长尾创新类任务纳入Agent工作台。这样既能尽快形成可见价值，又不会过早把系统复杂度全部推到生产环境中。
为便于在项目初期快速判断，我们整理出一个简化的对比表。需要强调的是，这个表格并不是为了得出绝对结论，而是为了帮助团队在需求分析阶段更快识别任务的主要特征。真正的生产级方案，往往仍然需要结合业务风险、现有系统基础和组织治理能力做进一步权衡。
对比维度 | AI Workflow | Agent |
|---|---|---|
核心思想 | 由人预先编排流程，在固定节点使用AI能力 | 由人定义目标和边界，由AI在运行时自主规划路径 |
控制方式 | 以确定性流程为主 | 以目标驱动和动态决策为主 |
下一步由谁决定 | 开发者在设计阶段决定 | AI在执行阶段决定 |
任务结构 | 适合结构清晰、分支相对稳定的任务 | 适合目标明确但路径开放的任务 |
交互模式 | 以单轮触发返回为主，也可支持路径预定义的固定多轮交互 | 更适合探索性多轮交互，即目标、路径可在执行中由用户动态调整或澄清 |
模型角色 | 负责局部认知任务，如分类、抽取、生成 | 负责规划、判断、调用工具和整合结果 |
工具使用方式 | 工具调用顺序通常固定 | 工具调用顺序和组合方式通常动态变化 |
可预测性 | 高 | 相对较低 |
可解释性 | 强，便于逐节点追踪 | 依赖日志、轨迹与评估体系辅助解释 |
成本特征 | Token消耗较低，运行成本更易控制 | Token消耗较高，对模型能力要求更高 |
测试方式 | 接近传统软件测试，适合逐节点验证 | 更接近行为评估，依赖LLM-as-Judge等方法综合判断任务完成质量 |
治理重点 | 流程设计、规则固化、节点校验 | 上下文工程、权限边界、工具约束和审计机制 |
典型优势 | 稳定、可靠、易审计、易规模化复用 | 灵活、覆盖长尾场景、适合复杂跨系统任务 |
主要局限 | 新场景需要重新编排，长尾需求成本较高 | 稳定性和治理复杂度更高，成本通常更高 |
更适合的场景 | 知识库问答、标准审批、合同抽取、固定模板生成 | 跨系统分析、复杂查询、方案生成、多轮协作任务 |
企业落地形态 | 常作为稳定的业务能力模块长期运行 | 常作为通用工作台或柔性能力层存在 |
需要补充的是，任务结构并非一成不变。今天的创新长尾任务，在被验证和标准化后，明天就可能被固化为高频稳定的Workflow。优秀的架构设计应为这种从Agent向Workflow的平滑演进预留可能，例如将Agent的成功执行路径沉淀为新的Workflow模板。
AI智能体的两种开发范式，本质上对应着企业在AI时代组织软件能力的两种方式。AI Workflow强调由人类预先定义任务路径，在确定性框架中嵌入AI能力，适合标准化、高频、规则稳定且对结果一致性要求较高的场景。Agent则强调由AI围绕目标自主规划和行动，在清晰边界内释放模型的灵活性，适合处理路径开放、需求多变、长尾价值高的任务。
对于企业级系统建设而言，从“把AI作为工具嵌入软件”，到“把软件能力交给AI调度”，企业并不是在两种对立路线中做取舍，而是在构建一套新的能力分层。谁来决定下一步，在哪里必须保留确定性，在哪里可以释放自主性，这些判断将成为未来企业智能体架构设计的核心。只有把这些问题想清楚，企业才能真正把AI从局部提效工具，升级为可治理、可扩展、可持续演进的生产力系统。
