牛客面经精选

Appearance

面经精选 2026-10-26 ​

收录概览 ​

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

  • 长鑫存储 AI Agent 开发：单/多智能体、长短期记忆、ReAct 失败与改进、MCP/Skill、Harness、Redis 分布式、RAG 改写与召回优化
  • CVTE 应用开发：LangGraph 节点编排、主图/子图传参、准确率提升、Redis 持久化与异常恢复、适配器/策略模式、线程池
  • 科大讯飞：缓存一致性、ThreadLocal、Agent 路由与 Graph、跨请求状态/撤销、上下文压缩、AI Coding 质量控制
  • 作业帮 Golang：Agent Loop/重试、权限沙箱、跨会话记忆、MySQL→PostgreSQL 在线迁移、Redis ZSet、优惠策略高并发设计

来源索引 ​

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

一、Agent 架构、记忆与协议 ​

Q1：单智能体和多智能体怎么选？记忆怎么分层？ ​

回答思路： 单智能体由一个决策中枢理解意图、调度工具并生成回复，工具只是能力单元；架构简单、延迟低、易调试，但复杂任务可能超出单一模型边界。多智能体按规划、执行、校验等角色拆分协作，扩展性强，但有通信、协调和状态一致性成本。流程固定、边界清晰时优先单智能体加工作流；任务异构、需并行或强隔离时再引入多智能体。

记忆通常分三层：短期记忆放会话上下文，支撑多轮理解；长期记忆把历史对话和偏好切片 embedding 后入库，按需检索；必要时加工作记忆或任务状态，记录当前目标、工具结果和 checkpoint。短期记忆本质是 In-Context Learning，超窗要截断或压缩；长期记忆核心是检索质量，写入时机、冲突合并和权限隔离都要单独设计。

易踩坑 / 追问： 不要把“多个工具”说成多智能体。继续追问决策权归属、失败回滚、跨 Agent 的 Schema 和审计链路。

Q2：ReAct 有哪些典型问题？常见改进是什么？ ​

回答思路： ReAct 把推理和行动交织，适合需要外部信息反馈的任务，但也容易出现：Thought/Action 格式不稳、复杂任务迭代过长、局部死循环、工具选错/参数填错、上下文膨胀。工程上要加结构化输出约束、最大步数与费用预算、重复动作指纹检测、工具白名单和参数预校验、阶段性复盘或目标锚定。

常见改进包括：Reflexion（失败后写反思再重试）、Plan-and-Execute（先全局规划再执行）、ReWOO（推理与工具调用解耦减 LLM 调用）、目标差距反思等。选择不是追新框架，而是看任务不确定性、可审计性和恢复成本。

易踩坑 / 追问： 不要只背缩写。继续说明“工具调用成功但状态无推进”是否算死循环，以及写操作如何幂等。

Q3：MCP 和 Skill 分别解决什么？调用失败怎么办？ ​

回答思路： MCP 是模型连接外部工具/数据源的标准协议，强调 Host/Client/Server 分层和 Tools、Resources、Prompts 等基元，目标是一次实现、多客户端复用。Skill 更偏能力单元定义：任务描述、输入参数、执行逻辑、输出约束；Function Calling 是执行动作。可以把 Skill 看成“可复用能力包”，MCP 看成“标准化接入层”。

调用失败要分类：超时、鉴权失败、参数非法、下游业务失败、结果不可信。超时可有限重试并查询幂等结果；鉴权失败不能盲重试；参数非法回澄清或修复；业务失败走降级、替代工具或人工确认。所有调用写审计：工具名、参数摘要、耗时、错误码、trace id。

易踩坑 / 追问： MCP 不等于万能插件市场；还要讲权限边界、沙箱、版本兼容和失败后的用户可感知反馈。

二、LangGraph 编排、准确率与持久化 ​

Q4：LangGraph 节点输入输出怎么设计？主图和子图如何传参？ ​

回答思路： 先定义版本化状态 Schema：任务 ID、输入、中间产物、错误、重试次数、checkpoint。每个节点声明可读字段、可写字段和副作用；节点间不靠“整段自然语言私传”，而靠结构化状态更新。主图负责路由和全局约束，子图负责局部子任务；跨图传递要用明确契约，返回结果、证据和失败原因，避免隐式全局变量。

异常恢复不能只靠 Redis 存一份状态：要有可恢复 checkpoint、节点级超时、可重入执行和幂等写。Redis 适合会话/短期状态和队列，长期任务状态、审计和最终结果仍应落库；节点失败时按策略重试、跳过、回退或转人工，并及时给用户可理解反馈。

易踩坑 / 追问： “用了 LangGraph”不是答案。继续追问状态字段、并发写冲突、子图取消和部分成功怎么处理。

Q5：如何提高数据处理 Agent 的准确率？怎么评估？ ​

回答思路： 准确率通常来自链路多处约束：输入校验与归一化、Schema/适配器统一格式、工具参数预检、关键步骤规则校验、抽样人工复核、失败样本回流。适配器模式适合把多源异构数据转成统一内部模型；策略模式适合按数据类型或业务线切换处理算法，两者关注点不同：一个管接口适配，一个管算法族切换。

评估要拆开：任务成功率、字段级正确率、工具调用正确率、重试率、耗时、Token 成本和人工介入率。离线用固定回归集；在线看失败原因分布和业务反馈。业务方只说“不准”时，先复现样本、分检索/解析/规则/模型/权限问题，再给修复和防回归方案。

易踩坑 / 追问： 不要只说“加 Prompt”。要说明哪一层约束生效，以及如何证明改进有效。

三、Agent 状态机、上下文与 AI Coding 质量 ​

Q6：Agent 跨请求长流程、状态流转和撤销怎么设计？ ​

回答思路： 把一次业务做成可持久化状态机：状态、版本、操作者、输入快照、输出快照、可撤销标记。跨请求靠 task_id/session_id 找回状态，而不是依赖模型“记住上次说了什么”。路由按类别进入不同流程时，先做分类置信度校验；低置信度澄清，高风险动作二次确认。Graph/工作流可以是配置或代码定义，但执行引擎必须保证按预期边转移，不允许模型随意跳边。

撤销不是简单 delete：要区分补偿、回滚和软删除；已产生外部副作用的步骤需要逆向操作或人工工单。状态数据可放 Redis 做热状态，权威状态和审计落库；并发更新用版本号或条件更新防止覆盖。

易踩坑 / 追问： “状态存在 Redis”不等于可恢复。继续问断电重启、部分节点成功、重复提交和权限变更后的行为。

Q7：上下文压缩怎么做？AI Coding 质量如何控制？ ​

回答思路： 压缩目标是降 Token 且尽量保留关键事实：任务目标、未完成约束、已确认决策、错误原因、关键文件路径和接口契约优先保留；可重建的大段日志、重复工具输出可摘要或外置引用。触发条件看窗口占用、轮次、工具噪声和费用预算；需要精确复现时再按引用拉全文，而不是永远只喂摘要。

AI Coding 要把需求拆成可验证任务：先对齐 PRD/接口/边界，再让模型改局部；核心逻辑、权限、资金链路自己把控。交付后用测试、静态检查、人工 Review 和对比需求验收；多人协作要沉淀可复用 Skill/组件和项目约束文档，避免每人一套隐式规则。

易踩坑 / 追问： 压缩丢了“不可重建约束”会直接导致错误修改；AI 生成通过编译不等于业务正确。

四、Golang / 服务端可靠性 ​

Q8：Agent 权限沙箱和失败重试怎么做？ ​

回答思路： 权限应分层且由程序强制：路径沙箱、工具白名单、参数校验、危险操作确认、会话级权限模式。规则不要只写进 Prompt；Prompt 是软约束，Runtime 是硬边界。命中拒绝应立即终止该动作并记录原因，而不是继续让模型“再试一次危险操作”。

失败恢复先分类：网络抖动可重试，权限/参数错误不应重试，业务冲突要查现状再决定。保存失败步骤、输入、部分结果和 checkpoint，便于续跑；重试要有上限、退避和幂等键。跨会话记忆写入要定义时机和冲突策略，旧记忆不能被低质量新结论静默覆盖。

易踩坑 / 追问： “五层权限”要能说出优先级和短路逻辑；模型说“已删除”不等于文件系统真的安全执行。

Q9：MySQL 迁 PostgreSQL 如何在线切换？缓存一致性怎么做？ ​

回答思路： 在线迁移通常分阶段：双写或旁路同步、存量迁移、校验、读切换、写切换、清理。关键是标记数据迁移进度、兼容新旧查询、按请求路由，并准备回滚。历史查询要能判断数据在新库、旧库还是迁移中；一致性校验用抽样对账和行级校验，而不是只看条数。

缓存与真实结果不一致时，按场景选同步：对延迟敏感且变更可追踪的可用 binlog/CDC；需要业务语义编排、削峰或多下游时用 MQ。预计算+Redis 的瓶颈常在失效风暴、穿透、预热和一致性窗口；要有版本号、过期策略和回源保护。ThreadLocal 的 key 用弱引用是为了避免类加载器泄漏，但 value 仍可能泄漏，线程池场景要显式 remove。

易踩坑 / 追问： 不要把“双写”说成银弹；继续讲乱序、重复消费、回填旧值覆盖新值和灰度验证。

Q10：Redis ZSet 和优惠/库存类高并发怎么设计？ ​

回答思路： ZSet 常用跳表+哈希表实现成员到分值的高效访问；按 member 查 score 可到 O(1) 量级（实现细节依版本/编码），按分值范围查询依赖有序结构。热榜、延迟任务、排行场景要说明写入频率、淘汰和分页游标，不只背“用了 ZSet”。

优惠预算/库存高并发要区分浏览与下单流量：浏览可缓存和限流，下单走独立配额，避免统一限流误伤成交。Redis 扣减用原子脚本，权威账本仍落库；更新链路可用 MQ 异步和解耦，手动 ACK 保证处理成功后再确认。Redis 已更新、MySQL 未更新时，禁止用旧库盲目回填；要用版本、状态机或对账修复。

易踩坑 / 追问： 限流按用户不等于保护总容量；策略很多时不能把全量策略丢前端遍历。