大家好我是浩哥这是我输出AI agent面试专题第十章已完结。建议加入粉丝后面粉丝可见。实时通信与行业动态 · 面试题型整理与标准答案导语本题型含两块——①Agent 实时通信WebSocket / SSE / WebRTC 在 AI 对话流中的选型与差异②行业观察作为拓展阅读帮助把握技术风向。实时通信的选型本质是「场景驱动」文字对话要的是可靠有序TCP 系语音对话要的是低延迟UDP 系而双向交互要不要上 WebSocket 取决于是否真的需要客户端随时主动发消息。把这套取舍讲清楚比背功能列表更有架构师味。2026年最新AI agent面试01_Agent基础与推理范式2026年最新AI agent面试02_MultiAgent与记忆2026年最新AI agent面试03_工具协议MCP_A2A_FC2026年最新AI agent面试04__工具工程网关外部2026年最新AI agent面试05_RAG基础应用2026年最新AI agent面试06_RAG文档与检索2026年最新AI agent面试07_大模型架构基础2026年最新AI agent面试08_大模型训练评测2026年最新AI agent面试09_AI编程ClaudeCode2026年最新AI agent面试10_通信与行业动态总目录可见 2026年最新AI agent面试0概述篇Q1. 为什么 AI 实时语音要用 WebRTC它和 WebSocket 在 AI 对话流中的核心差异是什么 来源字节 Agent 岗一面核心答案根因不在「P2P 直连」这种表层特点而在底层传输协议WebSocket 跑在TCP上WebRTC 跑在UDP上。两者对丢包的处理策略完全相反——TCP 丢包强制重传重传期间后续所有数据都被阻塞排队而语音场景的铁律是「可以容忍丢包但绝不容忍延迟」。人类对话超过 200ms 就明显卡顿、超过 400ms 出现「说话串线」因此 TCP 在语音里反而是负担一次网络抖动引发的重传会让延迟堆积到通话卡死。WebRTC 主动放弃可靠性、改用 UDP丢包时不重传而是用**丢包隐藏PLCPacket Loss Concealment**做前后帧插值填补用极轻微的瞬时音质损失换来稳定的 50–150ms 低延迟。此外 WebRTC 不是单一协议而是「协议全家桶」在 UDP 之上内置了编解码、回声消除AEC、噪声抑制NS、自动增益控制AGC、自适应码率ABR一整套音视频工程能力——用 WebSocket 传语音这些全得自己造轮子。这正是 OpenAI Realtime API 这类实时语音产品选 WebRTC 的原因TCP 系方案在延迟和音频处理上根本撑不住。关键点 / 展开协议栈差异最本质WebSocket TCP 可靠有序丢包重传、队头阻塞WebRTC UDP 不重传PLC 插值填补。延迟区间对照WebSocket 50–500ms受重传影响不可控WebRTC 50–150ms。语音 ≠ 文字的网络诉求文字 token 流靠 TCP 可靠有序才正确丢一个字母整段语义错乱所以 LLM 流式文字用 TCP 系反而合适语音丢 20ms 片段人耳无感但等它重传把后面全堵住就崩了——两者对 TCP 的态度正好相反。WebRTC 是协议组合不是单协议UDP地基→ DTLSUDP 版 TLS密钥协商/加密→ SRTP带时间戳/序列号的实时媒体传输 RTCP传输质量监控反馈→ ICE/STUN/TURNNAT 穿透。信令与媒体分离WebRTC 建连仍需一个双向「信令通道」交换SDP协商编解码、网络地址、加密参数这个通道通常用 WebSocket。即「WebSocket 跑信令、UDP 跑音频」二者是配合关系而非替代关系——这是高分回答点。NAT 穿透三级降级本地直连 → STUN 打洞 P2P家用路由器多数可行→ TURN 中转对称 NAT/企业防火墙打洞失败时退化但仍能通。最差情况退化成类似 WebSocket 经服务器中转。内置音频处理能力工程量差异AEC 解决扬声器外放被麦克风回收形成回声循环NS 在嘈杂环境滤背景噪声AGC 稳定音量ABR 依据 RTCP 监测动态调码率。这套能力是 WebSocket 做语音最难补齐的部分。常见追问WebRTC 既然能 P2P那它和 WebSocket 是不是替代关系——不是WebRTC 仍需 WebSocket 做 SDP 信令交换媒体流才走 UDP。为什么对称 NAT 下 STUN 打洞会失败、必须走 TURN——对称 NAT 对每个目标分配不同出口端口STUN 探测到的端口对端连入时已变只能兜底走双方都能访问的中转服务器。2026 延伸OpenAI Realtime API2024 发布选 WebRTC 作媒体传输层要求端到端延迟 300ms、双向语音可随时打断、且需回声消除TCP 系与无内置音频处理的方案均不满足来源字节 Agent 岗一面·小林面试笔记。Q2. WebSocket 和 SSE 通信的区别及局限性 来源阿里 Agent 开发一面核心答案二者不是「简单 vs 复杂」或「谁是谁子集」的关系而是底层机制根本不同SSEServer-Sent Events是HTTP/1.1 的原生特性本质是用一条长连接的 HTTP 响应「撑开」一根从服务端流向客户端的单向水管只有服务端能主动推客户端想发消息必须另起一个 HTTP 请求WebSocket 是独立协议通过 HTTP101 Switching Protocols升级握手把一条 TCP 连接「变性」为全双工信道双方随时主动发消息。选型逻辑很清楚——单向推就用 SSE真正需要双向才上 WebSocket。LLM 流式文字输出是典型「模型一直吐 token、用户只看」的单向场景SSE 完全够用且轻量、HTTP 原生、运维简单所以 OpenAI、Anthropic 的流式 API 全用 SSE只有需要用户中途打断、多人协同编辑、游戏实时同步这类客户端随时主动发消息的场景才值得引入 WebSocket 的复杂度。关键点 / 展开通信方向最本质差异SSE 单向服务端→客户端客户端发消息走独立 POST靠 conversation ID 关联是「双通道」架构WebSocket 全双工一条连接搞定双向。打断场景对比SSE 需先关流再发 POST断-重连割裂感WebSocket 在同一条连接里直接发「停止」指令无缝实时。协议归属SSE 是 HTTP 原生、纯文本data:格式 双换行浏览器有EventSource内置 API 自动触发onmessageWebSocket 是独立协议、需自己定义消息格式与解析。文字场景为何 TCP 系合适token 流需要可靠有序到达TCP 的重传在这里是「朋友」而非负担——这与 Q1 语音场景论点形成对照同一套 TCP 重传在文字里是优点、在语音里是灾难。SSE 的三大局限① HTTP/1.1 同域名连接数上限 6 条多标签页会排队卡死HTTP/2 多路复用可解② 只支持文本传语音/图片需 Base64数据膨胀约 33%解码开销实时语音不可接受③ 单向性导致双通道状态管理更复杂断线重连需Last-Event-ID才能「断点续传」不丢消息。WebSocket 的三大局限①有状态导致横向扩展麻烦——连接绑定特定后端机扩容需把连接状态外移到 Redis 等共享存储并用发布订阅中转多一跳且增延迟②代理/防火墙穿透差——企业代理Squid、老 CDN、安全网关可能把Upgrade握手当异常 HTTP 拒掉SSE 始终是普通 HTTP 可透传③无内置请求-响应配对需自己在消息里加请求 ID 并维护 ID→回调映射断线重连时待响应请求还需专门重试设计。选型决策树LLM 流式文字 / 多轮对话POSTSSE 解耦→ SSE用户中途打断 / 多人协同 / 游戏同步 → WebSocket实时语音 → WebRTCMCP 远程 Server → Streamable HTTP内部仍用 SSE 流代理穿透友好。绝大多数 LLM 文字对话产品 SSE 即够。常见追问为什么早期 MCP 远程传输选 SSE 而非 WebSocket——MCP Server 要在各种复杂网络环境工作SSE 对代理/防火墙兼容性好得多后续 2025-03-26 规范升级为单端点 Streamable HTTP本质仍走 HTTPSSE。WebSocket 有状态导致扩不出来怎么解决——连接状态外移到 Redis借助发布订阅把消息路由到正确后端代价是架构变复杂、多一跳延迟。2026 延伸MCP 规范在 2025 年 3 月2025-03-26从早期「HTTPSSE 双端点」升级为「单端点 Streamable HTTP」保留代理穿透友好特性、内部仍以 SSE 做流式来源阿里 Agent 开发一面·小林面试笔记。Q3. 后端岗 JD 没写 AI为什么面试仍在考察 RAG / Agent 能力 来源面试实况记录·小林面试笔记核心答案这是 2025–2026 年校招/社招中非常典型的「JD 与考察错位」现象岗位 JD 仍写「后端开发」但面试官会直接问「做过 RAG 或 Agent 吗」并明确表态「没写 AI不代表不用考察 AI 能力」。其底层逻辑是——大模型应用开发已从「专岗专用」下沉为通用研发的基础设施能力。当所有业务系统都在叠加 AI 能力智能问答、工单 Agent、代码 Copilot、检索增强后台哪怕是传统后端工程师也必须具备把 LLM 接入生产系统的工程素养能设计 RAG 检索链路、能搭建 Agent 编排与工具调用、能评估与治理模型输出。面试官真正要的不是一个跑通 Demo 的人而是一个「能在生产环境把系统撑起来、且能把每个技术决策讲清楚」的工程师。因此「JD 不写 AI」只是招聘文案的滞后不是能力要求的边界。关键点 / 展开能力基线在抬升AI 能力正从「加分项」变为后端/全栈岗的「默认基线」尤其 Agent 化改造已成业务常态JD 措辞滞后于真实岗位需求。Demo 不等于工程面试官最忌「LangChain 用得很熟、RAG Pipeline 跑通了但一追问就哑火」——能否讲清切分策略、Embedding 选型、召回评估、工具调用与失败重试才是工程能力的分水岭。考察的是「决策可解释性」不是背组件而是能说清「为什么这么切文档、RAG 和微调怎么取舍、Function Calling/MCP/Agent Skill 各在什么场景用」这类架构级取舍。反问也是信号候选人以「JD 只写后端」反呛面试官反而暴露了对岗位趋势的误判正确姿态应是主动把 AI 能力映射到自身后端工程经验上。应对思路后端背景者应将 AI 能力「寄生」于既有工程优势——高并发、分布式、可观测、稳定性治理讲清楚「我把 LLM 当成一个有状态的、会犯错的下游服务来架构」这比纯做算法的人更稀缺。常见追问如果 JD 真没写 AI我简历里没有 RAG/Agent 项目怎么接住这道题——用后端工程经验平移把检索、缓存、限流、降级、可观测的思路套到 Agent 系统上证明你具备「把不确定性的模型接入稳定系统」的工程框架。RAG 和微调到底怎么选——RAG 成本低、知识可热更新、可溯源适合知识频繁变动的场景微调成本高、适合固化风格/能力二者常组合而非二选一该点详见 RAG 题型。2026 延伸行业训练营如小林 coding 大模型训练营已把「从 0 到 Offer 掌握大模型应用开发/AI Agent 开发」作为主线并随技术迭代持续更新项目含 Claude Code 源码泄漏后用 Python 复刻等紧跟热点的实战侧面印证 AI 工程能力已成为求职通用硬通货来源面试实况记录·小林面试笔记。 拓展阅读行业观察非面试题Claude Fable 5 发布来源小林 coding / 小林面试笔记2026-06-12Fable 5 与 Mythos 同一底座Mythos 是「裸奔版」仅给安全机构用Fable 5 是加护栏的公开版遇到网络攻击类敏感请求会自动切回 Opus 4.8。命名体系暗含段位Haiku俳句最小最快→ Sonnet十四行诗→ Opus作品最重→ Fable寓言→ Mythos神话底座文学体量对应模型段位。跑分SWE-Bench Pro 上 Fable 5 80.3% vs Opus 4.8 69.2%拉开约 11 个点。实测亮点纯视觉裸眼通关《宝可梦火红》此前带辅助工具的 Claude 都打不通、一天完成 Stripe 5000 万行 Ruby 代码库迁移原计划团队两个多月、纯 Three.js 照片级森林渲染、手写物理的 3D 拆迁模拟铁链钟摆约束 砖塔真实坍塌。使用路径Claude 网页版可直接切 Fable 5Claude Code 需claude update到 v2.1.170 后用/mode切换2026-06-22 前免费含于 Pro/Max 套餐。对 Agent 开发的影响长任务代码迁移、复杂物理/3D 生成等「高规划 一次成型」能力跃升意味着 Agent 的「执行-交付」边界进一步前移可把更重的工程子任务直接委托给模型。Codex 退场GPT-5.6 上位Claude 被动挨打来源小林 coding / 小林面试笔记2026-07-11Codex 与 ChatGPT 合并为统一桌面应用Chat 模式被压缩主界面为 Work研究/文档/网站与 Codex写代码/看 diff/跑测试双模式OpenAI 意在把「聊天、研究、执行、交付」塞进一个工作台。GPT-5.6 分三档Sol旗舰、Terra平衡速度成本、Luna最快最便宜对应日地月命名。跑分对照官方Agents’ Last Exam Sol 52.7% vs Fable 5 40.5%Coding Agent Index Sol 80 vs Fable 5 77.2但 SWE-Bench Pro 上 Fable 5 80% 反超 Sol 64.6%Toolathlon Fable 5 也略高——「长任务/代码修复」仍是 Claude 强项。价格攻击性GPT-5.6 Sol 输入 $5/百万 token、输出 $30Luna 输入 $1、输出 $6Claude Fable 5 输入 $10、输出 $50——Sol 输入价仅 Fable 5 一半。Claude 在 GPT-5.6 发布后即重置全部用户 5 小时/每周额度「开粮仓」应对。对 Agent 开发的影响①多档位「速度-成本」分层让 Agent 可按子任务动态选模轻活走 Luna、重活走 Sol②Codex 融入统一工作台预示「Agent 即工作台」的产品形态③单价便宜≠额度更耐用真实消耗还看推理档位、上下文、工具调用与并行 Agent 数——架构选型时要做成本建模。 本题型速记 Checklist✅协议分层是根因WebSocketTCP 可靠有序WebRTCUDP 不重传SSEHTTP 原生长连接。选型先问「场景要可靠还是要低延迟」。✅语音铁律容忍丢包、绝不容忍延迟 → 选 UDP/WebRTCPLC 插值补帧文字 token 流要可靠有序 → TCP 系重传是朋友。✅WebRTC ≠ 单协议UDP DTLS SRTP/RTCP ICE/STUN/TURN仍用 WebSocket 跑 SDP 信令媒体与信令分离、配合而非替代。✅WebRTC 内置音频工程AEC 回声消除、NS 噪声抑制、AGC 自动增益、ABR 自适应码率——WebSocket 做语音全得自研。✅SSE vs WebSocket 最本质SSE 单向推客户端发消息走独立 POSTWebSocket 全双工一条连接双向。✅SSE 三坑HTTP/1.1 连接数上限 6、仅文本二进制需 Base64 膨胀 33%、双通道状态管理 Last-Event-ID断点续传。✅WebSocket 三坑有状态难横向扩展需 Redis 外移连接状态、易被代理/防火墙拦截 Upgrade 握手、无内置请求-响应配对自管请求 ID 映射。✅选型口诀单向推用 SSE真双向才上 WebSocket实时语音上 WebRTCLLM 文字对话 SSE 即够OpenAI/Anthropic 已验证。✅MCP 远程传输演进早期 HTTPSSE 双端点 → 2025-03-26 单端点 Streamable HTTP仍用 SSE 流代理穿透友好。✅行业风向AI 能力已成后端/全栈岗默认基线JD 滞后于真实需求模型进入「速度-成本分档 Agent 工作台」时代架构选型须做成本与能力建模。