我又拷打了一个 Agent 候选人：46 分钟模拟面试全程复盘 • Joye Personal Blog

时间:2026 年 5 月 28 日 | 时长:46 分 41 秒面试官:Joye(本人)| 候选人:H 同学形式:有偿模拟面试 · 围绕两个个人 Agent 项目 + Agent 基础八股 + 反问/复盘环节

作者:Joye | joyehuang.me ↗ | GitHub ↗ | 微信 joye050604

写在前面#

上一篇《一场 1 小时 19 分钟的 Agent 工程师模拟面试》也是我作为面试官的复盘——只是那场是双面试官,这一场是我 1v1 拷打 H 同学。

H 同学是付费约的模拟面试,目标方向 Agent 工程师。我用了和真实面试同样的强度——围绕他简历上两个个人项目深挖,后半段补 Agent 基础八股,最后留近 20 分钟做复盘和分享。

和上一篇相比,这场更聚焦在项目深挖 + 八股短板暴露的链路上,后半段的”反问 / Vibe Coding 装备学 / 简历建议”是我每次面试都会讲、但每次内容会基于候选人短板做调整的部分——这次专门补强了 H 答不上来的几块(RAG、Agent Evaluation、前缀缓存工程取舍)。

⚠️ 全文标注规则:

🟢 H 答得不错的 | 🟡 H 答偏/不完整的 | 🔴 H 没答上来/答错的

💡 = 我当场补的标准答案 / 正确思路

🔧 = 我事后对照 Anthropic 官方文档做的修正(发文前过了一遍,有几处我面试时也答得不够精确,坦诚标出来——知识更新太快了,这本来就是这行的常态)

Part 1 · 项目一:个人长期助手 Agent#

H 这个项目类似 Hermes——一个部署在 EC2 上的个人长期 AI Agent,核心是记忆系统(consolidation + memory.md)和前缀缓存优化。这部分是 H 最熟的,我也问得最深。

1.1 Consolidation(记忆沉淀)的触发频率 🟢#

我问:你说你做了 consolidate(沉淀),每次对话后 consolidate 的频率是多少?怎么判断的?

H 的回答:

consolidation 的触发不是按时间,而是按”新增信息数”阈值。
设置了一个新增信息数的阈值,达到这个数就触发一次 consolidate。
计入信息数的内容包括三部分:① 用户输入 ② React 循环后 assistant 的输出 ③ 一些 tool 的输出信息。
累计达到一定数量后,consolidate 就会进行一轮总结。

1.2 Consolidate 的输入到底是什么? 🟢#

我反复确认:你传入的既有 assistant 的信息,也有 user 的信息,对吧?你是对它们两个都做 consolidate 吗?

H 的回答:

全都塞进去——user 信息、AI 返回的信息都加进去累计。
consolidation 这一步会单独用一个 LLM(大语言模型) 来做。
它从这些信息里提取一些长期的事实之类的,再存到一个类似 memory 的 DB 库里面。

1.3 Consolidation 是不是一个独立 agent? 🟡#

我问:那这个 consolidation 是由另外一个单独的 agent 加它单独的系统提示词去做的吗?

H 的回答:

应该不算 agent,它就是一个很简单的工具调用。

我追问:这个 consolidation 步骤是在你主对话的 agent 里面,还是在哪里?执行 consolidate 这个 API 调用是谁发起的——是主 agent 还是那个额外的独立模块?

H 的回答:

不是主 agent。它是写死在工作流里的一个固定流程。
在一轮 React 循环结束后,它会做判断,判断要不要触发 consolidate。

🟡 我的复盘:H 这里表述有点绕,我追问了好几轮才确认清楚”到底谁来发起 API 调用”。其实他设计是对的——consolidation 是工作流里一个固定的、独立于主对话 agent 的步骤,由编排逻辑在每轮 React 循环结束后判断阈值并触发,使用单独的 LLM 调用(带专门的提取 prompt)。只是表达没绕到位。表达清晰度本身就是面试考点——尤其是当面试官追问”谁发起调用”这种核心权责问题时,模糊的回答会让人怀疑你到底是不是自己实现的。

1.4 上下文爆了怎么处理? 🟡#

我问:上下文爆了一般也会处理,你这边上下文爆了是怎么处理的?

H 的回答(分两块):

在 React 循环里,每调用一次之后会做一次检测,挂一个判断:查它有没有达到上下文窗口的 80%。
history 不是对历史记录判断爆了之后再摘要,而是 history 固定存多少条,一直固定在那里——从全量记录里拿最新的 N 轮塞进 prompt。
如果爆了,直接删:比如从 40 条直接砍成 20 条,还不行再砍成 10 条。
摘要这件事其实在 consolidation 里已经做了(consolidation 就是对这些信息做摘要,存进记忆库),所以不单独对”爆了”做摘要处理,两件事是分开的。

我追问:为什么是直接删掉呢? 🔴

🔴 H 没答上来。

💡 我当时的标准思路:直接 FIFO 砍掉旧消息的最大问题是信息丢失——被砍掉的轮次里可能有后续仍需引用的关键事实。更好的做法是:

砍之前先做一次摘要压缩(把要丢弃的旧轮次压缩成 1-2 条 summary 留在上下文里),而不是无脑删。

但摘要会引入一个前缀缓存失效的代价(见 1.6),所以工程上要权衡。

其实 H 的项目里之所以敢直接删是有道理的——因为 consolidation 已经把长期事实抽走存库了,被删的只是短期对话。这个论据他完全可以主动讲出来,但当下没意识到要把”我设计的 consolidation 已经兜底了”和”所以直接删是合理的”这两件事串起来。这是典型的”做了对的事但讲不出来”。

1.5 memory.md 是固定长度还是可无限增长? 🟢#

我问:你这个 memory.md(用户画像文档)是固定长度,还是可以一直增长的?

H 的回答:

memory.md 跟 **padding 层(缓存层)**绑定。
如果每轮对话结束都更新它,缓存就命中不了了。
所以 consolidation 会把那些长期的用户偏好、用户职业/工作之类的信息,异步写到 padding 层文件里。

我问:这个文档有没有设置上限?比如只能存多少条?还是可以一直累积?

H 的回答:

这个没有设置过上限。
因为它不是全部放进 prompt 的,而是有一轮检索,检索出相关信息再放进 prompt,应该不用担心爆的问题。

1.6 memory.md 在 prompt 中部 = 全量注入吗? 🟡#

我问(对着他的简历/项目文档问):你写的是”memory.md 作为用户画像位于 prompt 中部”,你是放整个 memory.md 吗?

H 的回答:

不是放整个的,这边写的有问题(简历/文档表述不准确)。
实际项目里应该是先做一轮检索,然后”记忆检索结果 + 用户画像”均注入其中——放进去的是检索出来的相关部分。

🟡 我的复盘:这是一个典型的简历踩坑案例。简历/文档上的措辞(“位于 prompt 中部”)和真实实现(检索后注入)对不上,被我当场抓到。简历上的每一句话都要能对应真实实现,否则就是被深挖的破绽——尤其是 Agent 方向的面试官几乎一定会盯着你写的每一个技术名词追问实现细节。

1.7 memory.md 该不该设上限?(开放设计题) 🟢#

我问:假设像 Hermes agent 一样,memory.md 是固定长度、完整塞进系统提示词。给你两个选择——① 有上限(比如 3000 token) ② 可以无限增长。你觉得哪个效果好?

H 的回答:

我觉得有上限更好。
因为无限增长无论如何都会造成资源浪费,而且可能有重复信息,导致模型注意力集中不了。

🟢 这题方向是对的(上限更好)。

1.8 有上限,但来了条真有用的新记忆怎么办? 🟢#

我追问:如果有上限,我现在已经到上限了,又检测出一条真的有用、需要存进去的记忆,怎么办?

H 的回答:

先做去重检测——新记忆和 memory 里已有的哪些重合,有没有重合部分。
如果基于业务需要实时更新,就更新进去。
如果没有重合,就和已有的内容做合并(归并),把能归并的归并,而不是原模原样地塞进去。

我追问:那你觉得合并是个好操作吗?

H 的回答:

合并肯定会造成信息失真。
但如果有 token 数限制,我觉得合并是有必要的操作(失真是为了换取空间的可接受代价)。

🟢 这一组答得不错——既给了方案(去重→更新/合并),又点出了 trade-off(合并 vs 失真)。这是我比较欣赏的一种答题结构:有方案 + 有取舍。

1.9 前缀缓存(Prefix Cache)还有什么提升技巧? 🟢#

我问:对于 prefix cache,你还有什么可以提升的技巧?

H 的回答:

核心思路:尽量找出每轮对话里”不变的地方”,把不变的内容放到前缀缓存能命中的位置,以减少 token 消耗。
举例:用户画像如果经常更新,就肯定无法命中缓存;但如果通过一个函数异步、定时更新(让它不频繁变),就可以放到缓存命中区。
所以这是个相对的、看怎么设置的问题——把易变内容和稳定内容分离,稳定的尽量前置。

🟢 这题答得好,抓到了”稳定前置 + 异步更新易变内容”的核心。

1.10 Plan 模式下如何不破坏前缀缓存?(Claude Code 场景) 🔴#

我问:你知道 Claude Code / Codex 有个 Plan 模式吧?在 Plan 模式下,我们希望限制工具——它不能有 edit 权限。但我又想保证前缀缓存一直存在,所以不能改变工具列表(否则从 plan 模式切回干活模式,缓存就失效了)。这个怎么办?

🔴 H 一开始说”这个我还真不知道”。 后来尝试回答,但思路错了——他以为”每轮能看见的 tool 是会变的、每次调用都重新组装当前激活的 tool”。

我当场纠正:如果 tools 不一样,前缀缓存就失效了。他简历里也写了”40+ 工具全量注入 schema”,这个 tool schema 应该放在前缀缓存部分,尽可能不要动它。

H 还反驳说”前缀缓存那部分和这个是分开的,工具部分每次都重新写”——这其实是他项目的设计,但我认为这个设计反而浪费。

💡 标准答案(我现场答得不够精确,这里基于 Anthropic 官方博客《Lessons from building Claude Code: Prompt caching is everything》 ↗补全):

Claude Code 的做法是:工具列表在 plan 和非 plan 模式下完全相同,字节级一致(byte-identical),没有任何 disable 标记或 schema 改动。
Plan 模式的实现方式是:EnterPlanMode 和 ExitPlanMode 本身作为两个工具存在于工具列表里。当模型调用 EnterPlanMode 后,通过 tool result 注入一个 <system-reminder>(作为后续消息追加,而不是修改 system prompt),告诉模型”现在是 plan 模式,你 MUST NOT 做任何 edit”。
这是一种**“软约束 / 信任式”设计**——模型物理上还是能调用 Edit、Bash 等所有工具,只是被指令明确告知”现在不要用”。对比 GitHub Copilot 的 plan 模式是物理移除 43 个工具(硬约束),Claude Code 选择了保留所有工具 + 用系统提醒约束行为,核心目的就是为了不击穿前缀缓存。
顺带补一个相关设计:Claude Code 还有 defer_loading 工具搜索机制 ↗——大量 MCP 工具不会全量注入 schema,而是只送轻量 stub(只有 tool name + defer_loading: true),模型通过 tool search 工具按需”发现”并加载完整 schema。这是另一种保护前缀缓存稳定性的方法。
核心原则:Tools 是缓存前缀的一部分,任何对 tool schema 的改动都会击穿整段缓存——所以工程上一切围绕”tool list 永不变”展开。

🔧 我自己复盘时的修正:我在面试中说成了”标记为 disabled / 静止”,这个说法不完全准确——Anthropic 的实际做法是 tool 列表完全不动,通过额外的 EnterPlanMode/ExitPlanMode 工具 + system-reminder 软约束 来切换模式。方向是对的(都是为了保前缀缓存),但具体实现细节我答得偏了。这也是一个反向案例——作为面试官也要敢承认自己答得不精确,知识更新太快了。

Part 2 · 项目二:音乐电台 Agent#

核心:歌曲语义检索链路 + 向量召回 + TTS 异步播报,做成一个”可交互的电台体验”。

2.1 用什么向量数据库?了解过别的吗? 🟡#

我问:你这个实现了歌曲语义检索链路、向量召回,用的是啥向量数据库?了解过其他的吗?

H 的回答:

用得很轻量,就是 SQLite。
听说过 Neoverse / Neo 系(口误,大概想说的是其他向量库)。
以及 PostgreSQL(PGSQL)应该也有一个向量库(指 pgvector),之前看到过。

🟡 我的复盘:向量库这块储备明显不足。常见的应该能脱口而出:Pinecone、Milvus、Qdrant、Weaviate、Chroma、pgvector、FAISS 等,并能说出各自适用场景(本地/云、规模、是否需要混合检索)。我没继续逼问,因为后面 RAG 的痛点他完全答不出,这块就跳过了。

2.2 向量召回最大的难点 / RAG 最大的痛点? 🔴#

我问:你觉得做向量召回过程中最大的难点是什么?或者你觉得现在 RAG 技术最大的痛点是什么?

🔴 H 没答上来。 他只说了”可能会召回一些不相关的”,痛点这块”没怎么了解过”。

💡 这题的完整答案我放在 Part 4 的 RAG 大科普里(复盘环节我专门补了一大段),见 4.5。

2.3 “120 秒黑盒等待”是什么?怎么解决的? 🟢#

我问(指着他简历):你这里写”未解决 / agent 同步 120 秒黑盒等待""用户可在每轮推荐后确认或跳过,配合 TTS 异步”——这是什么东西?

H 的回答:

问题在于:整条链路是整体生成的。如果你点一首歌,要等整条链路全部生成完才返回,用户就得一直干等(120 秒黑盒)。
他的解法:它生成一首歌就先告诉你这首歌;如果你决定加入接下来的播放歌单,点一个”确认”,它就加到歌单里,后续步骤放到后台去做。
这样把”长链路同步等待”改成了”先返回 + 用户确认 + 后台异步处理”,消除了黑盒等待。

🟢 我听完说”哦,我懂了”——这个异步交互设计是项目二的亮点,讲清楚了。

听完之后我就没继续问项目二了,原话:“我感觉项目没啥好问的呀,问基础八股吧。” → 项目二整体深度不足,被快速带过。这也是一个提示:一个项目如果只有一个亮点,十分钟就被问穿;真正经得起拷打的项目至少要有 3-5 个能讲深的设计决策。

Part 3 · Agent 基础八股#

3.1 Agent 是如何感知到 Skills 存在的? 🟡→🔴#

我问:Skills——agent 是如何感知到 skills 的存在的?

H 的回答:

应该有一个前置选项,类似你用 client 时可以选一些 skill 开(on)或关(off)。
用的过程中,肯定不是把全量塞进去,而是放它的一些 describe(描述);如果觉得这一轮对话会用到,再像调用 tool 一样把 skill 完整读出来。

🟡→🔴 我当场评价:“讲了一堆,没讲到点上。”

💡 我给的标准答案(对照 Claude Skills 官方文档 ↗核验过,基本准确):

Skill 有一个固定的模板,前面三行是它的 frontmatter——包含它的 name 和 description。
这部分(name + description)在 session 启动时就被加载到 system prompt 里——所以 LLM 一开始就能”看见”所有 skill 的存在。Anthropic 官方原话:“Provides just enough information for Claude to know when each skill should be used without loading all of it into context.”
当 LLM 决定要用哪一个 skill 之后,才通过文件读取(bash Read)把 SKILL.md 完整 body 加载到上下文(第二级渐进披露 / progressive disclosure)。
如果 SKILL.md 还引用了 references/ 或 scripts/ 里的具体文件,模型可以再进一步按需加载(第三级)。这是为什么一个项目可以挂几十个 skill 但启动开销很小——每个 skill 启动只占 ~30-60 token(frontmatter)。
结论:这非常考验你的 skill description 写得怎么样——因为模型是靠 description 来判断”这一轮要不要触发这个 skill”的。Description 写得不准,模型要么误触发、要么漏触发。

3.2 Skill 的 description 该写长还是写短? 🟢#

我接着追问:假设一个 skill 是”做前端设计”,你觉得它的 description 应该写详细(长)一点,还是简洁(短)一点?

H 的回答:

看 skill 内部的内容:
- 如果它是一个大方向的指导,可以简略描述——这样只要”有一点相关”就会被拿出来参考。
- 如果它面对的是很细节的场景,就写详细一点——这样只有用到的场景”更加符合”时才会被拿出来用。

🟢 这题答得不错——抓到了”description 的详略决定了 skill 的触发粒度”这个核心。3.1 没答上来但 3.2 接住了,说明他对底层逻辑其实有感知,只是没接触过具体实现。

3.3 了解 Agent Evaluation 吗? 🔴#

我问:你有没有了解过 agent evaluation(评估)的部分?

🔴 H 直接说**“没有怎么了解过。”** 这是我点名要他补的重点之一(见 Part 4 复盘清单)。

3.4 MCP 和 Skills 是什么关系? 🟡#

我问:你觉得 MCP 跟 Skills 是什么关系?

H 的回答:

MCP 是提供一些方法/工具的;Skill 是一套方法论。
两者是方法论 vs 实践的关系。

🟡 我的复盘:这个回答比较含糊。更准确的区分:

MCP(Model Context Protocol) ↗:一个标准化协议,让 agent 连接外部工具/数据源(本质是”工具/能力的接入标准”)。

Skills:一套封装好的、可渐进加载的能力包(SKILL.md + 资源),解决”何时、如何使用某类专业能力”。

简单说:MCP 解决”接什么、怎么接外部能力”;Skills 解决”模型在什么场景该调用哪套封装好的做法”。 两者可以组合。

3.5 给一个 Agent 项目省 Token、减少开销,有哪些方法? 🟡#

我问:假设一个商业研究 agent,目标是省 token、减少开销,你一般有哪些具体方法?

H 的回答(两点):

Tool 渐进式加载:不把全部 tool 放进上下文,做一个 tool 摄取(检索)工具,渐进式地把需要的 tool 拿出来。
强制格式化输出:在 prompt 里给模型加限制,让它输出格式化的数据,减少交互的 token 消耗(强制约束)。

我追问:强制约束除了靠提示词,还有什么方法?

H 的回答:

在输出结束后做一层校验层——校验它是不是按格式输出的,没通过就回去再做一轮(retry)。

🟡 我的复盘:答的两点都对,但不够全。其他可补充的省 token 手段:前缀缓存命中率优化、上下文压缩 / 摘要、用便宜模型做子任务(模型分级)、检索注入而非全量注入、减少冗余的 system prompt、batching、限制 max_tokens 与 reasoning 长度等。其中模型分级和前缀缓存优化是两个最大头,他没主动提到,有点可惜——尤其前缀缓存他自己项目里就在做。

3.6 多 Agent vs 单 Agent,什么时候用哪个? 🟡#

我问:多 agent 跟单 agent,你会在什么情况下用哪一个?原因?优缺点?

H 的回答:

职能分得不开的项目 → 单 agent:比如个人助手、电台这类,职能没分开,单 agent 就够了。而且各种调用之间的上下文是共用的,效果也会更好。
职责分得很开的大项目 → 多 agent 协作:比如这边做文档、那边写代码、另一边做 review,各模块职能分得很开;如果全并在一起,上下文会很乱。

我追问:像研究场景的 workflow(先调研→读文献→起草一→起草二→review),你觉得这算多 agent 吗?

H 的回答:

我觉得可能不算 / 不会用到多 agent,因为它的工作流比较固定,不需要多个 agent 去商量谁先谁后,也不需要一个总 agent 去判断该调用哪个 agent。

我没否定他,补充了一句”它们像 workflow 一样编排的这种”(即固定编排的 workflow 是另一种形态,介于单 agent 和真正的多 agent 之间)。

我继续追问:除了”分清职责”,多 agent 还有什么优点?说一个优点一个缺点。

H 的回答:

缺点(他先说的):多 agent 协作时,如何协调每个 agent 之间的交互是个很困难的点。
优点:可以完成复杂任务。

🟡 我否了”完成复杂任务”这个优点,原话:“说了半天就是多 agent 复杂、单 agent 简单。” 这是一个典型的”看似回答了实际什么都没说”的答案——单 agent 加上工作流编排同样可以完成复杂任务,这不是多 agent 的差异化优势。

💡 多 Agent 的两个核心优势(我给的答案 + 事后精修):

可以换模型 / 多模型组合:对一个公司项目来说,多模型非常重要——
- 不同功能用不同模型:文本功能、reasoning 功能、生图功能各用合适的模型。
- 省钱的真正逻辑:不是”多 agent 本身省钱”,而是**“多 agent 让你能合理使用便宜模型干杂活,不必为所有子任务都付顶配模型的钱”**。比如 Claude Code 的 Research 系统用 Opus 4 做编排、Sonnet 4 做 subagent——总 token 量上去了,但单 token 价格降下来,综合是合理的。
可以后台并发:多 agent 可以同时跑,节省 wall-clock time(墙钟时间)。单 agent 哪怕同一任务也只能串行跑完,多 agent 可以并发处理。
- Anthropic 官方数据 ↗:他们的 Research 系统(Opus 4 lead + Sonnet 4 subagents)比单 agent Opus 4 性能 高出 90.2%,核心机制就是并发拆解 + 每个 sub-agent 独立 context window。

🔧 事后精修的一句话:我在面试时把”省钱”作为多 agent 的核心优势讲了出来,这个论点严格说是有偏的——根据 Anthropic 官方数据 ↗,多 agent 系统总 token 消耗大约是单 agent 的 15 倍,绝不是”省钱”的架构。它真正的价值是**“用更多 token 换更好的效果 + 更短的墙钟时间”**,而”换便宜模型”只是降低单位 token 成本的优化手段。所以更精确的说法是:多 agent 的优势是并发性能和模型组合的灵活性,不是绝对省钱。

3.7 多 Agent 有哪几种编排 / 通信方式? 🟡#

我问:多 agent 大概有哪几种编排方式或通信方式?

H 的回答(三种):

主从式:一个主 agent 判断当前要调用哪个 agent,底下几个 agent 并列。
顺序编排:类似固定工作流,让 agent 按顺序跑。
循环式:类似 React 那种,跑完检测,不过就再跑一轮。

🟡 我说”大概知道你意思,但不太对”,给出更清晰的分类:

💡 多 Agent 编排 / 通信方式(我给的答案):

像调用工具一样调用 sub-agent:主 agent 告诉 sub-agent 要干嘛,把任务交给它。在 Claude Code / Codex 里会用便宜的模型去做搜索、读代码这类任务,sub-agent 干完后做一个简单摘要返回给主 agent。
Agent 之间互相交流 / 共享文档:做一个中间的公用文档,限制它们”有什么想法就写在这个文档里”,通过文档通信。
平级 or 主次:核心是看有没有主次之分——可以是主从,也可以是平级。

3.8 你用 AI 写代码有什么自己的技巧? 🟢#

我问:你平时自己用 AI 写代码,有什么技巧?

H 的回答:

让 AI 先跑一个类似需求文档的东西,让它先清楚现在要干什么,分步走。
让它先把工作链路列出来再去做,这样不容易做到一半就不知道自己在干什么。
把重复的规范直接放到 CLAUDE.md 这种文件里,作为固定上下文,每次不用再声明,它会自己读取。

🟢 这题答得务实、有手感(需求先行 + 链路规划 + CLAUDE.md 固化规范)。这是个开放题,本来就没有标准答案,但他答得让我觉得他真的用过。

Part 4 · 复盘 + 反问环节(我的”独家私货”)#

面试结束后,我花了近 20 分钟做复盘并分享实战经验。这部分是整场对 H 最有价值的内容,也是我每次模拟面试都会讲、但很少有人系统写出来的部分。

4.1 给 H 的待补知识清单#

🔴 RAG:完全不懂,是最大短板。
🔴 Agent Evaluation(测评):要去补。
🟡 OpenClaw / Hermes / Skill 这些较新的东西:稍微过一下,面试时能”垂壁(应付/接得住)“就行。
整体反馈:他对项目突然有点不熟(他自己说前两天还熟),需要再过一遍。

4.2 反问环节:要有”攻击性”#

我反复强调过——反问时间一定要有攻击性,尤其面对创始人 / CEO 时可以直接挑战。

① 直接问产品竞争力(前提:你了解这个赛道和产品)

直接问:“你这个产品对比竞品有什么优势?”
我自己二面时就这么问过,和对方讨论了半小时。
逻辑:如果一个创始人对自家产品都没信心、说不清和竞品的差异,这家公司可以不用看了(可能纯来骗融资)。

② 问项目发布周期(尤其初创)

问清楚:产品现在是开发中、内测(分一轮/二轮内测)、还是已上线?
类比游戏的内测分轮,要问到具体阶段。

③ 问商业模式 / 收入预估(注意:不是所有人都愿意答)

可以问下个季度预期的 ARR(年收入)、MRR(月收入) 量级、目标用户量级、目标收入。
收入模式也有讲究:不能凭空定价,要看竞品的收费逻辑——是订阅制还是买量制(API 计费)。

④ 问团队规模

问公司总人数 + 技术团队人数。
问你的带教是谁——一定要问清楚,因为很多岗位号称 agent 开发,进去后干的是传统开发,不碰 agent。

⑤ 聊增长(我个人偏好)

我喜欢聊增长、目标客户。
观点:初创早期技术团队不需要那么多人,反而更需要增长团队——产品做出来不是终点,怎么宣传、让大家知道并使用才是关键。

4.3 不会的题怎么”软处理”#

我分享了几招应对不会的问题:

① 借”改进空间”扯开

比如被问记忆系统,可以说:“我确实觉得我的记忆系统做得不怎么样,还有很多改进空间。” 然后顺势讲你的思考。

② 主动讲简历外的东西

我在面试里讨论过——简历上写的东西只占 30%~50%,我更想从这一小时里问出简历上没写的东西。
所以:项目有迭代(已经到版本二、版本三,但简历还停在版本一),完全可以主动讲。
关于记忆这种前沿话题,可以主动说:“我最近看了一些比较新的论文,有一些想法……”
- 好处一:证明你对项目思考很深、在持续迭代,而不是做完就丢简历上。
- 好处二:体现你关注前沿。
- ⚠️ 但要看人、把握节奏——我今天早上自己被打断好多次。

③ 弱智八股直接承认 + 用 AI 视角化解

我举了个例子:被问”线程和进程的区别""进程间通信怎么做”,我直接说忘了 / 不知道。
但补一句:“现在有 AI,我在工程实践 / 实习中遇到这个问题,我肯定会用 AI 搜索并解决。如果是我完全没接触过的领域,我担心单个 AI 有幻觉,我可以用多 agent 来交叉验证。”
这种回答听起来很舒服,又能巧妙躲过弱智八股。
我的态度:八股本来就弱智,现在有 AI 谁还问传统八股(但仍有些面试官会考,见简历建议)。

4.4 反问环节其他可问的问题#

① 问培养制度(看公司、看你自己的表现)

前提:先评估你这场面试表现。如果自己都觉得不一定稳过,问这种问题没意义,不如问别的。
有把握时可以问:公司有没有完整的实习生培养制度?带教是谁?

② 用”挑战问题”倒推面试表现

问:“对于你们招聘的这个岗位,你觉得实习中会遇到的最大挑战是什么?”
这种问题适合问大厂/中厂(它们通常不会在面试最后直接透露你的表现)。
你可以通过这个问题的答案,倒推面试官对你今天表现的评价。

③ “进公司除了钱还能获得什么?”——慎问

这个问题等你 offer 很多的时候再问比较好,否则有点不合适。

4.5 RAG 大科普(把 H 没答上来的全补上)#

因为 RAG 这块 H 完全不懂,我专门讲了一大段。这是 RAG 完整知识地图,也是我自己每次准备 RAG 题都会过一遍的清单:

RAG 整体流程三步:① 向量化 → ② 存向量库 → ③ 召回。每一步都能深挖。

第一步:怎么存向量(向量化 + 切块)

维度选择:维度更多 = 信息更多,但存储成本也更高——这是 trade-off。
关键认知:向量距离只是语义距离的”近似”(我在面试时说成”向量近 ≠ 语义近”,严格意义上不完全准确——embedding 模型本来就是为了让”向量近 ≈ 语义近”而训练的;但这个近似经常失真:同形异义、否定语义、domain mismatch、训练分布外的内容,都会让向量距离和真实语义距离脱钩。RAG 的痛点很大一部分就藏在这个”近似失真”里)。
切块策略(chunking):
- chunk size:一个块切多大的策略。
- chunk overlap:每个 chunk 之间要有重叠,避免”一刀切”切坏语义。常见做法是 10-20% overlap(比如 500 token 的 chunk 配 50-100 token overlap)。
  - 我面试时举的”苹果”两个字被切开的例子,严格说不太准——现代 chunking 是 token 级或字符级,不会真的把”苹果”两字劈开。更准确的例子:“苹果公司发布了新品。这款产品搭载了 M5 芯片”——如果在两句中间切,后一个 chunk 失去主语,就召回不到”苹果公司发布 M5”这个语义。这才是 overlap 解决的真正问题。
- late chunking:先把整篇文档先向量化(用长上下文 embedding 模型),再去切块——这样每个 chunk 的 embedding 都”知道”全文上下文,保留了长距离语义信号。
- PDF / 图片如何切块:这是个专门的难点(某些工具/方案有处理)。
- embedding 模型选型:用哪个 embedding 模型也是可以深聊的点。

第二步:存(目前没太多可说)

第三步:召回(retrieval),可优化点最多

query 优化:user query 进来之前可以做改写/扩展。
召回数量 + rerank:比如召回 Top 50,要不要 re-rank?re-rank 基于什么?都可优化。
召回质量评估(两个维度):
- 召回率(完整性):假设有 100 个正确答案,你是不是 100 个都召回了?
- 排序质量:召回回来后的排序好不好。

工程层面

模型降级策略(LiteLLM ↗):在项目里跑 LiteLLM 做模型降级——第一个模型服务商挂了,自动切换到第二个。

💡 这一整段直接对应 2.2 那道 H 没答上来的”RAG 最大痛点”——痛点就藏在每一步的 trade-off 里:向量近≠语义近、切块边界破坏语义、召回率 vs 排序、维度 vs 成本。

4.6 把面试当”交友 / 交流”,别被单方面拷问#

这个领域很新,面试可以当成交友机会,压力别太大,当聊天去交流。
把握面试节奏,别让它变成单方面拷问——拷问答案本身没意义,万一没拿到 offer 还被拷打一小时,纯亏。
反问技巧:面试官问你(比如”vibe coding 有什么技巧”),你答完三句话,就反过来请教面试官:“我这方面不太了解,想请教一下您有什么见解?”
- 稍微”舔”一点——面试官只要不是脑子有问题,基本都愿意分享。

4.7 Vibe Coding 实操环节的”装备”技巧#

我分享了屏幕共享做 vibe coding 题的实战技巧:

一般形式:共享屏幕现场 vibe coding。
核心心法:无论题目多简单,一定要把高级装备全堆上。
- 打开你最贵的 vibe coding 软件。
- 一定要装 skills(别管好不好用,装上面试官就大大加分)。
- 或者用 MCP 也行——反正高级的东西全堆上。
- 装 skill 别去 GitHub 装,去 skills.sh ↗(Vercel 出的那个网站)装。
利用等待时间:vibe coding 有等待时间,可以同时开另一个模型(Claude / ChatGPT,别用 Gemini,太路边)聊技术选择、搜竞品方案。
我的真实案例:被要求搓一个”视频剪辑框架”(我和合伙人做的项目),等待时就和面试官聊赛道其他玩家、上网搜竞品。

4.8 简历修改建议(结尾的零散建议)#

简历上要写技术栈(H 漏写了)。
专业技能放到最下面,项目写在上面。
专业技能可以写多一点。
项目尽量上线:做个网站或挂上线;实在不行把 repo 链接挂上去。
- (H 的情况:项目二还没做好,计划暑假前做完后挂链接;它是个 client 工具,可能没有前后端。)
后端八股还是要背一些——有些面试官(我吐槽的”智障面试官”)会考。

一句话总结(我作为面试官的评估)#

维度	H 同学的表现
🟢 答得好	记忆系统 consolidation 机制、前缀缓存稳定前置思路、memory 上限去重/合并 trade-off、异步交互设计、skill description 详略判断、AI 写代码方法论
🟡 答偏/不全	consolidation 表述绕、向量库储备不足、MCP vs Skills 含糊、省 token 不全、多 agent 优点没答全、编排方式不准
🔴 没答上来	为什么直接删上下文、Plan 模式保前缀缓存、Skills 感知机制(frontmatter)、Agent Evaluation、RAG 全套

我建议 H 最需要补的三块:RAG(从向量化到召回 rerank 全流程)、Agent Evaluation、前缀缓存与工具列表的工程权衡。

我自己最想分享的核心心法:反问要有攻击性、不会的题用”AI 视角 + 改进空间”软处理、把面试当交流而非拷问、vibe coding 堆满高级装备。

写在最后(我作为面试官的几点感受)#

每带一个候选人模拟面试,我都会更深一层理解——

Agent 工程师面试的核心,从来不是”你知道多少”,而是”你能不能讲清楚自己做过的事”。

H 同学的项目其实做得不错——consolidation 机制有思考、前缀缓存有手感、异步交互是真亮点。但有几次他明明做对了事,却讲不出”为什么这么做”(比如直接砍上下文那道题,他完全可以用”我有 consolidation 兜底”来辩护,但没意识到)。

这是大多数候选人共同的问题:做完即止,缺少”反向 ssh 进自己脑子里”的复盘步骤。

如果你也在准备 Agent 方向的面试,我的建议是:

每个项目的每个设计决策都问自己一遍”为什么”——能用一句话说清楚的,才算真的懂。
简历每写一句话,问自己”如果被深挖三层,我答得上来吗”——答不上来就别写。
RAG / Agent Evaluation / 前缀缓存这三块,是 2026 年 Agent 面试的高频深挖区——别等被问到才补。
反问环节有攻击性,不是为了卷面试官,是为了筛公司——这点很多人不敢做,但效果惊人。

关于付费服务#

后续我会持续整理这种有偿模拟面试复盘。每一篇都会尽量保留真实追问链路、候选人的原始回答、我当场的判断、以及事后补充的标准思路。

模拟面试不只是”练答题”,更是让你以最低风险的方式经历一次”被认真追问”的完整过程。经历过一次之后,你对真实面试的恐惧会下降一个数量级。

如果你也在准备 Agent 方向的求职,但不知道简历怎么改、项目怎么讲、面试怎么准备,我目前提供这三项 1v1 服务(具体价格请联系咨询):

服务	价格档位	适合谁
简历修改	￥	已有简历但不知道怎么”讲”才能让面试官眼前一亮
1v1 模拟面试	￥￥	即将面试,需要一次完整的实战演练 + 复盘
学习路线 / 入门陪跑	￥￥￥	完全零基础或缺乏方向感,需要持续 1-3 个月的周度陪跑

联系方式:微信 (备注”付费咨询”或”模拟面试”)。

—— Joye · joyehuang.me ↗