LangGraph 与更简单的工具调用：何时选择哪种方案
当请求是自包含的——一次调用、一个结果、然后继续——单次工具调用（single-shot tool-calling）就是正确的默认选择。而当你的流程需要显式状态、条件分支，或者崩溃后依然可追溯的审计记录时，LangGraph 才是合适的那一个。找准这条分界线，既能避免过早重写，也能防止几个月后陷入一堆脆弱补丁的泥潭。
此前我写过如何搭建第一条 LangGraph 流水线，也写过如何把 LangGraph 部署到现有数据基础设施中。这篇文章要讨论的是更靠前的问题：你究竟怎么判断，什么时候该做出这个转变？
单次调用模式什么时候开始撑不住
当输入可预测、输出也能满足下游代码的全部需求时，单次工具调用运行得很干净。但以下三种情况下，这种模式会开始让你付出代价。
第一种是输入规模或模式不固定。一个能总结 200 行 CSV 的模型，当同一个接口收到 2 万行的文件时，表现会完全不同。一旦你需要加入预处理步骤——过滤、类型转换、数据增强——这些操作要么藏在提示词里，要么散落在调用外围临时拼凑的 Python 代码里。表面上流水线只有一个步骤，实际上并不是。
第二种是会影响下游路由的决策点。想象这样一个工作流：拉取一组金融交易记录，标记超过阈值的条目，把标记过的条目转给合规审查，其余的送进报表仪表盘。如果标记逻辑只存在于模型回复里，你就无法审计某条交易为什么被导向了某个方向。没有显式状态可以检查，也没有地方挂一条日志。
第三个问题是错误处理不断累积。当某个工具返回意外的数据结构时，你要加一个条件判断；再为限流错误加一个；再为上游 API 恰好在不该超时的时候超时这种边界情况加一个。代码看起来仍然是一次调用，但周围已经绕满了特例分支，只有原作者能完全看懂。新成员接手就成了风险。
显式状态与分支能带来什么
LangGraph 的核心是引入一个跨节点共享的状态字典。每个节点只读取自己需要的内容，做一件事，再把结果写回状态。听起来只是一个小改动，却能解决上面提到的三个问题。
处理可变输入可以变成一个节点。与其在提示词里或调用前后做预处理，不如专门写一个节点，只负责在下一个节点看到输入之前完成规范化。这样一来，这一步在图里变得可见、可测试，还可以单独替换，不用动其他任何逻辑。
条件路由变成一条边。比如在合规审核的例子中，一个评估交易金额的节点会在状态里设置一个标志；条件边根据这个标志，把流程导向“复核”分支或“上报”分支。分支逻辑写在图定义里，而不是藏在提示词字符串中，所以你可以直接查看、做版本管理，不用重新写提示词就能修改。
错误处理同样可以做成节点。你可以在任意步骤挂一个重试节点，把超时逻辑集中到一处，失败时把信息路由到负责记录异常的日志节点。try-except 块就不会越堆越多了。
可观测性则是长期积累的红利。因为每一次节点跳转都能输出一条日志，包含节点名、输入快照和输出快照，所以不需要额外埋点，就能得到完整的运行时间线。当合规审计人员问“哪条规则标记了第 4217 笔交易”时，你能直接展示标记节点当时的确切状态。
四个信号，说明该换用图方案了
我会用四个实用问题来判断：一个新流程是否从一开始就值得用图来搭建。
什么时候该用 LangGraph，什么时候用简单的工具调用就够了？
第一个信号：工具必须处理形态差异很大的输入。如果你发现自己要写一堆结构判断逻辑来保护一次工具调用，那这部分逻辑就应该放进一个节点。
第二个信号：模型输出决定数据要交给下游哪个系统。只要某一步的输出会影响下一步把结果送到哪里，这就是一个分支。把分支画成一条边（edge），比把条件逻辑塞进提示词里更安全、也更好读。
第三个信号：同样的重试逻辑你已经写了两遍。写一次是合理的；写两遍就说明这是一个应该收敛到共享错误处理节点的模式，而不是散落在代码各个角落里。
第四个信号：这条链路要面对合规或审计要求。如果监管机构或内部审查会追问数据在系统里是怎么流转的，LangGraph 那套显式的状态和日志记录，显然比事后从应用日志里拼凑还原要省事得多。
上面四个信号，只要中了一个，就值得考虑用图。如果中了好几个，还用单次调用的方案，几周之后你就会发现维护成本上来了。
不用推倒重来，也能上手
切换到图结构不意味着要把现有代码全扔掉。从一个两节点的图开始——一个节点负责工具调用，一个节点负责校验——就已经是合理的起点。它把状态字典（state dictionary）这个概念带进来，让校验步骤变得显式，也让你有了一个可以挂重试节点的位置，应付调用失败的情况。之后按需扩展，一次加一个节点就行。
Hub 上那篇关于构建第一个 LangGraph 管线的文章，把关键步骤讲得很清楚：定义状态、把工具调用包进节点、加条件边、挂错误处理节点。observability 指南则覆盖了每个转移节点该记录什么日志，这样调试运行时不至于把整条管线重跑一遍。如果你是金融场景，可以看看 /work/finance-pipelines 的案例研究——一个 19 节点的图，让生产环境账本管线的对账人工时间减少了一半以上。
如果你发现现有的工具调用代码开始变得难以驾驭，那三篇文章可以帮你理清思路——从搭建第一个图结构，到最终部署并监控完整的流程管线。
如需针对你的具体技术栈设计图结构，请参考 /services，或通过联系页面与我们取得联系。