把不同模态，接成工作流：TongFlow 的设计起点

手里有一份文档，你想提取其中的信息，整理成摘要，再做成可以听的语音。这件事横跨文件、文本和音频，但目标很连贯：让同一份信息换一种方式被使用。

TongFlow 从这样的任务出发。先看你有什么材料、希望得到什么，再决定中间怎样连接。文字、图像、声音、视频、三维，都可以成为工作流的材料。

我们把这个设计起点叫作 modality-first：以模态组织工作流，让能力连接模态，再由插件和模型实现这些能力。

材料、能力、模型，各有自己的位置

“模态”听起来有些抽象，放到画布上就很具体了：一段文字、一张图、一份音频。它描述的是信息以什么形态存在。

在 TongFlow 里，一份材料拥有自己的节点。接下来要做什么，由连接它的操作决定。文字可以接到语音合成，也可以接到图像生成；图像可以被理解、处理，或参与视频生成。

这里有三件分别需要决定的事：

这个区分会影响搭建流程的顺序。你可以先把“这段文字需要变成语音”放进工作流，再选择语音合成的实现。模型依然重要，但它不必替你决定整条流程长什么样。

回到那份文档。一条示例路径可以这样组织：

文档 → 提取文字 → 文本
                   ├→ 整理摘要 → 摘要文本
                   └→ 语音合成 → 音频

两条分支使用同一份提取结果，各自保留输出。如果之后需要根据摘要合成语音，也可以把语音合成的输入改接到摘要文本。

这里关键的是，生成结果仍然是材料。上传的图像和生成的图像，都可以进入接收图像的后续操作。得到的音频也有自己的位置，可以继续处理，或与一张角色图像一起参与视频生成。

工作流因此不必在最初就被想完整。先走通一段，检查结果，再从合适的位置增加分支或组合。已经得到的东西，可以成为下一次尝试的起点。

生成图像和视频，是这套结构很直观的应用。文档提取、语音转录、内容理解和材料整理，同样适用。

例如，一段视频可以先拆成片段，再提取音轨、转成文字。得到的文本又可以进入整理或生成步骤。整个过程既包含一变多的拆分，也包含跨模态转换，不需要为每种任务换一套构建方式。

所以，我们把 TongFlow 定位为一种创造工具。你创造的可以是一份内容，也可以是一套处理资料的方法、一条反复使用的工作流。工作流要完成什么，由你的目标决定。

添加、转换、组合、拆分与批量处理，构成了基本的操作方式。它们的价值在于可以接在一起，而不只在于某一步能生成什么。

假设流程里有一步图像生成。你可能先使用插件 A，之后想试试另一个兼容实现。

TongFlow 分别记录这一步的能力和执行插件。只要新实现符合相同的输入输出约定，就可以保留周围的流程结构，替换承担这一步的插件。具体参数、凭据和生成结果，仍需按新实现检查。

代码里，这个区分体现在能力契约和节点注册表中。契约描述操作接收什么、输出什么；工作流再指定由谁执行。对使用者来说，这意味着你组织材料的思路，可以比某一次模型选择保留得更久。

Modality-first 的自由，建立在明确的输入输出类型上。接收音频的操作，需要音频输入；需要图像与声音共同参与的操作，就要接入这两种材料。

当前能执行哪些步骤，还取决于已有能力、安装的兼容插件，以及所需的配置。新模态或新能力的接入，也需要相应的定义与实现。这套设计提供的是继续扩展的方式，而不是宣称所有东西现在就能任意互连。

每增加一种兼容能力，已有材料就可能多一条可用的路径。它还可以与已有操作组合，这正是我们看重 modality-first 的原因。

画布提供了直观的搭建方式，底层结构也可以通过代码操作。TongFlow 的画布、连接检查和导出器共用节点注册表；DSH 集成则让 Agent 能够构建工作流文件，再由用户在画布上打开、检查和修改。

这样，Agent 交给你的可以是一份可继续编辑的过程。某一步的输入、执行能力或插件需要调整时，都有明确的位置可以改。

我们希望 TongFlow 留给用户的，既有结果，也有继续构建的余地。把不同模态接成工作流之后，下一步接在哪里，仍然由你决定。

打开 TongFlow，从你手里的一份材料开始。想进一步了解实现，可以查看 TongFlow 源代码、能力注册表和 DSH 集成。