AI 应用 / Agent 开发工程师
2026 面试题库与学习路线

参考回答

Chatbot 是"用户输入 → LLM 推理 → 输出文本"的单轮映射；Agent 是"推理 → 决定用什么工具 → 执行 → 观察结果 → 决定下一步 → 循环直到达成目标"的自主系统，具备感知（Perception）、规划（Planning）、行动（Action）、记忆（Memory）四种能力。

加分点：自主性是双刃剑——给太多自主权可能产生不可预期操作，给太少就退化成 Chatbot；真正的工程挑战是设计"安全的自主边界"。^[2]

参考回答

Agentic Loop 是 Agent 的工作流水线。以"帮我退掉上周五买的书"为例：模型先判断要查订单（Think）→ 调用订单查询工具（Act）→ 发现书已发货不能直接取消（Observe）→ 再查退货政策 → 确认符合条件后创建退货单，每一步都在思考—行动—观察的循环中推进，直到目标达成。^[2]

回答时最好在纸上画出循环图，并指出循环必须有终止条件（目标达成 / 最大轮次 / 熔断）。

参考回答

ReAct = Reasoning + Acting，把推理（Thought）和行动（Action）交错，用 Observation 回灌结果。消息格式是工程落地的核心：

• 模型在 assistant 消息中输出结构化的工具调用请求（如 <tool_call> 或 OpenAI 的 tool_calls 字段）；
• 程序解析后执行真实函数，结果以 tool 角色（或约定的 <tool_response> / observation 消息）回传；
• 再把拼好的消息数组发回模型继续推理，形成闭环。

关键点：LLM 并不会真的执行工具，它只是按 schema 输出一段 JSON/结构化文本，执行与回灌完全由你的代码控制——角色与格式必须严格匹配各模型 API 的协议，否则模型会"失忆"或重复调用。^[2][4]

参考回答

• CoT（思维链）：让模型写出逐步推理过程，解决"推理能力"，但只能想、不能做；
• ReAct：推理与行动交错，解决"推理 + 行动"，能与外部世界交互；
• ToT（思维树）：同时探索多条推理路径并评估择优，解决"多路径探索"，代价是 token 与延迟显著上升。

升级动因：真实任务需要调用工具、获取外部信息，CoT 只在文本空间推理，会出现"想得很好但什么都没做"。可补充 ReAct 在 ALFWorld 等基准上相对纯推理有约 34% 的成功率提升。^[2]

参考回答（四类）

1. 死循环：Observation 不满足预期就反复重试同一工具；
2. 上下文爆炸：循环轮次过多，历史塞满上下文窗口；
3. 早停：未拿到关键信息就判定"任务完成"；
4. 过度思考：推理模型开启 extended thinking 后在 Thought 阶段消耗大量 token 钻牛角尖——生产中需设置 thinking.budget_tokens 上限，简单任务用 reasoning_effort: minimal。^[4]

参考回答

Workflow 的路径是预先编排好的（确定性 DAG），LLM 只填某个节点；Agent 的路径由模型在运行时动态决策（调哪个工具、何时结束）。工程原则：能用确定性工作流就不要交给模型决策——规则明确、可枚举的步骤（如固定格式转换、审批路由）用 Workflow；需要语义理解、开放域判断的节点才交给 LLM。

对"扣子（Coze）是 Agent 平台还是工作流平台"的稳妥回答：它两者都支持，大量实际应用以可视化 Workflow 为主、在关键节点挂载 LLM 决策，属于低代码 Agent / Workflow 混合平台。^[1]

参考回答（三层记忆）

• 工作记忆：当前任务状态与中间变量（如 DAG 执行状态）；
• 短期记忆：会话内上下文，用 messages + 滑动窗口 + 自动摘要（参考 Claude Code 的 /compact），并分层——项目级规则、用户偏好、会话上下文分开存储；
• 长期记忆：跨会话持久化，主流方案是向量库 + 时间衰减 + 重要性加权（Mem0 / Zep 等封装），辅以 SQLite 全文索引。^[2][4]

不能全塞的原因：长上下文存在 Lost in the Middle（中段信息利用率低）与 Context Rot（无关内容越多准确率越低），且延迟与成本随长度暴涨——主动剪枝比无脑堆砌效果好。

参考回答

• 分层压缩：早期轮次只保留摘要，近期轮次保留原文；工具返回结果先结构化提取再入库；代码 / 日志类只留 diff 与错误栈；
• 触发条件按 token 水位分级（如 50% 触发摘要、75% 触发激进剪枝），不同层压缩内容不同；
• 压缩必须保留任务目标、已做决策、未完成事项（handoff 三要素）；
• 异常兜底：压缩后若模型表现下降（如工具选择错误率升高），应能回滚到未压缩版本或对关键段落"解压重取"，并通过离线评测监控压缩损失。^[1]

参考回答

规划模块负责任务拆解与动态重规划：把复杂任务拆成有依赖关系的子任务，用 DAG 管理执行顺序；每个子任务执行后做状态校验，失败或发现新信息时触发重规划（Replan），而不是死守原计划。可用 Planner Agent 出计划、Executor Agent 执行、Critic 校验结果的结构，并为计划设置最大重规划次数。

参考回答

• 分工：按能力边界拆（如 Planner / Research / Code / Summary），每个子 Agent 有独立系统提示与工具集，避免工具重叠导致抢任务；
• 通信：通过共享状态（黑板模式）或结构化消息传递，只传结论 / 摘要而非全量上下文；
• 终止：由 Orchestrator 依据完成条件统一裁决，设全局最大轮次与预算；
• 防扯皮：DAG 去环、共享状态锁、调用链监控（检测 A→B→A 重复模式即熔断）。^[2]

参考回答

LangChain 是链式调用的组件库（模型、提示、检索器等），擅长线性流程；LangGraph 是面向有状态、可循环 Agent 的图编排框架——Node 是执行单元（一次 LLM 调用或工具执行），Edge（含条件边）决定流转路径，State 在节点间传递并合并的共享状态，配合 Checkpoint 实现持久化、断点恢复与人机协同（Human-in-the-loop）。

选型理由：业务需要循环、分支、回滚、人工审批等图结构时 LangGraph 更可控、可调试；AutoGen 偏多 Agent 对话、CrewAI 偏角色协作模板，灵活性与可控性各有取舍。务实回答还应包括"框架不满足时用自定义 Node / 直接手写状态机扩展"，并知道 2026 年厂商 SDK（Claude Agent SDK、OpenAI Agents SDK）也在崛起。^[1][4]

参考回答

Tool 是单一的、可执行的能力原子（一个函数 / 一次 API 调用），有明确输入输出 schema；Skill 是"模型按需加载的指令包 / 能力包"，通常包含操作指南、提示模板与一组工具的编排，采用渐进式披露（progressive disclosure）——平时不占上下文，命中场景才加载。两者互补而非替代：Skill 解决"模型知道什么时候、按什么 SOP 用工具"，Tool 解决"具体执行动作"。^[2][1]

参考回答

1. 用 JSON Schema 向模型声明工具（名称、描述、参数类型、枚举、示例）；
2. 模型根据意图输出结构化调用请求（函数名 + 参数 JSON）——它没有执行任何代码；
3. 客户端解析 JSON、做参数校验，调用真实函数；
4. 把执行结果以 tool 角色消息回填，模型继续推理或给最终答复。

schema 质量直接决定调用质量：描述含糊→选错工具；类型 / 枚举不全→参数错误。2026 年主流模型均支持并行工具调用（一次返回多个 tool_use 块，并发执行后批量回填，链路延迟可降至 1/N）。^[4]

参考回答

• Schema 设计：工具命名无歧义、职责单一不重叠；参数给类型、枚举、必填约束与 few-shot 示例；
• 参数错误：服务端用 Pydantic 等强校验，校验失败把具体错误信息结构化回传给模型自我修正（而非抛异常中断）；
• 执行失败：工具内 try-catch，返回 {"status":"failed","error_type":"Timeout","retry_after":5} 这类结构化错误；设硬超时（如 15s）与重试上限；
• 危险工具：不直接暴露给模型，高危操作经服务端策略层 / 人工确认；工具做分级权限与只读 / 写入隔离；
• 架构：工具经服务端统一注册与分发，不把内部接口裸暴露给模型，便于审计与限流。^[1]

参考回答

传统 Function Calling 有三大绝症：厂商绑定（各家工具定义语法不同）、静态配置（新增工具要改代码、重新部署）、无执行标准（超时、错误处理全靠硬编码）。

MCP（Model Context Protocol）把工具描述与执行分离：工具定义统一存在 Server 端，Client 通过标准协议动态发现并调用，LLM 只负责决策。更深一层的价值：把工具调用从"一次性编码"变成"可复用资产"——MCP Server 写一次，所有 Agent、项目、模型都能用，治理集中、审计可追溯，集成复杂度从 O(N×M) 降到 O(N+M)。

应能说出五大原语：Tools / Resources / Prompts / Sampling / Roots；并知道它已是 OpenAI、Google、Cursor 等全面采纳的事实标准。^[2][4]

参考回答

二者是分层协作而非竞争：MCP 是垂直连接——Agent 如何调用外部工具与数据（解决"我能用什么"）；A2A（Agent-to-Agent）是水平连接——Agent 之间如何互相发现、委托任务、交换结果（解决"我能和谁合作"）。一个完整系统里 A2A 负责任务在 Agent 间流转，每个 Agent 再通过 MCP 去落地具体工具操作。^[2]

参考回答

致命缺陷之一是 Context Poisoning（上下文投毒）：工具描述会被全量注入 Agent 上下文，恶意指令可借工具元数据操纵模型推理，OWASP 已将其列为 LLM 应用头号风险；有基准显示超 50% 的 agentic 任务存在注入漏洞。

三大攻击面：Context Manipulation（篡改工具描述）、Server-Side Injection（恶意 Server 注入）、Cross-Server Compromise（跨 Server 扩散）。

生产级防御：工具描述入库前审计与签名、权限最小化（默认只读、按需授权）、MCP 隧道加密、第三方 Server 白名单与沙箱隔离、敏感凭证不进 Agent 上下文而在网络边界注入。^[2]

参考回答（离线索引 + 在线问答两阶段）

• 解析与清洗：PDF / Word / 网页 Loader，去页眉页脚、表格 / 图片特殊处理，剔除冗余；
• 切分（Chunking）：按语义结构切而非只按固定 token，控制块大小与重叠（overlap），保留标题 / 条款编号等 metadata；
• 向量化与入库：Embedding 模型 + 向量库（Milvus / Qdrant / Faiss 等）；
• 检索：Query 向量化做 ANN 召回，常配 Query 改写、混合检索；
• 增强：召回片段拼接 Prompt，控制顺序（关键信息放头尾）与长度；
• 生成：LLM 基于上下文作答，带引用出处与"不知道就说不知道"的约束。^[3]

参考回答

必须能说清自己项目用的模型：例如 BGE-M3 / Qwen3-Embedding / text-embedding-3-large 等基于 Transformer Encoder（双塔 Bi-Encoder），输出固定维度向量（如 768 / 1024 / 3072），维度越高表达力越强但存储与检索成本越高，需按召回效果与成本权衡。

切片要结合业务语义：法律文档中"第三条第二款"与"第三条之二"含义不同，固定 512 token 切分会切断条款——应按标题层级 / 条款边界切，块间加 overlap，并把条款号、文档来源写进 metadata 用于过滤与溯源。^[1]

参考回答（按收益排序）

1. 混合检索：BM25（关键词精确匹配，对专有名词、编号友好）+ 向量语义检索，结果融合（RRF）；
2. 两阶段召回 + Rerank：先用双塔 Bi-Encoder 粗排取 Top-20~50，再用 Cross-Encoder 交叉编码 Query 与文档精排取 Top-3~5——精度更高但计算贵 10–100 倍，所以只对小候选集做；Rerank 被普遍认为是成本最低、收益最高的优化手段；^[5]
3. Query 侧：改写、扩展、HyDE（假设答案嵌入）、多查询并行召回；
4. Chunk 侧：调整块大小与 overlap、父子索引（小块检索、大块喂模型）、metadata 过滤；
5. Top-K 动态化：按问题复杂度或相似度阈值动态决定取几条，避免噪声片段稀释上下文。

参考回答（增量更新）

• 给每个文档 / chunk 存内容 hash 与版本号，更新时计算 hash 比对，只处理变更部分；
• 关键坑点：文档内容变化后 chunk 边界会漂移，不能只"替换变化 chunk 的向量"——稳妥做法是以文档为单位"先删后增"（删除旧版本全部 chunk，重新切分入库），或用稳定的语义锚点切分降低边界漂移；
• 删除与写入放在同一事务 / 带版本切换（蓝白索引），避免更新中间态被检索到；
• 配套版本控制与回滚：错误文档入库后可按版本撤回，并保留操作审计。^[1]

参考回答

• 内容冲突：用 metadata 记录来源、生效时间、权威等级；检索后做冲突检测，优先高权威 / 最新版本，在答案中并列展示分歧而不是让模型私自裁决；
• 超范围问题：设置相关性阈值，召回分数过低则走"拒答 / 澄清 / 转人工"分支；可让模型先判断是否需要补充信息并向用户反问；多轮澄清仍无法解决则升级人工，而不是硬编答案。^[1]

参考回答

传统 RAG 是固定的"检索一次 → 生成"管线；Agentic RAG 让 Agent 自主决定是否检索、检索几次、怎么改写查询、是否切换数据源 / 工具，形成多轮检索与策略调整闭环。Query Rewrite 本身只是固定增强，只有当"是否改写、如何改写"由 Agent 根据中间结果动态决策时才算 Agentic。

检索失败的策略：换关键词 / 子查询分解重试 → 切换数据源（向量库→BM25→联网搜索）→ 放宽过滤条件 → 仍失败则如实告知并澄清问题。代价是 token 与延迟上升，需要设置检索轮次上限与成本监控。^[1]

参考回答（三层评测）

• 检索层：Recall@K（标注的相关文档是否出现在前 K，分子=命中相关文档数、分母=全部相关文档数）、Precision@K、MRR、Hit Rate、NDCG；
• 生成层：忠实度 / Faithfulness（答案是否忠于检索内容、有无外在幻觉）、答案相关性、上下文利用率；可用 RAGAS 等框架或 LLM-as-Judge；
• 端到端：标准答案匹配、人工评分、业务指标（解决率、转人工率）。

关键纪律：评测集要够量且按问题类型 / 难度分层抽样；必须有 baseline（朴素切片 + 单路向量检索）作对照，每次改动报相对提升，而不是只丢一个"Recall@5 = 0.81"；判断 LLM-as-Judge 本身的可靠性要看评委模型的一致性 / 与人工标注的吻合率。^[1][6]

参考回答

向量 RAG 按"局部语义相似"召回孤立片段，跨多个实体的关系链容易断；GraphRAG 先从语料抽取实体与关系构建知识图谱，多跳问题可沿图的边做结构化遍历与社区摘要汇总，擅长"A 和 B 通过 C 有什么关系"这类全局 / 关联推理，代价是构建与维护成本高。工程上常做混合：向量召回实体入口，再沿图谱扩展邻域。^[1]

参考回答（三层防御）

1. 工具层硬隔离：每次调用包 try-catch + 硬超时，返回结构化错误（错误类型、是否可重试、retry_after），而不是一段 error 字符串；
2. 推理层熔断：同一工具连续失败 N 次（如 3 次）、或检测到"调用→失败→再调用"重复模式 / 超过最大迭代次数，强制中断当前推理链；
3. 规划层自修正：失败后让 Agent 反思原因（参数错？工具选错？），换参数或换工具重试，即 Reflection Pattern；仍失败则降级（转人工 / 告知用户）。^[2]

参考回答（拆成三个问题）

• 依赖管理：无依赖的工具并行调用（利用模型一次返回多个 tool_use 块，客户端并发执行后统一回填）；有依赖的编码为 DAG，按拓扑序执行；
• 超时控制：每个工具调用前设定硬超时阈值（MCP 生态通常期望 7–10 秒返回，可设 15s），超时立即中断并返回结构化超时信息；
• 异常熔断：连续失败达阈值或检测到重复调用模式即熔断；整体采用异步编排 + 资源调度，单工具失败走降级分支而不是让整轮对话崩溃。^[2]

参考回答

把对话消息、任务状态（DAG 各节点状态）、中间产物与 checkpoint 持久化到数据库；基于 LangGraph 等框架的 Checkpointer 可在每个节点后落盘，恢复时从最近 checkpoint 重建 State 继续执行，支持断点续跑、时间旅行调试与人机审批后恢复。长任务用事件溯源（event log）记录每步动作，保证可重放、可审计。

参考回答

• 流式输出（SSE）降低首字延迟 TTFT；
• Prompt Caching：system prompt、工具定义、长文档前缀开启 KV Cache 持久化，命中后延迟可降约 80%、成本降约 90%；注意缓存前缀里不要放时间戳 / 随机 ID；^[4]
• 模型分级：简单节点用小模型、复杂节点才用大模型 / reasoning，按任务设置 reasoning_effort；
• 并行与缓存：工具并行、语义结果缓存；
• 服务化：FastAPI + vLLM / SGLang 自托管开源模型，配合 K8s 弹性扩缩、限流与排队；
• 预算控制：每会话 / 每任务设 token 与轮次预算。

参考回答（端到端分层，建议边画边讲）

• 接入层：意图识别与权限校验，区分咨询 / 查询 / 办理类意图；
• 编排层：确定性流程（订单状态机：下单→发货→签收→售后期）用 Workflow；开放问答与异常分支交给 Agent 决策；
• 工具层：订单查询、退货政策 RAG、退货单创建、物流查询、优惠券发放等，写操作分级并要求确认；
• 数据层：政策知识库 RAG（含版本与生效时间）、用户画像与订单系统；
• 记忆：会话短期记忆 + 用户历史长期记忆；
• 安全与兜底：退款等高风险动作二次确认 / 规则引擎拦截，失败转人工；
• 评测：意图准确率、工具成功率、任务完成率、转人工率、CSAT 与成本 / 延迟看板。

参考回答

分层讲：端侧小模型负责意图理解、隐私敏感数据处理与离线兜底；云端大模型负责复杂规划与推理；工具层打通系统能力（通讯录、日历、支付等）并做权限沙箱；通过统一的任务调度与状态同步层连接端云。重点回答功耗、延迟、隐私（敏感数据不出端）、弱网降级与跨 App 动作的授权确认。^[1]

参考回答

根源是 Context Mixing：单一上下文窗口里模型无法可靠区分系统指令、用户指令与不可信外部数据，所以它比 SQL 注入更难，防御必须建在模型外部。四层体系：

1. 前置隔离：采用 Execute-Only 等架构，尽量不让 LLM 直接接触不可信数据（对外部内容先净化 / 沙箱处理）；
2. 工具调用审查：在工具执行边界部署独立的语义审计层，拦截异常调用；
3. 影响溯源：标记并追踪不可信内容如何传播到最终决策（数据流标签）；
4. 权限最小化：静态最小权限 + 凭证移出 Agent，改为网络边界注入。^[2]

参考回答（四层，不是"加个确认弹窗"）

1. 确认层：高危操作执行前经独立安全分类器审查（分类器脱离 Agent 上下文运行，只看用户消息与调用请求，不看工具结果，防止被注入带偏）；
2. 规则层：PreToolUse Hook 做确定性规则匹配，DROP TABLE、kubectl delete 等直接拒绝，不经过 AI 判断；
3. 权限层：Agent 不持有生产凭证，敏感凭证经 MCP 隧道在网络边界注入、按需短时授权；
4. 治理层：全量审计操作日志，异常行为实时熔断与告警。^[2]

参考回答

• 内在幻觉：检索结果里有正确信息，但生成内容与之矛盾（如检索是 91%，答成 95%）；
• 外在幻觉：生成了检索结果中根本不存在的内容。

治理组合拳：Prompt 强约束（"仅依据给定材料、无依据就说不知道"、要求引用出处）；提升检索质量与上下文组织；输出校验（事实比对、结构化约束、自检）；温度调低；必要时用微调让模型学会该领域的拒答边界；上线后用忠实度指标持续监控 Badcase 并回流。^[7]

参考回答（过程 + 结果 + 成本三维）

• 结果指标：任务成功率（端到端）、目标达成率、答案正确率；
• 过程指标：工具选择准确率、参数正确率、平均调用轮数、死循环 / 熔断率、人工干预率；工具调用能力可对标 BFCL（Berkeley Function-Calling Leaderboard）；
• 效率指标：平均延迟、token 消耗与单任务成本；
• 方法：构造贴近真实分布的评测集（τ-bench 式多轮工具调用场景）、离线回归 + 线上灰度、LLM-as-Judge + 人工抽检、轨迹级评估（trajectory eval）而不只看最终答案。^[4]

参考回答

建立可复现的最小样例与消融实验：固定输入逐个变量排查——换更强模型若问题消失→能力问题；同一模型改提示 / 示例 / 输出 schema 后稳定改善→指令遵循问题；再看是工具描述歧义、上下文噪声还是参数约束缺失。修复手段按成本排序：Prompt / few-shot → 结构化输出与后处理校验 → 流程约束（不让模型做该决策）→ 微调。每次修复必须用评测集给出前后对比数据，避免"感觉变好了"。^[1]

面试白板伪代码（Python）

def run_agent(user_msg, tools, max_steps=5):
    messages = [{"role": "system", "content": SYSTEM_PROMPT},
                {"role": "user", "content": user_msg}]
    fail_count = {}
    for _ in range(max_steps):                 # ② 推理层：最大迭代
        resp = llm.chat(messages, tools=tools)  # 模型只输出决策
        if not resp.tool_calls:
            return resp.content                 # 终止条件
        messages.append(resp.raw)
        for call in resp.tool_calls:
            try:
                result = execute_with_timeout(  # ① 工具层：硬超时
                    call, timeout=15)
            except ToolError as e:              # 结构化错误回灌
                result = {"status": "failed",
                          "error_type": e.type, "retry_after": 5}
                fail_count[call.name] = fail_count.get(call.name, 0) + 1
                if fail_count[call.name] >= 3:  # ② 熔断
                    return escalate_to_human(messages)
            messages.append(tool_result_message(call.id, result))
    return "已达最大步数，转人工处理"            # 终局兜底

这段代码天然对应 Q26 的三层防御，面试时可直接边写边讲。