牛客面经精选

Appearance

面经精选 2026-10-22 ​

收录概览 ​

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

  • 字节 AI 应用开发：Agent 架构、Plan-Execute 与 ReAct、结构化输出、失败案例、本地部署、RAG、TCP/进程线程
  • Agent 开发工程师校招：原型拆解、AI 辅助开发、代码审查、前端交互意识
  • 汽车之家 Java 后端二面：延迟队列、幂等、MySQL MVCC、SSE、Function Calling、AI Coding 安全

来源索引 ​

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

一、Agent 架构与应用开发 ​

Q1：为什么选择 Plan-Execute，而不是 ReAct？ ​

回答思路： ReAct 是观察、推理、行动交替进行，适合信息不完整且需要根据工具结果即时调整的任务；Plan-Execute 先形成计划，再按步骤执行，适合步骤依赖明确、需要控制流程的任务。工程上还可以加入 Replan：前置条件变化、工具结果偏离或计划不可执行时重新规划。

选择不能只看框架流行度，要结合任务不确定性、步骤数量、可恢复性和审计要求。固定主流程可用状态机约束，模型只负责有限决策；每个节点保存输入、输出、错误、重试和 checkpoint，避免把整段自然语言当作唯一状态。

易踩坑 / 追问： 不要说 Plan-Execute 一定比 ReAct 好。继续追问时要说明最大步数、Deadline、费用预算、重复动作检测和写操作幂等。

Q2：Agent 的结构化输入输出怎么保证可靠？ ​

回答思路： 先定义版本化 Schema，明确字段类型、枚举、必填项、长度和业务约束；模型侧使用结构化输出或 Function Calling，服务端仍要做解析、Schema 校验、白名单过滤和业务状态校验。涉及写库或执行工具时，还要重新鉴权、检查资源版本和幂等键。

失败处理要分类：格式错误可有限次修复，参数缺失应回到澄清或规划节点，权限拒绝不能盲目重试，下游超时要查询幂等状态。最终无法校验时降级为待确认或人工处理，并记录原始输出、错误位置和模型版本。

易踩坑 / 追问： Prompt 里写“只输出 JSON”不是安全边界；结构化只是协议，不能代替业务校验和权限控制。

Q3：本地部署模型时，显存和性能如何分析？ ​

回答思路： 先区分权重、KV Cache、激活和运行时开销。权重显存受参数量和量化精度影响；长上下文、高并发和输出长度会显著增加 KV Cache。实际评估还要看 batch、并发、上下文窗口、量化方案、算子实现和显存碎片，不能只按参数量粗略估算。

部署前用固定问题集压测首 Token 延迟、生成吞吐、p95 延迟、显存峰值和错误率；根据结果选择量化、分页 KV Cache、限流、动态 batching 或模型路由。模型能力不足时不能只靠调参，应保留规则校验、检索证据和人工兜底。

易踩坑 / 追问： “本地部署更安全”不是完整理由，还要说明数据边界、更新成本、运维能力和质量回归。

二、AI Coding 与产品交付 ​

Q4：拿到高保真 HTML 原型，如何拆解成可开发需求？ ​

回答思路： 先从页面结构、用户角色、入口和核心任务梳理功能地图，再把静态区域拆成组件、状态和交互：加载、空态、错误、权限不足、提交中、成功和回滚。随后确认接口、字段、校验、分页、埋点、响应式和浏览器兼容性，并把不明确的业务规则列成问题清单。

开发前产出页面—接口—状态的映射、验收标准和边界场景；联调时用真实接口或契约 Mock 验证，而不是只保证页面“看起来像”。AI 可以辅助生成组件和测试，但需求判断、风险确认、代码审查和最终验收仍由工程师负责。

易踩坑 / 追问： 不要把原型当成完整需求；还要追问权限、异常反馈、操作成本、键盘/移动端体验和接口失败时用户怎么办。

Q5：多 Agent 如何通信？开子任务用多线程还是多进程？ ​

回答思路： Agent 间通信应尽量使用明确的任务 Schema，包含任务 ID、输入约束、状态、结果、错误和证据引用；简单场景可用进程内调用，异步场景使用队列或事件并持久化状态。不要只传一大段自然语言，否则难以校验、重试和恢复。

多线程适合共享地址空间、通信频繁且任务主要受 I/O 影响的场景，但要处理锁、竞态和故障隔离；多进程隔离性更强，适合 CPU 密集、不同运行时或不可信代码，但 IPC 成本更高。Agent 执行代码还要配合沙箱、资源限额、超时、取消和审计。

易踩坑 / 追问： 线程/进程不是二选一的架构答案；应结合 CPU/I/O、隔离性、数据共享、部署和故障恢复说明。

三、后端基础与流式 Agent ​

Q6：如何实现可靠的延迟任务？重复执行怎么办？ ​

回答思路： 任务数据先持久化并记录状态，Redis ZSet 可按执行时间维护待到期任务，到期后进入消费队列；消费者执行前要抢占或条件更新状态，执行结果和失败原因回写数据库。扫描、投递、消费、补偿都可能重复，因此系统应按“至少一次”设计。

幂等不能只靠分布式锁：状态流转使用条件更新，业务唯一约束防重复写入，副作用操作使用幂等键；下游超时要查询结果，不能直接重试造成二次执行。还要有重试上限、死信/人工处理、监控和优雅停机策略。

易踩坑 / 追问： Redis 只负责调度并不等于任务可靠；必须说明数据库持久化、补偿和故障恢复。

Q7：SSE 和 WebSocket 怎么选？Function Calling 如何落地？ ​

回答思路： SSE 基于 HTTP，适合大模型生成时服务端持续向客户端推送文本，接入简单且天然适配单向流；WebSocket 支持双向通信，适合协作、实时控制和高频交互。选择要看通信方向、连接生命周期、代理兼容性、重连和消息补偿，不是简单比较谁更先进。

Function Calling 的链路是：模型根据工具定义生成结构化调用请求，Runtime 校验工具名和参数，服务端鉴权后执行，再把结果以结构化消息回传模型。工具必须白名单化，设置超时、权限、幂等和审计；模型不能直接拼任意命令。

易踩坑 / 追问： 流式输出也要处理断线、重复片段和取消；工具返回成功不代表业务成功，仍需校验结果。

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

  • Agent：Plan-Execute/ReAct、结构化输出、失败分类、模型部署与 Function Calling。
  • AI 应用交付：原型拆解、AI Coding 的验证边界、多 Agent 通信和沙箱隔离。
  • 服务端：延迟队列、至少一次消费、幂等、补偿、SSE/WebSocket。
  • 基础：TCP 通信流程、进程线程、并发模型、RAG 证据链。

准备项目题时，建议画三张图：Agent 的 state—plan—tool—validator 图；原型到组件—接口—状态—验收的交付图；延迟任务的持久化—调度—消费—补偿图。每道题都补上失败处理、验证方式和安全边界。