AI产品经理面试八股

01 AI Agent 基础概念​

什么是 AI Agent​

1.1 概念解释（通俗易懂，带类比）​

AI Agent（智能体）可以类比为：一位能上网、能记笔记、会拆任务的「数字员工」。​

它不只「接一句话、回一段话」，而是能在多步任务里自己决定下一步做什么：先想清楚计划，再查资料、调工具，把中间结果记下来，最后汇总成答案。​

业界常用一句概括：​

​

Agent ≈ LLM + Planning（规划）+ Memory（记忆）+ Tools（工具）​

​

•

LLM：大脑，负责理解、推理、生成自然语言与结构化计划。​

•

Planning：把模糊目标拆成可执行步骤，并在执行中动态调整。​

•

Memory：短期上下文 + 长期知识，避免「说完就忘」或重复劳动。​

•

Tools：手脚，如搜索、数据库、代码执行、API 调用等。​

1.2 原理详解（技术细节）​

与「普通 LLM 单次调用」的区别​

◦

普通调用：输入 Prompt → 模型输出文本，没有与外部环境闭环。​

◦

Agent：输出往往是 「下一步动作」（例如：调用某工具、更新记忆、结束），环境返回 Observation（观察结果），再进入下一轮推理，形成 多轮控制循环。​

自主决策能力体现在哪里​

◦

在动作空间中选下一步（选哪个工具、传什么参数、是否结束）。​

◦

在信息不完整时决定先澄清还是先假设再验证。​

◦

在失败时重试、换策略或请求人工介入（视系统设计而定）。​

核心循环（典型 ReAct / Tool-use 范式）​

抽象为：Thought（推理）→ Action（行动）→ Observation（观察）→ … → Final Answer。​

实现上常由「编排层（Orchestrator）」驱动：解析模型输出、执行工具、把结果写回上下文，直到满足停止条件。​

1.3 面试问题（Q）与标准答案（A）​

Q1：一句话说明什么是 AI Agent？​

A： AI Agent 是以大模型为认知核心，结合规划、记忆与工具调用，能在多步交互中根据环境反馈持续决策并完成任务的系统；其本质是 闭环的感知—思考—行动 循环，而不仅是单次文本生成。​

Q2：为什么说 Agent = LLM + Planning + Memory + Tools？缺一块会怎样？​

A：​

•

缺 Planning：容易变成「只会接话」的聊天，长任务易跑偏或一步登天完不成。​

•

缺 Memory：长对话会丢线索，多会话无法延续用户偏好与任务状态。​

•

缺 Tools：只能「空谈」，无法查实时信息、执行代码、改系统状态。​

•

LLM 仍是中枢，但单靠 LLM 没有外环则不是完整 Agent。​

1.4 可能的追问及应对​

•

追问：Agent 的「自主」是不是不受控？​

应对： 强调 策略与护栏：工具白名单、参数校验、人在回路（HITL）、预算与步数上限、输出审核；自主是在约束空间内的决策。​

•

追问：和 AutoGPT 那种有什么区别？​

应对： AutoGPT 是早期「目标导向 + 工具」的一种产品形态；面试应抽象到 循环架构与组件（规划/记忆/工具），避免绑定单一产品名。​

1.5 代码示例：最小「思考—行动—观察」循环（Python 伪代码）​

​

代码块​

Python

def run_agent(user_goal: str, tools: dict, llm, max_steps: int = 8):​

messages = [{"role": "system", "content": "你是可调用工具的 Agent。"},​

{"role": "user", "content": user_goal}]​

for _ in range(max_steps):​

plan = llm.chat(messages) # 模型决定：结束 or 调用某工具​

action = parse_tool_call(plan) # 从模型输出解析结构化动作​

if action.name == "finish":​

return action.args["answer"]​

obs = tools[action.name](**action.args)​

messages.append({"role": "assistant", "content": plan})​

messages.append({"role": "user", "content": f"工具结果：{obs}"})​

​

Agent vs LLM Chain vs ChatBot​

2.1 概念解释（通俗易懂，带类比）​

•

ChatBot（聊天机器人）：像 前台接待——以对话为主，核心是「接话与回复」，通常不强调多步任务闭环与工具编排。​

•

LLM Chain（链）：像 流水线工人——人（开发者）预先写好步骤顺序：A 做完接 B，再接 C；路径相对固定。​

•

Agent：像 项目经理——步骤不是完全写死的，模型根据当前观察决定下一步，可分支、可重试、可换工具。​

2.2 原理详解（技术细节）​

​

#boKhQesvUWWl text{white-space:pre}.fb0{stroke:var(--N900-FG, 0.15)}.fx0{stroke-miterlimit:10}.fa1{fill:#bbbfc4}.fx1{font:normal 400 12px MonospacedNumber,LarkHackSafariFont,LarkEmojiFont,LarkChineseQuote,-apple-system,BlinkMacSystemFont,Helvetica Neue,Tahoma,PingFang SC,Microsoft Yahei,Arial,Hiragino Sans GB,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color Emoji}.fx2{text-anchor:middle}.fx3{dominant-baseline:central}.fx4{stroke:none}.fc0{fill:var(--text-caption)}.fa2{fill:var(--text-link-disabled)}.fx5{font:400 normal 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"}.fx6{text-anchor:start}.fx7{dominant-baseline:alphabetic}.fc1{fill:rgb(0, 0, 0)}.fb1{fill:var(--N900-FG, 0.15)}.fb2{fill:rgb(209, 217, 224)}.fa3{fill:var(--bg-body)}ABCD12345维度控制流工具状态适用ChatBot多为线性对话可有可无主要会话上下文问答、闲聊、简单引导LLM Chain开发者定义的 DAG/序列可嵌入固定节点链各节点显式传递ETL 式固定流程Agent模型驱动的分支与循环动态选择与多轮调用记忆 + 环境观察开放问题、研究、自动化任务

​

本质区别一句话：​

•

Chain：控制流在代码里。​

•

Agent：控制流在模型决策 + 环境反馈里（仍可由代码设边界）。​

2.3 面试问题（Q）与标准答案（A）​

Q3：Agent 和 Prompt Chain 有什么本质区别？​

A： Prompt Chain 的拓扑与顺序主要由工程侧固定；Agent 在运行时在动作空间中做选择，并依赖 Observation 更新信念，适合输入与路径不确定的任务。二者可结合：链负责稳定流程，Agent 负责链内某段的灵活分支。​

Q4：ChatBot 加上插件是不是就变成 Agent 了？​

A： 不一定。若插件调用由固定规则触发（例如关键词路由），更像「带工具的 Bot」。若由模型在多步推理中自主选择工具与参数，并形成闭环迭代，则更贴近 Agent。关键在是否具备多步自主决策与反馈闭环。​

2.4 可能的追问及应对​

•

追问：RAG + Chat 算不算 Agent？​

应对： 单次检索再回答，偏「增强型 Chat」。若有多轮检索策略（查不到换查询、分解子问题、交叉验证），则具备 Agent 特征。名称不重要，讲清架构即可。​

Agent 的核心组成​

3.1 概念解释（各部分做什么）​

感知（Perception）​

把多模态输入（文本、文件、接口返回、页面结构等）转成模型可用的表示，并抽取任务相关状态。​

规划（Planning）​

把目标拆成子目标与步骤；可以是 一次性计划 或 每步重规划（re-plan）。​

记忆（Memory）​

◦

短期：当前会话上下文、工具轨迹。​

◦

长期：用户画像、文档知识、向量库、图数据库等。​

工具（Tools）​

对外部世界可执行的操作抽象：需有清晰 schema（名称、描述、参数 JSON Schema）。​

执行（Action）​

真正调用工具或触发环境变化，并处理超时、重试、幂等等工程问题。​

反思（Reflection）​

对失败或质量不佳的结果进行自省：纠错、换策略、生成检查清单（常与「自我批评 / 验证器」配合）。​

3.2 原理详解（技术细节）​

•

感知常与 结构化抽取、OCR、HTML 解析、日志解析 结合；关键是减少噪声进上下文。​

•

规划常见实现：CoT / ReAct、Planner-Executor 双模块、树搜索（LATS）、任务图。​

•

记忆工程要点：摘要压缩、引用溯源、记忆冲突解决、权限与隐私。​

•

工具要点：最小权限、参数校验、错误信息回灌模型。​

•

反思可做成独立子调用：「列出本次推理的三处风险并修正」。​

3.3 面试问题（Q）与标准答案（A）​

Q5：Agent 的记忆一般怎么设计？​

A： 分层设计最常见：工作记忆（当前轨迹与关键结论）+ 会话记忆（摘要滚动）+ 长期记忆（向量检索/结构化库）。写入要区分「事实」与「推断」，并带时间戳与来源，便于更新与撤销。​

Q6：规划和执行要不要拆开两个模型？​

A： 视任务而定。Planner-Executor 拆分可提升可控性（强模型规划、快模型执行）；单模型端到端更简单但易在长链路漂移。可混合：规划用强模型，执行层做确定性校验。​

3.4 可能的追问及应对​

•

追问：反思是不是必须？​

应对： 不是必须，但对高 stakes 或易错工具场景收益大；成本是额外延迟与 Token。​

Q13：请用你自己的话定义 LLM Agent，并说明与单次调用的差异。​

A： LLM Agent 是以大语言模型为推理核心，在 多轮 中与外部环境交互，通过 规划、记忆与工具 完成复杂任务的系统。与单次调用的差异在于：单次调用是 开环生成；Agent 是 闭环决策，每步可依据工具返回更新状态，直到终止条件。​

追问： 若没有外部工具，还能叫 Agent 吗？​

应对： 可称为「弱环境」Agent，仅有对话记忆与推理；但仍可有 内环多步 CoT 与 **自我验证」。面试中强调 是否存在「行动—观察」循环 更清晰。​

​

​

Q14：ReAct 框架里三个字母代表什么？解决什么问题？​

A： Reasoning + Acting：在生成中交替进行 推理（Thought） 与 行动（Action），并接收 观察（Observation）。它解决的是：模型仅「空想」容易偏离事实；通过 显式推理 + 工具反馈 把推理锚定在真实环境上。​

​

​

Q15：你会如何设计 Agent 的停止条件？​

A： 组合使用：模型声明 finish、任务清单全部完成、达到步数/预算上限、超时、连续无进展检测、外部成功信号（如测试通过）。生产环境必须有 硬上限 防止死循环。​

​

​

Q16：工具描述（tool description）为什么非常重要？​

A： 模型靠描述做 工具选择；描述不清会导致 选错工具、参数幻觉。好的描述包含：何时用、何时不用、参数含义、错误示例、返回格式。​

​

​

Q17：Memory 用向量库就够了吗？​

A： 不够。向量检索擅长相似度，但弱于精确约束与关系推理。工程上常见 向量 + 关键词/结构化库 + 图谱（按需），并维护 元数据与权限。​

​

​

Q18：多 Agent 协作和单 Agent 多工具怎么选？​

A：​

•

单 Agent 多工具：实现简单、延迟低，适合任务边界清晰。​

•

多 Agent：角色分工、并行探索、对抗审查（如「批评者 Agent」）；但带来 协调成本与一致性 问题。​

选型看 任务分解结构、组织边界、延迟与成本。​

​

​

Q19：如何做「人在回路」又不打断体验？​

A： 分级：低风险自动执行；中风险 异步审批；高风险 实时确认。产品上 预授权（例如仅本次会话可读某目录）、可撤销、默认最小权限。​

​

​

Q20：Agent 日志应记录什么？​

A： 用户输入（脱敏）、模型原始输出、解析后的工具调用、工具返回摘要、耗时与 Token、版本号（模型与 Prompt）、追踪 ID，便于复盘与合规审计。​

​

​

Q21：为什么「让模型自己选工具」可能不如「路由器 + 规则」？​

A： 在 域窄、路径稳定 的场景，路由器更 省成本、可测试、行为确定；全模型路由在 开放域 更灵活。最佳实践常是 混合：易分类走规则，难例走模型。​

​

​

Q22：简述 Planner-Executor 架构及优缺点。​

A： Planner 产出步骤或 DAG；Executor 逐步执行并可把结果反馈给 Planner 重规划。优点：结构清晰、易加校验；缺点：规划一次可能不准，需 迭代重规划；两阶段可能增加延迟。​

​

​

Q23：Agent 如何做版本管理与灰度？​

A： Prompt/工具/schema 版本化；影子模式（只记录建议不执行）；金丝雀 用户群；关键指标对比（成功率、成本、违规数）；一键回滚。​

​

​

Q24：举一个「不是 Agent 但常被误认为 Agent」的例子。​

A： 固定三步的 RAG 流水线（query 改写 → 检索 → 生成），若无 基于观察的再决策循环，更像 Chain；若加入 多轮检索策略与失败分支 则接近 Agent。​

​

​

Q25：你如何向非技术经理解释 Agent 的风险？​

A： 用 「能办事的实习生」 类比：能力强但可能 记错、被误导、误操作；所以我们要 权限卡、审批、监控录像（日志），重要操作 双人复核——对应最小权限、人在回路、审计。​

​

​

Q26：上下文窗口越来越大，还需要外部记忆吗？​

A： 需要。长窗口 ≠ 低成本，也不等于 可检索、可治理、可遗忘。外部记忆解决 跨会话持久化、结构化权限、版本与溯源；窗口内更适合 热工作集。​

​

​

Q27：如何测试 Agent？​

A： 单元测工具、模拟环境、回归集（固定任务与期望轨迹范围）、对抗用例（注入、越权）、线上金丝雀；避免只测最终答案而忽略 过程正确性。​

​

02 Agent核心框架​

ReAct 框架（重点中的重点）​

1.1 概念解释（通俗易懂）​

ReAct 的全称是 Reasoning + Acting（推理 + 行动）。可以把它想象成：一个会做题的学生，不是一口气写完答案，而是 边想边做——先在心里说一句「我接下来要干什么」（推理），然后真的去查资料、用计算器、调 API（行动），看到结果后再继续想下一步。​

和传统「只输出最终答案」的提示不同，ReAct 要求模型在文本里 显式交替 写出：​

•

推理（Thought）：为什么要这么做、下一步选什么工具、预期看到什么。​

•

行动（Action）：调用某个工具（如搜索、代码执行），并给出参数。​

•

观察（Observation）：环境/工具返回的结果。​

循环多次，直到模型给出 Final Answer。​

一句话：ReAct = 把「思考过程」和「工具使用」写进同一条轨迹里，让推理可监督、可纠错、可复现。​

​

​

1.2 原理详解（技术细节）​

1.2.1 核心思想：交替推理与行动​

单轮问答时，模型容易「幻觉」事实；ReAct 通过 行动 把模型锚定在外部证据上。其关键不是「更会想」，而是 想与做的闭环：​

​

代码块​

Plain Text

用户问题​

→ Thought：拆解子目标​

​

1.2.2 标准工作流程（伪代码）​

​

代码块​

Plain Text

输入: question, tools, llm, max_steps​

初始化: trajectory = []​

​

for step in 1..max_steps:​

prompt = build_react_prompt(question, tools, trajectory)​

text = llm.generate(prompt)​

​

if "Final Answer:" in text:​

return extract_final_answer(text)​

​

thought = parse_thought(text) # 从 Thought: ... 解析​

​

解析要点（面试常问）：​

•

Thought / Action / Observation 通常用 固定前缀 或 结构化格式（如 JSON）便于程序解析。​

•

Observation 只能来自工具，不能由模型自己编造（工程上要校验）。​

•

停止条件：出现 Final Answer，或步数上限，或检测到重复无效循环。​

1.2.3 Prompt 模板设计（完整示例）​

下面是一个 可直接用于教学 的英文模板（业界常用英文工具名；面试时说明「中文任务可把指令改为中文」即可）。​

​

代码块​

Plain Text

You are a helpful assistant that can use tools to answer questions.​

​

若采用 单段 Action 行（不少论文与开源实现风格）：​

​

代码块​

Plain Text

​

设计要点：​

•

工具清单与参数格式要写清，减少模型胡写工具名。​

•

强调「Observation 由系统填充」，避免模型在提示里自己续写假 Observation。​

•

Few-shot：给 1～3 个完整轨迹示例，能显著提高格式遵从率。​

​

​

1.3 面试问题（Q）+ 标准答案（A）​

Q1：ReAct 和「普通 CoT 提示」有什么本质区别？​

A： 普通 CoT 只在模型内部展开推理链，不强制与外部环境交互；ReAct 把推理与 可执行行动 绑定，每一步行动后都有 真实 Observation 反馈，从而用工具结果约束生成，降低闭卷幻觉。​

​

​

Q2：ReAct 为什么要显式写出 Thought？​

A： 显式 Thought 有三类价值：可解释性（便于人类审计）、可调试性（定位哪一步选错工具）、学习信号（可做监督微调或评估中间步骤质量）。在工程上，Thought 也帮助模型在下一步更稳定地选择 Action。​

​

​

1.4 追问及应对​

​

​

​

​

1.5 代码示例（Python，简化版 ReAct 循环）​

​

代码块​

Python

from dataclasses import dataclassfrom typing import Callable, Dict, List, Tuple@dataclassclass Tool:​

name: strrun: Callable[[str], str]​

​

def build_prompt(question: str, history: List[Tuple[str, str, str]], tool_names: str) -> str:​

lines = [​

"You solve tasks with tools. Use EXACTLY this format each turn:",​

"Thought: ...",​

​

​

​

1.6 优缺点分析​

优点​

•

可解释：轨迹可读，便于调试与评测中间步骤。​

•

接地：通过工具把答案锚定在可验证数据上。​

•

通用：与具体工具解耦，易于替换搜索/代码/SQL 等。​

缺点​

•

多轮调用：成本高、延迟大。​

•

格式脆弱：模型若偏离模板，需要解析器与重试策略。​

•

规划能力有限：逐步贪心，复杂任务上可能缺「全局最优计划」（对比 Plan-and-Execute）。​

​

​

1.7 与 Chain-of-Thought（CoT）的区别​

​

​

一句话总结： CoT 让模型「更会想」；ReAct 让模型「在想的同时能动手，并用真实结果纠正自己」。​

LangChain Agent 实现​

5.1 概念解释（通俗易懂）​

LangChain 把 LLM、提示模板、工具、记忆、解析器等拼成可运行程序。Agent 在这里通常指：由 LLM 决定下一步调用哪个工具 的循环执行体；AgentExecutor 负责「跑这个循环直到结束」。​

​

​

5.2 原理详解（技术细节）​

5.2.1 LangChain 中与 Agent 相关的核心抽象（面试口径）​

不同版本命名略有变化，但面试常考概念层：​

•

Tools：对外部能力的封装（name、description、args schema、执行函数）。​

•

LLM / ChatModel：生成下一步决策与内容。​

•

Agent（推理策略）：如何把工具、提示、中间步骤组合起来（ReAct、OpenAI tools 等）。​

•

AgentExecutor：驱动循环：调用 Agent → 若有 tool_calls 则执行工具 → 回填消息 → 直到停止。​

5.2.2 AgentExecutor 工作原理（流程）​

​

代码块​

Plain Text

inputs → AgentExecutor​

loop:​

agent.plan(messages/tools) -> next message / tool_calls​

if final answer: return​

else: run tools -> append tool messages​

(optional) trim memory / handle parsing errors​

​

关键点：停止条件（达到最终答案）、解析错误处理、最大迭代次数。​

5.2.3 自定义 Agent 的步骤（通用 checklist）​

定义 Tools（清晰 description 与 schema）。​

选择 提示模板（ReAct JSON / OpenAI tool calling）。​

选择 模型 与 输出解析器（防止格式漂移）。​

组装 Agent + AgentExecutor（设置 max_iterations、handle_parsing_errors）。​

评测与加固（日志、重试、工具超时）。​

​

​

5.3 面试问题（Q）+ 标准答案（A）​

Q7：LangChain 里 AgentExecutor 解决的核心问题是什么？​

A： 把「模型决策 → 工具执行 → 结果回填 → 再决策」的 控制流 标准化，统一处理 迭代限制、错误处理、中间消息结构，让开发者专注工具与提示。​

​

​

Q8：工具描述为什么重要？​

A： Agent 依赖描述进行 工具选择；描述不清会导致错选工具或参数幻觉。应包含 用途、输入输出、边界条件、示例。​

Q13：请用一句话解释 ReAct。​

A： 让模型交替输出推理与可执行行动，并用工具返回的 Observation 闭环纠错，从而把推理接地到外部环境。​

​

​

Q14：ReAct 轨迹里，哪一部分必须由系统生成？为什么？​

A： Observation 必须由工具/环境生成，防止模型伪造证据导致「看似合理但错误」的答案。​

​

​

Q15：Plan-and-Execute 的最大风险是什么？如何缓解？​

A： 风险是 错误计划污染全局；缓解是 可验证子步骤、重规划、强 Planner 约束输出 与 执行期监控。​

​

​

Q16：Reflexion 的关键产出是什么？它如何提升下一轮？​

A： 关键是 高质量反思文本；它作为记忆进入下一轮提示，指导 Actor 改变策略而非重复错误。​

​

​

Q17：LATS 与 ReAct 在「探索能力」上如何对比？​

A： ReAct 通常主路径贪心推进；LATS/MCTS 通过 多分支搜索与价值回传 更系统探索决策空间（成本更高）。​

​

​

Q18：LangChain AgentExecutor 中为什么要限制 max_iterations？​

A： 防止工具循环、解析失败导致的 无限循环，并控制成本与延迟。​

​

​

Q19：描述 LangGraph 的条件边解决的业务问题。​

A： 根据中间状态动态路由，例如失败重试、需要人工审核、不同客户等级走不同流程。​

​

​

Q20：什么时候更建议「单 Agent + 强工具」，而不是多 Agent？​

A： 任务边界清晰、无需组织化分工、协调成本可能大于收益时；或延迟/成本敏感场景。​

​

​

Q21：多 Agent 系统的「评估器」可以有哪些实现？​

A： 单元测试/静态规则、更强模型评审、人工审核节点、外部检索核对事实等。​

​

​

Q22：ReAct Prompt 为什么要给 few-shot 示例？​

A： 提升模型对 固定格式 的遵从度，降低解析失败率，稳定工具调用。​

​

​

Q23：Re-planning 与 Reflexion 都「改正错误」，区别是什么？​

A： Re-planning 偏 计划结构 的调整（下一步怎么走）；Reflexion 偏 策略/经验 的语言化总结并跨轮复用。​

​

​

Q24：LangGraph 相比普通脚本编排的核心收益？​

A： 把流程 显式化 为图，分支/回环/人机节点一等公民，更易维护与观测。​

​

​

Q25：如果工具返回噪声很大，ReAct 可能出什么问题？怎么改进？​

A： 模型可能被噪声误导；改进包括 工具侧清洗/结构化输出、二次检索、在 Thought 里强制 引用证据片段、增加 校验工具。​

​

​

Q26：你如何为一个企业场景选择 ReAct vs Plan-and-Execute？​

A： 看任务是否 强流程、是否需要 可审计计划书、是否允许 前期规划成本；需要强工具交互与动态环境用 ReAct，强分解与多步骤交付用 Plan-and-Execute。​

​

​

Q27：为什么说「工具描述」是 Agent 的接口设计？​

A： LLM 靠描述做路由与填参；描述就是 人机接口，直接影响成功率。​

03 RAG技术​

04 工具调用​

05 记忆系统​

06 多智能体系统​

07 大模型基础​

08 工程化实践​

09 Prompt工程​