番外 3：框架选型决策——真实生产团队到底怎么选

这是「Agent 工程化」系列的番外篇。番外 1 横评了四大框架路线，番外 2 拆解了 LangGraph 的原理。这篇回答最难的问题：选型。 起因很真实——很多同学在面试时被问"为什么自研不用开源框架"，也有人被面试官点"不提倡重复造轮子"。同一个问题，两种声音，到底听谁的？这篇用真实生产团队的选择，给你一套不站队的决策方法。

---

两个声音，其实是同一道题

先还原两种真实场景：

美团面试题（面经高频）：为什么有时候选择"手搓" Agent，而不是直接用成熟框架？

小红书面试官建议：工程上大家还是不要重复造轮子，开源好的直接拿来用/基于改。

一面是"为什么自研"，一面是"别自研"——听起来矛盾，但本质是同一道题的两面：你对自己的场景和框架的能力边界，有没有做过真正的评估？ 面试官不是要一个"自研/复用"的站队答案，要的是你的决策逻辑。

先把事实摆清楚：真实的大厂生产团队，是怎么选的？

---

事实：真实生产团队在用框架，也有人在自研

用框架的（数据来自 2026 年公开案例）

公司	做了什么	规模/成果
Klarna（瑞典金融科技）	客服 AI Agent	服务 8500 万活跃用户，问题解决时间降 80%
Uber	Lang Effect 开发者工具	5000 名工程师用，自动化测试生成，节省约 2.1 万开发小时
LinkedIn	分层 AI 招聘 Agent + 企业 SQL Bot	企业内部数据自然语言查询
Replit	编程 Copilot	数百万开发者使用
Elastic	实时威胁检测流水线	安全场景

Klarna 的客服 Agent 很值得看：为什么 8500 万用户的客服必须用框架？ 公开资料显示它的架构是一张图——验证用户 → 查数据 → 查内部政策 → 路由到人工客服 → 更新状态。每一步都要状态持久化（用户聊到一半断线要能恢复）、可审计（金融行业合规要求）、人工升级（搞不定要转人工）。这三个要求，恰恰是 LangGraph 的核心能力：checkpoint、audit、human-in-the-loop。

自研的（比如你的实习项目）

诊断场景的 Agent：边界问题多、流程要灵活、规模小（几十个工具），自研一个轻量编排层 100 行能控住，框架反而重。

注意：这两类选择都不错。 Klarna 用框架是对的，你自研也是对的——因为需求和能力不同。选型不是"谁对谁错"，是"匹配不匹配"。

---

一个关键数据点：为什么框架反而更省心

LangChain 2026 年发布的 Agent 工程报告有个扎心数据：60% 以上的生产 Agent 事故，根源是状态管理失败——Agent 中途丢失上下文、重复执行步骤、崩溃后无法恢复。

这个数据说明两件事：

1. 生产 Agent 最大的坑不在"模型不够聪明"，在工程状态管理
2. 框架（尤其 LangGraph）存在的意义就是专门解决这件事

所以"复用框架"不是怕麻烦，是把最高发的坑外包给成熟方案。这也解释了为什么大厂普遍倾向复用——他们经历过自研踩坑的成本。

---

但框架不是免费的，三个隐性成本

理性对比的另一面，框架也有代价：

代价	说明
学习与排障成本	出 bug 要分"图逻辑错了还是框架内部错了"，抽象层越厚越难查
性能和存储陷阱	LangGraph 生产必须配 PostgresSaver；SqliteSaver 在高并发写入下是性能陷阱
框架不解决准确性问题	LangGraph 管"Agent 做什么"，不管"Agent 做对没有"——评测、护栏还得自己上

还有一点容易被忽略：框架选型几乎不影响你的账单，模型选型才影响。 多步 Agent 的 token 消耗是单次对话的 10-100 倍，省成本靠的是路由（简单步骤用小模型、硬推理用大模型），不是选哪个框架。别把选型当成省钱手段。

---

决策四问：不站队的选型方法

真正专业的选型，是回答下面四个问题：

问题一：核心差异化在哪？

• 你的 Agent 90% 的价值来自"流程可控+可审计"→ 复用框架（这些是框架的强项）
• 你的 Agent 价值来自对特定业务的深度定制（如诊断逻辑、领域规则）→ 核心逻辑自研，外围用框架

问题二：场景和框架的"默认模型"匹配吗？

框架都有自己的思维模型：LangGraph 是图（state + 节点 + 边）、CrewAI 是角色（role + task）、AutoGen 是对话。

• 你的场景天然是"固定流程 + 状态流转"→ LangGraph 匹配
• 你的场景是"多角色分工协作"→ CrewAI 匹配
• 你的场景是"边界模糊、流程多变"（如诊断）→ 框架默认模型可能反而束缚你 → 自研更合适

问题三：团队规模养得起自研吗？

• 自研 = 你要自己负责状态管理、可观测、人工审批、持续迭代——每一笔都是团队人天
• 1-2 人做内部工具 → 自研可控
• 多人、长期、面向外部用户 → 复用的隐性收益（生态、文档、社区踩坑）远超想象

问题四：留了迁移路径吗？

这是最重要的一个问题，也是面试官最想听的。 自研不丢人，丢人的是自研到一半发现走不通、又没有退路。

---

面试正确姿势：三句话话术

被问"为什么自研不用开源框架"时，标准答法不是辩解，是展示决策过程：

1. 我们评估过：对比过 LangGraph 等主流框架，看过它们的状态管理、可观测生态
2. 当前规模匹配：我们的场景边界问题多、流程多变，自研编排层 100 行可控；团队 1-2 人，自研成本可承受
3. 留了迁移路径：核心逻辑与框架解耦，一旦团队规模上来、或需求标准化，可以直接迁到开源框架

这三句话的内核是：评估过、规模匹配、留路径。 面试官听到的不是"我自研很牛"，而是"这个人做选型是有方法论的"——这正是他们真正考察的东西。

---

避坑：三个真实教训

教训一：别把选型当省钱手段

框架选型几乎不影响账单，模型路由才影响。为了"省框架费"自研，可能反而多烧几倍 token。

教训二：别忽视状态管理这个"隐形坑"

60% 的生产事故来自状态管理失败。自研的话，这 60% 的坑得自己踩一遍；复用框架是把它外包出去。选型时要给"状态管理"足够权重，别只盯着功能对比。

教训三：自研要写清楚"为什么"，否则就是真造轮子

“重复造轮子"的定义不是"自研”，而是**“没评估过就自研”**。评估过、有理由、留了路径，就是合理选择；什么都没想就开始造，才是面试官说的"重复造轮子"。

---

小结

• 大厂用框架也自研，都对：Klarna 用 LangGraph 服务 8500 万用户，你的诊断场景自研 100 行——匹配才是关键
• 60% 事故来自状态管理：这是"复用框架"最强论据，也是自研者要自己扛的坑
• 框架有隐性成本：学习排障、存储陷阱、不解决准确性；框架选型不影响账单，模型选型才影响
• 决策四问：差异化、默认模型、团队规模、迁移路径
• 面试三句话：评估过、规模匹配、留路径

下一篇进入深度篇：面经里高频出现的 Reflection 反思机制——“Agent 做错了能自己改吗”？这可能是你系列里最贴近面试实战的一篇。

---

本系列路线（从 0 到 1）： Agent 是什么 → 手写最小 ReAct → Function Calling 与工具设计 → 上下文管理 → Memory 记忆系统 → RAG 知识库 → Skill 自学习 → 编排模式与多 Agent → 给 Agent 装护栏 → 生产部署与可观测 → 评测与回归 → 番外：框架横评 → LangGraph 深挖 → 框架选型决策