面试题库

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

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

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

  国内高频海外高频基础#multi-agent#orchestration#architecture

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

  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，理由是它的失败模式最好理解——路由判错了看一眼路由理由就知道，而且它是唯一一个能顺便省钱的模式，简单意图可以路由到便宜的小模型。

  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.

  答题要点

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

  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
• LangGraph 里节点、边、状态分别扮演什么角色？如果不用框架，你自己会怎么实现？In LangGraph, what roles do nodes, edges and state play? If you had no framework, how would you implement it yourself?

  国内高频海外高频进阶#langgraph#orchestration#state-management

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

  1. 题眼在后半句。只答三个概念的定义，面试官会认为你读过文档；能说出「不用框架会难受在哪」，才证明你知道框架替你解决了什么。这类题的通用解法是：先讲自己手写的版本，再讲框架把哪几处收敛了。
  2. 先给手写版：一个循环，里面一串条件判断决定下一步走哪，中间用一个大对象在各步之间传数据。写到第三个分支就会撞上三件事——两步都往同一个字段写，是覆盖还是追加，你要在每个分支里手写一遍合并逻辑；中间过程全在局部变量里，出错只能靠打印；进程一挂就从头重来，已经花掉的模型调用钱白付。
  3. 然后一一对上：节点是一个普通函数，读全量状态、返回只含改动字段的增量；边是节点之间的连接，无条件边写死顺序，条件边在运行时决定去哪；状态是一张字段表，每个字段是一条独立通道，通道上挂着合并规则。
  4. 重点讲第三条，因为它是最容易被略过、也最值钱的一条：**合并规则是声明在字段上的，不是写在节点里的**。这意味着新增节点时不需要考虑「我该怎么和别人的写入合并」，字段自己知道；也意味着并行写同一个字段时行为是确定的，而不是取决于谁先返回。
  5. 配两个具体的坑，证明你真跑过：一是在节点里原地修改状态（比如直接往数组里 push）会绕过合并规则，单线程时察觉不到，并行时变成偶发覆盖；二是加了节点没连边不会报错，表现只是那个节点永远不执行，只能靠逐节点追踪发现。
  6. 可以预期的追问：那你为什么不直接自己写？答：三要素本身很轻，核心逻辑几十行就能手写出来——框架真正值钱的是检查点与恢复、并行执行、以及每一步的可观测，这三样自己写的成本远高于三要素本身。顺带说明 Java 和 Swift 没有官方 LangGraph，真要在这两门语言里做，就是把这三要素手写一遍。

  How to reason about it · think before answering

  1. The hinge is the second half. Defining the three concepts only proves you read the docs; explaining what hurts without a framework proves you know what it buys you. The general move for this family of questions is: describe your hand-rolled version first, then name what the framework collapsed.
  2. Hand-rolled version: a loop, a chain of conditionals picking the next step, and one big object carrying data between steps. By the third branch you hit three walls — when two steps write the same field, is it overwrite or append, and you hand-write that merge in every branch; intermediate state lives in local variables so debugging means print statements; a crash restarts from zero and the model calls you already paid for are wasted.
  3. Then map them: a node is an ordinary function that reads the whole state and returns a delta containing only what it changed; edges connect nodes, unconditional ones fix the order and conditional ones decide at runtime; state is a table of fields where each field is its own channel carrying a merge rule.
  4. Dwell on the third, which is the most skipped and most valuable point: the merge rule is declared on the field, not written inside the node. Adding a node therefore requires no thought about how to combine with other writers, and parallel writes to one field behave deterministically instead of depending on who returns first.
  5. Add two concrete traps to show you have actually run this: mutating state in place inside a node bypasses the merge rule — invisible single-threaded, an intermittent overwrite once things run in parallel; and adding a node without wiring an edge raises no error at all, it simply never executes, which only per-node tracing reveals.
  6. Expect: so why not just write it yourself? Because the three primitives are genuinely light — a few dozen lines. What the framework actually sells is checkpointing and recovery, parallel execution, and per-step observability, all of which cost far more to build than the primitives. Mention too that there is no official LangGraph for Java or Swift, so in those languages you do hand-roll exactly these three.

  答题要点

  • 节点是普通函数：读全量状态，返回只含改动字段的增量，不在节点里原地改状态
  • 边决定执行顺序：无条件边写死，条件边在运行时决定下一步去哪（Supervisor 就靠它）
  • 状态是一张字段表，每个字段一条通道，通道上挂合并规则——规则声明在字段上而不是写在节点里
  • 不用框架会撞三堵墙：合并逻辑在每个分支手写一遍、中间过程只能靠打印、进程挂了从头重来
  • 两个真实的坑：原地改状态绕过合并规则（并行时偶发覆盖）、加了节点没连边不报错只是永不执行
  • 框架真正值钱的不是这三要素，而是检查点恢复、并行执行和逐步可观测

  Key points

  • A node is a plain function: read the full state, return a delta of changed fields only, never mutate in place
  • Edges set execution order: unconditional edges are fixed, conditional edges decide the next hop at runtime — that is what a supervisor uses
  • State is a table of fields, each field a channel carrying a merge rule declared on the field rather than inside nodes
  • Without a framework you hit three walls: hand-written merges in every branch, no visibility into intermediate steps, and full restart after a crash
  • Two real traps: in-place mutation bypasses the merge rule and causes intermittent overwrites under parallelism; an unwired node raises no error, it just never runs
  • What the framework really sells is checkpoint recovery, parallel execution and per-step observability — not the three primitives themselves

D17 Planner–Executor–Critic + 共享工作区：workspace state、toolBudget、并行 fan-out、review 回路

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

  国内高频海外高频基础#multi-agent#orchestration#architecture

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

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

  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.

  答题要点

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