SCOPE本章边界
本章专讲长任务如何在中断、半执行和外部状态变化后恢复。这里把 replay、retry 和 time travel 的副作用语义讲清楚，其他章只复用这套分法。
30 SEC面试开口版
我会把 Agent 可靠性设计成 durable facts + recovery gates + idempotent effects。模型、工具、权限、artifact、context projection、验证结果都要写事件账本；外部副作用要有幂等键、锁、事务或补偿；恢复时先重建 session/runtime binding，再扫描 interrupted run、pending effect 和未完成 tool pair，最后从安全边界继续、分叉或请求人工确认。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Durable Facts：可持久化事实。 Recovery Gate：恢复前的安全检查门。 Idempotency：重复执行仍保持同一效果。 Pending Effect：未确认完成的副作用。 Replay：从记录事实重建视图或模拟轨迹。 |
| 为什么这样回答 | 可靠性题最怕只说重试。先讲事实源和副作用语义，面试官会知道你考虑过崩溃、重复执行和恢复安全。 |
| 小白解析 | 不是摔倒了就一直重跑，而是先看账本：做到哪一步、钱扣没扣、文件写没写、还能不能安全继续。 |
| 关联知识点 | Guga M5 明确采用 append-only session/event/artifact store；LangGraph durable execution 强调 checkpoint、determinism、idempotent side effects。 |
1 MIN一分钟口语版
我的可靠性分五层。第一，事件事实源：run、turn、model request、tool intent、permission、execution、artifact、context decision、verification 都要有 durable event。第二，副作用治理：写文件用 patch/atomic/write set，API 写入用 idempotency key，无法回滚就标记需要人工确认。第三，恢复协议：resume 时不相信内存，重建 conversation、workspace、tool registry、permission mode 和 artifact refs。第四，回放模式分开：诊断 replay 不重跑副作用，simulation replay 写成新 trajectory，live retry 重新走权限。第五，产品层要有 interrupt、resume、fork、rollback、handoff 和失败解释。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Append-only Event Log：只追加事实日志。 Atomic Write：原子写入。 Simulation Replay：模拟回放。 Live Retry：真实重试。 Fork：从历史节点分叉。 |
| 为什么这样回答 | 一分钟版要覆盖存储、执行、恢复、回放、产品五层，避免可靠性只停留在后端存储。 |
| 小白解析 | 长任务像长途运输：有运单、GPS、交接单、损坏处理和备用路线，车坏了也知道货在哪里。 |
| 关联知识点 | learn-agent hosted harness 把 job、workspace、sandbox、secret、durable step、worker lease 分开；Guga JSONL session store 支持 revision、idempotency 和 corruption diagnostics。 |
FLOW从故障到安全继续
可靠性恢复链路
COMPARE主流方案怎么讲
LangGraph
LangGraph durable execution 通过 checkpointer 保存进度，要求非确定性和副作用放进 task，并强调 idempotent side effects 和恢复语义。
Temporal / Durable Workflow 思路
长任务系统通常把状态、步骤结果和副作用边界外部化，让 worker 重启后能从历史恢复，而不是依赖进程栈。
OpenAI / Agent 平台
Tracing、sessions、guardrails 和 hosted tools 展示了运行轨迹、状态和控制面都需要成为可观察对象。
Guga / learn-agent
Guga M5 把 session/event/artifact/replay 作为 memory-ready substrate；learn-agent hosted harness 讨论 worker、lease、vault、artifact 和 notification。
DESIGN我会怎么设计
- Event Storeappend-only，带 session id、branch id、revision、schema version、actor、causation、idempotency key。
- Effect Ledger记录准备执行、已经执行、是否可回滚、外部 id、补偿路径和确认状态。
- Resume Gate恢复时检查 tool pair、workspace diff、pending effects、permission mode、artifact availability 和 context projection。
- Replay Modes诊断回放不重跑世界；模拟回放走 mock/frozen provider；真实重试重新走权限和幂等。
- User Control用户可以暂停、恢复、分叉、回滚、查看失败解释和批准高风险恢复动作。
TRADEOFF常见问题和优化
问题：每步持久化太慢
按风险选择 durability mode：低风险异步写，高风险副作用前后同步写，关键 checkpoint 强一致。
问题：重试可能重复副作用
写操作必须带幂等键、外部 request id 或补偿策略；恢复默认保守，不自动重跑未知状态。
问题：日志很多难诊断
event log 是事实源，trace view 是诊断投影；不要把所有日志原样给用户。
问题：恢复后上下文变旧
resume 时重建 runtime binding 和 context projection，检查 workspace、资源、权限和 active plan 是否仍有效。
REVISIONPending effect 恢复案例
如果事件账本里只有 effect_started(api.create_ticket, idempotency_key=k)，没有 effect_completed，恢复时不能直接重试。第一步用 k 查询外部系统；查到已创建，就补写 completed event 和外部 ticket id；查不到，且 API 支持幂等，才允许 retry；查不到且 API 不支持幂等，进入 need_human，让用户确认是否可能已产生副作用。写文件也类似：atomic rename 崩溃后先检查 temp file、目标 hash 和 write set，再决定补交、回滚或人工确认。
LangGraph checkpoint / persistence 很有价值，但 checkpoint 不天然解决外部副作用一致性。time travel 会重新执行 checkpoint 后节点，所以要把它和 diagnostic replay 分开讲。
REVISIONCancel 如何传播
| 位置 | 取消动作 | 完成后状态 |
|---|---|---|
| 模型 streaming | abort provider stream，写 cancel_requested 和 model_abort 事件。 | 不再追加模型输出；保留已生成片段为 partial artifact。 |
| 本地工具进程 | 向 process group 发终止信号，超时后强杀，收集 stdout/stderr 和 exit 状态。 | tool_cancelled / tool_killed，进入 pending effect scan。 |
| 外部 API 工具 | 如果请求已发出，使用 idempotency key 查询外部状态；不盲目重试或反向补偿。 | completed、cancelled、unknown_pending 三选一。 |
| 子 Agent | 父 run 广播 cancel token；子 run 写 cancel_requested，停止继续委派和高风险动作。 | child_cancel_ack 或 child_cancel_failed。 |
| 最终 run | 保存 partial artifacts、已完成证据、未确认副作用和下一步恢复建议。 | cancelled / interrupted，不伪装成 failed 或 completed。 |
取消不是简单把 UI 状态改成停止，而是要让模型、工具、子任务和副作用账本都收敛到一个可解释状态。
INTERVIEW高强度追问
面试官：Agent 长任务最常见的可靠性问题是什么？第二层追问：为什么不能只靠 retry？
我：常见问题是进程中断、provider 超时、工具半执行、上下文压缩丢事实、权限等待、外部状态变化。只靠 retry 会重复副作用或基于旧事实继续。可靠性要先有 durable facts、checkpoint、idempotency 和 recovery gate，再决定能不能 retry。
理解与记忆 · 背后工程点
背后工程点：Retry 只是恢复策略之一，不是可靠性基础。
专业术语：
Retry：重试。
Checkpoint：检查点。
Idempotency：幂等。
Recovery Gate：恢复闸门。
为什么这样回答：先反驳简单重试，抓住可靠性本质。
小白解析：转账失败不能一直点重试，先要确认钱有没有扣。
关联知识点：LangGraph durable execution 要求副作用用 task 包起来并保证幂等；Guga M5 恢复默认保守。
面试官：哪些状态必须 durable？第二层追问：哪些可以重算？
我：必须 durable 的是 session metadata、event log、tool intent/result、permission decisions、artifact refs、pending effects、plan state、context decisions、verification results、usage。可以重算的是 UI projection、部分摘要、token estimate、缓存和模型输入 view，但重算必须从 durable facts 来。
理解与记忆 · 背后工程点
背后工程点：事实源和派生视图要分开。
专业术语：
Source of Truth：事实源。
Projection：投影视图。
Artifact Ref：产物引用。
Usage：用量。
为什么这样回答：列出具体状态能显示工程经验。
小白解析：发票和付款记录必须保存，报表图表可以重新生成。
关联知识点：Guga M5 区分 durable events、artifact refs、conversation/model-input/audit view。
面试官：工具执行中途崩溃怎么办？第二层追问：怎么判断有没有副作用？
我：执行前写 effect_started，执行后写 effect_completed；如果崩溃只看到 started，就标记 pending effect。恢复时按工具 effect 类型检查：文件写看临时文件/diff/worktree，API 写查 idempotency key 或外部状态，shell 看进程和输出。不能确认就 ask human 或 mark inconsistent。
理解与记忆 · 背后工程点
背后工程点：半执行副作用要被显式建模。
专业术语：
Effect Started：副作用开始事件。
Effect Completed：副作用完成事件。
Pending Effect：待确认副作用。
Inconsistent：不一致状态。
为什么这样回答：这是可靠性题的硬工程点。
小白解析：装修工走了，不知道墙拆没拆完，要先现场检查，不要直接继续砸。
关联知识点：learn-agent hosted harness 强调 durable step、worker retry/resume；Guga 事件 marker 区分 completed/failed/cancelled/timeout/interrupted。
面试官：Replay 是不是重新执行一遍？第二层追问：LangGraph replay 和你的 replay 有什么区别？
我：我会区分诊断 replay、simulation replay 和 live retry。诊断 replay 只从 durable facts 重建模型输入、工具时间线和审计视图，不重跑 provider/tool。LangGraph time travel 的 replay 会从 checkpoint 后重新执行节点，LLM/API 可能重触发；如果用于 Agent 调试，要明确这类 replay 是新 trajectory。
理解与记忆 · 背后工程点
背后工程点：回放模式不同，副作用语义完全不同。
专业术语：
Diagnostic Replay：诊断回放。
Simulation Replay：模拟回放。
Live Retry：真实重试。
Trajectory：轨迹。
为什么这样回答：能体现你不会把“回放”说混。
小白解析：看监控录像不等于让事故重新发生一遍。
关联知识点：Guga replay audit 默认不重跑 provider/tool/mutating hook；LangGraph time travel 文档说明 checkpoint 后节点会重新执行。
面试官：恢复时如何保证 tool call/result 配对合法？第二层追问：如果只记录了 tool call 没记录 result 呢？
我：恢复 conversation view 前要跑 pairing safety。已完成 tool call 必须有对应 result；缺失 result 的调用不能直接塞回 provider，可以转成 interrupted state、合成受控 error observation，或要求 host 决策。不能让恢复后的 messages 违反 provider 协议。
理解与记忆 · 背后工程点
背后工程点：恢复不是拼聊天记录，要维护 provider contract。
专业术语：
Tool Pairing：工具配对。
Conversation View：对话视图。
Provider Contract：模型接口契约。
Interrupted State：中断状态。
为什么这样回答：这展示你熟悉 tool-calling 协议坑。
小白解析：订单有下单记录但没有支付结果，系统不能假装订单完成。
关联知识点：Guga M5 acceptance example 明确要求悬空 tool_use 恢复时要净化或标记 interrupted。
面试官：Checkpoint 频率怎么定？第二层追问：每个 token 都写是不是太重？
我：不用每个 token 都同步写。按安全边界写：run/turn start、model response、tool intent、permission decision、副作用前后、artifact commit、verification、compact boundary。低风险流式 token 可以批量或异步，关键副作用前后要同步。频率由恢复损失和性能成本决定。
理解与记忆 · 背后工程点
背后工程点：持久化粒度按风险和恢复损失设计。
专业术语：
Durability Mode：持久化模式。
Boundary Event：边界事件。
Flush：刷盘。
Recovery Loss：恢复损失。
为什么这样回答：能回答性能反驳。
小白解析：写日记不用每秒记录，但签合同、付款、验收这些关键节点必须记录。
关联知识点：LangGraph durable execution 提供 exit/async/sync durability modes；Guga 可按事件风险分层。
面试官：外部 API 写操作怎么保证幂等？第二层追问：对方系统不支持幂等键怎么办？
我：优先使用 idempotency key、external request id、事务和 read-after-write 校验。如果对方不支持，就把操作放在人工审批后，记录外部自然键，执行后立即查询确认；无法确认的操作标记不可自动重试，需要人工恢复或补偿流程。
理解与记忆 · 背后工程点
背后工程点：幂等不是总能实现，但不可幂等要提高控制等级。
专业术语：
External Request ID：外部请求标识。
Read-after-write：写后读确认。
Natural Key：自然键。
Compensation：补偿。
为什么这样回答：承认限制比假装都有方案更可信。
小白解析：没有小票的现金交易，出了问题就不能让机器自动再付一次。
关联知识点：LangGraph 文档建议副作用用幂等操作；Guga effect ledger 记录是否可回滚。
面试官：恢复后权限还有效吗？第二层追问：昨天用户批准的 shell 今天还能跑吗？
我：默认不能简单沿用。权限决定要带 scope、expiresAt、session id、workspace hash、command/resource pattern。Resume 时如果 workspace、用户、时间、工具版本、权限模式变化，就要重新确认。长期 allow 必须是明确产品语义，不是恢复时自动继承。
理解与记忆 · 背后工程点
背后工程点：权限也是恢复时要重新校验的事实。
专业术语：
Scope：作用域。
ExpiresAt：过期时间。
Workspace Hash：工作区哈希。
Persistent Allow：持久允许。
为什么这样回答：可靠性不能牺牲安全边界。
小白解析：昨天允许师傅进门修水管，不代表今天他能自己进来拆墙。
关联知识点：Guga 权限由 runtime 执行；learn-agent hosted harness 强调 secret 和 policy 边界。
面试官：工作区变了怎么恢复？第二层追问：用户手动改了文件怎么办？
我：Session 要记录 workspace snapshot、base revision、dirty diff、active files。恢复时扫描当前工作区和记录状态是否一致；如果用户改了相关文件，要 re-read、rebase、merge、fork 或暂停问用户。不能假设 Agent 仍然拥有旧事实。
理解与记忆 · 背后工程点
背后工程点：恢复要检查外部世界是否还和中断时一致。
专业术语：
Workspace Snapshot：工作区快照。
Dirty Diff：未提交变更。
Rebase：重放修改。
Fork：分叉。
为什么这样回答：这是真实 coding agent 的常见问题。
小白解析：你离开工地一天，回来先看现场有没有别人动过。
关联知识点：Harness 章节已讨论 workspace lock 和 external change；可靠性章节把它纳入 resume gate。
面试官：用户中断和系统崩溃有什么区别？第二层追问：取消会不会留下坏状态？
我：用户中断是有意图的 lifecycle event，可以选择 drain 当前安全边界；系统崩溃是非预期中断，只能从最后事实恢复。取消时要给工具 abort signal，写 cancelled marker，已发生副作用仍要记录；不能因为用户点取消就删除历史或假装没发生。
理解与记忆 · 背后工程点
背后工程点：取消也是事实，不是撤销历史。
专业术语：
Interrupt：中断。
Drain：排空到安全边界。
AbortSignal：取消信号。
Cancelled Marker：取消标记。
为什么这样回答：区分 lifecycle 对恢复很关键。
小白解析：叫停施工不等于已经拆掉的墙自动恢复。
关联知识点：LangGraph graceful shutdown/drain 在 superstep 边界保存可恢复 checkpoint；Guga event log 记录 cancel 和 interrupted。
面试官：可靠性怎么评测？第二层追问：怎么制造故障？
我：要做 fault injection eval：在 model call、tool before/after、artifact write、permission wait、compact、verification、worker shutdown 注入超时、崩溃、重复事件和尾部损坏。指标看恢复成功率、重复副作用数、非法 tool pair 数、人工救援率、数据丢失窗口和 replay 完整度。
理解与记忆 · 背后工程点
背后工程点：可靠性必须通过故障注入验证。
专业术语：
Fault Injection：故障注入。
Recovery Success Rate：恢复成功率。
Duplicate Effect：重复副作用。
Replay Completeness：回放完整度。
为什么这样回答：给出测试方法比只说“支持恢复”扎实。
小白解析：消防演练不是等真着火才知道门能不能打开。
关联知识点：Guga strategy 有长任务可恢复率和 runtime 边界回归率；M5 acceptance examples 覆盖恢复、fork、replay、corruption。
面试官：事件日志如果尾部损坏怎么办？第二层追问：append-only 也可能写一半，你怎么恢复？
我：append-only 不是等于永远正确。每条事件要有 schemaVersion、sequence/revision、idempotency key、payload hash，最好还有 previous hash。读取时如果发现尾部 JSONL 半行、hash 不连续或 revision 缺口，先截取最长合法前缀，把尾部隔离成 corruption artifact，再把 session 标记为 degraded，需要 host repair 或人工确认。不能静默跳过坏事件继续运行。
理解与记忆 · 背后工程点
背后工程点：durable store 也会损坏，恢复必须能诊断和隔离坏尾部。
专业术语：
Corruption Artifact：损坏片段产物。
Hash Chain：哈希链。
Longest Valid Prefix：最长合法前缀。
Degraded Session：降级会话。
为什么这样回答：这能把“事件是事实源”讲得更严谨，事实源本身也需要完整性设计。
小白解析：账本最后一页被水泡坏了，不能假装没事；要先锁起来，确认前面账目还完整。
关联知识点：Guga M5 acceptance examples 明确要求 JSONL 尾部损坏时识别最长合法前缀并暴露 corruption 状态。
面试官：Hosted worker 重启或重复领取同一个 job 怎么办？第二层追问：怎么避免两个 worker 同时操作同一 workspace？
我：Hosted harness 要有 job lease 和 fencing token。Worker 领取任务时获得 lease，定期续约；写 event、artifact、workspace 前都检查 fencing token 是否仍有效。Workspace 也要有 session-level lock 或独立 checkout。Lease 过期后新 worker 可以接管，但旧 worker 的迟到写入会被 expected revision 或 fencing token 拒绝。
理解与记忆 · 背后工程点
背后工程点：远程执行需要 worker lease 和 fencing，不能假设只有一个进程。
专业术语：
Job Lease：任务租约。
Fencing Token：防旧 worker 写入的令牌。
Expected Revision：期望版本写入。
Workspace Lock：工作区锁。
为什么这样回答：这覆盖 hosted harness 的真实并发问题，比“重启后恢复”更进一步。
小白解析：一个维修单不能两队人同时施工；如果换队，旧队回来也不能继续刷卡进门。
关联知识点：learn-agent hosted harness 把 worker lease、deployment、workspace identity 和 durable step 拆成独立边界。
面试官：模型流式输出到一半断了怎么办？第二层追问：半个 tool call 已经出来了，要执行吗？
我：不能执行半个 tool call。Streaming delta 先进入 assembler，只有完整、schema 合法、finish reason 合法的 tool intent 才能进入 pipeline。中断时记录 model_request_started、partial_delta refs 和 interrupted marker，conversation view 不暴露半成品 tool call。恢复时可以重新请求模型、让用户选择 retry，或者把中断作为 observation，但不能把半截 JSON 当真实意图。
理解与记忆 · 背后工程点
背后工程点：流式响应要先组装和提交，半成品不能产生副作用。
专业术语：
Delta Assembler：流式片段组装器。
Commit Boundary：提交边界。
Partial Tool Call：半成品工具调用。
Finish Reason：模型结束原因。
为什么这样回答：很多真实 provider 都是 streaming，可靠性不能只考虑完整响应。
小白解析：电话里只听到“请转账给...”就断线了，不能自己补全收款人去转。
关联知识点：Guga provider bridge 和 tool pipeline 分离，provider 只产生完整 tool intent，core 才执行真实动作。
面试官：Artifact 丢了或 hash 对不上怎么办？第二层追问：event 里只有 artifact ref，完整日志没了还能恢复吗？
我：artifact ref 必须带 hash、size、mime、createdAt、privacy tag。恢复时先校验 artifact 可读和 hash；如果丢失，session 进入 degraded replay，模型可见 view 只能使用 event 里的 bounded preview，不能假装完整日志还在。对关键 artifact 可以做复制、retention policy 和完整性扫描。丢失本身要写 incident event，影响 eval 和恢复结果。
理解与记忆 · 背后工程点
背后工程点：artifact 是事实证据的一部分，引用要可验证，丢失要显式降级。
专业术语：
Artifact Integrity：产物完整性。
Bounded Preview：有限预览。
Retention Policy：保留策略。
Degraded Replay：降级回放。
为什么这样回答：事件和 artifact 分离后，必须回答 artifact 生命周期和丢失问题。
小白解析：账本里写“详见附件”，如果附件丢了，就只能承认证据不完整，不能编一个附件。
关联知识点：Guga artifact store 把大输出保存到文件系统，event 只留 bounded preview 和可验证 reference。
面试官：Context compaction 过程中崩了怎么办？第二层追问：summary 写一半，会不会污染后续恢复？
我：Compaction 必须有事务边界。先写 compaction_started，生成 summary 和 source refs 后写 compaction_candidate，只有校验通过才写 compaction_committed。恢复时如果只看到 started 或 candidate，就不能把它当事实摘要；要回到压缩前事件路径，或重新运行 compaction。Summary 是 projection，不是历史本身，所以失败不能覆盖原始事件。
理解与记忆 · 背后工程点
背后工程点：压缩摘要要有提交语义，未提交摘要不能成为事实源。
专业术语：
Compaction Boundary：压缩边界。
Candidate Summary：候选摘要。
Commit：提交。
Projection：投影。
为什么这样回答：Context 压缩是长任务可靠性的高风险点，摘要失败不能损坏历史。
小白解析：会议纪要没审完不能替代录音和原始记录。
关联知识点：Context 章节强调 summary 是续航手段，不是唯一事实源；Guga M5 要记录 compaction boundary 和 projection decision。
面试官：恢复时 secret vault 不可用怎么办？第二层追问：任务要继续，但工具需要密钥，你怎么处理？
我：不能从旧 trace 或旧 env 里恢复 secret。Resume 时 secret capability 要重新向 vault 获取，获取失败就把相关工具标 unavailable，计划进入 blocked 或 partial mode。可以继续执行不需要 secret 的只读诊断，但涉及外部 API 的步骤要等待 vault、请求用户重新授权或切换替代路径。Secret 不进 event log，只记录访问决策和脱敏状态。
理解与记忆 · 背后工程点
背后工程点：恢复不能复用泄漏的 secret，密钥能力要重新获取和校验。
专业术语：
Secret Capability：密钥能力。
Vault：密钥库。
Unavailable Tool：不可用工具。
Partial Mode：部分能力模式。
为什么这样回答：可靠性和安全经常冲突，不能为了继续任务把密钥边界打穿。
小白解析：保险柜打不开时可以先整理资料，但不能从旧照片里找密码硬开。
关联知识点：learn-agent hosted harness 强调 secret boundary；Guga 安全口径是 secret 是能力，不是 context。
面试官：任务卡在人工审批上怎么办？第二层追问：用户一天后才批准，原来的上下文还能用吗？
我：审批等待要持久化成 pending approval event，带 request id、scope、expiresAt、risk summary 和 current plan revision。用户一天后批准时，不能直接执行旧动作，要重新跑 resume gate：检查 workspace、权限、工具版本、外部状态和计划是否仍然有效。过期审批要重新发起。批准只是恢复输入，不是绕过新状态检查。
理解与记忆 · 背后工程点
背后工程点：HITL 等待是长任务状态，批准后仍要重新校验环境。
专业术语：
Pending Approval：待审批。
Request ID：审批请求标识。
ExpiresAt：过期时间。
Resume Gate：恢复闸门。
为什么这样回答：人类审批经常跨小时或跨天，旧上下文和旧权限不能自动可信。
小白解析：昨天批准开门，今天开门前也要确认房子还是那间、钥匙还是那把。
关联知识点：Deep Agents/HITL 和 Guga permission runtime 都强调 approval 是运行时事实，必须可记录和恢复。
面试官：事件 schema 升级后，旧 session 怎么恢复？第二层追问：你会迁移历史事件吗？
我：历史事件默认不改写。每个事件带 schemaVersion，读取和 replay 时用 upcaster 转成当前 view；破坏性变更走新 major version 和兼容期。必要时生成新 projection 或 migration artifact，但原始 event log 保持不可变。Conformance tests 要覆盖旧 session fixture，防止升级后 replay 旧任务失败。
理解与记忆 · 背后工程点
背后工程点：事件历史是审计事实，schema 演进要 read-time 兼容，不能随意重写。
专业术语：
Schema Version：结构版本。
Upcaster：读时升级器。
Conformance Test：契约测试。
Migration Artifact：迁移产物。
为什么这样回答：可靠性不只是运行中恢复，也包括版本升级后的长期可回放。
小白解析：旧合同不能为了新模板直接改原件，只能做解释表或补充协议。
关联知识点：Guga M5 要求 event schema 演进采用加性兼容和 read/replay-time upcaster，不为适配新 schema 改写历史事件。
面试官：可靠性 MVP 先做什么？第二层追问：哪些高级能力先不做？
我：先做 append-only event store、artifact refs、tool lifecycle markers、resume gate、diagnostic replay、basic fork 和 fault injection tests。先不做跨设备同步、多人协作、复杂工作流引擎、自动补偿市场、全量搜索和 RL 数据飞轮。先保证单 agent 长任务能恢复、能解释、不会重复危险副作用。
理解与记忆 · 背后工程点
背后工程点：可靠性 MVP 先保护事实和副作用。
专业术语：
Append-only：只追加。
Artifact Ref：产物引用。
Diagnostic Replay：诊断回放。
Fault Test：故障测试。
为什么这样回答：收束到可执行路线图。
小白解析：先把账本、仓库和急停按钮做好，再做调度中心。
关联知识点：Guga M5 明确不做完整 memory/search/RL，只先打 session/event/artifact/replay 底座。
PRINCIPLE我总结的核心范式
可靠性的核心范式是“事实先于恢复，幂等先于重试，回放先于调参”。一个 Agent 可以失败，但不能失忆；可以中断，但不能乱续；可以重试，但不能重复伤害真实世界。