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

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

  Common in ChinaCommon overseasIntermediate#langgraph#orchestration#state-management

  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.

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

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

  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

  答题要点

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

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

• Why use structured output rather than natural language for routing? What exactly goes wrong with free text?为什么要让模型输出 structured output 而不是自然语言来做路由？自然语言到底差在哪？

  Common in ChinaCommon overseasIntermediate#structured-output#routing#reliability

  How to reason about it · think before answering

  1. The trap is answering structured output is cleaner and easier to parse. Those are adjectives, not reasons. The interviewer wants a concrete failure you have actually debugged.
  2. Lead with the sharpest point: free-text routing fails silently. The model replies I think the order desk should look at this — it judged correctly, but it spoke prose, not an id. Your regex misses, you fall through to the default, and the log shows only smalltalk. A correct model with a broken parser looks exactly like a wrong model, so you spend two days tuning a prompt that was never the problem.
  3. Then list three holes and map each to what structured output fixes: wording drifts across versions so regexes never catch up; there is no confidence signal, so you cannot tell certainty from guessing; and an invented route name only explodes at runtime, whereas an enum is a gate that exists before the request is even sent.
  4. Explain the mechanism rather than stopping at zod is nicer: send the schema in the request (response_format with a json_schema), so decoding is constrained by the enum, then validate the response with the same declaration. One declaration used twice means request and validation cannot drift apart.
  5. The counterintuitive point that separates candidates: structured output does not remove the need to validate. Not every gateway or model enforces the schema strictly, and a fallback model may not at all. Your parse function should return something-to-be-validated, not an already-typed decision.
  6. Expect: what if the model does not support json_schema? Fall back to few-shot plus a strict prompt plus your own validation. The real gate was never the model's discipline; it is your parsing layer.

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

  1. 这题最容易答成「结构化更规范、更好解析」——这是形容词，不是理由。面试官想听的是一个具体的失败场景，最好是你真的调过的那种。
  2. 把最锋利的一刀先亮出来：**自然语言路由的失败是静默的**。模型回「我觉得这个可以让查订单的同事看一下」，它其实判对了，但说的是人话不是 id，正则匹配不上就落进兜底，日志里只留下一个 smalltalk。模型是对的、解析是错的，而它和「模型判错了」在日志里长得一模一样。你会去调提示词，调两天才发现问题在那三行正则。
  3. 然后给三个漏洞，一条一条对上结构化输出解决了什么：输出会漂移（今天回「订单查询」明天回「查订单」，正则永远追不上，模型小版本升级你就掉准确率）；没有置信度（自然语言里没有「我有多大把握」这个信息，你没法区分它很确定还是在猜）；拼错或自造的路由名要到运行时才炸（枚举是一道编译期就存在的闸门）。
  4. 接着说清机制，别停在「用 zod 更规范」：把 schema 发进请求（response_format 里的 json_schema），模型的解码过程被枚举约束；回来之后**用同一份声明再校验一遍**。一份声明两用，请求与校验不会漂移。
  5. 关键的反直觉点，答到这里就拉开差距了：**结构化输出不等于不用校验**。不是所有网关、所有模型都严格执行 schema，降级到备用模型时更说不准。所以解析函数的返回类型应该是「一段待校验的东西」，而不是「已经是 RouteDecision」。
  6. 可以预期的追问：那不支持 json_schema 的模型怎么办？答案是退回「few-shot 加严格提示词加自己校验」，闸门仍然在你的枚举校验那一步——真正兜底的从来不是模型的自觉，是你的解析层。

  Key points

  • Free-text routing fails silently: a correct judgement in prose misses your regex and falls through, looking identical to a wrong judgement in the logs
  • Three holes: wording drifts, there is no confidence signal, and invented route names only fail at runtime
  • One declaration used twice: the schema constrains decoding in the request and validates the response, so the two cannot drift
  • An enum is a gate that exists before the call, turning a misspelled route from an incident into a parse failure
  • Structured output does not remove validation — gateways and fallback models may not enforce the schema, so parsing must return an unvalidated value

  答题要点

  • 自然语言路由的失败是静默的：模型判对了但说的是人话，正则匹配不上就落兜底，和判错在日志里完全一样
  • 三个漏洞：措辞会漂移（正则追不上）、没有置信度（分不清确定与猜）、自造的路由名要到运行时才炸
  • 机制是一份声明两用：schema 随请求发出去约束解码，回来后用同一份声明校验，请求与校验不会漂移
  • 枚举是编译期就存在的闸门，把「拼错的路由名」从线上事故降级成一次解析失败
  • 结构化输出不等于不用校验：网关和降级模型未必严格执行 schema，解析函数的返回类型应该是「待校验」而不是「已经是」
• What is a field like routingReason actually worth in production? Is it just logging?routingReason 这类调试信息在生产系统里有什么价值？只是打日志而已吗？

  Common in ChinaCommon overseasIntermediate#observability#routing#debugging

  How to reason about it · think before answering

  1. This looks like a throwaway question but it screens for whether you have ever been on call. Anyone who stops at it helps with debugging has not.
  2. Start with the fact you cannot design around: the routing decision is made by a model, and models are not reproducible. The same sentence may be judged differently next time, so you cannot re-run to see what it was thinking. The reason must be captured at decision time or it is gone forever — that is what turns this field from a log line into the only audit evidence you have.
  3. Then give three concrete uses. One, it separates a wrong model judgement from a parsing or fallback problem, provided the prefix carries a cause code. Two, it is raw material for the next prompt revision: group a week of fallbacks by cause and the missing intent descriptions jump out. Three, it feeds offline evaluation — a golden set should score routing accuracy, not just the final answer, and that is only scorable if the decision and its reason were recorded.
  4. Mention the shape: a structured prefix wrapping a human sentence. The prefix (fallback plus cause, override plus target) is what you aggregate on; the sentence is what you read for one specific case. Making the whole field prose puts you right back in the failure mode this chapter argues against.
  5. Add the detail people skip: neither a fallback nor a human override should erase the model's original judgement — carry it into the reason. Otherwise nobody can later tell whether the model got it wrong or a human redirected it. Twenty extra characters save an afternoon of archaeology.
  6. Expect: do these fields create privacy or cost problems? Yes, so record the basis for the decision rather than the user's raw text, cap the length, and reuse the same run identifier as your tracing instead of inventing a parallel one.

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

  1. 这题看着像水题，其实在筛「有没有真的排查过线上问题」。答「方便调试」就结束的人，基本没值过班。
  2. 先给一条不可回避的事实：**路由决策是模型做的，而模型不可复现**。同一句话下次未必给同样的判断，你没法重跑一遍去看「当时是怎么想的」。所以理由必须在当时就写下来，否则那次判断永远丢了。这一条把 routingReason 从「日志」抬到了「唯一的审计证据」。
  3. 然后给三个具体用途，每个都要能落地：一是把「模型判错了」和「解析或兜底出错了」分开，前缀写成 fallback 加原因码，一眼就能分辨；二是攒下一版提示词的素材，把一周内落进兜底的请求按原因分组，会看到集中的几类意图缺描述；三是它是离线评估的输入——标准样本集要评的不只是最终回答，还有分诊准不准，而这件事只有当时记了判断和理由才评得了。
  4. 写法上有个细节值得主动说：**结构化的壳加自然语言的芯**。前缀（fallback 加原因、override 加目标）用来聚合统计，后面那句人话用来看具体这一单。整条都写成自然语言，就退回成本章批判的那种东西了。
  5. 再补一条容易被忽略的：兜底和人工改派都不要擦掉模型的原判，原样拼进理由里。否则一周后没人说得清这一单是模型判错了还是本来就被人改过——多写二十个字符，省掉一次翻遍代码的排查。
  6. 可以预期的追问：这些字段会不会带来隐私或成本问题？答案是会，所以理由里只写判断依据不写用户原文，长度设上限（比如 120 字），并且和链路追踪共用同一个 run 标识，别另起一套。

  Key points

  • The decision comes from a model and is not reproducible, so the reason must be captured at decision time — it is the only audit evidence you get
  • Use one: it separates a wrong model judgement from a parsing or fallback failure, via a cause code in the prefix
  • Use two: grouping a week of fallbacks by cause tells you exactly what the next routing prompt is missing
  • Use three: it feeds offline evaluation, since routing accuracy can only be scored if the decision and reason were recorded
  • Shape it as a structured prefix around a human sentence: aggregate on the prefix, read the sentence for one case
  • Keep the model's original judgement through fallbacks and overrides; store the basis rather than raw user text, cap the length, and reuse the tracing run id

  答题要点

  • 路由决策由模型做出且不可复现，理由必须在当时写下来，否则那次判断永远丢了——它是唯一的审计证据
  • 用途一：把「模型判错」和「解析或兜底出错」分开，靠 fallback 加原因码一眼分辨
  • 用途二：把一周内落进兜底的请求按原因分组，直接得到下一版分诊提示词该补什么
  • 用途三：它是离线评估的输入，分诊准确率这个指标只有记了当时的判断与理由才评得了
  • 写法是结构化的壳加自然语言的芯：前缀用于聚合统计，人话用于看具体这一单
  • 兜底与人工改派都要保留模型原判；理由只写判断依据不写用户原文，长度设上限，并复用链路追踪的 run 标识

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

• Why give each subtask a tool-call budget, and what do you do when it runs out?为什么要给每个子任务设 toolBudget 这样的预算？超了预算之后你会怎么处理？

  Common in ChinaCommon overseasIntermediate#cost-control#reliability#agent-design

  How to reason about it · think before answering

  1. The hinge is the second half. Everyone can say it controls cost; what separates people is what happens when the budget runs out. Answering throw an exception usually means you have never shipped a user-facing agent.
  2. Make the why concrete: a stuck subtask rarely errors — it queries, dislikes the result, and queries again. The model never gets tired; it will spend whatever you allow. A per-conversation cap is the outer gate, a per-subtask budget is the inner one, and the finer grain tells you which piece went out of control instead of only that the conversation was expensive.
  3. Add the design point people miss: the budget must be per subtask, not per execution. With a review loop, retries have to draw on the same budget, or two rejections triple the real allowance and the gate is meaningless.
  4. The conclusion is the exhaustion path: degrade — return what you already have with a flag — rather than throw. Explain why: throwing upgrades this piece is half done into the whole request failed. The user waited several seconds and gets an error page, when in reality only one of three pieces is missing. Two and a half answers plus a clear note beats an error page every time.
  5. Say something about the flag too: it turns degradation into an observable, countable fact instead of a log line. The layer above decides whether to escalate to a human, and monitoring plots a degradation rate — two systems with the same average score but 30 percent versus 3 percent degradation are not the same system.
  6. Expect: how big should the budget be? Derive it from how many tool calls the task normally needs plus margin, not a round number pulled from the air. And pair it with a second dimension — wall-clock or tokens — because one very slow tool call can ruin a request while counting as a single call.

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

  1. 这题的题眼在后半句。前半句几乎人人会答「防止成本失控」，真正拉开差距的是超限之后的动作——答「抛异常」的人基本没做过面向用户的 Agent。
  2. 先把「为什么」说具体。子任务卡住的典型形态不是报错，而是反复查、反复不满意、再查——模型不会喊累，它会把额度花光为止。整轮对话的成本封顶是外层的闸，子任务预算是内层的闸；粒度细到单件事的好处是超支时你能精确指出是哪一件失控了，而不是只看到这次对话贵了。
  3. 再点一个容易被忽略的设计点：预算必须是子任务级的，不是单次执行级的。有评审回路时，被打回重做也得计费，否则打回两次实际额度就翻三倍，这道闸等于没设。
  4. 结论是超限的处理：降级返回已有结果并打上标记，不抛错。理由要说透——抛错等于把「这件事只做了一半」升级成「整个请求失败」，用户等了几秒最后看到一句服务异常，可他其实只是没拿到三件事里的一件。给出两件半的答案并说明哪半件没做成，永远比一个错误页有用。
  5. 降级标记本身也要说：它让降级变成可观测、可统计的事实，而不是日志里的一句话。上层据此决定要不要转人工，监控据此画降级率——两个平均分一样的系统，降级率百分之三十和百分之三完全不是一回事。
  6. 可以预期的追问：预算该设多少？答案是从「这件事正常需要几次工具调用」反推再留一点余量，不是拍脑袋取整数；同时要有第二个维度的闸（挂钟时间或 token 数），因为一次超长的工具调用同样能拖垮请求，而它只算一次。

  Key points

  • A stuck subtask loops rather than errors, and the model will spend whatever you allow; a conversation cap is the outer gate, a subtask budget the inner one that localises the blowup
  • The budget must be per subtask, not per execution, or two review rejections triple the real allowance
  • On exhaustion, degrade and flag rather than throw — throwing upgrades half done into whole request failed and discards what was already retrieved
  • The degradation flag makes the degradation rate a real metric for escalation and evaluation
  • Size the budget from the task's normal tool-call count plus margin, and pair it with a wall-clock or token gate

  答题要点

  • 子任务卡住的典型形态是反复查而不是报错，模型会把额度花光为止；整轮封顶是外层闸，子任务预算是内层闸，细粒度让你能定位到是哪一件失控
  • 预算必须是子任务级而不是单次执行级，否则被评审打回两次实际额度就翻三倍
  • 超限必须降级返回已有结果并标记，不能抛错——抛错把「做了一半」升级成「整个请求失败」，用户连已经查到的部分都拿不到
  • 降级标记让降级率变成可统计指标，上层据此决定转人工，评估据此区分两个平均分相同的系统
  • 预算大小从这件事正常需要几次工具调用反推并留余量，同时配一个时间或 token 维度的闸
• How do you keep a Critic review loop from spinning forever, and what else needs guarding besides a retry cap?Critic 的评审回路怎么防止陷入死循环？除了次数上限还有什么要防的？

  Common in ChinaCommon overseasIntermediate#reflection#loop-guard#reliability

  How to reason about it · think before answering

  1. Asking what else besides a cap tells you the interviewer already expects the cap. What is really being tested is whether you have run this loop for real. The cap earns baseline credit; naming the other two failure modes is what passes.
  2. Failure one is infinite rejection: every revision draws a new complaint and nothing converges. The cap exists to guarantee termination, not to save money. Two rejections and three executions is a reasonable default, because an effective fix usually lands on the second attempt — if the third still fails, the rubric itself is the problem.
  3. Failure two is a rejection with no actionable content. If the reviewer only says not good enough, the executor has nothing to act on and resubmits the same thing, burning the full cap. Rejections must carry a specific reason, and that reason must be written back into the subtask goal. Missing the refund conclusion, please add it is actionable; poor quality is not.
  4. Failure three is the dangerous one people rarely mention: when reviewer and executor share a model and a prompt, the reviewer tends to approve its own output. A single model has consistent preferences about what a good answer looks like, so pass rates go implausibly high and the review step becomes theatre. Mitigations by value: give the reviewer an objective, checkable rubric; use a different model even a cheaper one; score item by item rather than emitting one verdict.
  5. Also distinguish the framework's safety net from your business cap: orchestration frameworks usually ship a recursion limit, but that is a last-resort fuse — it is graph-wide so you cannot tell which loop ran away, and it throws, which means you lose the partial results you were supposed to degrade to.
  6. Expect: what do you return once the cap is used up? Return what you have, flag it as degraded, and carry the last review comment out with it so the layer above can decide whether to escalate. The loop's value is not only fixing things — it is stating precisely what could not be fixed.

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

  1. 问「除了次数上限还有什么」，说明面试官已经预设你会答上限，真正在考的是你有没有真的跑过这条回路。只答上限的人拿基础分，能说出另外两种失效方式的才算过。
  2. 第一种就是无限打回：每改一版评审者挑一个新毛病，永远收敛不了。上限的作用不是省钱，是**保证流程一定会结束**。本课取最多打回 2 次、共 3 次执行，这个量级的取法是「一次有效的修改通常在第二次就完成，第三次还不行说明判据本身有问题」。
  3. 第二种是打回不说人话：评审者只回一句「不合格」，执行者拿不到可执行信息，第二稿原样再交一遍，于是必然打满上限、白烧三倍的钱。所以打回必须带具体理由，而且理由要回写进子任务的目标里带给执行者——「缺了退款结论，请补上」才是可执行的，「质量不佳」不是。
  4. 第三种最危险也最少被提到：评审者和执行者用同一个模型、同一套提示词时，它倾向于认可自己的输出。同一个模型对「什么算好答案」的偏好是一致的，让它复核自己刚写的东西，通过率会高得离谱，这道工序等于没有。缓解手段按性价比排：给评审者一份可核对的客观验收要求；换一个不同的模型来评审，哪怕更便宜；把评审做成逐条打分而不是一句结论。
  5. 还要点一句框架的兜底与业务上限的区别：编排框架通常自带一个递归步数上限，但那是最后一道保险丝，不能当业务上限用——它是全图的，你不知道是哪条回路失控；而且它触发时抛异常，你连已有结果都拿不到，正好违背「降级返回」的原则。
  6. 可以预期的追问：上限用完了返回什么？答：返回已有结果并标记降级，同时把最后一次的评审意见一起带出去，让上层能判断要不要转人工——这条回路的价值不只是修好，还包括「修不好时说清楚差在哪」。

  Key points

  • A retry cap exists to guarantee termination, not to save money — two rejections, three executions total
  • Rejections must carry specific, actionable reasons written back into the subtask goal; not good enough guarantees an identical resubmission and a maxed-out cap
  • The most dangerous failure is a reviewer sharing model and prompt with the executor: it approves its own output, pass rates inflate, and the step becomes theatre
  • Mitigate with an objective checkable rubric, a different model for review, and item-by-item scoring instead of a single verdict
  • The framework's recursion limit is a fuse, not a business cap: it is graph-wide and it throws, so you lose the partial results you meant to degrade to
  • When the cap is spent, return what you have with a degraded flag plus the last review comment so the layer above can escalate

  答题要点

  • 次数上限的作用是保证流程一定会结束，不是省钱；本课取最多打回 2 次、共 3 次执行
  • 打回必须带具体、可执行的理由并回写进子任务目标，只说「不合格」会让执行者原样重交、必然打满上限
  • 最危险的是评审者与执行者同模型同提示词，它倾向于认可自己的输出，通过率虚高、这道工序等于没有
  • 缓解手段：给客观可核对的验收要求、换一个模型来评审、逐条打分而不是一句结论
  • 框架自带的递归上限只是保险丝，不能当业务上限：它是全图的、触发时抛异常，连已有结果都拿不到
  • 上限用完要返回已有结果加降级标记，并把最后一次评审意见带出去，供上层决定是否转人工

D18 History Fidelity and Summarization, Multimodal Placeholders, Checkpointer Persistence

• 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 的差别：摘要丢的不是细节而是判据，评审者靠「谁在第几步说的」区分产出与验收要求
  • 所以每条被压掉的消息都要在摘要里留下条号与发言人，实现就是把转录写成带序号和角色的形式
  • 只压自然语言历史，不碰共享工作区这类结构化字段，更不能碰存引用的附件字段
  • 摘要可用更便宜的小模型；摘要调用失败时跳过这一轮压缩并告警，不要让整次执行失败
• What problem does a checkpointer solve in a multi-agent system, and what does it cost?checkpointer 在多 Agent 系统里解决了什么问题？它的代价是什么？

  Common in ChinaCommon overseasIntermediate#checkpointing#cost#operations

  How to reason about it · think before answering

  1. The second half is the real question. Answering it enables recovery and fault tolerance is a feature blurb any doc carries. The interviewer wants to know whether you have done the arithmetic and where it hurts.
  2. Make the value concrete in money and time: one multi-agent run with a review loop costs nine model calls. If the process is restarted for a deploy at call seven, without checkpoints all nine are wasted and the user is still watching a spinner. With them the run continues from the last signed-off point and no completed node re-runs. What you bought is a smaller unit of failure — a node instead of a whole run.
  3. Mention the three things it unlocks that retries alone cannot: human approval gates (pause before a node and the state simply waits), time-travel debugging (go back to just before the bad step and inspect state), and forking for comparison (run two variants from one checkpoint) — which is also the infrastructure evaluation is built on.
  4. Then the costs, all three. First, bigger state means slower writes, and it is written at every step: one request produces six checkpoints, so a byte added to state is six bytes written. Hence attachments hold references, not content, and retrieval results hold document ids, not full text.
  5. Second, the store has limits. With jsonb the hard cap is far away, but a row past roughly two kilobytes gets pushed to out-of-line storage and costs an extra IO on every read and write. The real engineering line is do not let a single checkpoint reach hundreds of kilobytes, not the theoretical cap.
  6. Third, the one people forget: version compatibility. Checkpoints are long-lived data, so every change to the state shape incurs migration debt, and missing fields usually do not throw — they silently yield undefined or NaN. This is why state fields should be reserved early: once a shape is persisted, changing a field is a data migration, not a code edit.
  7. Expect the follow-up: do checkpoints need cleanup? Yes — retention and archival per thread, or the table grows linearly with active users. Also treat it as sensitive data: graph state contains full conversations, so it must be included whenever you delete a user's data.

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

  1. 这题的下半句才是考点。只答「能恢复、能容错」是功能介绍，任何文档都写着；面试官想听的是你有没有算过这笔账，以及知不知道它会在哪里疼。
  2. 先把价值说具体，用钱和时间说：一次带评审回路的多 Agent 执行要调九次模型，跑到第七次进程被换版本重启，没有检查点就是九次全废、用户界面还停在转圈。有检查点则从上一个签字点接着跑，已经跑完的节点一次都不重跑——它买的是「失败的粒度从一整次执行降到一个节点」。
  3. 顺带说清它解锁的另外三件事，这三样单靠重试做不到：**人工审批闸口**（在某个节点前停下等人点确认，状态就停在那儿）、**时间旅行调试**（回到出问题那一步之前看状态长什么样）、**分叉对比**（从同一个检查点跑两种走法，比较结果，这也是评估的基础设施）。
  4. 然后是代价，三笔要说全。第一笔，**状态越大写得越慢**，而且是每一步都写一份——一次请求写六个检查点，状态里多一个字节就要多写六遍。所以附件存引用不存内容，检索结果存文档 id 不存全文。
  5. 第二笔，**存储本身有上限**。用 jsonb 存的话，硬上限很远，但单行超过大约两 KB 就会被挪到外存、每次读写多一次 IO，所以真正的工程线是「别让单个检查点变成几百 KB」，而不是那个理论上限。
  6. 第三笔也是最容易被忽略的：**版本兼容**。检查点是长期存活的数据，你每改一次状态形状就欠下一笔迁移债，而缺字段读出来通常不报错，只是静默给出 undefined 或 NaN。这一条决定了状态字段要尽早占好位子——图状态的形状一旦被持久化，改字段就不是改代码，是数据迁移。
  7. 可以预期的追问：那检查点要不要清理？答要，按会话线设保留期与归档策略，否则这张表会随日活线性膨胀；另外要留意它是敏感数据——图状态里有完整对话，删除用户数据时这张表必须一起处理。

  Key points

  • Core value: it shrinks the unit of failure from a whole run to a single node, so a nine-call run is not wasted by one restart
  • It also unlocks three things retries cannot: human approval gates, time-travel debugging, and forking from one checkpoint to compare variants — the substrate evaluation is built on
  • Cost one: bigger state writes slower, and it is written at every step — hence references for attachments and document ids for retrieval results
  • Cost two: storage limits — a jsonb row past roughly two kilobytes goes out-of-line and costs an extra IO, so the practical line is keeping a checkpoint well under hundreds of kilobytes
  • Cost three: version compatibility — every change to the state shape is migration debt, and missing fields silently yield undefined or NaN, which is why fields should be reserved early
  • Operationally you need retention and archival, and you must treat it as sensitive data: graph state holds full conversations and must be purged with the user's data

  答题要点

  • 核心价值：把失败的粒度从「一整次执行」降到「一个节点」，九次模型调用的执行不会因为一次重启全废
  • 还解锁三件重试做不到的事：人工审批闸口、时间旅行调试、从同一个检查点分叉对比（也是评估的基础设施）
  • 代价一，状态越大写得越慢，而且每一步都写一份——所以附件存引用、检索结果存文档 id
  • 代价二，存储有上限：jsonb 单行超过约两 KB 就外存、多一次 IO，工程线是别让单个检查点到几百 KB
  • 代价三，版本兼容：状态形状改一次就欠一笔迁移债，缺字段静默给出 undefined 或 NaN；所以字段要尽早占位
  • 运维上还要有保留期与归档，并把它当敏感数据处理——图状态里有完整对话，删用户数据时必须一起删

D19 Cross-Service Agent Integration: Minting a User-Level JWT, JWKS Signature Verification, the inject/memory/usage Interfaces, Idempotent externalId

• For service-to-service calls, would you use a service token or a user token? When does each apply?两个服务之间调用，你会用服务级令牌还是用户级令牌？分别适用于什么场景？

  Common in ChinaCommon overseasIntermediate#auth#security#api-design

  How to reason about it · think before answering

  1. The hinge is each. Answering user tokens are safer turns a design question into a slogan — the interviewer wants the conditions under which each one is correct, and the concrete cost of choosing wrong.
  2. Give the deciding question first: is there a specific user behind this call? If yes, it must be a user token. If not — fetching config, reporting metrics, running a reconciliation batch — a service token is the right answer, and stuffing in a user id would fabricate audit history.
  3. Then state the three reasons as costs, not virtues. A leaked service token means every user's data at once; a leaked user token means one user, and it expires in fifteen minutes. Audit logs with a service token only show that some service called, never on whose behalf. And a downstream service doing per-user authorization is forced to trust a userId in the request body, which the caller writes freely.
  4. Add the production view: it is rarely either-or. Real systems use the service credential to obtain user tokens — the caller proves who it is once, then mints a short-lived token representing one user. The service credential then appears only at the minting step, never on every business call.
  5. Expect: what if a token leaks? Answer in two layers — a short lifetime (fifteen minutes here) does most of the containment, and a jti denylist is the supplement. Do not lead with a denylist: it puts a database lookup in front of every verification and gives away the whole point of stateless verification.
  6. Expect: how fine-grained should scopes be? Offer a usable rule — split along asymmetric risk. A bad read leaks information; a bad write poisons data that keeps influencing every later turn. So read and write always split; finer than that only if a real caller genuinely needs just one half.

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

  1. 题眼在「分别」。答「用户级更安全」就把一道设计题做成了口号题——面试官想看你能不能说出两者各自成立的条件，以及选错的具体代价。
  2. 先给判断依据，一句话就能拆开：这次调用**有没有一个具体的用户在背后**。有，就必须是用户级；没有（拉配置、上报指标、跑对账批处理），服务级才是对的，硬塞一个用户 id 进去反而是伪造审计记录。
  3. 然后把用户级的三条理由说成代价而不是优点：服务级令牌泄露一次等于全量用户数据泄露，用户级泄露一张只丢一个用户且十五分钟自动作废；服务级在审计日志里只能查到「某服务调了一次」，查不到替谁操作；下游做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以随便写的。
  4. 补一句生产视角：两者不是二选一，真实系统里常常是「服务级令牌用来换用户级令牌」——调用方先用自己的服务凭证证明自己是谁，再申请一张代表某个用户的短期令牌。这样服务凭证只出现在铸造这一步，不出现在每一次业务调用里。
  5. 可以预期的追问一：令牌泄露了怎么办？答案要分两层——短有效期（本课 15 分钟）是止损的主力，撤销列表按 jti 拉黑是补充；不要上来就说「用黑名单」，那等于给每次验签加一次数据库查询，把无状态验签的好处全赔进去了。
  6. 可以预期的追问二：那 scope 该切多细？给一条可操作的判据——按「读写不对称的风险」切，读错了泄露信息、写错了污染数据且会持续影响后续每一轮对话，所以 read 和 write 必须分开；再细就要看有没有真实的调用方只需要其中一半。

  Key points

  • The deciding question is whether a specific user stands behind the call: yes means user token, no (config, metrics, reconciliation) means service token
  • A leaked service token exposes every user; a leaked user token exposes one and expires on its own
  • Auditing has to reach a person — only the sub claim answers who the call was made on behalf of
  • With a service token the downstream must trust a userId in the request body, which the caller can forge
  • Common production shape: the service credential only buys short-lived per-user tokens and never appears on business calls
  • After a leak, short lifetimes do the containment and a jti denylist supplements it — do not trade away stateless verification by default

  答题要点

  • 判断依据是「这次调用背后有没有一个具体用户」：有就用用户级，没有（配置、指标、对账批处理）才用服务级
  • 服务级令牌泄露的爆炸半径是全量用户，用户级只影响一个用户且短期自动失效
  • 审计要能落到人：只有 sub 字段能回答「当时是替谁操作的」
  • 下游要做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以伪造的
  • 生产里常见组合：服务凭证只用来换取代表某个用户的短期令牌，不出现在每次业务调用里
  • 泄露后的止损顺序是短有效期优先、jti 撤销列表补充，别一上来就上黑名单换掉无状态验签
• How do you design an idempotency key for cross-service calls — who generates it, where does it live, and what do you return on a repeat?跨服务调用的幂等键该怎么设计？由谁生成、存在哪、重复了返回什么？

  Common in ChinaCommon overseasIntermediate#idempotency#distributed-systems#api-design

  How to reason about it · think before answering

  1. This question separates people entirely on implementation detail. Anyone can define idempotency; answering who generates the key, where it lives, and what a repeat returns shows whether you have actually built one.
  2. Start with the rule: the final arbiter must be a database uniqueness constraint, not an application-level check-then-insert. Check-then-insert always passes single-process tests and produces duplicates the moment you run two replicas — both check, both find nothing, both insert. The window is too narrow to reproduce under load testing and wide enough to produce dirty rows daily in production.
  3. Who generates it: the caller, because only the caller knows that two retries are the same event. But the key must be derived from the event itself, never a fresh random UUID per retry — that is idempotency in name only. Same criterion as the user-message case from day 8.
  4. Cross-service adds one trap worth the most points: never use the caller's raw id as the key. Two different callers will eventually both produce evt-1, and the failure is not an error — the second user silently receives nothing, because their event is treated as a duplicate and the logs look clean. Namespace it: issuer plus user id plus event id, all three taken from the verified token so none of them can be forged.
  5. What to return also matters: a repeat gets 200 with the original result, not 409. Repeats are normal in distributed systems; a 409 makes the caller's retry logic treat it as a failure and the situation compounds.
  6. Expect: does this table grow forever? Yes, so give it a retention window — a TTL matching the replay window the business tolerates, say seven days, with periodic cleanup. Say plainly that a duplicate arriving after cleanup is treated as new; that is a stated trade-off, not a hole.

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

  1. 这题的区分度全在实现细节上。概念谁都会说，能不能答对「谁生成、存在哪、返回什么」这三个具体问题，直接暴露你有没有真做过。
  2. 先立一条铁律：**幂等的最终裁判必须是数据库的唯一约束**，不是应用层的「先查一下有没有」。先查后插在单进程测试里永远是对的，一上多实例就出双份——两个副本同时查、同时发现没有、同时插入，这个时间窗压测时窄到复现不出来，上线后每天出几条脏数据。
  3. 再答「谁生成」：由**调用方**生成，因为只有它知道重试的那两次是同一件事；但键必须由事件内容决定，不能是每次重试重新生成的随机 UUID——那等于没有幂等。这条和 D8 的用户消息幂等是同一条判据。
  4. 跨服务比同服务多一个坑，这是本题最有价值的一点：**调用方给的 id 不能直接当键用**。两个不同的调用方各自造出 evt-1 是迟早的事，撞车之后的表现不是报错，而是后来那个用户静默收不到消息——他的事件被当成重复丢掉了，日志里干干净净。所以落库前要加命名空间，用「签发方 + 用户 id + 事件 id」三段拼，而且三段都取自验签后的令牌，伪造不了。
  5. 「返回什么」也是个坑：重复送达要返回 200 并附上第一次的结果，不要返回 409。重复不是错误，是分布式系统的常态；回 409 会让调用方的重试逻辑把它当失败处理，越重试越乱。
  6. 可以预期的追问：这张表会不会无限涨？答「会，所以要有保留期」——按业务能接受的重放窗口设一个 TTL（比如 7 天）定期清理，同时说明清理之后超期的重复请求会被当成新事件，这是一个明确的、可接受的取舍，不是漏洞。

  Key points

  • The arbiter is a unique constraint plus on conflict do nothing; check-then-insert duplicates as soon as you run two replicas
  • The caller generates the key, but it must be derived from the event — a fresh UUID per retry is not idempotency
  • Never use the caller's raw id: namespace it with issuer plus user id plus event id, all taken from the verified token
  • A collision does not raise an error; it silently drops another user's event and leaves clean logs
  • Return 200 with the original result on a repeat, never 409, or the caller's retry logic treats success as failure
  • Give the table a retention window and state that post-cleanup repeats count as new events — a stated trade-off, not a hole

  答题要点

  • 最终裁判是数据库唯一约束加 on conflict do nothing，先查后插在多实例下必然出双份
  • 键由调用方生成，但必须由事件内容决定，随机 UUID 等于没有幂等
  • 调用方给的 id 不能直接当键：加命名空间（签发方 + 用户 id + 事件 id），三段都取自验签后的令牌
  • 撞车的后果不是报错而是另一个用户静默收不到消息，日志里看不出异常
  • 重复送达返回 200 加第一次的结果，不要返回 409，否则调用方会当失败继续重试
  • 幂等表要设保留期，超期后的重复会被当成新事件，这是明确取舍不是漏洞

D20 Scheduled Jobs and Proactive Outreach: Time Zones, Quiet Hours, Daily Caps, a Notification Provider Abstraction

• How would you implement quiet hours and a per-user daily cap, and where in the pipeline should they be evaluated?quiet hours 和每日发送上限这两条规则你会怎么实现？它们应该放在链路的哪一步判断？

  Common in ChinaCommon overseasIntermediate#rate-limiting#quiet-hours#cost-control

  How to reason about it · think before answering

  1. There are two hinges here and most candidates only answer the first. One is how to evaluate the rules (a details question), the other is where in the pipeline (an architecture question) — the second is where the points are.
  2. Start with quiet hours. Once you fold times into minutes-from-midnight, almost everyone first writes start less-or-equal now and now less-than end. That is correct for a same-day window like a lunch break, but for 22:00 to 08:00 it is always false: start is 1320, end is 480, the condition never holds, and you push at 3am. The fix is to use and when start is before end, and or when start is after end. What makes this bug nasty is that it only misfires on the cross-midnight config, so a unit test written around 13:00 to 14:00 passes.
  3. Then what to do on a hit: defer, do not drop. The decision should not be the sender's mood — attach an expiry to each candidate and drop only when it expires before the window ends, deferring everything else to the window's end. A thirty-minute cancellation warning is worthless tomorrow; a billing summary is just as valid at 8am. Mention the thundering herd too: every deferred message resolves to the same due instant, so add jitter derived from a hash of the user id, never a random number, or you cannot reproduce incidents.
  4. Now two details on the daily cap. First, the day must be the user's local calendar day; keying on the UTC date charges an East-Asian user's 8am message to yesterday's budget. Second, increment first and check the returned value, then give the slot back if it exceeded — a read-then-write races, letting two candidates read the same count and both go out. Return the slot on a hard rejection from the channel as well.
  5. Finish with the architecture half, which is the valuable part: all three gates must run before the content is generated, not at the send step. Get the order wrong and the program still works and sends the same messages; the only difference is that you paid for a model call on every message you then threw away. At 1000 users, three candidates each per day, forty percent blocked and roughly $0.00075 per message, that is about $27 a month wasted — more than the normal conversational spend for the same cohort — and it is invisible in monitoring. Only putting candidate count next to sent count reveals the gap.
  6. Expect: what order do the three gates run in? Timezone, quiet hours, daily cap, with the cap last. A message deferred to tomorrow morning must not consume today's quota; reverse the order and users get rate-limited despite having received almost nothing.

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

  1. 这题有两个题眼，很多人只答了前一个。第一个是「怎么判断」（细节题），第二个是「放在哪一步」（架构题），后者才是拿分点。
  2. 先讲 quiet hours 的判断。把时刻折成从午夜起算的分钟数之后，绝大多数人第一次都会写成 start 小于等于 now 且 now 小于 end。这对午休那种同日区间是对的，对 22:00 到 08:00 恒为 false——start 是 1320、end 是 480，条件永远不成立，于是半夜照发。正确写法是 start 小于 end 时用「且」，start 大于 end（跨午夜）时换成「或」。这个 bug 恶劣在只在跨午夜的配置上错，用 13:00 到 14:00 写的单元测试全绿。
  3. 接着是命中之后怎么办：推迟，不是丢弃。判据不该由发送方临时决定，而应该由消息自己带一个过期时刻——过期时刻早于窗口结束的丢弃，其余一律推迟到窗口结束。限时取消提醒过了今晚就没意义，账单提醒明早发一样有效。另外要提一句惊群：所有推迟的消息会算出同一个到期时刻，要加一个按用户标识哈希得出的抖动（不能用随机数，否则线上复现不了）。
  4. 再讲每日上限的两个细节。一是「一天」必须是**用户本地日历日**，写成 UTC 日的话东八区用户早上八点前发的会算进昨天的额度。二是必须先占坑再判断——原子自增拿返回值比上限，超了再把名额还回去；先查后写在并发下两条候选会同时读到同一个值然后一起发出去。渠道明确拒绝时也要把名额还回去。
  5. 最后是架构题那一半，也是最值钱的一段：三道闸必须在**生成内容之前**判断，不是在发送那一步。顺序错了程序照样跑通、发出的消息也一样，唯一区别是每条被拦下的消息你都已经付过一次模型调用的钱。按 1000 用户每天各 3 条候选、拦掉四成、单条约 0.00075 美元算，一个月白花约 27 美元，比这批用户的正常对话开销还高，而且监控上完全看不出来——只有把候选数和实际发送数并排摆出来才看得见差额。
  6. 可以预期的追问：三道闸内部谁先谁后？答时区、安静时段、每日上限，上限必须最后。因为被安静时段推迟的消息明早才发，不该占掉今天的名额；顺序反了用户会发现自己明明没收到几条却被限流了。

  Key points

  • Cross-midnight quiet hours need or when start is after end; the naive and version is always false for 22:00-08:00
  • On a hit, defer to the end of the window rather than drop; only drop when the message's own expiry precedes that
  • Deferral causes a thundering herd, so add jitter hashed from the user id, never a random value
  • The day in a daily cap must be the user's local calendar day, not the UTC date
  • Increment atomically then compare and release on overflow; read-then-write over-sends under concurrency
  • Run all three gates before generating content — otherwise every blocked message has already been paid for (about $27/month at the example scale); order them timezone, quiet hours, daily cap, with the cap last

  答题要点

  • 跨午夜的安静时段：start 小于 end 用「且」，start 大于 end 换成「或」，朴素写法对 22:00-08:00 恒为 false
  • 命中安静时段是推迟到窗口结束而不是丢弃；只有自带的过期时刻早于窗口结束才丢
  • 推迟会造成惊群，要加按用户标识哈希得出的抖动，不能用随机数
  • 每日上限的「天」必须是用户本地日历日，不是 UTC 日
  • 计数要先占坑再判断（原子自增后比上限，超了还回去），先查后写在并发下会超发
  • 三道闸必须在生成内容之前判断，装晚了每条被拦的消息都已经付过模型调用的钱（示例量级约 27 美元每月）；闸内顺序是时区、安静时段、每日上限，上限最后
• You have abstracted model calls, payments and notification channels behind providers. How does the notification interface differ from the other two?模型调用、支付、通知渠道你都做过 provider 抽象。通知这一份接口和另外两份有什么不同？

  Common in ChinaCommon overseasIntermediate#provider-abstraction#api-design#retry-semantics

  How to reason about it · think before answering

  1. This question separates applying a pattern from understanding one. Saying all three are the same — an interface with several implementations so you can swap vendors without touching business code — only covers the shared part; the interviewer wants to see whether you spotted the differences and encoded them in the interface.
  2. Acknowledge the commonality in one line: each pushes a replaceable dependency behind an interface, business code depends only on the interface, and the selection point lives in exactly one place. Correct, but not differentiating.
  3. Then give three differences, which is where the points are. First, accepted is not delivered: when a payment gateway returns success the money has moved, but when a notification channel returns success it has merely taken the message, and actual delivery arrives later as an asynchronous receipt. So the result is accepted, never delivered, and it must carry the provider-side message id so the receipt can be correlated.
  4. Second, throttling lives at a different layer: the channel has its own per-second ceiling and tells you to come back later with a 429 plus a retry interval — a channel-level technical constraint — while the daily cap is a user-level courtesy constraint. Collapsing them into one concept makes them impossible to tune separately: one says this line is congested, the other says this person has been interrupted enough today.
  5. Third, there is no undo: payments have refunds, notifications do not. Once handed to the channel the message is gone, and cancel only means anything before that handoff. So the interface must not expose a cancel method — leaving an operation that cannot work is worse than not having it, because callers will actually use it.
  6. Expect: how do you design retries then? Three classes. Throttling backs off for the interval the channel gave you. Parameter errors (invalid body, unsubscribed user) are not retryable, so give up and return the daily slot. Server errors and timeouts are retryable but must carry the same idempotency key — you can delete a duplicate row, you cannot un-buzz a phone. Add a test for the abstraction itself: if a new channel only has to implement send the message, the boundary is right; if it also needs to know whether it is quiet hours or which message of the day this is, business rules have leaked into the channel layer.

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

  1. 这题在考你是「会套模式」还是「懂模式」。把三者说成一回事——都是接口加多个实现、换厂商不改业务——只答到了共性那一层，面试官真正想看的是你有没有识别出差异并把它写进接口。
  2. 先给共性，一句话带过：都是把「会被替换的东西」推到接口后面，业务代码只认接口，选择点集中在一处。这一层是对的，但不构成区分度。
  3. 然后给三条差异，这是拿分点。第一，收下不等于送达：支付网关返回成功钱就划走了，通知渠道返回成功只表示它收下了，真正送达是过一会儿通过回执异步告诉你的。所以返回值只能叫 accepted 不能叫 delivered，而且必须带渠道侧的消息标识，回执回来时靠它对上号。
  4. 第二，限流的层次不同：渠道自带每秒条数上限并会用 429 加重试间隔告诉你稍后再来，这是**渠道维度的技术约束**；而每日发送上限是**用户维度的礼貌约束**。两者混成一个概念就没法分别调整——一个说的是这条线路挤不下了，一个说的是这个人今天已经被打扰够了。
  5. 第三，没有撤销：支付有退款，通知发出去就撤不回来，取消只在交给渠道之前有效。所以接口里不能出现 cancel——在接口上留一个做不到的操作比根本没有这个操作更危险，调用方会真的去用它。
  6. 可以预期的追问：那失败重试怎么设计？答分三类：限流按渠道给的时长退避重试；参数错（正文非法、用户已退订）不可重试，直接放弃并把当天的名额还回去；服务端错误或超时可重试但必须带同一个幂等键——数据库里多一行你能删掉，用户手机上多响一声删不掉。再补一条判断抽象好坏的判据：新接一个渠道时如果它只需要实现「把这条消息发出去」，抽象就对了；如果它还得知道现在是不是安静时段、这是今天第几条，说明业务规则泄进了渠道层。

  Key points

  • The shared part is pushing a replaceable dependency behind an interface with a single selection point — that is only the baseline
  • Accepted is not delivered: name the result accepted and carry a provider message id so async receipts can be correlated
  • Throttling has two layers: the channel's per-second ceiling is technical, the daily cap is a user-level courtesy rule, and they must stay separate
  • Notifications have no undo, so the interface must not expose cancel — an unimplementable operation is worse than none
  • Three retry classes: back off for the channel's interval on throttling, give up and release the slot on parameter errors, retry server errors with the same idempotency key
  • Test the boundary: a new channel should only implement send; needing to know quiet hours or today's count means business rules leaked into the channel

  答题要点

  • 共性是把可替换依赖推到接口后面、选择点集中一处，但这只是及格线
  • 收下不等于送达：返回值叫 accepted 不叫 delivered，必须带渠道侧消息标识以便异步回执对号
  • 限流分两层：渠道的每秒上限是技术约束，每日发送上限是用户维度的礼貌约束，不能合并
  • 通知没有撤销，接口里不能有 cancel；留一个做不到的操作比没有更危险
  • 重试分三类：限流按渠道给的时长退避、参数错不可重试并归还名额、服务端错误可重试但必须带同一个幂等键
  • 判断抽象切没切对：新渠道只需实现发送就对了，还要知道安静时段和当天条数就说明业务泄进了渠道层

D21 Evaluation and Observability: a Golden Set, LLM-as-Judge, Tracing, a Failure-Rate/Cost Dashboard; Pi vs. LangGraph Summary; Week Three Retrospective

• How do you evaluate an agent's quality, and how does it differ from testing a conventional backend service?怎么评估一个 Agent 的效果？和传统后端服务的测试有什么不同？

  Common in ChinaCommon overseasIntermediate#evaluation#testing#agent-quality

  How to reason about it · think before answering

  1. The hinge is differ. Answering build a test set and measure accuracy is the textbook ML answer and misses the point; the interviewer wants to know whether you can articulate what makes agents special here.
  2. The root difference is one sentence: the same input does not guarantee the same output. Conventional tests assert equality, but an agent's output has no single correct answer, only good enough. Once the assertion changes from equality to scoring, the whole methodology changes with it.
  3. That difference cascades into three consequences, and covering all three secures the question. First, whether it ran tells you nothing about quality — the flow not throwing does not mean the reply stated the refund conclusion. Second, the blast radius of a change is diffuse: a one-word prompt edit may affect only one class of request, and hand-checking five samples that happen to miss that class yields no impact, then you ship. Third, multi-agent adds a layer: one request passes routing, planning, parallel execution, review and aggregation, and any one of them going wrong surfaces as that last paragraph seems off — without measuring each stage you cannot tell which to fix.
  4. So frame it: evaluation is not testing. Evaluation establishes a comparable baseline for a stochastic system. Its output is not pass or fail but a number you can compare against last time — and to compare, the sample set must be frozen.
  5. Then get concrete: a small stable golden set (15 items here), each declaring its expected route and a checklist of facts the reply must contain; an LLM-as-judge scoring against that checklist; and evaluation results joined to tracing on one dashboard. The checklist is the key move — it converts is this a good answer, which cannot be verified, into were these facts stated, which can.
  6. Expect: do you still need unit tests? Yes, with a clean split — deterministic parts (tool functions, state transitions, reducers) keep asserting equality in unit tests, while evaluation covers only the model-generated segment. Merge the two and you get a suite that fails randomly, after which everyone starts ignoring CI.

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

  1. 题眼是「不同」。只答「建一个测试集跑准确率」拿不到分——那是机器学习的标准答案，面试官想看你能不能说清 Agent 这个场景特殊在哪。
  2. 根子上的差别只有一句：**同样的输入，Agent 不保证给同样的输出**。传统测试的断言是「等于」，而 Agent 的产出没有唯一正确答案，只有「够不够好」。断言从等值变成了判分，整套方法论跟着变。
  3. 这条差别连锁出三个后果，说全了这题就稳了：一是**跑没跑通判断不了质量**——流程没抛错，不等于回复里写明了退款结论；二是**改动的影响是弥散的**，改一个字的提示词可能只影响一类请求，人肉抽查五条恰好没覆盖到，你会得出「没影响」然后上线；三是**多 Agent 又难一层**，一次请求走路由、拆分、并行执行、评审、汇总五道工序，任何一道歪了都表现成「最后那段话不太对」，不分开量就不知道该改哪块。
  4. 所以给出定位：**评估不是测试，评估是给一个随机系统建立一条可比较的基线。** 它的产物不是「通过」或「不通过」，而是一个能和上一次比的数字。既然要比，样本集就必须固定。
  5. 然后落到具体做法：一个小而稳的 golden set（本课 15 条），每条写清期望走哪条路由和一份必备信息清单；用 LLM-as-judge 对照清单打分；把评估结果和链路追踪接到同一块面板上。**清单是关键**——它把「这答得好吗」这种没法验的问题，换成了「这几件事写没写」这种能验的问题。
  6. 可以预期的追问：那还需要单元测试吗？需要，而且分工很清楚——工具函数、状态迁移、reducer 这些确定性的部分照旧用单元测试断言等值，评估只负责模型产出那一段。把两者混成一套，你会得到一堆随机失败的测试，然后所有人开始无视 CI。

  Key points

  • The root difference: identical input does not guarantee identical output, so the assertion shifts from equality to good enough
  • Three consequences: running is not quality, change impact is diffuse (sampling misses it), and in multi-agent any of five stages failing looks like the same symptom
  • Framing: evaluation is not testing — it establishes a comparable baseline for a stochastic system, yielding a number rather than pass/fail
  • Method: a small stable golden set, a required-facts checklist per item, an LLM-as-judge, and a dashboard sharing tracing's data source
  • The checklist is the key move: it converts is this good into were these facts stated — unverifiable into verifiable
  • Unit tests remain for deterministic parts; merging the two makes CI fail randomly until everyone ignores it

  答题要点

  • 根本差别：同样的输入 Agent 不保证同样的输出，断言从「等于」变成「够不够好」
  • 三个后果：跑通不等于质量合格、改动影响弥散（抽查会漏）、多 Agent 里五道工序任一歪了都表现成同一个症状
  • 定位：评估不是测试，是给随机系统建一条可比较的基线，产物是能和上次比的数字而不是通过与否
  • 做法：小而稳的 golden set + 每条的必备信息清单 + LLM-as-judge 打分 + 与 tracing 同源的面板
  • 清单是关键，它把「答得好吗」换成「这几件事写没写」，从没法验变成能验
  • 单元测试仍然需要，负责确定性部分；两者混在一起会让 CI 随机变红，最后被所有人无视
• What does observability look like for a multi-agent system, and how does it differ from a single agent?多 Agent 系统的可观测性要看哪些东西？和单 Agent 有什么不一样？

  Common in ChinaCommon overseasIntermediate#observability#tracing#distributed-systems

  How to reason about it · think before answering

  1. The hinge is differ. Saying add logs and metrics is a non-answer; name the structural difference.
  2. In one sentence: a single agent's call is a line, a multi-agent request is a tree. One request goes supervisor routing, planner splitting into three, three executors in parallel, a critic rejecting one, that one rerunning, then aggregation — flattened by time you cannot see nesting or which two ran concurrently.
  3. So spans must carry a parent pointer; that is the whole game. With it you have a tree, without it a flat list where you know what happened but not what triggered what. A span needs surprisingly few fields — id, parent, name, start and end, a few attributes — to reconstruct the entire tree.
  4. How the parent propagates is itself an interview point: do not thread a parentSpanId parameter through every function, because each new node then changes a signature and one omission breaks the chain. Use the language's implicit context — AsyncLocalStorage in JS, contextvars in Python, TaskLocal in Swift, and ScopedValue or ThreadLocal with explicit propagation across thread pools in Java.
  5. Then the four questions a dashboard must answer: how much is wrong (pass rate, routing accuracy, degradation rate, fallback rate), where is it slow (p50/p95), what did it cost, and which role spent the money (cost attributed per node). That last one is multi-agent specific and the most actionable — measured, executor nodes took over a third of spend, telling you immediately where to optimise.
  6. One foundational point: the dashboard is not a second instrumentation layer, it is an aggregation of traces. The same raw data read across is a tree and stacked up is a dashboard. Two separate sources will eventually disagree, after which nobody trusts either.
  7. Finally, tie back to routing: the routing decision is made by a model and the same sentence may route differently next time, so the routing rationale must be recorded — if you do not capture it then, that judgement is gone forever. It is the easiest thing to omit and the thing most needing post-hoc audit.

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

  1. 题眼在「不一样」。答「加日志加监控」等于没答，要说清结构上的差别。
  2. 结构差别一句话：**单 Agent 的一次调用是一条线，多 Agent 是一棵树。** 一次请求走监督者路由、规划者拆三件、三个执行者并行、评审者打回一件、那件重跑、最后汇总——按时间平铺看不出谁在谁里面，也看不出哪两个是并行的。
  3. 所以 span 必须带**父指针**，这是全部关键：有它才是树，没它只是一张平铺列表，你知道发生过什么，却不知道谁触发了谁。一条 span 的字段少得出奇——id、父指针、名字、起止时刻、几个属性，就够还原整棵树。
  4. 父子关系怎么传下去也是个考点：**不要在每个函数上加一个 parentSpanId 参数**，每加一个节点都要改签名、漏一处断一截。用语言自带的隐式上下文——JS 的 AsyncLocalStorage、Python 的 contextvars、Swift 的 TaskLocal，Java 用 ScopedValue 或 ThreadLocal 配合线程池的显式传播。
  5. 然后说面板要回答哪四个问题：错了多少（通过率、路由准确率、降级率、兜底率）、慢在哪（p50/p95）、花了多少、**钱花在哪个角色身上**（按节点分摊）。最后一样是多 Agent 特有的，也最有用——实测执行者节点占了成本三分之一强，一眼就知道压成本先压哪儿。
  6. 还有一条地基性的：**面板不是另一套埋点，是 trace 的聚合**。同一份原始数据横着看是树、竖着堆是面板。两套数据来源迟早会对不上，然后没有人相信任何一个。
  7. 最后回指路由：路由决策是模型做的，同一句话下次未必给同样的答案，所以必须把**路由理由**一起记下来——当时不记，那次判断就永远丢了。这是多 Agent 里最容易漏、又最需要事后审计的一条。

  Key points

  • Structural difference: a single agent call is a line, multi-agent is a tree (route, split, parallel execute, critic reject, rerun, aggregate)
  • Spans need a parent pointer, or you have a flat list showing neither nesting nor parallelism
  • Propagate parentage through implicit context (AsyncLocalStorage / contextvars / TaskLocal), not a parameter on every signature
  • The dashboard answers four questions: how much is wrong, where it is slow, what it cost, and which role spent it — the last is multi-agent specific and most actionable
  • The dashboard must be an aggregation of traces, not separate instrumentation; two sources will disagree
  • Record the routing rationale: routing is a model decision, and uncaptured it is lost forever

  答题要点

  • 结构差别：单 Agent 一次调用是一条线，多 Agent 是一棵树（路由→拆分→并行执行→评审打回→重跑→汇总）
  • span 必须带父指针，否则只是平铺列表，看不出嵌套关系也看不出并行
  • 父子关系用语言自带的隐式上下文传（AsyncLocalStorage / contextvars / TaskLocal），不要在每个函数签名上加参数
  • 面板回答四个问题：错了多少、慢在哪、花了多少、钱花在哪个角色身上（最后一个是多 Agent 特有且最有用）
  • 面板必须是 trace 的聚合而不是另一套埋点，两套数据源迟早对不上
  • 路由理由必须记下来：路由是模型做的决策，当时不记那次判断就永远丢了
• When should you reach for an orchestration framework like LangGraph, and when should you not?什么时候该用 LangGraph 这类编排框架，什么时候不该用？

  Common in ChinaCommon overseasIntermediate#architecture#framework-selection#langgraph

  How to reason about it · think before answering

  1. The trap is answering with a feature matrix. The interviewer wants criteria, specifically criteria that can also say do not use it — people who can only argue for adoption usually have not been burned by a framework.
  2. Start with three criteria for splitting at all (if none holds, do not split and do not add a framework): the prompt contains mutually exclusive behavioural demands (rigorous and playful at once, where tuning one breaks the other); tools have grown numerous enough that selection error is visibly rising; or some step needs its own failure and retry semantics (an inventory lookup should retry, a refund draft should escalate to a human, and they cannot share one policy).
  3. Then the framework criterion, which is one sentence: if multiple roles write the same state concurrently, it must be explicit; if you do not need concurrency, explicitness is pure overhead. LangGraph's value is declaring merge rules on the field — with three executors writing one workspace, how those writes combine has to be declared somewhere. Conversely, with two tools and a loop that runs at most twice, a while and a switch suffice and a framework is a net loss.
  4. When comparing against a higher-level SDK like Pi, use dimensions rather than features: onboarding cost (Pi's defaults make it fast, at the price of it choosing your model and persona); explicitness of state (Pi keeps history inside the session, so when you want to change how one workspace merges there is no place to change it); and debugging shape (Pi gives an event stream, one timeline; LangGraph gives per-node deltas and checkpoints, a replayable and forkable tree — linear problems read faster as a timeline, multi-role problems require the tree).
  5. Cross-language deserves its own mention because it is routinely forgotten: neither Java nor Swift has LangGraph, so a polyglot team either standardises on TS/Python or hand-writes the same structure. Pricing that in during selection is cheaper than discovering it after launch.
  6. Expect: so how do you choose? Give something actionable: do you fear invisible defaults more, or endless boilerplate more? Fear the former and pick the explicit framework; fear the latter and pick the high-level SDK. That sentence is more useful than any feature table.

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

  1. 这题最怕答成特性对比表。面试官想听的是判据，而且是能反过来说「不该用」的判据——只会说该用的人，通常是没被框架坑过的人。
  2. 先给三条该拆的判据（一条都不命中就别拆，也别引框架）：**提示词里出现了互斥的行为要求**（既要严谨又要俏皮，调好一个另一个就坏）；**工具多到选错率明显上升**；**某一步需要独立的失败与重试语义**（比如查库存失败该重试，拟退款方案失败该转人工，两者不能共用一套策略）。
  3. 然后给框架本身的判据，核心是一句：**要让多个角色并行写同一份状态，就必须显式；不需要并行，显式就是纯负担。** LangGraph 的价值是把合并规则声明在字段上——三个执行者并行写同一个工作区，谁的写入怎么合并，这件事必须有地方声明。反过来，一两个工具、循环最多两轮的场景，一个 while 加一个 switch 就够了，引入框架是净亏。
  4. 对比 Pi 这类高层 SDK 时，用维度而不是特性：上手成本（Pi 默认值多所以快，代价是模型和人设都是它替你挑的）、状态管理的显式程度（Pi 的历史在会话内部你感知不到，所以想改「同一个工作区怎么合并」时根本没有位置可改）、调试形态（Pi 给事件流是一条时间线，LangGraph 给逐节点增量和检查点是一棵可回放可分叉的树——**线性问题看时间线更快，多角色问题必须看树**）。
  5. 跨语言这条值得单独提，因为它常被忽略：**Java 和 Swift 都没有 LangGraph**，跨语言团队要么统一到 TS/Python，要么自己手写同一套结构。选框架的时候把这条算进去，比上线后再发现便宜。
  6. 可以预期的追问：那你怎么选？给一句可执行的：**你更怕看不见的默认值，还是更怕写不完的样板？** 怕前者选显式框架，怕后者选高层 SDK。这句话比任何特性表都实用。

  Key points

  • First decide whether to split at all: mutually exclusive prompt demands, rising tool-selection error, or a step needing its own retry semantics — none holding means no split and no framework
  • The framework criterion in one line: concurrent writes to shared state require explicitness; without concurrency, explicitness is pure overhead
  • LangGraph's value is declaring merge rules on the field; Pi keeps history inside the session, leaving nowhere to change merge behaviour
  • Different debugging shapes: an event stream is a timeline, per-node deltas plus checkpoints are a replayable forkable tree — timelines for linear problems, trees for multi-role ones
  • Neither Java nor Swift has LangGraph, so polyglot teams standardise or hand-write the structure — price that in at selection time
  • An actionable heuristic: fear invisible defaults, choose the explicit framework; fear endless boilerplate, choose the high-level SDK

  答题要点

  • 先答该不该拆：提示词有互斥的行为要求、工具多到选错率上升、某步需要独立的失败与重试语义——一条不命中就别拆也别引框架
  • 框架判据一句话：多个角色并行写同一份状态就必须显式；不需要并行，显式就是纯负担
  • LangGraph 的价值是把合并规则声明在字段上；Pi 的历史在会话内部，想改合并方式根本没有位置可改
  • 调试形态不同：事件流是一条时间线，逐节点增量加检查点是一棵可回放可分叉的树；线性问题看时间线，多角色问题必须看树
  • Java 和 Swift 都没有 LangGraph，跨语言团队要么统一栈要么手写同一套结构，选型时就要算进去
  • 一句可执行的选型判据：更怕看不见的默认值就选显式框架，更怕写不完的样板就选高层 SDK