微软、OpenAI大佬暗示LLM应用开发范式迁移：从Prompt Engineering到Flow Engineering

最近，有一篇论文《Code Generation with AlphaCodium: From Prompt Engineering to Flow Engineering》受到了各方的关注，特别是OpenAI技术大佬Andrej Karpathy对论文中提出的Flow engineering范式点评转发，将该论文热度推向了很高的位置。

它的核心思路是，利用多次生成测试反馈迭代的方式替代原有精心构造Prompt一次性生成的方式，最终在验证集上，GPT-4的准确率（pass@5）从使用单个精心设计的Prompt的19%提高到使用AlphaCodium流程的44%。

笔者认为，它的热度高，并不在于本身论文本身解决的问题水平如何，而是它提出了“Flow engineering”的概念，指出了未来LLM应用开发者应该重点关注的方向。

在以往大模型开发中，应用核心开发重点在于prompt engineering，这多见于一些RAG应用，也就是整个过程围绕如何精心构造Prompt，再利用Prompt诱导大模型生成一个好的答案，而这一过程往往是单次的，它们往往难以系统解决大模型存在的幻觉，不一致等问题，甚至有人研究给大模型多少小费可以提高效果的尝试。

但实际上，这样的模式显然无法满足人类对大模型的期待。因此，LLM应用从趋势上看，逐渐朝复杂的流程组织，以及模型基于环境反馈的自我迭代循环纠错的方向发展，而这就是Flow Engineering。从应用模式上看，其实就是我们所谓的Agents和多agents的应用。正所谓，“效率提升的终点是替代人，RAG的尽头是Agent”。对Agent感兴趣的朋友可查看本公众号文章《一文探秘LLM应用开发(24)-Prompt(架构模式Agent)》。

从某种意义上讲，大模型应用开发变得更加务实，从一个模型算法问题转变成为一个工程问题，如何将复杂问题拆解为多个子任务或者子agent执行，如何编排协调，如何处理数据，如何选择合适工具，如何迭代优化，如何人机协作成为了做好LLM应用的关键。以AlphaCodium为例，他们花在flow engineering上的时间占到了整个工作的95%。

而当下层出不穷的agent，特别是MultiAgent框架或平台以及创业项目就能反映问题，比如langchain新推出了Agent开发框架langgraph，微软出了Task weaver，Autogen等库或框架，并且近日AutoGen发布了2.0版本，提供了NoCode的Studio工具（AI Agent Builder），低门槛编排自己的Agent应用（后续介绍给大家）。微软CEO Satya Nadella甚至在一个访谈中表示，MultiAgent将是LLM时代的关键应用运行时（the key runtime of our times）。那么如何才能构建一个好的易用MutiAgent应用开发框架以及可落地的MultiAgent应用呢？这一命题值得当下应用开发者充分关注研究实践。