牛客面经精选

Appearance

面经精选 2026-10-17 ​

收录概览 ​

本期检索 AI/Agent、Golang 后端、服务端/后台开发方向，优先收录 2026-10-17 前后发布且能获取正文的公开面经；排除纯 HR 面、正文不足和近 7 日已收录的重复内容。共收录 5 篇，覆盖 Agent 运行时、多 Agent 编排、MCP/Skill、Coding Agent 质量保障、SSE、知识图谱、MySQL 事务与服务端基础。以下为公开技术问题的结构化改写，不代表整理者亲历。

  • 网易 Agent 开发岗一面：Agent 架构、范式、记忆、MCP、RAG、多 Agent 与部署
  • 网易互娱 AI 应用开发：Coding Agent、MCP/Skill、限流并发、自动修复与 MR 审查
  • 字节全栈二面：SSE、知识图谱底层、事务隔离、联合索引、Agent/Skill 边界
  • 腾讯后端开发岗：长连接、负载均衡、服务发现、RPC、线程池、消息队列与手撕
  • 优博讯软件开发：TCP/UDP、HTTP/HTTPS、负载均衡、Agent 应用与 GitHub 项目

来源索引 ​

说明：只保留公开技术问题和可迁移的工程考点，不复制个人隐私或原帖长段落。回答中的工程展开是通用复习思路；没有可靠指标时不虚构数字。

一、Agent 架构、运行时与可靠性 ​

Q1：Agent 的核心架构和 Agentic Loop 怎么讲？ ​

回答思路： 先从请求入口讲起：身份、租户、输入和风险校验后，加载系统约束、任务状态、短期上下文及经过权限过滤的长期记忆；路由器再判断直接回答、RAG 检索还是工具调用。运行时循环通常包含感知、规划、行动、记忆写回和结果验证，工具调用必须经过参数 Schema、权限与副作用检查，结果写入事件或 checkpoint，直到完成、超时、预算耗尽或转人工。最后输出要做格式和敏感信息校验，并记录 trace、模型版本、工具结果和证据。

易踩坑 / 追问： Agentic Loop 不是“不断调用模型”。要区分 state、context、memory 的生命周期；死循环防护至少包括最大步数、Deadline、Token/费用预算、错误上限、工具深度、重复参数指纹和“状态是否有进展”检查。进程重启后还要能从 checkpoint 恢复，不能只依赖内存计数。

Q2：ReAct、Plan-and-Execute、Workflow 怎么选？ ​

回答思路： ReAct 适合步骤不确定、需要边观察边决策的探索型任务，但可控性和成本较难保证；Plan-and-Execute 先生成计划再执行，适合中长流程，但要处理计划过时和局部失败；固定 Workflow 适合研发发布、支付、审批等边界明确的场景，便于审计、回放和稳定验收。实际系统可采用“主流程固定 + 节点内部有限自主决策”的混合方式，把高风险动作交给确定性代码和人工确认。

易踩坑 / 追问： 不能把“更自主”直接等同于“更好”。比较时说明任务不确定性、失败代价、延迟、可观测性和人工接管；不要把多 Agent 当作并行的唯一理由，单 Agent + 多 Skill 也可能并行。

Q3：MCP、Function Calling 和 Skill 如何区分？ ​

回答思路： Function Calling 是模型与应用之间约定结构化函数参数的调用机制；MCP 更像对资源、工具和提示能力进行标准化暴露的协议层，可通过不同传输方式连接外部服务；Skill 则偏向可复用的方法、流程和约束。设计时给每个工具补充清晰 description、输入输出 Schema、前置条件、权限、副作用、超时、重试语义和错误码。工具太多时先按领域、权限和风险召回少量候选，再做 Schema 和权限过滤，不要把全部描述塞入上下文。

易踩坑 / 追问： 名称相似不代表可调用；工具调用失败时区分参数错误、权限错误、限流、暂时性网络错误和业务失败，只有幂等且明确可重试的错误才能自动重试。高风险动作必须服务端重新鉴权、审计和幂等。

二、Coding Agent 与 AI 质量保障 ​

Q4：怎样设计“线上报错—AI 分析—修复—提交 MR”的闭环？ ​

回答思路： 入口层接收监控、日志、Trace 和工单事件，做去重、脱敏、租户隔离和关联；分析层检索代码、历史修复和运行上下文，分类根因并生成带证据的候选方案；执行层在隔离分支或沙箱中修改，运行格式化、静态检查、单元/集成测试和回归测试；交付层生成小范围 MR，附变更摘要、风险、测试证据和回滚方案，最终由人工审批合并。全链路保留事件 ID、版本、模型、工具调用和状态，支持取消、重试、回滚和人工接管。

易踩坑 / 追问： “AI 说测试全绿”不等于可以上线。要检查测试是否覆盖真实失败路径、是否存在只改测试迎合结果、依赖和配置是否变化、权限与数据迁移是否安全；大批量代码应先按风险、依赖和变更范围分层审查，优先看入口、数据写入、鉴权、并发、错误处理和外部副作用。

Q5：如何评估 Agent 稳定性以及自动化测试是否充分？ ​

回答思路： 先建立代表性任务集和明确验收标准，分别评估任务成功率、工具调用正确率、事实/引用准确性、重试率、成本、延迟、人工接管率和跨次结果一致性。对 Coding Agent，加入编译、静态检查、单元测试、集成测试、契约测试、回归样例、变更覆盖和线上灰度；对 UI 操作，还要覆盖状态断言、异常路径、权限、断线重连和数据清理。将失败样本分类为需求理解、检索、规划、参数、执行和验证错误，回流评测集。

易踩坑 / 追问： 不能用一次成功证明稳定，也不能只看平均延迟或测试数量。规则写在 CLAUDE.md 等文件中后，要用 lint、CI 检查、定期仓库扫描和架构约束测试验证是否真正遵守，并监测重复代码、依赖漂移、复杂度、缺陷和技术债务趋势。

三、服务端基础与数据系统 ​

Q6：SSE 和 WebSocket 怎么比较？ ​

回答思路： SSE 基于 HTTP，服务端到客户端单向推送，浏览器有 EventSource 和自动重连语义，适合 Agent 事件流、日志和通知；WebSocket 升级后提供双向长连接，适合实时协同、游戏和双向交互。SSE 还要说明 text/event-stream、事件 ID、重连、心跳、代理缓冲、断线补发和慢客户端处理；两者都需要连接数、超时、背压、鉴权、限流和优雅关闭设计。

易踩坑 / 追问： “单向/双向”不是全部区别；要说明协议、浏览器 API、代理兼容、广播模型和运维成本。流式 JSON 不能假设每个网络包都是完整对象，应使用序号、缓冲解析、幂等合并和最终快照。

Q7：MySQL 的 RC、RR 和联合索引怎么串起来讲？ ​

回答思路： 事务隔离级别需要从脏读、不可重复读和幻读的差异讲起，再说明 RC 通常在每次一致性读形成新的 Read View，而 RR 在事务范围内复用快照；当前读、锁和具体数据库实现要单独说明。联合索引要从真实查询条件、选择性、排序与覆盖需求出发，例如订单号和购买者 ID 的组合能服务对应的等值查询，但最终要用执行计划验证是否减少扫描和回表。

易踩坑 / 追问： 索引不是越多越好，会增加写放大；不能只说“用了索引所以快”，还要看扫描行数、回表、排序、锁等待和数据分布。面试官若追问订单量，应明确事实数据与设计假设，不能临场编数字。

Q8：服务发现、负载均衡和 RPC 怎样答？ ​

回答思路： 服务发现包括实例注册、健康检查、订阅/拉取、变更传播、过期剔除和多副本高可用；负载均衡可按轮询、加权、最少连接或一致性哈希选择实例，同时配合超时、熔断、限流、重试和连接池。RPC 设计则要覆盖协议与序列化、超时取消、错误码、连接复用、负载均衡、幂等、重试、认证、观测和版本兼容。

易踩坑 / 追问： 重试可能放大流量和重复副作用，必须区分连接失败、超时和服务端已执行但响应丢失；消息队列和线程池还要讲容量、背压、消费确认、重复消费、死信和优雅停机。

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

  • Agent：Loop、Workflow 与自主决策、MCP/Skill、工具 Schema、记忆、评测与人工接管。
  • Coding Agent：沙箱、MR、测试证据、代码审查重点、规则执行和技术债务治理。
  • 服务端：SSE/WebSocket、服务发现、负载均衡、RPC、限流重试和消息可靠性。
  • 数据库：RC/RR、Read View、联合索引、执行计划与回表。

复习时准备一张“请求—状态—模型—工具—验证器—人工审批”的时序图，再准备一个服务端故障闭环：超时、重试、幂等、背压、恢复和对账都能说清。所有项目指标都说明口径、基线、改动和验证方式；没有真实数据就明确评测计划。