AI 面试 / 150 道 AI 面试题

6. 人工智能智能体

原文备份 · 第 7 / 22 篇 · 查看极客时间原知识库 ↗

本篇目录 · 16 节

来源：150 道 AI 面试题

Agent 是"LLM + 工具 + 记忆 + 规划循环"。重实战：怎么设计工具、怎么规划、怎么多 Agent 协作、怎么防失控。

65. 一个 Agent 的"规划能力"是怎么来的？ReAct 和 Plan-and-Execute 的本质区别是什么？

直接答案：Agent 的规划能力来自**"推理 + 行动 + 观察"的循环**，而非一次性的"想好全部再执行"。

ReAct：将推理（Thought）、工具行动（Action）、观察（Observation）交替进行，执行者根据新证据决定下一步；它可以保留高层目标或计划，并非禁止全局计划。

Plan-and-Execute：把显式计划与执行职责拆开——先规划器生成完整计划，执行器逐项执行，通常还需要重规划（Replan）来处理意外。

本质区别：计划是否显式且前置。ReAct 是"边做边想、逐步决策"；Plan-and-Execute 是"先列计划、再执行、偏差时重规划"。

知识点讲解：

没有固定步数分界：不存在"小于 8 步用 ReAct、超过 10 步用 Plan"的通用选型线。要比较任务依赖、环境不确定性、错误可恢复性、并行收益、规划成本五个维度。
选型判断轴：
- 环境不确定、需边做边看 → ReAct（如查证经常变化的信息）。
- 步骤清晰、依赖明确、可并行 → Plan-and-Execute（如仓库迁移分阶段验收）。
验证方法：用同一评测集测成功率、延迟、费用和越权率，而非拍脑袋。
并行的前提：只有相互独立的子任务才可安全并行，显式计划本身不保证这一点。

参考：ReAct 论文。

66. 工具职责怎么划分？"工具太多"和"工具职责重叠"会带来什么问题？

直接答案：工具按明确业务动作划分，名称、描述、参数与权限要一致。两类反模式：

工具太多/职责重叠：重复能力增加选择歧义——模型不知道该选哪个，容易选错或乱选。
巨型工具：把所有能力塞进一个工具，把复杂度转移到参数中，模型难以填准参数。

知识点讲解：

没有通用阈值：不存在"少于 100 个工具、每个少于 20 个参数才稳定"的固定规则。要用真实任务集测工具选择准确率、参数合法率、任务成功率、延迟，再比较按需加载、工具分组或路由的收益。
工具粒度原则：一个工具 = 一个清晰业务动作，职责单一。例如 search_orders（查）与 refund_order（退）分开，后者要求订单 ID、退款额度、幂等键和执行层授权。
反例：do_everything(action, payload) 把约束全藏进参数，模型既难填对，执行层也难校验。
工具描述是 prompt 的一部分：描述写不清楚，模型就不会正确调用——这是高频坑。

67. 遇到中途变化，ReAct 与 Plan-and-Execute 如何取舍？

案例题：对"分析三个仓库并提出迁移方案"，怎样选择 ReAct 与 Plan-and-Execute？第 65 题介绍架构，这里关注中途变化。

直接答案：

先做只读盘点，拆出可独立验证的任务。
信息未知时允许观察后决定下一步（ReAct 风格）。
步骤已清楚时用计划逐项执行（Plan 风格）。
遇阻塞时重规划：若第二个仓库缺少构建环境，记录阻塞并调整计划，不能继续假定所有验收通过。

知识点讲解：

选择依据是动态的：依赖关系、反馈频率、失败恢复与成本，不是固定的步数分界。
中途变化是常态：真实任务总会遇到"假设不成立"的情况，关键在于能否检测偏差并重规划，而非死守原计划。
验证：用同一任务比较成功率、重做次数、总开销，看哪种架构在中途变化下更稳健。
可恢复性关键：可独立验证的子任务失败了能局部重做，不必整体重来。

68. Agent 的记忆（Memory）怎么设计？短期和长期怎么分？

直接答案：Agent 记忆分三层设计：

短期/工作记忆：当前任务上下文，放上下文窗口。
长期/情景记忆（Episodic）：历史会话，存数据库，按需检索。
语义记忆（Semantic）：长期知识、用户偏好，存向量库。

知识点讲解：

核心认知：上下文窗口 ≠ 记忆——窗口会溢出，必须分层持久化。
长期记忆要"按需召回"而非"全量塞入"：否则噪声挤掉目标。用检索（语义记忆）或时间排序（情景记忆）召回相关片段。
摘要化时机：达到阈值时把旧轮次压缩成摘要，持久化到情景记忆。
记忆的一致性问题：语义记忆（如用户偏好）需要更新和去冲突机制，否则新旧矛盾信息并存。
记忆 vs 隐私：长期记忆可能包含敏感信息，要考虑保留策略和合规。

69. Agent 为什么容易陷入死循环？怎么防？

直接答案：死循环是 Agent 的头号失败模式，成因：

模型反复调同一工具，结果无进展。
没有明确的终止条件。
错误结果导致重复尝试（"再试一次"没意义却反复试）。

防：

MAX_STEPS 硬上限：代码级限制最大步数。
检测重复调用：连续调同一工具且无进展则强制终止。
明确终止条件：约定"达成目标就停止"的判定标准。
预算三重上限：步数 + 时间 + token，任一触顶即停。

知识点讲解：

核心：护栏必须是代码级硬约束，不能靠模型自觉——模型自己不知道"该停了"。
死循环的真实代价：不只是慢，还有成本失控（token 越烧越多）和用户体验崩坏。
"无进展检测"的实现：比较连续 N 轮的状态变化，若无新信息/新结果则终止。
终止条件要可判定：不能只说"任务完成就停"，要定义可程序判断的完成信号（如"已得到最终答案""已执行目标动作"）。
面试加分点：能说出"步数/时间/token 三重预算" + "无进展检测"。

70. 多 Agent 什么时候是刚需、什么时候是过度设计？判断标准是什么？

直接答案：多 Agent 是用多个各司其职的 Agent 协作完成复杂任务。常见模式：编排器 + 专家子 Agent（Supervisor 模式）、点对点交接（swarm）、层级分治。

什么时候需要：任务可清晰分解、需要专业化分工、需要并行、单一上下文装不下。

什么时候不要：简单任务用多 Agent 是过度设计——每个 Agent 都乘倍成本，还引入通信开销和误差传递。

知识点讲解：

判断标准：先问"单 Agent 能否解决"，多 Agent 是最后手段而非默认。
多 Agent 的隐藏成本：
1. 成本线性放大（每个子 Agent 都消耗 token）。
2. 通信开销（Agent 间传递信息有损）。
3. 误差传递（上游 Agent 出错，下游全错）。
常见模式：Supervisor（中心路由）、swarm（点对点交接）、层级（分治递归）。
面试金句："多 Agent 是最后的选择，不是炫技。每个 agent 都乘倍成本。"

71. 何时需要人工审批？怎样避免审批恢复后重复执行？

直接答案：人工审批适合尚未授权、影响大或难恢复的动作；是否需要逐次审批，要综合现有授权、数据敏感性、影响范围、可逆性判断，不简单按读写划分。

读取私密文件并发送给第三方可能很敏感（虽是"读"也要审批）。
已授权的小范围本地修改可以自动完成（虽是"写"也可免审批）。

知识点讲解：

审批的正确实现：在副作用之前持久化待执行操作、参数摘要、授权主体和有效期；审批后核对参数与上下文未变，再用幂等键执行。
防重复执行（关键）：恢复检查点可能重放节点，不能因此重复付款或发送——必须用幂等键保证"同一次审批只执行一次"。
明确的分支：拒绝、超时、过期、参数变更都需要明确处理分支，不能静默。
职责分离：模型负责提出候选动作，可信执行层负责检查授权与调用——模型不能自己批准自己。

参考：LangGraph interrupts。

72. Agent 的工具调用失败了怎么处理？错误怎么回传？

直接答案：工具失败要把错误信息结构化回传给模型，让它据此调整，而不是静默吞掉。

处理：

捕获异常，把错误以 tool 角色消息回传（含错误原因）。
模型据错误调整策略（换参数、换工具、或放弃）。
设重试上限，避免"失败→重试→失败"死循环。
仍失败则降级（明确告诉用户做不到）。

知识点讲解：

关键：错误信息要喂回给模型，模型才知道错在哪，否则会重复犯错。
区分错误类型：
- 可重试错误（超时、限流、临时故障）→ 退避重试。
- 不可重试错误（参数错误、权限不足、资源不存在）→ 反馈给模型改参数或放弃。
错误回传的格式：结构化（错误码 + 原因），比纯文本更易被模型理解。
降级路径：多次失败后明确告知用户"无法完成"，而非无限循环。
面试加分点：能说出"错误回传 + 重试上限 + 降级兜底"，并区分可重试/不可重试。

73. Agent 的上下文会越滚越大，怎么管理？（衔接分类 7）

直接答案：Agent 多轮工具调用后上下文暴涨，管理手段（详见分类 7）：

摘要/压缩：旧轮次压缩成摘要。
工具输出即时压缩：长结果先摘要再进上下文。
滑动窗口：只保留近期原文 + 置顶保护关键指令。
分层会话：大任务拆小任务，只传结果不传过程。

知识点讲解：

核心：上下文管理是 Agent 工程化的命脉——跑 10 轮没事、跑 50 轮就发疯。
工具输出是隐性膨胀源：一次搜索返回几千 token，几轮下来上下文就爆了，必须即时压缩/裁剪。
压缩优先级：原文 > 紧凑化 > 摘要（摘要有信息损失）。
过程 vs 结果：子任务的中间过程不需要全部保留，只传结果，能大幅省上下文。
详见分类 7 专门展开。

74. ReAct 的 "Thought" 和 CoT 有什么区别？它们各自解决了什么问题？

直接答案：两者都让模型"显式写出推理"，但目的和位置不同：

CoT（思维链）：在单次回答内，让模型把中间推理步骤写出来再给答案。目的是提升推理正确率（给模型更多计算量 + 让错误可见）。是"一次调用内的推理展开"。
ReAct 的 Thought：在多轮循环中，每一步行动前写下的思考。目的是决定"下一步做什么"（该调哪个工具、该不该停），并让决策过程可审计。是"循环中的决策步骤"。

区别：CoT 是"想清楚再回答"，Thought 是"想清楚再行动"——一个服务"答案质量"，一个服务"行动决策"。

知识点讲解：

两者可叠加：一个 ReAct 循环里的某一步，内部可以用 CoT 做深度推理。
Thought 的工程价值：让 Agent 的决策可观察、可调试——出了错能定位是"哪一步想错了"。
代价：Thought 多消耗 token，简单任务不需要显式 Thought。
加分点：能区分"推理链（CoT）"和"决策步（Thought）"这两个易混概念。

75. 并行工具调用（Parallel Tool Calls）怎么做才真正省延迟？有哪些坑？

直接答案：并行工具调用让模型在一次响应里请求多个工具，你的代码并发执行，从而把多轮往返压成一轮。但"并行"本身有讲究：

关键坑（最常见）：模型发出 N 个并行 tool_calls 后，如果你在代码里用 for 循环 await 逐个执行，等于没并行——这是"以为并行了、实际还是串行"的头号原因，很多团队因此看到零延迟收益。

正确做法：

用 asyncio.gather / 并发线程池真正并发执行，而非顺序 await。
只对"无依赖"的工具并行；有依赖的（B 需要 A 的输出）必须串行。
结果回传要按 tool_call_id 精确配对，不能只按顺序。

知识点讲解：

收益要实测：只有无依赖的任务才适合并行；收益受时长差异、限流及汇总开销影响，不能假设一定省时间。
跨厂商语义差异（静默坑）：OpenAI 默认开并行（parallel_tool_calls），Anthropic 用多个 tool_use 块，Gemini 支持"组合式调用"（一次里做有依赖的连续调用）。跨厂商切换时这些差异会静默出错。
质量权衡：并行有时会轻微降低紧耦合工具链的推理质量——所以要用评测集对比"并行 vs 串行"，而非默认开并行。
加分点：能说出"并行要真并发执行 + 无依赖才并行 + 用评测验证"。

76. 怎么评估一个 Agent 好不好？（衔接分类 10）

直接答案：Agent 是路径依赖的，不能只看最终输出。要分层评估（详见分类 10）：

会话层：任务完成率。
轨迹层：决策序列是否合理（有没有绕路、死循环）。
节点层：每个动作的精度（工具选对没、参数准不准）。

知识点讲解：

核心：Agent 失败常是"工作流某环节断裂"，而非"一个坏答案"。只看最终结果会漏掉"结果对但过程错"（如暴力试错撞对）的情况。
评估信号要挂到 trace 上：把每层评估结果关联到具体轨迹，才能归因"哪一步出了问题"。
过程质量 ≠ 结果质量：一个 Agent 可能结果正确但绕了远路（成本高）、或结果错误但过程看似合理（难以发现）。
详见分类 10 展开。

77. Agent 的"权限"怎么控制？为什么写操作要审批？

直接答案：权限由执行层按授权范围、数据敏感性、对外影响、可逆性与额度控制，不能只按读/写二分。

读取私人文件或把内部内容传给外部搜索也可能越界（"读"但敏感）。
已明确授权、可恢复的练习目录写入可以自动执行（"写"但无害）。
删除生产数据、付款、外发信息需要满足具体授权与审核策略。

知识点讲解：

权限控制的落地：工具白名单、资源路径限制、短期凭证、审计记录；超出策略边界才升级审批。
模型不能管理自己的权限：提示词里"你是只读助手"不是访问控制，真正的权限在工具层的凭证和路径限制上。
最小权限原则：每个工具只授予完成任务所需的最小权限，而不是一把"万能钥匙"。
审计：所有敏感操作留痕，便于事后追责和复盘。

78. 模型会"幻觉式"调用不存在的工具或捏造参数，怎么从源头和执行层双重防御？

直接答案：幻觉式工具调用指模型调用不存在的函数、或捏造不存在的参数。原因是模型对工具的理解有偏差或"脑补"。

防：

工具 schema 清晰：名称、描述、参数写准，让模型不乱猜。
执行层校验：函数名是否存在、参数是否合法，用代码校验。
失败反馈：校验失败把错误回传，让模型修正（限一次）。
降级：仍失败则明确报错或降级，而非死循环。

知识点讲解：

核心：永远不要信任模型的工具调用输出，执行层必须独立校验。
"稳定捏造"问题：模型可能"稳定地"捏造某个参数（每次都错同一个），重试无效——要靠源头约束 + 代码兜底，而非无限重试。
双层防御的分工：schema/描述是源头（降低捏造概率），执行层校验是兜底（保证不执行非法调用）。
Schema 校验 vs 业务校验：Schema 保证参数类型对，业务校验保证参数值合理（如订单 ID 存在、金额为正）。
面试加分点：能说出"代码校验是硬约束，prompt 是软约束"。

79. Agent 编排器该不该用 LLM 当调度核心？确定性和智能怎么分离？

直接答案：可以让 LLM 提出任务分解、路由或重新规划，但可信执行控制应由确定性代码负责。

例如模型提出"同时查询两个数据源"，调度器验证工具、权限、参数和预算后执行；结果写入持久状态，最终是否完成由任务契约和验证器决定。模型输出"已完成"不能绕过失败检查。

知识点讲解：

建议 vs 执行权的分离：LLM 负责"建议怎么做"（智能），代码负责"能不能做、做得对不对"（确定性）。模型只能提建议，不能直接行使执行权。
Orchestrator-workers 是可用模式：编排器（LLM）拆解任务、分派，workers（工具/子 Agent）执行，但权限边界、状态转换条件、预算上限必须可检查。
为什么不能让 LLM 当"可信调度核心"：LLM 输出不确定、可被注入诱导，把权限和状态机交给它会引入不可控风险。
计划可动态变化，约束不可变：计划可以随执行调整，但权限、预算、验收条件是硬约束。

参考：Anthropic Building Effective Agents。

80. 一个 Agent 项目，你怎么从 0 设计到上线？

直接答案：完整 Agent 项目设计，五步：

明确目标与边界：Agent 做什么、不做什么，定义完成标准（Definition of Done）。
拆解任务：能否单 Agent？还是多 Agent？画依赖关系图。
设计工具与权限：需要哪些工具、读写分级、写操作审批、权限边界。
设计护栏与记忆：步数预算、上下文管理、状态持久化、成本上限。
评估与迭代：分层评估、trace 可观测、bad case 回流（详见分类 10）。

知识点讲解：

核心：从"会做"到"能判断什么是对的"——验收门禁、可观测、评估闭环是生产级 Agent 的标志。
Definition of Done 的重要性：没有明确完成标准，就无法判断 Agent 成功还是失败，也无法做自动化验收。
护栏要前置设计：步数/成本/权限这些硬约束应在架构阶段就设计，而非上线后补。
可观测是前提：没有 trace，出了问题无法定位、无法迭代。
面试加分点：能完整串起"目标→工具→护栏→评估"这条主线，并强调"验收门禁 + 可观测 + 评估闭环"。