推荐语

在技术演进中，如何平衡workflow和模型的使用？本文提供了实用的分析框架和决策指南。

核心内容：
1. 新场景构建时workflow和模型的选择依据
2. 已有系统演进中workflow细分和模型发展的权衡
3. 业务实践中等待与权宜之计的商业考量

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

一个很常见，但似乎没有专门讲过的问题。

新场景构建

新场景构建，最主要的是尽快验证技术上能做出符合要求的效果。一般都是先从整个问题开始，如果发现解决的不够好，就逐步拆解，直到在研发成本可控的范围内作出一个类workflow方案，或者发现做不出来。

如果光靠workflow做不出来，或者需要的研发时间太多，最终方案可能过于复杂时，应该考虑通过模型的方式解决，在应用层一般考虑的都是SFT或者RFT，根据场景特点进行选择。有一些场景可能需要正经的合成大量数据以及经过更大计算量的训练，这里不再展开。

在一些非常开放、现有方案baseline效果很低的场景中，也可以以一种类似AutoGPT的方式来构建，例如Devin/Manus/Genspark这样的方式。

已有系统的演进

在长期演进上，哪些方面应该更细分的拆解workflow，哪些地方应该等待模型发展，哪些方面应该考虑自己训练，我认为一个重要的因素是，是否有有效的中间过程检查验证方案。

如果知道一个任务的完成必然需要通过单一路径上某些阶段（或者几种路径之一），并且在这些阶段上可以进行非常可靠的检查验证，那么这个场景就更适合在这些环节进行拆分，插入验证工具，在发现验证不成功时进行打回。从RL的视角来看，这个验证方案实际上就是PRM（Process Reward Model）。

简单来说，就是存在有效PRM的环节就应该拆分；不存在有效PRM的环节，虽然在过程中会需要一些权宜之计的workflow设计，但长期会朝着融合方向发展。

在融合的方向中，到底是要只调用模型做Agent，还是要自己做一些模型训练，取决于具体场景。这两个细分路线都是靠模型的智能来解决问题。

这里还有一个方面是对人的可解释性。增加可解释性并不意味着提升整个系统的效果，甚至时常会牺牲模型的效果。但具有一定的可解释性经常是一些系统的必要需求，这应该视为一个功能性需求，而不是一种模型优化方案。在需要可解释性的环节，往往需要拆分出一些环节，提取中间结果进行展示。甚至会需要设计一些为了方便人类操控的控制方式来对系统进行干预。

是否要等待

在实际业务中，到底要等待还是先做一个权宜之计，是个复杂和关键的商业考量，需要具体场景具体分析。

抛一个方便思考这个问题的直觉泵：如果这个权宜之计的80%的工作量和价值都在半年之后被新发布的模型所颠覆，还是否要在现在做这个权宜之计。

Workflow是否该被淘汰了

既然我写了这个文章，就表明我认为它们都有用武之地，并非全方位的被替代。

以及还有一点要提醒：所有已经PMF的方案都不需要去改动，除非有强烈的其他需求。研发成本需要被均摊掉，技术方案变化也很快，等待0.5-1年再评估是一个不错的周期。