Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D5 The Tool System and Event-Driven Design: Parameter Validation, Feeding Errors Back for Self-Correction, Event Subscription (dg P05/P06/M05/M07)

• Which lifecycle events does an agent runtime typically expose, and why is waiting for the final return value not enough?Agent 的事件系统一般会暴露哪些生命周期事件？为什么不能只等最终返回值？

  Common in ChinaCommon overseasIntermediate#event-driven#observability

  How to reason about it · think before answering

  1. It looks like a listing question but it really tests whether you have shipped an agent with a UI. Reciting event names without saying what each one is for reads as documentation-deep only.
  2. Start with the motivation: a tool-using loop runs from seconds to minutes, calling models and tools and sometimes retrying, while the return value is just the final sentence. Everything in between is a black box to the caller, who cannot tell whether to keep waiting.
  3. List them with a purpose each: run:start, run:end and run:error mark the turn and its two endings; model:delta carries text fragments for the typewriter effect; tool:proposed fires when the model has chosen a tool but has not executed it, which is where the approval gate hangs; tool:start, tool:end and tool:error are the three exits of execution, with duration on tool:end; approval:required tells the UI to show a confirmation card.
  4. Then name the real payoff: one event stream feeds three consumers — the UI renders progress, logging gets distributed tracing, and metering reads token counts off run:end. One stream instead of three instrumentation layers is an architecture answer, not an API listing.
  5. Add two implementation rules that separate candidates: every event carries a runId and a monotonic sequence number because ordering is not guaranteed once events cross processes, and listeners must contain no business logic and never let an exception escape into the main loop. Events are a side channel, not the trunk.
  6. Expect the follow-up: isn't one event per token too many? Yes, so batch on a time window — flush every 50ms, which is imperceptible to users and cuts message volume by an order of magnitude.

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

  1. 这题看起来是背清单，实际考的是你有没有做过带界面的 Agent。只报事件名不解释用途，会被判成看过文档但没接过前端。
  2. 先说动机：一次带工具的循环短则几秒长则几分钟，中间要调模型、调工具、可能还失败重试，而返回值只有最后一句话。对调用方来说中间全是黑盒——不知道它在干什么，也不知道该不该再等。
  3. 再报清单并各配一句用途：run:start / run:end / run:error 是一轮的开始与两种结束；model:delta 是模型吐出的文本片段，前端拿它做打字机效果；tool:proposed 是模型决定要调工具但还没执行，权限确认就挂在这个事件上；tool:start / tool:end / tool:error 是工具执行的三个出口，tool:end 带耗时；approval:required 让界面弹确认框。
  4. 然后说出这套设计真正的价值：同一条事件流同时喂三个消费者——界面渲染进度、日志系统做链路追踪、计量系统拿 run:end 的 token 数算成本。不为三件事写三套埋点，这是架构判断而不是 API 罗列。
  5. 补两条实现纪律，能显著拉开差距：事件必须带 runId 和自增序号，因为跨进程传输后顺序不保证；监听器里不写业务逻辑，且监听器抛错不能炸掉主循环——事件是旁路不是主干。
  6. 可以预期的追问：model:delta 一个 token 一条事件会不会太多？会，所以要按时间窗合批，攒 50 毫秒推一次，用户感知不到差别而消息量掉一个数量级。

  Key points

  • Motivation: a turn takes seconds to minutes and only returns the final sentence, so the caller cannot tell whether to keep waiting
  • Typical events: run:start/end/error, model:delta, tool:proposed, tool:start/end/error, approval:required
  • One stream serves the UI, distributed tracing and cost metering — no need for three instrumentation layers
  • Every event carries a runId and a sequence number since ordering is not guaranteed across processes
  • Listeners hold no business logic and must not throw into the main loop; batch model:delta on a 50ms window

  答题要点

  • 动机：一轮循环几秒到几分钟，返回值只有最后一句话，中间全是黑盒，调用方无法判断该不该继续等
  • 常见事件：run:start / run:end / run:error、model:delta、tool:proposed、tool:start / tool:end / tool:error、approval:required
  • 同一条事件流同时喂界面、日志链路追踪和成本计量三个消费者，不用写三套埋点
  • 事件要带 runId 和自增序号，跨进程后顺序不保证，消费端要能自己排序
  • 监听器不写业务逻辑，且抛错不能影响主循环；model:delta 要按 50 毫秒时间窗合批