做 AI 应用不是把 Prompt 塞进接口就结束了。真到项目里，马上会遇到上下文长度、结构化输出、RAG 召回、工具权限、评测回归、成本和稳定性这些问题。

Agent 不是“会调用工具的聊天机器人”。一旦任务变长，它就要处理状态、记忆、权限、失败重试、上下文裁剪和执行边界。

AI 应用开发面试很少只问“概念是什么”。更常见的是顺着一个项目往下追：为什么这样设计，出了问题怎么排查，上线后怎么评测，成本和安全怎么管。

AI Agent 面试最容易出现两种极端：一种是把 Agent 讲得像“全自动数字员工”，什么都能自己规划、自己执行；另一种是把 Agent 讲得像“几个 Prompt 串起来”，完全看不出和普通工作流有什么区别。

真正好的回答要落到中间：Agent 的核心不是神秘的自主意识，而是一套围绕大模型构建的任务执行系统。它要有运行循环、上下文供给、记忆机制、工具调用、安全边界、失败恢复和评测闭环。

这份 AI Agent 面试题根据 AI 专栏现有文章整理，重点不是让你背“Agent 是什么”，而是帮你学会这样回答：

1. Agent 为什么需要 Loop？
2. Agent 为什么离不开 Context Engineering？
3. Memory、Tools、MCP、Skills 分别解决什么问题？
4. 什么时候应该用 Workflow，而不是直接上纯 Agent？
5. Agent 上生产后，怎么控制成本、风险和不确定性？

AI 应用开发面试和传统后端面试不太一样。

传统后端面试更多围绕 Java、JVM、并发、MySQL、Redis、消息队列、分布式和系统设计展开。AI 应用开发面试除了这些基础，还会继续追问：

• 大模型 Token 是怎么计算的？上下文窗口越大越好吗？
• Function Calling 和 MCP 有什么区别？工具调用怎么做权限控制？
• RAG 召回率低怎么排查？Chunk 怎么切？Rerank 解决什么问题？
• Agent 的 Memory 怎么设计？长任务上下文溢出怎么办？
• 如何设计一个生产级 AI 应用？模型网关、评测、可观测怎么做？

AI 系统设计题和传统后端系统设计很像，但多了一个特别麻烦的变量：大模型。

传统服务通常遵循确定性的输入输出，出了问题可以按日志、链路、数据库状态逐步定位。AI 应用不一样，模型输出有随机性，Prompt 会影响行为，RAG 证据会影响答案，工具调用可能失败，供应商可能限流，评测还不能只靠单元测试。

所以，AI 系统设计面试真正考的是：你能不能把一个 Prompt Demo 设计成稳定、可观测、可评测、可回滚、可治理的生产系统。

这份 AI 系统设计面试题根据 AI 专栏现有文章整理，适合 2 年以上开发者复习。建议你按这条主线准备：

很多同学准备大模型面试时，第一反应是去背 Transformer、Attention、RLHF 这些词。不是说这些不重要，但对大部分后端转 AI 应用开发、AI 工程应用岗位来说，面试官更关心的是另一件事：

你是不是真的理解大模型调用链路里的工程约束。

比如 Token 为什么会影响成本和延迟？上下文窗口为什么不是越大越好？Temperature 为什么会影响结构化输出稳定性？Function Calling 为什么不能让模型直接执行真实业务操作？这些问题看起来基础，答不好就会暴露一个信号：你可能只是调过 API，还没有把大模型当作生产系统里的一个不稳定外部依赖来治理。

RAG 是 AI 应用开发里最容易被低估的模块。

很多人以为 RAG 就是“文档切块 -> 转向量 -> 存向量库 -> 检索 -> 拼 Prompt”。Demo 阶段这么理解没问题，但一到真实业务，问题马上变复杂：文档解析不干净、Chunk 切碎了语义、Embedding 模型选错、召回结果不准、权限过滤漏了、知识库更新后旧版本还在、模型拿到证据却没有正确回答。

所以，RAG 面试真正考的不是“你会不会接向量数据库”，而是：你能不能把一个检索增强生成系统拆成可定位、可优化、可评测、可更新的工程链路。

大模型 API 看起来只是一段请求和一段返回，实际落地时问题都藏在细节里：Token 怎么花掉、上下文为什么塞不下、采样参数会不会让答案飘、结构化输出为什么偶发失败、上线前怎么证明效果真的变好了。

RAG 最容易被低估的地方，是它看起来像“文档切块 + 向量检索”，但真正影响效果的环节远不止这两个。