Workflow design

随着2023年大模型在国内的发展成熟，现在大家逐步开始真正关注到大模型应用的开发上。有人说，2024年是大模型应用的落地元年。的确，看似无所不能的大模型，也并不是直接丢到一个系统就能用的，如何开发大模型应用，实际上还处于一个刚起步的阶段。一些成熟的技术，经历过许多人摸索后，总能给出一个”best practice“；对于大模型应用开发来说，却仍还在探索阶段。 目前，一个看起来比较靠谱的模型，是这样定义大模型应用开发的几个level的：

最简单的Wrapper层级，实际就是把大模型的提示词封装成一个固定功能的”方法“，然后集成到业务系统中。KPP的Function（或者Prompt），就是一个Wrapper。Wrapper能做什么完全取决于大模型的能力，比如生成一段文字，甚至写一段代码，都没有问题。但是如果想做一个复杂的功能，恐怕就不行了，比如，先生成代码再执行得到代码运行结果，这样就没法直接通过大模型请求来做了，原因是大模型本身无法直接执行代码 。

显然，对于复杂的功能，我们可以尝试分步骤来解决。比如一键生成PPT就是很好的例子，第一步先生成一个outline；然后再根据outline，去填充内容；最后通过一个生成文档的API生成一个美化后的PPT。这样每一步都可以用最适合的技术来进行，比如生成outline和填充内容用LLM，可以选择最合适的模型；美化PPT则可以直接使用已有的API来处理。

这其实就是Flow了，或者更明确一点，Agentic Workflow。不是普通的工作流，是“智能”的工作流。通过流程的编排，我们可以扩充LLM的能力，通过一些组合来实现复杂的业务功能。相对于Wrapper而言，Workflow可以更好地实现复杂的AI能力。 因此，我们在KPP中也实现了Workflow的能力。这里就技术层面分享一下KPP在构建Workflow时的一些设计和实现。

为什么坚持要自研？

实际上，在开始设计工作流之前，就已经有不少公司已经在做了。其中最具有参考价值的主要是Dify和扣子。其中，Dify是一个开源的系统，理论上可以直接拿过来用。 但是，考虑到WPS AI的实际情况，有几个比较重要的问题是Dify难以支撑的：

•无法直接嵌入到WPS AI的现有体系，包括网关、KPP、AI Server等，一定会存在一个二次开发的成本 •Dify是用Python写的，如果大规模使用，很可能会遇到性能问题，包括工作流本身的异步多线程执行、以及水平扩展的性价比

实际上，字节的Coze是一个非常适合我们的开发平台。它的产品设计相当专业和完善，Workflow、图像流、Agent、多Agent协作等，是目前所有平台中定义最清晰的。相对而言，一些平台自己都不知道自己在做什么，比如百度的Agent Builder和App Builder，做着做着就成一样的了。 Dify在这方面也有明显的问题，看起来还没有搞清楚Agent和Workflow的关系。 然而很遗憾目前为止没有一个开源的系统可以达到Coze的高度。正是由于种种原因，最终KPP决定完全自研Workflow系统。

关于为什么要做Workflow，感兴趣可以从这里了解一些其他的信息。