使用 LangGraph 和 Model Context Protocol 构建 Agentic Flows
使用 LangGraph 和 Model Context Protocol 构建 Agentic Flows
Sagi Medina Sagi Medina, 2025年3月13日 7 分钟
在最新发布的 1.0 版本的 Qodo Gen (我们用于 AI 编码和测试的 IDE 插件) 中,我们引入了 agentic 工作流,允许 AI 做出动态决策来应对复杂的编码任务。
为了在 Qodo Gen 中启用 agentic 功能,我们使用两项关键技术重构了我们的基础设施:LangGraph 用于构建结构化的 agentic 工作流,Anthropic 的 Model Context Protocol (MCP) 用于标准化外部工具的集成。
在这篇博客中,我们将介绍我们如何演进我们的基础设施以支持 agentic flows,如何使用 LangGraph 来编排多步骤的 flows,以及如何使用 MCP 来支持可扩展的工具。
演进的基础设施以支持 Agentic AI
作为 AI 的早期采用者,我们构建了大量的逻辑来弥补早期 LLM 的局限性,这些 LLM 在上下文保持、推理深度和一致性输出方面存在困难。 我们创建了许多额外的逻辑来处理诸如数据分块、手动注入上下文和重新检查响应之类的任务。
在多步骤的 agentic flows 中,AI 可以动态地决定在每个步骤中使用哪些工具和数据源,从而减少了对僵化、预先编写的逻辑的需求。 更强大的模型,如 Claude Sonnet,进一步减少了我们早期补偿措施的需求,因为它们能够更有效地自行推理。 这使得我们能够简化我们的基础设施,同时提高灵活性和准确性。
然而,构建这种“智能聊天”不仅仅是连接一个 LLM。 我们需要一种方法来构建逻辑,处理多个步骤,并让 AI 调用跨后端和前端系统的不同工具。
异步通信
Agentic flows 引入了双向、异步的通信模式,并要求模型在单个“思考”过程中能够进行多次工具调用,每次调用都可能触发复杂的工作流,然后才能返回结果。
然而,我们之前的架构假定的是同步 flow:收集上下文,发送到 LLM,接收响应。 这种根本不同的交互模式需要重新思考我们的通信层。
我们实现了 IDE 和后端之间的双向异步通信,从而实现了 agentic 工作流所需无缝、实时的交互。 这使得 AI 能够动态地请求和处理上下文,执行工具,并响应用户操作,而不会阻塞操作,从而提高了响应性和效率。
上下文处理
在 Qodo Gen 的初始版本中,我们主动收集所有可能的上下文,并在将其传递给 LLM 之前对其进行过滤。 这种方法与 agentic flows 不兼容,后者旨在在需要时请求特定信息,而不是一次性接收所有信息。
为了支持这种按需上下文检索,我们转向了更面向任务的架构,让 LLM 通过工具,根据特定任务和会话状态动态地请求其所需的确切内容。
错误处理和可靠性
复杂、异步的工作流有多个潜在的故障点。 当 LLM 进行工具调用时,该请求可能会经过多个层——从编排层到工具提供商,然后再返回。 我们之前的错误处理机制是为同步交互而设计的,潜在的故障模式更少。 我们增强了错误处理系统来管理:
- 异步通信故障 - 实施重试和回退机制以维持稳定性。
- 工具执行错误 - 引入结构化的错误报告和故障转移策略。
- 会话状态不一致 - 开发验证和恢复逻辑以维持准确的用户上下文。
- 数据库操作 - 改进事务完整性和冗余措施以防止数据损坏或丢失。
编排和任务管理
一个关键的改变是采用了一个编排器-worker 模型,其中中央 LLM 可以动态地分解复杂的任务,并根据需要将其委派给各种工具。 例如,当解决 CI/CD 问题时,LLM 可以分析错误日志,调用调试工具,建议修复,并验证解决方案 - 所有这些都在一个协调的序列中完成。
我们还实现了 agent loop 模式,使 LLM 能够:
- 自主运行 - 启动和调整任务,无需手动干预。
- 检索实时“真实情况” - 持续从环境中收集新数据,例如实时 API 响应或版本控制更新。
- 做出明智的决策 - 根据工具执行结果调整策略,例如重试失败的测试或修改部署计划。
- 维持会话状态 - 在迭代中持久化上下文,确保在诸如渐进式代码重构等多步骤流程中的一致性。
使用 LangGraph 来启用多步骤 Agentic Flows
为了支持动态的工具编排,我们重构了 Qodo Gen 的后端,集成了 LangGraph,以简化底层任务并简化 agentic 工作流。
灵活的基于图的基础设施
从一开始,我们就知道我们需要一种灵活的方法,这种方法不会将我们锁定在僵化的架构中。 LangGraph 基于图的结构允许我们定义复杂的工作流,其中每个节点都可以做不同的事情——从调用 LLM 到从工具中获取数据——而不会强迫我们进入单个线性步骤链。 我们选择在没有 LangChain 的情况下使用 LangGraph,以保持对我们的执行逻辑的更大控制,并避免不必要的抽象。 这使我们能够构建我们需要的确切内容,而无需额外的复杂性或依赖性。
以下是定义 LangGraph 工作流的一个示例:
内置状态管理
多步骤工作流中的一个挑战是跟踪中间输出,而无需我们在每个步骤手动处理状态。 LangGraph 在底层提供内置的状态管理,您只需要一个会话 ID,其余的都会被处理。 这使得我们能够保持每个节点的数据对后续步骤都是可访问的。
有效的 agentic 工作流还需要跨多个交互的状态持久性。 我们之前的设计将每次交互主要视为无状态,只携带最少的上下文。
为了确保跨扩展的 agent 交互的可靠状态管理,我们为会话数据引入了持久数据库存储。 我们进行了广泛的性能和压力测试,以确定最佳的数据库解决方案,从而平衡速度、可扩展性和可靠性。 这使得会话能够跨交互保留上下文,从而提高了 AI 辅助开发的连续性。
构建块:节点、agents 和工具
有了 LangGraph 作为我们的框架,我们必须定义一个结构化的 AI 交互系统,该系统依赖于节点、agents 和工具协同工作来做出智能决策。
Agent vs 节点
一个 agent 是整体的智能系统,可以决定下一步的行动。 在我们的架构中,整个 LangGraph 工作流作为一个统一的 agent 发挥作用,尽管各个节点可能具有不同程度的自主性。
节点是我们图的构建块。 LangGraph 工作流中的每个节点都负责一个特定的操作。 我们大致将节点分为三种类型:
- 静态节点:执行一个简单的、确定性的函数(例如,解析一个文件,做一些快速的格式化)。
- LLM 节点:使用提示调用 LLM 来生成或改进文本。
- Agentic 节点:自己决定调用哪个“工具”或如何继续。 这些节点具有更多的自主性,通常弥合了与外部 API 或服务的差距。
以下是一个基本节点的示例,其中每个节点都基于节点的职责来实现 run 方法。
MCP 主干用于可扩展的工具
工具是 agent(或节点)可以使用的外部能力,如获取代码工件、Web 搜索或运行数据库查询。 在我们的实现中,一个核心概念是来自 Anthropic 的 Model Context Protocol (MCP)。 通过 MCP,Anthropic 引入了一个框架,用于管理 IDE、AI 模型和外部工具之间的通信,并提供了一种将外部工具功能公开给 AI 模型的方法。
MCP 能够创建一个插件架构,其中各种编码工具(linters、编译器、源代码控制等)可以注册为 AI 可用的能力。 一个工具可以用适当的元数据进行注册,这些元数据描述:
- 工具做什么
- 所需的输入/参数
- 预期的输出
- 错误处理模式
工具通过 AI 可以理解的一致的 JSON 模式来公开它们的功能,例如:
MCP 构建了工具结果如何以标准化格式返回给模型的方式:
这种标准化的 JSON 格式消除了为每个工具集成定制解析器和格式转换器的需要。 MCP 的真正强大之处在于,它在您的系统中的 AI 模型和工具之间建立了一致的通信协议。 与为每个集成创建定制接口不同,MCP 提供了一个结构化的框架,使得添加新工具更加简单和可维护。 这种标准化显著降低了集成开销,并简化了调试。
我们将 MCP 与我们的 LangGraph 工作流集成在一起,允许所有 agent 与外部工具的交互都通过标准化的 MCP 通信协议进行。 这种方法确保了工具交互遵循一致的模式,同时使我们能够灵活地添加新功能(如搜索 Jira),而无需重写我们的核心 agent 逻辑。 此外,它允许用户携带他们自己的 MCP 兼容工具,从而显著扩展了 agent 的能力,使其超出我们自己可以构建的能力。 这种架构在可扩展性和控制之间创造了一种强大的平衡,确保新工具可以轻松集成,同时保持一致的交互模型。
以下是集成定制工具的一个示例:
在实现过程中,一个重要的技术进步是自定义传输层的开发。 这些自定义传输证明了通过单个一致的接口统一处理内置 IDE 工具和用户提供的自定义工具的作用。
这种架构方法启用了一个强大的功能:agents 现在可以通过无缝地将内置工具与用户提供的自定义工具结合使用来成功完成复杂的任务。 这种集成解锁了对以前无法访问的信息源的访问,允许 agents 利用原生 IDE 功能和外部资源,例如通过用户创建的工具提供的公司特定知识库。
Agentic Flows 的实践
在我们用于 Qodo Gen 中 agentic 编码的新工作流程中,用户的请求通过一个 LangGraph,该 LangGraph 可能会:
- 调用 LLM 节点来确定用户的意图。
- 使用一个工具从本地仓库中获取相关文件(通过 MCP)。
- 总结该代码上下文(另一个 LLM 节点)。
- 向用户输出最终结果——或者决定它需要更多的上下文并循环返回。
控制 Agent 自治性
我们的指导原则之一是:“如果不需要 LLM,就不要使用 LLM。” 我们喜欢生成模型,但它们是不确定的,并且可能不可预测,特别是如果它们可以自由地按任何顺序调用多个工具。
我们没有让单个“全知 agent”随意搜索每个工具(“YOLO 风格”),而是构建了更具主观性的 flows。 每个 flow 或子 agent 都有一个特定的目的:收集上下文,回答用户的问题,或为示例生成代码。 这有助于防止奇怪或意外的工具使用。
最终,我们正在逐步构建更高级的功能(如让 AI 自动创建或更新工单),但我们希望有护栏到位。 LangGraph 为我们提供了这种结构控制。
结论
通过围绕灵活性和控制设计 agentic 工作流,我们创建了一个 AI 系统,该系统不仅仅是执行任务,而是编排复杂的开发工作流。 LangGraph 为此提供了主干,使我们能够在不牺牲可靠性的情况下扩展 AI 的作用,而 MCP 为我们提供了对外部工具的完全支持。
这对开发人员意味着什么:
- 更智能的自动化:AI 选择正确的工具并收集相关信息。
- 一个可扩展的系统:工作流程可以演进,而不会破坏核心基础设施。
- 一种结构化的 AI 自治方法:AI 保持适应性,但在明确的边界内。
开发人员工具的未来不仅仅是集成更多的 AI,而是智能地编排 AI 能力。
Sagi Medina Sagi Medina, 2025年3月13日 7 分钟
开始测试、审查和生成高质量的代码
获取 Qodo
VS Code JetBrains Github, Qodo Merge
订阅新闻邮件
分享
来自我们博客的更多信息
Qodo (前身为 Codium) 是一个质量至上的生成式 AI 编码平台,可帮助开发人员在 IDE 和 Git 中编写、测试和审查代码。 我们的 AI 代码生成提供自动化的代码审查、上下文建议和全面的测试生成,从而确保强大、可靠的软件。 无缝集成可在整个开发过程中保持高标准的代码质量和完整性。
Qodo
- 社区
- 有用的资源
- 开发人员的提示
- 开发人员中心
- 支持的语言
- Qodo vs. GitHub Copilot
- Qodo vs Amazon Q
- 数据隐私和安全
- Qodo 的常见问题解答
- 术语表
- 常见问答
- Qodo TestsHub
- 代码审查中心
- 状态 🔗
产品
- Qodo Merge: Git Agent
- Qodo Gen: IDE Plugin
- Qodo Cover: CLI Agent
- AlphaCodium
- Qodo API CONTACT US
- 为什么代码完整性很重要?
- 信任中心
- 定价
- 报告问题
关于
我们支持所有主要的编程语言
现在可以在以下平台上使用
@ 2025 Qodo. 保留所有权利。