牛客面经精选

Appearance

面经精选 2026-10-14 ​

收录概览 ​

本期检索 AI/Agent、Golang 后端、服务端/后台开发关键词，按“近期开帖、正文可获取、与目标岗位相关、近 7 日不重复”筛选。今天收录 2 篇可核验的公开面经，重点集中在 Agent 运行时、记忆、工具可靠性、MySQL/Redis、SSE 与高并发资源调度。未将仅有标题或正文为空的帖子扩写成面经。

说明：以下是对公开技术问题的结构化改写，不代表整理者亲历；个人经历、身份信息和原帖长段落未复制。回答中的工程展开属于通用复习思路，不能当作原帖作者的事实经历。

一、Agent 运行时与工作流 ​

Q1：一次 AI 工作流从需求到上线，应该怎样讲清楚？ ​

回答思路： 先说业务目标和成功标准，再按“需求输入 → 状态初始化 → 意图/任务拆解 → 模型决策 → 工具执行 → 结果验证 → 状态持久化 → 输出/人工接管”描述完整链路。最后明确个人负责的模块、接口、实验和未解决问题，区分框架已有能力与自己的扩展。若没有线上指标，不编造数字，可以说明评测口径：任务完成率、工具参数正确率、人工接管率、P95 延迟、Token 成本和 badcase 率。

易踩坑 / 追问：

  • 只说“用了 Agent 框架”而说不出状态、工具契约、失败恢复和观测边界。
  • 把团队结果都归为个人；应按模块、设计决策、提交边界和实验说明贡献。
  • 流程固定、规则明确或副作用很高时，不要为了追热点使用 Agent，工作流/状态机通常更可控。

Q2：SSE、WebSocket 和普通 HTTP 如何选？ ​

回答思路： HTTP 是请求/响应协议语义；SSE 是基于 HTTP 的服务端到客户端单向事件流，客户端通过 EventSource 建立长连接，适合模型流式输出、进度通知等场景，接入简单且可利用 HTTP 基础设施。WebSocket 在握手后提供双向长连接，适合实时协作、双向控制和高频交互，但连接管理、鉴权、心跳、扩缩容和代理支持需要额外设计。选择要看通信方向、消息频率、断线重连、基础设施和运维成本，不是简单比较“谁更快”。

追问： SSE 断线怎么办？答：事件带 id，客户端携带 Last-Event-ID 重连，服务端从 checkpoint 或事件日志补发；事件处理要幂等，最终以服务端完整状态为准。高并发时还要限制连接数、发送缓冲和单用户资源，避免慢客户端拖垮 worker。

Q3：Agent 编排范式、Multi-Agent 与 Sub-Agent 有什么区别？ ​

回答思路： Workflow 适合路径固定、可审计的任务；ReAct 适合边观察边选择工具的开放任务；Plan-and-Execute 先生成计划再执行；Replan 允许失败或新信息出现后重新规划。Multi-Agent 是多个具有相对独立角色或能力的 Agent 协作，重点是角色边界、通信协议、共享状态和冲突解决；Sub-Agent 更像主 Agent 按需委派的受控子任务，生命周期和权限通常由父任务管理。是否拆分应比较上下文隔离、并行收益、调度复杂度、成本和故障面，不能只看概念名称。

易踩坑 / 追问： 拆成多个 Agent 不会自动提升质量；需要定义输入输出 Schema、超时、取消、重试、预算、权限和结果验证。没有独立上下文或并行收益时，单一工作流更容易调试。

二、记忆、上下文与长任务 ​

Q4：长期记忆如何存储、检索和加载？一定要用向量库吗？ ​

回答思路： 先区分 Context、State、Memory：Context 是本次送入模型的材料；State 是当前任务的可变运行状态；Memory 是跨轮/跨会话复用的信息。短期状态适合关系库或 KV 持久化 checkpoint；长期记忆可按类型存储用户偏好、稳定事实、任务摘要和原始证据，检索时结合租户/用户权限、时间、新鲜度和关键词/向量召回。向量库适合语义相似检索，但不是所有记忆都要向量化；精确事实、权限和状态更适合结构化存储。

追问： 超长上下文模型是否会替代 RAG 和长短期记忆？答：更大的窗口降低了部分压缩压力，但不能解决数据新鲜度、权限过滤、成本、可解释引用和跨会话持久化。长上下文与 RAG 是互补关系：RAG 控制取数范围和更新，记忆负责生命周期，Context 负责当前推理预算。

Q5：长周期 Agent 出现“行为漂移”，如何检测和纠正？ ​

回答思路： 为任务保存版本化状态、目标、约束、工具回执和 checkpoint；每个阶段设置不变量和验收条件，记录工具选择、参数、结果、重试、Token、延迟及状态变化。用进展指纹检测重复动作，用预算、Deadline、最大步数和错误上限止损。发现目标偏离时，回读原始约束与证据，暂停高风险工具，重新规划或转人工，而不是继续堆上下文。

易踩坑： 只设置最大步数不能发现“每一步都成功但整体没有进展”；也不能把模型自评当质量指标，应使用回放集、规则校验、人工抽样和故障注入评测。

三、后端基础与可靠性 ​

Q6：如何保证数据库与缓存一致？Redis 过期删除怎么答？ ​

回答思路： 先明确业务允许的最终一致窗口。常见写路径是更新数据库成功后删除缓存，必要时延迟再删；读路径遇到 miss 回源并回填，热点 key 用 singleflight/互斥、随机 TTL 和限流防击穿，空值短 TTL 防穿透。Redis 过期通常由惰性删除和定期删除共同完成，不能简单说“到时间立刻删除”；对强一致或关键库存仍以数据库/事务状态为准，缓存只做加速。

追问： 删除缓存失败怎么办？答：记录可靠事件或重试任务，监控失败并允许补偿；超时重试写操作前必须确认下游是否已生效，并使用幂等键，不能无脑重放副作用。

Q7：SSE/Agent 服务如何面对高并发？ ​

回答思路： 先区分连接并发、请求吞吐和模型/工具并发，不把连接数直接当 QPS。入口做鉴权、限流和租户配额；任务提交与长连接输出解耦，用队列或事件总线传递进度，状态写入可恢复存储；模型、沙箱、数据库连接池分别设并发上限，使用超时、取消、背压和熔断。多机部署时需要事件路由或共享事件存储，重连靠事件 ID/checkpoint 恢复；监控连接数、活跃任务、P95/P99、重试率、队列长度、Token 成本和资源池利用率。

易踩坑 / 追问： 1000 个沙箱不能只靠启动 1000 个进程解决；应按资源规格做池化和调度，设置租约、隔离、空闲回收、优先级、最大执行时长和失败清理。服务重启后恢复的是持久化状态和事件，不是依赖进程内变量。

高频考点与复习清单 ​

  • Agent：Harness、状态机、编排范式、工具 Schema、权限、幂等、checkpoint、防死循环。
  • AI 后端：短期状态/长期记忆、RAG 与长上下文、评测回放、行为漂移检测。
  • 服务端：SSE 与 WebSocket、断线续传、背压、连接并发、资源池和多租户隔离。
  • 基础：MySQL B+树索引、联合索引与失效场景；Redis 持久化、过期、击穿/穿透/雪崩；LRU 与高并发扩展。

建议准备一张 Agent 请求时序图：模型只提出候选动作，运行时负责权限与 Schema 校验，工具执行后写回状态，验证器决定继续、重试、回滚或人工接管。这样比罗列框架名更能体现后端工程能力。