主流 Agent 框架如何选型，如何按 RAG 检索、有状态工作流、多 Agent 协作、工具/记忆/检索能力和自主性与可控性边界做取舍？｜阿里巴巴 AI 应用开发面经解析

60 秒回答模板

我不会先问哪个框架最火，而会先判断这个 Agent 项目的核心矛盾是什么。如果主要是知识库问答、文档检索、chunk、embedding、rerank、引用和检索评估，LlamaIndex 或 LangChain 的 RAG 组件更合适，重点是数据连接器、索引、召回、rerank 和 evaluation。如果主要是多步骤、有状态、可恢复的任务，比如审批、下单、代码修复、客服工单流转，LangGraph 这类状态图更合适，因为它能显式表达节点、边、state、重试和中断。如果主要是多角色协作、辩论、规划执行分工或代码 Agent 实验，AutoGen 这类多 Agent 编排更方便，但生产里要警惕成本、循环、不可控和难评估。框架还要看工具、记忆、检索和模型调用的抽象是否清晰：工具要有 schema、权限和错误码，记忆要区分短期上下文、长期用户偏好和任务状态，检索要有可评估的召回与引用。选型维度包括自主性和可控性的平衡、工具调用可靠性、状态持久化、可观测性、测试回放、权限安全、延迟成本、团队熟悉度和迁移成本。生产建议是从最小框架开始：RAG 用专门检索层，流程用显式工作流，模型接入用薄适配层，多 Agent 只在确有复杂协作收益时引入。

考点 按任务分类

难度 真实面经题

回答目标 让候选人展示 Agent 框架选型的工程判断：按问题边界选最小可控方案，在自主性、可控性、检索质量、协作复杂度和生产治理之间做取舍。

深入解析

先按问题类型选框架

Agent 框架没有绝对最优，只有问题匹配度。知识密集型问答、自动化任务流、多 Agent 研究协作、工具调用治理和记忆管理，是几类不同问题。选型时先识别主要风险：是检索质量不够、状态不可控、工具调用失败、多角色发散，还是上线后的权限、观测和评测治理困难。

RAG 边界看检索和数据治理

RAG 场景的核心不是 Agent 自主性，而是数据接入、切分、embedding、混合召回、rerank、引用、权限过滤、增量更新和检索评估。LlamaIndex 通常更偏数据索引和检索管线，LangChain 也有丰富组件。此类项目应优先把 retrieval quality、citation faithfulness 和权限隔离做好，再考虑是否需要复杂 Agent。

有状态工作流看可控性

当任务有多步骤、分支、重试、人工确认、外部副作用和恢复需求时，状态图或工作流框架更合适。LangGraph 的价值在于把节点、边和 state 显式化，便于回放、测试和观测。生产系统通常更需要可控状态机，而不是让模型每轮自由决定下一步。

多 Agent 协作要控制发散

AutoGen 等多 Agent 框架适合探索多角色讨论、代码生成评审、规划执行拆分和模拟协作。但多 Agent 会带来 token 成本、循环、责任边界不清和结果难评估。生产使用时要限制角色数量、轮次、终止条件、工具权限和最终裁决机制，不应把多 Agent 当作默认架构。

工具、记忆和检索要拆清边界

面试官提到模型、工具、记忆和检索，核心是在问抽象边界。工具层要有稳定 schema、权限、幂等、错误码和结果校验；记忆层要区分会话上下文、长期偏好、任务状态和外部事实，不应把所有历史直接塞回 prompt；检索层要保留索引、召回、rerank、引用和权限过滤的独立评估。边界清楚，框架替换和问题定位才可控。

自主性和可控性是最终权衡

Agent 越自由，越能覆盖开放任务，但也越难保证成本、时延、权限和结果一致性。生产系统要按风险分层：读操作和探索任务可以给更多自主规划空间；写操作、交易、客服承诺和用户数据相关链路要用显式流程、人工确认、工具白名单、步骤预算和终止条件，把模型决策限制在可审计边界内。

生产约束决定最终架构

生产选型要看状态持久化、权限、安全、审计、trace、评测、回放、灰度、成本、延迟、团队维护能力和故障恢复。框架 demo 跑通不等于可上线。越靠近交易、写操作、客服承诺和用户数据，越要偏向显式流程、强观测和可回滚，而不是追求 Agent 自主性。

易错点

只罗列 LangChain、LangGraph、AutoGen、LlamaIndex 等名字，不说明各自边界。
把 RAG 问题做成复杂 Agent，忽略检索质量、引用可信和权限过滤才是核心。
生产场景过度追求自主性，没有状态、回放、权限、成本和失败恢复设计。
把多 Agent 当作默认高级方案，忽视循环、延迟、成本和评估困难。
把工具、记忆和检索都塞进 prompt，不设计 schema、状态边界和独立评估。
只看 demo 能跑通，不检查 trace、回放、权限、安全、灰度和故障恢复。

面试官追问

什么时候不应该引入 Agent 框架？

如果任务是单轮问答、固定流程调用、简单分类抽取或直接模型 API 能解决，引入框架可能增加复杂度。先用薄模型接入层、清晰 prompt、少量工具和普通服务编排，等出现状态、恢复和多工具治理需求再加框架。

LangChain 和 LangGraph 怎么取舍？

LangChain 更适合作为组件集合和链式调用工具箱，LangGraph 更适合需要显式状态机、条件边、循环控制和恢复的 Agent 工作流。若生产里有多步骤和可观测要求，通常要从图和 state 的角度设计。

LlamaIndex 更适合什么场景？

它更适合数据和索引中心的 RAG 场景，例如文档加载、切分、索引、查询、引用和检索评估。若核心难点是知识库质量和检索效果，而不是自主规划，优先考虑这类检索框架。

多 Agent 为什么不应默认用于生产？

多 Agent 会增加 token 成本、延迟、循环概率和归因难度。除非问题确实需要多角色分工、互审或并行探索，否则单 Agent 加显式工作流和评测更容易控制。

工具、记忆和检索能力都需要时，框架边界怎么处理？

不要把所有能力混成一个大链路。工具调用保持 schema、权限和错误恢复；记忆按短期上下文、长期偏好和任务状态拆分；检索保留独立索引、召回、rerank、引用和评估。框架只负责编排，核心数据、trace、评测集和工具契约要掌握在业务系统里。