何时该用LangGraph而非简单Tool-Calling

Single-shot tool-calling 是正确的默认选择，当一个请求是自包含的：一个调用、一个结果、然后结束。LangGraph 是正确的选择，当你的 pipeline 需要显式状态、条件分支，或者需要一个在崩溃后仍能保留的审计追踪。知道这条线在哪里，可以让你避免一端过早重写，另一端避免数月的脆弱拼凑。

我写过关于构建第一个 LangGraph pipeline 的文章，也写过将 LangGraph 部署到现有数据基础设施的文章。这篇文章覆盖的是更早期的问题：你怎么知道什么时候该做这个迁移？

单-shot 模式开始吃力的时候

当输入可预测、输出是下游代码所需的全部时，单-shot 工具调用工作得很干净。在三种条件下，这种模式开始让你付出代价。

第一种是输入大小或 schema 可变。模型总结一个 200 行的 CSV，在同一端点收到 20,000 行的文件时，表现会不同。一旦你开始添加预处理步骤——过滤、类型转换、 enrichment——这些操作就藏在 prompt 内部，或者累积为围绕调用拼凑的临时 Python 代码。Pipeline 看起来像单个步骤，但实际不是。

第二种是影响下游路由的决策点。想象一个工作流：拉取金融交易列表，标记超过阈值的项目，将标记的项目路由到合规审查，其余发送到报表仪表板。如果标记逻辑存在于模型响应中，你就失去了审计为什么某个特定交易被那样路由的能力。没有显式状态可检查，也没有地方附加日志条目。

第三种是累积的错误处理。当工具返回意外的 schema 时，你添加一个条件检查。然后是一个限流错误的。然后是上游 API 恰好在最糟糕的时刻超时的边缘情况。代码看起来仍然像单个调用，但被一圈只有原始作者完全理解的特殊情况所包围。引入新团队成员成为一种风险。

显式状态和分支给你什么

LangGraph 的核心添加是一个在节点间持久化的共享状态字典。每个节点读取所需内容，做一件事，然后将其结果写回状态。这听起来像一个小改动，但它解决了上述所有三个问题。

处理可变输入成为一个节点。不在 prompt 内部或调用周围做预处理，而是写一个节点，它唯一的工作是在下一个节点看到之前规范化输入。图使那个步骤可见、可测试、可替换，而不影响其他任何东西。

条件路由成为一个边。在合规示例中，评估交易金额的节点在状态中设置一个标志；然后一个条件边根据该标志将流程发送到"审查"分支或"报告"分支。分支逻辑位于图定义中，而不是 prompt 字符串内部，这意味着你可以读取它、版本化它、修改它，而无需重新提示。

错误处理也成为一个节点。你可以将重试节点附加到任何步骤，在一处集中超时逻辑，并将失败路由到记录出错的日志节点。try-except 块不再成倍增加。

可观测性是复合收益。因为每次转换都可以发出一个包含节点名、输入快照和输出快照的日志条目，你无需额外仪器就能获得运行时间线。当合规审计员问哪个规则标记了第 4,217 号交易时，你可以向他们展示该标记节点的确切状态。

四个信号——是时候迁移了

在评估一个新的 pipeline 是否从一开始就需要一个图时，我使用四个实际测试。

第一个信号是工具必须处理有意义不同的输入形状。如果你发现自己写了形状检测逻辑来守卫单个调用，那个逻辑应该是一个节点。

第二个信号是模型输出决定了哪个下游系统接收数据。每当一个步骤的输出控制下一个步骤发送结果的位置时，你就有了一个分支。将其编码为一条边比将其编码为 prompt 内的条件更安全、更易读。

第三个信号是你写了相同的重试逻辑两次。一次是合理的。两次意味着你有一个属于共享错误处理节点的模式，而不是分散在代码库中。

第四个信号是 pipeline 将面临合规或审计要求。如果监管者或内部审查员会问数据如何流经系统，LangGraph 产生的显式状态和日志条目比从应用日志重建要容易呈现得多。

任何一个信号都足以证明需要一张图。多个信号同时出现意味着单-shot 方法会在几周内浪费你的维护时间。

无需全量重写即可开始

这个过渡不需要抛弃你已有的东西。一个双节点图——一个节点做工具调用，一个做验证——是一个合理的起点。它引入状态字典，使验证步骤显式化，给你一个在调用失败时添加重试节点的地方。从那里，你可以根据需要一次扩展一个节点。

关于构建第一个 LangGraph pipeline 的中心帖子 walks through the essential steps: defining state, wrapping tool calls in nodes, adding conditional edges, and attaching error-handling nodes. The observability guide covers what to log at each transition so you can debug runs without replaying the entire pipeline. For finance-focused implementation detail, the case study at /work/finance-pipeline shows how a 19-node graph reduced manual reconciliation time by more than half on a production ledger pipeline.

If you are at the point where your current tool-calling code is starting to fight back, those three posts cover the path from the first graph to a deployed, monitored pipeline.

For help designing the graph structure for your specific stack, see /services or reach out through the contact page.

PS: Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.

For further actions, you may consider blocking this person and/or reporting abuse