腾讯 CSIG 后台开发一面：Agent Memory、SkillRouter 与多 Agent Code Review
面经与参考答法
腾讯 CSIG 后台开发一面：Agent Memory、SkillRouter 与多 Agent Code Review
原帖发布于 2026 年 7 月，未披露具体面试日期。本文按主题选录可见技术问题，省略流程介绍、自我介绍、个人实习经历、项目选择和导师分工的个人陈述。全部短答和方案为教学整理，不代表候选人现场作答、实际项目实现或企业标准答案。
这场约 1.5 小时的后台开发一面从 Agent 项目展开，连续追问 Memory、SkillRouter、多 Agent PR Review、并发和评测，随后考察跨线程任务、gRPC、竞态条件、链表与图像处理。回答时要把项目叙述落到可验证的系统设计。
（1）怎样用“目标、挑战、解决方案”介绍项目？
（1）怎样用“目标、挑战、解决方案”介绍项目？
关联知识点待核实。
先说明用户、核心任务和成功指标，再给出约束，例如时延、数据权限、模型能力或已有系统。选择一个真正影响方案的挑战，列出考虑过的备选路径，解释为何采用当前方案；最后用测试、线上指标或用户反馈验证结果，并明确本人负责的模块。
如果架构由多人共同完成，应区分自己提出、实现、评审和维护的部分。项目介绍的价值在于展示决策过程，而不是把所有组件名串在一起。
（2）三层 Agent Memory 可以怎样划分？
（2）三层 Agent Memory 可以怎样划分？
关联知识点待核实。
一种常见划分是：工作记忆保存当前步骤与工具结果；会话记忆保存本次任务的摘要、计划和检查点；长期记忆沉淀跨会话仍有效的事实、偏好与经验。三层分别解决即时决策、任务连续性和跨任务复用，读写策略、生命周期与可信度不同。
长期记忆必须带来源、时间、作用域、权限和版本，写入前去重与确认；读取时综合相关性、时效和访问控制。分层本身不是目标，减少无关上下文、支持恢复并提升任务成功率才是验证标准。延伸阅读：Agent Memory 架构。
（3）Memory 怎样配合上下文、格式化输出与 Token 成本控制？
（3）Memory 怎样配合上下文、格式化输出与 Token 成本控制？
关联知识点待核实。
运行时根据当前步骤检索最小充分信息，把目标、约束、近期事件和证据组织成稳定 Schema；较早轨迹压缩为可核验摘要，大日志和文档外置并保留引用。模型输出先经过 Schema 校验，再进入状态或触发工具，避免自由文本直接污染记忆。
为每类上下文设置 Token 预算，记录召回内容、实际使用率、缓存命中、任务成功率和单位任务成本。压缩不能只追求字数减少，还要测试关键事实、否定条件和未完成事项是否可恢复。
（4）SkillRouter 应该怎样设计？
（4）SkillRouter 应该怎样设计？
关联知识点待核实。
每个 Skill 提供稳定 ID、适用场景、输入输出 Schema、权限、成本和示例。Router 先用规则过滤不满足权限、输入类型和必备条件的 Skill，再用关键词或语义模型排序；得分接近或低于阈值时请求澄清或回退，不能强行选择。
路由结果还要经过参数校验和运行时授权。评测集应覆盖正确命中、无 Skill 可用、多个 Skill 冲突和对抗描述，指标包括 Top-K 命中率、误路由率、任务成功率、延迟和成本。延伸阅读：Agent 工具选择与路由。
（5）怎样测试 Memory、向量召回和关键词匹配，并评估成本？
（5）怎样测试 Memory、向量召回和关键词匹配，并评估成本？
关联知识点待核实。
从真实任务构造带期望记忆或证据的 Golden Set，分别测 Recall@K、MRR/nDCG、权限过滤正确率、过期信息命中率和冲突处理；再测完整任务成功率，防止“召回到了”却没有被模型正确使用。关键词与向量检索要保留分路结果，才能定位失败来自数据、召回、重排还是生成。
经济性应按每个成功任务统计模型 Token、Embedding、重排、向量存储、请求次数和 P95 延迟，并与不使用该模块的基线比较。延伸阅读：Agent 评测。
（6）项目仍在使用时，怎样发现问题并规划改进？
（6）项目仍在使用时，怎样发现问题并规划改进？
关联知识点待核实。
把失败分成路由错误、召回不足、工具失败、格式不合法、超时和用户纠正等类型，记录完整但脱敏的 Trace。高频或高风险失败进入回归集，先复现再修改；新版本用离线对比和小流量灰度验证，保留回滚能力。
改进项应对应指标和完成条件，例如降低误路由率或恢复成功率，而不是笼统地“换更强模型”。
（7）从提交 PR 到生成 Review 意见，链路怎样设计？
（7）从提交 PR 到生成 Review 意见，链路怎样设计？
关联知识点待核实。
Webhook 到达后先验签、去重并记录仓库、PR 和 commit SHA；系统获取固定版本的 diff 与必要代码上下文，做语言、路径和风险分类，再路由到相应分析器。可并行执行安全、正确性、性能或规范检查，汇总器去重、核验证据和严重级别，最后以当前 commit SHA 为前提发布评论。
每一步保存状态、输入版本和幂等键。PR 更新后旧任务应取消或标记过期，评论引用具体文件与行，并区分确定缺陷和建议，避免模型猜测成为阻断结论。
（8）为什么拆成五个 Agent，一个 Agent 不可以吗？
（8）为什么拆成五个 Agent，一个 Agent 不可以吗？
关联知识点待核实。
单 Agent 完全可能完成任务，而且上下文共享、调试和成本控制更简单。只有不同职责需要隔离权限或上下文、可以真正并行，或需要独立核验时，拆分才有收益。角色数量应来自任务边界和评测，而不是预先追求“五个”。
多 Agent 需要定义统一消息 Schema、共享状态的所有者、预算、超时、冲突裁决和最终责任方。若拆分后成功率没有提高或成本显著上升，应合并角色。延伸阅读：多智能体协作与适用边界。
（9）RouterAgent 与多个并行 Agent 怎样编排？
（9）RouterAgent 与多个并行 Agent 怎样编排？
关联知识点待核实。
RouterAgent 输出结构化的任务类型、目标 Agent、输入引用和置信度，由确定性编排器校验后执行。并行分支拥有各自上下文和截止时间，通过 run ID、step ID 和输入版本关联结果；汇总器处理重复、冲突、缺失和部分失败，必要时只重试失败分支。
路由、扇出、等待和聚合应由可持久化状态机负责，不宜完全依赖模型自由对话。延伸阅读：多 Agent 消息与状态同步、Supervisor 编排。
（10）系统怎样同时处理多个 PR？
（10）系统怎样同时处理多个 PR？
关联知识点待核实。
每个 PR 的每个 commit 建立独立 run，通过队列削峰，并按仓库、租户和模型供应商设置有界并发与速率限制。执行环境使用隔离工作区或容器，缓存按 commit SHA 定位；优先取消同一 PR 已过期的旧 run，避免把旧评论写回新代码。
任务使用稳定幂等键，Worker 采用租约和心跳，失败按错误类型限次重试。系统可以并发处理不同 PR，但同一资源上的写操作仍要有明确顺序。
（11）一个 PR 有多个作者时，怎样处理并发问题？
（11）一个 PR 有多个作者时，怎样处理并发问题？
关联知识点待核实。
“多个作者”本身不必然产生数据竞争，真正的风险来自同时推送、重复 Webhook、评论更新和多个 Worker 处理同一版本。入口先去重，状态更新使用版本号或 CAS；发布评论前再次检查 head SHA，必要时用短租约确保同一任务只有一个有效提交者。
模型生成不能持有长时间数据库锁。外部写操作要幂等，并保存远端操作 ID，以便超时后先查询状态再决定重试。延伸阅读：Agent 并发与资源隔离、幂等设计。
（12）跨线程投放任务应该怎样实现？
（12）跨线程投放任务应该怎样实现？
关联知识点待核实。
生产者把任务放入线程安全队列，目标线程通过条件变量、事件通知或 eventfd 被唤醒后取出执行。任务数据在入队前完成构造，所有权通过值、智能指针或消息对象明确转移；共享队列用互斥锁加条件变量，或采用经过验证的 MPSC/MPMC 实现。
要处理队列上限、关闭流程、取消和异常，避免丢失唤醒、悬空引用和目标线程退出后继续投递。延伸阅读：线程同步。
（13）gRPC 能否替代跨线程任务队列？
（13）gRPC 能否替代跨线程任务队列？
关联知识点待核实。
gRPC 解决跨进程或跨机器的 RPC 通信，提供基于 HTTP/2 的接口契约、流式传输、截止时间和取消等能力；线程内队列解决同一进程中的任务所有权与调度，两者层级不同。若模块需要独立部署，可用 gRPC 连接服务，但服务内部仍可能需要队列和线程池。
使用 gRPC 时还要明确超时、重试、幂等、背压、负载均衡和错误语义，不能把一次远程调用当作可靠消息投递。延伸阅读：gRPC 基础。
（14）高并发服务器或内存池中常见哪些竞态条件？
（14）高并发服务器或内存池中常见哪些竞态条件？
关联知识点待核实。
典型风险包括多个线程同时修改任务队列、连接表、定时器、空闲链表或引用计数，一个线程释放对象时另一个线程仍在访问，以及关闭流程与回调并发。先明确每份状态的唯一所有者和不变量，再按临界区选择互斥锁、原子变量、线程封闭或消息传递。
无锁结构还要考虑 ABA、内存回收和内存序。使用 ThreadSanitizer、压力测试、故障注入和关闭竞态用例验证，不能仅凭代码审阅断言线程安全。
（15）怎样删除链表中的重复元素？
（15）怎样删除链表中的重复元素？
关联知识点待核实。
先澄清链表是否有序，以及是“每个值保留一个”还是“重复值全部删除”。有序链表若保留一个，只需单次遍历：当前节点与下一节点值相同时跳过下一节点，否则前进，时间 O(n)、额外空间 O(1)。
若要删除所有重复值，需要哑节点和前驱指针，发现一段相同值后整体跳过。无序链表可用哈希集合记录已见值，时间 O(n)、空间 O(n)；若限制额外空间，则通常需要 O(n²) 比较。
（16）怎样检测图片的 Alpha 通道？
（16）怎样检测图片的 Alpha 通道？
关联知识点待核实。
先解码图片并确认像素格式、通道数与位深。若问题是“格式是否支持 Alpha”，读取颜色类型或元数据即可；若问题是“是否实际存在透明像素”，还要扫描 Alpha 值，只要发现小于完全不透明上限的像素即可提前返回。
实现时要覆盖 RGBA、灰度加 Alpha、调色板透明和预乘 Alpha，统一不同位深的上限，并明确解码失败与无 Alpha 的返回语义。对超大图片可分块扫描，避免额外复制整张像素数据。