面试题库

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

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

• 断线重试之后，怎么保证不重复计费、也不重复执行已经做过的工具调用？After a retry, how do you avoid double billing and re-executing tool calls that already ran?

  国内高频海外高频深入#reliability#tools#idempotency

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

  1. 先把问题拆成两半：计费是「记录问题」，工具副作用是「执行问题」，两者的解法不同，混在一起答会含糊。
  2. 计费侧：用量应该在服务端按实际收到的 token 记账，而不是按「请求次数」。断在中途已经产生的 token 是真实成本，要照记；重试产生的是新成本，也要照记——关键是别把同一批 token 记两遍。
  3. 为此需要一个稳定的标识：给每轮生成一个 run id，用量记录以 run id + 序号去重，重放同一段不会重复入账。
  4. 工具侧：真正危险的是有副作用的工具（转账、发消息、下单）。解法是幂等键——由调用参数派生一个稳定的 key，执行前先查这个 key 是否已有结果，有就直接返回旧结果。
  5. 补一层状态机视角：把每次工具调用记为「待执行 / 执行中 / 已完成」，重试时只重放未完成的部分，已完成的直接取结果，这也是恢复中断任务的通用做法。
  6. 常见追问：幂等键该谁生成？应由客户端或调度侧生成并随请求传递，服务端自己生成就没法跨重试保持一致。

  How to reason about it · think before answering

  1. Split it in two: billing is a bookkeeping problem, tool side effects are an execution problem, and they have different fixes.
  2. Billing: meter server-side by tokens actually produced, not by request count. Tokens produced before the break are real cost; so are retry tokens. The point is not to count the same batch twice.
  3. That needs a stable identifier: give each generation a run id and dedupe usage records by run id plus sequence.
  4. Tools: the danger is side-effecting tools — transfers, messages, orders. The fix is an idempotency key derived from the call arguments, checked before execution.
  5. Add the state-machine view: record each call as pending / running / done and replay only what is unfinished.
  6. Follow-up: who generates the idempotency key? The caller must, and pass it along — a server-generated key cannot stay stable across retries.

  答题要点

  • 拆成两个问题：计费是记账问题，工具副作用是执行问题，解法不同
  • 计费按服务端实际产生的 token 记，用 run id 加序号去重，避免同一批 token 重复入账
  • 有副作用的工具用幂等键：由调用参数派生稳定 key，执行前先查是否已有结果
  • 把每次工具调用记成待执行/执行中/已完成的状态机，重试只重放未完成的部分
  • 幂等键要由调用方生成并随请求传递，服务端自行生成无法跨重试保持一致

  Key points

  • Separate billing (bookkeeping) from tool side effects (execution); they need different mechanisms
  • Meter by tokens actually produced, deduped by run id plus sequence so one batch is never counted twice
  • Guard side-effecting tools with an idempotency key derived from the call arguments
  • Model each tool call as pending / running / done and replay only unfinished work
  • The caller must generate and pass the idempotency key so it stays stable across retries