标签题目
AI Agent相关面试题第 2 页
AI 生成代码进入工程仓库前，如何用沙箱分支、最小改动范围、测试和 review 防止污染主分支？
这题考 AI 生成代码的分支治理和合入门禁。优秀回答要把主分支保护、沙箱隔离、diff 范围、自动化检查、人工 review、回滚审计串成一条工程流程。
Agent 服务中如何拆分模型调用、检索、审计落库和消息消费线程池，避免局部抖动拖垮全链路？
这题考 Agent 后端稳定性，不是普通线程池参数背诵。高质量回答要按任务类型隔离资源、设置队列和超时预算、做背压降级，并用指标证明局部抖动不会拖垮全链路。
高风险在线环境中的 Agent 异常管控体系应如何设计，覆盖权限分级、执行隔离、熔断止损和审计追踪？
这题考的是高风险在线 Agent 的工程治理能力，重点不是说模型更聪明或加人工确认，而是把权限、工具、执行环境、熔断止损、可观测性和审计恢复设计成一套闭环。
Agent 的 think-execute 循环如何控制规划路径，避免偏离业务预期或无限循环？
这题考 Agent 循环规划的可控性，重点是说明为什么需要 think-execute，以及如何用目标约束、状态机、校验器、评估器、停止条件和测试回放确保路径不跑偏。
同题还出现在 1 个公司岗位
AI 产品经理如何区分 Agent、RAG 和 Function Calling，并判断它们适合哪些产品场景？
这题考的是能否把大模型技术概念转成产品场景判断：RAG 解决知识来源和可追溯，Function Calling 解决外部动作和结构化能力接入，Agent 解决多步骤目标拆解和自主执行。
把 Skill 放进 Agent 沙箱后，主 Agent、Skill 运行时和文件系统之间应如何通信，并怎样做最小暴露和渐进式披露？
这题考 Agent 工程里的沙箱通信边界：不能让 Skill 直接拿到宿主进程和完整文件系统，而要用受控协议、能力句柄、文件视图和审计链路把调用、数据和权限拆开。
Agent 上下文压缩应该在什么时候触发，如何在 token 预算、信息损失和任务连续性之间取舍？
这题考上下文压缩的运行时策略：触发点不能只看 token 快满，而要结合任务阶段、信息密度、工具结果、记忆状态、失败风险和可恢复性来决定。
同题还出现在 1 个公司岗位
Agent 使用滑动窗口摘要时，旧摘要应逐步合并还是分段保留，如何控制信息遗失、冲突和可追溯性？
这题考滑动窗口摘要的状态维护策略：合并摘要更省上下文，分段摘要更可追溯，工程上通常需要分层结构而不是二选一。
Agent 如何从对话中更新向量记忆库里的用户画像，避免脏记忆、过期记忆和隐私风险？
这题考 Agent 长期记忆的写入路径：从对话提取用户画像不能直接整段入库，而要做候选抽取、确认、结构化、去重、过期、隐私过滤和可撤回治理。
大模型 Function Call 为什么会产生工具调用幻觉，工程上如何用 schema、权限、校验和反馈闭环降低误调用？
这题考 Function Call 的工程治理能力：工具调用幻觉不只靠 prompt 解决，还要靠工具契约、调用门禁、参数校验、执行反馈、回退策略和评测闭环共同降低。
同题还出现在 3 个公司岗位
AI Coding Agent 从用户输入到完成任务的完整链路是什么，如何经过上下文构建、计划、工具调用、代码修改和验证？
这题考的是 AI Coding Agent 的端到端运行时理解：候选人要能把自然语言需求如何变成可验证代码改动讲清楚，包括上下文、计划、工具、修改、测试和回滚闭环。
AI Coding Agent 如何从人工逐步确认切换到自主执行，权限、审批策略、风险护栏和回滚机制应如何设计？
这题考 Agent 自主化的安全工程：不是简单关闭确认按钮，而是用风险分级、最小权限、策略审批、沙箱执行、自动验证和回滚审计来决定哪些动作可以自动做。
同题还出现在 1 个公司岗位
Agent 的计划模式是什么？如何把用户目标拆成步骤、工具调用和可恢复执行状态？
这题考 Agent 运行机制：计划模式不是让模型多想一会儿，而是把开放目标转成可执行、可观测、可重试、可恢复的任务状态机或工作流。
同题还出现在 1 个公司岗位
Agent 调用服务端 API 工具的完整流程是什么？如何完成参数生成、鉴权、执行、错误处理和结果回填？
这题考 Agent 工具调用的工程链路：模型通常不直接访问业务 API，而是由宿主系统基于工具 schema、权限、参数校验、执行器、错误处理和结果回填来完成闭环。
同题还出现在 2 个公司岗位
Agent 的 thinking 阶段如何判断该调用工具还是直接回复，如何设计决策信号和安全约束？
这题考的是 Agent 运行时决策设计：候选人要能说明什么时候直接回答、什么时候调用工具、什么时候追问，以及如何用置信度、权限、安全和回归评估约束决策。
同题还出现在 1 个公司岗位
MCP、Function Call 和 A2A 在 Agent 系统中分别解决什么边界，如何协同？
这题考 Agent 系统的协议和责任边界。Function Call 解决模型到宿主工具调用意图的结构化表达，MCP 解决宿主和外部工具/资源服务之间的标准化连接，A2A 解决 Agent 与 Agent 之间的任务委托和协作。三者层级不同，不能混成同一个概念。
Agent 微调中如何选择和清洗训练样本，哪些样本质量问题最容易改变模型行为？
这题考 Agent 微调数据的样本选择与清洗能力。与普通 SFT 不同，Agent 样本不仅有问答文本，还包含意图、计划、工具选择、参数、工具结果、状态变化、安全边界和最终回复。回答要说明哪些样本值得训练、哪些噪声会改变模型行为，以及如何用指标验证。
同题还出现在 1 个公司岗位
从用户行为日志抽取 Agent 训练对话时，如何做归一化和事件抽象？
这题考从用户行为日志构造 Agent 训练对话的能力。关键不是把日志拼成聊天记录，而是做会话切分、事件抽象、状态归一、隐私脱敏、目标推断、轨迹标注和质量过滤，让低层行为事件变成可训练、可审计、可评估的 Agent 对话样本。
Spring AI Alibaba Graph 的底层原理是什么，图式编排如何表达 Agent 节点、状态流转、条件分支和工具调用？
这题考察对图式 Agent 编排的理解，重点是状态、节点、边、条件路由、工具调用、失败处理和可测试性，而不是背某个版本的 API。
ReAct 的思考-行动-观察循环如何驱动 Agent 工具调用，和普通 CoT 有什么区别？
这题考的是候选人是否理解 ReAct 把模型推理和外部行动交织起来：模型不是一次性输出答案，而是在思考、选择工具、观察结果、继续推理的闭环中逐步完成任务；它和普通 CoT 的关键区别是能通过工具调用改变外部状态并用真实观察修正推理。
Agent 工具调用失败后，如何通过 trace 定位是意图识别、工具选择、参数生成还是工具服务本身的问题？
这题考的是 Agent 工具调用失败后的分层定位能力。好的回答不能只说看日志，而要把一次请求拆成意图识别、工具检索与选择、参数生成、执行前校验、工具服务调用、结果解释几个 span，并让每一层都有输入、输出、置信度、候选集、错误码、耗时和重试信息。定位时先判断用户意图是否被理解错，再看工具候选和最终选择是否合理，然后检查参数 schema、枚举、时间范围、权限上下文等是否正确，最后才归因到工具服务的网络、鉴权、超时、限流或业务错误。
Agent 系统可观测性平台应记录哪些 trace，LangSmith 和 Langfuse 如何用于调试与评估？
这题考 Agent 可观测平台该记录什么，以及如何把 trace 用于调试和评估。好的回答要覆盖请求级 trace、LLM 调用、工具调用、检索、记忆、planner、guardrail、人工反馈、成本延迟和评测结果，并说明 LangSmith 与 Langfuse 都可以承载调试和评估闭环，但选型应基于技术栈、部署合规、数据治理、评测流程、成本和集成方式，而不是简单说谁更强。
如果项目要基于 Claude Code 这类现成 Agent 做领域适配，如何设计数据边界、工具接入、RAG、评测和监控？
这道题考察如何把现成 Coding Agent 或通用 Agent 平台做成某个业务域可用的工程系统。回答不能停留在“加提示词”或“接几个工具”，而要围绕数据边界、权限隔离、工具契约、领域知识 RAG、任务流程、评测集、灰度发布、监控和人工接管设计。重点是让通用 Agent 只在授权数据和明确工具能力内行动，用可回放、可评测、可审计的方式逐步扩大自主能力。
在现有 LangGraph Agent 上新增功能时，如何设计节点、边、state schema、工具注册和回归测试？
这题考的是把 Agent 功能扩展做成可维护的状态机工程，而不是在一个大 prompt 或一个大节点里继续堆逻辑。高质量回答应说明如何先界定新功能的触发条件和输出契约，再决定是否新增节点、边、state 字段和工具，并用可回放测试证明新增路径没有破坏原有 Agent 行为。
Agent 项目中的 harness engineering 是什么，如何支撑工具模拟、回放、评测、回归和线上前验证？
这题考的是 Agent 工程里的验证基础设施意识。harness engineering 不是写几个单测，而是为不稳定的模型输出、外部工具、副作用和多轮状态机建立可控运行环境，让开发者能模拟工具、回放真实轨迹、做离线评测、跑回归并在上线前发现风险。
当 Agent 有 100 个 Tool 时，如何做工具分组、动态子集检索、schema 治理、监控和 meta-tool/Skill 收口？
这题考的是大规模工具接入后的 Agent 治理能力。100 个 Tool 不能简单全部塞进模型上下文，否则会带来选择混乱、token 成本、schema 冲突、误调用和监控不可解释。好的回答应从工具分类、检索式候选集、契约治理、调用观测和能力收口几层展开。
同题还出现在 1 个公司岗位
内容安全类 Agent 需求如何从“万能问答”拆成可评测的原子能力、输入输出契约和停止条件？
这题考的是把模糊的内容安全 Agent 需求工程化。不能把它做成什么都能问、什么都回答的聊天助手，而要拆成可独立评测的能力单元，例如分类、证据抽取、规则匹配、风险解释、处置建议和人工复核触发，并为每个能力定义输入、输出、置信度和停止条件。
多 Agent 协作时，Agent 之间如何传递状态、消息和工具结果，并避免并发读写冲突？
这道题考察多 Agent 系统的状态建模、通信协议、工具结果传递和并发一致性设计。好答案不能停留在 Agent 之间互相发消息，而要区分临时对话消息、可持久化任务状态、不可变工具产物和需要事务保护的共享资源。回答边界应覆盖消息队列或事件总线、共享状态存储、编排器协调、版本号或乐观锁、文件和数据库写入隔离、幂等重试、冲突检测，以及如何用日志和压测证明没有丢消息、重复执行和覆盖写。
Agent 中 Function Call、MCP 和 Skill 的工具描述上下文占用有什么差异，如何降低 token 成本？
这道题考察对 Agent 工具接入方式和上下文成本的工程理解。好答案要区分 Function Call 是模型请求内的工具 schema，MCP 是客户端和外部工具服务器之间的协议，Skill 是把说明、脚本和资源按能力打包并按需加载的机制。回答不能简单说 MCP 一定比 Skill 大，而要说明上下文占用取决于客户端暴露了多少工具描述、schema 是否冗长、是否做动态路由和懒加载。高质量答案还应给出降低 token 成本的方法，包括工具分层、候选工具筛选、描述压缩、结果引用、prompt caching 和按任务加载。
Agent 的 self-refine 自我修正如何处理 API 返回字段缺失、冗余或结构不符合预期？
这道题考察 Agent 自我修正是否能和工程化 API 契约治理结合起来。好答案不能把 self-refine 说成让模型再想一遍，而要说明先用确定性 schema 校验发现字段缺失、冗余字段、类型错误和结构不匹配，再根据错误类型决定丢弃、补默认值、结构化转换、重调 API、降级或交给模型生成修复计划。边界是不能让模型凭空编造缺失事实；所有修复都要可追溯、有限重试、重新校验，并用错误率、修复成功率和幻觉字段率验证效果。
Agent 工具调用训练中，如果一个 query 有多个可用工具，如何构造样本让模型学会工具选择偏好？
这道题考察的是 Agent 工具调用训练里的偏好学习，而不是简单判断某个工具能不能用。好答案要说明：当多个工具都可完成同一 query 时，训练样本不能只保留一个正确 tool call，而要把候选工具、选择理由、约束条件、反事实样本和评价指标都设计出来，让模型学会在成本、延迟、稳定性、精度、覆盖范围和任务阶段之间做取舍。
Agent 设计中为什么要区分自然语言对话状态和结构化执行状态，分别存什么？
这道题考察 Agent 状态管理的边界意识。高质量回答要把自然语言对话状态和结构化执行状态分开：前者服务于模型理解上下文、用户意图和交互语义；后者服务于工作流执行、工具调用、恢复、审计和一致性控制。两者相互映射但不能混成一大段聊天记录，否则系统会难以恢复、难以测试，也容易产生幻觉状态。
开发 MCP 服务时，如何设计 resources/tools/prompts、输入输出 schema、权限和可观测性？
这道题考察的是 MCP 服务的能力建模和治理能力，而不是会不会写一个 HTTP endpoint。好答案要从 resources、tools、prompts 三类能力暴露开始，定义清晰的输入输出 schema、权限和错误语义，再补上发现机制、版本兼容、超时重试、可观测性、回放和审计，保证 Agent 能安全、稳定、可追踪地使用 MCP 服务。
RAG 和 Embedding 分别是什么，在大模型应用中各自解决什么问题？
这道题看似是定义题，实际考察大模型应用的知识接入链路。Embedding 是把对象映射成可计算的语义向量，RAG 是检索增强生成架构；RAG 常用 embedding 做召回，但不等于向量库加大模型，还需要文档切分、索引、混合检索、重排、权限、引用、拒答、评估和监控。
Agent 中输入特征和记忆模块有什么区别，如何分别建模当前请求状态和跨轮上下文？
Agent 的输入特征描述当前请求状态，记忆模块保存跨轮和跨会话的上下文。二者的核心区别在生命周期、更新方式、存储介质和使用目标：输入特征偏实时、短暂、结构化，记忆偏持久、可检索、需要治理。
业务 Agent 的评测流程应该怎么设计？如果工具被多调用但不影响最终结果，应该用哪些指标描述冗余工具调用？
这题考业务 Agent 评测，不是简单统计工具调用次数。关键是判断某次工具调用是否带来新增信息、状态推进或风险降低，再用 trace、反事实回放和人工标注校准冗余工具调用指标。
MCP 接入多个测评工具时，如果不同工具对同一问题返回格式不统一，应该如何设计统一输出协议或适配层？
这题考 MCP 多工具输出治理。多个 MCP 工具返回格式不统一时，应在工具和 Agent Runtime 之间加适配层，统一 envelope、内容块、结构化数据、错误协议、元数据、版本和审计，而不是让模型解析各类私有格式。
Agent 工具调用限制中间件应如何设计，才能约束候选工具范围、调用预算、权限校验和循环停止条件？
这题考 Agent 工具调用限制中间件。重点是 runtime/executor 如何通过 allowlist、预算、权限、参数校验、循环检测和停止条件约束工具调用，而不是只在 prompt 里提醒模型少调用。
Agent 系统里上下文缓存有什么价值，如何用它处理频繁复用的系统指令并降低冗余上下文成本？
这题考 Agent 上下文缓存和 prompt caching。核心是把稳定系统指令、工具协议和安全策略作为可缓存前缀，把用户问题、检索材料和工具结果作为动态上下文，并通过版本、权限作用域和失效机制避免缓存污染。
Agent 开发框架通常由哪些核心组件组成，Planner、Memory、Tools、Executor 和 Evaluator 分别负责什么？
这题考察候选人是否能把 Agent 从“调用大模型的应用”拆成可工程化的运行系统。好的回答应说明 Planner 负责把目标拆成步骤，Memory 负责保留和检索上下文，Tools 负责连接外部能力，Executor 负责按计划执行并处理状态，Evaluator 负责判断结果质量和是否需要重试、修正或终止。重点不是背组件名，而是讲清楚组件之间的数据流、控制流、失败兜底和可观测性。
Agent Skill 如何用渐进式披露按需加载能力说明、执行步骤和工具细节？
这题考察 Agent Skill 的核心机制，以及如何通过渐进式披露降低上下文负担。Skill 不是简单工具函数，而是一组可被 Agent 发现、选择和执行的能力包，通常包含能力说明、适用条件、输入输出、执行步骤、工具依赖和失败处理。渐进式披露的关键是先暴露轻量索引和选择信号，只有命中时再加载详细说明、示例和执行细节。
多工具 Agent 如何设计工具选择与调用调度链路，并在超时、参数错误或工具失败时做 fallback？
这题考察多工具 Agent 的工程调度能力。好的回答不能停在“让模型选择工具”，而要说明工具注册、候选召回、参数生成、权限校验、执行编排、状态记录、错误分类和 fallback 策略。面试官重点看你是否能把不稳定的 LLM 工具调用变成可观测、可恢复、可降级的业务链路。
Agent 评估体系应该覆盖哪些维度，如何分别衡量规划能力、任务成功率和幻觉率？
这题考察 Agent 评估体系设计。好的回答要把评估拆成任务成功、规划质量、工具调用质量、事实一致性、幻觉率、安全合规、成本延迟和用户体验等维度。规划能力和幻觉率不能都靠主观打分，应该结合离线任务集、步骤级 trace、工具结果、证据对齐、人工标注和线上指标。
可中断的 Agent 系统如何设计，怎样保存执行状态、恢复任务并处理用户打断？
这题从后端视角考察可中断 Agent 的状态机、持久化和恢复设计。好的回答要说明 Agent 执行不是一次同步请求，而是可暂停、可恢复、可取消、可重试的长任务。核心包括任务状态模型、步骤 checkpoint、幂等工具调用、用户打断语义、恢复策略、并发控制和可观测性。
Agent 工具服务为什么要独立部署并注册到 Nacos，而不是直接用 MCP 暴露工具？
这题考 Agent 工具服务的工程化部署边界：Nacos 解决服务发现和治理，MCP 解决模型侧工具协议，二者不是同一层能力，不能简单互相替代。回答时要强调在已有微服务治理体系下，Nacos 更适合管理真实工具服务的实例、健康、配置和流量，MCP 更适合统一工具契约、schema 和 Agent 侧调用方式。
蓝心小 V 这类手机 AI 智能体如何做竞品分析，并建立产品评估维度？
这题考手机 AI 智能体的产品竞品分析和评估体系，重点是围绕手机入口、系统上下文、多模态、跨 App 行动和可信执行建立维度，而不是泛泛比较聊天模型。回答不能编造 vivo 内部路线图或真实指标，应基于公开可观察的产品能力和方法论展开。
如何理解小爱同学这类 AI 助手产品的用户价值、核心场景和交互入口？
这题来自“小爱产品”的理解，且上下文提到手机端入口交互和终端展示，所以答案要围绕 AI 助手的产品本质：它不是单一 App，而是跨设备、跨系统能力的交互层。用户价值可以拆成三类：降低操作成本、连接多设备场景、提供个性化和主动辅助。核心场景包括手机系统任务、智能家居控制、信息查询与内容服务、车载/穿戴/音箱等多终端协同、无障碍和老人儿童场景。交互入口要按主动/被动、语音/触控、前台/后台分层：唤醒词、长按电源键或快捷键、桌面组件、锁屏、负一屏/搜索、耳机和音箱、车机、智能家居面板。终端展示不应只靠语音播报，而要有卡片、确认页、多轮澄清、执行反馈和可撤销机制。
构建 AI Agent 时，Memory 机制通常如何分层设计，短期上下文、长期记忆和检索注入分别解决什么问题？
这题考察的是候选人是否理解 Agent Memory 不是一个简单向量库，而是一套分层状态管理和检索注入机制。回答要区分短期上下文、工作记忆、长期记忆、外部知识检索和写入更新策略，并说明每层解决的问题、成本权衡、失效模式和评估方法。