面试题库

30 天从前端工程师到 Agent 工程师

D1 LLM API 基础：messages/roles、token、流式、temperature；Agent 到底是什么

• 移动端 App 里的对话，网络频繁抖动，你会怎么设计重连策略？On mobile, connectivity is flaky. How would you design the reconnection strategy for a chat feature?

  国内高频海外高频进阶#reliability#mobile#streaming

  分析过程 · 先想清楚再作答

  1. 先说明移动端和浏览器的差别：网络在 WiFi 与蜂窝之间切换、App 会被系统挂起、后台执行时间受限，所以不能照搬网页那套。
  2. 重试节奏用指数退避加随机抖动。抖动这一条常被忽略，但它是防止大面积断网恢复后所有客户端同时涌上来把服务打垮的关键。
  3. 要设上限：最大重试次数与最大退避间隔，超过就转成显式的「重新加载」按钮交给用户，而不是无限静默重试。
  4. 区分「短暂抖动」和「真的没网」：监听系统的网络状态变化，没网时直接停止重试并进入离线态，等网络恢复事件再立刻重连，比盲目定时重试省电得多。
  5. 结合上一题的服务端持久化：App 被系统杀掉后重进，靠会话 id 请求恢复端点，而不是指望本地缓存拼出完整回复。
  6. 最后补发送侧：用户在离线时发出的消息进本地队列，恢复后按序重发，且每条带幂等键，避免重复发送。

  How to reason about it · think before answering

  1. Start with what makes mobile different: network switches between WiFi and cellular, the OS suspends apps, background time is limited.
  2. Use exponential backoff with jitter; jitter is the commonly missed part that prevents a thundering herd when a wide outage clears.
  3. Set ceilings: max attempts and max interval, then surface an explicit reload action instead of retrying silently forever.
  4. Distinguish a brief blip from being genuinely offline: subscribe to OS connectivity events, stop retrying when offline, and reconnect on the restore event — far cheaper on battery than blind timers.
  5. Combine with server-side persistence: after the OS kills the app, resume by chat id rather than reconstructing from local cache.
  6. Finally the send path: queue outgoing messages while offline and replay them in order, each with an idempotency key.

  答题要点

  • 移动端特殊性：WiFi 与蜂窝切换、App 被挂起、后台执行时间受限，不能照搬网页策略
  • 指数退避加随机抖动，抖动用于避免大面积恢复时的重连风暴
  • 设最大重试次数与最大间隔，超过后转为显式的重新加载入口，不做无限静默重试
  • 监听系统网络状态：离线直接停重试进入离线态，收到恢复事件再重连，比定时轮询省电
  • 回复恢复依赖服务端持久化，靠会话 id 请求恢复端点；发送侧用本地队列加幂等键按序重发

  Key points

  • Mobile differs: network handoffs, OS suspension, limited background time — do not copy the web strategy
  • Exponential backoff with jitter, where jitter prevents a reconnect storm when an outage clears
  • Cap attempts and interval, then hand the user an explicit reload instead of retrying forever
  • Listen to OS connectivity events: stop while offline, reconnect on restore, which saves battery over polling
  • Resume replies via server-side persistence by chat id; queue outgoing messages with idempotency keys