Agent与Workflow的技术落地实践与思考

从概念混淆到清晰认知

最近半年，Agent落地到越来越多的业务场景中，但实际上真正意义纯粹的Agent(完全自主化)在很多实际场景中并未达到完全自主可用的程度。结合模型能力与实际落地场景条件，目前实际落地的技术路线分化出四个主要技术线路：预定义规则的Workflow，完全自主的Agent，结合workflow和agent特点的混合模式Agentic Workflow，和扩展到自主协作的Multi-Agent。

在实践中可能会遇到困惑是：这四种模式的区别到底在哪里？到底该怎么落地？ 尤其是伴随强化学习（RL）在agent领域的快速技术演进，对工程落地又有什么具体影响？

目前实际在agent落地上，大家都在说Agent，但做出来的东西差别很大。有的团队做的其实是固定流程的自动化，只是套了个"智能体"的名字；有的让LLM自主决策，结果发现实现不了业务目标而且很不可控，而有的场景似乎agent和workflow都能用，在两者之间反复摇摆，那又该如何平衡呢。本文结合自身的实践和调研，聊聊如何理解这些技术路线，在实际项目中如何进行选择、实施和迭代。

理解技术选型的两个维度

在实际项目中，可以用两个维度来切分不同的模式：自主性（Autonomy）和协作性（Collaboration）。

自主性指的是系统在运行时自主决策的程度。Workflow的自主性较低，每一步都是预定义的；Agent的自主性很高，它会根据当前状态动态选择下一步行动。

协作性指的是系统内部多个组件或角色之间的协同程度。简单的线性流程协作性低；多个Agent之间需要消息传递、状态同步的系统协作性高。

这两个维度构成了一个技术选型的坐标系：

• • Workflow：低自主性、低协作性。适合流程固定、步骤明确的场景
• • Agent：高自主性、低协作性。单个智能体自主完成任务
• • Agentic Workflow：中高自主性、中等协作性。结构化框架内的灵活决策
• • Multi-Agent：高自主性、高协作性。多个专门化角色的协同工作
• 
  
  

可以从这个坐标系出发，分析场景对自主性和协作性的需求，再结合系统复杂度和可控性来选择适用场景的技术模式。

两个关键判断问题

结合两个技术维度，我们可以进一步扩展为两个具体的问题来进行场景判断：

1. 1. 下一步该干什么，是提前确定，还是运行时动态决策？
2. 2. 任务是单一Agent完成，还是多个不同角色协作？

对这两个问题进行回答，根据答案就能大体对四个模式确定一些有代表性的适用场景了。

• • Workflow：流程固定明确 + 单一执行路径 → 财务对账、审批流程等
• • Agent：流程灵活多变 + 单一智能体 → 结构化抽取、智能报表等
• • Agentic Workflow：部分固定部分灵活 + 可能需要协作 → 绝大多数企业场景
• • Multi-Agent：高度灵活 + 明确角色分工 → 代码审查、多源数据分析等
• 
  

四种模式的技术本质

当然真实的业务场景并不是通过两个技术维度就能确定技术路线的，技术和场景是否真正契合，也需要对技术本身有更深入的认识。

Workflow：确定性的价值

Workflow的核心特征是预定义的执行路径。LangGraph将工作流定义为"通过预定义代码路径编排LLM和工具的系统"[1]。它像流水线一样，每个环节都是明确的、可测试的。

在企业场景中，Workflow特别适合那些逻辑固定、需要严格审计的业务。比如财务对账：收集数据→规则校验→异常标记→生成报告。这个流程可能有分支（如果金额超过阈值走特殊审批），但整体结构是确定的。

Workflow的优势很明显：

• • 可测试性强：每个节点都可以独立测试
• • 易于审计：执行路径清晰，出问题容易追溯
• • 性能可预测：知道会调用哪些服务，可以提前优化

但劣势也同样明显：缺乏适应性。当遇到预设路径外的情况，Workflow往往无能为力。这时候就需要修改流程定义、重新部署，响应速度慢。而且一旦场景复杂度比较高，工作流的维护会变得非常困难。

Agent：运行时的灵活性

Agent的关键在于运行时自主决策。Agent的基本概念大家都比较熟悉了，现在我们提到的agent泛指以LLM为核心的agent，所以可以把agent理解为结合LLM动态指导和使用外部记忆组件，在自动规划的流程中迭代使用工具来完成任务，并始终由agent来做出每一步的决策规划控制的自动化系统。它不需要预先知道所有可能的情况，而是根据当前观察到的状态来决定下一步。

典型的Agent工作循环(一般React[1]模式用的最多)是：

1. 1. 观察当前状态
2. 2. 思考可以采取什么行动
3. 3. 选择一个工具执行
4. 4. 观察执行结果
5. 5. 决定是继续还是结束

这种模式特别适合开放式任务。比如大家比较熟悉的DeepResearch，用户的输入和表达是高不确定性的，内部进行多少次搜索（也有加入tree搜索的设计），搜索到的内容是否能支撑研究，这个是没法预定义，但是最终交付的内容也不要求一定是完全准确的，有一定容错空间，这样场景就很适合agent。

所以实际Agent应用到真实场景也存在这些问题：

• • 行为不可预测：同样的输入可能产生不同的执行路径
• • 调试困难：出错时很难复现问题
• • 风险控制难：可能执行预期外的操作

在涉及敏感操作的场景，纯Agent模式风险较大，比如在用coding agent打开solo时(agent自主模式)，特别需要使用git进行代码管理，否则可能存在某个模块代码被误删而无法恢复的情况。

Agentic Workflow：务实选择的价值

Agentic Workflow是目前在实践中发现最实用的一种模式。这个概念其实没有完全清晰的定义。因为workflow本身的覆盖面就很广，再加上agentic这个概念现在也是广泛使用，两个组合在一起也很难有一个清晰的定义。

IBM[2]将它定义为："AI Agentic workflows approach complex problems in a multistep, iterative way, enabling AI agents to break down business processes, adapt dynamically and refine their actions over time.",强调的是对复杂任务的拆解迭代执行，这个本身就是agent的特点，实际上没有表达workflow的约束。

waveiate一篇技术博客[3]定义为："An agentic workflow is a series of connected steps dynamically executed by an agent, or series of agents, to achieve a specific task or goal. Agents are granted permissions by their users, which give them a limited degree of autonomy to gather data, perform tasks, and make decisions to be executed in the real-world",强调的是一个或多个agent获取特定权限收集数据，执行任务做出决策，也没有清晰定义和agent的边界。

结合实际经验和相关调研反馈，我就把它理解为workflow和agent综合的一个概念，agentic workflow是在一个既定的工作流程的多个节点中，将其中一个或多个节点换为Agent在自己的节点做出自主决策完成该节点任务，但多节点整体的运行是在结构化流程的框架内进行的。外层的流程保证了可控性和可审计性，内层的Agent提供了必要的灵活性。

客服助手就是Agentic Workflow比较适合的场景。通过agentic workflow构建的客服系统，可以处理从客户支付到退款的各种任务。系统有明确的流程框架，包括接收请求、路由分类、执行操作、生成回复，但在具体处理时，Agent可以灵活选择查询哪些数据、如何组织回复、是否需要人工介入。

这种设计的关键是定义好边界：

• • 什么必须固定：关键检查点、权限验证、日志记录、异常处理
• • 什么可以灵活：对多样性输入的处理，具体的执行策略、回复的组织方式、工具的选择顺序

这个模型刚好能在agent和workflow中间找到一种平衡。

过渡形态不等于技术落后

有人可能会说，Agentic Workflow是妥协方案，等Agent能力够了就应该用纯Agent，如果Agentic Workflow是一种过渡形态的技术，那它的技术价值在哪里呢。我认为这个观点可能忽视了工程落地的复杂性。

这就像自动驾驶领域的演进路径。选择直接做L4虽然是一种比较有技术前瞻的选择，但是要实现量产，比较可行的方案还是从L2过渡到L3一样，但是过渡形态不代表就没有技术演进，反而演进很激烈，就这两年，自动驾驶从bev->无图->noa->端到端（两段式，一段式），端到端现在又逐渐分化出VLA和世界模型方案了。技术落地需要考量多方面的因素，包括安全性、成本、监管、用户接受度等，选择切合当下实际的相对保守方案再逐步迈进到激进方案可能是一个综合相对更优的选择。

同样地，Agentic Workflow可能也是当前落地比较推荐的一个技术方案，因为它可以在可控和自主之间有比较大的调整空间。

• • 风险可控：关键路径有明确约束，不会完全失控
• • 成本合理：不需要为每个决策都调用LLM
• • 可维护：出问题知道在哪个环节，怎么修
• • 渐进演进：可以逐步扩大Agent的自主范围

而且，过渡形态内部的技术演进同样激烈。就像自动驾驶从BEV感知到无图化，再到端到端，技术路线在不断迭代。Agentic Workflow内部也在快速演进—更准确的意图理解、更可靠的工具调用、更稳定的长程执行能力、更有效的记忆管理。

选择当前能落地的方案是优先考虑，但保持技术视野同样重要。技术迭代很快，今天的最佳实践可能半年后就过时了。在实施Agentic Workflow的同时，要预留技术探索的空间，关注Agent背后的模型能力提升，持续评估新技术的可用性来不断调整优化架构。

Multi-Agent：协作的复杂性

Multi-Agent是在协作维度上的扩展。它不是让一个Agent包办所有事情，而是让多个专门化的Agent各司其职，这和人类工作的分工协作是一样的机制。

在一个Multi-Agent系统中，不同的agent被定义为特定角色，拥有不同的专业化能力去处理特定的任务，通过工作分配、协作完成复杂任务。比如一个文档审核系统，可以设置一个工作流，因为它的流程是固定的，内容提取和标准化，规则检查和风险评估，审核报告对应不同的节点。但是如果要模拟一个软件开发团队来完成复杂项目开发，就需要Multi-Agent才能处理频繁的协作和不同专业任务执行了，chatdev[4]和metagpt[5]都是基于multi-agent设计的实现模拟软件开发团队的技术方案。

这个模式将复杂任务拆解到个体agent上，具备协作优势的同时实现了功能解耦：

• • 责任清晰：每个Agent只需关注自己的领域
• • 可并行：某些Agent可以同时工作
• • 易维护：修改一个角色不影响其他

但复杂度也是真实的：

• • 协调开销：需要消息传递、状态同步
• • 调试困难：问题可能出在任何一个Agent或它们的交互上
• • 成本高：多个Agent意味着更多的LLM调用

但是在实际项目中，由于这个模式的不稳定性，复杂度，成本都是四种模式中最高的，目前multi-agent能落地的一般也是中心化方案，而且需要在外层加很多限制保障可控，所以一般只在明确需要并行处理、角色隔离或异质技能时才考虑用Multi-Agent。大部分场景，一个设计良好的单Agent加合理的工具就能够了。过早引入多Agent容易把系统搞复杂。

强化学习趋势对工程实践的影响

上面提到过agent的技术变化很快，接下来需要谈一下技术发展变化对工程实践的影响。近一年强化学习在Agent工程化中有两个明显的趋势，它们对我们的工程实践提出了新的要求。很明显的趋势就是RL后训练对Agent能力的快速提升—包括推理能力、工具调用能力经过RL后训练后都得到有效增强，在复杂长程Agent任务上有了比较明显的性能提升。

RLVR：用程序化验证替代人类反馈

传统的RLHF（人类反馈强化学习）依赖人工标注者对模型输出打分，这个过程主观、成本高、速度慢。RLVR（强化学习与可验证奖励）的创新在于当任务有明确的对错标准时，直接用程序化验证器来判断。OpenAI o1和DeepSeek R1是RLVR的集大成者，因为它们分别在闭源和开源领域使得此范式在LLM领域上得以开始展现time scaling law的威力。

它用验证函数替代奖励模型，只有当模型输出可验证正确时才给予奖励。这种方法在数学问题、代码生成、指令遵循等可验证任务上显示出显著提升。

可验证奖励的本质是提供明确的、二元的真值信号—"1"（正确）或"0"（错误）。与依赖学习到的奖励模型相比，它的优势在于：

• • 无偏差：不依赖人类主观判断
• • 可靠：基于确定性规则，不会漂移
• • 快速：程序化验证比人工标注快几个数量级
• • 难以欺骗：二元信号没有灰色地带，模型很难找到漏洞

RLVR的适用边界与现实挑战

但是，RLVR不是万能的。它有明确的适用边界：

适合RLVR的场景：

• • 结构化数据抽取：验证器检查JSON Schema、字段完整性、类型正确性
• • 代码生成：通过测试用例、编译检查、静态分析验证
• • 格式转换：验证输出格式是否符合规范
• • 规则验证：检查是否满足明确的业务规则

不适合RLVR的场景：

• • 开放式文本生成：无明确对错标准（如创意写作、营销文案）
• • 主观判断任务：需要人类偏好（如情感分析、风格评价）
• • 多步交互任务：单次验证不够，需要环境支持
• • 复杂业务逻辑：难以用程序完整表达验证规则

实际落地的困难

在企业场景中应用RLVR，最大的挑战不是技术本身，而是奖励函数的可验证性在很多业务场景难以定义。

举个例子：客服对话质量评估。你可以验证回复格式对不对、有没有调用正确的API、数据查询结果是否准确，但很难验证回复是否"亲切"、"专业"、"让客户满意"。这些软性指标难以程序化。

再比如：文档摘要质量。你可以检查摘要长度、是否包含关键词、语法是否正确，但很难验证摘要是否"抓住要点"、"表达清晰"。这需要人类判断。

因此，实际应用RLVR需要：

从细分领域入手：不要一开始就想用RLVR优化整个系统。找到可验证的子任务，先在这些子任务上应用。

评估性能指标转化：仔细评估业务指标中哪些可以转化为可验证奖励。转化不了的，不要强行使用RLVR，可能效果反而不好。

建设验证器资产：验证器不是一次性写完就行，而是持续积累的资产。从简单的格式检查开始，逐步扩展到语义验证、业务规则验证。验证器本身也需要测试和维护。

警惕验证器的误报和漏报：程序化验证也会出错。要定期审计验证器的准确性，建立反馈机制。发现问题要及时修正。

但是实际上要实现这四个RLVR目标难度挺大的，还需要投入算力资源和算法资源，RLVR后训练难度也高于一般的sft，容易出现训练崩溃的问题。但一旦企业在agent落地的场景已经明显受限于商用模型成本，agent的推理规划和工具调用能力明显受限，通用能力无法满足的时候，就可以考虑RLVR进行后训练了，但一般会先用sft进行冷启动，也需要构建合成对应long cot、工具调用数据进行微调，这个需要结合企业自身的基础资源进行投入评估。

多回合(multi-turn)RL：交互式任务的未来趋势

另外一个很明显的趋势就是多回合的RL训练，其实和第一点RLVR也相关，但关注点不同，多回合RL强调的是训练环境和推理环境的统一。怎么理解呢，就是在训练的时候，就构建了和生产使用一样的环境，提供了需要使用的工具和执行器，可以实时获得结果，模型根据结果给与reward进行RL训练。训练完成后，这个模型放在和训练环境一致的测试/生产环境，就能将训练提升的能力在真实环境得到有效发挥。更进一步说，模型即agent的终极目标就是agent实现端到端，不再依赖特定框架，当然这个目标还比较远，但趋势就在往这个方向发展。

这种模式是未来Agent的技术发展趋势，未来的Agent形态大概率就是从这个模式演化的，从而具备更强的场景适配性和泛化性，实现广泛落地。

现阶段的多回合训练如上面提到的受限于RLVR的可验证奖励，一般会集中在特定领域范围，比如数学计算，coding，wab搜索场景。相关的研究工作也很多，比较经典的，比如WebArena[6]，它提供了完整的Web应用环境（电商网站、论坛、内容管理系统），Agent需要完成复杂的多步任务，比如"找到价格在50-100美元之间的蓝色夹克，加入购物车并使用优惠码"。

这类RL在训练和使用场景存在不小挑战：

环境并发与隔离：训练需要同时运行几百个环境实例，每个环境要完全隔离。这意味着大量的容器、虚拟机或沙箱管理。一个环境崩溃不能影响其他。

状态重放能力：每次训练episode应该能从相同状态开始，这样才能比较不同策略的效果。对于Web环境，这意味着数据库快照、浏览器状态保存、网络请求录制回放。

训练-部署一致性：最容易被忽视但最重要的一点。训练时用的工具、权限、网络环境必须和生产环境一致。否则训练出的策略在真实环境中不work。这要求企业必须提前建立可复现的环境和严格的过程评测机制。

资源成本管理：多回合环境RL的计算成本很高。一个训练轮次可能需要几百个GPU几天时间。需要仔细设计训练策略，避免浪费。

Agent的RL环境工程可能是最有价值的工程化技术。很多人还没认识到它的重要性，实际上这很可能是RL Agentic范式落地最关键的基础设施。关于RL在Agent上的技术进展，可以参考Agentic RL Survey。

在实际项目中，有明确的价值验证后，再考虑引入多回合RL。这种训练基础设施的投入很大，不适合早期探索。有相关算法基础和资源的企业可以尝试，但要做好长期投入的准备。

工程落地的核心实践

其实不管选择哪种技术方案，有几个工程实践是共通的，是agent落地实践可以参考的相关准则经验。

结构化输出：消除格式不确定性

Agent最常见的问题之一是输出格式不稳定。有时返回JSON，有时返回纯文本，JSON格式还可能不对。这导致下游处理充满了容错代码。

解决方案是强制结构化输出。OpenAI、Anthropic、Google的模型API都支持JSON Schema约束。定义好输出Schema，模型保证返回符合格式的JSON。

这不只是个便利性问题，而是可靠性问题。在Agentic Workflow中，一个节点的输出是下一个节点的输入。格式不稳定会导致整个流程失败。

实践中，一般会考虑清楚哪些llm api调用需要结构化输出，给工具定义明确的输入输出Schema，并在接口层做严格验证。类型不对直接拒绝，尽量避免"智能容错"掩盖报错。

可观测性：看见Agent在做什么

Agent的行为不像传统程序那样确定，调试困难。可观测性变得至关重要。

关键是要记录过程，不只是结果：

• • 每个Agent循环的轮次
• • 每次工具调用的参数和返回值
• • 每次决策的理由（如果LLM提供的话）
• • 状态转换的轨迹

建议设计一套标准可审计日志系统和对应的分析工具，方便对问题进行定位。

但光有追踪还不够，还需要评测。要区分过程评测和终态评测：

过程评测：

• • 任务规划是否合理？
• • 工具选择是否合理？
• • 推理链是否逻辑自洽？

终态评测：

• • 最终答案是否正确？
• • 是否满足所有约束？
• • 副作用是否符合预期？

只看终态结果容易被模型本身的不确定性误导。Agent可能推理过程错误，但碰巧得到了对的答案。这种问题是最隐蔽和最危险的，特别是上线后突然发现，但是缺少可观测性就难以定位根因。

权限与安全：最小化攻击面

Agent能够调用工具执行实际操作，权限是agent在生产使用需要重点考虑的问题。

最小权限原则：每个Agent只能访问完成任务必需的工具和数据。客服Agent能查订单，但不能访问其他客户数据；代码Agent能在沙箱执行代码，但不能访问生产数据库。

操作分级：查询类操作可以自由执行，修改类操作需要额外验证，敏感操作（如大额退款、删除数据）必须有人工审批。

审计日志：所有工具调用都要记录——谁调用的、什么时间、什么参数、什么结果。出问题时能追溯。

沙箱隔离：代码执行、网页访问这种高风险操作必须在隔离环境中进行。网络限制、文件系统限制、资源配额都要设置好。

agent方案的自主性越高，安全性考虑也就要越重视，特别是设计到安全/容错性低的场景，需要做好限制措施来做预防，上线前需要通过充分测试来评估。

落地实施的思路

那如果现在要从零开始构建生产级Agent系统，结合上文的技术分析和落地实践，我们可以实行分阶段推进，每个阶段都有明确的目标和验证点。

第一阶段：基础设施先行

在写任何业务逻辑之前，先把基础设施搭好：

• • 统一的工具接入规范（建议参考MCP协议的思路）
• • 结构化输出的强制机制
• • 可观测性平台（追踪、日志、指标）
• • 安全护栏（内容过滤、权限控制、审计日志）

这些看似枯燥，但没有它们，后面的工作会很痛苦。调试困难、出问题难定位，会产生很大的“技术栈”。

如果后面需要考虑上RL，在这个阶段也要梳理场景的可验证点。什么任务能验证？怎么验证？验证器本身准确吗？这些搞清楚，后面引入RLVR才有基础。

第二阶段：选一个场景验证价值

不要一上来就想做大而全的系统。可以先选一个具体的、有价值的模块，快速验证技术方案的效果。

好的起步场景特征：

• • 需求明确：知道什么算成功，什么算失败
• • 风险可控：出错不会造成严重后果
• • 可量化：能用数字衡量改进（响应时间、准确率、成本）
• • 用户痛点真实：不是为了技术而技术

对于想把传统IT/AI项目改造为agent方案的项目，建议先用Agentic Workflow重构这个场景的1-2个核心流程。外层用Workflow保证可控，关键节点嵌入Agent提供灵活性。小规模进行测试，并收集真实反馈。

第三阶段：迭代优化与扩展

有了第一个场景的经验，就可以开始系统化地优化和扩展：

建立评测体系：不能靠感觉判断系统好不好。要有明确的指标、自动化的测试、定期的评审。过程指标和终态指标都要看。

优化提示词和工具：根据失败案例分析，哪些是提示词问题（Agent理解错任务），哪些是工具问题（工具功能不够），哪些是流程问题（Workflow设计不合理）。针对性改进。

异常处理完善：真实环境中会遇到各种边界情况。网络超时、服务不可用、数据格式异常。这些都要有明确的处理策略。但注意对于agent项目，在开发阶段和生产阶段的异常处理策略有很大差别，开发阶段如果一开始就开放异常处理，会造成“看上去正确但效果差，但又无法定位原因”的现象，很可能是其中的某个节点发生了回退，但是流程继续往下走导致的。所以在开发阶段可以设置全局开关区分dev和production模式，这样能避免回退吞没错误，同时也能知道回退可能产生在哪些节点，进行针对性的agent优化和兜底优化。

这个阶段要投入足够的时间。很多团队可能急于上更多场景，结果第一个场景还没做稳定就开始做第二个，发现问题越积累越多，但是找不到根因。

第四阶段：选择性引入RL

有了稳定的基础，对于适合的子任务，可以尝试引入强化学习优化。这个阶段适合agent已经稳定运行一段时间，积累了相关的业务数据，同时有算法，算法资源支持的团队。

避免的常见陷阱

最后再来谈一下实际开发的一些陷进，可以参考有针对性的避免。

过早引入Multi-Agent

有的项目为了尝试新技术，一开始没有做细致的场景技术分析，就设计复杂的多智能体系统，这样很可能会高估multi-agent的效果而低估了它的开发难度。

判断是否需要Multi-Agent的标准：

• • 是否有明确且不同的专长需求？（不是为了分而分）
• • 是否有真实的并行处理收益？（不只是理论上能并行）
• • 是否有清晰的角色与协议？（不是一团混乱的消息传递）
• • 是否能承受额外的成本和复杂度？

如果答案有任何一个是否定的，就先不要用Multi-Agent。一个设计良好的单Agent系统能承担绝大部分的现实场景任务，而且单agent也是实现multi-agent的基础，就算评估当前场景适合Multi-Agent，暂时不用设计复杂的通信，协作模式，可以先以单agent作为切入点，用workflow来进行任务编码，再逐步扩展为multi-agent可能是更稳妥的选择。

忽视环境可复现性

开发时能跑通，生产环境就出问题，根本原因往往是环境不一致。

必须保证：

• • 依赖版本明确锁定（Python的requirements.txt、Node的package-lock.json）
• • 网络访问白名单化（不能让Agent随便访问互联网）
• • 文件系统限制（只能访问指定目录）
• • 资源配额明确（内存、CPU、超时时间）
• • 随机性可控（设置seed，关键决策可重放）

做自动化测试时，环境可复现性更加重要。很多问题如果无法复现，优化就无从提起了。

只看结果不看过程

Agent给出了正确答案，就认为系统工作正常。这是很危险的想法。

可能的情况：

• • Agent推理过程一团糟，只是碰巧对了
• • Agent调用了错误的工具，但工具返回的数据恰好能用
• • Agent违反了某个约束，但这次没造成问题

下一次遇到类似问题时，运气可能就没这么好了。

必须建立过程监控，理解Agent是怎么得到答案的。工具调用序列对吗？推理链合理吗？有没有违反约束？这些都要检查。

总结与展望

回到最初的问题：在Workflow、Agent、Agentic Workflow和Multi-Agent之间如何选择？

答案取决于业务场景的自主性需求和协作复杂度。大多数企业场景适合Agentic Workflow—它在可控性和灵活性之间找到了平衡点。这不是技术上的妥协，是现阶段结合工程落地考虑的推荐选择，而且agent的技术方案本身就是在快速迭代发展的，今天的讨论分享可能3个月后就失效也是可能的。

而强化学习的快速演进趋势（RLVR和多回合环境RL）为进一步提升系统能力提供了扩展技术思路，但它们对工程基础设施的要求更高。比较推荐的做法是先把Agentic Workflow做稳定积累到相关的业务数据，再选择性地引入RL优化。

Agentic智能系统的工程实践并非简单调用大模型。 要实现稳定可用的AI工程，除了选择适配的技术模型，还需要建设面向Agent技术栈的基础设施、评测体系和审计验证流程。

同时，留有技术探索空间是非常有必要的。Agent的技术迭代非常快，不保持对技术的跟进和学习探索，很可能你的技术方案很快就滞后于行业最佳实践。强化学习的趋势进一步带来了提升与挑战，工程化上还需要考虑模型能力增长对原有架构设计、工程实现的冲击。

技术选型没有银弹。关键是理解不同方案的适用边界，结合具体业务需求做权衡。过度工程化和能力不足都是问题，找到平衡点才是真正的挑战。

明确资源成本并持续投入技术基础建设以及新技术探索，才能真正实现Agentic智能系统的可持续发展与长期价值创造。