新场景构建

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

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

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

已有系统的演进

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

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

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

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

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