用LangGraph进行图工程：三年经验总结

图工程这个术语最近在X的AI内容工厂中兴起，与提示工程、上下文工程、编排工程和循环工程等术语并列。尽管这些可能被视为流行语，但它们确实描述了构建者面临的实际挑战和设计决策。

在LangChain，我们三年来一直在帮助人们使用图形构建代理系统。我们的框架LangGraph目前每月下载量超过6500万次，被初创企业和大型企业广泛使用。其成功的关键在于它在确定性路径和自主步骤之间取得了平衡。

将代理建模为图形

图形提供了一种具体的方式来定义代理遵循的工作流。在LangGraph中，节点执行工作——可以是确定性代码、单个LLM调用、工具调用或具有内部循环的完整代理。边定义了下一步做什么，有些是确定性的，有些则基于节点结果、当前状态或外部信号是条件性的。这本质上是一个状态机。

何时使用图形

现实世界中的代理工作流通常具有可预测的结构：支持代理在回答或升级之前先对问题进行分类，编码代理在提出更改之前先检查仓库，合规工作流在采取外部行动之前需要审批。图形允许您直接编码这些结构：模型的决策点以及系统应强制确定性行为的地方。

例如，一个知识库代理使用三个子代理进行搜索：一个GitHub代理处理代码、问题和拉取请求，一个Notion代理处理内部文档和Wiki，一个Slack代理处理相关线程。工作流有三个固定阶段：分类、搜索、综合。结果是代码和模型推理协同工作，模型在增加价值的地方推理，代码处理其余部分，从而使代理更便宜、更快、更可预测。

何时避免使用图形

有些任务本质上更具自主性，强行使用确定性路径是错误的。例如通用的深度研究：研究代理需要规划、委派、搜索、阅读和综合，这些很难预先确定。早期的深度研究使用预定义的LangGraph工作流，但后来转向了更自主的核心循环。GPT Researcher也做了类似的转变。

构建LangGraph的教训

首先，代理图形通常不是DAG。生产代理需要循环：重试失败的工具调用、向用户询问缺失信息、验证后修改答案、重复调用工具直到获得足够上下文、在恢复前暂停等待人工输入。循环是代理系统的核心部分。

其次，循环是简单的图形。循环工程不是图形的替代品，而是它们的简化版本。

第三，动态转换很重要。您并不总是希望提前定义每条边。有时节点在运行时决定要创建多少工作。Map-reduce是经典案例：将输入拆分为片段，每个片段发送给工作器，然后组合结果。工作器的数量取决于输入，无法提前知道。LangGraph通过Send功能处理这种情况，允许节点动态地将工作路由到一个或多个下游节点。

什么实际上发生了变化

将代理系统表示为图形并非新鲜事——我们已经这样做了三年。现在的新情况是节点中可以包含的内容。早期节点是确定性代码或单个LLM调用。现在代理本身足够可靠，节点可以是一个完整的代理运行——您正在编排代理，而不仅仅是LLM调用。编码代理是很好的例子，它们嵌入在更大的图形中作为节点，这是一种新的实用模式。

例如，一个文档代理将Slack请求转换为可供审查的拉取请求。图中的每个节点都位于确定性到自主性的不同点上：固定步骤由代码和API调用驱动；模型步骤使用单个LLM调用且没有工具；代理步骤则完成更开放的工作。这种确定性/自主性的混合使得文档代理可预测、强大且高效。

更大的思路

图工程不是一个新想法，它是构建可靠代理的成熟方法的最新名称。它与循环工程和编排工程背后的理念相同：在正确的位置、正确的上下文中放置模型推理。如果您想尝试图工程，不妨试试LangGraph。