我们做了一个很酷的项目，展示了如何将我们的核心文档智能原语组合成可复用的流水线，将文档转化为机器可读的数据。快来瞧瞧！https://llamaindex.ai/blog/designing-a-visual-document-intelligence-workflow-with-llamaparse?utm_medium=socials&utm_source=twitter&utm_campaign=2026-jun-…

Parse-Flow：开源的可视化文档智能工作流设计器

来源：https://www.llamaindex.ai/blog/designing-a-visual-document-intelligence-workflow-with-llamaparse?utm_medium=socials&utm_source=twitter&utm_campaign=2026-jun- 非结构化文档仍然是企业存储和共享运营信息的主要界面。从合同到发票再到报告，这些文档都有一个共同点：它们混杂了布局、语言和上下文，下游系统无法直接消费。文档智能——即将这些文档转化为结构化、机器可读数据的技术——是让现代AI栈在企业中真正发挥作用的关键层。没有稳健的解析、分类、拆分和提取，每一个检索流水线、每一个智能体、每一个分析仪表盘都将建立在脆弱的基础之上。

Parse-Flow是一个小型开源项目，它将四个文档处理原语——解析(Parsing)、提取(Extraction)、分类(Classification) 和拆分(Splitting)——置于可视化工作流设计器、异步工作器和实时事件仪表盘的中心。你可以将步骤拖到画布上，放入文档，然后看着流水线运行时事件流回。本文是构建过程的一次巡览，重点介绍后端工作流如何基于llama-agents (https://github.com/run-llama/llama-agents) 工作流 (https://github.com/run-llama/llama-agents) 进行设计。

ParseFlow 画布## 系统的形态

Parse-Flow 由四个协作进程组成：

• 一个 React 前端，托管基于节点的工作流设计器、运行视图和任务仪表盘。
• 一个 Bun 服务器，负责接收上传、与 LlamaParse 平台通信、将任务加入队列、从 Postgres 读取历史记录，并通过服务器推送事件(Server-Sent Events)将事件流桥接到浏览器。
• 一个 Python 工作器，负责消费任务并执行实际的文档工作流。
• Redis 作为任务队列和事件总线，Postgres 作为任务及其事件历史的主记录系统。

通信模式如下：Bun 服务器将任务推送到 Redis 列表，工作器拉取任务，在任务运行期间，每个事件都被追加到每个任务的 Redis 流中，同时持久化到 Postgres。Bun 服务器通过创建专用的订阅者连接、发送心跳信号并在观察到最终事件后关闭连接，将该流桥接到浏览器。

这种分离带来了两个主要好处：

• 工作器可以运行缓慢而不会阻塞 HTTP 层。
• 每个事件都被捕获两次（一次在实时流中，一次在持久存储中），因此重新加载页面的用户可以查看并重放从 Postgres 重建的完整历史记录。

四个原语，任意组合

工作流词汇刻意保持精简，专注于 LlamaParse 平台提供的服务：

• parse — 使用 Parse 将文档转换为干净的 Markdown 和文本，可选择层级和可选提示。
• classify — 根据一组用户定义的规则对文档进行分类，附带推理过程和置信度分数。
• split — 根据类别列表将文档分割成类型化块。
• extract — 根据用户提供的 JSON 模式从文档中提取结构化 JSON。

系统的表达能力并非来自原语本身，而是来自限制它们如何链接的允许配对图(Allowed-Pairs Graph)。并非所有转换都有意义：extract 总是终止步骤，parse 可以交给其他三个原语中的任何一个，classify 和 split 可以根据匹配的规则或类别路由到 parse 或 extract。前端在提交之前根据该图验证流程，后端在接收时也会重新验证。

结果是一个基于 JSON 的小型领域特定语言：FlowDefinition 包含有序的步骤和类型化交接，足以描述大多数真实文档流水线（解析-然后-提取、分类-然后-路由到正确模式、按章节拆分-然后分别解析），同时又足够小，可以彻底推理。

ParseFlow 中流程的 JSON 定义## 核心的 LlamaAgent 工作流

有意思的设计工作体现在工作器中，一个单一的 LlamaAgent Workflow 在运行时解释用户定义的流程。

llama-agents 框架提供了一个事件驱动、不强调特定方式的工作流引擎：每个 @step 是一个异步函数，接收一个事件并返回一个或多个事件，运行时将事件路由到类型签名匹配的步骤。状态保存在一个类型化的 Context 存储中，步骤可以以事务方式读取和编辑。通过 ctx.write_event_to_stream 写入的事件会暴露给观察运行过程的任何人（在我们的例子中，就是将其转发到 Redis 和 Postgres 的工作器）。

Parse-Flow 的 DocumentWorkflow 只暴露了三个步骤，执行系统的关键在于它们如何协作以遍历任意长度的流程。

步骤 1 — 引导（Bootstrap）

第一个步骤接收一个携带已解析 FlowDefinition 和 LlamaCloud 文件 ID 的 RedisInitialEvent。它将流程写入工作流状态，记录当前位于索引零，并为第一个步骤发出类型化输入事件（ParsingInputEvent、ClassifyInputEvent、SplitInputEvent 或 ExtractInputEvent）。从这一点开始，工作流由数据驱动；引导步骤再也不会运行。

步骤 2 — 工作器（Worker）

工作器步骤有意采用宽泛的输入类型：任何 InputEvent。它根据事件类型进行模式匹配，在状态中推进步骤索引，并分派到 LlamaParse 平台上的相应操作。每个操作返回一个类似 Rust 的 Result (https://github.com/AstraBert/better-result-py/blob/71f5973c7296727e307738b540ce2aa54442712e/src/better_result/result.py#L60)，该结果被解包为类型化成功事件（带有解析后的 Markdown、分类结论、分割后的块或提取的 JSON）或携带失败消息的 ErrorOutputEvent。

一个小但重要的细节：一旦 parse 步骤产生了 parse_job_id，后续的 classify 和 extract 操作会优先使用该 ID 而非原始文件。这意味着当用户链接 parse → extract 时，提取步骤将基于已解析的表示进行操作，而不是从头重新解析文件——这是通过步骤间共享状态带来的免费延迟和成本降低。

步骤 3 — 路由器（Router）

后处理步骤是在运行时实际执行允许配对图的地方。它查看最后一个输出事件、流程中的当前步骤以及上一步骤记录的交接描述符。根据这三条信息，它决定接下来发出什么：

• 如果已经走到流程末尾，它将最后一个输出包装在 WrapperStopEvent 中，工作流终止。
• 如果输出是错误，则短路到停止。
• 否则，它会查询交接类型（classify-extract、parse-classify、split-parse 等）来构造下一个输入事件。对于路由交接，这意味着查找与上一步匹配的规则所对应的 JSON 模式、解析层级和提示或类别，并将它们打包到下一个输入事件中。

随后该路由器再次发出 InputEvent，这直接循环回到工作器步骤。引导-工作器-路由器三元组成为一个状态机，一次一步地遍历用户的流程，每一步都是类型化的，每一次交接都经过验证，每一个事件都可观察。

ParseFlow 运行期间显示事件的仪表盘## 为什么这种设计站得住脚

三个特性让这种设计用起来很舒服。

流程存在于事件中，而非代码中。 同一个 DocumentWorkflow 运行所有任务。新的流水线不需要新的 Python 代码，只需要一个新的 JSON 流程定义。这正是使在其之上构建可视化设计器变得可行的原因。

每一步转换都可观察。 因为每个步骤在返回之前将事件写入流，仪表盘看到的工作流与工作流自身看到的一致。没有会与现实脱节的独立日志层。

失败是一种值。 错误是一等输出事件，路由器知道如何将其转化为干净的停止。用户会得到一个带有真实消息的最终事件；系统永远不会静默挂起。

文档智能才是关键的层次

在2026年，很容易将解析和提取视为已解决的问题，隐藏在模型调用背后。但事实并非如此。一个用错误的模式对发票进行分类、在错误边界分割合同、或从错误页面提取日期的流水线，会在下游以任何检索技巧都无法恢复的方式失败。那些持久的系统，是将文档智能作为一等工程问题认真对待的系统：可组合的原语、验证过的转换、可观察的运行、持久的历史。

Parse-Flow 是一个小例子，展示了当你允许自己正确设计工作流层时会发生什么：四个原语、一个类型化交接图、以及一个其唯一工作就是遍历该图的 LlamaAgent 工作流。

试试看

完整源代码是开放的。克隆它，指向你的 LlamaCloud 密钥，然后带上你自己的文档。

→ github.com/run-llama/parse-flow (http://github.com/run-llama/parse-flow)

LlamaIndex 🦙 (@llama_index): 大多数 AI 流水线的质量取决于我们提供给它们的数据，而数据通常是 PDF 或其他非结构化文档。

合同、发票、报告……它们都混合了特殊的布局、语言和上下文，要从其中可靠地获取结构化数据，就需要