牛客面经精选

Appearance

面经精选 2026-10-21 ​

收录概览 ​

本期检索 AI/Agent、Golang 后端、服务端/后台开发方向，优先筛选 2026-10-21 发布且正文可获取、技术问题密度较高的公开面经；排除正文为空、与近 7 日已收录主题高度重复以及个人隐私和待遇信息。共收录 3 篇，以下只改写公开技术问题，不代表整理者亲历。

  • 快手 AI 全栈开发：Agent Harness、沙箱、Loop、ReAct、一站式交付平台、成本优化
  • 字节跳动后端开发：会议纪要 Agent、语音转录容错、节点重试、幻觉治理、知识库、海量 IP 统计
  • 佰聆数据 AI 应用开发：结构化输出、FastAPI、向量检索、BM25 与融合、Agent 交互、温度参数

来源索引 ​

说明：仅保留公开技术问题并做复习向改写，不复制原帖长段落、身份信息、薪资和情绪化表述。回答中的工程展开是通用思路，没有可靠指标时不虚构数字。

一、Agent Runtime 与应用架构 ​

Q1：Agent Harness 是什么？和普通 Agent 托管有什么区别？ ​

回答思路： 可以把 Harness 理解为包住模型和工具调用的运行时控制层：负责会话与任务状态、Prompt/模型路由、工具注册、权限、Loop、超时取消、重试、日志追踪和结果校验。普通托管往往只解决“调用一个 Agent 或模型”，Harness 更关注如何让一次任务可恢复、可观测、可审计，并把业务约束落到运行时，而不是全部写在提示词里。

设计时应明确 state、context 和 memory 的边界：state 保存当前任务步骤和结果，context 是本轮送入模型的材料，memory 才是跨轮复用的结构化信息。工具调用前做 Schema、权限和风险检查，调用后校验结果；写操作使用幂等键或人工确认。框架提供的能力与自己补的适配层、策略层要分开说明。

易踩坑 / 追问： 不要把“用了 Agent 框架”直接说成自己实现了运行时；继续追问时应能讲清取消、checkpoint、预算、失败恢复和审计。

Q2：Agent Loop 如何避免无限循环？节点重试多次仍失败怎么办？ ​

回答思路： Loop 每轮都应读取任务状态、选择下一步、调用工具、写回观察结果并验证是否收敛。退出条件不能只有最大轮数，还应包含 Deadline、Token/费用预算、连续失败次数、重复工具参数、状态无进展、用户取消和安全策略拒绝。相同错误重复出现时，要记录错误类型和上下文，避免模型盲目重试。

节点失败后先按错误分类：临时网络错误可以指数退避并限次重试；参数错误需要修正输入或回退；权限和业务拒绝不能重试；下游超时要查询幂等状态，不能假设一定没执行。超过重试上限后可切换降级路径、交给人工、生成待处理任务或明确失败原因，并保留 trace、checkpoint 和证据。

易踩坑 / 追问： “加一个最大重试次数”不等于故障治理；副作用操作要说明幂等、补偿和人工接管。

Q3：怎样设计会议纪要 Agent？语音转录错误、模型幻觉怎么处理？ ​

回答思路： 可以拆成音频接入与转录、说话人/时间戳整理、主题和行动项抽取、结构化校验、引用回溯和发布几个节点。输出至少包含摘要、决策、待办、负责人、截止时间和原文时间戳；关键结论应能定位到转录片段。节点之间传递版本化结构，而不是把一大段自然语言继续传下去。

转录错误要通过音频质量检测、分段重试、词表/专有名词纠正、低置信片段标记和人工复核处理；不能让下游把低置信文本当确定事实。幻觉治理依靠约束输出 Schema、要求证据引用、对关键字段做规则校验、检索原文复核和无证据时拒答。模型能力不足时可降级为“待确认”，而不是生成看似完整的结论。

易踩坑 / 追问： 仅说“换更强模型”没有回答 Agent 角度的问题；还要讲失败节点、数据质量、证据链和人工闭环。

二、RAG、检索与结构化输出 ​

Q4：BM25 和向量检索有什么区别？如何做融合？ ​

回答思路： BM25 依赖词项匹配和统计特征，适合错误码、专有名词、项目名等精确关键词；向量检索根据语义相似度，适合表达不同但含义接近的问题。两者的分数通常不在同一尺度，不能简单相加。工程上可并行召回，再用归一化或 RRF 等排名融合，之后去重、重排并按上下文预算截断。

融合比例不是固定答案，应通过带标注的问题集验证：按问题类型、领域词密度、文档规模和召回质量分桶比较 Recall@K、MRR/nDCG、引用准确率和端到端答案质量。还要保留标题、版本、权限和原文位置等元数据，查询时先做服务端权限过滤。

易踩坑 / 追问： KNN、HNSW 是向量近邻检索的算法/索引路径，不是和 BM25 完全同层的概念；“用了向量库”也不等于检索效果好。

Q5：如何处理模型输出的 JSON，避免结构化结果直接失控？ ​

回答思路： 先定义版本化 Schema，明确字段类型、必填项、枚举、长度、嵌套结构和业务约束。模型侧使用结构化输出或工具调用；服务端仍要做 JSON 解析、Schema 校验、白名单过滤和业务状态校验，不能因为模型声称成功就直接写库或驱动 UI。

校验失败时可以有限次数修复重试，仍失败则降级为文本或人工处理，并记录原始输出、错误位置和模型版本。涉及写操作时，后端重新鉴权、检查幂等键和资源版本；日志中注意脱敏。评测应覆盖缺字段、类型错误、越权字段、重复事件和半截流式 JSON。

易踩坑 / 追问： Prompt 中要求“只输出 JSON”不是安全边界；安全和一致性校验必须在模型外部完成。

Q6：模型温度参数在底层做了什么？ ​

回答思路： 语言模型会先产生 logits，再通过 softmax 转成 token 概率。温度通常对 logits 做缩放：温度较低时分布更尖锐，倾向选择高概率 token；温度较高时分布更平坦，随机性增加。它影响采样分布，不会凭空增加模型知识，也不能替代事实校验。

确定性结构化任务通常使用较低温度并配合 Schema、约束解码和重试；创意生成可以适当提高，但仍需限制长度、停止条件和安全规则。不同服务对 temperature、top-p 等参数的实现和可用范围可能不同，面试时应说明以实际模型 API 为准，并用固定数据集验证变化。

易踩坑 / 追问： 不要把温度解释成“模型思考深度”；温度调低也不能根治幻觉。

三、Golang 与服务端题 ​

Q7：高并发下如何统计访问次数最多的前十个 IP？ ​

回答思路： 先明确统计窗口、精确性、数据来源和是否允许近似。单机离线批处理可以用 HashMap 计数，再维护大小为 10 的小根堆，扫描后得到 Top 10；在线多实例场景要按 IP 做分片或使用 Redis/流式计算聚合，并处理热点 IP、过期窗口和重复请求。

数百万访问不能默认把所有记录无限堆在内存里。可按时间窗口分桶，使用 bounded queue、批量聚合和有界内存；如果业务允许近似，可评估 Count-Min Sketch 等结构，再用候选集校准。输出前要说明一致性、延迟、丢失和故障恢复口径，不能只回答一个排序算法。

易踩坑 / 追问： “用 Map 统计”没有覆盖多实例、窗口、内存上限和热点；若 IP 来自代理头，还要说明可信代理边界，不能无条件信任用户传入的头部。

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

  • Agent Runtime：Harness、Loop、重试分类、预算、checkpoint、幂等和人工接管。
  • AI 应用：会议纪要链路、转录质量、证据回溯、结构化输出和幻觉治理。
  • RAG：BM25/向量检索、归一化与 RRF、权限过滤、版本元数据和评测集。
  • Golang/服务端：高并发计数、Top-K、窗口聚合、有界内存和多实例一致性。

准备时建议画三张图：一张是 Harness 的 state—model—tool—validator 执行图；一张是音频—转录—抽取—证据—人工复核链路；一张是日志/IP—分片—窗口聚合—Top-K 输出图。每道项目题都补上失败分类、验证方式和安全边界。