面试题库

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

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

• 用户主动点「停止生成」和网络意外断开，在服务端看起来都是连接没了，怎么区分处理？A user pressing stop and a dropped connection both look like a closed connection server-side. How do you tell them apart?

  国内高频海外高频深入#streaming#reliability#ux

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

  1. 先点破为什么要区分：主动停止是「用户不想要了」，应当立即释放算力并结束这轮；意外断开是「用户还想要」，理应保留结果供恢复。处理反了，用户要么白花钱，要么回来发现内容没了。
  2. 所以不能只靠 TCP 连接状态判断——它对两种情况的表现是一样的。必须有一个显式信号。
  3. 做法是给「停止」单独一个接口：前端点停止时先调这个接口，带上 run id，服务端据此把该轮标记为「用户取消」，再中止上游模型调用。
  4. 而单纯的连接关闭一律按「意外断开」处理：继续把已生成内容落盘、保留可恢复的流，等客户端回来续。
  5. 补一个现实约束：停止请求本身也可能因为断网而发不出去。所以服务端还需要兜底——比如流没有任何消费者超过一定时间就自行结束，避免算力空转。
  6. 延伸到计费：两种情况都要为已经产生的 token 计费，因为上游厂商已经收了钱；区别只在于要不要保留结果和是否继续生成。

  How to reason about it · think before answering

  1. Say why it matters: stop means the user no longer wants the output, so free compute and end the run; a drop means they still want it, so preserve the result for resumption.
  2. Connection state alone cannot distinguish them — it looks identical — so you need an explicit signal.
  3. Give stop its own endpoint: the client calls it with the run id before closing, and the server marks the run as user-cancelled and aborts the upstream call.
  4. Treat a bare connection close as an unexpected drop: keep persisting output and hold the stream for resumption.
  5. Add the real-world caveat: the stop request itself may fail to send when the network is down, so the server needs a fallback — end a stream with no consumer after a timeout.
  6. Extend to billing: both cases still owe for tokens already produced, since the upstream provider has charged; they differ only in whether output is retained.

  答题要点

  • 两者语义相反：主动停止要立即释放算力并结束，意外断开要保留结果等待恢复
  • TCP 连接状态无法区分，必须有显式信号：给停止单独一个接口，带 run id 标记为用户取消
  • 只收到连接关闭一律按意外断开处理，继续落盘并保留可恢复的流
  • 兜底：停止请求本身也可能发不出去，服务端需对长时间无消费者的流自行结束
  • 计费上两者都要为已产生的 token 记账，区别只在于是否保留结果、是否继续生成

  Key points

  • The semantics are opposite: stop frees compute immediately, a drop preserves output for resumption
  • Connection state cannot distinguish them, so add an explicit stop endpoint carrying the run id
  • Treat a bare close as an unexpected drop: keep persisting and hold the stream for resume
  • Fallback: the stop call may itself fail to send, so end streams with no consumer after a timeout
  • Both still bill for tokens already produced; they differ only in retention and whether generation continues

D25 前端侧 Agent 体验：流式渲染、工具调用可视化、打断/重试、SSE hooks

• 失败重试怎么设计才不会产生重复副作用？工具调用过程要不要暴露给用户？How do you design retry so it does not duplicate side effects, and should the tool-call process be visible to the user?

  国内高频海外高频进阶#idempotency#retry#ux

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

  1. 这题把两件事绑在一起问，考的是你能不能看出它们的共同点：**都是「把不可见的中间状态变成可控的」**。分开答也行，但点出这层关系会显得成熟。
  2. 重试这一半的推导链：重试意味着同一句话可能被执行两遍 → 两倍 token，还可能两次不可逆的工具调用（比如退款打两次钱）→ 所以要幂等 → 幂等键必须由**客户端在第一次发送时生成**并在重试时原样带上 → 后端拿它做唯一约束，命中就把已有 run 的流接回来，而不是新建。
  3. 关键判据要说清：**什么时候该换新键？** 判据是「要发送的内容变没变」，不是「用户点了哪个按钮」。同一句话重试用同一个键；用户改了内容重新发，那是新的一句话，必须换新键。
  4. 顺带提一句这一招的复用面会很加分：落库去重、定时任务防止一个 tick 被消费两次、跨服务调用防重复投递、前端重试——同一个形状用在四个层面，最终裁判永远是数据库的唯一约束，不是应用层的先查后写。
  5. 工具可视化这一半：中间过程要暴露，理由有三条——用户能判断要不要打断（不然他只能盲等）；等待变得可以忍受（十几秒的转圈会让人刷新页面，而刷新意味着这一轮的钱白花）；出问题时用户能说清「卡在查订单那一步」，客服和你都省事。
  6. 可预期的追问：全都暴露会不会泄露内部实现？会，所以要过滤——工具名用人话不用函数名，参数里的用户标识、内部 id、密钥一律不显示，错误显示归类后的原因而不是原始堆栈。**可视化的是过程，不是内部结构。**

  How to reason about it · think before answering

  1. The question bundles two topics, and the test is whether you see what they share: both turn invisible intermediate state into something the user can act on. Answering them separately is fine, but naming the link reads as senior.
  2. Chain for retry: retrying means the same message may execute twice, costing double tokens and possibly duplicating irreversible tool calls such as issuing a refund twice. Hence idempotency. The key must be generated by the client on the first attempt and resent unchanged on retry, and the backend enforces it with a unique constraint, reattaching to the existing run instead of creating a new one.
  3. State the decision rule clearly: when do you mint a new key? The rule is whether the content being sent changed, not which button the user pressed. Same message retried keeps the key; edited content is a new message and needs a new key.
  4. Mentioning how far this pattern reaches scores well: write deduplication, cron ticks consumed exactly once, cross-service delivery, and frontend retry — the same shape at four layers, with the database's unique constraint always the final arbiter rather than an application-level check-then-write.
  5. For tool visibility: expose the process, for three reasons. The user can decide whether to interrupt instead of waiting blind; waiting becomes tolerable, since a spinner for fifteen seconds invites a page refresh that wastes the whole turn; and when something breaks the user can say 'it hung on looking up my order', which saves everyone time.
  6. Expected follow-up: does exposing everything leak internals? It can, so filter. Show human-readable tool names rather than function names, hide user identifiers, internal ids and secrets from the arguments, and show classified error reasons rather than raw stack traces. You are surfacing the process, not the internal structure.

  答题要点

  • 重试要带客户端首次生成的幂等键，后端用唯一约束命中后把已有 run 的流接回来，不新建。
  • 换不换键的判据是「内容变没变」：同一句话重试用同一个键，改了内容才换新键。
  • 同一招在落库、定时任务、跨服务调用、前端重试四处复用，最终裁判永远是数据库的唯一约束。
  • 工具调用要可视化：用户才能判断要不要打断、等待变得可忍受、出问题时说得清卡在哪一步。
  • 但要过滤：工具名用人话、参数里的内部 id 与密钥不显示、错误显示归类原因而不是原始堆栈。

  Key points

  • Retry carries the idempotency key minted on the first attempt; the backend hits a unique constraint and reattaches to the existing run.
  • The rule for minting a new key is whether the content changed — same message keeps the key, edited content gets a new one.
  • The same pattern recurs in write dedup, cron ticks, cross-service delivery and frontend retry, always arbitrated by a database unique constraint.
  • Make tool calls visible so users can decide whether to interrupt, tolerate the wait, and describe where it hung.
  • But filter: human-readable tool names, no internal ids or secrets in the arguments, classified error reasons instead of raw stack traces.