智能体面试准备（二十九）：主流智能体框架实战——LangGraph、AutoGen、CrewAI 对比与选型踩坑

前面我们把 Agent 的核心能力拆了个遍：ReAct（B12）、Function Calling（B18）、多智能体协作（B15）、记忆（B13）、人机协作（B27）、编程智能体（B28）。但到了真正写项目，没人会从零手搓一个循环——大家都会选一个框架。2024-2025 年最主流的三剑客是 LangGraph、AutoGen、CrewAI，它们解决的是同一类"工程脏活"：状态管理、持久化、并发、人机协作、可观测。但三者抽象完全不同，选错框架等于给项目埋雷。这是本系列第二十九篇。本文按"为什么用框架 → LangGraph 实战 → AutoGen 实战 → CrewAI 实战 → 三框架横评 → 选型决策树与坑"展开，结尾给面试速答和高频追问清单。

---

一、为什么要用框架而不是手写循环

1.1 手写 Agent 的脏活

从零写一个 ReAct 循环不难（几十行），但一旦要上生产，立刻冒出一堆"非功能性"需求：怎么把对话状态存进数据库以便断线重连（B22）？怎么在关键节点停下来问人（B27）？多智能体之间怎么传递消息、怎么并发？出错怎么重试和回滚？怎么把每一步 trace 打出来排障（B20）？

这些事的累计工作量远超"核心循环"本身。框架的价值就是把这套"状态机 + 持久化 + 人机 + 可观测"的脚手架标准化，让你专注在"这个 Agent 该干什么"上。面试被问"为什么不直接用 while 循环"时，答"生产级 Agent 的复杂度在循环之外"就抓住了要点。

1.2 三个框架的抽象差异

框架	核心抽象	心智模型	最强项
LangGraph	有向图（节点+边+状态）	"Agent 是一张状态流图"	可控流程、持久化、人机、复杂分支
AutoGen	可对话的 Agent + 群聊	"Agent 们开会"	多 Agent 对话编排、代码执行
CrewAI	角色 + 任务 + 流程	"组一支团队干活"	角色化协作、快速搭建、可读性

理解这个差异，选型就不会乱：要"精确控制每一步走哪"选 LangGraph；要"几个专家对话求解"选 AutoGen；要"按角色分工快速出活"选 CrewAI。

---

二、LangGraph 实战：把 Agent 画成图

2.1 核心概念

LangGraph 把 Agent 建模成一张图：节点（node）是执行单元（比如"调用 LLM""调工具""人工审核"），边（edge）是流转条件，状态（state）是在节点间传递的结构化数据（通常是一个 TypedDict/pydantic，含 messages 列表）。图的"终点"可以是普通节点，也可以是条件分支（conditional edge），根据状态决定下一步去哪——这天然实现了 ReAct 的"先想后做、按需循环"。

它最强的区别于其他框架的是：checkpointer（检查点）。图每走一步都把一个快照写入存储器（内存、SQLite、Postgres），所以你能随时暂停、恢复、回溯、甚至"时间旅行"到某一步重走。这直接落地了 B22 的断点续跑和 B27 的人机交接。

2.2 最小可运行示例

from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, END

class State(TypedDict):
    messages: Annotated[list, "对话历史"]

def call_model(s):
    # 调 LLM，把回复追加进 messages
    return {"messages": s["messages"] + [llm_reply]}

def call_tool(s):
    # 执行工具，追加观测
    return {"messages": s["messages"] + [tool_obs]}

def should_continue(s):
    return "tool" if needs_tool(s) else END

g = StateGraph(State)
g.add_node("model", call_model)
g.add_node("tool", call_tool)
g.add_edge("model", "tool")                 # 需要工具则去 tool
g.add_conditional_edges("tool", should_continue, {"tool": "model", END: END})
app = g.compile(checkpointer=MemorySaver())

注意 should_continue 这个 conditional edge——它就是 ReAct 里"该继续调用工具还是收尾"的判断点。把循环逻辑显式写成图，比手写 while 更易读、可持久化、可观测。

---

三、AutoGen 实战：让 Agent 们对话

3.1 核心概念

AutoGen 的抽象是"会聊天的 Agent"。每个 Agent 有角色设定和能干的事（比如一个 assistant 能执行代码，一个 user-proxy 代表人类或代发指令）。最经典的是 GroupChat：把多个 Agent 放进一个群聊，由"群聊管理员"决定下一步轮到谁发言，大家在对话中协作完成任务。它的强项是"多专家通过对话求解"，尤其擅长"写代码→跑代码→看报错→改"的编程场景（呼应 B28）。

3.2 最小可运行示例

import autogen
cfg = {"model": "gpt-4o", "api_key": "...", "code_execution_config": {"use_docker": False}}
assistant = autogen.AssistantAgent("assistant", llm_config=cfg)
userproxy = autogen.UserProxyAgent("user", human_input_mode="NEVER",
                                   code_execution_config={"use_docker": False})
group = autogen.GroupChat(agents=[userproxy, assistant], messages=[], max_round=10)
mgr = autogen.GroupChatManager(group, llm_config=cfg)
userproxy.initiate_chat(mgr, message="用 Python 实现并测试快速排序")

这里 userproxy 既代人类发需求，又能直接执行 assistant 生成的代码（code_execution_config），形成"生成-执行-反馈"闭环。AutoGen 把"谁在什么时候说话"交给群聊管理器，适合探索性强、流程不固定的任务。

3.3 它的坑

AutoGen 的群聊是"自由对话"，流程可控性弱于 LangGraph 的显式图；max_round 不只守护成本，否则容易陷入 Agent 互相捧场、无限循环的"嘴炮"。生产上常需要加明确的终止条件、结果校验、人工兜底。

---

四、CrewAI 实战：组一支团队

4.1 核心概念

CrewAI 把 Agent 建模成"带角色的同事"：每个 Agent 有 role（如"资深研究员"）、goal、backstory；Task 描述要做什么；Process 定义协作方式（顺序 Flow 或 hierarchical 层级）。它主打"可读性高、上手快、像在组队"，适合把"多个专长角色分工完成一项复杂任务"快速落地。

4.2 最小可运行示例

from crewai import Agent, Task, Crew, Process

researcher = Agent(role="研究员", goal="搜集竞品信息", backstory="十年行业老兵")
writer = Agent(role="撰稿人", goal="写成报告", backstory="技术作家")

task1 = Task(description="调研 A 产品功能", agent=researcher)
task2 = Task(description="基于调研写报告", agent=writer)

crew = Crew(agents=[researcher, writer], tasks=[task1, task2], process=Process.sequential)
crew.kickoff()

CrewAI 的卖点是"用自然语言式角色定义就能跑起来"，代码可读性极强，对非工程背景的团队友好。代价是细粒度控制不如 LangGraph，复杂分支和状态持久化要绕路。

---

五、三框架横评

维度	LangGraph	AutoGen	CrewAI
流程可控性	最强（显式图、条件分支）	弱（群聊自由）	中（顺序/层级）
状态持久化	一等公民（checkpointer）	需自己接	弱
人机协作	原生（interrupt）	user-proxy	弱
多 Agent 协作	图编排	群聊	角色分工
可观测	好（state 可见、可接 OTel）	一般	一般
上手难度	高（要学图抽象）	中	低
典型场景	复杂可控业务流程	探索性多专家求解	快速组队出活

一个常见误区是"三个都差不多，随便选"。实际差异在"流程要不要精确控制"和"要不要持久化/人机"上被急剧放大——做审批流、长时任务，LangGraph 几乎是唯一能稳妥落地的；做头脑风暴式多 Agent 解题，AutoGen 更顺手；做 demo 或轻量分工，CrewAI 最快。

---

六、选型决策树与常见坑

6.1 决策树

• 流程复杂、要持久化、要人工审核节点、要可回溯 → LangGraph；
• 多专家对话求解、探索性强、代码执行闭环 → AutoGen；
• 快速搭原型、角色分工清晰、可读性优先 → CrewAI；
• 三者都嫌重、逻辑极简单且一次性 → 手写 ReAct（但要想清楚 B22/B27/B20 怎么补）。

6.2 真实落地踩坑清单

第一，过度依赖框架的"自动循环"导致失控：AutoGen 群聊不设 max_round 和终止条件，Agent 空转烧钱；LangGraph 不画清楚条件边，状态卡死在某节点。第二，把状态管理想当然：没接 checkpointer，一重启全丢，违背 B22 的断点续跑原则。第三，可观测缺位：框架帮你跑起来，但每一步 LLM 调用、工具结果没打 trace（B20），上线后无法排障。第四，人机协作只在 demo 层：真实审批流要权限、要审计、要超时兜底（B27），框架只给 interrupt 原语，业务规则得自己写。第五，成本无护栏：没有预算上限和模型路由（B26），多 Agent 一开，token 费用指数级上涨。

6.3 框架不是银弹

最后要强调：框架解决"工程脚手架"，不解决"Agent 聪不聪明"。一个用 LangGraph 精心画的图，如果底层提示词烂、工具设计差、没接检索，照样产出垃圾。框架是把你从脏活里解放出来，让你把精力投到真正决定效果的地方——这点和写不写框架无关，是 Agent 工程的通用真理。

---

七、真实项目里的框架落地经验

7.1 框架只是开始，脚手架之外的活才是关键

选好框架只是第一步。无论选哪个，生产里都要补四件框架不替你做的事：状态要接持久化（否则重启丢上下文，违背 B22）；关键节点要接人工审核（否则危险动作无人把关，违背 B27）；每一步 LLM 与工具调用要打 trace（否则线上黑盒无法排障，违背 B20）；token 与金额要设护栏（否则多 Agent 群聊烧爆额度，违背 B26）。框架帮你把循环跑起来，但"稳不稳、贵不贵、查不查得清"全靠这些外围工程。

7.2 一个常见反模式：用框架掩盖混乱

新手最容易犯的错，是把所有逻辑塞进框架的"节点/角色"里，导致流程图或角色定义膨胀成谁也看不懂的一团。好的做法是：框架只管"流转与编排"，业务判断（该调哪个工具、何时升级人工、怎么校验结果）抽到独立函数或配置里。这样换框架、改流程、加测试都不用动核心逻辑。框架是骨架不是垃圾桶，塞太多反而失去选框架的意义。

7.3 迁移成本别低估

三个框架的抽象差异很大，一旦深度绑定（比如大量 LangGraph 的条件边、AutoGen 的群聊钩子），中途换框架几乎等于重写。所以选型阶段要把"未来要不要持久化/人机/复杂分支"想清楚，优先选能覆盖演进需求的。如果预判会从简单 demo 长成复杂可控流程，一开始就用 LangGraph 比先 CrewAI 再迁移省事得多。这也是为什么选型决策树要往前多看两步，而不是只盯当下。

7.4 框架混用：什么时候该"拼"

真实项目里常常不是"单选一个"，而是"各取所长拼起来"。常见拼法：用 LangGraph 做主控图（负责持久化、人机、复杂分支），在其中一个节点里调用 AutoGen 的 GroupChat 去解"多专家对话"子任务，或调用一个 CrewAI 风格的角色分工模块去产初稿。关键是"主控用最可控的框架"，把自由度高但难控的子任务隔离在局部节点里，既享受多框架之长，又不让整条流程失控。面试能讲出"主控与子任务分层"的拼法，是很加分的工程成熟度。

7.5 别把框架当护城河

最后提醒一个认知误区：选了哪个框架不构成竞争优势，因为三者能力逐渐趋同、且都开源。真正的护城河在框架之外——你的提示词质量、工具设计、检索与知识库、评测体系、行业数据。框架只是让你更快把"聪明的 Agent"跑起来，跑起来之后比的是那些框架给不了的东西。把精力从"纠结框架"挪到"打磨效果与工程护栏"上，才是正路。

7.6 一个选型实战：客服 Agent 该怎么选

讲一个具体决策，把前面所有维度串起来。需求是"智能客服：先单 Agent 接用户，复杂问题升级多人协作，关键退款要走人工审批，且要能查每通对话的来龙去脉"。分析：流程有清晰分支（接诉→分类→升级→审批），需要持久化（对话跨多轮、可回看），需要人工节点（退款审批），需要可观测（每通对话溯源）——这几乎每个点都指向 LangGraph：显式图正好表达分支与审批边，checkpointer 原生解决持久化与回溯。AutoGen 的群聊在此过于自由、难控审批流；CrewAI 的持久化弱、难满足溯源审计。所以选 LangGraph 做主控，把"多专家会诊"这类自由子任务隔离在局部节点用 AutoGen 调用。这个决策过程（列出硬约束→逐框架对照→锁定主控）比直接报框架名值钱得多。

7.7 版本与生态风险

选框架还要算一笔"维护账"。这三个项目迭代都很快，大版本之间 API 经常不兼容，lock 死版本号、写好适配层、对升级做回归测试，是生产必需。另一个风险是"隐式依赖"：AutoGen 的群聊能自动跑代码，若没把代码执行关在沙箱里（呼应 B30 的安全），等于给 Agent 开了本地执行权限；LangGraph 的 checkpointer 接了 Postgres，就要管数据库连接与迁移。框架带来的便利，背后都对应着要你负责的运维面。面试时能说出"框架的便利与其隐含的运维责任是一体两面"，说明你不是只写过 demo，而是真运维过。

7.8 调试框架 Agent 的实操技巧

框架把流程封装起来后，调试反而容易"看不见内部"。几个实战技巧值得记：第一，把图的每个节点都接日志或 trace，LangGraph 可以直接打印 state 在每个节点的变化，一眼看出"卡在哪个条件边"；第二，善用 interrupt 打断点，在关键节点暂停检查 state 再决定是否继续，相当于给 Agent 下断点；第三，对单个节点做单元测试，把"调 LLM"的节点和"纯逻辑"的节点分开，纯逻辑节点（如 should_continue 判断）完全可以脱离 LLM 测；第四，AutoGen 群聊卡死时，先打印 messages 列表看是"谁在重复说废话"还是"没人接话"，再针对性加终止条件或换发言策略。会调试的人才算真会用框架——这也是面试区分"跑通过示例"和"能独立排障"的关键。

7.9 从框架退回手写的信号

框架不是永远正确解。当以下几条出现，说明框架可能成了包袱：一是你的图/角色已经复杂到"改一处要读懂全框架"，框架的抽象反而掩盖了业务逻辑；二是框架的某个默认行为（比如 AutoGen 自动执行代码、LangGraph 的固定调度）和你的安全/合规要求冲突，你花大量精力去对抗它；三是框架更新频繁、文档不稳定，团队大量时间耗在追版本；四是任务极简单且高度定制化，框架 80% 的能力用不上，反而增加依赖体积和出错面。这时候退回"薄薄一层手写循环 + 自己管理状态"，反而更清爽。判断框架去留的准绳只有一个：它是帮你聚焦业务，还是让你忙着伺候它。能在面试里讲出"框架也有适用边界、知道何时下车的工程师"，比只会安利框架的更有经验。

7.10 按团队画像选框架

选型还要看"谁在用"。如果团队是工程能力强、要做强可控复杂流程，LangGraph 的学习曲线值得投入，它的图抽象能和工程师心智对齐；如果团队偏研究、想快速验证"多专家能不能解这类题"，AutoGen 的低门槛群聊更友好；如果团队有业务/产品同学参与、希望用"角色化"方式直观搭建，CrewAI 的可读性是加分项。反过来，让一个只写过脚本的初级团队硬上 LangGraph，容易陷入"图都画不对"的内耗；让研究导向的团队去抠 CrewAI 的细控，又觉得束手束脚。框架没有绝对优劣，只有"和团队能力、任务形态、演进预期"的匹配度。把这个匹配逻辑讲清楚，比背一通框架特性更显资深。

7.11 框架与 LLMOps 的衔接

选框架时还要想一层：它能不能无缝接进你的 LLMOps 体系。生产 Agent 离不开评估（B11/B19）和可观测（B20），如果框架把每一步 LLM 调用、工具结果都按标准格式吐出来，你就能直接喂给评测流水线和 trace 平台，否则就得自己写适配器，费力且易错。LangGraph 因为 state 显式、节点清晰，天然好接 OTel 和自定义评估；AutoGen 的群聊消息流也能接，但要自己规整发言结构；CrewAI 相对封闭，深度可观测要额外钩子。所以"框架是否好观测、好评估"应作为选型的硬指标之一，而不是上线后才补的课后作业。能提前把"框架—评估—监控"当成一条链路来选型的工程师，项目起步就少踩一半坑。说到底，框架是手段不是目的，把 Agent 稳稳跑在生产和可观测体系里，才是选型时真正该盯着的那条主线。

7.12 一个选型速记口诀

为了方便记忆和面试复述，可以记一句口诀："要控流程选图（LangGraph），要群聊求解选会（AutoGen），要快速组队选角（CrewAI）。"它把三个框架的抽象浓缩成三个字：图、会、角。但口诀只是入口，真正的功力在于能展开讲清每个字背后的代价——图意味着要学状态机、会意味着要管终止、角意味着要补持久化。面试官听到你先抛口诀、再拆代价，会立刻觉得你是"用过且想过"的人，而不是"背过特性列表"的人。这种"先给框架、再填血肉"的回答结构，本身也是一种高级的沟通技巧。它能让面试官在三秒内抓住你的选型逻辑，再用后续展开证明你不是只会背口诀，印象分立刻拉开。真正的高手，从不纠结"哪个框架最好"，而只关心"哪个框架最贴合眼前的约束与未来半年的演进"。

八、框架与 Agent 的可测试性

8.1 为什么 Agent 特别难测

Agent 是非确定性系统：同一输入，LLM 这次和下次可能走不同路径，工具也可能返回不同结果。若测试只断言"最终输出等于某字符串"，会极度脆弱、动不动红。正确做法是分层：节点函数（call_model、call_tool）做成纯函数用单测覆盖；整图用集成测试覆盖"主路径能否走通、异常路径能否兜底"；提示词变更用回归测试（固定一批样本跑前后对比质量分）。

8.2 用 mock 隔离外部依赖

测试时把 LLM、工具、外部 API 全部 mock：用桩 LLM 返回固定决策，用假工具返回预设结果，毫秒级、零成本下反复验证流程编排。框架的图抽象在此显优势——节点是独立函数，天然可替换、可单测。会讲"怎么给 Agent 写测试"，是区分"能跑 demo"和"能上生产"的分水岭，也是面试里常被忽略的高分点。

---

九、面试速答 + 高频追问清单

面试速答（一句话版）：
- 框架解决状态/持久化/人机/可观测等工程脏活，不是替代 Agent 核心逻辑。
- LangGraph 抽象是"图"，流程可控、checkpointer 原生支持持久化与回溯。
- AutoGen 抽象是"群聊"，多 Agent 对话求解强，但流程可控性弱、要设终止条件。
- CrewAI 抽象是"角色团队"，上手快可读性强，细控和持久化弱。
- 选型看"要不要精确控制流程 + 要不要持久化/人机"，否则框架只是换个地方写 bug。

高频追问清单：
1. 三个框架的核心抽象分别是什么？各自最擅长什么场景？
2. LangGraph 的 checkpointer 解决了什么？怎么实现断点续跑和时间旅行？
3. AutoGen 的 GroupChat 怎么决定下一步谁发言？为什么必须设 max_round？
4. conditional edge 在 LangGraph 里对应 ReAct 的哪一步？
5. CrewAI 的 Process 有哪两种？层级式适合什么？
6. 什么场景你会坚持手写而不用框架？什么场景框架是必选项？
7. 用框架后还需要自己补哪些东西（持久化/人机/可观测/成本）？
8. 多 Agent 群聊容易陷入"互相捧场空转"，怎么防？
9. 怎么给框架接可观测（OTel/GenAI trace）？为什么重要？
10. 让你从零设计一个"带人工审批的代码评审 Agent"，你会选哪个框架、为什么？