这是一份模拟面试复盘。候选人是一位 211 院校的同学，简历上挂着两个 AI 项目：一个是基于 LangGraph 的多 Agent 健康饮食助手，一个是 Agent 长期记忆引擎。我和另一位面试官 W 一起面了他 80 分钟。聊完之后我觉得这场面试值得整理成一篇博客——不是因为候选人答得多好或多差，而是因为它非常完整地暴露出了”用 AI 培训项目堆简历”这种主流路径的问题，也顺带过了一遍 Agent 工程师面试在 2026 年应该考察什么。
这篇文章会写得很长，我会把所有问到的题目、候选人当时的回答、我们的评价、以及”如果是我会怎么答”全部写进去。后面如果还有有价值的模拟面试，我也会陆续整理。
写在前面：为什么要写这篇#
我最近在帮我的 mentor 筛全栈 Agent 开发实习的简历、负责一面，所以面了不少同学；也被一些粉丝预约做有偿模拟面试。这场是其中一场，候选人是后端方向、想转 Agent 开发岗，简历上写了两个项目。整场面下来，我和 W 给的整体评价是：通过培训班 / 开源项目改改这条路学 Agent 开发，候选人很难形成自己的思想，深度不够——面试官一问就漏。
这不是这位同学的个人问题。培训班、横向项目、GitHub 拉一个开源项目改改产出的简历，普遍都是这个状态。所以这篇博客不是来嘲讽某一份简历的，而是想认真讨论：如果你想做 Agent 工程师，你应该如何准备项目、如何回答面试题、以及在写下任何一行简历之前需要先想清楚什么。
一、项目本身的问题：你解决了什么真实问题？#
候选人的两个项目：
- 项目一：AI 健康管家，下属饮食推荐模块。LangGraph 编排，Router + 多 Agent 分层设计，意图识别后分发到 Text2SQL Agent / RAG Agent / 图谱 Agent，最后汇总。检索层做了 GraphRAG 等三条混合链路。三层记忆模块。基于 Qwen3-8B 微调。
- 项目二：Agent 长期记忆引擎。三阶段抽取（摘要→实体→关系），写入 ChromaDB + Neo4j；图向量混合检索（向量召回 + BFS 扩展 + 语义重排）；基于艾宾浩斯遗忘曲线做记忆衰减；存储时做语义相似度分级、矛盾检测、相似合并。
听起来非常像那么回事。但 W 在听完后只问了一句话就让整个项目站不住（这里针对的是项目一——它的输入只有两种：非结构化的菜谱内容，或者结构化的营养成分表）：
“如果是我，我用豆包就能解决，为什么一定要做这个？“
为什么这个问题这么致命#
招人的时候面试官想看到的是”你识别了一个真实问题 → 选用了合适的技术 → 解决得比现成方案好”。项目存在的合理性 = 真实问题 × 现成方案的不足。
我真心建议大家从两个方向找项目：
- 从自己身边、个人遇到的真实需求出发——你能讲清楚”我为什么要做这个”，整个项目的故事线就立住了。
- 深度体验一个开源 Agent（比如 Hermes），找到它的不足，做革命性的二次开发——这个比较难，但含金量极高。
现在有了 AI，从 0 搓一个项目的成本已经变得很低很低了，没必要去抄。
候选人的项目走的是反过来的路径：先决定要用 LangGraph / 多 Agent / GraphRAG / 图向量混合检索 / 微调，然后找一个场景把这些技术塞进去。“AI 饮食推荐”这个场景豆包、ChatGPT、Kimi 直接就能解决，他做的所有架构上的复杂度都没有对应的回报。
怎么改#
W 的具体建议是：“换汤不换药”——技术栈可以保留，但场景必须换成一个真正需要 Agent 的场景。比如：
- 深度调研类（DeepResearch 那种，多步检索、跨源信息整合、需要规划）
- 多模态内容创作
- 垂直领域的复杂任务自动化（不是 QA 能解决的）
简历上的项目标题不要叫”AI 健康管家”——这个名字本身就在告诉面试官”这是一个不需要 Agent 的场景”。一个真正需要 Agent 的场景，你在面试里能聊的东西也会多很多——架构、决策、踩坑、改进，全都有得讲。
给所有 Agent 求职者的建议#
写项目之前先问自己三个问题：
- 这个场景用 ChatGPT / 豆包 / Claude 直接对话能不能解决？如果能，请换场景。
- 我用的多 Agent 架构相比单 Agent 有什么实质收益？如果说不出来，请改成单 Agent。
- 我用的每一个技术选型（向量库、图库、Redis、微调、RAG）能不能讲清楚”为什么是它，不是别的”？讲不清楚的，要么删掉，要么补功课。
二、那些被反复问到的”为什么”#
整场面试里，W 和我问得最多的一类问题就是”为什么你选 X 而不是 Y”。这是 Agent 岗面试官最喜欢的题型，因为它一句话就能区分”真正用过、踩过坑”和”看博客抄简历”。
候选人在这一类问题上几乎全军覆没。下面把每一个”为什么”问题展开。
2.1 为什么用 Milvus / ChromaDB？它们的区别是什么？#
候选人的回答：“Milvus 适合数据量比较大的，ChromaDB 适合数据量比较小的。其他的没太了解。”
为什么这个问题重要：向量库是 RAG / Memory 类项目的核心存储，选型直接决定性能、成本、运维复杂度。面试官问这个不是为了听你背参数，而是看你”为了项目做过哪些技术对比”。
应该如何回答：至少要能说出几个维度的对比——
- 部署形态：Milvus 是工业级分布式部署，ChromaDB 单机起步可以纯 embedded 使用
- 生态：Milvus 有完整的 SDK / 监控 / 运维工具链；ChromaDB 简单但生态薄
- 替代品：pgvector（本质上是 Postgres 插件，可以减少一套基础设施）、Qdrant、Weaviate、Pinecone
- 更轻量的选择：sqlite-vec / sqlite-vss 也支持向量检索——对于个人项目的数据集，难道不是 SQLite 就够用了吗？
更高分的答法是直接挑战这个选型本身：“其实我项目这个数据量，pgvector 完全够了，不用单独起一个向量库。“——这才是面试官想听到的”工程判断”。而不是”刚好选到了这个技术，或者项目本身就用的这个技术”。
实际改进方向：我不需要你说清楚 HNSW 和 IVF 的索引细节，但我想听到你在选择这个技术之前是做过对比、有过思考的。直接找一个 AI 给你讲讲主流向量库对比，大概知道就可以了。这里也推荐我博客的 notes 区域 joyehuang.me/notes ↗——有很多相对碎片化的知识，是我平时的积累，刚好有一篇就是在讲向量化数据库对比的。
2.2 你这个多 Agent 各个 Agent 用的是不同模型吗？#
候选人：“没有，全部都用 Qwen 一个模型。”
为什么这个问题重要：在多 Agent 系统里，模型选型应该按 Agent 的职责来分。意图识别这种简单分类任务用小模型 / 便宜模型，复杂推理任务用大模型，长文本摘要用 long-context 模型。
更尖锐一点说：如果你的多 Agent 本质上是个 workflow 编排、agent 之间没有通信，那你不做模型分级，这个多 Agent 的意义是什么？ 反过来，如果你做了模型分级，至少能讲出几个收益：
- 成本控制——这是生产项目必须考虑的
- 能力匹配——多模态场景可以接入 Gemini 系列，代码场景接 Claude，国内合规场景接 Qwen
- 体现你尝试过比较多的模型——起码大概知道每个模型各自擅长什么
很多人会觉得”用了多个模型”这个回答比较一般，但其实我非常认可这个答案——它说明你真的有在生产视角思考问题。
应该如何回答：举一个具体场景，比如”意图识别用 Qwen3-7B，因为延迟要求低、任务简单；汇总输出用 Claude Sonnet 或 GPT-4，因为需要语言组织能力；后台异步摘要用便宜的 Qwen-Turbo，因为对实时性没要求”。
这一点引申到后面我们聊的”Agent 成本控制”——后面会展开讲。
2.3 多 Agent 之间到底有没有”交流”？#
我问的：“你这个 Agent 之间有没有交流？除了汇总环节有没有彼此通信？”
候选人：“其实没什么交流，就是一个 workflow，编排好的。”
我：“那你这个其实不算多 Agent。”
为什么这个问题重要：业界对”多 Agent”的定义是有共识的——Agent 之间需要有自主决策、互相调用、互相通信。一个固定 router 把任务分发到几个独立处理器、最后汇总的，这叫 Workflow，不叫 Multi-Agent。这两个词在 Anthropic 那篇 Building Effective Agents ↗ 之后基本定型了。
应该如何回答：诚实承认这是一个 Workflow，然后讨论”如果要改造成真正的多 Agent 应该怎么做”——比如让 Agent 可以反向调用其他 Agent、可以发起追问、可以协作完成一个复杂任务。
更进一步，可以反思：“其实我这个场景不需要多 Agent，单 Agent + 工具调用就能解决。” 这种自我修正的能力比硬撑着说自己做的就是多 Agent 要值钱得多。
面试切记两件事：
- 不要嘴硬。被问到不熟的就承认，硬撑只会被钓鱼问到死。
- 不要硬说培训班项目是自己写的。面试官很清楚你这个项目是自己写的还是培训班抄的，如果你被识破后还继续坚持，那就从”项目深度不够”升级成”诚信问题”了。
2.4 单 Agent 和多 Agent / Router 编排的优劣？#
我接着问：“如果把你这个项目改成单 Agent 你会怎么设计？以及单 Agent 和你目前这个编排各自的优缺点？”
候选人答了一些”prompt 隔离、focus 在自己任务”之类的东西，但没说到点上。
应该如何回答：
多 Agent / Router 编排的优势：
- 上下文隔离，每个 Agent 只看自己任务相关的内容，不会被无关信息干扰
- 每个子任务可以单独优化 prompt、单独换模型
- 并行——独立任务可以并发执行
- 可观测性好，知道是哪一步出了问题——但这一条需要你主动设计一整套观测体系，否则出问题还是抓瞎。如果你的项目里做了 replay（可重放调试），那真的是个大加分项
多 Agent / Router 编排的劣势：
- 整体延迟高（每多一步调用就多一次网络往返）
- Token 消耗呈倍数增加（上下文要在 Agent 之间传递）
- 路由本身可能错（意图识别错了一切都错）
单 Agent 的优势：
- 简单、延迟低、成本低
- 模型自己看到全部上下文，可以做更全局的判断
- 现代大模型的 function calling 已经强到大部分场景单 Agent 就够
- Skills 加持——单 Agent + Skills 这套组合在 Claude Code 之后基本成了新范式（后面 3.5 会展开）
单 Agent 的劣势：
- 上下文容易爆炸
- 模型在长上下文里容易丢失早期信息
- 一个 prompt 要塞所有职责，容易写成屎山
记一个 2026 年的趋势：业界整体在从”花式多 Agent 编排”往”单个强 Agent + 好的工具 + 好的上下文工程”回归。Claude Code、Cursor Agent、Cline 都是这个范式。
2.5 意图识别 90.6% 准确率怎么算的？#
候选人：“构建了大概 200 个问题，跟标注答案比较得到的。”
为什么这个问题重要：所有简历上的”准确率 90%+“都会被问。没有 evaluation 体系的 Agent 项目就是耍流氓。
应该如何回答：要能讲清楚——
- 测试集是怎么构建的？覆盖了哪些 case？分布如何？你为什么选这些 case？这些 case 能体现你想测试的能力吗？——这是最容易被追问的，“我随便造了 200 个”和”我覆盖了 5 类常见意图 + 3 类边界情况 + 2 类对抗样本”是完全两个档次
- 评估指标是什么？只看准确率？还是有 precision / recall / F1？
- 评估是怎么自动化的？每次改完 prompt 怎么回归？
- 边界 case 是怎么处理的？识别不出来时怎么 fallback？
候选人提到了”识别不出来会走 Text2SQL 兜底”——这是个加分点，但没展开讲。
改进方向：去看一下业界 eval 工具——LangSmith、Braintrust、Promptfoo，自己跑一遍，理解 eval 平台到底解决什么问题。
2.6 为什么用 Redis？#
候选人：“因为 LangGraph 节点状态可以存 Redis，Redis 支持 TTL 做记忆过期。”
W 的反驳直接而精准，原话大意：
“如果只是为了 TTL，不应该用 Redis。Redis 的 TTL 是为高并发线上业务设计的。用户数据是整个系统里最宝贵的资产，记忆过期不应该是删掉，应该是 archive 掉。 Redis 真正的用途是跨服务节点的状态一致性——缓存、分布式锁、会话级状态隔离。”
为什么这个问题重要：这是一个非常典型的”堆技术不思考”案例。Redis 是后端老朋友，写在简历上看起来很专业，但用错了场景反而暴露你不懂 Redis 真正的定位。
应该如何回答：在 Agent 项目里 Redis 的合理用途包括——
- 缓存：模型响应的缓存、向量检索结果的缓存
- 分布式锁：多 Agent 并发写同一份记忆时的锁
- 会话级状态隔离：用户在 Web 端和 App 端同时登录时的会话状态同步
- 限流：API 调用配额管理
- 临时 checkpoint：LangGraph 的运行时状态快照（这个候选人答到了，但没强调”临时性”）
记忆数据本身应该存到持久化的存储里——向量库、图库、关系库都行，永远不要把”用户的长期记忆”作为可以被自动 evict 的缓存数据来对待。
2.7 PostgreSQL vs MySQL，最大区别是什么？#
候选人：“没怎么对比过，PG 是企业级，功能比较强，可以加 pgvector 当向量库用。”
W 的展开非常实用：
“现在起新项目基本不用 MySQL 了。pgvector 一上等于把 Milvus 干掉了；jsonb 存 JSON 比较友好；地理空间、时序数据支持好；一部分场景可以替代 Elasticsearch（不过分词器场景还是得用 ES）。”
为什么这个问题重要：这是 2025-2026 年后端选型的实质性变化。如果你简历上写”熟悉 MySQL”但不知道 Postgres 现在在新项目里的地位，你的认知是滞后的。
改进方向：
- 用 PostgreSQL 起一个新项目，跑一遍 pgvector 做 RAG
- 了解 Supabase 这种基于 Postgres 的全栈方案，理解 Postgres 为什么吃下了”小项目首选数据库”这个生态位
2.8 为什么用 Neo4j 不用 Redis 存图？为什么不用 Neo4j 存 Agent 状态？#
这一段是 W 钓鱼问的。候选人在解释 Redis 用途时不自觉地把”图存储”说成 Redis 的功能，被立刻揪出来。
教训：不要在自己不熟的领域做发散性回答。被问 Redis 就老老实实讲 Redis 的合理用途，不要为了显得懂得多扩展到图、向量、状态机管理这些 Redis 不擅长的领域。
更普适的一条规则：简历上写的每一点都是需要能理解透的，要不然就别写。作为面试官，你写了我就会问；回答不出来，那就”嗯，对，比较不好”了。
2.9 为什么用 Qwen3-8B 微调，而上游数据用的是 Kimi K2.5？#
候选人：“Kimi K2.5 是用来做 QA 对数据集构建的，从不同视角生成问答对。”
W 的批判：
“Kimi K2.5 模型性能 benchmark 上肯定比 Qwen3-8B 强。用一个更强的模型生成数据，去微调一个更弱的模型，逻辑上是合理的（数据蒸馏的思路），但你这里的场景设计有问题——你应该写：用 Claude Sonnet 4.6 + Kimi K2.6 去做用户隐私数据脱敏、补齐多模态训练数据，最终在阿里百炼平台上对 Qwen3 的最新版（如 Qwen3.6-235B）做 LoRA 微调。这样写就 make sense。”
为什么这个问题重要：微调的合理性 = 数据质量 × 任务匹配度 × 成本。说不清楚为什么微调，就别写微调。
实际怎么写：
“针对 [垂直领域] 的 [特定任务]，使用 Claude Sonnet 4.6 和 Kimi K2.6 对数据集进行清洗、隐私脱敏、多模态数据补齐，构建高质量训练集，在阿里百炼平台上对 Qwen3-X 进行 LoRA 微调，相比直接调用通用模型在 [具体指标] 上提升了 X%。”
我和 W 还顺嘴吐槽了一句：Qwen3-8B 这个模型在培训班项目里太常见了，看到就有 PTSD。如果你想让面试官眼前一亮，至少用一个 2026 年的最新模型版本。
三、Agent 核心知识：上下文工程、记忆、Skills、MCP#
3.1 你设计过上下文工程吗？#
候选人讲了一些他做的事情：128K 上下文窗口，到达 75% 阈值时启用滑动窗口保留近 5 轮对话，会话结束后用大模型对历史做摘要并写入长期记忆。
我的评价：“上下文管理”这一句话写在简历上等于废话文学——因为这是所有 Agent 项目的默认操作。
怎么写才有内容：
不要写”做了上下文管理”，要写——
- 我设计了多少层上下文（系统层、任务层、用户层、会话层）
- 每一层在什么时候被触发
- 我用什么 trigger 决定写入长期记忆 / 摘要旧上下文 / 启用滑动窗口
- 我怎么处理上下文里的”噪音”（无关消息、用户口误、矛盾信息）
- 我怎么做 prefix caching 友好的上下文设计（这个后面单独讲）
3.2 长期记忆的写入：用户说”今天想吃辣”是该记还是不该记？#
我问：
“用户今天说我喜欢吃辣，这个点是怎么写入记忆的？是用户显式调用，还是 Agent 自主判断？而且这个有可能他今天只是心情不好想吃辣，是短期偏好；和’我是一个长期吃辣的人’是不一样的。你怎么设计 Agent 去区分？”
候选人没有答上来，承认”做得比较粗”。
为什么这个问题重要：这是 Memory 系统最核心的设计问题之一。“什么该记、什么不该记、记多久、怎么覆盖”是记忆引擎的灵魂。如果你简历上写了 Memory 项目但说不清楚这些问题，整个项目的可信度就崩了。
应该如何回答：
记忆写入需要考虑——
-
事实型 vs 推导型 vs 偏好型：
- 事实型：“我叫 Joye，在墨尔本读书。” → 直接写入，高置信度。
- 推导型：“我经常在周末加班。” → 不需要写入，可以从历史会话推导。
- 偏好型：“我喜欢吃辣。” → 需要写入，但要标注置信度和时效性。
-
短期 vs 长期：
- 短期偏好（“今天想吃辣”）→ 写入会话级记忆，会话结束后衰减或丢弃。
- 长期偏好（多次提到、稳定的偏好）→ 提升到长期记忆。
- 这个升级机制可以基于”出现次数 + 时间跨度”。
-
矛盾检测：
- 用户说过”我喜欢吃辣”和”我不能吃辣”，怎么处理？
- 时间戳 + 上下文判断哪个是当前事实。
-
写入触发：
- 显式触发：“请记住我…”
- 隐式触发：会话结束 / 消息数达到阈值 / 检测到用户陈述事实
- 异步触发：后台用便宜模型对会话做总结提取
3.3 Memory 是怎么被使用的？加在 system prompt 哪个位置？#
候选人：“应该是加在 system prompt 里。” 然后说”靠后比较好，因为模型注意力机制对靠后内容更敏感”。
我立即纠正：完全说反了，是加在最前面，主要为了 prefix caching。
为什么这个问题重要：这是 2026 年 Agent 工程师必须知道的一个工程细节。
- Prefix caching：Anthropic / OpenAI / 国内模型供应商都支持把 prompt 的前缀缓存下来，缓存命中时 token 价格便宜很多（Anthropic 是缓存写比常规贵、缓存读比常规便宜）。
- 设计原则：把变化最少的内容放最前面（system prompt → 长期记忆 → 工具描述 → 历史会话 → 当前 query）。这样大部分时候只有最后一段在变化，前缀都能命中缓存。
- 如果你把 memory 加在最后，每次记忆更新都会破坏整个前缀的缓存，token 成本飙升。
引申问题：你的 memory 更新频率应该是多少？
- 更新太频繁 → prefix cache miss 太多 → 成本飙升
- 更新太慢 → 用户感觉 Agent “记不住” → 体验差
- 这个 trade-off 需要在你的项目里讲清楚
3.4 OpenAI / Claude / 开源 Agent 的 Memory 系统迭代过几个版本？各自优缺点？#
W 问的，候选人没答上来。
为什么这个问题重要：这是看你”是不是一个真正关注这个领域的人”。研究 Agent / Memory 的人不可能没看过这两家的产品迭代，以及主流开源 Agent 的方案。
应该如何回答：至少要能说出——
- OpenAI 的 Memory 演进：从最早的 “Saved memories”（用户显式触发，纯列表存储）→ 自动 memory（模型自主判断写入）→ 跨会话记忆（“reference chat history”）。
- Anthropic / Claude 的方向：Claude 的 Memory 通过 Skills 系统和 conversation_search 工具实现，结构上更接近”工具调用 + 显式存储”，而非自动写入。
- 开源 CLI Agent 的方案：以 Hermes、OpenCode、OpenClaude、Aider 为代表——基本都是用 Markdown 文件做记忆载体（memory.md / user.md），Agent 通过显式读取来恢复上下文。这条路线最大的优势是”记忆完全可读、可编辑、可版本化”。
改进方向：
- 实际用一段时间这几家的产品，体感它们的差异。不用的话起码也要去通过博客或者科普视频了解一下——证明你对 Agent 是真的好奇的
- 阅读 Claude 的 Skills 文档 ↗、Anthropic 关于 Building Effective Agents ↗ 的文章
- 关注 Hermes / OpenCode / OpenClaude / Aider 等开源 CLI Agent 的代码
3.5 Skills、MCP、Function Calling 三者的关系？#
W 的题，原文是 “Skill 跟 MCP 加一个 CLI”，但候选人没听过 CLI 类工具，所以聚焦在 Skills 和 MCP。
候选人答得还行：MCP 提供数据源连接，Skill 教模型如何使用这些数据完成特定任务，两者互补。
应该如何回答（更完整）：
| 解决什么问题 | 形式 | 例子 | |
|---|---|---|---|
| Function Calling | 给模型加可执行能力 | 单个函数定义（schema + 实现） | get_weather(city) |
| MCP | 标准化”模型 ↔ 工具/数据源”的连接协议 | 一个 MCP server 暴露一组 tool / resource | Asana MCP, GitHub MCP |
| Skills | 给模型”如何完成一类任务”的程序化指南 | 一个文件夹（SKILL.md + 资源） | docx skill, pdf skill |
| CLI 工具（Lark CLI / Playwright / OpenCLI） | 让模型通过命令行操作真实世界 | Shell 命令 | lark message send ... |
关键洞察：
- MCP 和 Skill 是互补的：MCP 给数据，Skill 给方法论。
- Skill 的最大优势是 SOP 化 / 流程化：把领域专家的最佳实践编码成模型可读的指南。
- Skill 用了 Progressive Disclosure（渐进式披露）：第一层只加载 skill 的元数据（name + description），命中后才加载完整内容，避免上下文爆炸。
3.6 Agent 怎么”感知”到 Skill 的存在？#
W 问的细节题，候选人答得模糊。具体机制是——
Skill 的元数据（name + description）会被注入到 system prompt 的 tool list 里（通常是工具描述区）。模型在每一轮决策时看到这个轻量级目录，判断当前任务是否需要某个 skill。如果需要，模型主动调用一个”读取 skill 内容”的 tool（比如 view SKILL.md），把完整的 skill 内容加载到上下文。
为什么这样设计：避免一次性把所有 skill 完整内容塞到上下文里——一个用户可能有几十个 skill，每个 skill 几千字，全塞进去 prompt 就爆了。渐进式披露是上下文工程的核心思想之一。
3.7 Skill / MCP 的安装上限？#
候选人：“肯定有上限。Skill 太多会让工具列表很大，模型选择精准率会下降。”
这一点答到了。补充一下：
- Claude Code 等产品对 skill 数量有软限制（一般几十个），就是因为元数据加载到 system prompt 会膨胀。
- 选择精准率下降的现象在 tool calling 里也存在（“工具过多导致幻觉调用”）。
- 解决方案：分层加载（按场景动态加载相关 skill 子集）。
值得专门提一下 Claude Code 里的 tool_search 机制——它本质上把”工具/skill 列表”也变成了一个可搜索的索引：模型默认看不到所有工具的完整定义，需要时通过 tool_search 查询关键词、按需加载。这是渐进式披露在”工具维度”的进一步推广，是当前 Agent 设计里非常值得借鉴的范式。
四、Agent 怎么控制成本#
W 的题。候选人：“要考虑大模型调用次数，把一些步骤合并起来。”
我们俩当场吐槽：“减少调用次数”这种回答等于”我每个月想少花点钱”——这是结果不是方法。
应该如何回答（这一段是这场面试我个人觉得最值得记下来的部分）：
1. Prefix Caching 友好的上下文设计#
如前文所述。把变化最少的内容放最前面，让 cache 尽可能命中。
具体动作：
- 把 system prompt、长期记忆、工具描述放在前面
- 把当前 query、最新消息放在最后
- Memory 更新频率不要太高，每次更新都会让前缀失效
- 评估你用的模型供应商的 cache 计费策略：Anthropic 是”显式 checkpoint + 写贵读便宜”，OpenAI / Gemini 是自动缓存
2. 模型分级使用#
简单任务（意图识别、分类、摘要）用便宜小模型，复杂推理用大模型。这是为什么”所有 Agent 都用同一个 Qwen3-8B”是个大问题。
3. 减少 Agent step 数#
Agent 的 token 成本是指数级增长的——每多一步，整个对话历史会作为输入再发一次。
具体动作：
- 能一步完成的不要拆两步
- 工具设计要”宽口径”——一个工具能解决一类问题，不要每个细分任务都一个工具
- Plan 阶段尽量做完整，避免边走边想
4. 上下文剪枝#
- 旧的工具调用结果如果已经被用过，就从历史里删掉（保留摘要）
- 文件类内容只保留 diff
- 大段无关上下文用 tool 来”按需读取”，不要默认塞进 prompt
5. 失败重试的限流#
Agent 失败会自动重试。如果不限制重试次数 + 不做指数退避，一个 bug 可以让你的账单爆炸。
五、AI Coding 工程实践：你怎么写代码、怎么用 AI？#
W 的题：“你做这些项目时有什么 AI Coding 的技巧？”
候选人答：“一般用 Claude Code 帮我编写或读代码。”
W 期待的答案是：
“我会基于项目构建一个 doc tree（项目索引），写 AGENTS.md / CLAUDE.md / Cursor rules，让 Agent 不要重复探索已经探索过的问题。我会把常用框架（PostgreSQL、FastAPI 等）的最佳实践放到 .claude/skills/ 下作为参考。”
为什么这个问题重要：
“我们更看重的是你中间是怎么做的。简历上的’成果’部分大家都大同小异——大家都用 AI Coding，开源项目改一改，简历都长得差不多。真正区分候选人的是过程。”
这一点放到所有 AI 时代求职者身上都成立：当 AI 把”写代码”这件事的成本拉到很低的时候，你的差异化必须体现在——
- 你怎么使用 AI 工具？
- 你建立了什么样的工作流？
- 你怎么让 AI 工具在你的项目里持续提供高质量输出？
- 你的 AGENTS.md / Skills / Memory 怎么设计？
- 除了 coding 场景，你还怎么用 AI？ —— 这是一个很好的延伸问。我指的不是”问 GPT 学校作业”这种，而是比如：用 Hermes 管理日程、用 cronjob + Agent 每天给自己推送 AI 圈热点、用 AI 工作流自动剪辑视频等等。能展示这些的人，明显比”只用过 Cursor”的人离这个行业近一截。
六、宏观的话：我们怎么看 Agent 开发和这个行业#
面试最后一段，我和 W 给候选人讲了一些更宏观的东西。这部分对所有想入行的同学都有价值。
6.1 不要堆技术，要解决问题#
“我面了很多人，他们喜欢堆技术——Redis、RAG、向量库、图谱、微调一通堆。然后简历上每一个技术写下来都答不出来’为什么用’。”
这是 2026 年 Agent 求职者最普遍的问题。培训班、横向项目、网上抄的简历模板，都在教你”堆技术显得专业”。但任何一个有经验的面试官都能在 5 分钟内识破。
真正能打的简历长什么样：
“你这个简历最大的问题是没有前端，因为我招人的话我都招全栈的。”
“我建议你项目不要多，就一个项目，里面既有 Agent 又有前端、又有 Agent 上下文工程、又有后端的高并发处理；又有你思考的过程，比如你的 AI Coding 最佳实践是什么、你用了什么 skill 来辅助开发、你这个项目的文档怎么写、可观测性怎么做、Agent 的 evaluation 怎么做、怎么证明它是好的、微调又是怎么弄的。”
一个深度做透的项目 >> 五个浅尝辄止的项目。
6.2 不要 RAG-for-the-sake-of-RAG#
强烈推荐先看一下 Karpathy 的 LLM Wiki ↗ 系列内容——他对”为什么传统 RAG 在长上下文时代逐渐失势”讲得很清晰，是这一节的底层思想之一。
W 问了一个很好的问题：
“RAG 是为了解决知识库的问题。那你看最新的 Agent 是怎么解决问题的？Claude Code 有 RAG 吗？”
候选人才意识到：Claude Code 没有 RAG，它用的是 grep。
这个观察很深刻：
- 传统 RAG 的范式是”先把文档切片向量化，查询时检索”——这是 2023 年的方法论，假设是”模型上下文小、token 贵、必须精准检索”。
- 2025-2026 年的范式是 Agent + 工具——长上下文模型 + grep / glob / 文件读取工具，让 Agent 自己探索代码库。这种方式精度更高、不依赖向量化质量、不需要维护索引。
- 这不是说 RAG 死了，而是 RAG 不是唯一答案。在很多场景里，让 Agent 用基础工具（grep, find, read）反而比上 RAG 更好。
求职建议：简历上”用了 RAG”不再是加分项。如果你写 RAG，要能说清楚”为什么 RAG 比 Agent + grep 更适合这个场景”。
6.3 项目要上线、最好能让面试官体验#
“你这个项目如果是自己做的、没上线，可能不太感兴趣。”
“我建议你把项目部署到 Vercel，半个小时就能部署好，要有一个能给大家用的生产级项目。”
为什么上线这么重要——
- 上线了你才会遇到真实问题（性能、并发、错误处理、用户行为）
- 上线了你的简历才有”流量”、“用户数”这种硬指标——当然这个不一定有，我也不强求，毕竟拉真实用户是很难的事情
但我希望的是你至少有一点部署经验。最理想的情况是：在面试或者面试前，我能自己去体验一下你的项目——哪怕只是一个不需要登录的 demo 页面。这种”能摸到的项目”比一份纯简历描述的项目要可信、加分太多了。
6.4 海外开发者生态：被很多国内候选人忽视的加分项#
W 这一段我觉得特别值得单独拎出来：
“全世界最有钱的人都在美国，SaaS 付费率最高的也在美国。所以开发圈应该只分中国和海外。”
具体技能栈：
- 怎么接 Google OAuth、AWS、Stripe 支付
- Vercel 部署、Cloudflare 防攻击（不是 robot 那种 Turnstile）
- Vercel template 怎么写、开源项目怎么让别人能 one-click deploy
- 海外开发者社区怎么融入（X、Hacker News、Reddit、Indie Hackers）
“国内大厂也都在出海，国内的整个资金也都在出海化。”
如果你想做 Agent 工程师又想拿好 offer，海外开发者生态的认知是真的能拉开差距的能力。
6.5 信息收集能力 = 软实力#
最后一段对话我说了：
“现在有了 AI，你写代码本身的这个能力，性价比或者说意义是在逐渐降低的。那你肯定需要去开发一些所谓的软能力。”
W 补充：
“你自己平常刷推特吗？你该多刷一下 AI 圈的推特，你会有很多灵感。刷多了解多了，就是降维打击——你就是从求职者的身份变成一个 AI 圈正在参与这场构建的狂欢的人。”
这是这场面试最重要的一句话。
在一个技术变化以周为单位的领域，你的信息源决定了你的天花板。如果你只看公众号、知乎、CSDN，你看到的永远是被翻译、被筛选、被滞后的二手信息。当一个新模型、新框架、新范式出现时，你比硅谷的从业者晚一周知道，比国内最早一批知道的人晚三天，三个月后你看到的就是被嚼烂的”科普文”。
要建立一手信息源：
- X / Twitter：关注 Anthropic、OpenAI 员工、知名独立开发者、AI infra 公司创始人
- Hacker News：每天扫一遍 frontpage
- 官方文档 / changelog：Anthropic、OpenAI、Vercel、Cursor 的产品页和 release notes
- GitHub：关注那些刚 launch 的 viral 项目，看代码、提 issue、参与讨论
- 个人博客：当然也欢迎关注一下我的 joyehuang.me ↗ hhh，我会把我每天读到的有意思的东西沉淀在 notes 区
“你就是会变，从求职者的身份变成一个 AI 圈正在参与这场构建的狂欢的人。“
6.6 关于”抄开源项目”#
候选人最后问：“有没有推荐的开源项目可以拉下来做？”
我的回答：
“我真的不打算推荐任何项目。现在有了 AI，你从 0 搓一个项目的成本已经很低了。我会建议你去发现你日常身边的需求，这样你在面试讲整个故事时会更真诚、更有信服力。或者你可以像我一样高强度使用 Hermes Agent，觉得它的代码哪里不好就去改——目前来说我遇到的面试官没有比我更了解 Hermes Agent 源码的，这种深度本身就是稀缺的。但是直接抄一个开源项目，我自己是不太能接受的。”
理由：
- 抄来的项目你说不出”为什么这么设计”——所有的”为什么”题都会翻车
- 抄来的项目没有你的真实使用动机——讲不出 use case
- 现在 AI Coding 工具已经把”从 0 写”的成本降到几个小时——没必要抄
七、表达能力：答不到点上的问题#
整场面试我反复指出候选人一个问题：回答前面会有两句没意义的废话，要很久才抓到问题核心。
候选人自己也意识到了：“对一些语言的表达确实得再学习。”
这其实是一个被严重低估的求职能力。同样的知识储备，能用 30 秒说清楚和需要 3 分钟绕弯子说清楚的人，面试评价完全不同。
提升方法：
- 录音回放：每次模拟面试录下来，回头听，你会发现自己有大量”嗯、就是、那种”的填充词
- 先结论后细节：每个回答的第一句话直接给结论，再展开
- 用专业术语：不要”那个东西”、“类似那种”，要”prefix caching”、“AQS”、“弱引用”——精准用词本身就是专业度的展示
- 不清楚就不要装清楚——这是更核心的一条。很多时候你回答绕弯子、铺垫一堆废话，本质上是因为你对答案本身没把握，想用”说多一点”来掩盖。但说多了反而错得多，不如直接承认”这块我不太熟”。承认不会，比硬撑被钓鱼问到死要好得多。
我和 W 还观察到的一点：有些答案候选人其实已经达到了，但就是没讲出那个词。会用额外一两句话去描述那个概念。这种情况下”知识到位但词没到位”，反而会被面试官判定为”不熟”。
八、总结：如果你也想做 Agent 工程师#
把这场面试的所有教训浓缩成一份 checklist：
项目层#
- 我的项目解决的是 ChatGPT / 豆包 / Claude 直接对话不能解决的问题吗？
- 我的多 Agent 设计相比单 Agent 有实质收益吗？
- 我的项目部署上线了吗？面试官能体验吗？
- 我的项目里 Agent + 前端 + 后端 + 评估 + 可观测性 + 文档 完整吗？
技术选型层#
- 我用的每一个技术（Redis / 向量库 / 图库 / 微调 / RAG）都能讲清楚”为什么是它，不是 X / Y / Z”吗？
- 我知道 PostgreSQL + pgvector 在很多场景下可以替代独立向量库吗？
- 我知道 Claude Code 用 grep 不用 RAG 的原因吗？
- 我用了不同模型分级处理不同任务吗？
Agent 知识层#
- 我能讲清楚 Function Calling / MCP / Skills / CLI 工具的关系吗？
- 我知道 Skill 的渐进式披露 / Claude Code 的 tool_search 是怎么工作的吗？
- 我能讲清楚 prefix caching 友好的上下文设计吗？
- 我能讲清楚记忆系统的”事实型 / 推导型 / 偏好型”分类，以及矛盾处理、衰减机制吗？
- 我研究过 OpenAI / Claude / Hermes / OpenCode 的 Memory 演进吗？
AI 工作流层#
- 我有自己的 AI Coding 工作流吗？AGENTS.md / Skills / Memory 怎么用？
- 除了 coding 场景，我还怎么把 AI 融入日常（日程、信息流、内容创作）？
- 我会写 Agent evaluation 吗？
软能力层#
- 我的一手信息源是什么？X、HN、官方 changelog 我每天看吗？
- 我了解海外开发者生态吗（Vercel / Stripe / Cloudflare / OAuth）？
- 我表达回答时能 30 秒切入核心吗？我会用专业术语吗？
写在最后#
这场面试持续了 1 小时 19 分钟，我和 W 给候选人的整体反馈是”项目要重写、信息源要扩、表达要练”。听起来很残酷，但他自己反应是”知道问题比不知道问题好”。
我赞同这个态度。
“知道问题比不知道问题已经好很多了，接下来就是你的行动力了。”
这篇博客里聊到的所有问题，我自己也都还在持续学习和踩坑。我每天都在改 Hermes 的源码、读 Anthropic 的官方文档、看 X 上 AI 圈的最新讨论——不是因为我有多厉害，是因为这是这个行业的入场券，不是高分项。
如果你也在准备 Agent 方向的求职，希望这篇能帮到你。
📮 关于有偿模拟面试 / 简历辅导
我目前在接 Agent 方向的有偿 1v1 模拟面试和简历辅导，会基于你的具体项目和目标岗位定制问题、给出可执行的改进方向（这篇博客就是一场真实模拟面试的复盘）。如果有需要可以在我的个人网站 joyehuang.me ↗ 找到我，或者通过站上的联系方式直接预约。
后面我也会陆续整理更多模拟面试的复盘，欢迎关注。
本文所有人名和敏感信息已脱敏。