面试题库

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

D26 系统设计专题：Agent 平台 / 客服 Agent / 多租户 / 成本控制

• 一个多租户的 Agent 服务，数据隔离和计费隔离要怎么设计？什么时候该从共享表升级到独立库？For a multi-tenant agent service, how do you design data isolation and billing isolation, and when do you move from a shared table to a dedicated database per tenant?

  国内高频海外高频进阶#system-design#multi-tenancy#isolation

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

  1. 这题的题眼在「隔离」是复数。只答数据隔离的候选人非常多，而多租户翻车最多的其实是资源那一层——一个租户的洪峰打穿别人的处理能力，数据一条都没串，用户照样投诉。所以第一句先把三层摆出来：数据、资源、计费，缺哪一层对应一类事故。
  2. 数据这一层，判断一个人有没有真做过就看一句话：他说「每条查询都带 tenant_id」还是「靠数据库的行级安全兜底」。前者迟早会漏一处，而漏掉的那处通常是最新加、最没被测过的功能。正确说法是行级安全是闸门，应用层那句 where 只是优化——这和幂等的最终裁判必须是数据库唯一约束，是同一种思路：能在数据层强制的，不要指望每个人写代码时都记得。
  3. 资源这一层给两件具体的东西：每个租户一个独立限流桶，以及 worker 按租户标识哈希分片。分片这一招和「按用户哈希保住同一用户顺序」是同一套机制，只是哈希的输入换了，目的从保序变成隔离洪峰。Agent 场景里噪声邻居格外突出，因为单次执行可能跑三十秒，一个租户灌一千条进来，别人就得排队。
  4. 计费这一层最简单也最容易漏：token 用量台账加一列租户标识，写入时打标。账单、配额、超支降级三件事全靠它。顺带说一句成本口径——单轮 2000 输入加 500 输出约 0.0006 美元，日活 1 万人均 5 轮约每月 900 美元，能报出这个量级说明你真的算过每租户成本。
  5. 然后回答升级判据，这是本题的第二个区分点。三档是共享表加租户列、schema 级、库级；**判据不是租户数量，是「有没有单个租户能把别人拖垮」和「有没有合规硬要求」**。答「超过一百个租户就该分库」是典型的凭感觉，因为一百个小租户共享一张表毫无问题，而一个受监管的大客户哪怕只有一个也可能必须物理隔离。代价要一起说：库级隔离看着干净，但迁移脚本、备份、监控、连接池全部乘以租户数，运维成本是陡增不是线性。
  6. 可以预期的追问，也是最见功力的一问：幂等键在多租户下要不要变？答案是键的算法不用变，但**作用域必须带上租户标识**。不带的话两个租户的客户端各自生成了同一个字符串（都用订单号 order-1024），后来那个会被唯一约束当成重复请求挡掉——一个租户的写入被另一个租户的历史请求吞掉，两边日志都完全正常，是多租户里最难查的一类 bug。

  How to reason about it · think before answering

  1. The hinge is that 'isolation' is plural. Plenty of candidates answer only data isolation, but the layer that actually breaks in production is resources: one tenant's spike starves everyone else, no rows leak, and users still complain. Open with all three — data, resources, billing — and note that each missing layer maps to its own class of incident.
  2. On data, one sentence separates people who shipped this from people who read about it: 'every query carries tenant_id' versus 'row-level security is the backstop'. The first eventually misses a query, and the one it misses is always the newest, least-tested feature. The correct framing is that RLS is the gate and the application-level where clause is just an optimisation — the same reasoning as idempotency being adjudicated by a database unique constraint. Whatever the data layer can enforce should not depend on everyone remembering.
  3. On resources, give two concrete things: a rate-limit bucket per tenant, and workers sharded by a hash of the tenant id. That is the same sharding mechanism used to preserve per-user ordering, with a different hash input and a different purpose — containing spikes rather than serialising. Noisy neighbours hurt more in agent workloads because a single execution can run thirty seconds, so a thousand queued items from one tenant leaves everyone else waiting.
  4. Billing is the simplest and the most often forgotten: add a tenant column to the token usage ledger and tag every write. Invoicing, quotas and over-budget degradation all hang off it. Bring the cost figures too — roughly $0.0006 per turn at 2000 in and 500 out, about $900 a month at 10k daily actives and five turns each — because quoting per-tenant economics shows you actually ran the numbers.
  5. Then the escalation criteria, the second discriminator. Three tiers: shared table with a tenant column, schema per tenant, database per tenant. The trigger is not tenant count, it is whether a single tenant can starve the rest and whether there is a hard compliance requirement. 'Split the database past a hundred tenants' is guesswork: a hundred small tenants share a table happily, while one regulated enterprise customer may require physical separation on its own. State the cost too — a database per tenant looks clean, but migrations, backups, monitoring and connection pools all multiply by tenant count, so operational cost jumps rather than scaling linearly.
  6. Expect the sharpest follow-up: does the idempotency key change under multi-tenancy? The algorithm does not, but its scope must include the tenant id. Without it, two tenants whose clients independently produce the same string — both using order id order-1024 — collide, and the later request is rejected by the unique constraint as a duplicate. One tenant's write is swallowed by another tenant's history, both logs look perfectly normal, and it is the hardest class of multi-tenant bug to find.

  答题要点

  • 三层隔离并列，缺一层对应一类事故：数据、资源、计费
  • 数据靠行级安全兜底，应用层的 where 只是优化——能在数据层强制的不要靠人记得
  • 资源是每租户独立限流桶加按租户标识哈希分片，防的是噪声邻居而不是数据串
  • 计费是台账加一列租户标识，账单、配额、超支降级全靠它
  • 升级到 schema 级或库级的判据是「单租户能否拖垮别人」与「有没有合规硬要求」，不是租户数量
  • 库级隔离的代价是迁移、备份、监控、连接池全部乘以租户数，运维成本陡增
  • 幂等键算法不变，但作用域必须带租户标识，否则两个租户的同名键会互相挡掉请求

  Key points

  • Three parallel layers, each missing one causing its own class of incident: data, resources, billing
  • Data isolation is backstopped by row-level security; the application where clause is only an optimisation
  • Resource isolation is a per-tenant rate-limit bucket plus sharding workers by tenant hash, aimed at noisy neighbours
  • Billing isolation is a tenant column on the usage ledger, powering invoices, quotas and degradation
  • Escalate to schema or database isolation based on starvation risk and compliance mandates, not tenant count
  • Per-tenant databases multiply migrations, backups, monitoring and connection pools — operational cost jumps
  • The idempotency key algorithm stays, but its scope must include the tenant id or identical keys across tenants collide
• 一个 Agent 系统的模型成本失控了，你会从哪几个层面着手控制？每一层大概能省多少？An agent system's model spend is out of control. Which levers do you pull, in what order, and roughly how much does each save?

  国内高频海外高频进阶#system-design#cost#capacity-planning

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

  1. 这题最容易脱口而出的答案是「换个便宜模型」，也是最容易被追死的答案——面试官紧跟着就问「你怎么知道换了质量不掉」，答不出离线评估集和对比实验就露馅了。正确的第一句是「先看台账」：按用户、按天、按模型各切一刀，找出是哪一维在涨。先定位再动手，这是工程习惯。
  2. 第二步是把基准摆到桌上，没有基准的成本讨论全是废话。单轮 2000 输入加 500 输出，输入 2000 除以一百万乘 0.15 等于 0.0003 美元，输出 500 除以一百万乘 0.60 也等于 0.0003 美元，一轮约 0.0006 美元；日活 1 万、人均 5 轮就是 5 万轮，一天约 30 美元、一个月约 900 美元。
  3. 然后给五层，排序的依据是**你要付出的代价从小到大**，不是省钱多少：缓存与 prompt cache、模型分级路由、上下文压缩、步数与工具预算上限、限流与降级。这个顺序本身就是答案的一部分，因为它同时说明了你的落地顺序。
  4. 每层配一个从基准推出来的数字。缓存按一成半命中估，900 降到 765 左右。分级路由要诚实说清前提：它是唯一能改数量级的一层，但前提是你的基准用的是旗舰模型；基准已经是最便宜那档时这一层榨不出东西——主动说破这一条，比硬编一个省钱比例可信得多。上下文压缩把输入从 2000 压到 1200，单轮变成 0.00048 美元，一个月 720 美元，降两成。
  5. 第四层最容易被讲成「省钱」，其实它买的是**可预测**：给每个子任务设 5 次工具调用上限之后，单轮成本才有上界——调满 5 次、每次结果回灌 800 token，输入涨到 6000，单轮 0.0012 美元，正好是基准的两倍；没有上限时这个数字没有上界。这一层的正确说法是「我不是靠它省钱，我是靠它让账单可以被预测」。
  6. 第五层是限流与降级，代价最大所以放最后：900 美元摊到 1 万日活是每人每月 0.09 美元，给单用户设 1 美元硬顶，正常用户碰不到，挡的是脚本刷接口那种极端户。要点是超预算先降档再拒绝，而不是直接拒绝——它是五层里唯一用户能感觉到的一层。
  7. 可以预期的追问：这五层里哪一层最先做？答「第一层和第三层」，因为它们只改自己的代码、不动产品承诺、也不需要重新验证质量；而分级路由要配离线评估集，限流要配产品沟通，都不是当天能上的。

  How to reason about it · think before answering

  1. The reflex answer is 'switch to a cheaper model', and it is also the easiest one to get killed on: the follow-up is 'how do you know quality did not drop', and without an offline eval set and a comparison run you are exposed. The right opening is 'look at the ledger first' — slice by user, by day and by model to find which dimension is growing. Locate before you act.
  2. Second, put the baseline on the table, because cost talk without a baseline is noise. At 2000 input and 500 output tokens per turn, input is 2000 over a million times $0.15 which is $0.0003, output is 500 over a million times $0.60 which is also $0.0003, so about $0.0006 per turn. 10k daily actives at five turns is 50k turns, roughly $30 a day and $900 a month.
  3. Then give five layers ordered by the cost you pay, not by the savings: caching and prompt caching, tiered model routing, context compression, step and tool budget caps, rate limiting and degradation. The ordering is part of the answer, because it also communicates your rollout sequence.
  4. Attach a number derived from the baseline to each layer. Caching at a 15% hit rate takes $900 to roughly $765. For tiered routing, state the precondition honestly: it is the only layer that can change the order of magnitude, but only if your baseline runs a flagship model — if you already run the cheapest tier there is nothing left to squeeze. Saying that out loud is far more credible than inventing a savings percentage. Compression takes input from 2000 to 1200 tokens, so $0.00048 per turn, about $720 a month, a 20% cut.
  5. Layer four is usually mis-sold as savings; what it actually buys is predictability. With a cap of five tool calls per subtask, per-turn cost finally has a ceiling: five calls each feeding back 800 tokens pushes input to 6000, so $0.0012 per turn, exactly double the baseline — and with no cap there is no ceiling at all. The right phrasing is 'this does not save money, it makes the bill predictable'.
  6. Layer five is rate limiting and degradation, last because it costs the most: $900 across 10k daily actives is about $0.09 per user per month, so a $1 monthly hard cap is invisible to real users and only stops scripted abuse. The nuance is degrade before refusing — this is the only layer users can feel.
  7. Expect the follow-up: which layer first? Say layers one and three, because they only touch your own code, change no product promise, and need no quality re-validation, whereas tiered routing needs an eval set and rate limiting needs product buy-in.

  答题要点

  • 第一句不是「换便宜模型」，是「先看台账」：按用户、按天、按模型各切一刀定位是哪一维在涨
  • 先立基准：单轮约 0.0006 美元，日活 1 万人均 5 轮约每天 30 美元、每月 900 美元
  • 五层按代价从小到大：缓存与 prompt cache、模型分级路由、上下文压缩、步数与工具预算上限、限流与降级
  • 分级路由是唯一能改数量级的一层，但前提是基准用的是旗舰模型；基准已经最便宜时要诚实说没得省
  • 上下文压缩把输入从 2000 压到 1200，单轮 0.00048 美元、每月 720 美元，降两成
  • 工具预算上限买的是可预测：有上限时单轮上界是 0.0012 美元，没上限时没有上界
  • 限流降级放最后，因为它是唯一用户能感觉到的一层；超预算先降档再拒绝

  Key points

  • Open with 'look at the ledger', not 'use a cheaper model': slice by user, by day and by model to locate the growth
  • Set a baseline: about $0.0006 per turn, roughly $30/day and $900/month at 10k DAU and five turns
  • Five layers ordered by cost to you: caching and prompt cache, tiered routing, context compression, step and tool budget caps, rate limiting and degradation
  • Tiered routing is the only order-of-magnitude lever, but only if the baseline is a flagship model — say so when it is not
  • Compression from 2000 to 1200 input tokens gives $0.00048 per turn, about $720/month, a 20% cut
  • Tool budget caps buy predictability: with a cap the per-turn ceiling is $0.0012, without one there is no ceiling
  • Rate limiting comes last because users feel it; degrade before refusing