LangGraph 不是默认答案，Agent 工作流上线前先补验证层

Labyrinth Analytics Consulting 在 4 月 26 日的一篇文章里，讲了一个金融数据客户的 LangGraph 项目：7 个数据源，19 个节点，用来处理交易数据、分类、校验和人工复核。

这个案例有意思的地方，不是节点数量。19 个节点也不能拿来当行业指标。它真正提醒的是：企业做 agentic AI 工作流时，最该先问的不是“要不要上 LangGraph”，而是“这个流程复杂到必须用图来管了吗”。

我更在意的是另一个问题：上线以后，谁来证明 AI 的结果是对的？如果只证明流程跑完了，那离生产系统还差一截。

该不该用 LangGraph，看状态复杂度

LangGraph 的核心价值，是处理有状态、多步骤、条件分支和可恢复的 AI 工作流。

换句话说，它适合流程会“边跑边变”的场景。上一个节点的判断，会影响下一个节点走哪条路；中间可能要暂停等人审；某个节点失败后，还要从 checkpoint 接着跑。

如果只是一次模型调用，再加几条 if-else，LangGraph 可能反而太重。普通 Python 更直接，排错成本也低。

Airflow、Prefect 则更适合另一类问题：确定性强、结构固定的数据流程。比如定时抽取、清洗、入仓、生成报表。流程大多提前写死，不依赖模型在运行时做语义判断。

对技术负责人来说，这会直接影响采购和立项节奏。

如果团队还没证明流程确实需要动态路由，就不必急着把项目迁到 LangGraph。先用 Python 或现有调度系统跑通业务闭环，可能更稳。等到状态、分支、人审、恢复都开始变复杂，再引入图式编排，理由才站得住。

工具不是路线。复杂性本身，才是选型依据。

生产难点不在画图，在验证结果

原文里的金融数据案例，接入了 7 个数据源，由 19 个节点组成。它覆盖抽取、分类、校验和人工复核。

这个案例说明的不是“金融项目都要 19 个节点”。它说明的是：当数据来源多、规则复杂、分类错误会传导到下游时，单靠一个顺滑的 AI 流程图不够。

原文提到一个关键设计：maker-checker。

maker 节点按分类结果做计算。checker 节点独立检查结果是否成立。两者一致，结果进入输出层；两者不一致，就把交易、计算结果和输入依据交给人工审核。

这里要避免一个误解：checker 不等于必须再调用一个 LLM。

规则校验、阈值检查、统计抽样、人工抽检，都可以是验证机制。关键是它要相对独立，不能只是把同一个 AI 输出换个包装再信一遍。

企业 AI 系统最麻烦的事故，往往不是程序挂了。挂了至少会报警。更麻烦的是程序正常运行，结果却错了。

所以生产监控不能只看运行时长、失败率、接口超时。金融、税务、合规、医疗等场景，还要看结果分布、抽样准确性、异常比例和漂移迹象。

这会改变工程团队的工作重心。

做 LangGraph 项目，不只是多写几个节点。更要提前定义：状态里存什么、谁能改、失败后从哪里恢复、哪些节点必须有人审、哪些结果必须被规则或抽样检查。

这些东西不漂亮，但它们决定系统能不能进生产。

选顾问和验收项目，要问失败怎么处理

LangGraph 项目最容易在三件事上翻车：状态膨胀、缺少错误边界、没有独立验证层。

状态膨胀，会让长流程越来越难追踪。错误边界不清，一个节点异常可能拖垮整条图。没有 checker，系统就变成把 AI 输出直接推到生产数据里。

这也是采购顾问或外包团队时最该追问的地方。不要只看 demo，也不要只看架构图。

更有用的问题是这些：

如果对方只能展示一个顺畅的 demo，却说不清失败、恢复、验证和人审，那项目风险很高。

对正在评估 agentic AI 工作流的团队，我的判断很简单：可以先延后采购或迁移决策，把验证机制列成验收项。没有验证层，不要把 LangGraph 项目当生产系统验收。

接下来最该观察的变量，也不是 LangGraph 教程多不多。

要看企业是否把验证层、人审成本、准确性监控放进正式预算。只愿意为 demo 付钱，不愿意为 checker、抽样和恢复机制付钱，最后大概率会得到一张好看的图，以及一套没人敢完全相信的系统。

回到开头那个金融数据案例。7 个数据源、19 个节点，真正值得记住的不是数字，而是它背后的约束：流程越会自己改道，越需要有人和规则站在旁边验算。

图能组织复杂性，但不能替你承担判断。