Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D11 The Run State Machine, Streaming Output Back, Ordering by runId, SSE Waiters, Merging Interruptions Within 30 Seconds

• A user sends another message while the agent is still answering the previous one. How should the system handle it?用户在 Agent 还没回复完的时候又发来一条消息，应该怎么处理？

  Common in ChinaCommon overseasIntermediate#interrupt-merge#state-machine#cost

  How to reason about it · think before answering

  1. It reads like a product question but tests whether you have thought through two concurrent runs. 'Queue it' or 'cancel the previous one' are not wrong, just incomplete — they want the criteria and the costs.
  2. Start with what happens if you ignore it: two runs write into the same conversation, so the UI shows two interleaved answers, and the first run was computed from incomplete input, so its answer is already wrong. Those two consequences point straight at merging rather than concurrency.
  3. Then give the actual test — all three must hold: same session, the previous run is running or streaming, and it was created less than 30 seconds ago. On a hit, append the new message to that run's input and flag it for a rerun instead of creating a new run; outside the window, or if the previous run finished, create a new one. Excluding pending is deliberate: that window lasts milliseconds, and excluding it keeps the rule free of races with the worker reading the input.
  4. Two implementation details show hands-on experience. First, the rerun flag does not belong in the business table — it is meaningful only during this execution, and persisting it means a crash mid-flight leaves a dirty flag that makes the run loop forever after restart; an expiring key is the right home. Second, on rerun the sequence must keep counting up rather than resetting, or a reconnecting client resuming from its last id lands in a history that has been invalidated.
  5. Volunteer the arithmetic to kill the 'saves money' answer: at roughly 2000 input and 500 output tokens, one answer costs about $0.0006. Not merging means two full runs, about $0.0012; merging means a first pass cut off a third of the way in (about $0.0004) plus a full second pass ($0.0006), about $0.0010 — a 17% saving, which is two dollars a day even at ten thousand corrections. Merging is a user-experience decision, not a cost optimization.
  6. Expect: where does 30 seconds come from? It is a product judgment, not a derivation — corrections usually arrive 5 to 15 seconds in, too short misses them and too long merges genuinely new questions into old ones. What matters is defining it once and referencing it from both the rule and the UI hint rather than scattering the constant.

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

  1. 这题看起来是产品题，其实考的是你有没有想过「并发两次执行」的后果。答「排队处理」或「直接取消上一条」都不算错，但都不完整——面试官想听的是判据和代价。
  2. 先说清不处理会怎样：两次执行同时往同一个会话里写输出，前端看到两段交错的文字；而且第一次执行是基于不完整的信息跑的，它的答案注定要被推翻。这两条后果一说，方案的方向就定了——要合并，不要并发。
  3. 然后给可执行的判据，三个条件全中才合并：同一个会话、上一次执行正处于 running 或 streaming、距它创建不到 30 秒。命中就把新消息追加进同一次执行的输入并标记为需要重跑，不新建；超窗或上一次已完成就正常新建。把 pending 排除掉是有意的——那段窗口只有几毫秒，排除后判据不必考虑「执行侧正好在这一刻读输入」的竞态。
  4. 两个实现细节最能体现动手过：一是「需要重跑」这个标记不要写进业务表，它只在本次执行期间有意义，写进表里进程崩在半路就留下脏标记、重启后无限重跑，放一个带过期时间的键上更合适；二是重跑时序号必须接着往上加、不能重置，否则重连的客户端按上次收到的号续，会续到一段已经作废的历史上。
  5. 主动算一笔账，把「为了省钱」这个错误理由挡回去：按输入 2000、输出 500 个 token 估，单次约 0.0006 美元；不合并是两次跑完约 0.0012 美元，合并是第一遍被掐在三分之一处约 0.0004 美元加第二遍 0.0006 美元约 0.0010 美元，只省 17%，一天一万次改口也就两美元。所以合并的理由是体验，不是成本。
  6. 可以预期的追问：30 秒怎么定的？答它是产品判断不是推导结果——用户改口通常在 5 到 15 秒之间，窗口太短合并不到、太长会把新问题误并成补充；关键是这个数只在一处定义、被判据与前端提示共同引用，不要在代码里散落三份。

  Key points

  • Without merging you get two interleaved answers in one conversation, and the first was computed from incomplete input
  • Merge only when all three hold: same session, previous run running or streaming, created under 30 seconds ago; otherwise create a new run
  • On a merge, append to the same run's input and flag a rerun, keeping that flag in an expiring key rather than the business table
  • Sequence numbers keep counting on rerun and are never reset, or reconnects resume into an invalidated history
  • The cost saving is small (about 17%); the real reason is to avoid two answers talking over each other

  答题要点

  • 不合并的两个后果：两段输出交错写进同一个会话，且第一次执行基于不完整信息注定被推翻
  • 判据三条全中才合并：同一会话、上一次执行处于 running 或 streaming、距创建不到 30 秒；否则正常新建
  • 命中就把新消息追加进同一次执行的输入并标记需要重跑，标记放带过期时间的键上而不是业务表
  • 重跑时序号继续往上加、绝不重置，否则断线重连会续到作废的历史上
  • 合并省的钱有限（约 17%），真正的理由是不让两个回答同时对着用户说话