面试题库

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

D17 Planner–Executor–Critic + 共享工作区：workspace state、toolBudget、并行 fan-out、review 回路

• 多个子任务并行执行、都要写同一份共享状态时，怎么设计才不会互相覆盖？When several subtasks run in parallel and all write the same shared state, how do you design it so they do not clobber each other?

  国内高频海外高频深入#multi-agent#state-management#concurrency

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

  1. 这题的区分度极高，因为大多数人会答成「加锁」或者「用不可变数据结构」——都是从多线程经验迁移过来的答案，但图的执行模型里根本没有并发写内存这回事，写入是被收集起来统一合并的。答错方向比答不全更致命。
  2. 先把机制说对：并行节点各自返回一份增量，框架把同一轮里所有增量按字段收集，再逐字段调用这个字段的合并规则（reducer）算出新值。所以问题不是「怎么加锁」，而是**这个字段的合并规则写得对不对**。
  3. 然后给一条可复用的判断链：先问这个字段同一轮会被几个人写；再问他们写的是不是同一条记录。只有一个写者，默认的后写覆盖就够；多个写者写不同记录，数组追加就够；多个写者写同一条记录的同一份数据，要按主键原地更新；多个写者写同一条记录的不同字段，要做字段级合并。四种情况四种 reducer，这条链能直接迁移到任何框架。
  4. 结论落在最容易踩的那一格：把「更新一条记录」写成「往数组里追加一条同 id 的新版本」。它的症状不是报错，是同一个 id 在状态里有两份、而且哪份在前取决于谁先跑完——下游任何按 id 查的地方都可能拿到过期版本，日志干净、结果偶尔错。
  5. 补一句权衡：也可以不动 reducer，改成每处读状态前先按 id 去重。但读取点有三四处，漏一处就是一个偶发脏读；reducer 只写一次，之后所有读取点自动干净。在字段上解决一次，还是在每个读取点解决 N 次，这是同一个问题的两种成本。
  6. 可以预期的追问：那顺序不确定要不要紧？答：合并规则最好对顺序不敏感（可交换），做不到就必须保证每条记录只有一个写者。本课的按 id 原地更新属于后者——它是最后写入者获胜，靠「一轮里一条记录只有一个执行者」这个前提才安全。

  How to reason about it · think before answering

  1. This one separates people fast, because most candidates answer locks or immutable data structures — instincts carried over from threads. A graph runtime has no concurrent memory writes at all: updates are collected and merged. Answering in the wrong frame is worse than answering incompletely.
  2. Get the mechanism right first: parallel nodes each return a delta, the runtime groups all deltas from the same step by field, then calls that field's reducer to compute the new value. So the question is not how to lock, it is whether that field's reducer is correct.
  3. Then give a reusable chain: how many writers touch this field in one step, and do they write the same record? One writer — last-write-wins is fine. Several writers on different records — appending to a list is fine. Several writers on the same record — upsert by key. Several writers on different fields of the same record — merge per field. Four cases, four reducers, and the chain transfers to any framework.
  4. Land on the common mistake: implementing update this record as append a new version with the same id. The symptom is not an error — the same id exists twice and which one comes first depends on who finished first, so any lookup by id may return the stale version. Clean logs, occasionally wrong results.
  5. Add the trade-off: you can leave the reducer alone and dedupe by id at every read instead. But there are three or four read sites, and missing one is an intermittent stale read; a reducer is written once and every read is clean afterwards. Solve it once on the field, or N times at the read sites.
  6. Expect: does nondeterministic ordering matter? Ideally the reducer is order-insensitive (commutative); if it is not, you must guarantee one writer per record. Upsert-by-id is the latter — it is last-write-wins and is safe only because each record has exactly one executor per round.

  答题要点

  • 图的执行模型里没有并发写内存：节点各返回增量，框架按字段收集后调用该字段的 reducer 合并，所以问题是 reducer 写得对不对，不是加不加锁
  • 判断链：同一轮几个写者、写的是不是同一条记录——单写者用覆盖、多写者写不同记录用追加、多写者写同一条记录用按主键原地更新、写同一条记录的不同字段要字段级合并
  • 最常见的错是把「更新」写成「追加同 id 的新版本」，症状是同 id 两份、顺序取决于谁先跑完、按 id 查会拿到过期版本，而且全程不报错
  • 另一条路是每处读取前手动去重，但读取点有好几处，漏一处就是偶发脏读；reducer 只写一次就一劳永逸
  • 合并规则最好对顺序不敏感；做不到就必须保证一轮里一条记录只有一个写者

  Key points

  • A graph runtime has no concurrent memory writes: nodes return deltas, the runtime groups them per field and calls that field's reducer — so the answer is a correct reducer, not a lock
  • Decision chain: how many writers per step, and same record or not — overwrite, append, upsert by key, or per-field merge
  • The classic bug is implementing update as append-a-new-version-with-the-same-id: two entries per id, order depends on who finished first, lookups return stale data, and nothing ever errors
  • The alternative is deduping at every read site, but there are several and missing one gives an intermittent stale read; a reducer is written once
  • Prefer an order-insensitive reducer; if it is not, guarantee exactly one writer per record per step

D29 弱项补强 + 编码热身：rate limiter、LRU、并发控制、流式 JSON 解析

• 限流器有哪几种常见算法？各自的优缺点是什么？如果只能落地一种，你选哪个？What are the common rate limiting algorithms, what are their trade-offs, and which one would you actually ship?

  国内高频海外高频基础#rate-limiting#concurrency

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

  1. 这题在考「你知不知道限流有多种语义」，而不是「你会不会写计数器」。只答出一种算法的人，会被默认没做过真正的流量治理。
  2. 先把四种按复杂度排开再逐个给弱点：固定窗口最省内存但有边界双倍；滑动窗口日志最精确但内存和请求数同阶；滑动窗口计数是近似解、内存回到常数；令牌桶允许突发、内存常数。这个排列顺序本身就是答案的骨架。
  3. 边界双倍要用具体数字讲，它是本题最常见的追问：限每分钟 100 次，用户在 12:00:59 打满 100 次，12:01:00 计数器清零又能打 100 次，跨边界的这 2 秒实际放行了 200 次。说不出这个例子，等于没答第一问。
  4. 结论选令牌桶，理由要落在业务形状上：真实流量本来就是突发的，令牌桶同时约束了长期速率（补充速度）和瞬时突发（桶容量），两个旋钮分别对应两个业务问题。实现上必须是惰性补充——取的时候按时间差现算，不要给每个用户起一个定时器，十万用户就是十万个定时器。
  5. 生产视角：单机内存版只在单实例下成立。多个网关实例共享配额时，「读余额 → 算补充 → 写回」三步之间一定有竞态，两个实例都读到「还剩 1 个」就会双双放行。修法是把三步塞进一段 Redis Lua 脚本，靠单线程执行整段脚本拿到原子性——用 Lua 不是为了快，是为了把三条命令粘成一条。
  6. 可以预期的追问：脚本里为什么不直接取当前时间？因为那会让脚本变得不确定，时间戳应该由调用方传进来；代价是各实例的时钟要大致对齐，这个取舍要主动说出口。

  How to reason about it · think before answering

  1. This question tests whether you know rate limiting has several distinct semantics, not whether you can write a counter. Naming only one algorithm reads as never having run real traffic.
  2. Lay the four out by complexity and attach a weakness to each: fixed window is cheapest but has the boundary burst; sliding window log is exact but its memory grows with request count; sliding window counter is an approximation with constant memory; token bucket allows bursts with constant memory. That ordering is the skeleton of a good answer.
  3. Make the boundary burst concrete, because it is the standard follow-up: with a 100-per-minute limit, a client can spend 100 at 12:00:59 and another 100 the instant the counter resets at 12:01:00 — 200 requests inside two seconds, double the quota.
  4. Pick the token bucket and justify it by traffic shape: real traffic is bursty, and the bucket gives you two independent knobs — refill rate caps the long-run rate, capacity caps the burst. Implement it with lazy refill: compute the top-up from the elapsed time when a token is requested, never run a timer per user.
  5. Production angle: the in-memory version only holds for a single instance. Across gateway replicas, read-compute-write has a race and two replicas can both see 'one token left' and both allow. Fix it with a Redis Lua script so refill and deduction happen in one atomic step — Lua is not for speed here, it is for gluing three commands into one.
  6. Expect the follow-up: why not read the clock inside the script? Because that makes the script non-deterministic. Pass the timestamp in from the caller, and say the cost out loud — replica clocks now have to be roughly aligned.

  答题要点

  • 四种算法：固定窗口（省内存但边界双倍）、滑动窗口日志（精确但内存与请求数同阶）、滑动窗口计数（近似、常数内存）、令牌桶（允许突发、常数内存）
  • 固定窗口的边界双倍：跨窗口交界的 2 秒内可以放行两倍配额，下游是数据库或模型 API 时足以打穿
  • 落地选令牌桶：补充速度管长期速率、桶容量管瞬时突发，两个旋钮对应两个真实业务约束
  • 必须用惰性补充：取令牌时按时间差现算，不要为每个 key 起定时器
  • 分布式版把补充与扣减写进一段 Redis Lua 脚本，先 GET 再 SET 一定有竞态；时间戳由调用方传入以保持脚本确定性

  Key points

  • Four algorithms: fixed window (cheap, boundary burst), sliding window log (exact, memory grows with requests), sliding window counter (approximate, constant memory), token bucket (bursty, constant memory)
  • The fixed-window boundary burst lets twice the quota through in the two seconds around a window edge, which is enough to overload a database or model API
  • Ship the token bucket: refill rate bounds the long-run rate and capacity bounds the burst, two knobs for two real constraints
  • Use lazy refill — top up from elapsed time on access instead of running one timer per key
  • For the distributed version, put refill and deduction in one Redis Lua script; a GET followed by a SET always races. Pass the timestamp in to keep the script deterministic
• 怎么实现一个限制并发数的调度器？为什么不能直接用 Promise.all 或者 asyncio.gather？How would you build a scheduler that caps in-flight async tasks, and why is Promise.all or asyncio.gather not enough?

  国内高频海外高频进阶#concurrency#async

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

  1. 题眼在后半句。面试官在确认你分不分得清「等待一批任务」和「限制同时运行的任务数」——这两件事在 API 名字上很像，在语义上毫无关系。
  2. 先说破错误答案为什么错：把 500 个任务全部映射成 Promise 再一起 await，这段代码的并发度是 500。Promise 一被创建，它内部的请求就已经发出去了，await 只是在等结果；gather 和 CompletableFuture.allOf 是同一个坑的另外两种口音。
  3. 再给正确形状的两条路：固定数量的工人从同一个游标取任务（JS 的惯用法，槽位就是工人本身），或者用信号量挡在任务启动之前（Python 的 asyncio.Semaphore、Java 的 Semaphore）。Swift 要用 TaskGroup 自己开滑动窗口，先塞满 limit 个、每收一个结果补一个。
  4. 本题真正的失分点是槽位泄漏：acquire 之后必须在 finally 里 release，或者把错误在任务内部收敛成结果值。忘了这一步的代码在 happy path 上完全正常，只有下游开始报错时才会一点点变慢直到彻底卡死——这是最难查的那类 bug，因为症状出现在故障之后而不是之中。
  5. 落到 Agent 场景说收益：批量 embedding、并行工具调用、多路子任务都靠它。收益不只是「不打爆下游」，还有同时驻留的内存与并发度同阶而不是与任务数同阶。
  6. 可以预期的追问：如果任务本身还要重试呢？答案是重试要在槽位内部完成（占着槽位退避重试），否则重试风暴会绕过限流；再追一层就是给重试加抖动，避免所有失败任务在同一时刻一起回来。

  How to reason about it · think before answering

  1. The hinge is the second half. They are checking whether you separate 'await a batch' from 'cap how many run at once' — similar API names, unrelated semantics.
  2. Name the wrong answer first: mapping 500 items to promises and awaiting them together runs at concurrency 500. Creating the promise already fired the request; awaiting only collects results. gather and CompletableFuture.allOf are the same trap in other accents.
  3. Then give the two correct shapes: a fixed set of workers pulling from a shared cursor (the JS idiom, where a worker is the slot), or a semaphore gating task start (asyncio.Semaphore, java.util.concurrent.Semaphore). Swift needs a manual window over a TaskGroup — fill limit slots, then add one task per result received.
  4. The real failure mode is slot leakage: release must happen in a finally, or the error must be collapsed into a result value inside the task. Code that misses this looks perfect on the happy path and only degrades once the downstream starts failing, which makes it one of the hardest bugs to trace.
  5. Tie it to agents: batch embedding, parallel tool calls, fan-out subtasks. The benefit is not only sparing the downstream — peak memory now scales with the concurrency limit instead of the task count.
  6. Expect the follow-up: what if tasks retry? Retries must happen inside the slot, otherwise a retry storm bypasses the limiter entirely. One level deeper: add jitter so failed tasks do not all come back at the same instant.

  答题要点

  • Promise.all 与 asyncio.gather 只负责等待，任务在被创建的那一刻就已经启动了，并发度等于任务总数
  • 两种正确形状：固定数量的工人从共享游标取任务，或者用信号量挡在任务启动之前
  • 槽位必须在任何退出路径上归还：Java 写在 finally 里，Python 用 async with，Swift 把错误收敛成结果值，JS 在循环里 try 与 catch
  • 槽位泄漏的症状是「下游一开始报错就越来越慢直到卡死」，happy path 完全看不出来
  • 收益是同时驻留的内存与并发度同阶，而不是与任务总数同阶；重试要占着槽位做，并加抖动

  Key points

  • Promise.all and asyncio.gather only wait; the work started when each promise was created, so concurrency equals the task count
  • Two correct shapes: a fixed worker set pulling from a shared cursor, or a semaphore gating task start
  • The slot must be returned on every exit path — finally in Java, async with in Python, error-to-value inside a Swift task, try/catch inside the JS loop
  • A leaked slot shows up as gradual slowdown to a full stall once the downstream starts erroring, and is invisible on the happy path
  • The payoff is peak memory scaling with the concurrency limit rather than the task count; retries must stay inside the slot and carry jitter

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

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

• 多个任务共用一家厂商的额度，你会怎么设计限流？Many jobs share one vendor's quota. How would you design the rate limiting?

  国内高频海外高频进阶#rate-limiting#concurrency#scheduling

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

  1. 这题的题眼是「共用」两个字。只回答一个令牌桶算答了一半，面试官想听的是你按什么维度分桶、以及桶之外还需要什么。
  2. 先给维度：限流要按「厂商 + 接口类别」分桶，不能全局一个桶。同一家的图像和语音是两个独立的配额池，混在一起会让紧的那个把松的那个也拖住。
  3. 再给部件：一个桶不够，要两个。令牌桶管速率（一分钟发几次，数字是厂商定的），信号量管并发（同一时刻挂着几个，数字是你自己定的用来保护内存和钱包）。只有速率控制的话，快速返回的接口一分钟能发几百次；只有并发控制的话，二十个请求同时在飞会把内存挂满。
  4. 然后是关键的工程细节：拿许可的动作必须是非阻塞的。如果任务先被派出去、再在执行流里等令牌，工作槽会被一批低优先任务占死，优先级就静默失效了。正确结构是调度器派活之前先问闸门要许可，拿不到就跳过它去看下一个候选。
  5. 最后落到取值：并发上限不该按 CPU 核数定，这条线几乎没有本地计算，全在等网络；它该按「一次失败要重跑多少东西」和厂商配额来定。
  6. 可预期的追问是「桶的状态放哪」。单进程放内存就够；多进程要放 Redis，用一个原子脚本取令牌，否则每个进程各限各的，加起来照样超。

  How to reason about it · think before answering

  1. The hinge is the word shared. Naming a token bucket only answers half of it; the interviewer wants your bucketing dimension and what else sits around the bucket.
  2. Dimension first: bucket per vendor and per API family, never one global bucket. Image and speech quotas at the same vendor are separate pools, and merging them lets the tight one throttle the loose one.
  3. Then the parts: one bucket is not enough. A token bucket caps rate (calls per minute, a number the vendor sets); a semaphore caps concurrency (how many are in flight, a number you set to protect memory and spend). Rate alone lets a fast endpoint fire hundreds per minute; concurrency alone lets twenty downloads pile up.
  4. The engineering detail that decides everything: admission must be non-blocking. If a job is dispatched first and then waits for a token inside the worker, low-priority work pins every worker slot and priority silently stops working. Ask the gate before dispatch, and skip to the next candidate when it says no.
  5. Finally the numbers: concurrency should not track CPU cores, since this pipeline is almost all network wait. Derive it from vendor quota and from how much work one failure forces you to redo.
  6. Expected follow-up: where does bucket state live. In-memory is fine for one process; across processes it belongs in Redis behind an atomic token-take script, or each process limits itself and the sum still blows the quota.

  答题要点

  • 按「厂商 + 接口类别」分桶，一家的图像和语音各一道闸门。
  • 每道闸门两个部件：令牌桶控速率（厂商给的 RPM），信号量控并发（自己定的在飞上限）。
  • 准入必须非阻塞，拿不到许可就把任务留在队列里，绝不占着工作槽干等。
  • 先抢并发票再取令牌，顺序反了会白白扣掉配额。
  • 多进程部署时桶的状态要外置到 Redis，用原子操作取令牌。

  Key points

  • Bucket per vendor and per API family; image and speech at one vendor get separate gates.
  • Each gate has two parts: a token bucket for rate (the vendor's RPM) and a semaphore for in-flight concurrency (your own number).
  • Admission is non-blocking: if the gate says no, the job stays queued instead of holding a worker slot.
  • Take the concurrency slot before the token, or a rejected admission silently burns quota.
  • Across processes, move bucket state to Redis and take tokens atomically.