牛客面经精选

Appearance

面经精选 2026-10-15 ​

收录概览 ​

本期检索 AI/Agent、Golang 后端、服务端/后台开发关键词，优先筛选 2026-10-14～10-15 的公开帖子，并排除与近 7 日已收录内容重复、正文不可获取或明显偏离目标方向的帖子。今天收录 3 篇可核验面经，覆盖 AI 测试、Python Agent、AI 全栈与数据库基础，重点是评测指标、上下文治理、Agent Harness、Redis/MySQL 和资源型场景题。

  • 虎牙｜测试开发｜一面：AI 测试用例生成、准确率/召回率、AI Harness、Agent 重复调用、压测与基础题
  • 安恒信息｜Python Agent 开发实习｜一面：大模型结果不可靠、上下文裁剪、项目沉淀与全栈协作
  • 字节跳动｜AI 全栈开发实习｜一面：多 Agent 编排、Redis、MySQL B+Tree/MVCC、海量数据 TopK、区间合并

来源索引 ​

说明：以下内容是对牛客公开技术问题的结构化改写，不代表整理者亲历；只保留可迁移的技术考点，不复制个人隐私和原帖长段落。回答中的工程展开是通用复习思路，不能当作原帖作者的事实经历。

一、AI 应用与 Agent 工程 ​

Q1：AI 测试用例生成平台如何证明效果？准确率和召回率怎么答？ ​

回答思路： 先定义任务边界：输入是需求、页面或代码，输出是测试点、用例或可执行脚本；再定义样本、标注规则和评测粒度。召回率回答“应覆盖的有效测试点找到了多少”，准确率回答“生成结果中有多少确实有效”，二者都要说明分母、去重规则和人工复核方式。若是执行型 UI 测试，还要补充脚本可执行率、定位成功率、缺陷发现率、误报率和回归通过率，不能只报一个漂亮数字。与传统 UI 自动化比较时，应说明稳定性、维护成本、覆盖变化和误报，而不是笼统说 AI 更好。

易踩坑 / 追问： 没有真实统计就不要编造百分比；测试集不能只由模型生成，至少要有人工样本、未见场景和线上 badcase。面试官继续问“怎么提升”，可答规则校验、结构化输出、失败样本回流、模型与代码双重验证。

Q2：什么是 AI Harness？它和 Prompt 工程的核心区别是什么？ ​

回答思路： Prompt 工程主要优化给模型的任务描述、示例、约束和输出格式；Harness 是包裹模型的运行时工程，负责上下文组装、工具注册与 Schema 校验、权限、安全边界、状态和 checkpoint、重试/超时/取消、结果验证、观测与评测。可以用“模型提出候选动作，Harness 决定能否执行、如何执行以及是否接受结果”来解释边界。回答项目时要讲清自己实现了哪些模块，避免把框架自带能力说成个人工作。

易踩坑 / 追问： 只会改 Prompt 不能解决工具副作用和失控循环；高风险动作要有人审或策略拦截，工具参数要做类型和权限校验，所有重试都要考虑幂等。

Q3：Agent 连续调用同一个工具或子 Agent 爆炸，如何处理？ ​

回答思路： 运行时维护每个任务的步骤数、工具调用计数、相同参数指纹、错误次数、Token/时间预算和最近进展。对重复动作设置检测与上限，对无进展循环触发重新规划、降级回答或人工接管；对并行子任务设置全局并发、深度、总预算和超时，使用取消传播和熔断。工具返回结构化状态，包括是否完成、下一页游标、可重试原因和建议动作，不能让模型只能从自然语言猜下一步。

易踩坑 / 追问： 最大步数不是唯一保护；“每次调用都成功但状态不变”同样是死循环。状态和事件要持久化，服务重启后从 checkpoint 恢复，不能依赖进程内计数。

Q4：多轮工具调用导致上下文持续膨胀，如何做裁剪？ ​

回答思路： 先区分不可丢的系统约束、当前目标、关键工具结果和可压缩的历史观察。按 token 预算保留最近窗口与任务摘要，对大文件或长结果使用分页、游标、引用和按需读取，不把全部原文塞给模型；重要事实保留来源和版本，摘要要能回溯原始证据。裁剪由代码规则和状态管理控制，模型可以提出摘要，但不能单独决定安全策略和持久化策略。

易踩坑 / 追问： 只做字符串截断可能丢掉约束或破坏 JSON；要在裁剪后做 Schema 校验、关键事实检查和回放评测，并为不同租户设置成本上限。

二、数据库、服务端与场景题 ​

Q5：MySQL B+Tree、回表和 MVCC 怎么串起来讲？ ​

回答思路： B+Tree 的非叶节点保存键和指针，叶子节点保存有序索引记录并通过链表便于范围扫描；辅助索引只拿到主键、再去聚簇索引取完整行叫回表。覆盖索引能直接提供查询所需列，减少回表。MVCC 通过版本信息和 Read View 让事务读取符合隔离级别的可见版本，普通一致性读与当前读的行为不同。最后结合执行计划解释索引选择、联合索引最左匹配和回表成本，不能只背概念。

易踩坑 / 追问： 索引不是越多越好，会增加写放大和存储；“用了索引”也不等于快，要看扫描行数、回表、排序、锁等待和实际执行计划。

Q6：10 亿条 URL、只有 1GB 内存，怎样找 Top100？ ​

回答思路： 先明确 Top 的定义和是否允许近似。精确方案可分块读取，使用外部哈希分区把相同 URL 聚到同一文件，逐块统计频次；每个分区用大小为 100 的最小堆保留局部 Top100，最后合并所有候选。若 URL 极多且允许误差，可用 Count-Min Sketch 做频次估计，再对候选集精确计数。工程上还要说明磁盘空间、哈希倾斜、流式读取和异常 URL 处理。

易踩坑 / 追问： 不能直接把全部计数放内存，也不能只保留全局遇到的前 100 条；频次高的 URL 可能很晚才出现。回答复杂度时说明单遍/多遍、外存 I/O 和堆空间，而不是只说“用哈希表”。

Q7：春节红包压测或长连接服务，应该关注哪些指标？ ​

回答思路： 先按链路拆分：入口 QPS、并发连接、成功率、P50/P95/P99 延迟、超时和错误码；再看业务指标如发放成功、重复消费、库存/余额一致性和消息积压。资源侧关注 CPU、内存、GC、连接池、线程/协程、网络、数据库锁等待、缓存命中率和队列长度。压测应逐步升压并记录容量拐点，设计限流、降级、幂等和故障恢复验证。

易踩坑 / 追问： 只报平均延迟会掩盖尾延迟；只压接口不验证业务正确性也没有意义。长连接场景还要关注断线重连、慢客户端、发送缓冲和单租户资源上限。

本期高频考点与复习建议 ​

  • Agent：Harness 与 Prompt 边界、工具 Schema、权限、安全执行、上下文裁剪、循环检测、预算和 checkpoint。
  • AI 评测：准确率/召回率的分母、人工标注、未见样本、badcase 回流、执行成功率和成本延迟。
  • 数据库：B+Tree、覆盖索引、回表、MVCC、执行计划、海量数据 TopK。
  • 服务端：压测指标、幂等、限流、队列积压、长连接背压与资源池隔离。

建议准备一张“模型—Harness—工具—状态—验证器”的时序图，并给每个环节标出失败恢复方式。这样既能回答 Agent 项目，也能自然衔接后端可靠性问题。