最近一直在折腾 LangGraph。
看了不少 Demo，也看了官方文档，还参考了一些开源项目。
我最大的感受就是：
大部分 LangGraph 示例都是为了演示功能，而不是为了上线。
真正做线上系统，关注点完全不一样。
例如：
一个节点失败怎么办？
LLM 输出 JSON 不合法怎么办？
用户修改内容后怎么继续执行？
如何做到断点恢复？
一个 Agent 运行十几分钟如何管理状态？
如何避免整个 Graph 越来越复杂？
这些问题，在 Demo 里基本都不会出现，但线上一定会遇到。
下面分享一下我目前认为比较容易维护的一套设计思路。
- 1.不要把 LangGraph 当成流程图，把业务流程和 Agent 流程混在了一起
- 2.Graph 只负责状态，不负责业务，真正的业务，全部交给 Service，Graph 只负责，下一步去哪。
- 3.State 永远不要无限增长，很多 Demo，运行几分钟以后，Context 越来越大，LLM 成本越来越高，真正大文本，全部放数据库，State 里面只保存引用。
- 4.Node 应该像微服务，每个节点只有一个职责，以后替换模型也非常容易。例如：Draft换Claude，Review换 GPT。Quality换规则引擎,Graph 不需要修改。
- 5.不要相信 LLM 一次就成功，线上一定会遇到：JSON 不合法，字段缺失，格式错误，真正稳定的不是 Prompt，而是输出之后还能自动修。
很多人觉得：Agent 的核心是 Prompt。
我现在越来越觉得真正决定线上质量的是：
状态管理
+
错误恢复
+
结构化输出
+
可观察性
+
Checkpoint
+
Human Loop
Prompt 只是其中一部分，如果这些工程能力没有做好，模型再强，Graph 也很难稳定运行。
想听听大家的看法
以上只是我最近在设计 Agent 架构时的一些思考，还没有哪一种方案能适用于所有场景。
也想请教几个问题：
- 大家线上会把 State 全部放内存，还是做持久化？
- Review/Fix 会做循环次数限制吗？
- Checkpoint 是按节点存，还是按业务阶段存？
- 有没有人在生产环境大规模使用 LangGraph？踩过哪些坑？
欢迎分享你们的实践，我也想看看有没有更好的设计思路。
Comments
lingfan · 2026-07-23
我说说我的看法吧 我觉得非必要不要上LLM，想好LLM主要做的是什么 业务中那些地方是规则引擎解决不了的 比如归类 有些文章标题写的天花乱坠 规则根本理解不了 这种情况下可以考虑上LLM 。在使用LLM过程中会遇到各种错误 ，执行过程是黑盒，你无法穷尽完所有的错误，只能提前解决大概率会发生的常见问题，以及找到一条正确的路线 在执行前做好判断，让LLM继续走正确的路线，同时重试异常捕获 日志记录通知等等，不断改进。这是我的一些看法 不知道对佬有没有帮助