面试题库

14 天用 Agent 搭一条 AI 短剧生产线

D4 从分镜到镜头：图生视频、异步任务轮询与失败重试

• 让你实现一个异步生成任务的客户端，你会考虑哪些失败情况？You are asked to implement a client for an asynchronous generation task. Which failure cases would you cover?

  国内高频海外高频进阶#async-task#error-handling

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

  1. 这题的区分度不在代码，在你能列出多少种失败。只答「加个 try catch 和重试」的人，通常没在生产上跑过这类接口。
  2. 先把任务的形状说清楚，失败点才有地方挂：提交拿标识、轮询查状态、取件换地址、下载落盘，四步是四类不同的失败。
  3. 然后逐步列：提交阶段有限流、鉴权、参数无效、内容审核；轮询阶段有查询接口自己限流、状态一直不前进、任务返回失败终态；取件阶段有标识存在但取不到地址；下载阶段有地址过期、下到一半断流、写盘失败。
  4. 接着说横跨全程的两类：超时与进程重启。超时的关键在于它不是失败而是「不知道成没成」，必须先按幂等键查一遍再决定要不要重提；进程重启意味着内存里的任务标识没了，所以标识必须先落盘再发请求，否则你会有一批花了钱却找不回来的任务。
  5. 最后给一句能体现工程判断的话：这四步里只有下载是可以无脑重试的，其余每一步的重试都可能产生一次新的计费。
  6. 可以预期的追问：厂商提供回调了还需要轮询吗？需要。回调会因为服务重启、网络抖动、地址不可达而丢失，生产上的标准做法是回调为主、低频轮询兜底扫描长时间没有终态的任务。

  How to reason about it · think before answering

  1. The differentiator here is coverage, not code. Answering 'wrap it in try/catch and retry' usually means you have never run this kind of API in production.
  2. Describe the shape first so the failures have somewhere to hang: submit and get an id, poll for status, retrieve a URL, download to disk — four steps, four families of failure.
  3. Then enumerate: at submit, rate limiting, auth failure, invalid parameters, content moderation; at poll, the query endpoint rate limiting you, a status that never advances, or a terminal failure; at retrieve, a valid id that yields no URL; at download, an expired link, a stream cut halfway, a disk write error.
  4. Then the two that span the whole flow: timeout and process restart. A timeout is not a failure, it is 'I don't know' — you must look up the idempotency key before resubmitting. A restart means in-memory task ids are gone, so the id has to be persisted before or immediately after the request, or you will have paid-for tasks you can never reclaim.
  5. Close with a line that shows judgment: of the four steps, only the download is safely retryable on its own; a retry at any other step can create a new billable job.
  6. Expect the follow-up: if the vendor offers callbacks, do you still poll? Yes. Callbacks get lost to restarts, network blips and unreachable endpoints, so the standard is callback-first with a low-frequency sweep for tasks stuck without a terminal state.

  答题要点

  • 按四步拆失败：提交（限流、鉴权、参数无效、内容审核）、轮询（查询限流、状态停滞、终态失败）、取件（拿不到地址）、下载（地址过期、断流、写盘失败）
  • 超时不是失败而是状态未知，重试前必须先按幂等键查一遍已有产物，否则会为同一个任务付两次钱
  • 任务标识要及时落盘，进程重启后才能把在途任务认回来
  • 四步里只有下载可以无脑重试，其余每一步的重试都可能产生新的计费
  • 有回调也要保留低频兜底轮询，回调会丢

  Key points

  • Break failures down by the four steps: submit (rate limit, auth, invalid params, moderation), poll (query rate limit, stalled status, terminal failure), retrieve (no URL), download (expired link, cut stream, disk error)
  • A timeout means unknown, not failed: look up the idempotency key for an existing artifact before resubmitting, or you pay twice
  • Persist the task id promptly so in-flight tasks survive a process restart
  • Only the download is safely retryable on its own; retries at the other steps can create new billable jobs
  • Keep a low-frequency polling sweep even when callbacks exist, because callbacks get lost
• 生成类接口返回失败，你怎么判断该不该重试？重试几次之后该做什么？When a generation API returns a failure, how do you decide whether to retry, and what happens after the retries run out?

  国内高频海外高频深入#error-handling#retry#cost

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

  1. 这题的题眼是「判断」。按状态码首位数字一刀切是最常见的错误答案，因为生成类接口的业务错误码往往和 HTTP 状态码不在一个层面上——很多厂商的失败是 HTTP 200 加一个响应体里的业务码。
  2. 给一条可复用的判据，比背错误码表有用：问三个问题——等一等会不会好、改输入会不会好、还是必须叫人来。三个问题对应三种处置：退避重试、修请求、立刻告警。
  3. 落到具体：限流和服务端故障属于第一类，程序自己扛；参数无效与内容审核属于第二类，重试一万次都是同一个错，而且会挤占限流额度让真正该重试的排不上号；鉴权失败与余额不足属于第三类，重试只会延迟告警。
  4. 然后单独处理超时，这是最能体现经验的一条：超时不是失败，是状态未知，对方队列里那个任务可能还在跑甚至已经成了。所以超时之后不能直接重提，要先按幂等键查一遍已有产物。
  5. 重试用尽之后要做三件事，缺一不可：把这一条标成失败并记下最后一次的错误码与请求参数、继续跑批次里剩下的任务不要中断、把失败清单汇总成一次可读的告警而不是每条发一次。
  6. 可以预期的追问：重试次数怎么定？按单价定。单价越高，允许的重试次数越少，而且高单价的失败更应该先送人复核再决定要不要重做。

  How to reason about it · think before answering

  1. The hinge is 'decide'. Bucketing by the leading digit of the HTTP status is the classic wrong answer, because generation APIs often return HTTP 200 with a business error code in the body.
  2. Give a reusable test instead of reciting a code table: ask three questions — will waiting help, will changing the input help, or does a human have to step in? They map onto three dispositions: back off and retry, fix the request, alert immediately.
  3. Concretely: rate limits and server errors are the first bucket and the program handles them; invalid parameters and content moderation are the second, where retrying repeats the same error and burns rate-limit budget that genuinely retryable tasks needed; auth failure and insufficient balance are the third, where retrying only delays the alert.
  4. Handle timeout separately — this is the line that signals experience. A timeout is unknown, not failed: the job may still be running, or may have finished. So never resubmit blindly; look up the idempotency key for an existing artifact first.
  5. When retries are exhausted, do three things: mark the item failed with the last error code and the exact request parameters, keep processing the rest of the batch instead of aborting it, and aggregate the failures into one readable alert rather than one per item.
  6. Expect the follow-up: how many retries? Scale it by unit price. The more expensive the call, the fewer automatic retries, and expensive failures should go to a human for review before being redone.

  答题要点

  • 不要按状态码首位一刀切，生成类接口的业务错误码常常藏在 HTTP 200 的响应体里
  • 判据是三个问题：等一等会不会好、改输入会不会好、还是必须叫人来，分别对应退避重试、修请求、立刻告警
  • 限流与服务端故障可重试；参数无效与内容审核重试无用且会挤占限流额度；鉴权失败与余额不足必须告警
  • 超时是状态未知不是失败，重试前先按幂等键查一遍已有产物，否则会重复计费
  • 重试用尽后：标记失败并留下错误码与请求参数、不中断整批、把失败汇总成一次可读告警；重试次数按单价定

  Key points

  • Do not bucket by the leading HTTP digit; generation APIs often hide the business error code inside an HTTP 200 body
  • Use three questions — will waiting help, will changing the input help, or is a human required — mapping to back off, fix the request, alert
  • Rate limits and server errors are retryable; invalid parameters and moderation blocks are not and waste rate-limit budget; auth and balance failures need an alert
  • A timeout is unknown rather than failed: check the idempotency key for an existing artifact before resubmitting, or you pay twice
  • When retries run out, mark the item failed with its error code and request parameters, keep the batch running, and aggregate failures into one alert; scale retry counts by unit price

D7 一集杀青：把六个环节串成端到端流水线并算清第一笔账

• 一条多步骤的生成流水线，中间某一步失败了，你希望系统有什么行为？In a multi-step generation pipeline, one step fails. What behavior do you want the system to have?

  国内高频海外高频进阶#pipeline-reliability#idempotency#error-handling

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

  1. 这题的区分度在于你会不会分层回答。只说「重试」的人默认失败都是瞬时的；真正做过的人会先问一句：这次失败是可重试的还是不可重试的，因为这一条决定了后面所有动作。
  2. 先把行为拆成三层：立刻要做的、这一次运行要做的、下一次运行要做的。立刻要做的是错误分类与有界重试，只有限流、超时、五开头这类瞬时错误才值得退避重试，鉴权失败、余额不足、内容审核不通过重试一百次也是白烧钱。
  3. 这一次运行要做的是保住已经产生的价值：把已完成步骤的产物、耗时、花费全部落盘，包括失败那一步自己已经花掉的钱。一个直接向上抛的实现会把这些一起丢掉，而它们恰恰是复盘时最该看的。
  4. 下一次运行要做的是不重复花钱：每个节点算一个幂等键，产物按内容寻址落盘，重跑时先做一次差集，已完成的跳过、只补做没做完的。判据非常硬——第二次运行的付费接口调用次数应当是 0。
  5. 在生成式流水线里这一条比传统后端更要紧，因为单步成本高得离谱：本课量过一集的账，视频那一环占了全部花费的九成八，从头重跑一次就是白烧十块多，而且是必然的，不是偶然的。
  6. 可预期的追问是「幂等键里该放什么」。答：模型 id、提示词、时长分辨率这类会影响产物的输入，加上实现版本号和全部依赖的指纹；绝不能放运行标识、时间戳、随机数，放了就永远不命中。

  How to reason about it · think before answering

  1. The discriminator is whether you answer in layers. People who just say 'retry' assume all failures are transient. Anyone who has run one of these asks first: is this failure retryable, because that decides everything downstream.
  2. Split the behavior into three layers: what to do immediately, what to do for this run, and what to do for the next run. Immediately: classify the error and retry with bounds. Only rate limits, timeouts and 5xx deserve backoff; auth failures, insufficient balance and content-policy rejections will fail a hundred more times.
  3. For this run: preserve the value already produced. Persist artifacts, elapsed time and spend for every completed step, including the money the failing step itself already burned. An implementation that just rethrows loses exactly the data a post-mortem needs.
  4. For the next run: do not pay twice. Give every node an idempotency key, store artifacts content-addressed, and make a rerun a set difference — skip what is done, redo only what is not. The bar is hard: the second run should make zero paid API calls.
  5. This matters more in generative pipelines than in ordinary backends because per-step cost is extreme. Measured on one episode in this course, the video step is 98 percent of total spend, so a full rerun burns over ten yuan, predictably rather than occasionally.
  6. Expect the follow-up 'what goes into the idempotency key'. Answer: model id, prompt, duration and resolution — anything that changes the artifact — plus an implementation version and the fingerprints of all dependencies. Never the run id, a timestamp or a random value.

  答题要点

  • 先做错误分类：可重试的才退避重试，鉴权、余额、内容审核这类重试没有意义。
  • 失败时保住已完成步骤的产物、耗时与花费，失败那一步自己花的钱也要记。
  • 下一次运行靠幂等键与内容寻址的产物做差集，只补做没做完的部分。
  • 验收判据是第二次运行的付费接口调用次数为 0，而不是「日志里没报错」。
  • 生成式流水线单步成本极高，这一条的收益能直接换算成账单上的金额。

  Key points

  • Classify errors first: only retryable ones get backoff. Auth, balance and content-policy failures gain nothing from retries.
  • On failure, preserve completed steps' artifacts, timings and spend, including what the failing step itself already cost.
  • The next run uses idempotency keys and content-addressed artifacts to compute a set difference and redo only what is missing.
  • The acceptance bar is zero paid API calls on the second run, not 'no errors in the log'.
  • Per-step cost is extreme in generative pipelines, so this work converts directly into money on the bill.

D9 并发与配额：多集同时开机，还不能把厂商额度打爆

• 收到限流响应之后，除了退避重试还该做什么？Beyond backing off and retrying, what else should happen when you get rate limited?

  国内高频海外高频深入#rate-limiting#error-handling#retry

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

  1. 这题在考你有没有真在生产里被限流打过。只答「指数退避加抖动」是标准答案的前半段，面试官等的是后半段。
  2. 先把限流摆正位置：它不是错误，是信号。它告诉你此刻的发送速率超过了厂商愿意接受的速率。既然是信号，就该有反馈动作，而不只是重试。
  3. 第一个动作是主动降速：把令牌桶罚一档，接下来一两个窗口只发一半令牌。不降速的话，退避结束后你会用同样的速度再撞一次，重试次数越多越糟。
  4. 第二个动作是别在退避里占着执行流。正确做法是把任务重新入队并记一个「不早于」时间戳，槽位立刻还回去给别的任务。
  5. 第三个动作是分类：限流和服务端错误可以重试，鉴权失败、余额不足、参数错误、内容审核不通过一次都不该重试——重试只会让你在一分钟里把同一个错误犯五遍，还白占配额。MiniMax 这边 1002 是限流、1039 是 TPM 维度的限流，1004 鉴权、1008 余额、2013 参数、1026 和 1027 是内容审核。
  6. 第四个动作是把限流次数记进指标。撞得多说明闸门配小了或者配大了，这个数字是你回头调参数的唯一依据。
  7. 可预期的追问是「退避上限怎么定」。定在业务能等的时间上，超过就转降级：换更小的分辨率、更短的时长，或者干脆排到下一批。

  How to reason about it · think before answering

  1. This question separates people who have actually been throttled in production. Exponential backoff with jitter is only the first half of the answer.
  2. Frame it correctly: throttling is a signal, not an error. It says your current send rate exceeds what the vendor will accept right now, so it deserves a feedback action, not just a retry.
  3. Action one is to slow down on purpose: penalize the bucket so the next window or two issues half the tokens. Without that, you finish the backoff and hit the same wall at the same speed.
  4. Action two is to not hold an execution slot while waiting. Requeue the job with a not-before timestamp and hand the slot back immediately.
  5. Action three is classification. Throttling and server errors are retryable; auth failure, insufficient balance, invalid parameters and content-policy rejections are not, and retrying them just repeats one mistake five times while consuming quota. At MiniMax, 1002 is rate limiting and 1039 is the token-per-minute variant, while 1004 is auth, 1008 is balance, 2013 is bad parameters and 1026 or 1027 are content rejections.
  6. Action four is to record throttle counts as a metric. That number is the only evidence you have when you later retune the gate.
  7. Expected follow-up: how to cap the backoff. Cap it at what the business can wait for, then degrade instead of retrying: smaller resolution, shorter duration, or push the job into the next batch.

  答题要点

  • 把限流当信号：退避的同时给令牌桶降档，接下来的窗口只发一半令牌。
  • 退避期间把任务重新入队并记一个不早于时间戳，工作槽立刻还回去。
  • 退避要带抖动，否则同时被限的任务会同时醒来再撞一次。
  • 严格区分可重试与不可重试：鉴权、余额、参数、内容审核一次都不重试。
  • 把限流次数记成指标，它是回头调闸门参数的唯一依据；退避到上限就转降级而不是继续重试。

  Key points

  • Treat throttling as a signal: back off and also penalize the bucket so the next window issues fewer tokens.
  • Requeue with a not-before timestamp instead of sleeping inside the worker slot.
  • Add jitter, or everything throttled together wakes together and collides again.
  • Separate retryable from non-retryable: auth, balance, bad parameters and content rejections get zero retries.
  • Emit a throttle counter as a metric, and switch to degradation once backoff hits its ceiling.