在上一篇文章，我们提到了Langchain在8月1日推出的Langgraph Studio以应对复杂的Agent应用构建调试挑战。延伸阅读：Langchain发布官方Agent IDE，不同于Dify/Coze的设计理念，能否获得开发者认可？
同一天，LLM应用开发另一个代表产品Llamaindex也发布了其在此领域的新功能——workflow，进一步提升应用编排的能力。早在去年，Llamaindex在这方面已经有了动作，推出了Query Pipeline（详见：应用编排的未来是Pipeline，LlamaIndex开发预览版推出Query Pipeline，提升应用开发的灵活性），它是一个声明式设计，可以自定义整个查询流程为一个DAG（有向无环图）流程，支持从简单到复杂的不同服务流程。对于一般的RAG类的流程来讲，DAG是可以应付的，并且简单直观，这也是大量LLM workflow设计的一致选择，然而对于Agent流程来讲，标准的DAG的结构有一定的缺陷，比如无法处理循环逻辑（有环），然而经典的ReAct的流程就是一个循环迭代的过程。除此之外，Llamaindex官方还提出了这一结构的一些其他问题：1）不易排错
2）模糊了组件和模块执行逻辑
3）Pipeline执行器实现越来越复杂，必须处理大量不同的边（edge）情况
4） 复杂的Pipeline，难以阅读。
一旦我们在查询Pipeline中添加了环，这些围绕图的开发应用的用户体验问题就会被放大。以下是一些常见麻烦：
1）很多核心编排逻辑（如 if-else 语句和 while 循环）都被定义到图的边（edge）上。定义这些边（edge）会变得繁琐冗长。
2）处理可选值和默认值的边的情况变得很困难。作为一个框架，很难确定参数是否会从上游节点传递。
3）对于构建Agent的开发人员来说，用有环的图来定义并不总那么自然。Agent封装了一个由 LLM 驱动的通用实体，它可以接收观察结果并生成响应。在这里，图的形式强制要求 "Agent"节点明确定义传入边和传出边，迫使用户定义与其他节点的冗长通信模式。
这一些问题，迫使Llamaindex官方团队重新审视这种设计的合理性。实际上，笔者在设计Flowengine时也遇到这样的问题，顺着dag图来设计编排执行器虽然很直觉，但是并不是最佳做法，理由两点：
一，它迫使开发者需要从宏观解析图中边（edge）和节点（node）的关系，整个逻辑非常复杂，特别是对于复杂的流程节点的处理以及失败情况恢复来讲，都涉及到大量的状态管理，这都使得图很复杂，特别是对边的处理，进而导致编排器实现复杂。
二，违反依赖倒置原则，选择应用编排的方式，很大程度上是希望图上的组件是可以复用，可插拔的，不应该考虑它到底处于一个什么样的图中，毕竟先有组件，再有具体的业务流程Pipeline。而前面的做法，就使得组件节点需要适配图的结构，这显然不利于组件沉淀复用，也导致了组件开发的复杂性。
对于此，Llamaindex推出了新的实现方法——事件驱动的模式来协调组件流程执行。显然事件驱动的模式，将图流程的调度变成了组件如何订阅和处理事件上来。这样很多原来边上的处理逻辑就变成了组件自己的行为，极大的降低了复杂度和依赖，并且这样的设计可以很容易的实现重试，失败，超时，循环，甚至是human-in-loop等原本直接解析图而产生的复杂逻辑。对于pipeline执行器来讲，提供消息分发和Context维持，以及根据订阅情况唤醒执行相关组件即可，也简化了整个实现的复杂度。我们来看看Llamaindex的workflow是如何编写的：
from llama_index.core.workflow import (StartEvent,StopEvent,Workflow,step,)
from llama_index.llms.openai import OpenAI
class OpenAIGenerator(Workflow):@step()async def generate(self, ev: StartEvent) -> StopEvent:query = ev.get("query")llm = OpenAI()response = await llm.acomplete(query)return StopEvent(result=str(response))
w = OpenAIGenerator(timeout=10, verbose=False)result = await w.run(query="What's LlamaIndex?")print(result)
上面例子定义了一个workflow类OpenAIGenerator，其中generate函数使用@step装饰器标记为这是一个workflow步骤，方法签名定义了其接收什么样的事件消息以及返回值定义该步骤执行后发布什么样的消息。
Llamaindex同时给出了这种方式下循环的实现方法：
class ExtractionDone(Event):output: strpassage: str
class ValidationErrorEvent(Event):error: strwrong_output: strpassage: strclass ReflectionWorkflow(Workflow):@step()async def extract(self, ev: StartEvent | ValidationErrorEvent) -> StopEvent | ExtractionDone:if isinstance(ev, StartEvent):passage = ev.get("passage")if not passage:return StopEvent(result="Please provide some text in input")reflection_prompt = ""elif isinstance(ev, ValidationErrorEvent):passage = ev.passagereflection_prompt = REFLECTION_PROMPT.format(wrong_answer=ev.wrong_output, error=ev.error)
llm = Ollama(model="llama3", request_timeout=30)prompt = EXTRACTION_PROMPT.format(passage=passage, schema=CarCollection.schema_json())if reflection_prompt:prompt += reflection_prompt
output = await llm.acomplete(prompt)
return ExtractionDone(output=str(output), passage=passage)
@step()async def validate(self, ev: ExtractionDone) -> StopEvent | ValidationErrorEvent:try:json.loads(ev.output)except Exception as e:print("Validation failed, retrying...")return ValidationErrorEvent(error=str(e), wrong_output=ev.output, passage=ev.passage)
return StopEvent(result=ev.output)
w = ReflectionWorkflow(timeout=60, verbose=True)result = await w.run(passage="There are two cars available: a Fiat Panda with 45Hp and a Honda Civic with 330Hp.")print(result)
在这个例子中，validate步骤接收试验性模式提取的结果作为事件，并且它可以通过返回ValidationErrorEvent来决定再次尝试，该ValidationErrorEvent最终将被传递到extract步骤，该extract步骤将执行下一次尝试。这样就实现了循环迭代的逻辑。
由于编程本身的问题，复杂的业务流程读代码是件痛苦的事情，Llamaindex提供了类似LangGraph Studio的能力，对执行流程可视化，方便开发者进行调试。
可以看出，Llamaindex在应对复杂的LLM应用时，采用了与Langchain相似的策略，即高代码+可视化辅助调试的思路。这其中，事件驱动的流程编排是一个独特的设计。但笔者认为，事件驱动本身是可以和声明式、低代码Pipeline开发相融合的，用户可以采用直观的拖拉拽编排整个流程，而编排器实现可以采用事件驱动的方式而非解析图的方式，这样岂不是更好？甚至可以提供两种模式编程和低代码可视化，两者还可以实现互操作，更大层面覆盖了不同背景的开发者。事实上，FlowEngine便是采用了这样的设计，更多细节可以加入群了解。
粤ICP备14082021号
免费POC，
零成本试错
