面试题库

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

D1 LLM API 基础：messages/roles、token、流式、temperature；Agent 到底是什么

• 用户切到后台或者直接关掉网页，回来后怎么恢复那条还在生成的回复？The user backgrounds the app or closes the tab. How do you restore a reply that was still being generated?

  国内高频海外高频深入#streaming#reliability#architecture

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

  1. 先识别这题和「网络断了」不是同一个问题：客户端已经不存在了，任何写在前端的重试逻辑都不会执行。
  2. 由此推出唯一出路：生成过程必须能脱离这个客户端独立存活，也就是把流本身放到服务端持久化。
  3. 落到具体架构：发起请求时给这轮生成分配一个流 id，服务端一边把 token 推给当前连接，一边把同样的内容写进 Redis 之类的存储；会话记录里保存这个 activeStreamId。
  4. 恢复路径是另开一个 GET 端点：客户端带着会话 id 请求，服务端按 activeStreamId 找到那条流并接着推；找不到活跃流就返回 204，让前端知道没有需要恢复的东西。
  5. 说清代价，别只说方案：多了一份存储、一套过期清理、以及「同一条流可能被多个连接消费」的并发问题。
  6. 延伸：这套结构和普通聊天产品的「消息已持久化，重进会话直接读库」不同——区别在于回复还在生成中，需要的是可续的流而不是一条静态记录。

  How to reason about it · think before answering

  1. First separate this from a dropped connection: the client is gone, so no client-side retry will ever run.
  2. That leaves one option — the generation must outlive the client, which means persisting the stream server-side.
  3. Concretely: assign a stream id per generation; the server pushes tokens to the live connection while also writing them to storage such as Redis, and the chat record stores that activeStreamId.
  4. Recovery is a separate GET endpoint: the client asks with the chat id, the server locates the stream by activeStreamId and resumes; with no active stream it returns 204.
  5. Name the costs, not just the design: extra storage, expiry/cleanup, and concurrency when several connections consume the same stream.
  6. Extension: this differs from ordinary message persistence because the reply is still being produced — you need a resumable stream, not a static row.

  答题要点

  • 客户端已经不在了，前端重试无从谈起，必须让生成过程在服务端独立存活
  • 发起生成时分配流 id，服务端边推送边把内容写进 Redis，会话里记录 activeStreamId
  • 恢复走单独的 GET 端点：按会话 id 找到活跃流接着推，没有活跃流就返回 204
  • 代价：额外存储、过期清理，以及同一条流被多个连接消费的并发处理
  • 与「消息持久化后重新读库」的区别在于回复仍在生成中，需要的是可续的流

  Key points

  • The client is gone, so recovery must live server-side: the generation has to outlive the connection
  • Assign a stream id at start; the server writes tokens to Redis while streaming, and the chat stores activeStreamId
  • Resume through a dedicated GET endpoint that replays the active stream, returning 204 when there is none
  • Costs: extra storage, expiry and cleanup, and concurrent consumers of one stream
  • It differs from plain message persistence because the reply is still in flight, so you need a resumable stream

D15 多 Agent 模式全景（Router/Supervisor、Planner-Executor、Critic、Swarm、Blackboard）与何时不该用；LangGraph 入门

• 什么情况下不应该引入多 Agent 系统？请给出可操作的判据，而不是「视情况而定」。When should you not introduce a multi-agent system? Give operational criteria, not it depends.

  国内高频海外高频深入#multi-agent#architecture#trade-offs

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

  1. 这是本组最有区分度的题，因为它反着问。绝大多数候选人会顺着「多 Agent 很强大」讲下去，而面试官问这题正是想找那个会说不的人——**在真实团队里，拦住一次不必要的架构升级，价值高于实现三个模式**。
  2. 先给结论式的默认值：默认答案是不拆。然后给三条判据，命中任意一条才拆——一是单个 Agent 的系统提示词里出现了互斥的行为要求（既要严格核对退款规则又要热情挽留，这两条不是难写，是不可能同时最优）；二是工具数量超过模型能稳定选对的规模（经验线大约八个，超线的第一反应是合并工具而不是拆 Agent）；三是某一步需要独立的失败与重试语义。三条都不命中，单 Agent 加几个工具就够。
  3. 接着点名最常见的错拆：把提示词问题当成架构问题。「回答质量不好，所以拆成三个 Agent」——质量差有九成来自提示词含糊、工具描述互相干扰、上下文塞了无关历史，这三样拆完一样存在，只是分散到三个地方更难查。**拆 Agent 解决的是职责冲突，不是能力不足。**
  4. 再补两类明确不该拆的场景：一是低延迟要求的场景，多一跳就多一次模型往返，对语音或实时补全这类交互直接不可用；二是只读的简单查询链路，三五个工具的客服助手拆了只是把一次调用变成三次，准确率不会涨、账单会涨。
  5. 然后给一条可执行的验证路径，这是加分项：任何拆分都先留住单 Agent 版本当对照基线，用同一批标准样本集跑 A/B，同时比准确率、每次对话成本和延迟。**拿不出对照基线的架构升级，等于没有证据的重构。**
  6. 可以预期的追问：那如果老板就是要求上多 Agent 呢？答：那就把它当成一个可回退的实验来做——先按判据拆最有把握的那一刀（通常是互斥规则那一条），保留基线，两周后拿数据说话。这个回答同时展示了技术判断和沟通方式，比硬顶或硬上都好。

  How to reason about it · think before answering

  1. This is the highest-signal question in the set because it is asked in reverse. Most candidates keep selling how powerful multi-agent is, while the interviewer is looking for someone who will say no — on a real team, blocking one unnecessary architecture upgrade is worth more than implementing three patterns.
  2. Lead with the default: do not split. Then give three criteria, any one of which justifies splitting — the system prompt contains mutually exclusive behavioural requirements (strictly enforce refund rules while also warmly retaining the customer; these are not hard to write, they are impossible to optimise together); the tool count exceeds what the model picks reliably (roughly eight as a rule of thumb, and the first response to crossing it is consolidating tools, not splitting agents); or one step needs its own failure and retry semantics. None of the three, and a single agent with a few tools is enough.
  3. Then name the most common bad split: treating a prompt problem as an architecture problem. Quality is poor, so we split into three agents — but nine times out of ten poor quality comes from vague prompts, tool descriptions that interfere with each other, or irrelevant history in the context. All three survive the split and are now harder to find. Splitting fixes conflicting responsibilities, not weak capability.
  4. Add two scenarios that clearly should not split: latency-sensitive interactions, where each extra hop is another model round trip and voice or realtime completion becomes unusable; and read-only lookup flows, where a support assistant with three or four tools gains no accuracy from splitting and simply triples the bill.
  5. Then offer an executable verification path, which earns points: keep the single-agent version as a baseline for any split and A/B both against the same golden set, comparing accuracy, per-conversation cost and latency together. An architecture upgrade with no baseline is a refactor with no evidence.
  6. Expect: what if your manager insists on multi-agent? Frame it as a reversible experiment — make the one cut you are most confident in (usually the conflicting-rules criterion), keep the baseline, and bring data in two weeks. That answer shows technical judgement and a way to disagree without stonewalling.

  答题要点

  • 默认答案是不拆；三条判据命中任意一条才拆：提示词有互斥要求、工具超过约八个的告警线、某一步需要独立的失败与重试语义
  • 工具太多的第一反应是合并工具与收敛描述，拆 Agent 是第二反应
  • 最常见的错拆是把提示词问题当架构问题——质量差多半来自提示词含糊、工具描述干扰、上下文塞了无关历史，拆完这三样照旧存在
  • 明确不该拆：低延迟交互（每多一跳就多一次模型往返）、只读的简单查询链路（准确率不涨、账单涨）
  • 任何拆分都要留单 Agent 版本当对照基线，用同一批标准样本集比准确率、成本和延迟
  • 代价要说出口：延迟按步数乘倍数、成本约三倍、调试要同时排查路由与状态合并

  Key points

  • Default to not splitting; split only if one of three criteria holds: mutually exclusive prompt requirements, tool count past the roughly-eight warning line, or a step needing its own failure and retry semantics
  • Too many tools should first trigger tool consolidation and tighter descriptions; splitting agents is the second response
  • The most common bad split is treating a prompt problem as an architecture problem — vague prompts, interfering tool descriptions and irrelevant history all survive the split
  • Clear do-not-split cases: latency-sensitive interactions where every hop adds a model round trip, and read-only lookup flows where accuracy does not move but the bill does
  • Always keep the single-agent version as a baseline and compare accuracy, cost and latency on the same golden set
  • Say the costs out loud: latency multiplies with steps, spend roughly triples, and debugging now spans routing plus state merging

D19 跨服务 Agent 集成：用户级 JWT 铸造、JWKS 验签、inject/memory/usage 三类接口、幂等 externalId

• 设计一组给外部服务调用的 Agent 平台接口，你会怎么划分职责边界？You are designing the API surface an Agent platform exposes to other services. How do you draw the responsibility boundaries?

  国内高频海外高频深入#api-design#security#architecture

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

  1. 这是开放题，考的是你有没有一条能反复用的划分依据。上来就罗列接口清单的人会被追问到没词；先给依据再给清单的人，追问反而是加分机会。
  2. 给一条判据：**按「谁拥有这份数据」划，不按「谁调用它」划。** 会话、执行记录、记忆、成本台账都属于平台，所以平台开的三个口子恰好是「写一条进来（inject）」「读写记忆（memory）」「查账（usage）」；编排逻辑属于对方，平台就不该提供「帮我跑一遍这个图」的接口——那是把对方的职责搬到自己身上，将来两边都改不动。
  3. 第二条判据是**贯穿全课的安全不变量：身份只能来自令牌，不能来自请求体**。所有接口都不接受 userId 参数，服务端一律从令牌的 sub 取。这条一旦破例，权限模型就整个塌了：查成本的接口如果接受 userId 查询参数，任何一张有效令牌都能遍历所有人的消费金额。同一条原则在 D12 的记忆检索工具上也出现过——不给模型身份参数，服务端自己填。
  4. 第三条是**返回粒度要按最小必要给**。usage 只返回汇总不返回明细，因为明细里带着执行 id 和模型选型，等于把平台的内部策略一并交出去；memory 要支持按 query 检索并限制条数，不提供「把这个人的所有记忆倒出来」的接口——一旦提供，它迟早会被某个图省事的调用方用成默认写法。
  5. 第四条是**每个写接口都要能被安全重放**：带 externalId、唯一约束兜底、重复返回 200。跨服务调用一定会重复，这不是要不要做的问题。
  6. 可以预期的追问：那限流按什么维度做？答「每用户，不是每调用方」——按调用方限流的话，一个用户的异常重试会把所有人的额度吃光；另外写接口要防回环，注入的消息要打来源标记，否则两个服务能把彼此拉进无限循环，账单是唯一会提醒你的东西。

  How to reason about it · think before answering

  1. This is an open design question testing whether you have a reusable criterion. Candidates who start listing endpoints run out of material under follow-ups; candidates who give the criterion first turn follow-ups into extra points.
  2. Offer the criterion: draw boundaries by who owns the data, not by who calls it. Sessions, run records, memories and the cost ledger belong to the platform, so the platform exposes exactly three things — write one event in (inject), read and write memory, and read usage. Orchestration belongs to the caller, so the platform should not offer run this graph for me; that pulls someone else's responsibility inside your walls and freezes both sides.
  3. Second criterion, the security invariant that runs through the whole course: identity comes from the token, never from the request body. No endpoint accepts a userId; the server always reads sub. Break this once and the authorization model collapses — a usage endpoint that accepts a userId query parameter lets any valid token enumerate everyone's spend. The same principle appeared on the memory search tool: the model gets no identity parameter, the server fills it in.
  4. Third, return the minimum necessary. Usage returns aggregates, not line items, because line items carry run ids and model choices — that hands over your internal strategy. Memory supports a query with a result limit rather than dump everything this user ever said; once that exists, some caller in a hurry will make it the default.
  5. Fourth, every write endpoint must be safely replayable: an externalId, a uniqueness constraint underneath, and 200 on a repeat. Cross-service calls will be duplicated; this is not optional.
  6. Expect: what dimension do you rate-limit on? Per user, not per caller — limiting per caller lets one user's runaway retries consume everyone's budget. Also guard against loops: tag injected messages with their source, or two services can pull each other into an infinite cycle and the bill is the only thing that tells you.

  答题要点

  • 按「谁拥有这份数据」划边界，不按「谁调用」划：会话、记忆、台账属于平台，编排属于对方
  • 三个口子对应三种所有权：inject 写入、memory 读写、usage 查账；不提供「帮我跑图」这种越界接口
  • 所有接口都不接受 userId 参数，身份一律从令牌 sub 取——这条破例一次权限模型就塌了
  • 返回粒度按最小必要：usage 只给汇总不给明细，memory 按 query 限条数而不是全量倒出
  • 每个写接口都带 externalId 并由唯一约束兜底，重复返回 200
  • 限流按每用户而不是每调用方；注入的消息要打来源标记防止两个服务互相回环

  Key points

  • Draw boundaries by data ownership, not by caller: sessions, memory and the ledger belong to the platform, orchestration belongs to the caller
  • Three endpoints for three kinds of ownership — inject, memory, usage — and no run this graph for me endpoint that crosses the line
  • No endpoint accepts a userId; identity always comes from the token's sub, and one exception collapses the model
  • Return the minimum necessary: usage gives aggregates only, memory takes a query with a limit instead of dumping everything
  • Every write endpoint carries an externalId backed by a uniqueness constraint and answers 200 on repeats
  • Rate-limit per user rather than per caller, and tag injected messages with their source so two services cannot loop forever