面对多样的LLM应用需求，不管是主流如LangChain这样的基础开发框架，还是以云服务提供的低代码开发平台，都试图在提供基础组件抽象的基础上，提供更便捷的组装与编排这些组件的方式，以帮助构建更高级的AI工作流应用。比如年初发布的LangChain新版本中就引入了LangGraph，以帮助构建Graph表示的AI工作流。（彻底搞懂LangGraph：构建强大的Multi-Agent多智能体应用的LangChain新利器 ）

最近，另一家主流LLM框架LlamaIndex推出了一项新beta特性：Workflows。提供了一种与LangGraph不同、事件驱动的框架，以编排复杂的RAG或Agent应用工作流，支持灵活的分支、并行与循环等处理。

我们将分成两篇来给大家深入解析与介绍LlamaIndex Workflows：

• Workflows的思想、概念与简单演示

• 基于Workflows构建多分支与循环的复杂LLM应用

  
  

回顾：为什么需要Workflows

以两种主流LLM应用开发框架LangChain与LlamaIndex来看，它们都提供了大量的基础组件封装，将常见的RAG或Agent应用开发中常用到的流程环节进行了抽象，简化了开发并避免锁定到特定的底层设施（如大模型、向量库）。利用它们提供的API可以在极短的时间内开发出大模型应用，比如在LlamaIndex中，几行代码可以快速完成一个RAG原型：

......
documents = SimpleDirectoryReader("../data").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()
response = query_engine.query('你的问题')
print(response)

但这里的问题是：当面对复杂的业务与优化需求时，不断出现更多的RAG工作模块与算法（重写、路由、排序、图索引等），如何用最佳的方法来组合与协调这些组件，实现更复杂的工作流程？

在框架的早期，可以总结成两种主要方式：

• 提供更高层的组件与API的封装。比如简单的向量检索器是VectorIndexRetriever，但现在需要增加路由功能，就封装一个带有路由的RouterRetriever；简单的查询引擎是QueryEngine，但现在需要增加重排功能，就增加一个可以传入Reranker模块的参数。

• 提供链式或DAG（单向无环图）结构的可编排方法。最具代表性的是LangChain框架中的Chain（链）与LCEL（LangChain表达语言）特性；以及LlamaIndex在年初推出的Query Pipeline（查询管道）声明式API特性。它们都在一定程度上提供了编排能力。

  
  

LlamaIndex的Query Pipeline提供了一定的编排能力

尽管如此，这种受限的工作流编排仍然面临较大的局限性：

* 高层的组件或API封装缺乏足够的灵活性。体现在：

• 随着需求的复杂化，需要封装更多的高层组件，框架变得更臃肿。

• 高层组件的内部过于“黑盒”。比如很难对LangChain或LlamaIndex的ReActAgent组件构建的智能体的执行过程做更精细化的控制。

  
  

* 链式或DAG结构的流程无法支持循环，限制了使用场景。但在如今的很多AI工作流中，比如智能体的反思（Relfection）以及一些新的RAG范式（如C-RAG等）都需要循环的支持。

* 不够简洁与直观，也难以调试。

基于这样一些原因，提供一种更强大的工作流定义与编排的支持，也成为了开发框架的发力重点，典型的就是之前介绍过的LangGraph以及本篇将一窥究竟的LlamaIndex Workflows。

LlamaIndex Workflows初探

LlamaIndex Workflows是LlamaIndex近期推出（仍然是测试版）的用来替代之前Query Pipeline（查询管道）的新特性。与LangGraph不同的是，其没有采用类似LangCraph基于图结构的流程编排模式，而是采用了一种事件驱动的工作流编排方式：

工作流中的每个环节被作为step（步骤，代表一个处理动作），每个step可以选择接收（类似订阅）一种或多种event（事件）做处理，并同样可以发送一种或多种event给其他step。通过这种方式，把多个step自然的连接起来形成完整的Workflow。

在这种架构中，工作流的运行不是由框架来根据预先的定义（比如Graph）来调度任务组件执行，而是由组件自身决定：你想接收什么event，做什么处理，并发出什么event。如果组件B接受了A发出的某种event，那么B就会在A发出event后触发执行。

看一个这种方式定义的模拟复杂工作流：

图中涉及到LlamaIndex Workflows中的一些关键概念：

• Workflow（工作流）

工作流代表一个复杂的RAG、Agent或者任意复合形式的LLM应用的端到端流程。创建完工作流后，调用run方法，并输入任务即可启动。

Workflow类似LangGraph中的Graph。

• Step（步骤）

步骤代表工作流中的单个任务，你可以自由的定义步骤内容。每个步骤接收输入事件（订阅），并返回输出事件。当输入事件发生时，这个步骤就会自动执行。步骤使用Python函数定义。

Step类似LangGraph中的Node。

• Event（事件）

事件是一个步骤的输入输出，也是工作流各个步骤之间的数据载体。当事件发生时，“订阅”该事件的步骤就会执行，同时从事件中取出必要数据。事件是一个Pydantic类型对象，可以自由定义结构。注意两个特殊事件：

• StartEvent与StopEvent是两个系统事件，代表工作流开始与结束。

• StartEvent由框架派发，接收StartEvent的步骤代表工作流的开始。

• StopEvent由框架接收，发送StopEvent的步骤代表没有后续步骤。

  
  

Event是LlamaIndex中连接Step的机制，作用类似LangGraph中的Edge（边），但机制完全不同。

• Context（上下文）

Context是一个用来在整个工作流内自动流转的上下文状态对象，放入Context中的数据可以被所有步骤接收和读取到，可以理解为全局变量。

Context类似LangGraph中的State（状态），但LlamaIndex中各Step的数据交换更多通过event传递，而不是Context。

最后总结：LlamaIndex Workflows是通过一种事件驱动、自我管理的任务组件（step）来组装与编排复杂工作流的方式。此外还具有可视化（生成流程图）、可单步调试、可复用工作流等特性。

Hello,Workflows!

现在我们用LlamaIndex的Workflows来实现一个最简单的带Rerank重排功能的RAG工作流。其工作流程图如下：

这个简单的Workflow反映了一个经典RAG流程的两个工作阶段，索引（indexing）与生成（generate）阶段。这里把两个阶段做成不同的分支，是为了便于一次索引后做多次生成，也体现了Workflows的一个特征：一个Workflow的入口step可以有多个，只要这个step接收StartEvent事件。

看下这个Workflow的简单实现代码：

from llama_index.core.workflow import Event
from llama_index.core.schema import NodeWithScore

#定义两个事件
class RetrieverEvent(Event):
    nodes: list[NodeWithScore]

class RerankEvent(Event):
    nodes: list[NodeWithScore]

from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.core.response_synthesizers import CompactAndRefine
from llama_index.core.postprocessor.llm_rerank import LLMRerank
from llama_index.core.workflow import (
    Context,
    Workflow,
    StartEvent,
    StopEvent,
    step,
)

from llama_index.llms.openai import OpenAI
from llama_index.embeddings.openai import OpenAIEmbedding

#workflow定义
class RAGWorkflow(Workflow):
    @step
    async def indexing(self, ctx: Context, ev: StartEvent) -> StopEvent | None:
        #不带query参数，表示索引阶段
        if not ev.get("query"):
            documents = SimpleDirectoryReader(input_files=['../../data/sales_tips1.txt']).load_data()
            index = VectorStoreIndex.from_documents(documents=documents)
            print("Indexing complete")
            return StopEvent(result=index)
        else:
            return None

    @step
    async def retrieve(
        self, ctx: Context, ev: StartEvent) -> RetrieverEvent | None:
        #带query参数，表示生成阶段
        if not ev.get("query"):
            return None
        
        query = ev.get("query")
        index = ev.get("index")

        await ctx.set("query", query)
        retriever = index.as_retriever(similarity_top_k=2)
        nodes = await retriever.aretrieve(query)
        return RetrieverEvent(nodes=nodes)

    @step
    async def rerank(self, ctx: Context, ev: RetrieverEvent) -> RerankEvent:
        ranker = LLMRerank(
            choice_batch_size=5, top_n=3, llm=OpenAI(model="gpt-4o-mini")
        )
        new_nodes = ranker.postprocess_nodes(
            ev.nodes, query_str=await ctx.get("query", default=None)
        )
        return RerankEvent(nodes=new_nodes)

    @step
    async def generate(self, ctx: Context, ev: RerankEvent) -> StopEvent: 
        llm = OpenAI(model="gpt-4o-mini")
        summarizer = CompactAndRefine(llm=llm, streaming=True, verbose=True)
        query = await ctx.get("query", default=None)

        response = await summarizer.asynthesize(query, nodes=ev.nodes)
        return StopEvent(result=response)
    
w = RAGWorkflow()

代码非常清晰易懂：其中四个函数定义了四个step，各个step之间通过输入的event与返回的event进行连接，并驱动整个工作流的自动运行。这里也能体现Workflows与LangGraph的最大区别：LangGraph通过定义图中的edge来体现流程节点之间的关系；而Workflows则是通过step之间的event传递来体现。

你可以通过如下代码运行工作流并测试：

w = RAGWorkflow()

#索引阶段
index = await w.run()

#生成阶段，需要带入问题和创建好的索引
result = await w.run(query="你的问题", index=index)
async for chunk in result.async_response_gen():
    print(chunk, end="", flush=True

此外，Workflows提供了工具对定义的Workflow进行可视化，使用如下代码：

from llama_index.utils.workflow import draw_all_possible_flows
draw_all_possible_flows(
    RAGWorkflow, filename="RAG.html"
)

可以生成可视化的工作流程图：

如果你使用过LlamaIndex，可能会觉得这里的代码似乎更复杂化了，这并不意外：Workflows（以及LangChain的LangGraph）显然都是为了更复杂与更灵活化的LLM应用场景而设计，而非简单应用。

下一篇我们将分析如何使用Workflows实现一个复杂的Agent工作流。