角色详解 (Roles)
在大模型对话中，messages 数组的每个元素都是一个对象，其中 role 字段是其核心。不同的 role 承担着不同的功能，共同构建了完整的对话上下文。
| 角色 (Role) | 主要功能 | 使用场景与示例 | 备注 |
|---|---|---|---|
| system (系统) | 设定模型的行为、角色、语气和规则。 | 用法 ：设定AI助手的个性和边界。 示例 ：{"role": "system", "content": "你是一位专业的翻译官，会将用户输入的任何语言翻译成中文。"} |
可选，且通常必须位于 messages 数组的第一条。 |
| user (用户) | 代表用户的输入，可以是问题、指令或任何想要模型处理的内容。 | 用法 ：用户的每一次提问或指令都应使用此角色。 示例 ：{"role": "user", "content": "请帮我总结一下这篇文章的核心观点。"} |
每轮对话的起点，必选。 |
| assistant (助手) | 代表模型对用户输入的回复内容。 | 用法 ：在多轮对话的历史记录中，模型的每一次回复都应使用此角色。 示例 ：{"role": "assistant", "content": "这篇文章的核心观点是..."} |
在多轮对话中，assistant 的历史回复需要被包含在后续请求的 messages 中，以维持上下文连贯性。 |
| tool (工具) | 用于模型进行函数调用（Function Calling/Tool Use） 的高级功能，代表工具的执行结果。 | 用法 ：当模型请求调用某个工具后，你需要将工具的执行结果通过 tool 角色回传给模型。 示例 ：{"role": "tool", "tool_call_id": "call_abc123", "content": "{\"temperature\": 25}"} |
常用于构建可执行具体操作的AI Agent。 |
| developer (开发者) | 部分新模型（如GPT-OSS）引入的角色，用来替代传统的 system 角色，更具权威性。 |
用法：用于向模型提供更底层的、开发者级别的指令。 |
REACT
一、核心思想
ReAct = Reasoning (推理) + Acting (行动)
- 不是纯思考（CoT）→ 无法获取外部信息
- 不是纯行动 → 缺乏规划和纠错
- 而是交替进行"思考→行动→观察"的闭环
一句话：让LLM像人一样，边想边做，根据结果调整，直到完成任务。
二、三个核心概念（谁做什么）
| 概念 | 含义 | 谁生成/执行 | 例子 |
|---|---|---|---|
| Thought | 内心独白：分析、拆解、规划 | LLM 生成（文本） | Thought: 我需要搜索华为最新手机 |
| Action | 具体动作：调用工具或Finish | LLM 决定（输出字符串），你的代码解析并执行 | Action: Search[华为最新手机] |
| Observation | 工具返回的结果 | 你的代码 调用真实API获取，然后追加到历史 | Observation: 华为Mate 70... |
关键理解：
- LLM 不会直接调用工具，只输出文本指令
- 你的代码负责解析指令、执行工具、拼接Observation到下一轮对话
- Observation 本质是注入到 prompt 中的额外上下文
三：tools
什么时候不该用 ReAct？ 任务不需要外部信息（纯内部推理） → 用 CoT 更便宜更快。
外部信息 = 任何不在 LLM 训练参数中隐含存储、需要通过调用外部工具（Tool）才能获取的信息。
包括但不限于：
| 类型 | 例子 | 是否需要工具 |
|---|---|---|
| 实时数据 | 当前天气、股票价格、新闻头条 | ✅ 需要（搜索/API） |
| 私有数据 | 公司数据库里的订单记录、用户画像 | ✅ 需要（数据库查询） |
| 精确计算 | 12345 × 6789 ÷ 3 的结果 | ✅ 需要（计算器工具） |
| 超长文档 | 一本1000页的PDF中的具体段落 | ✅ 需要（检索/读取工具） |
| 外部知识 | 某个冷门领域的专业术语解释（LLM可能幻觉） | ✅ 需要（搜索或知识库） |
| 纯逻辑推理 | "如果A则B，A为真，问B？" | ❌ 不需要（LLM自身可推） |
| 常识推理 | "今天是周三，后天是周几？" | ❌ 不需要 |
| 已知事实（训练集内） | "中国的首都是哪里？" | ❌ 不需要 |
Plan-and-Solve
一、核心思想
一句话：先规划（Plan），后执行（Solve）------像建筑师画图纸再施工，而不是像侦探边查边想。
- 规划阶段 ：LLM 将复杂问题分解为一系列有序的子步骤（计划）。
- 执行阶段 ：严格按照计划顺序执行每个子步骤，上一步结果作为下一步输入。
关键实现细节与难点
难点1：如何让 LLM 输出格式绝对可靠？
| 方法 | 说明 |
|---|---|
| 强制代码块 | 要求输出放在 ```````python```` 中 | |
| few-shot 示例 | 在提示词中给出1~2个完美示例 |
| 安全解析 | 使用 ast.literal_eval 而非 eval |
| 重试机制 | 解析失败时重新调用 LLM，并强调格式 |
难点2：步骤粒度如何控制？
- 太粗：步骤模糊，LLM 不知道怎么做
- 太细：步骤过多，token 浪费，错误累积
原则 ：每个步骤应是 LLM 可以单步完成 的子任务。
✅ 好的步骤："计算矩形面积：长 × 宽"
❌ 差的步骤："处理数据"（太模糊）
难点3：历史过长导致 token 超限
- 只保留最近 k 步结果
- 对历史做摘要（如"上一步结果为 X"）
难点4：某一步执行失败怎么办？（原始范式未解决）
原始 Plan-and-Solve 计划静态 ，无恢复机制。
改进方案 ：引入动态重规划
python
for i, step in enumerate(plan):
answer = solve_step(step, history)
if is_invalid(answer): # 检测失败
new_plan = replan(plani:, history) # 重新规划剩余步骤
plan = plan:i + new_plan
continue
history += f"{step}: {answer}\n"
难点5：错误累积（接力棒效应）
如果第 i 步答错，后续所有步骤都基于错误结果。
缓解方法：
- 用计算器工具代替 LLM 做数值计算
- 每步后增加自验证（如"请确认上一步结果是否正确"）
- 使用更强模型做执行
Reflection
一、一句话定义
执行 → 反思 → 优化 迭代循环。
智能体像人类一样：先写初稿，再自我批判，然后修改，直到满意。
核心价值：将"一次性生成"升级为"持续迭代优化"，显著提升输出质量
三个关键角色（不同提示词）
| 角色 | 目标 | 提示词风格 |
|---|---|---|
| 执行者 (Execution) | 生成初始方案 | 直接、任务导向 |
| 评审员 (Reflection) | 找出问题，提出改进建议 | 批判性、严格、专注质量维度 |
| 优化者 (Refinement) | 根据反馈修改方案 | 建设性、循循善诱 |
关键点 ：这三个角色可以由 同一个 LLM 扮演（通过不同提示词），也可以用 不同模型（如GPT-4反思，GPT-3.5执行）。
output = llm(initial_prompt) # 初稿
for i in range(max_iterations):
feedback = llm(reflect_prompt + output) # 反思（不调用工具）
if "无需改进" in feedback:
break
output = llm(refine_prompt + output + feedback) # 优化
return output
三个范式的总结
三种智能体范式综合对比（ReAct / Plan-and-Solve / Reflection）
一、一图看懂三种范式
| 范式 | 核心流程 | 一句话解释 |
|---|---|---|
| ReAct | 思考 → 行动 → 观察 → 思考 → ... |
边想边做，边做边改，依赖外部反馈 |
| Plan-and-Solve | 先规划列表 → 再顺序执行 → 传递结果 |
先画图纸，再施工，计划固定 |
| Reflection | 执行初稿 → 自我反思 → 优化 → 再反思 |
写完初稿，自己当评委修改，内部迭代 |
react：调用外部工具不断优化
plan：先计划好再执行
reflection：不同的角色，自己批判自己
三者混合使用，完成自己的目标。
二、详细对比表
| 维度 | ReAct | Plan-and-Solve | Reflection |
|---|---|---|---|
| 核心理念 | 推理与行动协同 | 先分解任务，再逐步求解 | 自我批判，迭代优化 |
| 决策方式 | 动态、步进（每步观察后调整） | 静态、全局（计划一次性生成） | 动态、质量驱动（多次迭代） |
| 信息反馈来源 | 外部工具（搜索、API、数据库） | 内部历史（上一步结果） | 内部自省（LLM 自我评价） |
| 是否需要外部工具 | 通常需要（否则失去意义） | 不需要（纯推理） | 不需要（可纯粹内部优化） |
| LLM 调用次数 | 不确定（≈ 实际步数，一般3~6次） | 1次规划 + N次执行 | 1次执行 + 2×迭代轮数（通常2~3轮） |
| 成本与延迟 | 中等 | 中等（N 较大时偏高） | 高（迭代叠加） |
| 可解释性 | 高（Thought 链可见） | 高（计划与中间结果可见） | 高（反馈轨迹可见） |
| 典型适用场景 | 需要实时/外部知识的任务 | 逻辑清晰、可分解的任务 | 对质量要求极高、可离线优化的任务 |
| 典型例子 | "华为最新手机是哪款？"（需搜索） | "三天苹果销量总和"（数学题） | "写出高效的素数函数"（代码优化） |
| 主要局限 | 依赖 LLM 格式遵循；可能陷入循环 | 计划静态，无法应对意外 | 成本高；反馈质量决定上限 |
三、核心伪代码对比
1. ReAct
python
def react(question):
history = \[\]
for _ in range(max_steps):
prompt = build_prompt(question, history, tools)
response = llm(prompt)
thought, action = parse(response)
if action.startswith("Finish"):
return extract_answer(action)
tool, arg = parse_action(action)
obs = call_tool(tool, arg) # 必须调用外部工具
history.append(f"Action: {action}\nObservation: {obs}")
return None
2. Plan-and-Solve
python
def plan_and_solve(question):
阶段1: 规划（一次LLM调用）
plan = llm(planner_prompt + question) # 输出 "步骤1","步骤2",...
阶段2: 执行（顺序调用LLM，传递状态）
history = ""
for step in plan:
result = llm(executor_prompt + question + plan + history + step)
history += f"{step}: {result}\n"
return result # 最后一步结果
3. Reflection
python
def reflection(task):
output = llm(initial_prompt + task) # 初稿
for i in range(max_iterations):
feedback = llm(reflect_prompt + task + output) # 自我批判
if "无需改进" in feedback:
break
output = llm(refine_prompt + task + output + feedback)
return output
四、如何选择？------ 决策树
text
开始
│
├─ 任务需要外部信息（搜索/数据库/API）？
│ ├─ 是 → 选择 ReAct （必须用工具）
│ └─ 否 → 继续判断
│
├─ 任务是否可明确分解为线性步骤，且步骤间无分支？
│ ├─ 是 → 选择 Plan-and-Solve （更快、更省）
│ └─ 否 → 继续判断
│
└─ 对最终输出质量要求极高（代码/报告/决策）且可容忍高延迟？
├─ 是 → 选择 Reflection
└─ 否 → 单次 LLM 调用或 ReAct（轻量）
AI Agent 面试题全面总结（基于2026年大厂真题）
面向：Agent开发岗位（字节、阿里、腾讯、美团等大厂）
整合来源：27道大厂真题、30道高频题、15道核心题及多篇深度面经
一、基础概念篇（面试第一道分水岭）
Q1：什么是AI Agent？和传统LLM Chatbot的本质区别是什么？
核心回答框架：
- Agent = LLM（大脑） + 规划模块 + 记忆模块 + 工具模块，在闭环中自主完成目标
- Chatbot是被动问答机（用户输入→LLM→输出文本），Agent是主动行动者（用户输入→LLM→决定工具→执行→观察→循环→目标达成）
| 对比维度 | Chatbot | Agent |
|---|---|---|
| 能力 | 只生成文本 | 生成文本 + 调用工具 |
| 交互 | 一问一答 | 多步骤自主循环 |
| 记忆 | 通常无状态 | 短期+长期记忆 |
| 核心组件 | LLM | LLM + Planning + Memory + Tools |
背诵版本：Agent区别于Chatbot的四个本质特征是感知、规划、行动、记忆。
追问 ："若没有外部工具，还能叫Agent吗？"
A：可以称为"弱环境Agent"，仍具对话记忆和推理能力，也可有内环CoT与自我验证。面试中强调是否存在"行动-观察"循环更清晰。
Q2：LLM和Agent有什么区别？
核心回答 ：LLM本质上是一个条件概率模型，无状态、无记忆、不对外部世界交互。LLM存在四大天花板：
- 只会说不会做------它能告诉你"可以查天气"，但自己不会去查
- 没有记忆------上下文窗口一满就"失忆"
- 知识截止------训练数据有截止日期，昨天的事不知道
- 不会规划------无法自主拆解复杂任务
回答范例 ："帮我查一下明天北京的天气，如果下雨就取消跑步计划"：LLM会告诉你"可以打开天气APP查询，手动去日历删除"；Agent会直接调用天气API→调用日历API找到跑步计划→删除→回复"已完成"。"LLM告诉你怎么做，Agent直接帮你做完"。
面试加分点 ：Agent完整四模块**------LLM（大脑）负责理解意图与推理判断；规划模块负责任务拆解与步骤排序；记忆模块负责短期上下文与长期知识存储；工具模块负责调用外部API/数据库，是Agent的"手和脚"**。
Q3：Agentic Loop是什么？画一下它的流程？
Agentic Loop是Agent的"工作流水线"，标准四步循环：
- Thought（思考） ：根据当前状态决定下一步做什么
- Action（行动） ：调用工具或执行动作
- Observation（观察） ：接收工具返回结果
- （循环） → 直到目标达成
追问案例："帮我退掉上周五买的书"。第1轮：Thought"需查订单"→Action调用getOrders→Observation看到订单；第2轮：Thought"已发货，查退货政策"→Action调用getReturnPolicy→Observation获知支持7天无理由；第3轮：Action调用createReturn→Observation收货结果；第4轮：回复用户。
Q4：Agent和Workflow/Prompt Chain的区别是什么？
| 类型 | 决策主体 | 执行路径 | 适用场景 |
|---|---|---|---|
| Workflow | 代码（固定流程） | 线性/分支固定 | 标准化任务，如报表生成 |
| Agent | LLM（动态决策） | 动态调整 | 开放任务、复杂决策 |
| Prompt Chain | 工程侧固定 | 线性 | 输入确定、流程固定场景 |
"Workflow适合步骤固定、无动态决策 的标准化任务；Agent解决需要自主决策、动态适应的复杂任务，二者可根据需要组合。"
何时不该用Agent：① 任务简单且步骤固定；② 延迟要求极高（<100ms）；③ 成本敏感、调用次数受限；④ 无工具依赖、纯对话场景。
二、三大经典范式篇（面试最高频）
Q5：ReAct范式的工作原理是什么？核心优缺点？
核心回答 ：Reasoning（推理）+ Acting（行动）交替进行。思考→行动→观察→再思考的闭环循环。
3个关键机制：
- Observation反馈驱动：工具返回结果进入下一步Thought
- 执行轨迹可回溯：每一步Thought说明为什么选这个Action，便于调试
- 多工具协同 ：每一步Action可绑定任意工具，天然支持多工具协同
优点 ：实现简单、灵活应变、调试方便、工具调用准确率提升可达42%。
缺点：长流程易偏离目标、易陷入循环、复杂任务效率低、对LLM输出格式强依赖。
追问 ："ReAct如何解决幻觉问题？"
A：通过持续观察环境反馈，将工具执行结果作为新上下文输入LLM，形成闭环验证，从根本上减少模型凭空捏造。
追问 ："如果工具返回空结果，下一步Thought怎么处理？"（面试官高阶追问）
A：需在Thought prompt中加入结构化约束，要求模型在上一条Observation不符合预期时，先验证工具调用是否正确（参数错？查无数据？需换工具？），再调整策略，不能盲目重试。
Q6：Plan-and-Solve / Plan-and-Execute的核心思想？
两阶段解耦：先规划后执行。
- 规划阶段：LLM将模糊高层目标拆解为有序子任务序列
- 执行阶段 ：严格按照规划逐步执行，上一步结果传递给下一步
优点 ：长流程任务不偏离目标、步骤结构清晰可追溯。
缺点：计划静态，执行中发生意外无法自适应。
ReAct vs Plan-and-Execute本质差异 ：Plan-and-Execute是"先铺完所有铁轨再开车 "，ReAct是"边铺轨边开，根据地形随时调整"。
面试进阶：生产实践中，ReAct和Plan-and-Execute并非互斥，而是可以混合使用------整体先用Plan做顶层规划，执行中遇到异常细节，自动切换到ReAct做局部动态调整。
追问 ："为什么不用ReAct？"
A：长流程任务中，ReAct容易遗忘初始目标，容易"迷路"。Plan-and-Execute先拆解所有子任务，确保后续决策始终围绕全局目标，避免偏离。
Q7：Reflection（反思机制）是什么？
核心回答：智能体的"自我纠错、迭代优化"能力------在执行任务后检查自身行为和结果，发现不足并修改。核心价值：减少幻觉、提升准确性；提升自主性、减少人类干预。
三个核心触发条件：
- 行动后触发：每完成一步自动反思
- 异常时触发：工具调用失败或输出偏离目标时触发
- 任务结束后触发：整体完成后全面反思
设计误区警示 ："很多人一听反思，就以为是让模型输出一句'我再仔细检查一下'，这没用。"Reflection不是让人去思考，而是让Agent自己拿一套标准去校验自己的结果，发现漏洞后自我修正。
追问 ："Reflection和ReAct的核心区别是什么？"
A：ReAct的反馈来自外部工具 （Observation），修正行动路径；Reflection的反馈来自内部自省 （LLM自我批判），优化输出质量。Reflection没有独立任务闭环能力，不能单独承接完整业务，而是给ReAct和Plan-and-Execute加装的"检查修正buff"。ReAct管"把事做完"，Reflection管"把事做好"。
追问 ："如何避免Reflection陷入无限循环？"
A：①设置最大反思迭代次数（通常3轮）；②加入终止条件------当修改建议中无有效优化点时自动终止；③连续两轮输出几乎无变化时提前终止。
Q8：ReAct / Plan-and-Execute / Reflection三者如何选型？
从三个不同维度 理解三者的定位差异：ReAct解决"任务执行灵活性 "，Plan-and-Execute解决"长流程可控性 "，Reflection解决"输出质量严谨性"。
选型决策树：
text
开始
├─ 任务是否依赖外部工具（实时信息/搜索/API）？
│ ├─ 是 → 采用 ReAct（或在此基础上加Reflection优化输出质量）
│ └─ 否 → 继续判断
│
├─ 任务是否可明确分解为线性步骤？
│ ├─ 是 → 采用 Plan-and-Execute + Reflection（后者用于校验每步结果）
│ └─ 否 → 采用 ReAct
│
└─ 对最终输出质量要求极高（代码生成/报告/决策）？
├─ 是 → 在所选范式上加Reflection作为质量保障层
└─ 否 → 单次LLM调用或轻量ReAct
一句话理解 ：ReAct="推进器 "，Plan-and-Execute="导航图 "，Reflection="质检员"。三者不是并列选择，而是可以组合使用
三、工具调用与Function Calling篇（大厂必问）
Q9：Function Calling是怎么工作的？大模型怎么"学会"调工具？
核心回答 ：工具调用能力不是天生的，是后天训练出来的，分两个阶段：
- SFT（监督微调）阶段：给模型看大量"正确的工具调用示范"，每条训练样本完整展示"用户问了什么→有哪些工具可用→该不该调→调哪个→参数怎么填→结果回来之后怎么回答"。模型在几十万条样本上反复训练后，学会这一套动作流程。
- RLHF（基于人类反馈的强化学习）阶段 ：SFT教会模型"怎么调"，但没教会"什么时候该调、什么时候不该调"。RLHF通过人类的偏好反馈，帮模型建立判断边界------简单问题直接回答，别画蛇添足去调工具。
追问 ："用了三个项目的Function Calling，但对它的训练原理一无所知。SFT和RLHF在工具调用这件事上分别解决了什么问题？"（大厂面试官追问）
A：SFT教会模型格式和流程 （输出JSON、调哪个工具），RLHF教会模型边界和质量（什么时候调、不调、调错如何纠正）。
Q10：Function Calling 和 Tool Use 有什么区别？各有什么优缺点？
| 维度 | Function Calling | Tool Use |
|---|---|---|
| 标准化 | 高（JSON Schema） | 中（自定义格式） |
| 灵活性 | 中 | 高 |
| 并行调用 | 不支持 | 支持 |
| 实现复杂度 | 低 | 高 |
| 兼容性 | 好（OpenAI） | 一般 |
选择建议：简单场景→Function Calling，复杂工具系统→Tool Use，需要并行调用→Tool Use。
Q11：如何让模型老老实实调用工具，不瞎编参数？
分两套方案保障参数规范：
- 优先使用模型原生function calling，后端直接解析结构化数据，稳定性最优
- 不支持函数调用的模型：Prompt中完善工具定义，标注参数类型、必填项、入参示例，强制输出JSON；后端增加正则校验，格式错误重试2次；关键参数后端配置默认值兜底，不完全依赖模型生成
四、记忆机制篇
Q12：Agent的记忆怎么设计？
分层设计最常见：
记忆分层：
- 工作记忆（短期）：当前任务轨迹和关键结论，存Redis
- 会话记忆（短期）：摘要滚动，避免上下文过长
- 长期记忆：向量检索/结构化库存储历史信息
写入要点：区分"事实"与"推断"，附带时间戳和来源。对话过长需自动摘要压缩，防止超限撑爆窗口。
记忆类型对比：短期记忆基于上下文窗口内历史对话存储实现。长期记忆通过会话结束后的摘要压缩，提取用户偏好和常用信息向量化存入向量库，新对话通过向量检索召回相关历史信息。
五、高级话题篇（拉开差距的关键）
Q13：多智能体（Multi-Agent）怎么协作？
核心实践：
- 角色固化：各Agent的System Prompt固定岗位职责和输出格式（编码Agent只写代码，审查Agent只做校验）
- 串行流转：顺序链路，代码编写完成直接下发给审查Agent
- 消息规范：全量消息用JSON封装，携带任务ID方便链路追踪
- 冲突处理：多Agent意见矛盾时，新增仲裁Agent，关键业务节点预留人工介入通道
Q14：MCP（Model Context Protocol）是什么？
MCP是连接AI助手与外部数据源和工具的开放标准化协议 。当Agent需要连接多个不同的外部系统和工具时，如果每个系统都用独立的自定义接口，会导致集成成本高昂、难以维护。MCP通过统一协议格式解决这个问题。
大厂面试追问 ："MCP和传统Function Calling最大的区别是什么？"
A：Function Calling是调用协议本身 （让模型学会输出结构化JSON），MCP是管理和接入协议（一套标准化规范，让Agent可以统一连接各种外部数据源和工具）。
Q15：Agent如何实现工具的组合调用？
三种组合模式：
- 顺序调用：工具按顺序调用，后一个工具使用前一个工具的结果（如"查询→分析→生成报告"）
- 并行调用：多个工具同时调用，提高执行效率（如同时查询多个数据源）
- 条件调用：根据前一个工具的结果决定后一个工具是否调用（如搜索→如果搜不到则改用另一引擎）
六、系统设计与工程化篇（面试后半场核心）
Q16：工具调用失败、超时怎么办？
工程化处理方案：
- 统一封装所有工具调用函数，捕获异常后返回标准化错误信息回传给模型
- 由模型自主选择：重试调用、更换备选工具或告知用户异常
- 熔断限制：单工具最多重试2次，全任务设置30s全局超时，超时直接终止
- 降级方案：核心工具配置备用API，主接口故障自动切换
追问 ："Agent调了三个工具就死循环了，异常处理在哪写的？"（大厂面试官场景题）
A：三层防御体系：工具层硬隔离（工具白名单、执行沙箱、超时限制）→推理层熔断（步骤上限、重复检测、熔断降级）→规划层自修正（反思机制、偏差检测、自动修正）。
Q17：Agent死循环怎么防止？
三个常见实现方式：
max_iterations：设置最大循环次数- 重复检测：Agent连续两次做出相同Action时，强制触发Reflection Prompt："你已经尝试过此路径且失败了，请更换策略"
stop word机制：某些关键词触发终止
Q18：上下文窗口不够用怎么办？
优先工程优化，模型扩容作为兜底：
- 早期对话压缩成摘要，只留存关键信息
- 超长任务拆分子任务，子任务独立对话执行，最后汇总结果
- 中间结果存入数据库，按需读取，不全塞进上下文
- 上述方案无效时，更换大窗口上下文模型
Q19：怎么评估Agent效果好不好？
从离线、线上两个维度评估：
- 核心指标：任务成功率、执行步数&耗时、工具调用准确率
- 离线评测：自建标注测试用例，人工标注标准答案，使用GPT-4自动化打分
- 线上监控：依托用户反馈、线上失败率，配合A/B测试持续迭代
七、场景设计与系统架构篇
Q20：设计一个"客服智能体"，你会选哪种范式？
题目背景：需要理解退款申请理由、查询订单状态、根据政策判断是否批准退款、生成回复邮件并发送。
推荐方案 ：混合范式------整体流程用Plan-and-Execute 规划步骤（理解申请→查订单→判断政策→生成回复→发邮件），其中"查询订单""判断政策"等子任务内部用ReAct 调用外部工具（订单API、政策知识库），最终回复输出前用Reflection检查逻辑合理性。
工具清单：订单查询API、物流状态API、退款政策知识库、邮件发送API。
关键挑战 ："如何确保智能体的决策既符合公司利益，又能保持对用户的友好态度？"
A：提示词中需加入平衡性原则："在遵守退款政策的前提下，优先考虑用户体验，对符合条件的情况快速批准，对不符合的情况提供替代方案（如换货）。当判断存在争议时，输出置信度低于阈值则启动Reflection再审查。"同时建议核心决策节点留人工审核通道。
上线风险：工具调用失败时决策中断、模型对政策理解偏差导致错误批准、恶意用户利用智能体漏洞、成本失控（长对话多工具调用）。降低风险：工具熔断降级、policy注入并增加验证、异常检测和审计日志、步数限制和预算控制。
Q21：你项目中的Agent遇到的最大挑战是什么？
生产环境里的常见问题**------无限循环调用：模型反复调用失败工具，需增加失败计数，超限直接终止。真正的工程挑战在于设计一个安全的自主边界：给太多自主权，模型可能做出不可预期的操作；给太少，退化成Chatbot。**大厂的面试官不是在面一个会调API的人，而是在面一个能搭系统、能修车的人**。
八、高频追问速查表
| 追问方向 | 一句话回答要点 | 深度展开建议 |
|---|---|---|
| ReAct循环怎么用代码实现 | 需要维护history列表，循环调用LLM直到Finish | 给面试官展示伪代码，重点说"解析Action→调用工具→追加Observation" |
| ReAct和RAG有什么区别 | RAG检索静态知识库，ReAct动态调用工具获取实时信息 | 可以问"一个Agent系统可能同时需要RAG和ReAct吗？" |
| Reflection会不会成本太高 | 通常在2-3轮后收益递减，低成本场景可省略 | 引本章成本收益表，结合项目说 |
| Function Calling适合不适合复杂组合 | 简单场景适合，复杂组合需上Tool Use | 准备组合模式例子------顺序/并行/条件 |
| Agent安全性怎么保障 | Prompt注入防御、工具调用权限校验、沙箱执行、审计日志 | 最少可说出"工具白名单+参数校验" |
| 何时不该用Agent | 简单固定流程、极低延迟要求、无工具依赖的纯对话场景 | 用上表列出的4条作答 |
九、面试官推荐追问路径
- 问定义→答概念差异→追问"本质区别"→从LLM四大天花板展开→再追问"那就不要Agent全用Workflow？"→引导回场景选型
- 问ReAct范式→答"思考→行动→观察"→追问失败路径→答"工具调用失败空结果"及处理→再追问可混合范式→答"先Plan后ReAct"
- 问Function Calling→答"模型输出JSON后解析"→追问训练原理（SFT和RLHF区别）→继续追问具体怎么构造训练数据