Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D15 A Tour of Multi-Agent Patterns (Router/Supervisor, Planner-Executor, Critic, Swarm, Blackboard) and When Not to Use Them; Getting Started With LangGraph

• What are the common multi-agent collaboration patterns, and what shape of task suits each?常见的多 Agent 协作模式有哪些？分别适合什么形状的任务？

  Common in ChinaCommon overseasBasic#multi-agent#orchestration#architecture

  How to reason about it · think before answering

  1. This looks like a giveaway but it separates people who memorised names from people who have split a system. Listing five names is a bare pass; the interviewer wants the axis you use to tell them apart, because an axis means you can classify an architecture you have never seen.
  2. Offer a reusable axis: the difference is not the name, it is the shape of the graph. Four questions suffice — is there a branch (pick one at runtime), a fan-out (hand it to several at once), a join (merge several outputs), a back edge (send it back for rework).
  3. Then place each one: Router/Supervisor is branch only, one specialist per turn, the hard part is deciding who; Planner-Executor is fan-out plus join, for work that splits into independent pieces; Critic is branch plus back edge, for output with a clear pass/fail test where redoing is cheaper than shipping; Swarm is also branch plus back edge, but the next hop is chosen by whoever holds the baton; Blackboard is fan-out plus join plus back edge, participants unaware of each other, reacting only to shared state.
  4. Point out yourself that Critic and Swarm score identically on all four, and that the real difference is who decides the back edge — a fixed reviewer node versus the current agent. Volunteering where your own criterion breaks down scores better than reciting one more pattern name, because it proves you have used the axis rather than invented it on the spot.
  5. Attach a cost to each: Router adds one routing call of latency; Planner-Executor's parallelism creates write conflicts so fields need merge rules; Critic loops need a hard retry cap or nothing ever ships; Swarm has no upfront bound on steps so cost and latency are hard to cap; Blackboard has the hardest termination condition and tends to either stall or re-trigger.
  6. Expect: which do you use most in production? Say Router/Supervisor, because its failure mode is the easiest to read — check the recorded routing reason — and because it is the one pattern that can save money, by routing simple intents to a cheaper model.

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

  1. 这题看似送分，其实在筛「背过名词」和「拆过系统」。只报五个名字最多拿及格分，面试官真正想听的是你用什么维度把它们区分开——有维度说明你能给没见过的架构归类，没维度说明你只是读过一篇综述。
  2. 给一个可复用的维度：模式的差别不在名字，在图的形状。盯四件事就够——有没有分叉（运行时三选一）、有没有扇出（同时交给多个人）、有没有汇合（多份产出合到一起）、有没有回边（可以打回重做）。
  3. 然后逐个落位：Router/Supervisor 只有分叉，一次只找一个专家，难点在判断该找谁；Planner-Executor 是扇出加汇合，适合一件事拆成几件、几件之间没有先后；Critic 是分叉加回边，适合对错有明确判据、且重做比发出去便宜的产出；Swarm 也是分叉加回边，但下一棒交给谁由当前这位自己决定；Blackboard 是扇出加汇合加回边，参与者互相不知道对方存在，只认公共状态。
  4. 主动指出 Critic 和 Swarm 的四个特征一模一样，区别落在「回边由谁决定」——Critic 是固定的评审节点在判，Swarm 是当前这位自己判。**主动承认自己的判据在哪里失效，比多背一个模式名更能加分**，因为它证明你真的用过这套维度而不是刚编出来。
  5. 每种模式还要配一句代价，这是区分度所在：Router 多一次路由调用的延迟；Planner-Executor 的并行会带来状态写冲突，字段必须配合并规则；Critic 的回路必须有次数上限，否则永远出不了稿；Swarm 事先不知道会走多少步，成本和延迟都难封顶；Blackboard 的终止条件最难写，容易谁都不接活或者反复触发。
  6. 可以预期的追问：生产上你最常用哪个？答 Router/Supervisor，理由是它的失败模式最好理解——路由判错了看一眼路由理由就知道，而且它是唯一一个能顺便省钱的模式，简单意图可以路由到便宜的小模型。

  Key points

  • Give the axis before the names: branch, fan-out, join and back edge separate all five patterns
  • Router/Supervisor is branch only — one specialist per turn, the hard part is choosing who
  • Planner-Executor is fan-out plus join — split into independent subtasks, then merge into one deliverable
  • Critic is branch plus back edge — for output with a clear pass/fail test, and it needs a hard retry cap
  • Swarm scores the same as Critic; the difference is who decides the back edge. Blackboard decouples via shared state and has the hardest termination condition
  • Pair each with a cost: extra call latency, parallel write conflicts, infinite review loops, unbounded step count, fuzzy termination

  答题要点

  • 先给维度再给名字：分叉、扇出、汇合、回边四个特征就能把五种模式分开
  • Router/Supervisor 只有分叉，一次只找一个专家，难点是判断该找谁
  • Planner-Executor 是扇出加汇合，适合拆成几件互不依赖的小任务再合成一份交付
  • Critic 是分叉加回边，适合对错有明确判据、重做比发出去便宜的产出，必须配打回次数上限
  • Swarm 与 Critic 的四个特征相同，区别在回边由谁决定；Blackboard 靠公共状态解耦，终止条件最难写
  • 每种模式配一句代价：多一次调用的延迟、并行的写冲突、回路的死循环、步数不封顶、终止条件难定

D16 Dynamic Routing With a Supervisor: Structured-Output Routing, Override, routingReason

• How is the routing decision usually implemented in a supervisor pattern? What should that node do, and what should it not do?Supervisor 模式里的路由决策一般怎么实现？请说说这个节点该做什么、不该做什么。

  Common in ChinaCommon overseasBasic#multi-agent#routing#langgraph

  How to reason about it · think before answering

  1. This is a warm-up question, and warm-ups are where people lose points by restating the prompt: an agent decides who goes next. The discriminator is the second half — can you state the node's responsibility boundary?
  2. Start with the mechanics: the supervisor is an ordinary node. It reads state, makes one model call, and writes exactly two fields — the route and the reason for it. The actual branching happens on the conditional edge after it, whose selector function maps the route to the next node name.
  3. Then draw the boundary, which is where the points are: the supervisor never answers the user, never calls business tools, and produces no side effects. It only takes a multiple-choice test, so it can run on a cheaper small model with a short input.
  4. One boundary people miss: do not call the model inside the selector function. The judgement was already made and stored in state; the selector only translates. Calling a model there makes the same state jump to different nodes across runs, which destroys reproducibility and breaks checkpoint replay and evaluation later.
  5. Close with one-at-a-time: a supervisor answers who takes this, not how to split a task and who reviews the output. That second problem belongs to planner-executor-critic. Drawing that line yourself signals you have seen a real system.
  6. Expect: where does the list of sub-agents live, and how many places change when you add one? Answer that the list should be a single source of truth — the enum, the schema, and the edge mapping all derive from it, so adding an agent is one edit and everything else fails at compile time.

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

  1. 这是一道送分题，但送分题最容易答成「让一个 Agent 决定下一步找谁」这种复述题面的话。区分度在后半句：你能不能说清这个节点的职责边界。
  2. 先给机械原理：Supervisor 是图里的一个普通节点，它读状态、调一次模型、只写两个字段——交给谁（route）和为什么这么判（routingReason）；真正的分叉发生在它后面那条条件边上，边上挂一个选择函数，把 route 翻译成下一个节点名。
  3. 再划边界，这是拿分的地方：Supervisor 不回答用户的问题、不调业务工具、不产生副作用。它只做选择题，所以可以配一个更便宜的小模型，输入通常只有系统提示词加最后一两句话。
  4. 还有一条边界更容易被忽略：**选择函数里不要再调模型**。判断已经在 Supervisor 节点里做完并落进状态了，选择函数只做翻译。把模型调用塞进选择函数，同一份状态每次可能跳到不同的节点，图就不可复现，后面做检查点重放和评估都会失真。
  5. 最后补一句「一次只派一个人」：Supervisor 解决的是「交给谁」，不解决「一件事要拆成几件、还得有人验收」。后者是 Planner-Executor-Critic 的活。能主动划出这条线，面试官会认为你见过真实系统的边界。
  6. 可以预期的追问：那三个子 Agent 的名单从哪来、加一个新的要改几处？答案是名单应该是单一真相来源——枚举定义、schema、条件边的映射表都从它生成，加一个子 Agent 只改一处，其余地方编译期报错提醒你。

  Key points

  • The supervisor is an ordinary node: read state, one model call, write only the route and the routing reason
  • Branching lives on the conditional edge after it — a selector maps the route to a node name, and the mapping table must be exhaustive
  • Boundary: it never answers the user, calls no business tools, has no side effects, so it can run on a cheaper small model
  • Never call a model inside the selector, or the same state jumps to different nodes across runs and replay and evaluation both break
  • A supervisor dispatches one agent at a time and only answers who takes this; splitting and reviewing belong to planner-executor-critic

  答题要点

  • Supervisor 是图里的一个普通节点：读状态、调一次模型、只写 route 与 routingReason 两个字段
  • 真正的分叉在它后面的条件边上：选择函数把 route 翻译成下一个节点名，映射表要写全
  • 职责边界：不回答用户、不调业务工具、不产生副作用，因此可以单独配一个更便宜的小模型
  • 选择函数里不能调模型，否则同一份状态每次跳的节点不同，图不可复现，检查点重放与评估都会失真
  • Supervisor 一次只派一个人，只解决「交给谁」；拆任务与验收是 Planner-Executor-Critic 的职责

D17 Planner-Executor-Critic Plus a Shared Workspace: Workspace State, toolBudget, Parallel Fan-Out, a Review Loop

• What problem does the Planner-Executor-Critic structure solve, and how is it different from Supervisor routing?Planner-Executor-Critic 这种结构解决了什么问题？它和 Supervisor 路由的区别在哪？

  Common in ChinaCommon overseasBasic#multi-agent#orchestration#architecture

  How to reason about it · think before answering

  1. The hinge is the second half. Reciting plan, execute, review is naming shapes from memory; the interviewer wants to see you separate the two patterns by graph shape.
  2. Separate by shape: a Supervisor is a fork — at runtime it picks one of several paths and hands the work to exactly one agent, so the graph only branches. Planner-Executor-Critic fans out, joins, and adds a back edge. Branching answers who takes this, fan-out answers this must be split into several pieces, the back edge answers who signs it off.
  3. Then give the criteria: use a Supervisor when only one specialist is needed per request and the hard part is picking them; only fan out when a request genuinely splits into independent pieces with no ordering between them; only add a Critic when correctness has an explicit rubric and redoing is cheaper than shipping something wrong. If none of these hold, do not build this.
  4. Land on cost, which is where shipped-it separates from read-the-docs: three subtasks turn one model call into seven (one plan, three executions, three reviews) and nine after a single rejection round; latency is set by the slowest branch rather than the average, and parallelism buys latency, never money.
  5. Expect: does the Critic have to be its own node? Not necessarily — if the rubric is checkable in code (schema validation, required fields), check it in code: faster, cheaper, and more reliable. A Critic earns a model call only when the rubric requires understanding meaning.

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

  1. 题眼在后半句。只答「拆解、执行、评审」是在背名词，面试官想确认的是你能不能用图的形状把两种模式分开，而不是靠记忆背模式表。
  2. 先用形状拆：Supervisor 是一个岔路口，运行时在几条路里选一条走，一次只交给一个人，图上只有分叉；Planner-Executor-Critic 是先扇出、再汇合、中间还有一条回边。分叉解决「交给谁」，扇出解决「一件事要拆成几件」，回边解决「谁来验收」。
  3. 再给适用判据：一次只需要一个专家、难点在判断该找谁，用 Supervisor；一件事必须拆成几件且几件之间没有先后依赖，才值得扇出；产出的对错有明确判据、且错了重做比错了发出去便宜，才值得加 Critic。三条判据都不命中就别上这套结构。
  4. 结论要落到代价，这是区分「读过文档」和「上线过」的地方：拆出三件事意味着模型调用次数从一次变成七次起步（拆解一次、三次执行、三次评审），有一轮打回就是九次；延迟被最慢的那件事决定而不是平均值，而且并行只省延迟不省钱。
  5. 可以预期的追问：Critic 一定要单独一个节点吗？答案是不一定——如果验收判据是可以用代码判的（比如 JSON schema 校验、必填字段检查），就别花一次模型调用，代码判更快更准也更便宜。只有判据本身需要理解语义时，Critic 才值得是一次模型调用。

  Key points

  • A Supervisor branches (one agent per request); Planner-Executor-Critic fans out, joins, and loops back (split, run in parallel, then sign off)
  • Three criteria: route when one specialist suffices; fan out only for genuinely independent pieces; add review only when the rubric is explicit and redoing beats shipping wrong
  • The cost is seven to nine model calls instead of one, with latency set by the slowest branch — parallelism buys latency, not money
  • If the rubric is checkable in code, check it in code; a Critic deserves a model call only when semantics must be understood

  答题要点

  • Supervisor 是分叉（一次派一个人），Planner-Executor-Critic 是扇出加汇合加回边（拆成几件并行做，做完有人验收）
  • 三条适用判据：一次只需一个专家用路由；能拆成互不依赖的几件才扇出；对错有明确判据且重做便宜才加评审
  • 拆解的代价是模型调用从一次涨到七到九次、延迟由最慢的分支决定，而并行只省延迟不省成本
  • 评审判据能用代码判就别用模型判，Critic 只在需要理解语义时才值一次模型调用

D18 History Fidelity and Summarization, Multimodal Placeholders, Checkpointer Persistence

• How should agent memory be layered? What belongs in short-term context, in summaries, and in long-term memory — and what happens when each is lost?记忆应该怎么分层？短期上下文、摘要、长期记忆分别放什么、丢了会怎么样？

  Common in ChinaCommon overseasBasic#memory#context-management#multi-agent

  How to reason about it · think before answering

  1. The discriminator here is not listing three layers, it is saying what breaks when each one is lost. An answer that only names the layers tells the interviewer you have never operated one.
  2. Offer a reusable split first: sort any memory scheme by who reads it, how long it lives, and whether it can be rebuilt after loss. Those three questions cut through every design.
  3. Short-term context is the message array sent to the model this turn. It dies with the request and is billed in full every turn. Losing it only costs coherence for that turn, because the raw transcript still lives in your own store and can be replayed.
  4. A summary is derived from short-term context, produced to shrink early turns before the window fills. It can be regenerated after loss — but only if the raw transcript was stored separately. That is the practical reason a summary must never overwrite the original.
  5. Long-term memory holds cross-session user facts and preferences. It never enters the message array; it lives in a retrieval layer and a few hits get injected on demand. Losing it means the system forgot the user — single requests still work, but the product gets noticeably worse.
  6. Multi-agent adds a fourth layer people usually miss: graph execution state — messages, shared workspace, review rounds, degraded flags. It is the only copy that gets checkpointed and replayed on resume, and losing it is the most expensive failure: a run that already burned nine model calls starts over while the user watches a spinner.
  7. Expect the follow-up: should the summary live inside the message array or in its own field? Say its own field — keeping raw and derived data apart is what lets you regenerate with a different strategy later; merged together you can no longer tell what actually happened from what was written after the fact.

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

  1. 这题的区分度不在能不能列出三层，而在能不能说出**每一层丢了会怎样**。只报名词的答案，面试官听不出你有没有真的运维过。
  2. 先给一条可复用的拆法：按「谁在读它、活多久、丢了能不能补」三个问题去分，任何一个记忆方案都能被这三问切开。
  3. 短期上下文是这一次请求要发给模型的那个消息数组，随请求结束作废，全量进 token 账单；它丢了只影响这一轮的连贯性，原文还在你自己的会话记录里，可以重放。
  4. 摘要是短期上下文的派生数据，用来在窗口顶到之前把早期内容压短；它丢了可以重新生成——**前提是原文另存了一份**。所以摘要绝不能覆盖原文，这是「压缩不可逆」那条纪律的实际落点。
  5. 长期记忆是跨会话的用户事实与偏好，不进消息数组，存在外部检索层里按需捞几条注入；它丢了的表现是「这个用户被系统忘光了」，不影响单次可用，但产品价值直接掉一层。
  6. 多 Agent 还要补第四层，也是最容易被忽略的一层：**图的执行状态**。它包含消息、共享工作区、评审轮次、降级标记，是唯一一份会被检查点持久化并在恢复时重放的数据。它丢了的后果最重——一次已经花掉九次模型调用的执行必须从头再来，而且用户界面还停在转圈。
  7. 可以预期的追问：摘要该放在消息数组里还是单独一个字段？答单独字段，理由是原文与派生数据要分开存，才可能换一种策略重新生成；混在一起之后你分不清哪条是真发生过的、哪条是事后编的。

  Key points

  • Layer by who reads it, how long it lives, and whether it can be rebuilt — that beats reciting names
  • Short-term context: this turn's message array, discarded after the request, billed in full, replayable from your own transcript
  • Summary: derived from short-term context and regenerable, but only if the raw transcript is stored separately — so it must never overwrite the original
  • Long-term memory: cross-session user facts in a retrieval layer, injected on demand; losing it means the system forgot the user
  • Multi-agent adds graph execution state — messages, workspace, review rounds, degraded flags — checkpointed and replayed on resume, and the most expensive to lose
  • Keep the summary in its own field rather than back in the message array, so raw and derived data stay separable

  答题要点

  • 按「谁在读、活多久、丢了能不能补」三问分层，比背名词有用
  • 短期上下文：本轮请求的消息数组，随请求作废，全量计费，丢了可从原始记录重放
  • 摘要：短期上下文的派生数据，可重新生成，前提是原文另存——所以摘要不能覆盖原文
  • 长期记忆：跨会话的用户事实，存在检索层按需注入，丢了是「系统忘了这个人」
  • 多 Agent 多一层图执行状态：消息 + 工作区 + 评审轮次 + 降级标记，会被检查点持久化并在恢复时重放，丢了最贵
  • 摘要放独立字段而不是塞回消息数组，原文与派生数据分开存才可能换策略重生成