腾讯营销后端一面：Agent 上下文体系与多路归并

《面试题目》

1. 请做一下自我介绍。
2. 你是哪里人？毕业后打算读研，还是直接就业？
3. 选一段实习项目详细介绍一下。
4. 你介绍的 Agent 基础设施是广告团队做的吗？是否也面向公司其他业务方？
5. Skill 是怎样被发现和按需加载的？
6. 加载后的 Skill 正文放在模型上下文的什么位置？
7. Skill 使用完后，什么时候从上下文里卸载？下一轮还会带上吗？
8. 下一轮不再带 Skill 正文，会不会影响模型的 Prefix Cache？
9. 上下文压缩机制具体是怎么做的？
10. 遇到很长的 Tool Result，怎么压缩？
11. 历史信息压缩后，Agent 怎样按需找回原始内容？
12. 历史信息的索引分几层？各层是什么关系？
13. 你们的内部 SDK 和开源某框架是同一个东西吗？
14. 这段实习里，你自己具体完成了哪些工作？
15. 一个需求从提出到上线，AI 可以怎样参与整个开发过程？
16. 需求、设计、编码这些阶段，是在一轮对话里完成，还是会用 Skill、子 Agent 等能力？
17. Agent 怎样理解本地项目以外、其他仓库里的代码？
18. 业务知识库和可复用的 SOP，怎样沉淀给 Agent 使用？
19. 测试、发布和验收阶段，哪些由 AI 来做，哪些需要人来做？
20. 有 N 个升序数组，每个数组长度为 M，怎样合并成一个升序数组？
21. 如果把所有元素都放进堆，时间复杂度是多少？
22. 能不能利用每个数组本来就有序这个条件，进一步优化？
23. 优化后的时间复杂度是多少？

《参考解析》

Skill 的按需加载与卸载：Skill 通常是「元数据常驻、正文按需注入」——系统提示里只放名称与简短描述（让模型知道有哪些能力），命中后才把完整正文插入当前轮。位置一般紧跟系统指令之后、用户消息之前，作为可替换的上下文区块。卸载的目的是控制 token 与注意力污染，但卸载会破坏 Prefix Cache：缓存按前缀逐 token 命中，一旦中间某段被删改，后面所有内容都要重新计算。实践中的取舍是：把不变的部分（系统指令、稳定元数据）放前面并保持字节级一致，把会变的 Skill 正文放在靠后位置，或者干脆保留已加载的 Skill 正文直到会话结束——用缓存换 token 通常更划算。

上下文压缩：分层处理。短期保留原文；中期把成组的工具调用与结果做摘要（保留结论、丢弃中间过程）；长期只留索引与关键结论。长 Tool Result 的压缩要点是”保留可回查的指针”——原文落到对象存储或数据库，把 result_id + 摘要（含关键字段、条数、是否截断）回灌给模型。同时要显式标注截断，避免模型误以为拿到了全量。

压缩后如何找回原文：靠索引分层。典型三层：会话级索引（本轮涉及哪些来源）、文档/结果级索引（每份原文的元数据与摘要，可全文检索或向量检索）、以及片段级定位（章节、页码、行号）。模型先检索到摘要层，再按 ID 拉取需要的片段。索引之间是”粗到细”的引用关系——上层指路、下层给内容，这样即使原文很长也不会一次性占满上下文。

AI 参与研发全流程：需求阶段可以帮做需求拆解与影响面分析（检索相关代码、历史 issue）；设计阶段产出方案草稿与接口定义；编码阶段用 Skill 和子 Agent 分工（一个查代码、一个写实现、一个补测试）；测试阶段生成用例并跑、失败后把日志交给修复节点；发布阶段由人审批，AI 只做构建、灰度与健康检查的自动化。边界很清楚：AI 做执行与初稿，人做决策与验收。跨仓库代码的理解靠”索引 + 依赖图 + 检索”，而不是把代码全塞进上下文；SOP 则要沉淀成可复用的 Skill 或流程定义，带上触发条件与校验步骤。

N 个升序数组合并：全部入堆的做法是把 N×M 个元素都推进最小堆再逐个弹出，时间 O(NM log(NM))，空间 O(NM)——只用了”每个数组有序”这个条件的一半。更优的是多路归并：堆里只放 N 个元素（每个数组当前的头），每次弹出最小并压入它所在数组的下一个元素，共弹出 NM 次、每次堆操作 O(log N)，时间 O(NM log N)，空间 O(N)。如果要求原地输出且数组是链表，空间还能降到 O(1)（用分治两两归并，时间 O(NM log N)）；若 N=2 则退化为经典双指针归并，时间 O(NM)、空间 O(1)。