项目为什么选择当前 Agent 框架？

核心回答

项目选 Agent 框架，应先看工具接入、控制流、状态恢复、部署与团队维护这些约束，再用同任务原型验证，而不是因为某个框架流行。

以需要“检索资料、生成草稿、人工审阅、不合格则补查”的项目为选型示例：我会考虑 LangGraph，因为共享状态、节点和条件边适合表达分支与循环，检查点和中断机制可以支持恢复与人工介入。若只有一次模型调用或固定检索生成，普通代码或较高层组件可能已经足够。框架复用的是通用执行机制，业务规则、工具契约和验收仍要自己实现。

展开说明

从必须满足的条件筛选

先列真实需求：是否需要循环补查、是否等待人工、任务是否跨进程恢复、工具能否接入、数据在哪部署。再看团队语言、依赖升级、调试和运维能力。拥有某个功能名不够，还要确认其实际语义是否满足业务。

LangChain 主要提供模型、工具、检索等抽象和集成；LangGraph 提供更显式的有状态编排。两者可以配合，LangGraph 也可以独立使用。选择较高层 Agent 循环还是自己构图，取决于是否需要控制每一步状态与流转，不是两者只能选一个。

用一条完整任务验证选型

对同一份资料、工具、模型和验收问题，比较最小原型。除了正常完成，还测试工具失败、人工暂停后继续、服务中断恢复和重复提交，记录能否完成、错误能否定位、状态是否正确、时间与调用成本。

例如草稿没有证据，应该补查而不是直接结束；人工改了结论，后续节点应读取更新状态。恢复时检查当前步骤是否重执行，工具写入使用业务幂等键。LangGraph 的检查点不等于外部接口天然“只执行一次”，业务副作用需要自己约束。

为什么有时选择自己做 Runtime？

如果现成框架在事件协议、工具调度、部署或状态格式上与项目有明确冲突，可以用较小的自定义循环控制这些边界。但要承担消息配对、错误处理、取消、状态保存、观测与回归的维护成本。

只有少量定制时，优先使用扩展接口或在框架外做业务适配；确实需要自建时，说明具体冲突、替代实现及验证。把“自己写更灵活”当作理由，无法解释总成本和可靠性。

可能的追问

选择 LangGraph 后，最容易忽略什么？

状态字段的更新方式、并行写入冲突、检查点持久化，以及中断或重试时节点可能重执行。尤其不能把进程内保存器当成服务重启后的持久恢复；写操作在恢复后可能重做，要设计幂等和结果核对。

不用框架是不是更容易调试？

短链路可能更直接；复杂状态与恢复自行实现后也会产生隐性框架。应比较实际问题定位时间、代码复杂度和维护负担，不能只比较初版行数。

对应教程

参考资料