2. Linux.do
  3. 这是我设计和迭代 LangGraph 工程架构时的思考和方案，欢迎大家提提意见

这是我设计和迭代 LangGraph 工程架构时的思考和方案，欢迎大家提提意见

admin1 2026-07-23 11:02 1

LangGraph 在线上到底应该怎么设计？聊聊我认为真正能落地的 Agent 架构


最近一直在折腾 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 架构时的一些思考，还没有哪一种方案能适用于所有场景。

也想请教几个问题：



  1. 大家线上会把 State 全部放内存，还是做持久化？

  2. Review/Fix 会做循环次数限制吗？

  3. Checkpoint 是按节点存，还是按业务阶段存？

  4. 有没有人在生产环境大规模使用 LangGraph？踩过哪些坑？


欢迎分享你们的实践，我也想看看有没有更好的设计思路。 ^-^

最新回复 (10)
  • 凌凡 07-23 11:25
    1楼

    我说说我的看法吧 我觉得非必要不要上LLM，想好LLM主要做的是什么 业务中那些地方是规则引擎解决不了的 比如归类 有些文章标题写的天花乱坠 规则根本理解不了 这种情况下可以考虑上LLM 。在使用LLM过程中会遇到各种错误 ，执行过程是黑盒，你无法穷尽完所有的错误，只能提前解决大概率会发生的常见问题，以及找到一条正确的路线 在执行前做好判断，让LLM继续走正确的路线，同时重试异常捕获 日志记录通知等等，不断改进。这是我的一些看法 不知道对佬有没有帮助

  • 无敌 07-23 11:33
    2楼

    langgraph从最开始就是错误的,搞一个复杂的工作流编排,就是最大的问题,工作流编排用扣子就行,如果是要发挥模型最大的能力,应该学习claude code的完全体agent,自主选工具,skill,上下文

  • ltzh3530 07-23 17:26
    3楼

    前面自己做量化就思考过这个问题 其实最后想的办法是固定一个状态给llm 这就相当于替代人做判断 还是很难实现统一 后面就没做了 不过现在新悟到了一个底层原理 等有时间了再说

  • wuming1 07-23 17:55
    4楼

    我工作流直接用codex cli了 真大模型我真搞不懂 直接拿市面上现成的去干活了

  • 捉水母吗 07-23 17:57
    5楼

    卧槽，我还真遇到这个 LLM 输出 JSON 不合法了，让AI改，说不合法重新生成

  • Kassdin 07-23 17:59
    6楼

    这只对个人有效。对个人用户来说，没必要固化流程，直接写 Skill 就行了。做不好就打断提示一下。但是对生产环境来说，既然本身都是靠 Skill 约束工作流程，为什么不直接固化为固定的 workflow来减少不确定性？


    Skill 是为了可交互场景去做的，企业里还有很多非交互的场景，这些地方是 langgraph 发挥的空间（当然，也不是非他不可，SDK 其实就已经够了）

  • 无敌 07-23 18:19
    7楼

    关键是工作流无法覆盖所有场景,无法穷尽,能这样干的场景也很少,真实物理世界也不是固化的啊

  • admin1 楼主 07-23 18:20
    8楼

    agent完全体固然可以，但是面对固定业务模式，langgraph优势明显，减少token开支，减少业务完成时间，减少业务错误率，这才是面向生产业务的解法吧，各人拙见

  • 张林 07-23 18:24
    9楼

    用langgraph，还不如自己做开发。langgraph会限制好多的想法功能实现，或者说会绕远路。也有可能是我没有真正会使用它

  • Lemonade 07-23 18:25
    10楼

    我这里说得是某一个行业的 agent ，不是通用 agent。

    大体上基本首先你的项目需求用不用得上 agent。一般业务其实 workflow 就够了。或者 workflow + 部分agent 就行。多 agent 听着厉害，实际实施很多麻烦事情。

    然后就是首先 pormpt 调整好了再去管其他的东西。很多东西比如 错误降级 + 重试（网络可以重试，其他类似支付、删除不应该重试，尤其是有副作用的）以及 幂等 + checkpoint 是必须考虑的。然后就是可观测性多次调试。

    然后才是什么 SFT 还有 agentic rl ，不断收集 bad case 做迭代优化。

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐