开发 Agent，应该用 LangChain、LangGraph，还是自己写？
🧑💻 面试官：你做一个 Agent，会选择 LangChain、LangGraph，还是直接调用模型 SDK？
🙋♂️ 我：如果只是一个简单循环，可以自己写；需要更复杂的状态和流程时，可以考虑框架。
🧑💻 面试官：那 LangChain 就不能暂停和恢复吗？
🙋♂️ 我：不能这么判断。现在 LangChain 的 Agent 底层就使用 LangGraph，要看暴露的能力是否够用。
🧑💻 面试官：既然底层有关联，你为什么还要直接用 LangGraph？自己写又省下了什么、承担了什么？
选框架要回答的是：哪些运行细节需要你控制，哪些能力可以复用，以及剩下的维护工作由谁承担。
面试速答（60 秒版）
这三个选择并不是按“简单、中等、复杂”排成一条线。LangChain 提供比较高层的模型、工具和 Agent 组织方式，它的 Agent 底层使用 LangGraph；LangGraph 则让我们更直接地定义状态、节点和执行路径。
如果标准的模型与工具循环已经满足需求，可以先用 LangChain，减少基础接入工作。需要明确控制业务分支、暂停位置、并行任务和状态合并时，可以直接使用 LangGraph，也可以在图里组合 LangChain 的组件。
自己写适合范围可控、已有基础设施，或者确实需要特殊实现的情况。但不使用框架，不代表运行系统的工作消失了：状态、重试、权限、恢复和调试仍然要有人负责。
最终我会拿同一个小业务验证扩展与故障场景，再比较开发、排错和长期维护成本，而不是只比较第一版用了多少行代码。
知识点详解：把三种方案放进同一个项目比较
先把它们的关系说准确
按本次核验的 LangChain 官方说明，LangChain 的 Agent 建立在 LangGraph 之上。因此，“LangChain 只能线性执行，LangGraph 才能做循环”已经不是一个可靠的选型依据。
LangGraph 的定位更接近底层编排运行时：你可以直接定义状态如何变化、节点之间怎样转移，以及确定规则和模型决策如何结合。
二者可以一起用。比如外层用 LangGraph 表达业务流程，某个节点里使用 LangChain 的模型接口或 Agent。所谓“自己写”，也不必从 HTTP 请求开始重复造轮子；可以直接使用模型 SDK，再接上团队已有的任务队列和状态存储。
所以，先说明你准备接管哪一层，再讨论选型，才不会拿不同范围的东西硬比。
第一版只查工单，哪里需要自定义？
假设咱们要做一个运维助手：用户描述故障，Agent 查询已有工单，再给出相关处理记录。
这一版主要是模型判断是否查询、调用只读工具、结合结果回答。如果标准 Agent 循环已经能够表达，LangChain 可以减少模型接入、工具组织等重复工作。
如果团队已经有稳定的模型网关、工具执行器和日志系统，直接使用 SDK 实现这一小段循环，也可能更容易维护。关键是复用了哪些已有能力，而不是把“自己写”理解成什么都不需要。
此时直接画一张包含很多节点的图，不一定带来价值。节点多不是更专业；要看是否有业务状态需要被单独表达和检查。
加入审批后，真正变化的是执行要求
后来需求变了：找不到合适工单时，可以拟定一个新工单，但必须由用户确认标题、内容和项目后，才能正式创建。用户可能隔天才回来审批。
这时需要明确区分“正在查询”“等待确认”“确认后创建”“创建成功”等状态，还要保存草稿和审批对象。服务重启后，也应该能找到原来的任务。
如果高层 Agent 提供的中间件和持久化能力能够清楚表达这些需求，可以继续使用。不要一出现审批就认定必须推翻现有实现。
但如果流程还有固定校验、多个审批分支、并行查询和明确的状态合并，直接定义 LangGraph 图，可能更方便检查每个步骤的输入、输出和去向。
这种选择是为了获得必要的控制，不是因为图天然比循环更高级。底层框架提供恢复机制，也不意味着业务侧的权限、幂等和审批有效期会自动正确，需要单独设计。
自己写，要把隐藏的工作算进去
一个演示循环可能很短：调用模型，发现工具请求就执行，再把结果传回去。但进入真实业务后，下面这些问题都会出现：
| 问题 | 不使用框架时谁来处理 |
|---|---|
| 模型返回不同消息或工具格式 | 自己的适配层，或所选 SDK |
| 执行到一半退出 | 自己接入的状态与任务恢复机制 |
| 工具重复执行或超时 | 工具协议与业务幂等设计 |
| 查不到哪一步出了错 | Trace、日志和任务查询能力 |
| 旧任务遇到新代码 | 状态兼容与运行版本管理 |
这些工作可以由现成基础设施承担，不一定都要自己开发。但选型时应该列出明确的承担者，不能把它们从成本表里删掉。
反过来，使用框架也有代价：需要理解抽象、跟进升级、排查框架与业务之间的边界问题。有时一个特殊流程为了塞进现有接口，需要写很多绕行逻辑，这也是重新选择的信号。
怎样做一个有用的选型验证？
不要分别做三个不同的 Demo。就拿“查询工单，必要时确认后创建”这一条流程，用候选方案实现相同的最小范围。
然后增加几个条件：工具超时、用户第二天确认、服务重启、审批后参数被修改、模型换成另一家。检查实现是否容易调整，状态能否看懂，错误能否定位，以及哪些地方必须依赖额外服务。
性能测试也要区分框架处理时间与模型、网络、工具耗时。没有实际测量，不能因为一段代码短，就认定它延迟更低。
最后选择团队能解释、能排错、能持续维护的方案。这个结论可能是继续用高层 Agent，也可能是显式图，或者是已有业务运行系统加模型 SDK。
面试官继续追问
LangGraph 自带持久化，用上就能重启恢复吗？
要正确配置持久化后端、任务标识和状态保存方式。只用内存保存，进程退出后数据就会消失。而且恢复运行状态与避免外部动作重复，是两个问题，后者仍然依赖业务操作的幂等和结果查询。
害怕框架绑定，是否应该一开始全部自研？
不必。可以把业务工具、数据结构、权限规则和验收用例独立出来，减少核心业务对框架内部对象的依赖。自研本身也会形成内部实现绑定，需要维护和迁移，不是天然没有成本。
团队只有一个人，选最简单的就行吗？
要明确“简单”指什么。调用代码少，不一定排错简单；基础设施少，也不一定恢复简单。优先选择你能理解并维护的最小方案，同时列清未支持的能力，避免用演示项目的复杂度估算正式服务。
面试速记卡
- 关系判断：LangChain Agent 底层使用 LangGraph，不是互斥的两套世界。
- 高层接口：标准循环足够时，先利用现成组织能力。
- 显式编排：需要控制状态与业务路径时，再接管更底层流程。
- 自研成本：不依赖框架，也要有人负责运行、恢复和排错。
- 选型验证：同一业务、同一故障条件下比较长期维护成本。
