LlamaIndex多Agent工作流：事件驱动共享状态编排

LlamaIndex 将自己定位为在结构化和非结构化数据上构建 LLM Agent 的领先框架。其架构强调事件驱动的工作流和共享状态管理，通过 Context 实例而非线性调用链来实现多 Agent 协调。这种方法用能够处理复杂研究任务的弹性系统取代了脆弱的脚本。

Event-Driven Architecture for LLM Apps

LlamaIndex 作为一个数据框架运行，将索引检索置于原始上下文注入之上。这种设计通过保持输入流清洁和降低计算负载来优化 Token 相关性。该系统采用事件驱动的编排基础，通过特定触发器而非刚性代码块来管理 Agent 步骤。存储与生成分离使 LLM 能够访问预构建索引，而不会压垮模型的上下文窗口。

AgentWorkflow 作为多步骤编排的核心构建块，在交互过程中维护状态和内存。开发者必须明确定义状态模式和交接条件，以防止并发执行期间的竞态条件。虽然这增加了初始配置复杂性，但确保了可扩展的生产级多 Agent 系统。

Coordinating FunctionAgents and ReActAgents

FunctionAgent 执行 Python 函数，而 Context 类在交互之间维护共享状态。这种架构使诸如 ResearchAgent 和 ReActAgent 之类的 Agent 能够访问和修改持久存储，而无需线性脚本依赖。工作流通过显式交接逻辑（如 can_handoff_to 参数）协调这些 Agent，确保 WriteAgent 只在 ResearchAgent 完成其任务后才会继续。

共享状态引入了并发约束，要求 Agent 对 Context 存储进行序列化访问。如果没有保护措施，可能会发生竞态条件，在高吞吐量场景中造成瓶颈。开发者必须设计工具接口以批量更新或实现锁定机制以实现可扩展性。

# Example of tool function interacting with ctx.store
async def record_notes(ctx, notes):
    state = ctx.store.get("research_notes", {})
    state.update(notes)
    ctx.store["research_notes"] = state

Pre-built Indexes vs Context Injection

LlamaIndex 从预构建索引中检索信息，而非向模型倾注大量上下文 Token。这种方法在保持高检索精度的同时降低了 Token 使用量和计算负载。索引检索将历史记录排除在提示之外，依赖 google-genai 等工具来高效管理查询。

维护索引会产生运营开销，但对于需要长期记忆和成本效率的系统来说，索引检索变得至关重要。

Implementing External Tools with Gemini

集成 GoogleSearch 等外部工具需要将其包装在 types.Tool 定义中。此设置进入 GoogleGenAI 客户端的 generation_config 参数，在 Token 生成期间启用动态函数调用。正确的配置确保输出结构匹配 API 要求。

# Example of configuring a search tool
search_tool = types.Tool(types.GoogleSearch())
generation_config = {"tools": [search_tool]}

开发者必须在配置中验证 tools 列表以确保正确的工具绑定，使系统能够动态回答查询。

LlamaIndex 为通过共享状态和事件驱动架构编排多 Agent 工作流提供了强大的框架。它对索引检索和显式交接逻辑的强调确保了可扩展的生产级系统。开发者必须专注于状态模式设计和工具配置，以充分利用这种方法，从提示工程转向结构完整性。