小米员工：从现在开始，除了本职工作每天还要做AI相关的创新工作，AI相关成果会作为核心产出（附Agent面试题）
最近，看到小米员工这样一则爆料。
这条爆料里最值得关注的四个字是“核心产出”。不是“鼓励尝试”，不是“有余力可以搞搞”，是核心产出——直接和绩效挂钩。
这意味着 AI 能力已经不是加分项了，是必选项。
在我看来，公司搞新方向，对普通员工来说是最好的机会。因为原来的赛道大家都占好坑了，论资排辈轮不到你出头。新方向不一样，所有人都是从零开始，谁先做出来东西，谁就能被看见。
“摸着石头过河”恰恰说明还没有标准答案，领导自己也不知道最终要做成什么样子。这种时候最怕的不是做错，是不做。你做出来一个能演示的东西，哪怕粗糙，就是成绩。
而且说句大实话，大部分人卡住不是因为“AI 太难了学不会”，是不知道从哪下手。
这两件事完全不一样。
“学不会”是能力问题，“不知道从哪下手”是信息差问题。
Agent 工程化这个方向，并不要求你去训练模型、写 CUDA、搞分布式推理。它要求的是你能把大模型的能力包装成一个好用的产品——能调工具、能管上下文、能评估效果、能处理异常。
看看现在各大厂，最火热的产品要么说桌面Agent，要么是终端Agent。
Python/TypeScript/Go都有：https://github.com/itwanger/PaiCLI-Python
如果想要在 Agent 方向有所研究，有所建树，那不妨现在就行动起来，GitHub上这样的Agent产品实在是太多了，找准需求点，用Codex或者Claude Code搞一个出来，难度真不大。
如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来这份硬核的面经，希望你能认真读一读。
（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗粗发～）
content
01、你之前做的 Agent 项目用的是什么架构？
老王的第一问直奔架构：“你做的 Agent 项目用的是什么架构？LangGraph 还是自研？master+sub Agent 还是 workflow？”
“终端 Agent 是自研的，基于 Spring AI，设计了三条执行路径。”
"ReAct 模式是默认路径，单循环：LLM 决策 → 工具调用 → 观察结果 → 再决策，适合实时交互的短任务。"
"Plan-and-Execute 模式用于复杂任务，先让规划器生成一个带依赖关系的任务图，按拓扑排序（Topological Sort）执行，中途失败会触发重新规划。"
"Multi-Agent 模式是三个角色协作，规划、执行、审查各管各的。"
02、单 Agent 还是多 Agent？子 Agent 怎么分工？
“默认单 Agent，也就是 ReAct 模式。多 Agent 是按需启动的，用户输入 /team 指令也会直接切换到 Team 模式。”
Team 模式下有四个角色：
- 调度器：接收用户任务，把任务交给规划器，拿到执行计划后按拓扑排序分批派发给 Worker，最后把结果交给审查器
- 规划器：把任务拆解成带依赖关系的 JSON 计划，比如“任务 2 依赖任务 1 的输出”。规划器不调工具，只输出计划
- Worker：真正干活的角色，每个工人有独立的对话历史和完整的工具集。同一批没有依赖的任务可以并行执行，默认最多 2 个工人同时工作
- 审查器：质量关卡。审查 Worker 的产出，不合格就打回重做，最多打回 2 次
“关键设计是角色隔离——规划器和审查器都不碰工具，只做判断。工具执行权集中在 Worker 手里，避免审查器自己改代码、自己审自己。”
03、首次生成和多轮补充的路由怎么区分？
老王在他的小本本上打了个勾，继续提问：“首次生成和多轮补充的路由是怎么区分和实现的？”
“靠会话状态判断。核心是一个会话 ID，存在 Redis 里，7 天过期。”
"首次请求没有会话 ID，系统创建新会话，走完整的意图识别和工具调度流程。多轮补充带着已有的会话 ID 进来，从 Redis 取出最近 6 条对话历史注入上下文，LLM 基于历史理解当前意图。"
“区分首次和补充，技术上不复杂，复杂的是意图分类的粒度。”
同一个会话 ID 下，用户的第二句话可能是追问（“具体怎么实现的？”）、也可能是补充（“对了，还要支持图片格式”）、也可能是完全换了个话题。
“我的做法是把分类权交给 LLM。把历史对话和当前输入一起给模型，模型自己判断该检索新内容、还是基于已有上下文直接回答、还是要求用户澄清。比起硬编码规则路由，LLM 判断意图的准确率更高，维护成本也更低。”
04、提示词模板怎么构建？上下文工程有哪些实践？
“提示词组装用的是分层拼接，一共 9 层，按固定顺序组装。”
"前四层是静态的。第一层放身份、行为守则、工具定义、安全策略，整个会话不变。第二层是人格层，控制语气风格。第三层是模式层，根据当前执行路径加载不同的指令集，ReAct、Plan、Team 各一套。第四层是审批层，定义人机协作策略，比如工具调用前是否需要用户确认。"
"后五层是动态的。运行时上下文（日期、时区）、项目记忆、Skills 索引，这三层每轮都会变。第八层是上下文管理策略，告诉模型什么时候压缩、怎么压缩。第九层是收尾指令。"
“核心设计是静态内容排最前面。前四层在整个会话期间不变，放在提示词开头。Prompt Caching 按最长公共前缀命中，稳定内容越靠前，缓存命中率越高，token 成本能省一个数量级。”
to do list 为什么能让模型更聚焦？
“to do list 的本质是给模型一个结构化的任务追踪。”
“LLM 在长对话中容易出两个问题：一是忘了前面做过什么，重复操作；二是漏了某个步骤，直接跳到最后。to do list 把'已完成'和'待完成'的步骤显式列出来，模型每一轮都能看到当前进度，自然就知道下一步该做什么。”
“就像我们开发用看板一样，任务列在上面，做完一个划掉一个。模型也需要这种外部记忆辅助。”
05、查询改写做过吗？多维度查询改写是什么？
“做过。查询改写的目的是提升检索召回率，用户的原始提问往往不是最佳的检索 query。”
多维度查询改写包括三个方向：
“第一个方向是同义扩写。把'Agent 性能'扩展成'Agent 延迟''Agent 吞吐量''Agent 响应时间'，用不同的表述去命中更多文档。”
“第二个是意图分解。复合问题拆成多个单一问题。'比较 A 和 B 的性能和价格'拆成两条 query 分别检索，召回精度比一条混合 query 高得多。”
“第三个是上下位泛化。把具体产品名泛化到品类。'Claude Code'泛化成'终端 Agent'，能召回同类产品的横向对比内容。”
“改写后的多条 query 并行检索，结果按文档 ID 去重，取 top-K 合并。”
需要用户补充信息时怎么设计？
“靠槽位检测（Slot Detection）。”
“每种意图预定义一组必要槽位。比如'帮我查个 bug'这个意图，必要槽位是'错误描述'和'复现步骤'。如果用户只说了'帮我查个 bug'，缺了两个槽位，Agent 就生成一条澄清问题：'能描述一下具体的报错信息和复现步骤吗？'”
“用户回答之后，填充槽位，用完整的信息重新构造 query 再检索。这个交互要做到自然，不能一次问太多——每轮最多补一到两个槽位，否则用户会觉得在填表。”
06、并行化意图识别是什么？为什么要并行化？
老王往前倾了倾身子，继续问：“并行化意图识别了解多少？”
“传统的意图识别是串行流水线：先做意图分类，再做实体抽取，再做领域判断，再做紧急程度评估。每一步都要等上一步完成，延迟层层叠加。”
“但这几个维度之间其实没有依赖关系。意图分类不需要等实体抽取的结果，领域判断也不依赖紧急程度。既然彼此独立，就应该并行跑。”
"实现方式是把每个分类维度定义成一个独立的分类器，可以是轻量模型，也可以是一次 LLM 调用。用线程池或 CompletableFuture 并发执行所有分类器，全部返回后在路由层合并结果，根据组合条件决定走哪条处理链路。"
“延迟从所有分类器耗时之和，变成最慢那一个分类器的耗时。假设有 5 个维度，每个差不多 200 毫秒，串行就是 1 秒，并行还是 200 毫秒。对用户体验来说，差了 5 倍。”
07、Agent 的 Skills 体系怎么设计？
“核心原则是渐进式披露（Progressive Disclosure），分三层加载。”
"第一层是索引。只把 Skill 的名称和一句话描述放进 system prompt，控制在 4KB 以内，最多 20 个 Skill。这一层常驻上下文，成本很低。"
"第二层是正文。LLM 看到索引后，判断当前任务需要哪个 Skill，调用 load_skill 工具把完整的 Skill 指令加载进来，单个 Skill 正文上限 5KB。"
"第三层是参考文档。部分 Skill 带有参考文档目录，只在 Skill 指令明确要求时才按需加载。"
“加载进来的 Skill 正文放在一个 LRU 缓冲区里，最多同时持有 3 个 Skill，超出的按最久未使用淘汰。”
“为什么不一次性全量加载——system prompt 越长，Prompt Caching 命中率越低。绝大多数对话只会用到一两个 Skill，全量加载等于让用户为用不到的内容买单。”
“Skill 来源有三级优先级：内置的、用户级的、项目级的，从低到高覆盖。项目级的 Skill 可以覆盖内置同名 Skill 的行为，不需要改源码。”
08、Agent 系统的效果怎么评估？
“分三层指标看。”
"结果层看任务成功率。前提是评测环境可复位，每次都从同一个状态出发，上一次运行的副作用不能污染下一次。"
"过程层看效率。完成同一个任务用了多少步、消耗了多少 token、工具调用成功率多少。两个 Agent 都能完成任务，一个用 3 步，一个用 12 步，这就是水平差距。"
“PaiCLI 的代码搜索模块有一个 Golden Set，123 个确定性测试用例。每条用例定义输入 query 和预期命中的文件行号，跑一遍就知道搜索链路有没有回退。”
没有用户反馈怎么抽检？
“两个手段配合。”
“一是模型裁判（LLM-as-Judge）。定义评分标准，让模型按标准给产出打分。好处是成本低、速度快，能覆盖大批量样本。”
“二是人工校准。定期随机抽一批模型裁判打过分的样本，人工复审，算一下模型裁判和人类判断的一致率。一致率低于阈值，说明评分标准需要调整，或者模型裁判本身漂移了。”
“这两个缺一不可。只用模型裁判，评测体系自己先漂移了都不知道。”
09、Badcase 怎么定位到具体是哪个 Agent 环节？
“靠 trace 链路重建。”
“每个节点的执行都有快照记录：输入是什么、输出是什么、状态是成功还是失败、耗时多少、报错信息是什么。整条链路从用户输入到最终产出，每一步都有据可查。”
“拿到 trace 之后做归因打标。每个 Badcase 打一个主标签：检索没召回、工具调用报错、推理链断裂、格式违规、上下文溢出。标签不要打多个，一个 Badcase 只认一个主因。”
“标签攒够量之后，哪个维度的失败率最高一目了然，下一轮优化就往那个方向发力。”
怎么判断该对哪个 Agent 做 SFT？
“看标签分布，然后做数据分流。”
- 事实性错误（模型理解错了、推理断了）→ 修正成正确轨迹，进 SFT 训练数据
- 质量问题（不算错但不够好）→ 做成偏好对，去训奖励模型（Reward Model）
- 工具或环境问题（API 超时、格式解析失败）→ 修的是基础设施，不是模型
“分流是关键。Badcase 不能一股脑塞回训练集，类型不同，处理方式完全不一样。”
10、Prompt 调优“修好一类、坏了另一类”怎么解决？
“这个问题的根源是提示词之间存在隐式耦合。你改了一条指令，模型对所有任务的行为都可能变化，因为它是全局生效的。”
“第一步，评测集先行。动手改提示词之前，先把现有能力覆盖的典型用例收集成评测集。改之前跑一遍，改之后跑一遍，对比分数。”
“第二步，分层隔离。提示词按关注点拆成独立文件，system 层、模式层、Skill 层各管各的。改 Skill 层的指令不应该影响 system 层的行为。”
“第三步，单点修改。一次只改一个地方，跑完评测确认没有回退再改下一个。同时改两个地方出了问题，你都不知道是哪个改坏的。”
“第四步，维护回归用例池。每次'修好 A 坏了 B'，把 B 加进回归池。”
“说白了，和软件工程里的单元测试、回归测试是一个道理。提示词也是代码，改了就要跑测试。”
11、设计一个带 TUI 界面的视频剪辑工具？
老王合上笔帽，换了个方向：“来道场景题。如果让你开发一个带 TUI 界面的交互式视频剪辑工具，MVP 版，怎么设计？”
“分三层。”
"第一层是 TUI 交互层，负责终端界面的渲染和用户输入。时间轴用字符可视化，每个片段用不同颜色标识，当前选中位置用光标高亮。操作全靠快捷键驱动，方向键移动光标、s 键分割、d 键删除、空格键预览。预览功能可以用 iTerm2 的 inline image 协议或 Sixel 协议在终端内渲染视频帧。"
"第二层是编排层，核心业务逻辑。命令解析把键盘输入翻译成编辑操作。状态管理用命令模式（Command Pattern）实现撤销/重做栈，每个操作封装成可逆的命令对象。时间轴模型维护片段列表、转场标记、当前播放位置。"
"第三层是执行层，本质上是 FFmpeg 的封装。剪切用 -ss 和 -to 参数定位，拼接用 concat demuxer，转场用 xfade 滤镜，导出走独立线程，不阻塞 TUI 交互。"
“MVP 只做四件事：导入视频、分割片段、调整顺序、导出成品。转场和特效留给后续迭代。”
12、Self-Attention 的实现原理是什么？
“Self-Attention 的计算分五步。”
"输入的每个 token 先经过 Embedding 变成一个 d 维向量，然后分别乘以三个权重矩阵 W_Q、W_K、W_V，生成三个新向量：Query（查询向量）、Key（键向量）、Value（值向量）。"
"接下来用 Q 和所有 K 做点积，再除以 √d_k 做缩放，得到注意力分数。缩放是为了防止点积结果太大导致 softmax 梯度消失。对注意力分数做 softmax 归一化成概率分布之后，用这个概率分布对所有 V 做加权求和，就得到了当前 token 的输出向量。"
为什么要分成 Q、K、V 三个向量？
“如果用同一个向量同时承担'我在找什么'和'我能提供什么'和'我实际包含什么'三个角色，模型只能计算自相似度，表达能力非常有限。”
“分成三个，各司其职：Q 负责'我在找什么信息'，K 负责'我能匹配什么查询'，V 负责'匹配上了之后实际传递什么内容'。三个独立的权重矩阵给了模型 3 倍的可学习参数，注意力模式的灵活性大幅提升。”
同一个 token 在不同位置的向量是一样的吗？
“不一样。因为有位置编码（Positional Encoding）。”
“以 RoPE（旋转位置编码）为例，它会根据 token 所在位置对 Q 和 K 向量施加一个旋转变换，旋转角度和位置成正比。同一个词'的'出现在第 5 个位置和第 50 个位置，经过 RoPE 旋转之后，向量方向是不同的。”
“没有位置编码，Transformer 就是一个词袋模型——'我打了他'和'他打了我'对模型来说一模一样，这肯定不行。”
PaiCLI 如何写到简历上？
项目名称：PaiCLI — 终端 AI Agent 命令行工具
项目简介：对标 Claude Code 的 Java 版终端 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，具备多轮对话、代码搜索、工具调用、自动修复等能力。
技术栈：Java 21 + Spring AI + LangGraph4j + Elasticsearch + MCP 协议
核心职责：
- 设计并实现 Agent 多模式架构，支持 ReAct 快速响应、Plan-and-Execute 复杂任务分步执行、Multi-Agent Team 多角色协作三种执行路径，根据任务复杂度自动路由选择
- 构建 9 层 Prompt 组装器，将静态层（角色定义、安全规范）前置为固定前缀命中 Prompt Caching，动态层（对话历史、工具结果）按 token 预算裁剪，单次请求 token 成本降低约 35%
- 实现多维度查询改写模块，集成同义词扩展、意图分解、上下位泛化三种改写策略，改写后多条 query 并行检索并按文档 ID 去重，检索召回率提升约 20%
- 设计 Skills 渐进式加载体系，采用索引→正文→参考文档三级结构按需加载，通过 LRU 缓冲区控制同时激活的 Skill 数量（上限 3 个），避免上下文溢出
- 搭建三层效果评估体系（结果层/过程层/稳定性层），维护 123 条确定性测试用例的 Golden Set，结合 LLM-as-Judge 批量评分和人工校准抽检，保障迭代过程中效果不回退
ending
以前我们找工作拼的是八股文，背并发、背中间件、背设计模式。现在是架构选型、上下文工程、效果评估、Badcase 定位。
【技术在变，但底层逻辑没变——谁能把东西做出来、做稳定、做到生产级，谁就是稀缺的。】
AI 正在重新划分工程师的能力版图，这个过程才刚开始，机会远比想象的多。
加油吧，兄弟姐妹们。
下期见。