Agent 框架选型

1. 主流 Agent 框架有哪些，各自的定位是什么？
1. LangGraph 是 LangChain 系的状态图编排框架，把智能体流程建模成带状态的有向图，适合精细控制流程的团队。
2. AutoGen 是微软的多智能体对话框架，主打多个 Agent 通过对话协作，群聊和辩论模式开箱即用。
3. CrewAI 走角色扮演路线，给每个 Agent 定角色、目标和背景故事，像搭一个虚拟项目组。
4. OpenAI Agents SDK 官方出品，轻量主打 Handoffs 和原生工具调用，绑定其模型生态但集成顺畅。
5. Dify、Coze 这类低代码平台面向非深度开发者，拖拽式搭智能体，重在快速上线和运营。
6. 还有 Semantic Kernel 这类企业系框架，和微软技术栈、成熟运维体系结合紧密。
7. 面试答法建议按"代码灵活性从高到低"排序记忆，面试官追问哪款都能顺着这条线展开。

2. 什么情况下不用框架、直接裸写更好？
1. 任务单一明确、就是几轮工具调用的场景，两三百行裸代码比引入框架全家桶更干净。
2. 团队对框架抽象没有掌控力时，裸写的学习成本反而是最低的，出了问题每一行都是自己的。
3. 对延迟和成本敏感的核心链路，框架的多层封装会带来额外开销和不透明性，裸写可控性更强。
4. 需要深度定制执行循环、特殊停止逻辑或非标准编排的场景，框架的约束会变成枷锁。
5. 长期演进的大项目也要掂量，框架大版本一升级，迁移成本可能远超当初省下的开发时间。
6. 裸写不等于从零造轮子，模型 SDK、工具调用协议、观测组件该用还是要用，只是不套编排框架。
7. 面试加分点：给出务实结论，框架的价值在多角色协作和流程编排，单智能体简单链路裸写是更好的默认选择。

3. LangGraph 和 AutoGen 的设计思路差在哪？
1. LangGraph 的核心抽象是状态加图，节点是函数或智能体，边定义流转，全局状态显式声明、显式更新。
2. AutoGen 的核心抽象是对话，智能体之间发消息推进任务，状态藏在对话历史里，靠对话协议维持秩序。
3. 控制流上 LangGraph 显式得多，条件边、循环、检查点都是图定义的一部分，可预测性强。
4. AutoGen 更灵活自由，适合探索性协作，但行为更难预测，调试要翻对话记录。
5. 工程化能力上 LangGraph 带断点恢复、时间旅行调试、人工审批节点，生产配套更成体系。
6. 选型建议：流程清晰要严控就用 LangGraph，角色协作以对话为主就试 AutoGen。
7. 面试加分点：点出本质差异是"状态为中心"还是"对话为中心"，两种世界观决定了各自的适用边界。

4. CrewAI 这类角色扮演式框架适合什么场景？
1. 角色扮演式的最大优点是建模直觉，把业务里的分工直接映射成角色，产品和业务人员也能看懂。
2. 适合内容生产类流水线，比如调研员写素材、写手成文、审校把关，角色链路和业务流程天然对齐。
3. 适合作为多智能体的入门教学和原型验证，几个角色一配就能看到协作效果。
4. 局限之一是流程控制偏弱，复杂条件分支和精确编排不如图式框架，深度定制会别扭。
5. 局限之二是角色设定容易流于形式，写了一堆人设模型未必真按人设干活，效果要靠工具和提示词兜底。
6. 局限之三是规模上去后角色之间依赖关系难管理，容易变成一锅对话粥。
7. 面试收尾观点：角色扮演框架适合"任务像项目组协作"的场景，任务本身是确定性流程时就别硬套人设。

5. 低代码平台和代码框架怎么选？
1. 低代码平台的强项是快，从想法到可用原型可能就半天，运营人员自己就能改流程和提示词。
2. 平台把部署、托管、日志、发布都包了，小团队省掉一整套基础设施投入。
3. 代价是灵活性天花板明显，特殊执行循环、私有协议对接、深度定制基本做不了。
4. 数据合规是硬考量，平台版数据要过第三方，强合规行业往往只剩私有化一条路。
5. 代码框架换来的是完全掌控，性能、成本、安全、集成全部自己说了算，代价是团队要养工程能力。
6. 实践中常见混合策略，用平台做原型验证和运营侧轻应用，跑通了的场景再迁到代码框架精耕。
7. 面试收尾判断式：看两件事，需求会不会长出框架表达不了的复杂度，数据能不能出本地，答案决定了选哪边。

6. 官方 SDK 类框架有什么优势和风险？
1. 优势是集成顺滑，和自家模型的工具调用、结构化输出、推理特性是原生配合，坑最少。
2. 文档和示例跟模型版本同步更新，新能力第一天就能用，这是第三方框架追不上的时效。
3. 抽象层通常更薄，学习曲线平缓，排查问题时链路短、干扰少。
4. 风险是厂商锁定，核心抽象绑定单一模型生态，换模型供应商时迁移成本可能不小。
5. 生态宽度也受限，多模型路由、异构模型协作这类需求，官方 SDK 通常不是主战场。
6. 务实做法是核心业务逻辑写成框架无关的模块，SDK 只做薄薄的接入层，锁定风险就可控。
7. 面试加分点：能结合 Handoffs、原生工具等特性说明官方 SDK 在单模型场景的性价比确实高。

7. 框架的抽象泄漏指什么，怎么应对？
1. 抽象泄漏是指框架承诺帮你屏蔽细节，但关键时刻细节穿透抽象层直接咬你，比如隐藏的重试悄悄烧钱。
2. 典型症状包括莫名其妙的多余调用、框架偷偷注入的提示词改变模型行为、错误信息被包装得看不出根因。
3. 根因是智能体行为的决定权在提示词、上下文和模型参数这些细节上，任何封装都不可能完全不碰它们。
4. 应对第一招是知内情，读框架源码或调试日志，搞清它实际发给模型的完整提示词长什么样。
5. 第二招是留逃生口，框架一般都支持绕过封装直接传原始参数，关键链路要敢用。
6. 第三招是建对照实验，怀疑框架行为异常时，用裸写版本跑同样任务对比，一比就现形。
7. 面试观点收尾：抽象泄漏无法根除只能管理，选框架时把"可观测、可绕过"当成和功能列表同级的硬指标。

8. 框架绑定风险有多大，怎么留后路？
1. 绑定风险分三层，代码层是 API 换名字，数据层是状态和轨迹格式私有，思维层是团队只会用框架不会造。
2. 最贵的是思维层绑定，团队离开框架就不会写执行循环，这才叫真的下不来船。
3. 防御的核心手法是六边形架构，把模型调用、工具执行、状态存储都抽象成自有接口，框架只当编排壳。
4. 提示词、工具定义、评测集这些核心资产放在框架外自管，它们才是智能体的灵魂不是框架。
5. 迁移演练要定期做，每年挑个非核心服务实际迁一次，检验抽象层的成色，别等被迫迁移才发现裸奔。
6. 关注框架的健康度再决定投入深度，维护活跃度、版本节奏、社区规模都是绑定风险的变量。
7. 面试收尾观点：不反对用框架，反对的是无意识绑定，用不用都该是评估后的主动选择。

9. 评估一个 Agent 框架该看哪些维度？
1. 第一维度是控制力，执行循环、上下文管理、停止条件能不能精细控制，还是只能接受框架的默认行为。
2. 第二维度是可观测性，轨迹、token 消耗、工具调用是否一等公民地暴露，调试体验好不好。
3. 第三维度是状态管理，长任务的中断恢复、检查点、持久化是否内置，这决定生产可用性下限。
4. 第四维度是生态兼容，模型支持广度、工具协议支持比如 MCP、和现有观测告警体系的对接成本。
5. 第五维度是团队匹配，学习曲线、文档质量、招聘市场上会不会找对人，比功能列表更决定成败。
6. 第六维度是演进活力，看更新节奏和 breaking change 频率，太慢的养老太快的心累。
7. 面试加分点：建议做两周左右的 Eat your own dog food 试点，拿真实小需求走一遍全流程，比看任何测评文章都准。

10. 从一个框架迁移到另一个框架，成本有多大？
1. 成本大头通常不是重写编排代码，而是迁移提示词资产、评测基线和踩坑经验这些隐性积累。
2. 行为等价是最难的验收标准，同一个任务新框架跑出来的轨迹风格不同，要逐类任务对齐效果。
3. 状态数据要写迁移脚本，历史任务、检查点、记忆数据格式私有，搬不干净就丢历史。
4. 周边配套全部重来，观测埋点、告警阈值、成本核算逻辑都要在新框架上重新校准。
5. 合理估算是一人月到数人月起步，复杂多智能体系统翻倍，面试敢给量级说明真做过。
6. 降成本的姿势是当初就留了抽象层，编排层薄到接近可替换，迁移就是换个壳。
7. 面试收尾建议：迁移前先问动机，如果只是追新，收益大概率盖不住成本；如果是硬伤不迁移会死，那就尽早动。

11. 团队该押注一个框架还是多框架并行？
1. 小团队默认押注一个，精力集中、经验复利、基础设施只养一套，这是大多数团队的最优解。
2. 押注对象优先选团队学得最快、社区最活跃的，而不是功能最炫的，工具是拿来干活的。
3. 中大团队可以有主次分工，一条主线框架加一个探索位，新框架进探索位试点再决定是否升级。
4. 并行多框架的隐性成本常被低估，运维、监控、招聘、经验沉淀全部乘以框架数，别轻率开多个头。
5. 无论押注谁，核心资产框架无关化都是前提，提示词、评测集、工具层自持，进退才自由。
6. 框架决策要定期复盘，半年一年回头看一次，框架格局变化很快，去年对的今年未必对。
7. 面试收尾观点：框架是快消品，能力是固定资产，团队真正该押注的是智能体工程的通用能力，框架只是租车。

包含的内容比较多，这里只做了简单的截图介绍，需要拿来学习的小伙伴查看下方图片！

📚 大模型面试题系列 · 持续更新

INTRO_REMOVED

长按识别二维码，添加微信好友

获取完整版面试题合集，注明 「面试」 通过好友申请