Reference 0002

P6+ AI 应用面试题库与十场评测

题库按真实面试判断点组织。每个大专题至少 12 题，其中 5 个是可展开成系统设计和多轮追问的高质量深题；完整概念解释在对应 lesson 页的“知识展开”中学习。

1. 评分标准

分数表现典型信号
0-2demo 级只会说 prompt、API、RAG，不谈权限、状态、eval、异常。
3-4概念级知道术语，但无法解释失败定位、成本、延迟和灰度上线。
5-6可实现能搭基本链路，但追问到异常、权限、质量门禁时变浅。
7-8P6+ 合格覆盖数据流、状态、工具边界、eval、trace、安全、成本和回滚。
9-10P7- 强信号能主动识别隐藏约束，提出灰度、组织流程、风险分层和长期演进。

2. 覆盖矩阵

Agent Harness

5 个深题，7 个广度题，共 12 题。

深题用于系统设计、追问和知识串联；点击专题页学习每个深题背后的知识展开。

Tool Calling

5 个深题，7 个广度题，共 12 题。

深题用于系统设计、追问和知识串联；点击专题页学习每个深题背后的知识展开。

Context / Memory

5 个深题，7 个广度题，共 12 题。

深题用于系统设计、追问和知识串联；点击专题页学习每个深题背后的知识展开。

RAG

5 个深题，7 个广度题，共 12 题。

深题用于系统设计、追问和知识串联；点击专题页学习每个深题背后的知识展开。

Orchestration

5 个深题，7 个广度题，共 12 题。

深题用于系统设计、追问和知识串联；点击专题页学习每个深题背后的知识展开。

Eval / Observability

5 个深题，7 个广度题，共 12 题。

深题用于系统设计、追问和知识串联；点击专题页学习每个深题背后的知识展开。

Security / Production

5 个深题，7 个广度题，共 12 题。

深题用于系统设计、追问和知识串联；点击专题页学习每个深题背后的知识展开。

3. 扩充题库

Agent Harness：5 个高质量深题

深题面试官考什么7+ 分答案必须出现
1. 你要从零设计一个客服 agent runtime，支持查订单、申请退款、解释政策和转人工。核心模块有哪些？面试官在判断你是否理解 agent 不是一次模型调用，而是一个受控循环。必须讲清 observe → decide → act → observe → stop 的 run loop，以及谁负责预算、状态、工具、策略和恢复。高分答案先拆 runner、state store、tool registry、policy gate、context builder、trace/eval hook、human escalation。查订单是 read tool，可重试；退款是 side-effect tool，需要幂等键、审批、审计和恢复点。runner 控制 max step、timeout、cost、risk budget，policy gate 在工具执行前拦截越权和高风险动作。
2. Agent 连续调用同一个工具停不下来，线上成本飙升。你怎么定位和治理？考 loop 控制和 observability。不能只说 max token 或换模型。先从 trace 看重复调用是否参数相同、tool result 是否未进入 state、模型是否看不到失败原因、prompt 是否鼓励继续尝试。治理上设置 max steps、per-tool quota、same-args dedupe、state diff 检测、semantic loop detector、budget guard 和 fallback。对写工具还要用幂等键防重复副作用。
3. 一个 agent 任务需要用户审批，审批可能隔天才回来。harness 如何暂停和恢复？考持久化状态，而不是靠聊天历史。把任务建模为 durable state machine：保存 task_id、thread_id、current node、pending approval、tool args draft、risk summary、trace id、version。暂停时不继续调用模型；审批回来后校验审批人和 state version，再从同一节点 resume。任何外部写动作必须可幂等或有补偿动作。
4. 如何设计 agent 的状态层，避免“所有东西都塞 prompt”？考 context 与 state 分层。状态分 conversation messages、task state、tool results、retrieved evidence、memory candidates、policy decisions、approvals、audit log。prompt 只装当前决策必要的投影，不是完整数据库。状态层用于恢复、审计和 eval；context builder 按任务读取最小必要视图。
5. 如果你要让多个业务团队共用同一个 harness，哪些接口必须抽象？考平台化能力。抽象 AgentSpec、ToolSpec、PolicySpec、MemorySpec、EvalSpec、TraceSchema、RunConfig。业务团队配置工具、权限、模型、prompt 和风险规则；平台提供 runner、state、budget、trace、eval、release gate。工具接口要有 schema、auth context、risk level、idempotency、timeout 和 error taxonomy。

Agent Harness：7 个知识广度题

快问准确回答
1. Runner 和 planner 是一回事吗？不是。runner 是确定性的执行控制器，planner 是模型或规则生成下一步计划的组件。runner 必须能拒绝 planner 的危险动作。
2. 为什么 tool result 要结构化保存？为了恢复、回放、eval、去重和错误分类；只保存自然语言会丢失状态和机器可判定字段。
3. max token 能不能防止 agent 无限循环？不能。循环是 step/action 层问题，要用 max step、预算、重复检测和 stop rule。
4. 什么时候必须 human-in-the-loop？高金额交易、权限变更、外部提交、法律风险、低置信但高影响决策。
5. Agent harness 的 trace 至少记录什么？run id、step、prompt/model/schema version、tool args/result/error、policy decision、latency、cost、final answer。
6. 为什么不要让模型传 tenant_id/user_role？身份和权限必须来自服务端 auth context，模型参数不可信。
7. 怎么区分 retry 和 fallback？retry 是同一路径再次尝试，fallback 是降级到另一路径，如小模型失败转人工或跳过非关键 enrichment。

Tool Calling：5 个高质量深题

深题面试官考什么7+ 分答案必须出现
1. 你要设计一个付款 tool，让 agent 能根据用户请求创建付款单。schema 和执行链路怎么设计？考副作用控制。模型可以提出 intent，但不能绕过权限、校验、审批和审计。schema 只接受 payee_id、amount、currency、invoice_id、reason、idempotency_key，不接受 tenant_id、role、approval_status。服务端从 auth context 注入身份并校验金额、收款方、发票状态和权限。先 dry-run 生成付款摘要和风险等级，高风险进入审批；确认后使用幂等键执行并写 audit log。
2. 工具调用参数通过 schema 校验了，为什么仍然可能危险？考 schema 与业务校验的边界。schema 只能约束类型和必填字段，不能证明 payee 存在、用户有权限、金额合理、发票未被支付、操作符合风控。业务校验必须在 tool adapter 或后端服务执行；模型输出永远只是候选请求。
3. 支付 API 超时后 agent 想重试，你如何避免重复付款？考幂等和外部状态查询。写工具不能盲目 retry。先用 idempotency key 或 payment_request_id 查询外部系统状态：已成功则返回成功，处理中则等待或告知用户，未创建或明确失败才可重试。所有重试要绑定同一个幂等键，trace 中记录 retry reason。
4. 工具返回 200 条搜索结果，如何给模型使用而不污染上下文？考 tool adapter 与 context packing。工具层先分页、过滤权限、排序、摘要、保留 source ids；context builder 只传当前决策需要的 top items 和引用。原始结果保存到 state，不全塞 prompt。若模型需要更多，显式调用分页工具。
5. 如何给 tool calling 做专项 eval？考不是只看最终回答。拆工具选择是否正确、参数是否正确、权限是否被拦截、审批是否触发、错误恢复是否正确、最终业务状态是否一致。对 side-effect tool 使用 sandbox 或 dry-run eval，不能在真实环境跑破坏性测试。

Tool Calling：7 个知识广度题

快问准确回答
1. Read tool 和 write tool 最大区别是什么？write tool 会改变外部状态，必须有幂等、审批、审计和补偿策略。
2. tool description 写得越详细越好吗？要足够让模型正确选择，但不能把安全策略只写在 description；策略要在应用层执行。
3. 模型能不能决定用户有没有权限？不能。权限由服务端根据 auth context 和资源 ACL 判定。
4. 为什么工具错误要分类？模型和 runner 需要知道是 transient、validation、permission、business rule 还是 unknown，恢复策略不同。
5. 什么是 dry-run tool？只计算将要执行的动作、风险和摘要，不产生最终副作用。
6. 工具返回自然语言可以吗？可以给人看，但机器判断应返回结构化字段、状态码、错误类型和引用 id。
7. 如何防 prompt injection 诱导工具调用？检索内容视为 data，工具 allowlist、参数校验、权限检查和高风险审批都在模型外执行。

Context / Memory：5 个高质量深题

深题面试官考什么7+ 分答案必须出现
1. 设计一个个性化学习助手：它要记住用户目标、薄弱点和偏好，但不能被用户污染成“以后都跳过安全检查”。你怎么设计？考 memory 分层和写入策略。把本轮 prompt 使用的 working context 与长期 memory 分开。memory schema 包含 type、content、source、confidence、created_at、updated_at、TTL、privacy_scope、user_editable。可写入长期目标、稳定偏好、已验证薄弱点；安全策略、权限身份、系统规则不可由用户写入覆盖。读取时按任务 retrieval gating，只取相关且可信的 memory。
2. 多轮对话超过上下文窗口，如何摘要而不丢关键状态？考摘要边界。先分类哪些信息可摘要、哪些必须 pin。必须 pin 的包括系统约束、未完成任务、用户明确承诺、审批状态、工具结果 source id、引用证据和错误状态。摘要生成后要保留来源范围和版本；关键任务可用结构化 state 替代自然语言摘要。
3. 用户新说“我现在不学后端了”，与旧记忆冲突怎么办？考冲突处理。不要直接覆盖。记录新声明来源和时间，比较旧记忆置信度、最近性和任务相关性。对重要目标变更可询问确认；确认后更新 active goal，旧记忆降权或归档。生成答案时说明依据的是最新确认目标。
4. 如何评估 memory 真的有帮助，而不是制造幻觉？考 memory eval。构造 paired eval：同一任务在无 memory、有正确 memory、有冲突 memory、有过期 memory 下比较任务完成率、个性化准确率、用户纠正率、隐私误用率和 hallucination。还要监控 memory retrieval precision：取出的记忆是否确实支持当前任务。
5. 企业内部助手如何处理用户“删除我的记忆”的请求？考合规与产品边界。长期 memory 必须可查看、可编辑、可删除。删除后从 memory store 和索引中移除或墓碑化，后续 retrieval 不得返回。审计日志可按合规保留最小记录，但不能继续用于个性化。缓存和向量索引要异步清理并有完成状态。

Context / Memory：7 个知识广度题

快问准确回答
1. Context 和 memory 的一句话区别？context 是本轮输入，memory 是跨轮可复用的持久状态。
2. 聊天历史等于 memory 吗？不等于。聊天历史是原始事件，memory 是经过筛选、结构化、带来源和置信度的状态。
3. 什么信息不该写入长期记忆？临时情绪、一次性任务细节、低置信推断、权限身份、安全策略和敏感数据。
4. 为什么 memory 要有 source？用于解释、冲突处理、删除定位、可信度评估和回放。
5. TTL 有什么用？避免过期偏好或临时事实长期污染答案。
6. 低置信 memory 怎么用？不要直接当事实；可以作为候选并向用户确认。
7. Memory retrieval 为什么不能只靠相似度？还要按任务类型、权限、隐私范围、时间和置信度过滤。

RAG：5 个高质量深题

深题面试官考什么7+ 分答案必须出现
1. 设计一个企业知识库问答系统，要求权限隔离、引用来源、文档更新后增量生效。你怎么做？考 RAG 是否能从 demo 讲成生产系统。接入时解析 PDF/网页/表格，保留标题、层级、source_url、version、ACL、updated_at。chunk 按结构和语义切，写 embedding、sparse tokens、metadata。查询时先按 tenant/ACL/time filter，再 dense+sparse hybrid retrieval，rerank 后 context packing。答案必须带 citation，证据不足 no-answer。文档更新触发 affected chunks 重建，保留版本支持回放。
2. 答案错了，你如何判断是检索错、上下文错，还是生成错？考失败定位。保存 trace：query rewrite、filters、retrieved chunks、scores、rerank 排名、packed context、final answer。若正确 chunk 未召回是 retrieval miss；召回但没进 context 是 packing/rerank 问题；context 有证据但答案错是 generation/faithfulness；文档本身冲突则需要 source authority 和冲突策略。
3. 如何设计 chunking，避免切太碎或太大？考数据结构理解。按文档结构优先：标题、段落、表格、代码块、列表。chunk 保存 parent/child、section path、page、token length。长文档可 parent-child retrieval：小 chunk 召回，大 parent 给上下文。用 eval 比较 Recall@k、context precision 和 citation accuracy，而不是凭感觉调 chunk size。
4. 企业知识库有权限，为什么“先向量召回再过滤”可能错？考安全与召回。如果先在全库召回再过滤，可能发生越权候选进入中间 trace、排序受越权文档影响，且过滤后 topK 为空导致漏召回。应在检索前或检索阶段应用 tenant/ACL metadata filter；对无法过滤的索引按权限分区或重建。
5. 如何处理两个权威文档答案冲突？考 source authority。metadata 中维护 source authority、version、effective date、owner。生成前检测冲突：同一问题多个候选给出不同事实时，不强行合成；优先最新/更高权威来源，或输出冲突说明和引用，必要时触发人工确认。

RAG：7 个知识广度题

快问准确回答
1. Dense retrieval 和 sparse retrieval 各擅长什么？dense 擅长语义相似，sparse 擅长关键词、编号、专有名词和精确匹配。
2. Rerank 解决什么问题？对召回候选按与问题的真实相关性重排，减少相似但不回答问题的片段。
3. metadata filter 会提升语义准确率吗？不会直接提升语义模型；它约束候选集合，减少越权和无关文档。
4. No-answer 为什么重要？知识库没有证据时拒答比编造更可靠，也是 RAG 质量指标。
5. Citation accuracy 怎么测？检查答案句子的引用是否真的支持该句，而不是只引用了同一文档。
6. Query rewrite 什么时候有用？用户问题口语化、多跳或缺少实体时，rewrite 可生成检索友好的查询。
7. RAG 延迟高优先看哪里？拆 ingestion 不影响在线；在线看 query rewrite、retrieval、rerank、model context length 和网络工具。

Orchestration：5 个高质量深题

深题面试官考什么7+ 分答案必须出现
1. 设计一个合同审核系统：抽取条款、比对模板、识别风险、生成修改建议。哪些用 workflow，哪些用 agent，是否需要 multi-agent？考可控性和边界。文档解析、条款抽取、模板比对、风险打分用 graph workflow，因为步骤稳定、可恢复、可审计。非标准条款解释和修改建议可用受限 agent。多 agent 只有在法律、财务、业务有清晰工具/权限/评价边界时使用。高风险输出和外发前走 HITL。
2. 什么时候 multi-agent 是合理设计，什么时候是过度设计？考架构判断。合理：角色有不同工具权限、上下文需要隔离、可并行、评价标准清晰、handoff 输出可结构化。过度：只是想让 agent 互相讨论、没有独立状态和指标、成本延迟不可控、失败难定位。
3. handoff 传什么，不能传什么？考上下文最小化。传 task contract、input subset、证据引用、已知约束、expected output schema、trace id、risk flags。不要传全量聊天、无关 memory、权限 token、可被下游当作指令的不可信内容。
4. Graph 中某个节点失败，如何恢复和补偿？考 durable workflow。每个节点有输入、输出、状态版本和错误类型。纯读节点可重跑；写节点必须幂等，失败后先查询外部状态；不可幂等动作设计补偿动作。workflow 保存 checkpoint，可从失败节点 resume，不从头盲跑。
5. 如何给 orchestration 做 eval？考中间路径评估。不仅评最终答案，还评节点选择、handoff payload 完整性、工具顺序、HITL 触发、失败恢复、成本步骤数。用 trace replay 检查不同 prompt/model 版本是否保持关键路径稳定。

Orchestration：7 个知识广度题

快问准确回答
1. Workflow 的优势是什么？确定性、可恢复、易审计、适合稳定流程和高风险业务。
2. Single agent 适合什么？目标清楚但路径不固定，需要动态选择工具或分步推理。
3. HITL 不是“问人”这么简单，关键是什么？触发条件、状态保存、审批身份、恢复位置和审计记录。
4. 为什么多 agent 会更难 debug？多个上下文、handoff、并发和评价边界会让失败归因更复杂。
5. 编排中的状态放哪里？放 durable state store，不依赖模型聊天历史。
6. 什么时候应该并行执行？子任务相互独立、工具无共享副作用、结果可合并且延迟收益大于协调成本。
7. Orchestration 的红线是什么？让多个 agent 自由对话后直接执行高风险动作，没有状态、权限和审批。

Eval / Observability：5 个高质量深题

深题面试官考什么7+ 分答案必须出现
1. 你的 agent 上线后用户反馈“偶尔胡说、偶尔工具调用错”。你如何定位并证明改动有效？考 observability 和 eval 闭环。先看 trace，把失败分成 retrieval miss、wrong context、tool args error、policy miss、model hallucination、latency/cost。把代表性 trace 转成 eval case，保留输入、期望路径、允许工具、禁止行为和 rubric。修复后跑离线回归，通过后 canary，线上继续采样新坏 case。
2. LLM-as-judge 可以用吗？如何避免不可靠？考评价方法边界。可以用于可观察标准，如是否引用支持、是否包含必要字段、是否违反安全规则。必须有明确 rubric、少量人工标注校准、judge prompt/version 固定、抽样复核。不能用模糊的“好不好”替代业务状态和工具结果断言。
3. 如何为 RAG agent 设计分层 eval？考系统拆解。检索层测 Recall@k、MRR、nDCG、context precision；生成层测 faithfulness、answer correctness、citation accuracy、no-answer；agent 层测 query rewrite、分步检索、工具选择、成本和延迟。不要只测最终答案。
4. 线上成本升高，你如何用 observability 找原因？考指标归因。按 tenant、feature、model、prompt version、tool、retrieval、rerank、retry、cache miss、agent steps 拆成本和延迟 waterfall。看是否 prompt 变长、loop 增多、cache 失效、工具超时重试、rerank 批量扩大或模型路由变化。
5. 如何把 eval 接入发布流程？考工程落地。定义 golden set、risk-specific safety set、线上坏 case regression set。CI 中跑快速关键集，发布前跑完整集；门禁包含质量不下降、红线安全 case 0 失败、成本/延迟不超过阈值。通过后 shadow/canary，失败可 rollback。

Eval / Observability：7 个知识广度题

快问准确回答
1. Task eval 和 trajectory eval 区别？task eval 看最终任务是否完成，trajectory eval 看中间路径是否合理。
2. Tool-call eval 测什么？工具选择、参数、权限拦截、错误恢复和副作用状态。
3. Trace 最少要记录哪些版本？prompt、model、tool schema、index、policy、judge rubric。
4. 为什么用户满意度不能替代 eval？它滞后、噪声大、不可复现，不能定位失败原因。
5. Golden set 怎么来？高频真实请求、线上坏 case、业务关键路径、安全红线和边界样本。
6. 什么是回归门禁？新版本必须通过既有关键 case，防止修一个问题破坏旧能力。
7. 为什么要采样线上 trace？生产分布会变化，新的坏 case 是持续改进 eval 集的来源。

Security / Production：5 个高质量深题

深题面试官考什么7+ 分答案必须出现
1. 一个 RAG agent 读取外部文档后，被文档里的 prompt injection 诱导去导出用户邮箱。你如何防御并上线？考 defense-in-depth。检索内容标记为 untrusted data，不作为 instruction。邮箱/数据库工具只接受应用定义的受限接口和服务端 auth context，工具层做 RBAC、row-level ACL、PII masking、rate limit、audit。敏感导出走审批。上线前用 prompt injection、越权、PII 泄露、工具滥用 case 做 safety eval，灰度发布并监控 blocked calls。
2. 为什么“在 system prompt 里说不要泄露”不是安全方案？考安全边界。prompt 是软约束，会被不可信上下文、模型错误和工具漏洞绕过。真正边界在工具/API 层：服务端权限、参数白名单、最小返回、敏感字段脱敏、审批、审计和速率限制。prompt 只能帮助模型遵循流程，不能替代 access control。
3. AI 功能如何从 prototype 推到 production？考发布流程。先定义业务指标和红线，建立 offline eval 和 safety eval；接 trace 和成本延迟观测；shadow mode 只观察不行动；canary 小流量带 feature flag；设置 SLO、alert、kill switch 和 rollback；版本化 prompt/model/tool schema/index/policy。
4. 用户输入最终进入 HTML/SQL/shell/workflow，如何防输出注入？考输出安全。模型输出视为不可信。进入 HTML 要转义或 sanitize；进入 SQL 使用参数化查询；进入 shell 禁止自由拼接，使用 allowlist 参数；进入 workflow 要 schema validate 和权限校验。不同目标系统用对应 encoder/validator。
5. 线上出现越权回答，如何止血和复盘？考 incident response。先 feature flag/kill switch 降级相关能力，保留 trace 和 audit。定位是 retrieval ACL、tool auth、context packing、prompt injection 还是缓存污染。补 safety regression case，修复后跑门禁和 canary。对受影响用户、数据范围、时间窗口做审计。

Security / Production：7 个知识广度题

快问准确回答
1. Prompt injection 和 jailbreak 区别？prompt injection 常来自外部不可信内容影响任务；jailbreak 常是用户直接诱导模型绕过规则。
2. 最小权限在 agent 中怎么落地？每个工具只暴露必要动作、字段、资源范围和调用频率。
3. PII masking 应该放在哪里？工具/API 返回前和输出前都可做，但权限判断必须在服务端。
4. 什么是 kill switch？可快速关闭某个 agent、工具、模型版本或高风险能力的开关。
5. Shadow mode 有什么用？让新 agent 在真实流量旁路运行但不影响用户，用于收集质量和风险数据。
6. 生产 SLO 应包含哪些 AI 特有指标？任务成功率、拒答准确率、工具失败率、安全拦截、P95 延迟、成本和用户纠正率。
7. 为什么要版本化 index？RAG 答案依赖索引内容；没有 index version 就无法回放和比较。

4. 十场模拟面试

场次方向准出要求
Mock 01Harness runtime客服 agent 支持查单、退款、转人工：画出 run loop、state、tool policy、trace 和 HITL。
Mock 02Memory system个性化学习助手：区分 thread state、summary、profile memory、episodic memory 和删除机制。
Mock 03Enterprise RAG企业知识库：覆盖 ingestion、ACL、hybrid retrieval、rerank、citation、eval 和 no-answer。
Mock 04Agentic RAG跨 CRM、文档库、工单：说明 planner、query rewrite、多源检索、step budget 和 trace。
Mock 05Side-effect tools付款/发邮件：schema、auth context、idempotency、dry-run、approval、audit。
Mock 06Workflow vs agent合同审核：固定 workflow、受限 agent、handoff contract、HITL、checkpoint。
Mock 07Eval loop从线上坏 case 到 golden set、trajectory/tool/safety eval、CI gate 和 canary。
Mock 08Cost latency按 tenant、feature、model、tool、retry、cache、agent steps 拆 waterfall。
Mock 09Security incident外部文档注入导出邮箱：defense-in-depth、RBAC、PII masking、audit、kill switch。
Mock 10Production final从 prototype 到 production：指标、架构、质量、安全、成本、发布和迭代闭环。