2026年最新AI agent面试（10）_通信与行业动态

大家好，我是浩哥，这是我输出AI agent面试专题第十章，已完结。建议加入粉丝，后面粉丝可见。

实时通信与行业动态 · 面试题型整理与标准答案

导语：本题型含两块------①Agent 实时通信（WebSocket / SSE / WebRTC 在 AI 对话流中的选型与差异）；②行业观察（作为拓展阅读，帮助把握技术风向）。实时通信的选型本质是「场景驱动」：文字对话要的是可靠有序（TCP 系），语音对话要的是低延迟（UDP 系），而双向交互要不要上 WebSocket 取决于是否真的需要客户端随时主动发消息。把这套取舍讲清楚，比背功能列表更有架构师味。

总目录可见 2026年最新AI agent面试（0）概述篇

Q1. 为什么 AI 实时语音要用 WebRTC？它和 WebSocket 在 AI 对话流中的核心差异是什么？［来源：字节 Agent 岗一面］

核心答案 ：

根因不在「P2P 直连」这种表层特点，而在底层传输协议：WebSocket 跑在 TCP 上，WebRTC 跑在 UDP 上。两者对丢包的处理策略完全相反------TCP 丢包强制重传，重传期间后续所有数据都被阻塞排队；而语音场景的铁律是「可以容忍丢包，但绝不容忍延迟」。人类对话超过 200ms 就明显卡顿、超过 400ms 出现「说话串线」，因此 TCP 在语音里反而是负担，一次网络抖动引发的重传会让延迟堆积到通话卡死。WebRTC 主动放弃可靠性、改用 UDP，丢包时不重传而是用**丢包隐藏（PLC，Packet Loss Concealment）**做前后帧插值填补，用极轻微的瞬时音质损失换来稳定的 50--150ms 低延迟。此外 WebRTC 不是单一协议，而是「协议全家桶」，在 UDP 之上内置了编解码、回声消除（AEC）、噪声抑制（NS）、自动增益控制（AGC）、自适应码率（ABR）一整套音视频工程能力------用 WebSocket 传语音这些全得自己造轮子。这正是 OpenAI Realtime API 这类实时语音产品选 WebRTC 的原因：TCP 系方案在延迟和音频处理上根本撑不住。
关键点 / 展开：
1. 协议栈差异（最本质）：WebSocket = TCP 可靠有序，丢包重传、队头阻塞；WebRTC = UDP 不重传，PLC 插值填补。延迟区间对照：WebSocket 50--500ms（受重传影响不可控），WebRTC 50--150ms。
2. 语音 ≠ 文字的网络诉求：文字 token 流靠 TCP 可靠有序才正确（丢一个字母整段语义错乱），所以 LLM 流式文字用 TCP 系反而合适；语音丢 20ms 片段人耳无感，但等它重传把后面全堵住就崩了------两者对 TCP 的态度正好相反。
3. WebRTC 是协议组合，不是单协议：UDP（地基）→ DTLS（UDP 版 TLS，密钥协商/加密）→ SRTP（带时间戳/序列号的实时媒体传输）+ RTCP（传输质量监控反馈）→ ICE/STUN/TURN（NAT 穿透）。
4. 信令与媒体分离 ：WebRTC 建连仍需一个双向「信令通道」交换 SDP （协商编解码、网络地址、加密参数），这个通道通常用 WebSocket。即「WebSocket 跑信令、UDP 跑音频」，二者是配合关系而非替代关系------这是高分回答点。
5. NAT 穿透三级降级：本地直连 → STUN 打洞 P2P（家用路由器多数可行）→ TURN 中转（对称 NAT/企业防火墙打洞失败时退化，但仍能通）。最差情况退化成类似 WebSocket 经服务器中转。
6. 内置音频处理能力（工程量差异）：AEC 解决扬声器外放被麦克风回收形成回声循环；NS 在嘈杂环境滤背景噪声；AGC 稳定音量；ABR 依据 RTCP 监测动态调码率。这套能力是 WebSocket 做语音最难补齐的部分。
常见追问：
1. WebRTC 既然能 P2P，那它和 WebSocket 是不是替代关系？------不是，WebRTC 仍需 WebSocket 做 SDP 信令交换，媒体流才走 UDP。
2. 为什么对称 NAT 下 STUN 打洞会失败、必须走 TURN？------对称 NAT 对每个目标分配不同出口端口，STUN 探测到的端口对端连入时已变，只能兜底走双方都能访问的中转服务器。
2026 延伸：
- OpenAI Realtime API（2024 发布）选 WebRTC 作媒体传输层，要求端到端延迟 <300ms、双向语音可随时打断、且需回声消除，TCP 系与无内置音频处理的方案均不满足（来源：字节 Agent 岗一面·小林面试笔记）。

Q2. WebSocket 和 SSE 通信的区别及局限性？［来源：阿里 Agent 开发一面］

核心答案 ：

二者不是「简单 vs 复杂」或「谁是谁子集」的关系，而是底层机制根本不同 ：SSE（Server-Sent Events）是 HTTP/1.1 的原生特性 ，本质是用一条长连接的 HTTP 响应「撑开」一根从服务端流向客户端的单向水管，只有服务端能主动推，客户端想发消息必须另起一个 HTTP 请求；WebSocket 是独立协议 ，通过 HTTP 101 Switching Protocols 升级握手把一条 TCP 连接「变性」为全双工信道，双方随时主动发消息。选型逻辑很清楚------单向推就用 SSE，真正需要双向才上 WebSocket。LLM 流式文字输出是典型「模型一直吐 token、用户只看」的单向场景，SSE 完全够用且轻量、HTTP 原生、运维简单，所以 OpenAI、Anthropic 的流式 API 全用 SSE；只有需要用户中途打断、多人协同编辑、游戏实时同步这类客户端随时主动发消息的场景，才值得引入 WebSocket 的复杂度。
关键点 / 展开：
1. 通信方向（最本质差异）：SSE 单向（服务端→客户端），客户端发消息走独立 POST，靠 conversation ID 关联，是「双通道」架构；WebSocket 全双工，一条连接搞定双向。打断场景对比：SSE 需先关流再发 POST（断-重连割裂感），WebSocket 在同一条连接里直接发「停止」指令（无缝实时）。
2. 协议归属 ：SSE 是 HTTP 原生、纯文本 data: 格式 + 双换行，浏览器有 EventSource 内置 API 自动触发 onmessage；WebSocket 是独立协议、需自己定义消息格式与解析。
3. 文字场景为何 TCP 系合适：token 流需要可靠有序到达，TCP 的重传在这里是「朋友」而非负担------这与 Q1 语音场景论点形成对照（同一套 TCP 重传，在文字里是优点、在语音里是灾难）。
4. SSE 的三大局限 ：① HTTP/1.1 同域名连接数上限 6 条，多标签页会排队卡死（HTTP/2 多路复用可解）；② 只支持文本，传语音/图片需 Base64（数据膨胀约 33%+解码开销），实时语音不可接受；③ 单向性导致双通道状态管理更复杂，断线重连需 Last-Event-ID 才能「断点续传」不丢消息。
5. WebSocket 的三大局限 ：① 有状态 导致横向扩展麻烦------连接绑定特定后端机，扩容需把连接状态外移到 Redis 等共享存储并用发布订阅中转，多一跳且增延迟；② 代理/防火墙穿透差 ------企业代理（Squid）、老 CDN、安全网关可能把 Upgrade 握手当异常 HTTP 拒掉，SSE 始终是普通 HTTP 可透传；③ 无内置请求-响应配对，需自己在消息里加请求 ID 并维护 ID→回调映射，断线重连时待响应请求还需专门重试设计。
6. 选型决策树：LLM 流式文字 / 多轮对话（POST+SSE 解耦）→ SSE；用户中途打断 / 多人协同 / 游戏同步 → WebSocket；实时语音 → WebRTC；MCP 远程 Server → Streamable HTTP（内部仍用 SSE 流，代理穿透友好）。绝大多数 LLM 文字对话产品 SSE 即够。
常见追问：
1. 为什么早期 MCP 远程传输选 SSE 而非 WebSocket？------MCP Server 要在各种复杂网络环境工作，SSE 对代理/防火墙兼容性好得多（后续 2025-03-26 规范升级为单端点 Streamable HTTP，本质仍走 HTTP+SSE）。
2. WebSocket 有状态导致扩不出来，怎么解决？------连接状态外移到 Redis，借助发布订阅把消息路由到正确后端；代价是架构变复杂、多一跳延迟。
2026 延伸：
- MCP 规范在 2025 年 3 月（2025-03-26）从早期「HTTP+SSE 双端点」升级为「单端点 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」只是招聘文案的滞后，不是能力要求的边界。
关键点 / 展开：
1. 能力基线在抬升：AI 能力正从「加分项」变为后端/全栈岗的「默认基线」，尤其 Agent 化改造已成业务常态，JD 措辞滞后于真实岗位需求。
2. Demo 不等于工程：面试官最忌「LangChain 用得很熟、RAG Pipeline 跑通了，但一追问就哑火」------能否讲清切分策略、Embedding 选型、召回评估、工具调用与失败重试，才是工程能力的分水岭。
3. 考察的是「决策可解释性」：不是背组件，而是能说清「为什么这么切文档、RAG 和微调怎么取舍、Function Calling/MCP/Agent Skill 各在什么场景用」这类架构级取舍。
4. 反问也是信号：候选人以「JD 只写后端」反呛面试官，反而暴露了对岗位趋势的误判；正确姿态应是主动把 AI 能力映射到自身后端工程经验上。
5. 应对思路：后端背景者应将 AI 能力「寄生」于既有工程优势------高并发、分布式、可观测、稳定性治理，讲清楚「我把 LLM 当成一个有状态的、会犯错的下游服务来架构」，这比纯做算法的人更稀缺。
常见追问：
1. 如果 JD 真没写 AI，我简历里没有 RAG/Agent 项目，怎么接住这道题？------用后端工程经验平移：把检索、缓存、限流、降级、可观测的思路套到 Agent 系统上，证明你具备「把不确定性的模型接入稳定系统」的工程框架。
2. RAG 和微调到底怎么选？------RAG 成本低、知识可热更新、可溯源，适合知识频繁变动的场景；微调成本高、适合固化风格/能力，二者常组合而非二选一（该点详见 RAG 题型）。
2026 延伸：
- 行业训练营（如小林 coding 大模型训练营）已把「从 0 到 Offer 掌握大模型应用开发/AI Agent 开发」作为主线，并随技术迭代持续更新项目（含 Claude Code 源码泄漏后用 Python 复刻等紧跟热点的实战），侧面印证 AI 工程能力已成为求职通用硬通货（来源：面试实况记录·小林面试笔记）。

📚 拓展阅读（行业观察，非面试题）

Claude Fable 5 发布（来源：小林 coding / 小林面试笔记，2026-06-12）
- Fable 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 5；Claude Code 需 claude update 到 v2.1.170+ 后用 /mode 切换；2026-06-22 前免费含于 Pro/Max 套餐。
- 对 Agent 开发的影响：长任务代码迁移、复杂物理/3D 生成等「高规划 + 一次成型」能力跃升，意味着 Agent 的「执行-交付」边界进一步前移，可把更重的工程子任务直接委托给模型。
Codex 退场，GPT-5.6 上位，Claude 被动挨打（来源：小林 coding / 小林面试笔记，2026-07-11）
- Codex 与 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、输出$ 30；Luna 输入 $1、输出$ 6；Claude Fable 5 输入 $10、输出$ 50------Sol 输入价仅 Fable 5 一半。Claude 在 GPT-5.6 发布后即重置全部用户 5 小时/每周额度「开粮仓」应对。
- 对 Agent 开发的影响：①多档位「速度-成本」分层让 Agent 可按子任务动态选模（轻活走 Luna、重活走 Sol）；②Codex 融入统一工作台预示「Agent 即工作台」的产品形态；③单价便宜≠额度更耐用，真实消耗还看推理档位、上下文、工具调用与并行 Agent 数------架构选型时要做成本建模。

📌 本题型速记 Checklist

✅ 协议分层是根因：WebSocket=TCP 可靠有序；WebRTC=UDP 不重传；SSE=HTTP 原生长连接。选型先问「场景要可靠还是要低延迟」。
✅ 语音铁律：容忍丢包、绝不容忍延迟 → 选 UDP/WebRTC（PLC 插值补帧）；文字 token 流要可靠有序 → TCP 系（重传是朋友）。
✅ WebRTC ≠ 单协议：UDP + DTLS + SRTP/RTCP + ICE/STUN/TURN；仍用 WebSocket 跑 SDP 信令，媒体与信令分离、配合而非替代。
✅ WebRTC 内置音频工程：AEC 回声消除、NS 噪声抑制、AGC 自动增益、ABR 自适应码率------WebSocket 做语音全得自研。
✅ SSE vs WebSocket 最本质：SSE 单向推（客户端发消息走独立 POST）；WebSocket 全双工（一条连接双向）。
✅ SSE 三坑 ：HTTP/1.1 连接数上限 6、仅文本（二进制需 Base64 膨胀 33%）、双通道状态管理 + Last-Event-ID 断点续传。
✅ WebSocket 三坑：有状态难横向扩展（需 Redis 外移连接状态）、易被代理/防火墙拦截 Upgrade 握手、无内置请求-响应配对（自管请求 ID 映射）。
✅ 选型口诀：单向推用 SSE，真双向才上 WebSocket，实时语音上 WebRTC；LLM 文字对话 SSE 即够（OpenAI/Anthropic 已验证）。
✅ MCP 远程传输演进：早期 HTTP+SSE 双端点 → 2025-03-26 单端点 Streamable HTTP（仍用 SSE 流，代理穿透友好）。
✅ 行业风向 ：AI 能力已成后端/全栈岗默认基线（JD 滞后于真实需求）；模型进入「速度-成本分档 + Agent 工作台」时代，架构选型须做成本与能力建模。

2026年最新AI agent面试（10）_通信与行业动态

实时通信与行业动态 · 面试题型整理与标准答案

Q1. 为什么 AI 实时语音要用 WebRTC？它和 WebSocket 在 AI 对话流中的核心差异是什么？ ［来源：字节 Agent 岗一面］

Q2. WebSocket 和 SSE 通信的区别及局限性？ ［来源：阿里 Agent 开发一面］

Q3. 后端岗 JD 没写 AI，为什么面试仍在考察 RAG / Agent 能力？ ［来源：面试实况记录·小林面试笔记］

📚 拓展阅读（行业观察，非面试题）

📌 本题型速记 Checklist

Q1. 为什么 AI 实时语音要用 WebRTC？它和 WebSocket 在 AI 对话流中的核心差异是什么？［来源：字节 Agent 岗一面］

Q2. WebSocket 和 SSE 通信的区别及局限性？［来源：阿里 Agent 开发一面］

Q3. 后端岗 JD 没写 AI，为什么面试仍在考察 RAG / Agent 能力？［来源：面试实况记录·小林面试笔记］