面试题库

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

D8 为什么 Gateway/Worker 分离；Postgres 表设计（sessions/runs/messages）+ Drizzle

• 为什么生产级 Agent 服务通常要把 Gateway 和 Worker 拆开？什么情况下不该拆？Why do production agent services usually split a gateway from workers, and when should you not split?

  国内高频海外高频基础#architecture#scalability

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

  1. 题眼在后半句。只答「解耦、可扩展」是从架构书上抄来的，面试官想知道你有没有被某个具体现象逼着拆过——所以答案里必须出现「什么现象」和「不拆的代价」。
  2. 先给一条可复用的推导链：Agent 的一次执行是长耗时且时长不可预测的（模型响应加上多轮工具调用，几秒到几十秒），而接入层要承载全部流量、必须是毫秒级的短请求；把两种时长量级差三个数量级的工作放进同一个进程，慢的那一类必然会挤占快的那一类的资源。
  3. 把现象说具体：单进程时一台机器同时跑十几次长执行，连接与内存被占满，新来的健康检查开始超时，编排系统判定实例已死并重启它——正在跑的执行全部陪葬。这个「健康检查被自己的业务拖挂」的故事比任何抽象论证都有说服力。
  4. 然后给判据：能在 Worker 做的不放 Gateway，接入层只留鉴权、限流、落库、投递这四件耗时确定的事。拆开之后 Gateway 无状态可以任意扩缩，Worker 的并发度可以按模型配额单独调，两者的扩容曲线本来就不一样。
  5. 主动说代价，这是区分度所在：接口语义从 200 变成 202，客户端要多一次订阅往返；系统里多了一条总线和一张 runs 表，可观测性和排障链路都变长；本地开发要起更多进程。所以单次执行只有几百毫秒、没有工具调用、日活很小的场景不该拆——那时候拆分带来的复杂度远大于收益。
  6. 可以预期的追问：不拆但用线程池或者子进程行不行？答案是能缓解「挤占」但解决不了「重启即丢失」和「多实例状态不共享」，因为那两件事的根因是状态在进程里，不是并发模型不对。

  How to reason about it · think before answering

  1. The hinge is the second half. Answering only 'decoupling and scalability' sounds copied from a textbook; the interviewer wants to know which concrete symptom forced you to split, and what splitting costs.
  2. Offer a reusable chain: one agent run is long and unpredictable (model latency plus several tool calls, seconds to tens of seconds), while the ingress path carries all traffic and must stay in the millisecond range. Put workloads three orders of magnitude apart in the same process and the slow one starves the fast one.
  3. Make the symptom concrete: a single process running a dozen long executions saturates connections and memory, health checks start timing out, the orchestrator declares the instance dead and restarts it, and every in-flight run dies with it. That story lands harder than any abstract argument.
  4. Then state the rule: anything a worker can do should not live in the gateway, which keeps only auth, rate limiting, persistence and dispatch — four steps with bounded latency. After the split the stateless gateway scales with traffic while worker concurrency is tuned against model quota; the two curves were never the same.
  5. Volunteer the cost, which is where candidates separate: the contract becomes 202 instead of 200 so clients need a second subscribe round trip, you now operate a bus and a runs table, tracing spans more hops, and local development needs more processes. So do not split when a run takes a few hundred milliseconds, uses no tools, and serves modest traffic.
  6. Expect the follow-up: could a thread pool or child processes do instead? They ease starvation but fix neither 'restart loses in-flight work' nor 'two instances cannot see each other's state', because the root cause is state living inside the process, not the concurrency model.

  答题要点

  • 一次 Agent 执行是几秒到几十秒的长任务，接入层是毫秒级短请求，两者同进程时长任务必然挤占短请求的资源
  • 单进程的三个具体死法：重启丢掉在途执行、多实例状态各存各的、长执行把健康检查拖超时导致实例被误杀
  • 判据是「能在 Worker 做的不放 Gateway」，接入层只留鉴权、限流、落库、投递
  • 拆开后 Gateway 无状态按流量扩容、Worker 按模型配额扩容，两条曲线可以独立调
  • 代价是接口从 200 变 202、多一次订阅往返、排障链路变长；单次执行仅几百毫秒且无工具调用的场景不该拆

  Key points

  • A run takes seconds to tens of seconds while ingress requests are millisecond-scale; in one process the long work starves the short work
  • Three concrete failure modes: restarts lose in-flight runs, multiple instances hold separate state, and long runs stall health checks so the orchestrator kills a healthy instance
  • The rule is that anything a worker can do stays out of the gateway, which keeps only auth, rate limiting, persistence and dispatch
  • After splitting, gateways scale on traffic and workers scale on model quota — two independent curves
  • Costs: a 202 contract plus a subscribe round trip, an extra bus and table to operate, longer traces; skip the split for sub-second runs with no tool calls

D9 Redis Streams 消息总线：XADD/XREADGROUP/XACK/XAUTOCLAIM、consumer group、毒消息

• Redis Streams 和 Kafka 该怎么选？什么情况下 Streams 明显不够用？How do you choose between Redis Streams and Kafka, and when is Streams clearly not enough?

  国内高频海外高频进阶#message-bus#redis-streams#architecture

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

  1. 这题的坏答案是「看数据量」。吞吐从来不是第一判据——单机 Redis 每秒几万条 XADD 毫无压力，绝大多数业务的量级根本碰不到天花板。答成「量小用 Streams、量大用 Kafka」会被认为没做过选型。
  2. 换成两个真正的判据来推：一、这些消息需要保留多久；二、会不会有第二类消费方。生命周期是「执行一次就没用了」、且只有执行层这一个消费方，Streams 完全够用，还省掉一整套运维；需要「三个月内任意时间点重放」、或者同一份数据要同时喂给实时执行、离线数仓、风控三条链路，那就该上 Kafka。
  3. 再补三条结构性差异：Streams 是内存为主、保留全靠你自己 MAXLEN 或 XTRIM，Kafka 是磁盘顺序写、保留几周是常态；Streams 一个组里加多少消费者都行，Kafka 的消费者数受分区数限制，多了就有人空转；顺序保证的粒度不同，Streams 是单条流内有序而组内分配随机，Kafka 是同 key 落同分区、分区内有序。
  4. 然后主动说出那条最能体现深度的话：Redis 的持久化是有损的。AOF 默认每秒刷盘，最坏丢最后一秒的写入；主从异步复制，故障切换时未同步的消息会消失。所以用 Streams 时架构上必须有一个真相之源——本课是 Postgres 的 runs 表，流只是触发器，丢了消息那个 run 还停在 pending，补投任务会把它捡回来。把总线当唯一数据源是最危险的误用。
  5. 结论落成一句可复用的判断：Streams 适合「触发执行」，Kafka 适合「数据管道」。前者的消息是一次性的命令，后者的消息是需要被多方反复读取的事实。
  6. 可以预期的追问：那 RabbitMQ、SQS 呢？答：RabbitMQ 强在复杂路由和延迟队列（Streams 没有原生延迟投递，要自己带「下次可执行时间」重投）；SQS 强在零运维，代价是没有回放、也没有严格顺序（FIFO 队列另算）。把判据说成「保留时长、消费方数量、路由复杂度、运维预算」四条，比背产品参数强得多。

  How to reason about it · think before answering

  1. The bad answer is 'it depends on volume'. Throughput is never the first criterion — a single Redis node handles tens of thousands of XADDs per second, and most workloads never approach that ceiling. 'Small volume Streams, large volume Kafka' reads as never having run a real evaluation.
  2. Use two real criteria instead: how long the messages must be retained, and whether a second class of consumer will appear. If a message is useless once executed and the execution layer is the only consumer, Streams is plenty and saves an entire operational surface. If you need replay from any point in the last three months, or the same data must feed real-time execution, an offline warehouse and a risk engine, choose Kafka.
  3. Add three structural differences: Streams is memory-first with retention you enforce yourself via MAXLEN or XTRIM, while Kafka does sequential disk writes and keeps weeks by default; a Streams group takes any number of consumers, while Kafka consumers are capped by partition count and extras idle; ordering granularity differs — Streams orders a single stream but dispatches randomly within a group, Kafka pins a key to a partition and orders within it.
  4. Then volunteer the line that shows real depth: Redis persistence is lossy. AOF fsyncs once per second by default, so the last second of writes can vanish, and replication is asynchronous, so a failover can drop unreplicated messages. Using Streams therefore requires a source of truth elsewhere — here the Postgres runs table, with the stream acting only as a trigger; a lost message leaves the run pending and a sweeper republishes it. Treating the bus as the only datastore is the dangerous misuse.
  5. Land on a reusable rule: Streams suits triggering work, Kafka suits data pipelines. One carries one-shot commands, the other carries facts that many parties re-read.
  6. Expect: what about RabbitMQ or SQS? RabbitMQ wins on complex routing and delayed delivery (Streams has no native delay, you republish with a next-eligible timestamp); SQS wins on zero operations at the cost of replay and strict ordering (FIFO queues aside). Framing the criteria as retention, number of consumers, routing complexity and operational budget beats reciting product specs.

  答题要点

  • 第一判据不是吞吐，是「消息要保留多久」和「会不会有第二类消费方」
  • 只有执行层一个消费方、消息执行完即失效：Streams 够用，且大概率你已经有 Redis，零新增运维
  • 需要长期保留与任意时间点回放、或多条下游链路共用同一份数据：选 Kafka
  • 结构差异：Streams 内存为主、保留靠自己裁剪、组内分配随机；Kafka 磁盘顺序写、按 key 分区且分区内有序、消费者数受分区限制
  • Redis 持久化有损（AOF 每秒刷盘、异步复制），所以真相之源必须是数据库，流只当触发器，靠补投任务兜底
  • 一句话判断：Streams 适合触发执行，Kafka 适合数据管道

  Key points

  • The first criterion is not throughput but retention length and whether a second class of consumer will exist
  • One consumer class and messages that expire on execution: Streams is enough, and you probably already run Redis
  • Long retention with arbitrary replay, or one dataset feeding several downstream pipelines: pick Kafka
  • Structural differences: Streams is memory-first with self-managed trimming and random in-group dispatch; Kafka is sequential-disk, key-partitioned with in-partition ordering, and caps consumers at partition count
  • Redis persistence is lossy (per-second AOF fsync, async replication), so the database must be the source of truth with the stream as a trigger plus a republish sweeper
  • One-line rule: Streams triggers work, Kafka moves data

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

• pgvector 和专用向量数据库相比，优劣分别是什么？你会怎么选？How does pgvector compare with a dedicated vector database, and how would you choose?

  国内高频海外高频进阶#vector-database#pgvector#architecture

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

  1. 这题考的是选型判断力，不是产品参数背诵。开口就报「Milvus 支持分布式、Qdrant 过滤更强」是最没有区分度的答法——面试官想知道你按什么判据选，以及你有没有算过运维成本。
  2. 先给三个提问维度，把选型变成可推导的：数据量到什么量级、要不要和业务表在同一个事务里提交、过滤条件复不复杂。这三问能覆盖绝大多数真实场景。
  3. pgvector 的赢面几乎全在后两问上：记忆表和业务表在同一个库，写记忆和更新执行记录可以放进同一个事务；按用户过滤就是普通 where 条件；备份、监控、连接池、迁移工具全部复用。**多一个有状态服务的运维成本，通常比向量检索的性能更早成为瓶颈**——这句话最能体现你上过线。
  4. 再诚实地说它的天花板：单表到千万级向量时 HNSW 索引构建吃内存、写入放大明显，ANN 与元数据过滤的融合不如专用库，水平扩展只能靠 Postgres 自己那一套。不肯说缺点的人会被认为在推销。
  5. 结论要能写死：百万级以内、需要和业务表一起过滤或同事务提交、团队人手紧，用 pgvector；上千万条、检索本身就是主要负载、有专人维护，上专用库。别在第一天就选专用库。
  6. 可以预期的追问：以后想换库，迁移成本大不大？答案会让很多人意外——换库不用重算 embedding，向量是模型产出的，跟存它的库无关，导出导入即可，成本主要在双写和灰度。真正要全量重算的是换 embedding 模型，那才是硬锁定。

  How to reason about it · think before answering

  1. This is a judgment question, not a feature-recital. Opening with 'Milvus does sharding, Qdrant filters better' carries no signal — they want your decision criteria and whether you have priced the operational overhead.
  2. Offer three questions that make the choice derivable: what scale, does it need to commit in the same transaction as business tables, and how complex is the metadata filtering.
  3. pgvector wins on the last two: memories live in the same database as the business tables, so writing a memory and updating a run share one transaction; filtering by user is an ordinary WHERE clause; backups, monitoring, pooling and migrations are all reused. The line that shows operational experience is that one more stateful service usually becomes the bottleneck before vector search performance does.
  4. Be honest about the ceiling: past roughly ten million vectors in one table, HNSW index builds eat memory and write amplification shows; ANN plus metadata filtering is weaker than a purpose-built engine; horizontal scaling is whatever Postgres gives you. Refusing to name downsides reads as salesmanship.
  5. Commit to a rule: under a million vectors, needing joins or shared transactions, small team — pgvector. Tens of millions, retrieval as the primary workload, someone owning the service — dedicated store. Do not start with the dedicated store on day one.
  6. Expect the follow-up on migration cost. Switching stores does not require re-embedding — vectors belong to the model, not the store, so export and import; the cost is dual-write and rollout. Switching the embedding model is what forces a full recompute, and that is the real lock-in.

  答题要点

  • 三个判据：数据量级、要不要和业务表同事务提交、元数据过滤复不复杂
  • pgvector 的优势是同库同事务、普通 SQL 过滤、运维零新增——少一个有状态服务往往比性能更值钱
  • pgvector 的天花板：千万级向量时索引构建吃内存、写入放大、ANN 与过滤融合弱、扩展受限于 Postgres
  • 专用向量库给的是分布式分片、更强的过滤与 ANN 融合、混合检索，代价是多一个要备份要监控的有状态服务
  • 换向量库不用重算 embedding；换 embedding 模型才要全量重算，真正的锁定点是模型不是库

  Key points

  • Three criteria: scale, need for same-transaction commits with business tables, and filtering complexity
  • pgvector gives one database, one transaction, ordinary SQL filters and zero new operations — often worth more than raw performance
  • Its ceiling: memory-hungry index builds and write amplification at tens of millions, weaker ANN-plus-filter fusion, scaling limited to Postgres
  • Dedicated stores buy sharding, better filtered ANN and hybrid search, at the price of another stateful service to back up and monitor
  • Changing stores needs no re-embedding; changing the embedding model does — the lock-in is the model, not the database