考察点
「做 Agent 有哪些框架？什么情况下选哪个？」考察的不是名词背诵，而是你对各框架抽象层级的理解，以及从 demo 到生产这个过渡里框架会暴露什么问题。能讲出「为什么生产上很多人最后退回自研薄循环」是真实经验的体现。
参考答案
先按抽象层级分类
框架混战看着眼花，其实按「它帮你管什么」可以分成三层：
1. 组件抽象层：LangChain（传统链）、LlamaIndex。帮你统一 LLM、工具、检索器的接口，快速拼出 RAG 和简单链。问题是链式抽象（LCEL）假设流程是线性的，而 Agent 是带状态的循环，硬套会拧巴。现在这层的价值主要是生态——各种模型和向量库的接入适配器现成。
2. 状态机层：LangGraph。把 Agent 建模成图：节点是函数（LLM 调用或工具执行），边是状态转移，有一个显式的全局 State 在节点间流动。它真正值钱的是三样生产件：checkpointer（状态持久化、断点续跑）、interrupt（人工介入点）、time-travel 调试（回到任意历史状态重放）。这三样自研成本不低，是 LangGraph 的护城河。
3. 多 Agent 对话层：AutoGen、CrewAI。抽象单位是「角色」和「对话」，你定义几个 Agent 人设和协作规则，框架管消息路由。做原型和验证多 Agent 想法非常快，但自由对话在生产上不可控——轮数不可预测、token 消耗不可预测、出错了定位困难。
选型的四个判断维度
可控性：流程中有多少必须写死的确定路径？金融、审批类业务，选 LangGraph 这种显式状态机；探索性研究类，AutoGen 的自由度可以接受。原则：框架给的自由度 = 你业务的容错度。
可观测性：框架能不能给出每次 LLM 调用的完整 trace？LangGraph 配 LangSmith、或者自己接 OpenTelemetry 都行；黑盒框架直接排除。
状态管理：任务会不会长跑（分钟级以上）、会不会中断恢复、需不需要人审？需要，就绕不开 checkpointer 这类机制，这是自研最肉疼的部分，用框架最划算。
团队心智成本：LangChain 全家桶的抽象层数多，新人上手要爬的坡不短。如果团队多数人是后端背景，「显式状态机」比「魔法链式调用」好理解得多。
一个务实的选型路径
我实际项目里的演化路径，供参考：
- 验证期：什么都不用，200 行手写 ReAct 循环 + OpenAI SDK。目的是搞清楚这个业务里 Agent 到底怎么跑、需要什么控制点。这个阶段框架是负担。
- 成型期：循环变复杂了（要 checkpoint、要人审、要并行分支），迁到 LangGraph，把已经验证过的循环逻辑翻译成节点和边。手写循环里验证过的 prompt 和工具原样保留。
- 多 Agent 期：确实需要多角色协作，先在 LangGraph 里用 supervisor 模式实现（节点即 Agent），AutoGen 只在需要快速验证「多 Agent 到底有没有收益」时做一次性原型。
两个常见的坑
过早框架化。业务还没跑通就先引入三层抽象，出 bug 时在框架的回调栈里找半天，最后发现是 prompt 问题。框架放大了所有复杂度，包括你还没想清楚的部分。
把框架当架构。框架解决的是编排问题，不解决你的业务问题：工具设计、上下文管理、评估体系，这些该自建的一样少不了。见过团队把 LangChain 的链定义当系统架构图，结果链之外的权限、降级、审计全无，上线就翻车。框架是零件，不是房子。
可能的追问
- 「LangGraph 的节点和边相比传统工作流引擎有什么优势？」 状态是一等公民（全局 State 任意读写）、边可以是条件函数（模型输出决定走向）、原生支持循环和人审中断——传统 BPM 引擎的转移条件是写死的规则。
- 「Java 技术栈怎么办？」 LangChain4j / Spring AI 在跟进，生态成熟度落后 Python 一截；务实做法是 Agent 编排层用 Python 服务化，Java 主系统走 RPC 调用。
- 「为什么不直接用 Dify/Coze 这类低代码平台？」 快速验证可以；但它们把编排封装在黑盒里，深度定制（自定义循环控制、特殊权限逻辑）和性能调优空间小，长期看核心链路还是要自持。