xiaom员工：15升16，一般的嫡系要满足在15级停留一年半的时间，嫡中嫡则完全不需要，不是嫡系那就很难升了（附Agent面试题）

沉默王二约 7498 字大约 25 分钟

看到一位老哥聊起 15 升 16 的晋升体感，说一般的嫡系要在 15 级停留满一年半的时间，嫡中嫡则完全不需要，不是嫡系那就很难升了。

按照我了解的职级体系，应届生入职大多定在 13 级，工作三年左右的集中在 15 级，而 16 到 17 级对应的是部门里的技术骨干和专家。从 15 升 16，正好是从一名熟练执行任务的工程师迈向独当一面技术骨干的门槛。

在已经运转多年的成熟业务部门里，团队架构稳定，上面的坑位早就满员了，所以每年的晋升名额就那么几个，评审时更看重资历年限、更看重是不是长期跟着重点项目攻坚的班底，这其实也是很多互联网公司存量部门的常态。

如果在存量部门里一直纠结自己算不算嫡系，越想越容易陷入内耗。与其盯着有限的存量名额熬年限，不如看看公司里正在发生增量的地方。

比如说 AI 部门，就一定是增量部门。

回头看 MiMo 团队大半年交出的答卷，推进节奏确实很快。从开源 1M 上下文的 MiMo-V2.6-Pro、自研桌面端工作台 MiMo Desktop，到在 GitHub 上拿到 1.3 万以上 Star 的终端编码工具 MiMo Code，再到针对 Agent 场景把 KV Cache 占用压缩到 2.69GB 的 HySparse2 架构，模型研发和 Agent 工程化几乎是同步往前推进。

加上小爱同学架构调整后，基础模型正式划归 MiMo 团队，云端工程化和端侧各业务操作系统团队全面联动，手握全球超过 11 亿台消费级 AIoT 硬件和汽车生态的xiaom，对懂大模型推理、懂 Agent 架构与评测的工程师需求量正在激增。

接下来，继续来啃硬骨头，每天学一点，日积月累，总有一天你会出人头地的。

content

01、你怎么评估Agent生成代码的质量？有没有做过自动化评测？

“最基础的一关是代码刚写完时的静态语法与编译检查。Agent 每次调用写文件或编辑文件工具修改完 Java 源码，钩子函数会立刻调用 JavaParser 解析抽象语法树，收集括号不匹配、方法签名错误等语法问题，并在下一轮调用大模型之前，把语法诊断信息追加进对话上下文，让模型在当前任务里先把低级语法错误修好。”

“另外，我们自建了一套评测集 Native AgentBench，覆盖代码定位、缺陷修复、终端操作、MCP 工具编排和长上下文压缩等场景。自动化评测运行时，候选 Agent 被放进断网且根文件系统只读的 Docker 容器里独立执行，API 密钥留在宿主机侧，防止 Agent 联网搜答案或者读取测试脚本作弊。等 Agent 结束任务后，宿主机的验证器把预设的隐藏单元测试拷进隔离目录，不经过任何 Shell 字符串拼接，直接用进程参数数组执行编译和单元测试。”

“以区间边界修复这道题为例，验证脚本会先调用 Java 编译器编译被修改的源码，编译失败直接判为未通过；编译成功后立即生成并执行隐藏边界测试类，专门判断边界重合、空区间等极端情况。”

“在结果通过率之外，还会从工具调用监听器里采集完成步数、输入输出 Token 消耗、工具调用失败率以及是否触发了危险命令拦截。至于代码可读性、异常处理规范、有没有冗余改动这些单元测试测不出来的软性指标，就交给模型裁判（LLM-as-Judge）按预先定义的评分表打分。”

LLM-as-Judge评分怎么避免位置偏见和标准漂移？

“为了不让模型乱算分，我们在单样本评分器里把待测代码和执行轨迹全部标为不可信数据，要求裁判模型只针对每个评分维度输出 1 到 5 的整数分和简短证据。一旦模型返回了未知维度、重复维度、缺失维度或者越界分数，解析器直接抛出异常；加权总分以及是否违反一票否决项，全部由确定性的 Java 代码计算。”

“在做基线版本与候选版本的成对比较时，位置平衡评测器会把同一对答案送进模型评测两次，第一次按基线在前、候选在后排列，第二次把两者的位置对调。只有两次评估选出的是同一个胜者，才承认胜负结果；只要互换位置后结论不一致，说明模型受到了位置偏见影响，系统强制将结果降级为平局。另外，裁判模型自身的评判标准也会随版本更新发生漂移，工程上还需要用不同厂商的模型担任裁判，并定期抽样 10% 的评测样本交由资深研发人工盲评，计算模型打分与人工判断的一致率，一旦一致率跌破阈值就及时校准评分表的描述边界。”

02、设计一个代码审查Agent，怎么保证它不漏掉关键安全漏洞？

“如果直接把几百行 Git Diff 丢给一个通用大模型，说‘帮我看看有没有安全漏洞’，漏报率一定会很高。因为大模型看长文本容易注意力分散，而且很多高危安全问题（比如越权访问、二次 SQL 注入、未受控的反射调用）跨越了多个文件，光看被修改的那几行代码根本看不出完整的攻击路径。”

“所以防漏检的起点，是用确定性的静态扫描工具给大模型当眼睛，做前置证据冻结。审查开始前，先用基于 JavaParser 的语法树分析器、污点追踪规则以及密钥正则扫描器过一遍变更文件，把所有拼接 SQL 字符串、启动子进程执行外部命令、反序列化外部输入、硬编码凭证以及路径未规范化的位置全部标出来，连同变更文件的导入、继承和上下游方法调用关系一起提取出来。如果某个被修改的 Controller 方法改了参数结构，系统自动顺着调用图把下游 Service 里的权限校验代码和上游过滤器配置一并读取出来，打包成一份冻结的脱敏证据快照。”

“拿到完整的证据快照后，不能让一个 Agent 从头审到尾，那样它很容易顾此失彼，看完了代码规范就忘了排查权限漏洞。参考我们在 PaiCLI 里实现的 Better Harness 审查工作流，我把审查拆分成 3 条相互独立的只读审查通道，用固定大小为 3 的线程池并发执行。这三路分别排查外部输入边界与注入风险（SQL 注入、命令注入、SSRF、目录穿越与软链接逃逸）、身份认证与多租户接口越权，以及敏感凭证泄露、子进程环境变量污染与不安全的第三方依赖。”

多Agent并行审查时怎么防止误报刷屏和漏报放行？

“为了减少误报，我们在提示词和输出 Schema 里立了这样的规矩，每路专家提交的候选问题不能只写一句‘这里可能有注入风险’，必须同时给出四项内容，分别是可观察到的安全后果、精确到文件行号的证据边界、最小修复责任点以及可执行的验收方法。三路专家全部返回后，由一个独立的主审模型（Lead Reviewer）做交叉核验。主审会把没有污点的传播路径、或者上游已经有明确白名单拦截的猜测性警告剔除掉，只保留证据确凿的漏洞并评定高、中、低风险等级，最终由确定性的 Java 代码落盘生成结构化问题清单和可视化报告。”

03、RAG和长上下文模型，你觉得未来是替代关系还是互补？为什么？

“就目前以及未来相当长的一段时间来看，RAG 和长上下文模型一定是互补关系，谁也替代不了谁。长上下文解决的是‘把资料找出来之后怎么一口气读完整’的问题，而 RAG 解决的是‘怎么在海量、动态、带权限的数据里把那几页关键资料挑出来’的问题。”

“很多人觉得现在 Claude Opus 5.5、DeepSeek V4 都支持 1M Token 上下文了，是不是直接把知识库全放进提示词里就行了。算一笔账就知道行不通。一个中等规模企业的内部知识库或者一个几十万行代码的微服务仓库，动辄就是几千万甚至上亿 Token，1M 窗口根本装不下。退一步讲，就算资料刚好只有 80 万 Token 能放入窗口，每次用户问一个简单问题都要做 80 万 Token 的预填充计算，首字响应时间（TTFT）会飙升到好几秒甚至十几秒，单次请求的 API 账单和 GPU 显存开销直接涨一两个数量级。更何况大模型在百万级长文本里依然存在中间位置注意力衰减（Lost in the Middle），几百页无关文档混在上下文里，反而会稀释关键段落的注意力权重，诱发张冠李戴的幻觉。”

“还有一个长上下文永远绕不开的硬伤，就是企业级的多租户与组织权限隔离。在我们的企业级知识库项目派聪明里，不同部门的员工能看到的文档完全不同。如果靠长上下文把全公司的文档一股脑放入提示词（哪怕复用公共前缀缓存），再在 system 提示词里叮嘱模型‘不要回答非本部门的内容’，只要遇到简单的提示词注入，跨部门机密就会泄露。只有通过 RAG 在检索阶段把权限条件直接写进 Elasticsearch 的 BM25 布尔过滤器和 2048 维向量 KNN 的预过滤器（pre-filter）里，才能从物理上保证进入大模型上下文的每一个字符，都是当前用户有权限访问的数据。”

实际工程里怎么把RAG和长上下文结合起来用？

“工程落地的黄金组合就是‘小分块精准检索，大窗口完整阅读’。以前受限于 4K、8K 的小窗口，RAG 切块只能切几百字，检索命中后原样喂给模型，经常出现一句话被截断、表格缺了表头、代码只有半个方法体的情况；现在有了长上下文模型，我们完全可以把检索粒度和阅读粒度解耦开。”

“在派聪明里，我们入库切块依然保持小粒度，按自然段和标点切分成不超过 512 字符的子块，保证阿里云百炼 text-embedding-v4 生成的 2048 维向量语义纯粹、不掺杂多主题噪声。检索时，BM25 关键词检索和 KNN 向量检索双路并行召回前 150 条候选，经过 RRF 融合和 gte-rerank-v2 重排序拿到最相关的 Top-K 小分块。但在把结果交给大模型之前，父块扩展器会按命中分块的文件哈希、所属用户和分块序号，去数据库里把前后相邻的分块一起取出来，去掉块间重叠文本后合并成最高 1500 字符的完整父块（单次检索总预算控制在 6000 字符以内）。”

“如果同一个父块范围内命中了多个小分块，扩展器会按文件哈希加起止分块序号生成唯一键复用同一个父块，只在上下文里发送一次完整段落，同时保留小分块的精确页码和首句锚点用于前端高亮引用。在 PaiCLI 里也是同样的思路，先用基于 ripgrep 的关键词搜索或基于 JavaParser 抽象语法树的混合代码检索快速定位到目标文件和命中行号，自动生成从命中行往前 20 行、一共读取 80 行的文件读取建议，再把相关类的完整方法体和上下游接口放进长上下文窗口里让模型一次性完成跨文件重构。”

04、你怎么理解Agent中的长短期记忆？实际项目中分别如何实现？

“在 Agent 工程里，短期记忆和长期记忆是按信息生命周期和作用范围划分的两套完全不同的存储体系。短期记忆相当于当前任务的工作台，存的是这一轮或多轮对话里模型说的话、调用的工具参数、工具返回的原始结果，生命周期跟当前会话绑定，目标是保证眼下这个长程任务不走神、不断片；长期记忆相当于跨会话的经验笔记本，存的是用户的编码偏好、项目的构建规范、数据库表结构约定这些稳定事实，生命周期跨越所有会话，目标是让 Agent 下次启动时不用用户从头再交代一遍背景。”

“在 PaiCLI 里，短期记忆没有搞额外的内存副本，直接就是发送给大模型的对话消息列表，同时配了一个只追加写入本地 JSONL 文件的原始会话账本，用来支持会话断点恢复。因为代码 Agent 执行单元测试、搜代码极易把上下文撑爆，每次调用模型前，自动压缩管理器会按代价从小到大执行三档渐进式治理。第一档是超大结果卸载，单次工具输出超过 32000 字符时，直接把完整内容写进本地会话输出目录下的独立文件，上下文里只留文件路径、开头 2000 字符和结尾 800 字符的预览。第二档是清理旧工具结果，当上下文 Token 数达到摘要阈值的六成时，保留最近 3 条工具结果不动，把更早的工具消息正文替换成已清理占位符，但严格保留工具调用 ID 维持消息配对协议。第三档是结构化摘要，当 Token 数逼近窗口上限时，保留最近 3 个完整用户轮次，将更早的历史按 60000 字符分块，压缩成必须包含‘当前目标与成功条件、用户要求与已确认决定、已完成工作及证据、未解决问题与下一步’四个固定栏目的摘要；如果生成的摘要缺了任何一个栏目或者 Token 数没降下来，系统会先尝试修复一次，仍不合格就直接放弃压缩保留原历史，防止劣质摘要把任务带偏。”

“长期记忆则同时维护显式项目指令和动态结构化记忆。团队级硬性规范按顺序从用户全局目录、项目根目录与本地私有的指令文档合并加载，支持最多 3 层深度的相对路径导入和 24000 字符上限。而会话过程中动态积累的事实，则持久化在本地 JSON 结构化记忆库中，区分项目级（仅当前项目可见）和全局两个作用域，多进程并发读写时通过进程内锁、文件锁和临时文件原子替换保证数据不损坏。这些动态记忆既支持模型显式调用记忆保存工具写入，也会在每轮结束后由自动事实提取器按规则补充。”

长期记忆出现新旧冲突或过时污染时怎么治理？

“长期记忆用久了一定会碰上三类脏数据问题，分别是外部网页提示词注入污染、同一事实的新旧版本冲突（比如上个月记了‘项目用 Java 17’，今天升级成了‘项目用 Java 21’），以及代码改了但旧记忆还在的过时污染。”

“为了避免外部数据注入污染，我们的自动事实提取器立了死规矩，只从用户本轮亲手输入的原话里逐字摘取事实，自动过滤掉包含密钥、手机号的敏感词以及带有‘这次、临时、先这样’的短期指令，而且打上待核实标签。一旦本轮会话读取过外部网页、浏览器页面、MCP 资源或者执行过网络抓取命令，回合策略会立即锁死记忆写入，除非用户在当前原话里明确下令‘记住’，否则完全禁止调用记忆保存工具和自动提取。”

“针对新旧版本冲突，我们在去重器后面专门加了冲突检测器。去重器只合并标点或空白差异的完全重复项；而冲突检测器会把两条同域记忆里的所有数字和版本号替换成统一的特殊掩码字符，如果掩码后文字一模一样（说明只有版本号或数值变了），或者字符二元组（Bigram）的 Dice 相似度达到 0.8 以上，系统就会阻止静默写入，把旧条目和新条目同时列出来交给用户决定是替换还是共存。到了检索注入阶段，我们结合关键词分词与语义向量做混合召回，按窗口大小的 1/200 控制注入预算（夹在 500 到 5000 Token 之间）；每条记忆都带着写入时间和最后核实时间，一旦超过 30 天未核实，或者记忆关联的源码文件最后修改时间（mtime）比记忆核实时间更新，检索器就会降低它的排序权重并显式打上可能已过时的标记，在系统提示词里明确要求模型把长期记忆当线索而非绝对事实，动手改代码前必须以当前磁盘上的真实文件内容为准。”

05、是否了解KV Cache？它在大模型推理过程中起到什么作用？

“了解。KV Cache 是大模型自回归推理里用显存空间换计算时间的核心加速机制。它的作用是把预填充（Prefill）阶段和解码（Decode）阶段已经算出来的历史词元键（Key）和值（Value）缓存在 GPU 显存里，避免每生成一个新词都把前面的所有词从头重算一遍，将单步解码的计算复杂度从随序列长度平方级增长（ $O (N^{2})$ ）降到线性增长（ $O (N)$ ）。”

“具体来看，大模型生成回复分两个阶段。第一个阶段是预填充，模型一次性并行读入用户的全部提示词（假设有 $N$ 个词元），在 Transformer 的每一层里，通过乘上三个权重矩阵 $W_{Q}$ 、 $W_{K}$ 、 $W_{V}$ ，算出这 $N$ 个词元的查询向量 $Q$ 、键向量 $K$ 和值向量 $V$ ，完成注意力计算后生成第一个输出词元。第二个阶段是自回归解码，模型每次把刚生成的那个词元拼到序列末尾，去预测下一个词元。如果没有 KV Cache，生成第 $N + 1$ 个词时，模型得把前 $N + 1$ 个词全部重新过一遍线性投影和注意力矩阵乘法；到了生成第 1000 个词，前面 999 个词的 $K$ 和 $V$ 就被白白重复算了 999 次。而在因果注意力掩码（Causal Mask）下，前面位置词元的表示根本不会受后面新生成词元的影响，它们的 $K$ 和 $V$ 算过一次就永远固定了。把这些历史 $K$ 、 $V$ 张量存进显存，解码阶段每一步只需要针对最新的那 1 个词元计算它的 $q_{t}$ 、 $k_{t}$ 、 $v_{t}$ ，把 $k_{t}$ 、 $v_{t}$ 追加进缓存，再用 $q_{t}$ 去和缓存里全部的 $K$ 、 $V$ 做点积与加权求和即可。”

为什么只缓存K和V而不缓存Q？长上下文下KV Cache占满显存怎么优化？

“不缓存 $Q$ 是由自回归注意力矩阵的运算方式直接决定的。在第 $t$ 步生成新词元时，我们要算的是第 $t$ 个位置的隐藏状态输出，公式是拿当前第 $t$ 个词元的查询向量 $q_{t}$ ，去和第 $1$ 到第 $t$ 个词元的键向量 $k_{1 \dots t}$ 做点积算相关性权重，再对 $v_{1 \dots t}$ 加权求和。在这个过程里，历史位置 $1 \dots t - 1$ 的查询向量 $q_{1 \dots t - 1}$ 已经在它们各自生成的那一步用完了，后续任何一个新词元的计算都不会再读取旧的 $Q$ 。留着旧的 $Q$ 纯属浪费显存，所以只缓存后面每一步都必须反复读取的 $K$ 和 $V$ 。”

来源：HySparse2 论文 Figure 4。比较条件为 80B-A3B 研究模型、最长 1M Token、FP8 KV Cache；论文计算量分析不等同于应用实测延迟。

“但 KV Cache 的代价是显存占用会随着批次大小和序列长度线性膨胀。按公式计算，每个词元的 KV Cache 字节数等于 $2 \times 层数 \times KV头数 \times 头维度 \times 精度字节数$ 。在长上下文和并发请求下，KV Cache 占用的显存很容易超过模型权重本身，把解码阶段彻底推向显存带宽受限（Memory-bound）。要化解这个瓶颈，需要模型架构、推理引擎和上层 Agent 工程三端配合。”

“在模型架构与推理引擎侧，主流做法是用分组查询注意力（GQA）或多头潜在注意力（MLA）减少 KV 头数和缓存维度，用 vLLM 的 PagedAttention 按固定大小的块分页管理显存消除碎片，再用 FP8 量化把单元素字节数减半。针对 Agent 场景‘发一个短动作调用、换回一大段长工具观察结果’导致预填充占比极高的特点，最近 MiMo 团队在论文里提出的 HySparse2 混合稀疏注意力架构非常典型，它在 80B 总参数（激活 3B）的 MoE 模型上只保留少数全注意力层并做跨层 KV 共享，在 1M 上下文、FP8 精度下把 KV Cache 显存从混合滑动窗口注意力的 12.09GB 直接压到了 2.69GB，预填充计算量降低了 5.02 倍。加上 NVIDIA Dynamo 这类分布式推理栈的 KV 感知路由（KV-Aware Routing）和预填充与解码分离部署，可以把同一个 Agent 会话的第 $N + 1$ 轮请求精准路由到已经缓存了前 $N$ 轮 KV 块的 GPU 节点上。”

“到了我们写 Agent 应用的工程侧，最直接的优化就是围绕服务端的 Prefix Caching（前缀缓存）做上下文布局设计。因为推理引擎的前缀缓存是按词元序列从头往后做严格前缀匹配的，中间只要改了一个字符，后面的 KV Cache 就全部失效。所以在 PaiCLI 的系统提示词组装器里，我把 9 层提示词严格按照稳定度从高到低排列，把整个会话期间绝不改变的基础规则、人格、执行模式、审批规范、上下文管理指令和收尾指令放在最前面，把只在启停时变化的 Skills 索引和按天变化的运行时日期放在中间，而把随用户每一轮提问动态检索出来的项目上下文与长期记忆放到最末尾；同时在工具注册表导出 Schema 时按工具名称字典序固定排序，并且把运行中按需加载的 Skill 正文作为同轮独立的 user 消息追加在对话尾部而不去改动顶层 system 提示词。根据 NVIDIA 对多轮编码 Agent 流量的实测数据，保持前缀逐字节稳定能让多轮会话的 KV 缓存命中率达到 85% 到 97%，首字延迟降低约 5 倍，输入 Token 成本也能省下大半。”

PaiCLI 如何写到简历上？

项目名称：PaiCLI（对标 Claude Code 的生产级终端 AI Coding Agent）

项目简介：基于 Java 17 从零构建的商业级命令行编码 Agent，支持 ReAct、Plan-and-Execute（DAG 拓扑校验与失败重规划）与 Multi-Agent Team 三种执行方式，内置 18 个工具、MCP 协议客户端、LSP 语法诊断、Side-Git 独立快照回滚与 Docker 隔离自动化评测体系。

技术栈：Java 17 + OkHttp + Jackson + JavaParser + SQLite + JGit + JLine + MCP 协议 + Docker

核心职责：

设计按稳定度排序的 9 层系统提示词组装机制与字典序固定工具 Schema，将每轮动态变化的长期记忆后置，并将按需加载的 Skill 正文改为会话尾部独立消息注入，保障多轮工具调用下的 KV Cache 最长公共前缀命中
实现三档渐进式短期上下文压缩与流式请求体序列化，通过超 32000 字符工具输出自动落盘预览、超阈值清理旧工具结果正文保留调用 ID、逼近窗口上限时生成四栏目结构化摘要控制上下文膨胀，配合 Jackson 直接写网络输出流将 1M Token 场景下单次请求堆内存分配从 90.5MB 降至 4.7MB
构建跨会话长期记忆分层治理体系，支持项目级指令文件合并加载与带文件锁的多进程安全持久化，写入时通过数字掩码变体识别与字符二元组 Dice 相似度（阈值 0.8）拦截新旧事实冲突，并在读取外部不可信内容后自动锁死记忆写入防止提示词注入污染
实现原生多路并行审查工作流与默认拒绝门禁，先冻结脱敏证据快照，再通过 3 个剥离写与执行工具的只读专家线程并行审查，由主审模型按证据边界与最小修复责任方交叉核验并生成结构化报告，审查判定严格校验 JSON 布尔字段杜绝误放行
搭建断网只读 Docker 沙箱下的 28 题自动化评测体系与位置平衡模型裁判，结合 JavaParser 写后实时语法诊断、独立进程隐藏单元测试退出码判定、Rubric 硬门槛 Java 计分以及交换 A/B 顺序二次复评机制，消除评测位置偏见与数据泄漏

ending

失去 Claude 的第二周，除了编码层面，其他都找到了对应的替代品。

看来有些东西并非真的必需。

随着其他模型能力的提升，失去 Opus 5.5 也不见得就无法学习和工作。

当然了，我也会尽量尝试找回 Opus 5.5 的方法，比如试试中转。

或者远程租赁，等方案成熟了再给大家汇报。

继续冲啊。