面试题库

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

D12 长期记忆：pgvector、embedding、chunking、memory_search 工具

• 为什么 Agent 需要额外的长期记忆，而不是把历史全部塞进上下文？Why does an agent need a separate long-term memory instead of stuffing all history into the context window?

  国内高频海外高频基础#long-term-memory#rag#cost

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

  1. 这题最容易答成「因为窗口装不下」。那只答对了一半，而且是不值钱的那一半——窗口一年比一年大，光靠这条理由，面试官会追问「等窗口到一百万 token 呢」，你就没词了。
  2. 先把两个问题拆开：上下文压缩解决的是「同一次会话里这一轮塞不下」，长期记忆解决的是「上个月说过的事想不起来」。前者在组装请求时做减法，后者做加法，触发时机、数据去向、失败后果都不同。能主动区分这两件事，是这题最大的区分度。
  3. 然后给成本账：200 条记忆、每条约 400 token 就是 8 万 token，按输入价 0.15 美元每百万 token 算，每一轮多付 0.012 美元；一天 20 轮就是 0.24 美元一个用户。只检索最相关的 5 条是 2000 token、每轮 0.0003 美元，差 40 倍。而且这笔钱是每轮重复付的，不是一次性的。
  4. 再给比钱更硬的理由：无关信息会降低命中率。200 条里跟这一轮相关的可能只有 1 条，剩下 199 条是噪声，模型会被带偏去回答一个用户没问的问题。**所以哪怕窗口无限大、token 免费，也该检索而不是全塞。** 这一句是这题的最优解。
  5. 落到做法上：把跨会话的用户事实与偏好抽成陈述句存进向量库，每轮按语义检索最相关的三五条注入请求——这就是 RAG 最小的一环。
  6. 可以预期的追问：什么信息该进长期记忆？答三问——跨会话之后还需要吗、会不会随时间失效、能不能靠检索捞回来。「用户住上海」三条都满足，「把刚才那段改成三句话」一条都不满足。

  How to reason about it · think before answering

  1. The tempting answer is 'the window is too small'. That is half right and it is the cheap half — windows keep growing, and the interviewer will ask what you would do at a million tokens.
  2. Separate the two problems first: context compression solves 'this turn does not fit in one session', long-term memory solves 'I cannot recall what was said last month'. One subtracts at request-assembly time, the other adds. Naming that distinction unprompted is where the signal is.
  3. Then quantify: 200 memories at roughly 400 tokens each is 80k tokens; at 0.15 USD per million input tokens that is 0.012 USD every single turn, about 0.24 USD per user per day at 20 turns. Retrieving the top 5 is 2k tokens, 0.0003 USD per turn — a 40x gap, and it repeats every turn.
  4. Give the reason that beats cost: irrelevant context lowers accuracy. If one of 200 memories is relevant, the other 199 are noise that pull the model toward answering something nobody asked. So even with an infinite free window, you would still retrieve rather than dump.
  5. Land on practice: distil cross-session user facts and preferences into standalone statements, store them as vectors, and inject the three to five most relevant per turn — the minimal form of RAG.
  6. Expect the follow-up: what belongs in long-term memory? Three tests — is it still needed across sessions, does it expire, can retrieval find it again. 'Lives in Shanghai' passes all three; 'shorten that paragraph' passes none.

  答题要点

  • 压缩管「这一轮塞不下」，长期记忆管「上个月说过的事想不起来」，是两个问题、两套机制
  • 全塞的成本是每轮重复付的：200 条约 8 万 token，每轮多 0.012 美元；检索 5 条只要 0.0003 美元
  • 更硬的理由是准确率：无关记忆是噪声，会把模型带偏，所以窗口再大也该检索而不是全塞
  • 做法是把跨会话的事实抽成陈述句、向量化存储，每轮按语义检索最相关的三五条注入
  • 判断一条信息该不该进长期记忆：跨会话还需要吗、会不会失效、能不能被检索到

  Key points

  • Compression handles 'this turn does not fit'; long-term memory handles 'what did they say last month' — different problems, different machinery
  • Dumping everything costs on every turn: 200 memories is about 80k tokens and 0.012 USD per turn versus 0.0003 USD for five retrieved ones
  • The stronger reason is accuracy — irrelevant memories are noise, so you would retrieve even with an infinite window
  • Practice: distil cross-session facts into statements, embed them, inject the top three to five per turn
  • Admission test for a memory: still needed across sessions, does not expire, and is findable by retrieval

D13 cron 调度（中心调度→stream 投递）+ 成本计量（token→USD 台账、usage report）

• 服务部署了多个实例，定时任务为什么不能让每个实例各自起一个 cron？你会怎么做？When a service runs multiple replicas, why not let each replica start its own cron? What would you do instead?

  国内高频海外高频基础#scheduling#distributed-systems#cost

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

  1. 题眼在「多个实例」四个字。只答「会重复执行」拿不到分，因为那是现象；面试官想看你能不能把现象换算成业务后果和钱。
  2. 先把重复的代价说具体：3 个副本各起 cron，同一个任务被执行 3 次，用户收到 3 份一样的推送，你付 3 份模型调用的钱。而且这个倍数会跟着副本数走——扩容到 10 个副本，账单和骚扰量一起变成十倍，却不会触发任何告警，因为从每个进程自己的视角看它只是老实地执行了一次。
  3. 然后给出正确的形状：把「谁该在什么时候被执行」收进一个中心调度器，它命中 cron 之后只做一件事——往消息总线投递一条任务消息；执行侧照旧靠消费组分摊，一条消息只会被一个消费者拿到。关键认知是「定时任务不是一种新的执行方式，只是把按按钮的人从用户换成了钟表」，所以执行侧一行代码都不用改。
  4. 接着主动补上「那调度器自己不就成单点了吗」——这是必被追问的一句。答案分两层：调度器无状态、崩了拉起来就行，短暂不可用的代价只是几分钟内的任务延迟；真要高可用就起两个实例，靠投递时的幂等键去重，而不是靠给调度器加分布式锁。
  5. 最后点一句选型：任务量不大时中心调度器加消息总线足够；量大或者任务本身有依赖关系时，业界会换成专门的调度框架（带任务依赖、重试策略、补数），但底层的「中心决定 + 队列分发」结构是一样的。
  6. 可以预期的追问：调度器崩溃 90 秒，中间跨过的那一分钟怎么办？答启动时回看最近 N 分钟逐分钟重放，因为有幂等键兜底，重复投递无害——这正是 at-least-once 加幂等这组搭配能成立的地方。

  How to reason about it · think before answering

  1. The hinge is the phrase multiple replicas. Saying it would run twice is only the symptom; the interviewer wants the business and dollar consequence.
  2. Make the cost concrete: three replicas each running cron means the job fires three times, users get three identical pushes, and you pay for three model calls. The multiplier tracks replica count, so scaling to ten makes both the bill and the spam tenfold, with no alert firing, because from each process's own point of view it ran exactly once.
  3. Give the right shape: move the decision of who runs when into one central scheduler whose only job, on a cron match, is to publish a task message onto the bus; the execution side keeps using a consumer group so one message reaches exactly one consumer. The key insight is that a scheduled task is not a new execution path, it just swaps the user for a clock as the thing pressing the button, so the worker code stays untouched.
  4. Volunteer the obvious follow-up: doesn't the scheduler become a single point of failure? Two layers. It is stateless, so a crash costs you a few minutes of task delay; if you truly need HA, run two instances and dedupe on the idempotency key at publish time rather than bolting a distributed lock onto the scheduler.
  5. Close with sizing: a central scheduler plus a bus is enough at modest volume. At high volume, or when tasks have dependencies, teams move to a dedicated workflow scheduler with dependency graphs, retry policy and backfill, but the underlying central-decision-plus-queue shape is identical.
  6. Expect: the scheduler was down for 90 seconds and skipped a minute — now what? Replay the last N minutes on startup, one minute at a time. The idempotency key makes redundant publishes harmless, which is exactly what makes at-least-once plus idempotency the easy combination.

  答题要点

  • 每个实例各自起 cron 等于同一个任务被执行 N 次：用户收到 N 份重复推送，模型调用花 N 倍的钱，倍数随副本数线性增长且不会触发告警
  • 正确形状是中心调度器命中 cron 后只往消息总线投递一条消息，执行侧靠消费组保证一条消息只被一个 Worker 拿到
  • 定时任务不是新的执行路径，只是把触发者从用户换成了钟表，所以 Worker 侧不需要任何改动
  • 调度器是无状态的，崩了拉起来即可；需要高可用就起两个实例靠投递时的幂等键去重，不要给它加分布式锁
  • 崩溃期间跨过的时间点靠启动时回看最近 N 分钟重放补上，幂等键保证重复投递无害

  Key points

  • Per-replica cron means the job runs N times: N duplicate pushes, N times the model spend, scaling linearly with replica count and silently
  • The right shape is a central scheduler that publishes one message to the bus on a cron match, with a consumer group ensuring exactly one worker picks it up
  • A scheduled task is not a new execution path — only the trigger changed from a user to a clock, so worker code is unchanged
  • The scheduler is stateless: restart on crash, and if you need HA run two and dedupe on the idempotency key rather than adding a distributed lock
  • Missed minutes are recovered by replaying the last N minutes at startup, which is safe because the idempotency key absorbs duplicates