腾讯社招一面面经（Agent 方向）

《面试题目》

1. 介绍一下项目
2. 项目用了什么框架？（LangChain + LangGraph）
3. 为什么用这个框架，怎么做的技术选型？
4. 方案审核这一块，有哪些指标判断方案不合适？
5. 如果审核有问题，会怎么反馈到整个链路中？
6. 系统有没有做一些可观测性的工程？
7. 调用 sub-agent 的时候，会把主 Agent 的一些 context 带到 sub-agent 里吗？
8. 内容很长的话会超出上下文窗口吗？
9. 压缩机制是自己设计的，还是用 LangGraph 自带的？
10. 介绍一下 token 消耗优化的一些手段
11. 了解其他优化 KV Cache 命中效率的手段吗？
12. 怎么样设计 Skill 系统？
13. 如果 Skill 折叠、移除了 Skill，会导致 KV Cache 被破坏吗？
14. 有没有做过实验？衡量过移除 Skill 正文和不移除 Skill 正文的 token 成本消耗？
15. 大模型可能只知道工具调用，那 Skill 调用是怎么实现的？
16. Skill 本身是一个工具还是多个工具？
17. 项目主要用到了哪些模型？
18. 有去做审核相关的评测吗？

《参考解析》

1. Skill 系统怎么设计：Skill 不是一个新概念，它是把「一类任务怎么做」固化成可复用的说明 + 可调用的入口。设计时要解决三件事：发现（模型怎么知道有这个 Skill——靠名称和描述，所以描述要写触发条件而不是实现细节）、加载（正文多长、什么时候把完整内容注入上下文——常用做法是渐进式披露，先只给一行摘要，模型决定用了再把正文拉进来）、执行（Skill 描述流程，实际动作仍落到工具调用上）。Skill 之间要保证语义不重叠，否则模型会在几个相似 Skill 之间摇摆。

2. Skill 调用是怎么实现的、一个还是多个工具：大模型本身只会「调用工具」这一种动作，所谓 Skill 调用是在它之上包了一层。常见实现是两级——一个 use_skill(name) 之类的通用工具负责「选中并加载 Skill 的说明正文到上下文」，Skill 正文里再描述具体要用哪些底层工具、按什么顺序做；另一种是把每个 Skill 直接注册成一个工具（描述即 Skill 摘要，调用即执行）。前者的好处是工具数量固定、上下文可控，适合 Skill 很多且会持续增加的系统；后者的好处是链路短、少一次模型决策，适合 Skill 少而稳定的场景。多数生产系统是混合的：少数高频 Skill 直接注册成工具，长尾的走 use_skill。

3. KV Cache 与 Skill 折叠：KV Cache 命中的前提是前缀逐字节一致。如果把 Skill 正文插在 prompt 前部，那么任何变化——新增、删除、重排、甚至只是顺序变了——都会让那段之后的所有缓存失效，下一次请求要重新prefill。所以「移除 Skill 正文」对缓存的影响取决于它插在哪：在系统提示之后、对话历史之前，那么移除会让后面整段失效；只影响它自己那一段（如果它本来就在末尾）。稳妥的做法是把稳定内容（系统提示、工具定义、当前启用 Skill 的固定集合）放最前面并保持顺序稳定，易变内容（本轮检索结果、用户输入）放最后；Skill 集合的增删尽量低频，并在会话内固定。

4. 有没有量化过代价：这种题面试官要的是「你做过实验」。可测的口径是：固定同一批请求，分别跑「保留 Skill 正文」和「移除 Skill 正文」两个版本，比较输入 token 数、缓存命中率、以及端到端延迟和成本；同时看效果指标（任务成功率）有没有下降。结论通常不是「越短越好」——正文能提升选中正确率，砍掉省了 token 但换来更多选错和重试，整体可能更贵。所以要用「单位成功任务成本」来判，而不是单看 token 数。

5. Token 优化手段：分几类——减少输入（检索只取相关片段而不是全量文档、工具定义按需加载、历史轮次摘要压缩、去重重复的 few-shot 示例）；提高缓存命中（稳定前缀 + 易变后缀、保持工具与 Skill 顺序稳定、多轮对话保留原始消息形式不插入临时内容）；减少输出（约束输出格式、限制不必要的解释、能确定性做的一律交给代码而不是让模型生成）；减少轮次（合并可以并行执行的工具调用、把多步判断压成一次结构化输出）；以及模型路由（简单任务走小模型，复杂任务才上大模型）。每一项都要能报出量级才有说服力。

6. sub-agent 要不要带上主 Agent 的 context：带，但要挑。全量带过去的问题很明显——token 成本翻倍、噪音变多、而且 sub-agent 会被主 Agent 的中间结论带偏。实际做法是传「已经确定的结论 + 当前任务需要的最小输入 + 期望的输出格式」，而不是把整段对话历史复制过去；主 Agent 只保留 sub-agent 的结论摘要，明细留在日志里。如果 sub-agent 需要更多背景，给它检索工具让它自己按需拉，比一次性灌进去更好。

7. 审核评测怎么做：先定义「什么叫不合格」，把它拆成可判定的维度（事实性错误、逻辑不完整、不符合约束条件、不可执行），每个维度给出正反例；再用一组覆盖各维度的样本做回归集，每次调整 prompt 或换模型都跑一遍看指标变化。如果审核本身也是模型做的，还要定期人工抽检它的判断，避免「审核器自己跑偏了没人发现」。