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的workflow是如何编写的：
from llama_index.core.workflow import (StartEvent,StopEvent,Workflow,step,)from llama_index.llms.openai import OpenAIclass 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: strclass 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_promptoutput = 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便是采用了这样的设计，更多细节可以加入群了解。
