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

《面试题目》

1. 项目是用什么语言开发的，哪些是用 Go 开发的？
2. 有没有看过 Go 的 Agent 框架？
3. 意图识别具体是怎么做的，最终的准确率有多少？
4. 95% 的准确率是有专门的评测数据来验证，还是线上观察的？
5. 线上跑的话，用户的提问大部分会落到多意图吗？
6. 上下文工程和 memory 模块是怎么做的？
7. KV Cache 命中率能有多高，怎么做的优化？
8. 上下文如果多轮对话，有没有做上下文压缩和摘要？
9. 上下文压缩是同步做的还是异步做的？
10. 记忆模块有没有做什么工作，mem0 怎么做的了解吗？
11. Agent 线上部署的规模怎么样，访问的用户量多少？
12. 有没有做整体效果的评测？
13. 全链路观测的数据是用什么存储的？
14. 大事件项目怎么做的？

《参考解析》

1. 准确率的数字要怎么站得住：面试官追问「是评测集还是线上观察」时，想区分的是「你知道自己准不准」还是「你有个印象」。靠谱的答案必须包含评测集怎么来的——从真实流量采样、人工标注、固定成回归集；指标怎么算——准确率之外还要看各类别的召回和混淆矩阵，因为总体 95% 可能掩盖某个类几乎全错；以及线上怎么看——抽样人工核对或用户反馈信号（重问率、转人工率）。如果只有线上观察，老实说这是弱证据，并说清下一步打算怎么补评测。

2. 多意图请求怎么处理：真实用户提问经常一句话里包含多个诉求。做法上分两种：一是把意图识别从单标签改成多标签（每个意图独立判一次，或用一个多标签模型），置信度都低于阈值就走澄清；二是先做任务拆解，把一个请求拆成有序的子任务再逐个执行，最后合并结果。关键在于要有「澄清」这个出口——硬猜多意图比只做一个意图更容易全错。

3. KV Cache 命中率怎么优化：KV Cache 的命中前提是前缀完全一致。所以优化的核心是让 prompt 的稳定部分排在前面：系统提示、工具定义、长期稳定的上下文放在最前且内容逐字节不变；易变的部分（当轮用户输入、检索结果）放后面。反过来，任何插在最前面的变动（比如把动态时间戳拼进 system prompt、按请求重排工具顺序、随机裁剪 skill 正文）都会让后面整段缓存失效。多轮对话里保留历史消息的原始形式、不要在中间插入临时信息，命中率会明显更高。量化收益时要按 token 单价算——缓存命中的输入 token 通常便宜一个数量级。

4. 上下文压缩：同步还是异步：看它是不是阻塞用户响应。同步压缩发生在生成前，用户要等压缩完成，好处是本次请求立刻受益、逻辑简单，代价是首 token 延迟变高；异步是后台定期把已完成的历史轮次压缩成摘要，用户请求走的是已压好的版本，延迟低但摘要可能滞后一轮。工程上常见的是混合：会话内早期轮次异步预压，接近窗口上限时同步兜一次。无论哪种，摘要都要保留「已确认的事实和决策」，并且原始记录不能删——出问题时需要回溯。

5. memory 与 mem0 这类方案：mem0 的思路是从对话里抽取事实性记忆、存进向量库（配 metadata），检索时按相关性取回注入上下文，并支持更新/删除单条记忆。它解决的是「跨会话记住稳定事实」，不解决「当前会话的完整历史」。自己实现时最容易踩的坑是：抽取出来的事实没有出处、无法纠错；记忆无限增长导致检索噪声越来越大；以及把本该短期存在的东西写成了长期记忆。所以写入要有门槛、每条带来源和时间、支持按时间衰减。

6. 全链路可观测性：一次 Agent 请求的链路是「用户请求 → 意图/路由 → 检索 → 模型调用（可能多轮、多个工具）→ 工具执行 → 结果聚合 → 输出」，每一跳都要能串起来。落地做法是给每次请求一个 trace id 贯穿全链路，记录每跳的耗时、输入输出摘要、token 数与成本、错误与重试。存储上分两类：明细日志进对象存储/日志系统（数据量大、按需查），聚合指标进时序库或 OLAP（做看板与告警），trace 数据进专门的链路追踪系统。关键是「能按某次请求把全过程捞出来」——只存聚合指标是没法定位单次异常的。