面了近 10 家 AI 创业公司后，我想聊聊 Agent 岗面试到底在考什么，以及那些比”背答案”重要一百倍的事。
写在前面#
我叫 Joye，墨尔本大学大二，计算与软件工程在读。过去几个月我在上海的特赞（Tezign）做 AIGC 研发实习，主要负责 Atypica——一个商业研究方向的 Multi-Agent 系统。
最近在看新的机会，陆陆续续面了将近 10 家公司，清一色都是 AI 创业公司和海外 Startup，岗位方向集中在 Agent 开发、LLM 应用工程这一块。面完之后回头看，我发现这个方向的面试经验在中文互联网上还挺稀缺的——不像前端后端有成体系的八股文可以刷，Agent 开发的面试更像是一场关于”你到底理不理解你在做的东西”的深度对话。
所以写这篇文章，一方面是把自己的面试记录做个整理和复盘，另一方面也希望给同样在这个方向上探索的同学一些参考。
但我想先说一件事：这篇文章不只是写给正在准备面试的人的，也同样写给正在学习 Agent 开发、正在写自己 Agent 项目的人。
为什么这么说？因为 Agent 开发的面试题和前端八股文有一个本质区别——前端八股你背完可能一辈子用不上，但 Agent 面试里被问到的这些问题，是你在做项目的时候真真切切需要去考虑的设计决策。“上下文爆了怎么办”不是一道面试题，它是你的 Agent 跑到第 20 轮对话时一定会遇到的工程问题。“如何防止 LLM 乱用 Tools”也不是面试官在刁难你，它是你部署到生产环境后第一周就会收到的 bug report。
换个角度想：如果你在自己的项目中已经认真做好了上下文工程、做好了 Tool-Calling 的可靠性保障、思考过 Prompt 注入的防御——那这些就不是需要”准备”的面试题，而是你可以自然而然讲出来的实战经验，这就是真正的加分项。我后续自己去做新的项目，也会带着这些问题去思考和设计。
Agent 岗面试到底在考什么#
和传统开发面试的区别#
面了这么多轮之后，我最大的一个感受是：Agent 开发的面试几乎没有”标准答案”。
传统的前端面试你可以背闭包、背事件循环、背虚拟 DOM diff 算法，背完就有个七八成把握。但 Agent 方向不一样，面试官问的很多问题是开放式的，他不是在考你记住了什么，而是在考你经历过什么。“你们的 Agent 出现死循环怎么办？“——这种问题，没踩过坑的人是编不出来的。
我观察下来，面试官关心的东西大致可以分成三个层次：
- 你会不会用——你用过 LangChain 吗？RAG 怎么搭的？MCP Server 怎么设计的？
- 你理不理解为什么这样设计——为什么用结构化 Prompt 效果更好？为什么要做记忆分层？为什么选 Vercel AI SDK？
- 你能不能在工程约束下做取舍——Token 预算有限怎么办？回复速度和质量怎么平衡？模型幻觉怎么兜底？
第一层靠经验，第二层靠理解，第三层靠判断力。越往后越难准备，但也越能体现一个人的工程成熟度。
面试题目全景分类#
我把这段时间遇到的面试题按主题做了一个分类整理，大概涵盖了 Agent 开发面试的主要考察方向：
RAG 与检索增强
- 多重 RAG 和单一 RAG 的区别与适用场景
- 如何做检索增强（Retrieval Augmentation）
- RAG 什么时候用向量检索，什么时候用图数据库检索
- RAG 的数据清洗怎么做
- RAG → Agentic Search → Agentic Memory 的演进路径
Agent 架构与编排
- Agent 的路由设计：如何决定调用哪个 Sub-Agent
- Agent 的兜底机制设计
- Sub-Agent 是并行还是异步？支不支持互相通信？
- 如何防止 LLM 乱用 Tools
- 如何处理 LLM 的死循环调用
- 如何设计 MCP Server
- Agent 流程的整体框架设计
- 如何做回调（Callback）机制
上下文工程与 Token 管理
- 如何节省 Token
- 上下文爆了怎么办（除了 FIFO 还有什么方案）
- 短期记忆如何转换成长期记忆
- 提示词压缩策略
- Prompt Cache 打在哪些位置
Prompt Engineering 与安全
- 为什么结构化 Prompt 有助于提升回复质量
- 如何设计情感类的隐晦情感 CoT
- 如何防止 Prompt 恶意注入
- 如何把抽象需求转化为实际需求（让 AI”更聪明""更有活人感”）
- 访谈开始和结束时有没有做 Prompt 注入防护
- One-shot 的负面作用：example 不够有差异化会限制模型思路
LLM 基础与模型工程
- Attention 机制（公共知识）
- Pretrain 与 LoRA 微调
- LLM as a Judge 的设计与局限
- 回复速度与回复质量的取舍
- 如何避免 OOC（Out of Character）
- 如何处理 LLM 幻觉
AI Infra 与工程化
- 模型网关 / Agent 网关的设计
- Eval 平台搭建
- DPO / APO 算法评估
- 为什么使用 Vercel AI SDK
行业认知与系统设计
- Manus、OpenClaw、OpenCode 分别是如何做架构设计的
- Agent 的主要应用场景：AI 搜索、Chat-to-BI 生成图表、Vibe Coding
- Skill 和 MCP 的关系与区别
- LangChain / LangGraph 的使用经验
看完这个列表你可能会发现，这些问题没有一个可以靠”背”来解决。它们考察的更多是你对系统的整体理解和你在实际工程中的判断力。
面试中最让我成长的几个问题#
比起列出每道题的”参考答案”，我更想分享几个在面试中真正让我成长的瞬间。这些问题当时有的答上来了，有的没答好，但它们都在面试结束后持续地影响着我对 Agent 开发的理解。
“上下文爆了怎么办？除了先进先出还有什么？”#
这个问题几乎每家都会问，而且面试官通常不满足于你只说”FIFO 淘汰最早的消息”。
我第一次被问到这个的时候，确实只答出了先进先出。面试官追问：如果用户在对话开头说了一个非常重要的约束条件，你用 FIFO 直接丢掉了怎么办？我当时愣住了。
后来复盘的时候我才意识到，这个问题本质上考的是**上下文工程（Context Engineering）**的全局视野。在 Atypica 项目里，我们其实已经在做这件事了——记忆分层（Working Memory / Short-term / Long-term）、摘要压缩、检索拼接、Token Budget 管控——但我当时没有把它们串成一个完整的 Pipeline 来表述。
这个经历教会我一件事：做过不等于能讲清楚。很多时候你在项目里已经解决了某个问题，但如果你没有把它抽象成一个系统性的方案，面试时就会支支吾吾说不出个所以然。从那之后，我开始刻意地用”问题 → 方案 → 权衡 → 结果”的框架重新梳理我在 Atypica 的每一个设计决策。
“如何防止 LLM 乱用 Tools？”#
这个问题初听起来好像很简单——加个权限控制不就行了？但面试官要的远不止这些。
在 Atypica 里，我们搭了一套 Tool-Calling 的异步状态机，包括 checkpoint、重试、幂等、超时回滚、状态恢复这些机制。但”防止乱用”不只是事后兜底的问题，更关键的是事前约束：Tool Schema 的设计是不是足够清晰？Function Calling 的描述有没有歧义？路由逻辑是不是能正确地把请求分发到对应的工具？
有一次面试中面试官继续追问：如果 LLM 进入了死循环反复调用同一个 Tool 怎么办？我提到了我们做的 watermark 和去重机制，还有断点续跑的设计。面试官点了点头，但又问了一句让我印象很深的话：“那你有没有想过，与其在运行时做这么多防御，不如在 Prompt 层面就把工具的使用边界讲清楚？”
这句话点醒了我。很多 Agent 可靠性的问题，根源不在 Runtime 层，而在 Prompt 层——你给 LLM 的指令如果本身就含糊不清，再多的工程兜底也是在给糟糕的 Prompt 擦屁股。这也是为什么后来我越来越重视 Prompt 的结构化设计和 guardrails 的前置约束。
“为什么结构化 Prompt 比自然语言 Prompt 效果更好？”#
这个问题我一开始觉得很好回答：“因为结构化信息更容易被模型解析嘛。“但面试官追问了一句：“从 Attention 机制的角度，你能解释一下为什么吗？”
我当时对 Attention 的理解还停留在”Q、K、V 做点积计算相关性”的层面，没有深入想过它和 Prompt 格式之间的关系。面试官给了一个很有启发的思路：结构化的 Prompt（比如用 XML 标签、JSON Schema 或者明确的分隔符）实际上是在帮助模型的注意力分配——它让关键信息在 token 序列中有更清晰的”锚点”，降低了模型在长上下文中”找重点”的难度。而自然语言的表述往往把关键信息淹没在大量的修饰语和过渡句中，增加了注意力的分散。
这次对话让我意识到，很多时候我们在工程层面做的 Prompt 优化，背后其实有很扎实的模型机制支撑。知其然更要知其所以然，这在面试中尤其重要——面试官能很快分辨出你是”背的经验”还是”真的理解了”。
“如何把抽象需求转化为实际需求？”#
这可能是我面试中遇到的最”软”的一个硬问题。
面试官的原话大概是：“用户说’让 AI 更聪明一点”更有活人感一点’，你怎么把这种模糊的需求变成可以落地的技术方案？”
这恰好是我在 Atypica 里花了大量时间做的事。我们设计了一套 Counter-Questioning（澄清式反问）系统：当用户的需求模糊时，Agent 不是硬着头皮去猜，而是通过显式和隐式的意图识别，把模糊的需求拆解成结构化的约束——目标是什么、受众是谁、风格偏好、限制条件各是什么。
我在面试中完整地讲了这套系统的设计思路，面试官听完之后问了一个我觉得很高级的问题：“那你怎么评判 Counter-Questioning 的质量？怎么知道你问的问题是有效的，而不是在浪费用户的耐心？”
说实话这个我当时没答好。后来我想了很久，觉得这可能需要用 LLM as a Judge 或者用户满意度的间接指标来做评估——但这个方向我确实还没有深入实践过。面试就是这样，它会精准地戳到你知识体系的边界。
“如何防止 Prompt 恶意注入？”#
这个问题在多场面试中都被问到了，但真正让我受益的不是面试本身，而是面试之后我做的功课。
面试中我大致聊了一些基础的防御思路——输入过滤、角色锁定、输出校验之类的。但面试官显然期待更系统化的回答。回去之后我去认真读了 OpenAI 和 Anthropic 各自关于 Prompt 安全的技术博客，发现这个领域其实有两个非常清晰的核心思想：
一个是 OpenAI 提出的 Instruction Hierarchy（指令层级）——核心理念是给不同来源的指令设定优先级，System Prompt > 开发者指令 > 用户输入，让模型在遇到冲突指令时知道该听谁的。另一个是 Anthropic 的沙盒化思路——把不可信的外部内容隔离在受限的执行环境中，从架构层面限制恶意指令的影响范围。
我为什么要特别提这个？因为我真心建议每一个做 Agent 开发的人都去花时间读一读 OpenAI 和 Anthropic 的技术博客。它们不是停留在理论层面的学术论文，而是非常优秀的、来自一线的工程实践建议，读完之后你对很多问题的理解会上一个台阶。当然论文也值得读——我后面会在我的个人博客上出一个精选论文系列，筛选对 Agent 开发实践最有价值的论文做解读。同时我也在做一个 RSS 订阅推送的东西，每天或每周汇总来自各大 AI 厂商的最新 Agent 开发实践，加上我自己的理解和点评，不是单纯的搬运，而是带观点的筛选和解读。感兴趣的可以关注我的博客 joyehuang.me ↗ 获取更新。
“你了解 Manus / OpenClaw / OpenCode 的设计吗？”#
这不是一个技术深度的问题，而是一个行业广度的问题。面试官想知道的是：你有没有在关注这个行业正在发生什么？你不只是在自己的项目里埋头干活，还有没有抬头看看别人在怎么解决类似的问题？
当时我对 Manus 和 OpenCode 有一些了解（我研究过 OpenCode 的架构），但对 OpenClaw 了解不多，回答得比较勉强。这个问题提醒了我：Agent 开发还处在快速演进的阶段，面试官考察行业认知本质上是在考你的学习速度和信息敏感度。
如果你平时不看 GitHub Trending、不追 Twitter/X 上的 AI 讨论、不去研究新出的开源项目，面试中遇到这类问题就会非常被动。我后来养成了一个习惯：每周花固定时间去看看 Manus、OpenCode 这些项目的 changelog 和 design doc，不一定要深入，但至少要知道行业的风向在往哪吹。
那些比”刷题”更重要的事#
关于面试本身#
复盘是面试最大的杠杆。
这是我最想强调的一点：不做复盘的面试是没有意义的。如果条件不允许录音，那就面试一结束立刻找个地方坐下来，趁记忆还热乎，把所有问题和自己的回答记录下来。尤其是没答上来的、答得磕磕巴巴的——那些才是最有价值的复盘素材。你现在看到的这篇文章里的面试题列表，就是这么一轮轮记下来的。
让面试官给你复盘。
很多人忽略了反问环节的价值。我后来养成了一个习惯，在反问环节一定会问两个问题：“我今天面试哪里表现得不太好、需要改进？“和”我哪里做得还不错？“你可能会觉得这样问很直接，但实际上大部分面试官都非常愿意回答。他们给你的反馈比你自己瞎猜精准得多，而且这也展示了你是一个积极寻求成长的人。
除了这两个问题，还可以问问”如果入职后第一个要上手的项目是什么”——这既能展示你的诚意，也能帮你判断这个岗位的实际工作内容是不是和 JD 描述的一致。
面试官也是你的人脉。
面完之后，不管结果怎样，尽量加个微信或者 LinkedIn。你不知道什么时候这段关系会产生价值。我有一个真实的经历：面了一家做 toB 方向的 Fintech Agent 公司，通过了一面，但面试官觉得他们公司的产品方向可能不太适合我的兴趣，就主动把我推荐给了另一家公司。我现在正在那家公司的笔试流程中。机会有时候就是这么来的——你永远不知道一次”没成功”的面试会通向哪里。
关于选 Offer：给实习生和初创方向的建议#
用一个问题筛掉不靠谱的创业公司。
在面试创业公司的时候，我一定会在反问环节问一个问题：“对比竞品，你们产品的核心优势是什么？“这个问题看似简单，但它的筛选效果非常好——一个创业公司的面试官如果连自家产品的差异化优势都讲不清楚，那这家公司的方向大概率是模糊的。创业公司对自己的产品都没有信心，你去了能学到什么？直接避雷。
不要被”天使轮融资 xxx 万”忽悠。
融资金额只是评判一家创业公司的一个维度，绝对不是唯一维度。当然，连融资都没有的公司确实需要更加谨慎。但有融资不代表一切都好——你还需要看产品方向是不是靠谱、团队背景如何、你在里面能不能真正学到东西、有没有 mentor 带你。实习不只是卖时间，更是一次学习投资，要想清楚你的时间花在哪里回报最高。
对我自己来说，选 offer 时最在意的几个点是：这个产品有没有意思？我自己是不是真的感兴趣？是不是出海方向？是不是 toC？这些偏好因人而异，但重要的是你得有自己的判断框架，而不是被融资额或者公司名头牵着走。
主动出击，不要被”全职”标签吓退。
在 Boss 直聘或者各种招聘平台上，很多岗位写的是招全职。但如果你觉得这个岗位方向很契合，完全可以主动联系，说明自己的情况：“虽然我目前还在读书，但如果贵公司有实习的需求，希望您可以看看我的简历。“最坏的结果不过是被拒绝，但很多时候对方其实是有实习 headcount 的，只是没有单独发出来而已。
说个题外话：如果你的实习经历足够扎实，甚至可以直接去面全职岗位。我就面过一个全职的 Agent 开发岗，被拷打得很惨但居然通过了——面试官到最后才发现我还没毕业。这件事让我意识到，不要自我设限，别人对你的预期往往没有你对自己的预期那么低。
行业观察：从面试题看 Agent 开发的风向#
面试题本身就是一个行业风向标——面试官问什么，某种程度上反映了这个行业当下最关心什么问题。从我这近 10 场面试中，我观察到了几个明显的趋势。
RAG 正在向 Agentic 方向演进#
几乎所有面试都问到了 RAG，但没有一个只停留在”检索 + 生成”的基础层面。面试官更关心的是 Agentic Search 和 Agentic Memory——也就是说，检索不再是一个被动的管道，而是 Agent 自己决定”什么时候搜、搜什么、搜到的结果怎么用”。这是一个从工具到能力的质变。
Agent 的三大落地场景反复被提及#
在和不同公司的面试官交流中，有三个应用场景被提到的频率最高：AI 搜索（从关键词匹配到语义理解的升级）、Chat-to-BI（用自然语言生成数据分析图表）、以及 Vibe Coding（用 AI 辅助甚至主导代码编写）。这三个方向各自对 Agent 的架构设计有不同的要求，但共同点是都在追求更强的”自主性”和”可靠性”。
AI Infra 层开始被认真对待#
早期做 Agent 开发，大家更关注上层应用逻辑——Prompt 怎么写、Chain 怎么串。但现在面试中越来越多地出现 AI Infra 层的问题：模型网关怎么设计？Agent 网关怎么做路由和限流？Eval 平台怎么搭建？DPO/APO 这些对齐算法你了解多少？这说明行业正在从”demo 阶段”走向”生产级”，基础设施的成熟度开始成为决定产品可靠性的关键因素。
MCP 和 Skill 体系正在标准化#
MCP（Model Context Protocol）在面试中被问到的频率很高，它代表的是 Agent 能力调用的一种标准化方向。同时，Skill 这个概念也在从 Manus 等产品中浮现出来——把 Agent 的能力打包成可复用、可组合的模块。这个趋势对开发者来说意味着：未来 Agent 开发可能不再是从零搭建，而是在一个标准化的能力市场里做组装和编排。
工具链选型体现工程品味#
为什么用 Vercel AI SDK 而不是 LangChain？这种问题看似在考技术选型，实际上在考你对工具链生态的理解和自己的工程判断力。在面试中能讲清楚”我为什么选这个、它的 trade-off 是什么、什么场景下我会换别的”，比单纯说”我用过 xxx”要有说服力得多。
写在最后#
面了这么多轮之后，我最大的感受是：面试是一面镜子，它不会骗你。
它会精准地照出你知识体系里的每一个漏洞，也会让你发现那些你以为自己懂了、其实只是”用过”的东西。从”我在项目里用过 Agent”到”我能设计一个可靠的 Agent 系统”，中间隔着的不是更多的项目经验，而是更深的理解和更系统的思考。
作为一个还在读大二的学生，我知道自己还有很多要学的。但这段密集面试的经历让我对 Agent 开发有了一个远比之前清晰的全景图——不只是技术上的，也包括行业判断上的。
最后送一句话给同样在这条路上的朋友们：
Build fast, learn faster. 面试不是终点，是下一段成长的起点。
如果这篇文章对你有帮助，欢迎在评论区交流你的面试经历，也可以在 GitHub ↗ 上找到我。