百度 AI Agent 开发岗面经：LangGraph 架构与高并发会员保障

《面试题目》

面经 01（面试时间 2026 年 9 月 16 日）

1. 请介绍一个最熟悉的项目，并向不了解背景的人说明项目内容。
2. 项目的设计思路是什么，最初是如何想到这个方案的；追问：为什么使用 LangGraph？
3. LangGraph 较旧，是否考虑迁移到新的架构？
4. 迁移到不同架构时可能遇到哪些问题？
5. 如何保证 Agent 部署后能覆盖复杂业务场景？
6. Agent 流程中是否设置验证节点和人工复核？
7. 评测集的设计思路是什么？
8. Agent 平台开发解决了什么问题？
9. 业务问答 Agent 是否收到过异常反馈，如何处理？
10. Go 或 Python 开发中遇到过什么问题，如何解决？
11. 使用 AI 辅助开发时，如何确保实现正确？
12. 是否考虑使用审计模型？
13. 是否了解 Harness 等新的 AI 工程技术？
14. 高并发场景下如何优先保证会员用户的服务可用性？
15. 使用优先级队列后，如何避免非会员请求长期得不到处理？
16. MySQL 和 Redis 有什么区别？
17. Kafka 和 etcd 分别有什么特性，解决什么问题？
18. 请做一下自我介绍。

面经 02（面试时间 2026 年 9 月 15 日）

1. 是否使用过 Skill？
2. Agent 和 Skill 有什么区别？
3. 怎样编写一个高质量的 Skill？
4. 如果要编写一个能在机器上执行文件写入和删除操作的 Skill，应该如何设计？
5. 如何避免大模型幻觉导致误删其他文件；追问：还有哪些更可靠的安全手段？
6. MCP 和 API 有什么区别？
7. 请介绍 Transformer 处理用户输入的主要流程。
8. 是否了解 KV Cache，为什么只缓存 K、V 而不缓存 Q？
9. 请介绍 TCP 三次握手和四次挥手。
10. 一台机器出现大量 TIME_WAIT 的原因是什么，如何处理？
11. 多人使用面试助手平台时，如何保证平台稳定性？
12. 如何发现平台不可用或大量用户无法访问？
13. 告警策略应该如何配置，需要覆盖哪些指标？

面经 03（面试时间 2026 年 9 月 10 日）

1. 介绍实习工作的目标、问题背景、解决方案、系统架构、个人职责和最终效果。
2. 项目平台的定位和主要能力是什么？
3. 网关抓包功能如何保证安全性？
4. MCP 与 HTTP API 有什么区别？
5. Agent 如何发现和使用 MCP Server 提供的能力？
6. MCP 工具真正执行调用时会经历哪些步骤？
7. 设计 MCP Server 时，如何限制危险工具的调用？
8. 一个新工具从注册到被调用的完整链路是什么？
9. 从 MCP Client 和 Server 的角度看，一次调用会经历哪些过程？
10. JSON-RPC 是什么，为什么称为 RPC？
11. MCP Server 上线后会统计哪些指标，调用量大致如何衡量？
12. MCP 工具数量过多会带来什么问题？
13. MCP 和 Skill 是什么关系？
14. TCP 为什么需要三次握手，而不是两次或四次？
15. TCP 和 UDP 有什么区别，哪些上层协议使用 UDP？
16. HTTP/3 与 HTTP/1、HTTP/2 有什么区别？
17. 死锁的必要条件有哪些？
18. 算法：实现 LRU 缓存。
19. 算法：找出数组中出现次数超过一半的元素，要求时间复杂度 O(n)、空间复杂度 O(1)。
20. 算法：找出数组中出现次数超过三分之一的两个元素。

面经 04（面试时间 2026 年 9 月 8 日）

1. 如何理解 Harness？
2. 请做一下自我介绍。

原帖为连载合集，面经 04 的正文在牛客服务端即被截断，此处只保留已发布的部分。

《参考解析》

LangGraph 架构与迁移成本

LangGraph 的核心是「图 + 显式状态」：节点是函数、边是控制流，状态通过 reducer 合并，另外提供 checkpoint 持久化、human-in-the-loop（interrupt）和时间旅行回放。所谓「旧」通常不是指图模型过时，而是 API 迭代快、生态早期偏 Python。真要迁移，成本不在图怎么写，而在四件事：① checkpoint / 持久化的历史数据兼容，存量在跑的任务怎么恢复；② 人工复核（interrupt 后恢复）在新框架里的等价语义；③ 状态 schema 变更后的版本兼容；④ 可观测与评测数据的迁移。工程上的应对是把业务逻辑从框架里剥出来——工具层、状态定义、节点函数都写成不依赖框架的纯函数，框架只当编排层，这样换框架的成本从「重写项目」降到「换一层 adapter」。

评测集怎么设计

分层做：L1 单点能力（工具选择准确率、参数 schema 合法率、检索 Recall@k），L2 端到端任务成功率（人工标注 100300 条真实 case，按业务场景分层抽样），L3 回归集（线上每条 badcase 都进集并标 P0）。指标至少覆盖任务成功率、平均步数、工具调用错误率、事实性错误率、P95 延迟和单任务 token 成本。构建顺序是先从线上日志采真实请求、人工写期望结果，再用 LLM 生成候选、人工审核扩量——生成只管扩量，判定必须落到人工或可确定验证的断言上。用 LLM-as-judge 打分前要先在 50100 条上和人工标注算一致性，一致性不够分数就不可信。评测集必须能进 CI，改 prompt 或换模型后跑一遍，允许的回归阈值写死，否则「调好一个坏一个」永远发现不了。

高并发下保障会员可用性

分四层做，而不是只加一个优先级队列。① 分级限流：按资源 + 调用方维度配不同阈值（Sentinel 支持热点参数和来源限流），会员走独立阈值；② 资源隔离：给会员链路单独线程池 / 独立实例，非会员排队长度设上限并快速失败，避免被拖垮；③ 分级降级：会员保核心链路（面试实时链、音频通道），非会员先降非核心功能（推荐位、历史记录、报表）；④ 优先级调度要防饿死：纯优先级队列在高优先级持续到来时会让低优先级无限等待，正确做法是加权公平队列（WFQ / 赤字轮询 DRR）给小权重类保底配额，或给等待时间做老化（aging）——等待超过阈值就临时提级。观测量级要看 P99 而不是均值，并单独盯会员侧的可用性与排队时长。

Kafka 和 etcd 解决什么问题

Kafka 是分布式提交日志 + 消息队列：partition 内顺序追加、按 offset 消费，副本靠 ISR 同步，单机吞吐可以到几十万条每秒，消息默认保留若干天。它保证的是单 partition 内有序，不保证全局有序，适合解耦、削峰、异步化和流处理。etcd 是基于 Raft 的强一致 KV 存储，提供 MVCC + revision、watch、lease，写要过半节点确认，所以吞吐远低于 Kafka，数据量也小（官方建议控制在几 GB 内），定位是服务注册发现、配置中心、分布式锁和选主（Kubernetes 的 apiserver 后端就是它）。一句话：Kafka 是「流」，etcd 是「一致性小账本」，两者不可互换。

KV Cache 为什么只缓存 K、V

自注意力的输出是 softmax(QKᵀ/√d)·V。自回归生成第 t 个 token 时，Q 只有当前这一步产生（1 行），而 K、V 要用到包含历史的全部位置（t 行）。也就是说 Q 是一次性的、没有复用价值，缓存它只会白占显存；缓存 K、V 才能把历史位置的投影结果复用，把每步计算量从 O(t²·d) 降到 O(t·d)。显存占用约为 2 × 层数 × KV 头数 × head_dim × 序列长度 × batch × dtype 字节数，所以工程上用 MQA/GQA 减少 KV 头数、用 PagedAttention 分页管理碎片、用 INT8/INT4 量化 KV Cache 来压这块开销。

大量 TIME_WAIT 怎么看、怎么处理

TIME_WAIT 是主动关闭方在发出最后一个 ACK 后停留 2MSL 的状态（Linux 上固定 60 秒，net.ipv4.tcp_fin_timeout 对它无效），作用有两个：保证对方没收到 ACK 时能重传 FIN 并被我方正确处理，以及让本次连接的旧报文在网络中消散，避免污染复用同一四元组的新连接。大量 TIME_WAIT 说明本机是主动关闭方且短连接多。排查用 ss -s 看总量、ss -tan state time-wait 按对端地址聚合看是谁，再判断是压测短连接、爬虫还是上游没开 keep-alive。处理手段按优先级：① 上游改长连接 / 连接池（HTTP keep-alive、gRPC）；② 调整关闭方角色，短连接尽量让客户端主动关；③ net.ipv4.tcp_tw_reuse=1（出向连接、开启时间戳时可用，是安全的）；④ 扩大 ip_local_port_range，必要时调 tcp_max_tw_buckets（只是超额直接销毁并打日志，属于缓解）。绝不建议 tcp_tw_recycle，NAT 场景会丢包，Linux 4.12 已移除。

MCP 与普通 API 的区别

普通 API 是人写代码去调，接口的语义、参数、错误处理都固化在调用方；MCP 是给模型看的接口标准：Server 用 JSON-RPC 2.0 over stdio 或 Streamable HTTP 暴露三类能力——tools（可执行动作）、resources（可读数据）、prompts（模板），每个工具都自带名字、自然语言描述和 JSON Schema，Client 在握手时通过 tools/list 拉取清单并把描述塞进模型上下文，由模型自主决定调用哪个、参数怎么填。区别就在「谁来决定调用」和「接口描述给谁看」：API 面向程序员，MCP 面向模型，所以描述质量、参数校验和危险动作的拦截反而变成 MCP 设计的核心问题。