AI 产品经理如何区分 Agent、RAG 和 Function Calling，并判断它们适合哪些产品场景？｜百度产品面经解析

60 秒回答模板

我会先把三者按“解决什么产品问题”区分。RAG 是检索增强生成，核心是让模型在回答前先从外部知识库、文档、网页或业务数据里取证据，再基于证据回答，适合知识问答、客服、规章制度查询、文档助手、投研或售前资料问答这类对事实新鲜度和可追溯性要求高的场景。Function Calling 是让模型把自然语言意图转成结构化函数参数，调用搜索、下单、查库存、发消息、建日程、查数据库等确定性工具，适合“需要执行动作或读取系统状态”的场景。Agent 则是在目标比较复杂时，让模型具备规划、工具选择、执行、观察结果和迭代修正的能力，适合多步骤任务，例如自动整理资料、生成报告、跨系统办事、数据分析和运营流程辅助。产品经理不能把它们当成互斥选项：很多产品会用 RAG 提供知识，用 Function Calling 调工具，用 Agent 组织多步流程。判断是否适合，要看任务复杂度、容错空间、动作风险、用户是否需要控制、数据权限、延迟成本和可观测性。简单问答优先 RAG，单步确定动作优先 Function Calling，多步骤开放目标才考虑 Agent，并且要设计确认、回滚、审计和失败兜底。

考点 RAG

难度 真实面经题

回答目标 让候选人能用产品语言区分三类能力：RAG 解决可信知识，Function Calling 连接确定工具，Agent 编排多步任务，并能根据场景风险和指标做取舍。

深入解析

先按产品问题而不是技术名词分类

RAG、Function Calling 和 Agent 都围绕大模型能力扩展，但产品价值不同。RAG 让模型回答时有外部依据，降低知识过期和无依据编造的风险；Function Calling 让模型从“会说”变成“能调系统”；Agent 让模型围绕目标做计划、选择工具、执行和反思。面试回答的关键不是背定义，而是说明它们分别改变了信息来源、动作能力和任务组织方式。

RAG 适合知识密集型问答

RAG 的典型链路是理解问题、检索相关材料、筛选或重排证据、把证据放入上下文、生成带依据的回答。它适合答案依赖私有知识、长文档、政策规则、产品手册、FAQ、合同条款或最新资料的场景。产品取舍在于召回质量、证据覆盖、引用展示、权限隔离和答案可追溯，而不是只看模型语言是否流畅。

Function Calling 适合确定性系统动作

Function Calling 的重点是把用户意图解析成可校验的函数名和参数，再由外部系统执行。它适合查订单、查库存、发通知、创建工单、调用计算器、写入 CRM、订会议或拉取实时数据。它的价值是把自然语言入口接到业务系统，但必须处理参数缺失、权限校验、二次确认、幂等、错误提示和工具返回结果解释。

Agent 适合多步骤开放目标

Agent 面向的是用户只给目标、不指定每一步操作的任务。它需要拆解计划，选择 RAG 或工具，观察执行结果，必要时调整路线。适合资料搜集、竞品分析、报表生成、跨系统流程办理、复杂客服工单初筛等任务。风险也更高：步骤越多，错误累积、成本、延迟和不可控动作越明显，所以需要可视化计划、阶段确认、操作审计和人工接管。

三者经常组合而不是三选一

一个成熟 AI 产品可能同时使用三者：先用 RAG 找到知识依据，再用 Function Calling 查询系统状态或执行动作，最后由 Agent 管理多轮计划和状态。产品经理要能判断最小可行方案。只需要回答制度问题时，先做高质量 RAG；只需要一句话创建日程时，Function Calling 已足够；只有任务跨多个步骤、需要动态决策时，才把 Agent 作为主形态。

场景判断要落到风险和指标

选型时要看任务复杂度、事实依赖、动作风险、失败代价、用户控制需求、权限边界、延迟预算和成本预算。RAG 重点看召回率、引用命中、答案准确率和用户采纳；Function Calling 重点看参数正确率、调用成功率、动作完成率和失败恢复；Agent 重点看端到端任务完成率、步骤可解释性、人工接管率、成本和安全事故率。

易错点

把 Agent、RAG、Function Calling 当成三个并列卖点，只背定义，不说明分别解决信息、动作和流程问题。
认为上了 RAG 就不会出错，忽略检索质量、证据冲突、权限隔离和生成阶段误读。
把 Function Calling 说成模型自己执行真实动作，忽略外部系统、参数校验、权限控制和二次确认。
把所有 AI 助手都包装成 Agent，导致简单场景复杂化，增加延迟、成本和失败面。
只讲技术链路，不讲产品指标，例如任务完成率、调用成功率、引用命中率、人工接管率和用户采纳率。
忽略动作风险，把只读查询、低风险草稿和高风险写入操作用同一套确认策略处理。

面试官追问

什么时候不应该上 Agent？

当任务可以用一次问答或一次确定工具调用完成时，不应该为了概念先进而上 Agent。Agent 会增加步骤、延迟、成本和不可控风险，只有多步骤目标、路径不确定、需要动态决策时才有明显价值。

RAG 能完全解决大模型幻觉吗？

不能。RAG 只能提高答案有依据的概率，仍可能出现检索不到、检索错、证据冲突、模型误读证据或过度发挥。产品上要做证据引用、置信度提示、拒答策略和用户反馈闭环。

Function Calling 和传统 API 调用有什么区别？

传统 API 调用通常由程序逻辑决定何时调用和传什么参数；Function Calling 让模型参与意图识别、工具选择和参数填充。它降低自然语言入口成本，但必须用 schema、校验、权限和确认机制约束。

如何为 Agent 设计用户控制感？

可以展示计划、标出当前步骤、区分只读和写入动作、高风险操作前二次确认、允许暂停和回滚、保留执行日志，并在失败时给出可理解的恢复选项。

面向企业知识库，先做 RAG 还是 Agent？

通常先把 RAG 的知识接入、权限、引用和准确率做好，因为这是知识问答的基础能力。等用户需要跨文档整理、自动生成报告或联动业务系统时，再引入工具调用和 Agent 流程。