面试题库

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

D18 历史保真与摘要、多模态占位、checkpointer 持久化

• 从 checkpoint 恢复执行（replay）需要注意什么？说几个真实会踩的坑。What do you need to watch out for when replaying execution from a checkpoint? Give failure modes you would actually hit.

  国内高频海外高频深入#checkpointing#replay#reliability

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

  1. 这题最容易答成「读出来接着跑就行」。区分度在于你能不能说出**这些坑几乎全是静默的**——不抛异常、日志干净、结果看起来也对，只有对比数据时才发现不对。能说出这一点，答案就已经赢了一半。
  2. 先给一条推导链：检查点里存的是「当时那个版本的代码眼里的状态形状」，恢复就是把它塞回今天这个版本的代码里。所以所有坑都来自**两端不一致**：数据的形状、执行的入口、和那些不该被重放的东西。
  3. 坑一，恢复时又把输入喂了一遍。恢复的入口是不带输入地调用，状态已经在检查点里；带着原来那句话再调一次，框架会把它当成一次新的状态更新叠在中断点上，历史变成两份。它不报错。
  4. 坑二，分叉忘了带检查点 id。只给会话 id 拿到的是这条线最新的状态，于是「从第 2 步重来」变成了「在最后一步后面接着写」。同样不报错，只有对比子任务列表才看得出来。
  5. 坑三，版本兼容。改一个字段名、加一个必填字段，库里的老检查点就和新代码对不上；而缺字段读出来是 undefined，拼进文案就是字符串「undefined」，参与算术就是 NaN——比如工具预算的上限判断，一旦变成 NaN 比较，恒为假，预算上限在恢复出来的那条线上彻底失效。正确做法是在读的那一侧迁移，迁移函数只补默认值和改名、不做业务判断，绝不能失败。
  6. 坑四，不该被重放的东西进了状态。一次性的人工干预（比如人工改派）如果写进图状态，就会被检查点持久化并在每次恢复时重放一遍。判断口径：这条信息说的是「这一次执行怎么跑」还是「这个会话是什么」，前者进运行时配置，后者才进状态。
  7. 可以预期的追问：待执行的并行子任务存不存？答存——检查点里除了状态快照还有一份「还没跑的那几步，连参数一起」，所以恢复不用重跑规划节点；但它存在框架的内部通道里，自研存储层只实现「存状态」而漏掉这一半，恢复出来的图会看起来跑完了、其实一件活都没派出去。

  How to reason about it · think before answering

  1. The easy failure is answering just load it and keep going. The discriminator is recognising that almost every replay bug is silent — no exception, clean logs, plausible output, and you only notice when you diff the data. Saying that up front wins half the question.
  2. Give a chain first: a checkpoint stores the state shape as the code of that moment understood it, and replay pushes it back into today's code. So every failure comes from a mismatch across those two ends — the shape of the data, the entry point of execution, and things that should never have been replayed at all.
  3. Trap one: feeding the input again on resume. Resume takes no input; the state is already in the checkpoint. Passing the original message once more makes the framework treat it as a fresh update stacked on the interrupt point, and the history quietly doubles. Nothing throws.
  4. Trap two: forking without a checkpoint id. With only the thread id you get that thread's latest state, so start over from step 2 silently becomes append after the last step. Again nothing throws; you only see it by diffing the task list.
  5. Trap three: version drift. Rename a field or add a required one and every old checkpoint stops matching the new code. A missing field reads as undefined, which renders as the literal string undefined in user-facing text and as NaN in arithmetic — a tool-budget ceiling compared against NaN is always false, so the budget silently stops existing on resumed threads. Migrate on read, and keep the migration to defaults and renames only: it must never fail.
  6. Trap four: replayable data that should not be replayed. A one-off human override written into graph state gets checkpointed and re-applied on every resume. The test: does this describe how this run executes, or what this conversation is? The former belongs in runtime config, only the latter in state.
  7. Expect the follow-up: are pending parallel tasks preserved? Yes — a checkpoint holds not just the state snapshot but the steps not yet run, arguments included, so the planner does not re-run. But they live in a framework-internal channel, so a hand-rolled store that persists state and forgets that half will resume into a graph that looks finished while no work was ever dispatched.

  答题要点

  • 先点破共性：replay 的坑几乎全是静默的，不报错、日志干净、结果看着也对
  • 恢复不要带输入，带了就是在中断点上又追加一次，历史变成两份
  • 分叉必须带检查点 id，只给会话 id 会落在最新状态上，「从第 2 步重来」变成「接着往后写」
  • 版本兼容：缺字段读出来是 undefined 或 NaN，会让预算上限之类的比较恒为假；在读的那一侧迁移，迁移只补默认值和改名且不能失败
  • 一次性的人工干预不要进图状态，否则会被持久化并在每次恢复时重放；「这次怎么跑」进配置，「这个会话是什么」才进状态
  • 待执行的并行子任务连参数一起存在检查点里，所以恢复不重跑规划；自研存储层漏掉这一半，恢复出来的图会一件活都不派

  Key points

  • Lead with the pattern: replay bugs are almost all silent — no exception, clean logs, plausible output
  • Resume takes no input; passing one appends another update at the interrupt point and doubles the history
  • Forking requires the checkpoint id — thread id alone lands on the latest state, turning start over from step 2 into append after the end
  • Version drift: missing fields read as undefined or NaN, so comparisons like a tool-budget ceiling become permanently false. Migrate on read, restricted to defaults and renames, and never let it fail
  • Keep one-off human overrides out of graph state or they get persisted and re-applied on every resume — how this run executes belongs in config, what this conversation is belongs in state
  • Pending parallel tasks are stored with their arguments, so the planner does not re-run; a hand-rolled store that skips that half resumes into a graph that dispatches nothing
• checkpointer 在多 Agent 系统里解决了什么问题？它的代价是什么？What problem does a checkpointer solve in a multi-agent system, and what does it cost?

  国内高频海外高频进阶#checkpointing#cost#operations

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

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

  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.

  答题要点

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

  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