先这样答
相比手写 prompt 流程，LangGraph 的核心优势在于将散落的控制逻辑抽象为图结构，并提供统一的状态管理。手写流程通常是一个 while 循环，在循环体内部负责拼接消息、调用模型、解析工具调用、执行具体逻辑以及回填结果。这种单条链路跑起来确实能走通，但一旦业务需要引入状态管理，比如中断恢复、复杂的分支走向或者针对特定错误的重试机制，开发者就只能在业务代码里堆砌大量的条件判断语句，导致代码逻辑变得难以维护。
LangGraph 则是把整个执行流程显式建模成一张图，其中的节点代表具体的执行步骤，边代表步骤之间的转移过程，并且支持条件路由来决定下一步走向。整个流程的状态不再依靠散落的消息拼接，而是被定义为一个统一的 schema 对象。这种工程化设计带来了几项直接的收益。首先是免费获得了 checkpoint 机制，因为每一步执行都会被持久化，天然支持任务的中断恢复以及时间旅行调试。其次是容易实现人工审核，可以在指定的节点将任务挂起，等人审后再继续。最后，它原生支持并发分支与子图嵌套，同时附带了流式输出与逐步追踪功能。这些机制如果全部由团队自研，不仅需要重新写一遍底层逻辑，还很容易写出边界缺陷。
至于选择 LangGraph 还是自研，主要取决于业务的状态复杂度与可靠性需求。如果链路涉及复杂的恢复机制、人工审核或者高并发，选择图框架更为稳妥。但如果链路属于极端定制的场景，例如需要非图结构的动态规划算法，或者系统对延迟与依赖体积非常敏感，就应该考虑自研。此外，如果团队已经拥有成熟的自研调度基座，或者需要深度控制底层调度细节，自研也是更好的选择。框架的抽象层带有学习与升级成本，对于非常简单的单链任务，上手直接写循环反而比引入框架更快。
在实际的选型口径上，并不需要将两者完全对立。一种常见的做法是先使用框架起步完成业务验证，当发现部分环节存在瓶颈时，再将特定的节点替换为自研逻辑。在面试官面前可以这样收束：LangGraph 卖的从来不是提示词能力，而是状态与可靠性的工程化。
面试官会怎么追问
- 「如果业务链路非常简单，只是调两个工具，还有必要上 LangGraph 吗」 此时没有必要。引入框架会带来额外的抽象层和依赖体积，对于简单的单条链路任务，直接手写 while 循环开发速度更快，维护成本也更低。当后续业务需求增加，状态管理开始变得复杂时，再考虑将其迁移到图框架中。
- 「你提到 LangGraph 支持人审挂起，底层是怎么挂起和恢复的」 这主要依赖其 checkpoint 机制。图在执行到指定的挂起节点前，会将当前统一的状态 schema 持久化存储并暂停当前执行。人工审核完成后，系统会读取对应的 checkpoint 恢复状态对象，并沿着图的边继续向下执行后续节点。
- 「自研框架在什么情况下表现会比 LangGraph 好」 在对延迟极度敏感或需要深度控制调度细节的场景下表现更好。如果业务逻辑属于非图结构的动态规划，或者团队已经有成熟的自研基座，自研可以避免引入第三方框架升级带来的学习成本，也能更灵活地控制依赖体积。
回答的坑
把 LangGraph 的优势归结为模型效果好，实际上这类框架不改变模型的提示词能力，它们解决的纯粹是状态管理和执行可靠性的工程问题。
认为自研和框架是对立的互斥选项，正确的工程思路是可以先用框架快速搭建流程，在遇到性能瓶颈或者特殊需求时，将特定节点替换为自研实现。
同系列的题