智能体应该开发中——灵活性和稳定性之间的抉择

在前面几篇文章中介绍了人工智能应用中大模型所扮演的角色，以及提示词在其中的重要性和作用；但在之前的文章也介绍过智能体，工作流之间的关系，我们今天讨论的就是智能体实现过程中，怎么兼顾灵活性和稳定性，以及为什么会有工作流的存在。

关于智能体的实现或者说关于大模型应用的开发，其核心都是围绕大模型所展开；但大模型有一个很大的问题就是其输出不稳定，因此这也成为智能体开发过程中无法避免的一个问题。

毕竟不能因噎废食，不能因为大模型输出不稳定就不做智能体了；因此我们需要找一些解决方案来解决这个问题；而其中比较简单的解决方案就是把复杂的智能体拆分成一个个小模块，以局部最优解的思路达到全局最优解。

但拆分之后的小模块怎么串联起来呢？使用硬编码还是使用工作流，或者是其它方式？

从灵活性的角度来说，基于大模型构建智能体我们应该把所有的功能模块都交给大模型进行处理和调度，尽量弱化人类在其中的作用；但由于大模型的不稳定性，就间接导致智能体的不稳定性，特别是调用链路比较长时；局部的不稳定性就会随着链路被无限放大。

因此，这时工作流的作用就体现了；通过工作流，可以把智能体的不同模块串联起来，在其中需要人为决策或者容易出现问题的地方，交由人类介入处理；这样通过人为干涉就可以进来保证智能体运行的稳定性。

但这里就存在一个问题，在一些固定场景中使用工作流是没有问题的，但如果在变化比较大的场景中或者业务比较复杂的场景中，工作流可能就不那么好用了，这时可能灵活性更重要。

因此，面对这种问题时应该怎么处理？

是应该为了保证灵活性而放弃稳定性，亦或者是为了保证稳定性而放弃灵活性。

我想，这对很多人或者很多场景来说都是一个两难的抉择；稳定性意味着相对简单，但扩展性差，灵活性意味着复杂，稳定性差；而从成本的角度来看，稳定性需要根据不同的场景开发不同的智能体，而灵活性由于其功能比较复杂，其技术开发成本高。

以我们自己公司的数据分析智能体为例，使用工作流和硬编码的方式可以解决数据分析的准确率问题；但在产品开发过程中，其灵活性下降需要根据不同的场景开发不同的功能。而我们公司目前由于产品的业务场景较复杂，更多的需要的确实灵活性，但在前面的介绍中也说明了，灵活性会导致智能体的输出不稳定，一个小错误会被无限的放大。

所以，在真实的开发场景中，到底应该选择稳定性，还是选择灵活性；需要根据自己的业务需求做抉择，而其更像鱼和熊掌，两者不可兼得。

但两者却可以合作，在一些比较重要的场景中，我们可以选择稳定性较高的开发方式；而在一些非核心业务中，可以使用灵活性更高的开发方式。