主题
面试高频知识点
用法：先自己回答“核心关注点”，再说出“代价/边界”，最后补一个真实失败场景。能讲清取舍，比背结论更耐追问；下面只给检查点，不提供标准话术。
单 Agent 基本盘
| 问题 | 核心关注点 | 常见误区 | 展开 |
|---|---|---|---|
| Agent 和一次模型调用差在哪 | 循环、工具、状态、终止条件；模型只产生意图，执行与验证在 Harness | 把“多轮提示词”当 Agent | 02 |
| ReAct、Plan-Execute、Reflection 怎么选 | 路径确定性、任务长度、失败代价；Reflection 的收益来自可验证反馈 | 以为什么任务都该先规划 | 02 |
| 循环为什么会停不下来 | 缺少预算、重复探索、验证器太弱；终止要由 Harness 判定 | 只加一句“最多三步” | 02 |
| Prompt 怎么写才可评测 | 任务、证据、约束、输出契约四件事说清；约束要可判定，输出要 schema 校验 | 用“准确、专业”这类不可判定的词当规则 | 03 |
| 上下文越大越好吗 | 有效上下文受检索、压缩、注意力影响；中段信息会被稀释 | 把窗口上限当有效容量 | 04 |
| 压缩上下文会丢什么 | 目标、已确认事实、未完成项必须保留；先提交事实再压缩，切点不能切断工具配对 | 只压对话，不压工具结果 | 04 |
| 压缩到什么程度算够 | 不看压掉多少 token，看压缩后能否继续执行、结论能否回溯、总成本是否下降 | 把压缩率当指标 | 04 |
| 多个会话能同时跑吗 | 同会话必须串行，跨会话并行；瓶颈是等待不是 CPU，阻塞操作要隔离线程池 | 用无锁并发处理同一会话 | 10 |
| 拦截器多了谁先谁后 | 按阶段分组、组内显式优先级；声明能否否决与异常时 fail-open/fail-closed | 依赖注册顺序，异常一律放行 | 10 |
| 业务知识怎么放进上下文 | 按条款卡/事实卡/SOP/决策表包装；常驻、检索、指针、工具四种注入 | 把文档切块塞进去就算包装 | 04 |
| 规则该放 system prompt、Skill 还是 hook | 常驻事实、按需流程、确定性拦截分层；放错层就不可执行或太贵 | 所有约束都塞进提示词 | 03、04、07 |
| 记忆和 RAG 的分工 | 记忆存“经历过什么”，RAG 存“组织知道什么”；写入要策展 | 把聊天记录直接当长期记忆 | 06 |
| 记忆污染怎么处理 | 来源、时效、冲突消解、可回滚；错误记忆要能降级 | 只做向量检索，不做治理 | 06 |
工具、协作与安全
| 问题 | 核心关注点 | 常见误区 | 展开 |
|---|---|---|---|
| Function Calling 谁在执行 | 模型只输出结构化意图，宿主做校验、授权与执行 | 以为模型真的调用了 API | 07 |
| MCP 的 Host/Client/Server 怎么分 | 概念分工，不是部署拓扑；stdio 无网络跳，HTTP 才多一跳 | 把三原语当协议全貌 | 07 |
| MCP 和 A2A、ACP 的区别 | MCP 接工具/数据，A2A 接 Agent，ACP 接编辑器与 Agent | 所有互操作都塞进 MCP | 07、07b |
| 什么时候需要多 Agent | 三条判据：上下文隔离、权限分离、并行提速；单 Agent 加好工具能解决的不要拆 | 先搭多 Agent 再找问题 | 07b |
| Delegation 和 Handoff 差在哪 | 前者父任务保留责任，后者控制权转移；都要有状态与责任记录 | 只靠一条自然语言消息 | 07b |
| 间接提示注入从哪来 | 检索文档、网页、工具返回值、仓库文件；工具描述本身也不可信 | 只防用户输入 | 09 |
| 沙箱能解决什么、不能解决什么 | 限制文件/网络/进程影响；不能替代凭证管理、出网控制与审批 | 有沙箱就认为安全 | 09 |
| 第三方 MCP/Skill/扩展怎么治理 | 允许列表、版本钉住、来源与签名、权限最小化、kill switch | 装完就默认可信 | 09 |
质量、RAG 与落地
| 问题 | 核心关注点 | 常见误区 | 展开 |
|---|---|---|---|
| Agent 怎么评测 | 结果、关键步骤、轨迹三层；黄金集 + 回归门禁 + 人工校准 | 只看单次 Demo 或满意度 | 12 |
| LLM-as-Judge 可信吗 | 有偏差、需校准；适合相对比较与初筛，不天然是权威 | 让 Judge 决定发布 | 12 |
| 请求成功等于任务成功吗 | 不等于；要看环境证据、验收器与副作用 | 用 HTTP 200 当完成 | 12、20 |
| RAG 的瓶颈通常在检索还是生成 | 先量检索 Recall@k / nDCG，再量答案忠实度；多数问题在切分与召回 | 一上来换更大的模型 | 13 |
| 切分策略怎么选 | 结构感知优先，父子块/上下文增强；固定窗口只是基线 | 只调 chunk size | 13 |
| 混合检索为什么有效 | 稀疏抓关键词与专有名词，稠密抓语义；RRF 融合降低单路偏差 | 只用一个向量库 | 13 |
| 重排的价值和成本 | 先召回后精排，提升 top-k 精度；增加延迟与算力 | 对全量候选做重排 | 13 |
| GraphRAG 适合什么 | 实体/关系/社区摘要，适合全局与多跳问题；构建与更新成本高 | 所有问答都上 GraphRAG | 13 |
| Agentic RAG 什么时候值得 | 查询需要分解、迭代或工具补充；要设轮次与预算 | 用多轮检索掩盖索引质量差 | 13 |
| 什么时候该微调 | 风格/格式/领域行为稳定且数据充足；知识更新仍优先 RAG | 用微调灌知识 | 21 |
| Harness、Runtime、沙箱怎么分 | Harness 决定下一步，Runtime 承载过程，Sandbox 限定影响范围 | 把容器当架构 | 20 |
| 平台什么时候该建 | 多团队、多 Agent 出现身份/配额/审计重复建设时 | 第一个 Agent 就上平台 | 20 |
自检方法
- 任选一行，用 90 秒讲清“是什么 → 为什么这样设计 → 代价 → 一个失败场景”。
- 如果只能讲结论，讲不出替代方案和被否原因，回到对应文章重读“核心机制”与“边界”。
- 把答不出的行记成待补清单，不要用更多术语掩盖空洞。
适用：2026 年 AI Agent 面试与工程复盘 | 初稿 2026-10