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 靠公共状态解耦，终止条件最难写
  • 每种模式配一句代价：多一次调用的延迟、并行的写冲突、回路的死循环、步数不封顶、终止条件难定
• What signals typically trigger the move from a single agent to a multi-agent system, and what does the upgrade cost you?从单 Agent 升级到多 Agent，通常是被什么信号触发的？升级之后系统会多付出什么？

  Common in ChinaCommon overseasIntermediate#multi-agent#cost#architecture

  How to reason about it · think before answering

  1. This question tests whether business pain forced the split or a blog post did. Answering the business got complex is a non-answer; the interviewer wants observable signals — what symptom made you act.
  2. Give five, in the order they usually appear: prompts start fighting each other (add one rule, another metric drops); the tool list grows until you need the docs yourself; one step's failure needs isolated handling instead of redoing the whole turn; you want a different model for one specific step; and evaluation granularity is too coarse to say more than good or bad.
  3. Expand on the fourth, the counter-intuitive one: multi-agent is usually more expensive, but per-step model selection is the one case where it saves money — a short triage decision on a cheap small model, a drafting step on a larger one. A single agent cannot swap models per step. This lands well in interviews.
  4. Then volunteer the costs, or the answer reads as evangelism: latency multiplies by step count (two seconds becomes six, while user patience is about three); cost grows linearly with calls because every step re-sends the current state as context, typically three times; and debugging cost grows with state dimensions, since a failure now requires checking routing, each sub-agent's input state, and whether merges overwrote each other.
  5. Add the reverse check to show you are not splitting reflexively: too many tools should first prompt consolidation and tighter descriptions, with splitting as the second response; poor quality should first prompt tuning the single-agent version to its best, which then becomes the baseline the multi-agent version is measured against.
  6. Expect: how do you prove the split helped? Keep the single-agent version as a baseline and A/B both against the same golden set, comparing accuracy alongside per-conversation cost and latency. People who cannot name a baseline usually cannot explain why they split either.

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

  1. 这题考的是「你是被业务逼着拆的，还是照着博客拆的」。答「业务变复杂了」等于没答，面试官要的是**可观测的信号**：什么现象出现时你才动手。
  2. 给五个按出现顺序排的信号：一是提示词开始互相打架（加一条规则，另一个指标就掉）；二是工具列表长到自己都要查文档；三是某一步的失败需要单独处理，不该整轮重来；四是想给某一步单独换模型；五是评估颗粒度不够，只能整体打分好或不好。
  3. 第四个信号要展开讲，它是唯一一个反常识的：多 Agent 通常更贵，但按步换模型是它唯一能省钱的场景——分诊这种短判断走便宜的小模型，拟方案走大模型。单 Agent 做不到按步换模型。这一条在面试里是明显的亮点。
  4. 然后主动给代价，不给代价的回答会被当成布道：延迟按步数乘倍数（原来两秒变六秒，而用户耐心大约三秒）；成本按调用次数线性涨，因为每一步都要把当前状态重新塞进上下文，典型是三倍；调试难度按状态维度涨，出错要同时回答路由对不对、每个子 Agent 拿到的状态对不对、合并有没有互相覆盖。
  5. 再补一句反向判断，证明你不是无脑拆：工具太多的第一反应应该是合并工具、收敛描述，拆 Agent 是第二反应；质量差的第一反应应该是把单 Agent 版本调到最好，那个版本还会成为多 Agent 的对照基线。
  6. 可以预期的追问：拆完怎么证明比原来好？答：留住单 Agent 版本当基线，用同一批标准样本集跑 A/B，比准确率也比每次对话的成本与延迟。说不出对照基线的人，通常也说不清自己为什么拆。

  Key points

  • Five observable signals: prompts fighting each other, a tool list you must look up, one step needing isolated retries, wanting a different model per step, and evaluation too coarse to act on
  • Per-step model selection is the only case where multi-agent saves money: small model for triage, larger model for drafting — impossible in a single agent
  • Cost one: latency multiplies with step count, two seconds becomes six, while patience for a support bot is about three
  • Cost two: spend grows linearly with calls since every step re-sends state as context, typically three times the original
  • Cost three: debugging cost grows with state dimensions, so multi-agent and tracing have to ship together
  • Reverse check: consolidate tools before splitting, and tune the single agent to its best first — that version becomes your baseline

  答题要点

  • 五个可观测信号：提示词互相打架、工具多到要查文档、某一步需要独立重试、想按步换模型、评估颗粒度不够
  • 按步换模型是多 Agent 唯一能省钱的场景：短判断走小模型、拟方案走大模型，单 Agent 做不到
  • 代价一：延迟按步数乘倍数，两秒变六秒，而用户对客服机器人的耐心大约三秒
  • 代价二：成本线性涨，每一步都要把状态重新塞进上下文，典型是原来的三倍
  • 代价三：调试难度按状态维度涨，所以多 Agent 和链路追踪必须一起上
  • 反向判断：工具多先合并再拆分，质量差先把单 Agent 调到最好——那个版本还是多 Agent 的对照基线
• When should you not introduce a multi-agent system? Give operational criteria, not it depends.什么情况下不应该引入多 Agent 系统？请给出可操作的判据，而不是「视情况而定」。

  Common in ChinaCommon overseasDeep dive#multi-agent#architecture#trade-offs

  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.

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

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

  答题要点

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

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 只在需要理解语义时才值一次模型调用
• When several subtasks run in parallel and all write the same shared state, how do you design it so they do not clobber each other?多个子任务并行执行、都要写同一份共享状态时，怎么设计才不会互相覆盖？

  Common in ChinaCommon overseasDeep dive#multi-agent#state-management#concurrency

  How to reason about it · think before answering

  1. This one separates people fast, because most candidates answer locks or immutable data structures — instincts carried over from threads. A graph runtime has no concurrent memory writes at all: updates are collected and merged. Answering in the wrong frame is worse than answering incompletely.
  2. Get the mechanism right first: parallel nodes each return a delta, the runtime groups all deltas from the same step by field, then calls that field's reducer to compute the new value. So the question is not how to lock, it is whether that field's reducer is correct.
  3. Then give a reusable chain: how many writers touch this field in one step, and do they write the same record? One writer — last-write-wins is fine. Several writers on different records — appending to a list is fine. Several writers on the same record — upsert by key. Several writers on different fields of the same record — merge per field. Four cases, four reducers, and the chain transfers to any framework.
  4. Land on the common mistake: implementing update this record as append a new version with the same id. The symptom is not an error — the same id exists twice and which one comes first depends on who finished first, so any lookup by id may return the stale version. Clean logs, occasionally wrong results.
  5. Add the trade-off: you can leave the reducer alone and dedupe by id at every read instead. But there are three or four read sites, and missing one is an intermittent stale read; a reducer is written once and every read is clean afterwards. Solve it once on the field, or N times at the read sites.
  6. Expect: does nondeterministic ordering matter? Ideally the reducer is order-insensitive (commutative); if it is not, you must guarantee one writer per record. Upsert-by-id is the latter — it is last-write-wins and is safe only because each record has exactly one executor per round.

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

  1. 这题的区分度极高，因为大多数人会答成「加锁」或者「用不可变数据结构」——都是从多线程经验迁移过来的答案，但图的执行模型里根本没有并发写内存这回事，写入是被收集起来统一合并的。答错方向比答不全更致命。
  2. 先把机制说对：并行节点各自返回一份增量，框架把同一轮里所有增量按字段收集，再逐字段调用这个字段的合并规则（reducer）算出新值。所以问题不是「怎么加锁」，而是**这个字段的合并规则写得对不对**。
  3. 然后给一条可复用的判断链：先问这个字段同一轮会被几个人写；再问他们写的是不是同一条记录。只有一个写者，默认的后写覆盖就够；多个写者写不同记录，数组追加就够；多个写者写同一条记录的同一份数据，要按主键原地更新；多个写者写同一条记录的不同字段，要做字段级合并。四种情况四种 reducer，这条链能直接迁移到任何框架。
  4. 结论落在最容易踩的那一格：把「更新一条记录」写成「往数组里追加一条同 id 的新版本」。它的症状不是报错，是同一个 id 在状态里有两份、而且哪份在前取决于谁先跑完——下游任何按 id 查的地方都可能拿到过期版本，日志干净、结果偶尔错。
  5. 补一句权衡：也可以不动 reducer，改成每处读状态前先按 id 去重。但读取点有三四处，漏一处就是一个偶发脏读；reducer 只写一次，之后所有读取点自动干净。在字段上解决一次，还是在每个读取点解决 N 次，这是同一个问题的两种成本。
  6. 可以预期的追问：那顺序不确定要不要紧？答：合并规则最好对顺序不敏感（可交换），做不到就必须保证每条记录只有一个写者。本课的按 id 原地更新属于后者——它是最后写入者获胜，靠「一轮里一条记录只有一个执行者」这个前提才安全。

  Key points

  • A graph runtime has no concurrent memory writes: nodes return deltas, the runtime groups them per field and calls that field's reducer — so the answer is a correct reducer, not a lock
  • Decision chain: how many writers per step, and same record or not — overwrite, append, upsert by key, or per-field merge
  • The classic bug is implementing update as append-a-new-version-with-the-same-id: two entries per id, order depends on who finished first, lookups return stale data, and nothing ever errors
  • The alternative is deduping at every read site, but there are several and missing one gives an intermittent stale read; a reducer is written once
  • Prefer an order-insensitive reducer; if it is not, guarantee exactly one writer per record per step

  答题要点

  • 图的执行模型里没有并发写内存：节点各返回增量，框架按字段收集后调用该字段的 reducer 合并，所以问题是 reducer 写得对不对，不是加不加锁
  • 判断链：同一轮几个写者、写的是不是同一条记录——单写者用覆盖、多写者写不同记录用追加、多写者写同一条记录用按主键原地更新、写同一条记录的不同字段要字段级合并
  • 最常见的错是把「更新」写成「追加同 id 的新版本」，症状是同 id 两份、顺序取决于谁先跑完、按 id 查会拿到过期版本，而且全程不报错
  • 另一条路是每处读取前手动去重，但读取点有好几处，漏一处就是偶发脏读；reducer 只写一次就一劳永逸
  • 合并规则最好对顺序不敏感；做不到就必须保证一轮里一条记录只有一个写者

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 多一层图执行状态：消息 + 工作区 + 评审轮次 + 降级标记，会被检查点持久化并在恢复时重放，丢了最贵
  • 摘要放独立字段而不是塞回消息数组，原文与派生数据分开存才可能换策略重生成
• When summarizing a long conversation, how do you keep the critical information from being lost — and what is different about this in a multi-agent system?长对话做摘要时，怎么保证关键信息不丢？在多 Agent 场景下这件事有什么特别的？

  Common in ChinaCommon overseasIntermediate#context-compression#multi-agent#reliability

  How to reason about it · think before answering

  1. The hinge is the second half. Answering only keep user constraints and the last few turns is the standard single-agent answer — passable, not memorable. Asking what is different in multi-agent is asking whether you have actually hit this in a collaboration graph.
  2. Get the single-agent half solid first: trigger on thresholds, never a timer. This course uses more than 20 messages or an estimated 8000 tokens, counting one character as one token — deliberately high, because underestimating means the threshold never fires. Keep the last 6 messages verbatim. Align the cut to a turn boundary: cutting between a tool call and its result produces a dangling message and most vendors return 400.
  3. Then name the real difference: in a single agent a summary loses detail; in a multi-agent graph a summary loses the criteria. A critic decides whether output passes by telling apart what is being reviewed from what the requirement was. A smooth narrative summary that flattens speakers reads fine and is useless to the critic.
  4. So multi-agent summarization has one extra hard requirement: every compressed message must leave behind two coordinates — its index and its speaker. The implementation is one line: build the transcript with numbered, role-prefixed entries before handing it to the model.
  5. Add the boundary that shows you have shipped this: summarize natural-language history only, never structured fields. Compressing the shared workspace into a sentence kills every lookup by task id and every comparison against an acceptance requirement, and structured data does not come back. Attachments are even more off-limits — they hold a reference, not content, so summarizing one orphans the underlying object.
  6. Expect the follow-up: which model writes the summary, and what if it fails? A cheaper small model is fine since the job is condensation, not reasoning. On failure the correct behaviour is to skip this round of compression, keep running, and alert — not to fail the whole execution. Setting the threshold at seventy or eighty percent exists precisely to leave that rescue room.

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

  1. 题眼在后半句。只答「保留用户约束、保留最近几轮」是单 Agent 的标准答案，能过但不出彩；面试官问「多 Agent 有什么特别的」，是在看你有没有真的在协作图里踩过这个坑。
  2. 先把单 Agent 那半答扎实：触发用阈值不用定时器，本课口径是消息超过 20 条或估算超过 8000 token（一个字符算一个 token，故意高估，低估会让阈值永远触发不了）；保留最近 6 条原文不动；切口必须对齐到一轮的开头，切在工具调用与工具结果之间会让下一次请求出现悬空消息，多数厂商直接返回 400。
  3. 然后给出多 Agent 那半的关键差别：单 Agent 里摘要丢的是**细节**，多 Agent 里摘要丢的是**判据**。评审者判一份产出合不合格，靠的是分清「这句是待验收的产出、那句是验收要求」；一段把发言人抹平的流水摘要读起来通顺，但评审拿它做不了任何判断。
  4. 所以多 Agent 的摘要有一条额外硬要求：每条被压掉的消息，在摘要里都要留下「第几条 + 谁说的」这两个坐标。实现只有一行——把转录写成带序号和角色前缀的形式再交给模型。
  5. 再补一条边界，这条最能显出你写过：**摘要只对自然语言历史动手，不碰任何结构化字段**。把共享工作区压成一句话，「按 id 找到某条子任务、比对验收要求」就整个失效了，结构化数据压成自然语言就再也回不去。附件字段更是碰不得——它存的是引用不是内容，摘要掉等于把那个对象变成孤儿。
  6. 可以预期的追问：摘要用哪个模型、失败了怎么办？答可以用更便宜的小模型（它只做归纳不做推理），失败时的正确行为是**跳过这一轮压缩继续跑**并告警，而不是让整次执行失败——阈值定在七八成就是为了留出这次抢救余量。

  Key points

  • Trigger on thresholds, not timers: more than 20 messages or an estimated 8000 tokens, counting one character as one token to stay conservative
  • Keep the last 6 messages verbatim and align the cut to a turn boundary, or you ship a dangling tool call and the request 400s
  • The multi-agent difference: a summary loses criteria, not just detail — the critic needs to know who said what and at which step
  • So every compressed message keeps its index and speaker in the summary; the implementation is a numbered, role-prefixed transcript
  • Summarize natural-language history only — never the shared workspace or other structured fields, and never the attachment references
  • A cheaper small model is fine for summarizing; if the call fails, skip compression for this round and alert rather than failing the run

  答题要点

  • 触发用阈值不用定时器：超过 20 条或估算超过 8000 token，token 按一字符一 token 保守高估
  • 保留最近 6 条原文不动，切口必须对齐到一轮开头，否则会出现有调用没结果的悬空消息、请求直接 400
  • 多 Agent 的差别：摘要丢的不是细节而是判据，评审者靠「谁在第几步说的」区分产出与验收要求
  • 所以每条被压掉的消息都要在摘要里留下条号与发言人，实现就是把转录写成带序号和角色的形式
  • 只压自然语言历史，不碰共享工作区这类结构化字段，更不能碰存引用的附件字段
  • 摘要可用更便宜的小模型；摘要调用失败时跳过这一轮压缩并告警，不要让整次执行失败