由 ComfyUI 启发的一种 QT 应用软件架构

之前写过一篇文章《一种基于插件的QT软件开发架构》，介绍了在QT项目中采用插件架构，增加软件的可维护性和可扩展性，取得了一定的效果。然而，面对越来越多的客户定制需求，我们依然面临着许多挑战。

作为软件方案提供商，我们面临的压力主要来自以下几个方面：

1. 用户需求多样化：现在，AI应用种类繁多，有用于制作PPT的、绘画的、语音输入和翻译等各种使用场景。客户可能需要其中的一个或几个功能，也有的客户全都需要。这就要求我们提供一种可以快速交付的弹性方案。
2. 实现层面的多样化需求：接入大模型的需求各不相同。有客户希望接入百度，有客户希望接入讯飞，还有海外客户可能希望接入谷歌等。这就需要我们提供一种灵活的可配置方案。
3. 产品形态的多样性：系统接入的设备种类繁多，如智能鼠标、键盘、耳机、录音笔等，系统输出可能是声音、文字、视频等。这意味着我们需要提供一种统一的、通用的输入输出框架。

当然，我们并不奢望为用户提供二次开发的方案。类似于高通提供的SDK开发包或字节跳动提供的AI Agent开发平台，这不是一个小公司能够做到的。我们希望尽可能通过代码复用和配置文件修改，就能交付给客户一套定制化的软件。

面对这些挑战，我一直在思考，如何设计软件架构，才能将我从疲于奔命的状态中解救出来。直到前段时间看到ComfyUI，不禁眼前一亮，这不正是我一直在寻找的吗？

关于ComfyUI，我在上一篇文章《程序员的视角解析 ComfyUI》中进行了分析。ComfyUI采用了可视化编程的思路，将Stable Diffusion的各个功能模块以“节点”的形式呈现，用户只需将节点用“边”连接起来，就能自定义出一个完整的图像生成流程。“节点”代表特定的操作或函数，“边”将“节点”的输出连接到另一节点的输入。整个流程就像一条生产线，原材料（如文本提示）在不同工位（节点）加工处理，最终生成成品（如图像）。

看到这里，有些同学可能已经反应过来，这不就是一款工作流软件吗？或者说是当前流行的低代码开发平台吗？是的，ComfyUI并不追求简单易用，而是将重点放在了自由度和可拓展性上。它通过模块化的节点设计，让用户能够根据自己的需求，自由组合和调整工作流，实现高度个性化的创作。同时，ComfyUI还支持用户自行开发和拓展节点功能，使其成为一个开放的创作平台。

支持用户自行开发和拓展节点功能非常重要，因为你永远无法预料用户有什么需求。对于新需求，只需拓展节点功能，不需要修改软件整体架构。这也是我前面提到的基于插件的软件架构所带来的好处。ComfyUI结合了工作流和插件，虽然看起来对最终用户不太友好，但赢得了设计师的青睐。实际上，普通用户也能接受，因为直接使用别人设计好的工作流，入门门槛也很低。

我们也希望打造一个软件开发平台，通过搭积木的方式，交付软件产品。仔细分析一下软件的应用场景，其实也可以拆分成一个个的工作流。比如最简单的语音打字，包含如下流程：

插入一个步骤，比如加上翻译，就是一个语音翻译打字的流程：

再比如说，开发一个英语口语对话的 AI 助手，流程也是可以拆分的：

如果觉得口语能力还没那么强，还可以插入一个翻译节点，这样你讲中文，AI 助手说英文，锻炼英语听力，也是一个不错的玩法：

甚至，你可以选择一个理解中文的 GPT 大模型，然后指定其输出英文回复，这样也可以不需要英文翻译这个步骤：

1. 语音采集：从麦克风采集用户的中文语音信号。
2. 语音识别：将中文语音信号转换为文本。
3. 对话处理：使用能理解中文并输出英文的AI模型（如 ChatGPT）处理文本并生成英文回复。
4. 文本转语音：将英文回复转换为语音。
5. 语音输出：将生成的英文语音通过音响或耳机播放出来。

通过上面的示例，可以说很多 AI 应用就是一个工作流。上面的一个个节点就是功能，而每个功能有不同的实现方法，比如语音识别，我们可以选择讯飞 API、谷歌 API 接入，也可以使用本地部署的模型。功能节点可以通过插件来实现。如果有新的功能需求，比如OCR，我们可以定义一个OCR的插件接口，而实现上可以使用开源库、百度OCR API等方式。

每条工作流，存在着数据的流动，从语音采集而得到的可能是PCM语音比特流，经过语音识别后，转成文本，经过TTS步骤后，又形成语音流。整个过程需要考虑数据格式的转换和处理。例如：

1. 语音采集：采集的原始数据可能是PCM格式的音频流。
2. 语音识别：将PCM格式的音频流转换成文本数据。
3. 文本处理：如果需要翻译，处理后的文本需要以适合翻译API的格式输入。
4. 翻译输出：翻译后的文本需要以适合下一处理步骤（如TTS）的格式输出。
5. TTS处理：将翻译后的文本数据转换成语音数据，可能需要选择特定的语音合成API。
6. 语音输出：将最终的语音数据输出到音频设备，可能需要处理为特定的音频格式。

在这样的架构设计下，我们的软件开发平台不仅可以提高开发效率，还能大大增强系统的灵活性和可扩展性。我们可以为每个功能模块创建标准接口，这样不同的实现方法（如不同的API或本地模型）就可以通过实现这些接口来被系统调用。

如果更进一步，还可以设计一个用户友好的界面，使得即使没有编程经验的用户也能通过拖拽节点来创建自己的工作流。梦想更进一步，通过开放平台吸引更多的开发者和用户，开发插件，设计工作流，建立生态，就像 ComfyUI 一样。当然这是后话，毕竟人力物力都有限。

象 ComfyUI 那样通过 JSON 文件描述工作流，即使没有图形化界面，通过手工编辑，也能达到快速交付、高度定制化的软件解决方案，满足不同客户的多样化需求。

尽管通过工作流 + 插件的架构来打造 AI 软件开发平台有诸多优势，但是相比 ComfyUI 还存在一些挑战。

ComfyUI 采用了 Python 编程语言，这是一种解释型语言，具有许多在插件架构上天然的优势。解释型语言的动态类型特性允许在运行时进行类型检查和类型转换，这使得开发和集成插件变得更加灵活和高效。相比之下，QT的C++语言对数据类型有着更严格的要求，在编译时就需要确定类型，这在一定程度上限制了其灵活性。C++虽然在性能上有优势，但在需要快速迭代和灵活扩展的插件架构中，往往显得繁琐。

此外，我们的数据处理中还涉及流式数据，比如语音流，这使得工作流的流向不再是一个简单的线性过程，而是一个往复循环的过程。在这种情况下，数据处理往往是异步的，这意味着一个节点在处理数据的同时，其他节点可能也在处理数据。相比之下，ComfyUI采用的是同步处理模式，一个节点处理完毕后，数据才会传递到下一个节点。这种同步处理模式要简单得多，而我们的产品则需要考虑：

1. 实时性：对于流式数据，尤其是语音流，实时处理是关键。我们需要确保数据在采集、处理、和传输过程中保持低延迟，以提供良好的用户体验。例如，在语音识别和翻译的场景中，用户希望语音输入能迅速转换成文本并展示出来。
2. 异步处理：在流式数据处理过程中，不同节点可能需要不同的时间来完成各自的任务。因此，我们必须设计一个异步处理机制，使得各个节点能够独立并行地工作，而不必等待其他节点完成。

除了流式数据处理的复杂性，我们的平台还需要支持多设备操作。这意味着工作流可能会有多个触发点，而不仅仅是一个固定的启动节点。为了实现这一目标，我们需要考虑以下几点：

1. 多设备兼容性：我们的平台需要兼容各种设备，这些设备可能有不同的输入输出方式和数据格式，我们需要设计灵活的接口，确保它们能够无缝接入平台。
2. 多触发点设计：工作流的启动不应仅限于单一设备或固定节点。我们需要支持多种触发方式，比如语音、键盘、鼠标等。每个触发点都应能够独立启动工作流，并根据具体场景进行相应的处理。
3. 统一的事件管理：为了管理来自不同设备的触发事件，我们需要设计一个统一的事件管理系统。这个系统能够实时监控、捕捉和处理各种触发事件，确保工作流能够灵活、高效地启动和运行。

总体而言。面临的挑战还不少。架构的调整也是一个重大工程，这个只能逐步推进，敬请关注！

步入 AI 时代，您不妨以一款智能鼠标作为起始。此款智能鼠标绝非仅仅是普通的输入设备，其融合了语音识别技术，您能够凭借语音命令来进行操作，进而解放双手，提升工作效率。不管是打字、开启应用程序、搜索信息抑或是执行命令，皆能够经由简便的语音指令得以完成。在鼠标上所集成的自定义按键，能够一键唤醒 AI 应用，不管是制作 PPT，还是撰写文案，都会更加游刃有余。