Agent Runtime 与安全执行 ​

读图重点是状态与副作用分离：Runtime 负责让任务跨故障继续，Execution 与操作账本负责让现实动作可验证、可对账。

定位：这是七篇正式文档中的第 03 篇。
目标：把两个最容易混淆、但又最决定 Agent 能不能真正进生产的能力讲透：
Runtime 负责让 Run 跨故障、等待、重启和版本升级正确活着；Execution Infrastructure 负责让真实动作在正确的身份、隔离和环境里发生。

整篇主线：

text

Agent / Workflow
→ Run
→ Checkpoint / Wait / Signal / Resume
→ Operation Ledger / Idempotency / Reconciliation
→ Lease / Fencing / Version
→ Execution Request
→ Environment / Workspace / Identity / Network
→ Tool / Shell / Browser / Computer Use
→ Artifact / Evidence
→ Verification

**本篇不是 Workflow Engine 教程，也不是容器 / K8s 教程。**真正要回答的是：
一个长任务怎样在失败以后“正确继续”，一个真实动作怎样在可控边界内“安全发生”。

回答原则：故障题先把 Failure Window 讲清楚，再给恢复机制；方案题先明确保证边界；系统设计题先讲不变量，不先堆组件；执行安全题优先讲 Blast Radius（影响半径）和 Deterministic Containment（确定性隔离），而不是只说“加审批”。

一、先建立整篇主线 ​

1.1 第一性问题 ​

只要 Agent 开始做真实工作，就会遇到两类完全不同的问题。

第一类：

这个任务怎么活下去？

例如：

Worker Crash
服务发布
人工审批等待 2 小时
外部 Tool 异步完成
节点迁移
网络抖动

这属于 Runtime。

第二类：

这个动作到底在哪里、以什么身份、在什么权限和网络边界里执行？

例如：

Shell
Browser
SQL
Git
Deploy
Computer Use

这属于 Execution Infrastructure。

因此最重要的边界是：

Harness
→ Agent 怎么工作

Runtime
→ Run 怎么可靠地活着

Execution
→ Action 在哪里、以什么边界真实发生

如果这三个概念混在一起，后面几乎所有 Recovery / Security / Scale 设计都会变乱。

1.2 为什么 Agent 特别需要 Durable Runtime ​

传统 Web Request 往往是：

Request
→ 计算
→ Response

生命周期可能只有几百毫秒到几秒。

Agent Run 很容易变成：

5 分钟
30 分钟
2 小时
1 天

而且中间还会：

• 等用户；
• 等 CI；
• 等 Browser；
• 等外部系统；
• 等子任务；
• 重启进程；
• 切版本。

于是“把状态放内存里”天然不可靠。

真正需要的是：

Durable State
+
Durable Control Flow
+
Durable Wait
+
Durable Side-effect Semantics
+
Version-aware Resume

这就是 Durable Execution（持久执行）的核心。

1.3 为什么 Sandbox 不等于 Execution Infrastructure ​

一个 Container 只解决了很小一部分问题。

真正的 Execution Infrastructure 还要回答：

Environment 谁创建？
Workspace 是否持久？
Secret 怎么注入？
Network 能访问哪里？
Browser Profile 属于谁？
进程如何 Cancel？
Artifact 怎样保存？
Evidence 怎么回传？
环境何时销毁？

所以：

Sandbox 是执行边界的一部分，不是完整执行系统。

1.4 本篇口述控制原则 ​

这篇特别容易陷入“分布式系统百科”。

面试现场要优先围绕一条 Failure Chain 讲。

例如：

“Tool 已经成功，但 Worker 在 Checkpoint 前 Crash 了怎么办？”

先讲：

Crash Window
→ 本地状态落后于真实世界
→ 不能直接 Retry
→ Operation ID
→ Reconcile
→ 再决定 Resume / Retry

先停。

如果面试官继续追：

“Operation Ledger 怎么设计？”

再展开 Ledger Schema、事务边界、Retention。

这样比一上来讲 Exactly-once、Saga、Lease、Fencing、Temporal 全部术语更高级。

1.5 读不懂时先记这张“Runtime / Execution”速记表 ​

一句话：

Runtime
→ 管“任务怎么继续活着”

Execution
→ 管“动作怎么安全地发生”

Verification
→ 管“发生以后怎么证明是真的”

二、Agent Runtime 与 Durable Execution ​

2.1 Q1｜Agent Runtime、Harness、Execution Infrastructure 的边界是什么？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会这样分：

Harness
→ 决定 Agent 怎么工作、下一步做什么

Runtime
→ 负责这个 Run 怎样跨时间、故障、等待继续活着

Execution
→ 负责动作最终在哪里、以什么身份和隔离边界真实发生

三者可以协作，但职责不能互相吞掉。

2～3 分钟高分回答 ​

举一个 Coding Agent 例子。

用户说：

“修复支付 Bug，跑测试，等 Senior Engineer 审批后 Merge。”

Harness 负责：

• 当前该读哪个文件；
• 是否调用 Test Tool；
• 是否需要 Re-plan；
• 什么时候认为任务完成。

Runtime 负责：

• Run ID；
• Checkpoint；
• 等审批时释放 Worker；
• 两小时后 Signal 到来时 Resume；
• Crash 后恢复；
• Old Run 用哪个 Version。

Execution Infrastructure 负责：

• 创建 Sandbox；
• 准备 Repo Workspace；
• 运行 Shell；
• 注入 Git Credential；
• 保存 Diff / Test Artifact；
• 限制 Network。

所以我通常用一句话概括：

Harness 管“怎么干活”，Runtime 管“怎么活着”，Execution 管“手脚在哪里动”。

项目映射 ​

研发 AI Workflow 是最适合讲这三个边界的母案例。

Data Agent 也一样：

• Harness 决定分析步骤；
• Runtime 管长 SQL / Human Approval；
• Execution 真正执行 SQL / Python / Export。

高分亮点句 ​

非确定性决策属于 Harness，持久生命周期属于 Runtime，真实副作用属于 Execution。

面试官真正想听什么 ​

• 是否把 Runtime 等同模型服务；
• 是否把 Sandbox 当 Runtime；
• 是否真正理解生产 Agent 的分层。

典型追问 ​

1. Checkpoint 属于 Harness 还是 Runtime？
2. Tool Timeout 谁负责？
3. Runtime 要不要知道 Tool 语义？
4. Execution 可以没有 Runtime 吗？

Red Flags ​

• “Runtime 就是模型推理环境。”
• “Runtime 就是一个 Sandbox。”

为什么这样回答 / 本题套路 ​

这是本篇总边界题。先用一个真实长任务串起三层，比直接背定义更容易让面试官确认你理解系统责任。

2.2 Q2｜Durable Execution 是什么？为什么不是“程序永不失败”或“把 State 存数据库”？ ​

复习优先级：P0｜题型：S2 Incident / Debug

30 秒核心回答 ​

Durable Execution 的核心不是“不失败”，而是：

失败以后还能在保持业务语义正确的前提下继续。

仅仅把 State 存数据库远远不够，因为真实副作用可能已经发生，但本地状态还没来得及更新。

2～3 分钟高分回答 ​

举一个最典型的 Crash Window：

1. create_ticket 成功
2. Worker Crash
3. Checkpoint 还没写成功

恢复以后，如果 Runtime 只看本地 State：

“当前还没完成 create_ticket。”

然后重跑，就创建两个工单。

所以 Durable Execution 至少要覆盖：

Durable State
Durable Control Flow
Durable Wait
Side-effect Semantics
Version-aware Resume

其中最关键的是：

State Recovery 不等于 Semantic Recovery。

真正恢复时还要知道：

• 哪个 Operation 已经发生；
• 当前外部状态是什么；
• 是否可安全 Retry；
• 是否需要 Reconcile；
• 当前 Code / Tool Version 是否兼容。

Restate 当前通过 Journal（执行日志）记录 durable step 结果，失败后 Replay 并跳过已完成步骤；DBOS 也把 workflow step 结果持久化，Crash 后从完成点恢复。这些实现都说明 Durable Execution 的核心是“持久控制流 + 已发生事实”，而不是简单存一个 status。[R1][R2]

高分亮点句 ​

Durable Execution 不是保证不失败，而是保证失败以后不会把世界做错。

面试官真正想听什么 ​

• 是否理解 Crash Window；
• 是否区分 State 和 Side Effect；
• 是否理解“恢复”是语义问题。

典型追问 ​

1. 每一步都写 Checkpoint 能解决吗？
2. Exactly-once 能不能彻底解决？
3. LLM 调用本身要不要 Durable？
4. Runtime 和 Workflow Engine 有什么关系？

Red Flags ​

• “把消息和状态存 Redis 就 Durable 了。”
• “失败以后从上一次 Step 重新跑。”

为什么这样回答 / 本题套路 ​

这是机制题。必须用“外部副作用成功、本地状态没落盘”的 Crash Window 解释为什么简单持久化不够。

2.3 Q3｜Checkpoint、Wait、Signal、Resume 分别解决什么问题？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

四个概念可以看成一条长任务生命周期：

Checkpoint
→ 我做到哪里

Wait
→ 我现在不需要 Worker，但任务还没结束

Signal
→ 外部条件满足了

Resume
→ 重新获得执行权继续

2～3 分钟高分回答 ​

比如研发 Agent：

改代码
→ 跑测试
→ Checkpoint C1
→ 等审批

这里不应该让 Worker 睡两小时。

Runtime 把 Run 变成：

WAITING_APPROVAL

释放 Worker。

审批系统两小时后发：

Signal(approval_id=A100)

Runtime 再：

load checkpoint
→ check version
→ reacquire execution ownership
→ Resume

Checkpoint 不是简单 Message History，它还要保存：

• 当前 Control State；
• Pending Operation；
• Version Manifest；
• 未完成 Todo；
• Resume 所需引用。

Signal 自己也要幂等。Webhook / Approval Provider 可能重复发送，不能因为收到 3 次 Approved 就 Resume 3 次。

项目映射 ​

研发 AI Workflow 里：

• 等 CI；
• 等 Code Review；
• 等审批；

都应该用 Durable Wait，而不是 Worker 阻塞。

高分亮点句 ​

Wait 的价值不是“暂停”，而是让任务暂停时不继续占用计算资源，同时仍保持可恢复。

面试官真正想听什么 ​

• 是否会把长等待和 Worker 生命周期解耦；
• 是否知道 Signal 也会重复；
• 是否理解 Checkpoint 是恢复契约。

典型追问 ​

1. Checkpoint 多久写一次？
2. Signal 顺序错乱怎么办？
3. Approval 过期怎么办？
4. Waiting Run 要不要计费？

Red Flags ​

• “Worker sleep 两小时等审批。”
• “收到 Signal 直接执行，不校验当前 State。”

为什么这样回答 / 本题套路 ​

这是长任务状态机题。用“审批等待”场景能自然带出四个概念，也方便继续追 Runtime Scale。

2.4 Q4｜Tool 已产生副作用，但 Worker 在写 Checkpoint 前崩了，恢复后怎么办？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

这是经典 Crash Window。

恢复后不能直接 Retry，因为：

真实世界可能已经成功，只是本地还不知道。

正确做法是：

Operation ID
→ Operation Ledger
→ Reconcile Remote Reality
→ 再决定 Skip / Retry / Compensate

2～3 分钟高分回答 ​

执行一个有副作用 Tool 前，我会先创建：

operation_id = OP123
status = INTENT_RECORDED

然后调用外部系统。

如果外部已经成功，但 Worker Crash 了，恢复以后 Runtime 先查 Ledger：

OP123 = UNKNOWN / IN_PROGRESS

再去远端 Reconcile：

query remote operation / resource

三种结果：

已成功
→ 补写 Success，继续下一步

确认没发生
→ 安全 Retry

状态无法确认
→ 人工 / Compensation / Risk Escalation

如果远端支持 Idempotency Key，恢复路径更简单；如果不支持，就更依赖 Reconciliation。

项目映射 ​

研发 Agent：

• Create PR；
• Merge；
• Deploy；
• Revert。

Data Agent：

• Export；
• 写回 Dataset；
• 创建 BI Asset。

高分亮点句 ​

恢复时要以真实世界状态为准，而不是以 Crash 前最后一条本地记录为准。

面试官真正想听什么 ​

• 是否真正理解副作用恢复；
• 是否会无脑 Retry；
• 是否知道 Operation Ledger / Reconciliation。

典型追问 ​

1. Ledger 写入本身 Crash 怎么办？
2. 外部系统无法 Query Status 怎么办？
3. Compensation 和 Rollback 区别是什么？
4. Operation ID 保留多久？

Red Flags ​

• “恢复以后重跑当前 Step。”
• “所有 Tool 都 Retry 三次。”

为什么这样回答 / 本题套路 ​

这是本篇最重要的 P1 事故题。先讲 Crash Window，再讲真实世界事实优先，最后才落 Ledger / Idempotency / Reconciliation。

2.5 Q5｜Operation Ledger、Idempotency Key、Reconciliation 分别承担什么职责？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

三者解决的是三个不同问题：

Operation Ledger
→ 我们尝试做过什么

Idempotency Key
→ 重复请求不要重复产生同一副作用

Reconciliation
→ 本地记录和真实世界不一致时重新确认事实

缺任何一个，恢复能力都可能不完整。

2～3 分钟高分回答 ​

举支付 / Deploy 类动作。

Operation Ledger

保存：

operation_id
run_id
action
target
status
external_id
attempt
result

它解决：

Runtime 自己有没有记住这次动作。

Idempotency Key

发给远端：

deploy_key = release_123

即使重复请求，远端仍然映射到同一 Operation。

它解决：

重复 Delivery 不重复产生 Effect。

Reconciliation

当：

本地 = UNKNOWN
远端 = ?

去查远端真实状态。

它解决：

Crash / Timeout 后的不确定性。

所以真正完整的是：

Record Intent
→ Execute with Idempotency
→ Record Result
→ Crash?
→ Reconcile

高分亮点句 ​

Ledger 负责“记得做过”，Idempotency 负责“重复也只做一次”，Reconciliation 负责“搞清现实到底发生了什么”。

面试官真正想听什么 ​

• 是否把三个概念混成“幂等”；
• 是否理解本地 / 远端状态不同步。

典型追问 ​

1. Idempotency Key 谁生成？
2. Ledger 和 Trace 有什么区别？
3. 可以只用 Ledger 不用 Idempotency 吗？
4. Ledger 是 Event Store 吗？

Red Flags ​

• “有 Idempotency Key 就不需要 Reconciliation。”
• “Trace 就可以当 Operation Ledger。”

为什么这样回答 / 本题套路 ​

这是机制边界题。三者名字经常同时出现，但职责完全不同。用一句话分别回答“记忆 / 去重 / 对现实”最容易讲清。

2.6 Q6｜Exactly-once 为什么必须先问 Guarantee Boundary 在哪里？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我不会直接说系统支持 Exactly-once。

我会先问：

Exactly-once 是在哪个边界内？

在单数据库事务里可以很强；一旦跨第三方 API、邮件、支付、Git、Browser，通常只能通过：

At-least-once Delivery
+ Idempotent Effect
+ Reconciliation

实现业务上的“效果不重复”。

2～3 分钟高分回答 ​

例如：

Runtime DB

内部可以用一个 Transaction 原子提交：

Operation Ledger
+
Checkpoint

这里保证边界比较清晰。

但调用：

GitHub
Payment
Email
Cloud Provider

你的 DB Transaction 无法把远端一起包进去。

所以更现实的语义是：

Delivery
→ 可能重复

Effect
→ 尽量 Idempotent

Unknown Outcome
→ Reconcile

如果有人说：

“MQ 支持 Exactly-once，所以问题解决。”

我会继续问：

“它保证的是消息消费，还是远端真实副作用？”

这是完全不同的边界。

高分亮点句 ​

Exactly-once 不是一个系统标签，而是一条必须写清楚的保证边界。

面试官真正想听什么 ​

• 分布式系统基本功；
• 是否会滥用 Exactly-once；
• 是否理解业务效果和消息语义区别。

典型追问 ​

1. Kafka Exactly-once 能解决 Tool 重复吗？
2. DBOS 的 exactly-once 语义边界在哪？
3. Payment 如何做？
4. Email 如何做？

Red Flags ​

• “用 Exactly-once MQ 就不会重复执行。”

为什么这样回答 / 本题套路 ​

这是高阶边界题。高分关键不是反复说“分布式系统没有 Exactly-once”，而是明确在哪个边界能保证什么。

2.7 Q7｜Lease、Heartbeat、Epoch、Fencing 为什么要组合使用？只做分布式锁有什么问题？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我会把四者理解成：

Lease
→ 当前谁拥有执行权

Heartbeat
→ Owner 是否还活着

Epoch / Fencing Token
→ 当前所有权是第几代

Fencing
→ 拒绝旧 Owner 的迟到写入

只做 Lock 不能彻底解决 Zombie Worker。

2～3 分钟高分回答 ​

场景：

Worker A 拿到 Lease
→ 网络分区
→ Runtime 认为 A 失活
→ Lease 过期
→ Worker B 接管

但 A 其实还在继续执行。

如果网络恢复：

A + B

可能同时写状态、同时发 Tool。

所以新的 Owner 获得：

epoch = 11

旧 Worker A：

epoch = 10

所有关键写入 / Operation 都必须带 Fencing Token。

Storage / Executor 只接受最新 Epoch。

Restate 当前架构也使用递增 Epoch 拒绝旧 Attempt 的迟到事件，防止 Split-brain；这说明 Fencing 不只是理论模式。[R1]

高分亮点句 ​

Lease 解决“谁应该是 Owner”，Fencing 才解决“旧 Owner 还能不能继续造成影响”。

面试官真正想听什么 ​

• 是否真正懂分布式 Ownership；
• 是否知道 Lock 释放后旧 Worker 可能仍活着。

典型追问 ​

1. Fencing Token 放哪里校验？
2. 外部 Tool 不支持 Epoch 怎么办？
3. Heartbeat TTL 怎么选？
4. Clock Skew 怎么处理？

Red Flags ​

• “Redis Lock 足够。”
• “Lease 到期后旧 Worker 一定停止。”

为什么这样回答 / 本题套路 ​

这是经典并发恢复题。先讲 Zombie Worker 事故，再解释四个机制各自负责什么，比背“Fencing Token”定义更有生产感。

2.8 Q8｜两个 Worker 同时恢复同一个 Run，怎样避免 Zombie Worker 和双执行？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

需要两层保护：

Runtime Ownership
→ Lease + Epoch + CAS

Real-world Effect
→ Operation ID + Idempotency / Reconciliation

只有 Runtime 锁是不够的，因为外部副作用可能已经在进行。

2～3 分钟高分回答 ​

恢复 Run 时：

1. Acquire Lease
2. Get monotonic epoch
3. CAS transition WAITING/RECOVERING → RUNNING
4. Execute with epoch

所有 Runtime State 更新都校验：

run_id + epoch

如果旧 Worker A 再写：

Storage 拒绝。

但如果 A 已经发出：

deploy()

外部系统可能不认识 Epoch。

所以还要：

operation_id
idempotency_key
reconcile_method

也就是：

Control Plane 防双 Owner，Side-effect Contract 防双 Effect。

高分亮点句 ​

“一个 Run 只能有一个逻辑 Owner”和“现实世界只发生一次副作用”是两个不同的保证。

面试官真正想听什么 ​

• 是否会只用 Lock；
• 是否理解 Runtime 和 Tool Recovery 两层。

典型追问 ​

1. CAS State Transition 怎么设计？
2. Queue Duplicate Delivery 怎么办？
3. 多 Region 怎么保证 Owner 唯一？

Red Flags ​

• “队列保证一条消息只消费一次。”

为什么这样回答 / 本题套路 ​

这是 Q7 的场景化应用题。要把控制面 Ownership 与外部 Effect 分开，体现跨层思考。

2.9 Q9｜等待中的几十万 Run 同时被唤醒形成 Resume Storm，系统怎么治理？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

这不是简单 Autoscale 问题，而是 Admission + Scheduling + Backpressure 问题。

我会做：

Signal
→ Ready Queue
→ Priority / Tenant Fairness
→ Admission Control
→ Rate / Concurrency Limit
→ Worker / Model / Tool Capacity

2～3 分钟高分回答 ​

例如：

10 万个 Run

都在等某个外部事件。

事件恢复后同时 Ready。

如果直接全部拉起：

• Model QPS 打满；
• Browser / Sandbox Slot 打满；
• Tool API 429；
• DB 热点；
• Retry 再放大。

所以要分层：

Global Admission

当前最多允许多少 Resume。

Tenant Quota

避免一个大客户把所有 Worker 吃掉。

Dependency-aware Limit

例如：

model_concurrency
browser_slots
tool_qps
warehouse_slots

Fair Scheduling

不同 Tenant / Priority 公平拿资源。

Jitter / Batch

不要让所有 Timer 同一毫秒触发。

Retry Storm 和 Resume Storm 要区分 ​

两者看起来都像流量爆发，但触发原因不同：

Resume Storm
→ 大量合法 Waiting Run 同时重新 Ready

Retry Storm
→ 下游故障导致失败请求不断重试并自我放大

Retry Storm 还需要：

Exponential Backoff
Jitter
Retry Budget
Circuit Breaker
Dependency Health

否则 Runtime 自己会成为故障放大器。

项目映射 ​

研发 Agent 等 CI 恢复、Data Agent 等 Warehouse / Data Quality 恢复，都可能形成类似 Resume Burst。

高分亮点句 ​

恢复能力不仅要回答“能不能恢复”，还要回答“大家同时恢复时系统会不会被恢复流量打死”。

面试官真正想听什么 ​

• 是否有 Capacity / Backpressure 视角；
• 是否只会 Autoscale。

典型追问 ​

1. Fair Scheduling 怎么做？
2. 哪些任务优先？
3. Retry Storm 和 Resume Storm 区别？
4. Waiting Run 为什么也有成本？

Red Flags ​

• “多扩 Worker 就行。”

为什么这样回答 / 本题套路 ​

这是 Scale 题。先构造恢复流量峰值，再从下游 Capacity 反推 Admission / Quota / Fairness。

2.10 Q10｜Runtime 升级时 New Run、Running Run、Waiting Run 应怎样处理版本兼容？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

长任务发布不能按普通 HTTP 服务“一次替换”。

我会区分：

New Run
→ New Version

Running Run
→ Pin / Drain

Waiting Run
→ Resume Compatibility Check
→ Old Version or Migration

2～3 分钟高分回答 ​

一个 Run 可能等待几小时甚至几天。

期间：

agent code
checkpoint schema
tool schema
execution image

都可能升级。

所以 Run 必须绑定 Version Manifest：

agent_version
runtime_version
checkpoint_schema_version
tool_contract_version
execution_image_version

升级时：

New Run

直接走新版本。

Running Run

通常 Pin Old Version，Drain 完再下线。

Waiting Run

Resume 时检查：

old checkpoint
× new runtime

是否兼容。

不兼容则：

• 路由到 Old Worker；
• 做 Migration；
• 或人工终止 / Restart。

高分亮点句 ​

长任务发布的难点不是“新代码能不能启动”，而是“旧任务还能不能继续”。

面试官真正想听什么 ​

• 是否考虑 Waiting Run；
• 是否有 Version Pin / Migration；
• 是否理解长期执行和发布治理耦合。

典型追问 ​

1. Old Version 保留多久？
2. Checkpoint Migration 怎么测试？
3. Tool Contract 已废弃怎么办？
4. Runtime Rollback 会影响新 Run 吗？

Red Flags ​

• “发布后所有 Worker 滚动升级。”
• “Checkpoint 用 JSON，所以兼容。”

为什么这样回答 / 本题套路 ​

这是 Release / Migration 题。高分点是按 Run 生命周期分类，而不是从 K8s Rolling Update 视角回答。

2.11 Q11｜State Recovery 和 Semantic Recovery 为什么不是一回事？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

State Recovery 只回答：

“数据找回来了没有？”

Semantic Recovery 还要回答：

“从这个状态继续执行，业务意义还正确吗？”

2～3 分钟高分回答 ​

例如恢复到：

step = deploy

State 完整。

但真正 Resume 前还要问：

• Deploy 是否已经部分成功？
• Artifact 还在吗？
• Approval 还有效吗？
• Environment 还能重建吗？
• Credential 是否过期？
• Tool Contract 是否变了？
• Code Version 还能运行吗？

因此 Recoverability 应该更完整地定义成：

State Recoverable
+
Operation Reconciliable
+
Environment Reconstructable
+
Version Compatible
+
Pending Signal Recoverable

这也是 Runtime 和 Execution 的边界：

Runtime 定义恢复需要什么；Execution 真正把环境重建出来。

项目映射 ​

Coding Agent Checkpoint 还在，但 Sandbox TTL 已过期，就是典型 State Recovery 成功、Semantic Recovery 还没完成。

高分亮点句 ​

Recover State 不等于 Recover Meaning。

面试官真正想听什么 ​

• 是否把恢复等同读 DB；
• 是否理解环境 / Tool / Version 都参与语义恢复。

典型追问 ​

1. Browser Session 怎么恢复？
2. Approval 过期怎么办？
3. Artifact 丢了怎么办？
4. 什么时候直接 Restart 比 Resume 更合理？

Red Flags ​

• “Checkpoint 能读出来就算恢复成功。”

为什么这样回答 / 本题套路 ​

这是高级概念题。用一个“状态完整但外部世界已变”的例子，最容易体现语义恢复。

2.12 Q12｜Snapshot-based Runtime 和 History / Replay Runtime 怎样选择？ ​

复习优先级：P0｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

Snapshot（快照）偏向：

保存“现在是什么状态”。

History / Replay（历史 / 重放）偏向：

保存“怎么走到这里”。

前者简单、恢复快；后者审计和重建能力强，但对 Determinism（确定性）要求更高。

2～3 分钟高分回答 ​

Snapshot-based

优点：

• 直接读当前状态；
• Resume 快；
• 编程模型简单。

缺点：

• 难回答为什么到这里；
• Time Travel / Debug 弱；
• 中间事件需要额外日志。

History / Replay

保存：

Event / Journal

恢复时 Replay。

优点：

• Audit；
• Time Travel；
• 精确重建；
• 已完成步骤可跳过。

缺点：

• History Growth；
• Replay Cost；
• 非确定性操作必须被包起来；
• Code Versioning 更复杂。

Agent 特别要注意：

LLM
HTTP
Random
Time
External Tool

都是非确定性操作。

Restate 明确要求把数据库 / HTTP / Random 等非确定性操作包进 durable step，Replay 时读取 Journal；这就是 History / Replay 路线的典型约束。[R1]

高分亮点句 ​

Snapshot 优化“恢复现在”，History 优化“解释和重建过去”；选择本质上是 Recovery、Audit 和 Determinism 的权衡。

面试官真正想听什么 ​

• 是否理解 Replay 约束；
• 是否知道 Agent 非确定性比普通 Workflow 更强。

典型追问 ​

1. LLM Call 怎么 Replay？
2. History 太长怎么办？
3. Snapshot + History 能混用吗？
4. Event Sourcing 一定更好吗？

Red Flags ​

• “History Replay 就把 LLM 再调用一次。”

为什么这样回答 / 本题套路 ​

这是 Trade-off 题。必须同时讲编程体验、恢复、审计和 Determinism，不能简单说谁“更先进”。

2.13 Q13｜什么时候应该引入 Temporal / Restate / DBOS 一类 Durable Runtime，什么时候自己实现就够？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我不会因为“任务超过 30 秒”就上 Workflow Engine。

真正 Trigger 是：

Long Wait
Failure Recovery
Side Effect
Version
Signal
Concurrency

开始在多个业务里重复出现，而且自研复杂度快速增长。

2～3 分钟高分回答 ​

早期如果只有：

• 少量长任务；
• 一个团队；
• 简单 Retry；
• 少量审批；

用：

runs table
+ queue
+ timer
+ idempotency

完全可以。

真正值得引入成熟 Durable Runtime，是当你开始重复实现：

Checkpoint
Wait / Signal
Retry / Backoff
Durable Timer
Version Migration
Workflow Ownership
History / Replay
Recovery

这里要注意三类产品路线并不一样。

Temporal

代表成熟 Workflow / Activity / History Replay 路线。

Restate

更强调普通 Service Code + Journal / Replay + Durable RPC / State。

DBOS

更接近 Postgres-native Durable Workflow，利用数据库事务和持久化 Step 降低独立 Workflow Cluster 运维复杂度。DBOS 当前文档明确支持 Workflow Crash 后从已完成 Step 恢复、Durable Sleep、Workflow Timeout 等语义。[R2]

所以 Build vs Buy / OSS 的关键不是 Feature 数量，而是：

需要多强的 Durability
团队是否能承担 Runtime 运维
已有数据栈
迁移成本
语义控制权

高分亮点句 ​

Durable Runtime 应该在“可靠性语义开始重复建设”时平台化，而不是因为它听起来高级。

面试官真正想听什么 ​

• 是否会过早平台化；
• 是否理解不同 Durable Runtime 路线；
• 是否有 Build vs Buy 判断。

典型追问 ​

1. Postgres 自研能做到什么程度？
2. Temporal 和 Restate 最大差别是什么？
3. Workflow DSL 是优势还是负担？
4. 怎么迁移已有 Agent？

Red Flags ​

• “所有 Agent 都应该上 Temporal。”
• “自己写 Redis + Cron 永远够。”

为什么这样回答 / 本题套路 ​

这是架构选型题。先用 Trigger 判断是否值得引入，再比较不同实现的持久语义和运维模型。

2.14 Q14｜1000 个 Run 到百万级 Waiting Run 后，Runtime 在容量、调度、存储和多 Region 上会怎样演进？ ​

复习优先级：P2｜题型：S4 Architecture Evolution

30 秒核心回答 ​

规模上来后，Runtime 会从“状态表 + Worker”演进成真正的分布式调度系统。

最反直觉的一点是：

Waiting Run 可能远远多于 Running Run。

所以容量规划不能只看 CPU。

2～3 分钟高分回答 ​

我会从四个维度看。

State / Storage

Active State
Cold History
Checkpoint
Operation Ledger
Index
Retention

要分层存储。

Scheduling

需要：

Ready Queue
Priority
Tenant Quota
Fair Scheduling
Admission
Backpressure

Ownership

单机状态锁演进成：

Lease
Epoch
Fencing
Partition Ownership

Multi-region

需要先定义：

Home Region
Run Affinity
RPO / RTO
Failover
Data Residency

多 Region 最难的不是“复制数据库”，而是：

• Timer 不重复；
• Signal 不重复；
• Run Owner 唯一；
• Idempotency 全局有效；
• Artifact 可访问；
• Version 可用。

此外 Runtime 成本还包括：

State Storage
Checkpoint IO
Queue / Timer
Retry Waste
Waiting Run Retention
Human Operation Cost

这里还有一个容易被忽略的问题：Durability 会扩大数据治理面。

Run 持久化以后，下面这些原本可能只活几十秒的数据会被保存更久：

Tool Arguments
Approval Evidence
Checkpoint
Operation Ledger
Artifact Pointer
Trace
Context Reference

所以 Retention（保留策略）不能统一一个 TTL。不同对象要按：

Recovery Need
× Audit / Compliance
× Privacy
× Storage Cost

分别定义。

所以一个很有价值的指标是：

Cost per Successful Run
Cost per Waiting Run / Day

高分亮点句 ​

大规模 Runtime 最先变复杂的往往不是计算，而是等待、状态、所有权和恢复峰值。

面试官真正想听什么 ​

• 是否有大规模调度视角；
• 是否只会讲 Worker Autoscale；
• 是否理解 Multi-region 的语义问题。

典型追问 ​

1. Waiting Run 怎么分片？
2. Timer 怎么 Scale？
3. Run Home Region 宕机怎么办？
4. Retention 怎么定？

Red Flags ​

• “百万 Run 就多加 Pod。”
• “多 Region 复制 DB 就行。”

为什么这样回答 / 本题套路 ​

这是 Scale / Architecture Evolution 题。按 Storage、Scheduling、Ownership、Region 四轴展开，比堆组件更稳定。

2.15 Runtime 阶段性总结 ​

Runtime 的知识可以压缩成一条因果链：

任务活得越来越久
↓
内存状态不可靠
↓
需要 Checkpoint

任务会等待
↓
需要 Wait / Signal / Resume

任务会改变真实世界
↓
需要 Operation Ledger / Idempotency / Reconciliation

任务会分布式运行
↓
需要 Lease / Fencing / Backpressure

任务会跨版本和故障域恢复
↓
需要 Version / Migration / DR

最终只记一句：

Runtime 的目标不是保存状态，而是让一个 Run 在复杂现实里保持正确的生命周期语义。

三、Execution Infrastructure 执行基础设施 ​

3.1 Q15｜Environment（执行环境）、Workspace（工作区）、Artifact（产物）、Evidence（证据）在一次 Agent Execution 中分别是什么？生命周期如何串起来？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会把执行系统拆成四个对象：

Environment
→ 动作真正运行在哪里

Workspace
→ 任务持续读写的工作状态

Artifact
→ 需要跨环境生命周期保留下来的产物

Evidence
→ 证明动作和结果真实发生的可验证信息

它们的生命周期应该被显式管理，而不是都塞进“Sandbox”。

2～3 分钟高分回答 ​

一个 Coding Agent 的执行链可以是：

Provision Environment
→ Attach / Create Workspace
→ Execute
→ Produce Artifact + Evidence
→ Persist Artifact / Evidence
→ Cleanup Workspace
→ Destroy Environment

具体看：

Environment

• Container / MicroVM / VM；
• Runtime Dependency；
• Network；
• Execution Identity。

Workspace

• Repo Checkout；
• 临时数据； -中间文件； -任务持续状态。

Artifact

• Patch；
• Build Package；
• Notebook；
• Chart；
• Export。

Evidence

• Test Report；
• Diff；
• Exit Code；
• Deployment Status；
• Query ID。

项目映射 ​

研发 Agent：

Sandbox = Environment
Git Worktree = Workspace
Diff / Build = Artifact
Test Result = Evidence

Data Agent：

Query Engine / Notebook = Environment
Temp Table = Workspace / Intermediate State
Chart / Export = Artifact
Query ID / Metric Version = Evidence

高分亮点句 ​

Environment 是临时计算边界，Artifact 才是需要跨环境生命周期交付的结果。

面试官真正想听什么 ​

• 是否会把 Sandbox 当所有东西；
• 是否理解 Workspace / Artifact / Evidence 的生命周期差异。

典型追问 ​

1. Workspace 要不要持久化？
2. Artifact 和 Tool Result 有什么区别？
3. Evidence 一定是 Artifact 吗？
4. Environment Destroy 前必须做什么？

Red Flags ​

• “Sandbox 里生成的文件就是 Artifact。”
• “Workspace 和 Environment 是一回事。”

为什么这样回答 / 本题套路 ​

这是 Execution 的对象模型题。先把四个对象分开，后续 Secret、Network、Artifact、Recovery 才有清晰落点。

3.2 Q16｜Sandbox、Container、MicroVM、VM 的隔离强度和成本差异是什么？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

我不会把它们理解成“谁更高级”，而是四个维度的 Trade-off：

Isolation
Startup Latency
Resource Density
Operational Cost

越强的隔离通常越贵、启动越慢，但风险边界更清晰。

2～3 分钟高分回答 ​

粗略看：

Process / Container
→ 快、密度高、共享 Kernel，隔离相对弱

MicroVM
→ 更强 Kernel 边界、启动较快、成本中等

VM
→ 隔离更强、启动和资源成本更高

但真正选型不能只看技术名字，要看：

• 是否执行不可信代码；
• 是否多 Tenant；
• 是否带高权限 Credential；
• 是否允许 Network；
• 是否有 Host Mount；
• Blast Radius 多大。

一个 Container 如果：

mount docker.sock
mount host filesystem
expose cloud metadata

隔离几乎就没意义。

Anthropic 当前关于 Agent Containment 的工程总结也明确强调：随着 Agent 能力和权限增大，关键问题是限制 Blast Radius，方法包括 Process Sandbox、VM、Filesystem Boundary、Egress Control 等硬边界，而不是只依赖模型或人工审批。[R3]

高分亮点句 ​

Sandbox 是安全边界设计，不是“用了 Docker”这个实现细节。

面试官真正想听什么 ​

• 是否理解 Container ≠ 强安全边界；
• 是否能按风险选隔离层。

典型追问 ​

1. gVisor / seccomp / Landlock 属于哪层？
2. Coding Agent 一定要 VM 吗？
3. 多租户能否共享 Kernel？
4. Warm Pool 会不会削弱隔离？

Red Flags ​

• “用了 Kubernetes Pod 就安全了。”
• “VM 一定比 Container 更适合所有 Agent。”

为什么这样回答 / 本题套路 ​

这是基础设施 Trade-off 题。先给选型变量，再比较隔离层，不把实现名字当答案。

3.3 Q17｜为什么优先 Structured Tool / API，把 Browser / Computer Use 当更高风险的执行通道？ ​

复习优先级：P1｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我通常优先：

Domain API / Structured Tool
> Shell / Script
> Browser DOM
> Computer Use / GUI

因为越往后，状态越隐式、输入输出越难验证、误操作概率越高。

2～3 分钟高分回答 ​

Structured Tool 的优势：

• Schema 明确； -权限边界清晰； -错误码稳定； -幂等更容易； -审计更完整。

Browser / Computer Use 的问题在于：

• UI 会漂移； -页面状态隐式； -按钮可能被遮挡； -点击成功不代表业务成功； -坐标 /视觉识别可能错误； -动作后的真实状态需要重新 Ground。

所以我把 Computer Use 定位成：

Coverage 扩展能力，而不是默认 Reliability 最强的执行方式。

什么时候值得用？

• Legacy 系统无 API； -第三方 SaaS 只暴露 UI； -桌面软件； -长尾流程无法结构化接入。

项目映射 ​

研发 Agent：

Git / CI 有 API 就优先 API；只有内部旧系统没有 API 时再 Browser / Computer Use。

高分亮点句 ​

Computer Use 的核心价值是“能覆盖更多真实系统”，不是“执行更可靠”。

面试官真正想听什么 ​

• 是否理解 API / GUI 执行边界；
• 是否会过度 Computer Use。

典型追问 ​

1. Playwright 算 Structured Tool 还是 Computer Use？
2. GUI 动作怎么 Verification？
3. Browser 登录态怎么治理？

Red Flags ​

• “UI 能做的都让 Computer Use 做。”
• “点到按钮就算执行成功。”

为什么这样回答 / 本题套路 ​

这是方案选择题。核心是 Reliability / Observability / Verification 三个维度，而不是谁“更智能”。

3.4 Q18｜Secret（密钥）为什么不应该进入 Prompt、Tool Result、Log 或 Artifact？Secret Broker（密钥代理）应怎样工作？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Secret 一旦进入 Model / Context / Log 链路，就很容易被复制到 Trace、Eval Dataset、Artifact，生命周期失控。

更安全的模式是：

Identity
→ Policy
→ Secret Broker
→ Short-lived Credential
→ Out-of-band Inject

让 Agent 拥有“使用能力的权限”，而不是看到 Secret 原文。

2～3 分钟高分回答 ​

错误做法：

SYSTEM_PROMPT += API_KEY

或者：

env
→ stdout
→ Tool Result
→ Context
→ Trace

Secret 一旦进模型路径，后续删除很困难。

更合理的是先把三类身份分清：

User Identity
→ 谁提出任务

Agent Identity
→ 哪个 Agent / Run 代表用户行动

Execution Identity
→ 真正访问 Git / Cloud / DB 的工作负载身份

然后：

User / Agent Context
→ Authorization
→ Secret Broker / Workload Identity
→ scoped short-lived token
→ Executor injects to process / request

关键原则：

• 最小 Scope；
• 短 TTL；
• 自动 Revoke；
• 不返回 Secret 给模型；
• Trace 自动 Redact。

OpenAI 当前公开 Codex 安全实践也强调 Identity / Credential、Sandbox、Network Policy 与 Approval 组合治理，而不是把 Credential 暴露给模型。[R4]

高分亮点句 ​

Agent 应该拿到“使用某个能力的授权”，而不是拿到长期 Secret 本身。

面试官真正想听什么 ​

• 是否理解 Secret Exfiltration；
• 是否会 Out-of-band Credential Injection；
• 是否有 Workload Identity 思维。

典型追问 ​

1. Shell 进程怎么拿 Secret？
2. Browser 登录态算不算 Secret？
3. Secret Broker 宕机怎么办？
4. Trace 怎么脱敏？

Red Flags ​

• “API Key 放 System Prompt 就行。”
• “环境变量默认安全。”

为什么这样回答 / 本题套路 ​

这是安全工程题。先说明 Secret 进入模型链路后为什么不可控，再推导 Broker / Short-lived Identity。

3.5 Q19｜Network Egress（网络出站）为什么也是 Capability（能力）？Allowlist（白名单）为什么仍可能被滥用进行数据外泄？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Network Access 本身就是一种 Capability。

Allowlist 只说明：

“Agent 可以连接这个 Domain。”

它不等于：

“任何数据都可以发给这个 Domain。”

所以 Egress Policy 需要同时考虑 Destination 和 Data Flow。

2～3 分钟高分回答 ​

一个合法站点也可能支持：

• Upload；
• Webhook；
• Query Param；
• Public Paste；
• Search。

如果 Agent 能读敏感文件，又能访问：

allowed.example.com/upload

仍然可能 Exfiltrate。

所以 Egress Policy 至少要考虑：

Domain
Method
Path
Credential Scope
Data Classification
Request Size
Audit

高风险环境可以加：

• Proxy；
• DLP；
• Content Inspection；
• DNS / IP 约束。

研发 Agent 还要特别看 Software Supply Chain（软件供应链）：

npm install
pip install
curl | sh
build script
CI config

这些操作表面是“正常联网”，实际上可能把恶意 Package / Script 带进 Sandbox。
所以 Package Registry、Dependency Provenance、Lockfile、Malware / Vulnerability Scan 也属于 Execution Security，而不是只靠 Egress Allowlist。

OpenAI 当前公开的 Codex 内部部署说明明确采用 Managed Network Policy，对预期目标允许访问、对陌生 Domain 要求审批，并强调不提供 Open-ended Outbound Access。[R4] Anthropic 的 Containment 实践也把 Egress Control 当作硬边界之一。[R3]

高分亮点句 ​

Network Allowlist 是 Capability Grant，不是 Data Loss Prevention。

面试官真正想听什么 ​

• 是否理解 Prompt Injection + Network 的外泄链；
• 是否把 Allowlist 当终点。

典型追问 ​

1. Package Registry 可以放行吗？
2. DNS Rebinding 怎么办？
3. Proxy 本身怎么审计？
4. Browser Network 和 Shell Network 是否共用策略？

Red Flags ​

• “只允许公司白名单域名就安全了。”

为什么这样回答 / 本题套路 ​

这是安全边界题。核心是把“能连到哪里”和“能带什么数据出去”拆成两个问题。

3.6 Q20｜Browser Profile 串到另一个 Tenant，可能是哪几层出了问题？怎样修？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

这不是单纯 Cookie Bug，而是：

Identity
Profile Ownership
Pooling
Cache
Lifecycle

多个层一起失效。

我会把 Browser Profile 当成带身份和敏感 Session 的租户级资源。

2～3 分钟高分回答 ​

先检查：

profile_id
tenant_id
user_id
run_id

绑定是否完整。

常见问题：

• Warm Pool 跨 Tenant 复用；
• Profile Snapshot 没带 Owner；
• Cache Key 缺 Tenant；
• Session 并发共享；
• Destroy / Cleanup 不彻底；
• Resume 重新挂错 Profile。

修复：

Strong Ownership Binding
Tenant-scoped Pool
Re-auth on Reuse
Encrypted Profile Storage
TTL / Revoke
Cross-tenant Negative Test

如果浏览器 Profile 含 Cookie / Token，还必须按 Secret 类资源管理。

高分亮点句 ​

Browser Profile 不是“浏览器缓存”，而是带用户身份和权限的安全资产。

面试官真正想听什么 ​

• 是否理解 Browser Agent 多租户风险；
• 是否有资源 Ownership 思维。

典型追问 ​

1. Profile 能不能共享？
2. Warm Browser 怎么做？
3. 用户 Logout 后 Profile 怎么失效？
4. Browser Snapshot 怎么加密？

Red Flags ​

• “清 Cookie 就行。”
• “共用浏览器进程最省资源。”

为什么这样回答 / 本题套路 ​

这是 Incident 题。先把 Bug 从 Cookie 提升成多租户资源 Ownership，再给系统性修复。

3.7 Q21｜Per-call Ephemeral Sandbox 和 Per-task Stateful Sandbox 如何选择？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我的默认判断是：

短、独立、低状态任务
→ Ephemeral

长任务、需要 Workspace 连续性
→ Task-stateful

核心 Trade-off 是：

Isolation
State Continuity
Cold Start
Idle Cost
Recovery Complexity

2～3 分钟高分回答 ​

Ephemeral

优点：

• 干净； -隔离简单； -清理明确。

缺点：

• 每次初始化； -依赖重复安装； -跨 Tool Call 状态难保留。

Task-stateful

适合：

• Coding Agent；
• Notebook / Data Analysis；
• Browser Session。

优点：

• Workspace 连续； -重复调用低成本； -依赖保留。

风险：

• Secret Residue；
• Workspace Drift；
• Idle Cost；
• Profile / Tenant 污染；
• Recovery 要重建环境。

还有一个很重要的边界：

Task-stateful 不等于 Environment 必须一直在线。

例如 Coding Agent 等审批两小时，可以：

Persist Workspace / Artifact
→ Destroy or Hibernate Environment
→ Runtime Wait
→ Resume 时重建 Environment

所以我会把“Sandbox Persistence”与“Workspace Persistence”拆开，并把策略写进 Execution Contract，而不是由 Provider 默认行为决定。

高分亮点句 ​

Sandbox 是否持久，是任务语义的一部分，不应该是底层实现的偶然默认值。

面试官真正想听什么 ​

• 是否理解 Stateful 的收益与风险；
• 是否能按任务生命周期做选型。

典型追问 ​

1. Stateful Sandbox 等待审批时要一直活着吗？
2. Hibernation 怎么做？
3. Workspace 和 Sandbox 生命周期一定一致吗？

Red Flags ​

• “所有 Agent 都每次新建 Container。”
• “Coding Agent 一个 Session 共用同一 Workspace 就行。”

为什么这样回答 / 本题套路 ​

这是 Trade-off 题。重点不是列优缺点，而是把任务状态连续性与隔离 / 成本连接起来。

3.8 Q22｜Agent Cancel 了，但 Shell 子进程还在后台继续写数据，为什么？怎样设计 Cancellation Propagation？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

因为：

Run State 变成 CANCELLED，不代表真实执行进程已经停止。

Cancellation 必须沿：

Run
→ Tool
→ Executor
→ Process Tree / Remote Job

向下传播，并且最终 Verification 确认真的停了。

2～3 分钟高分回答 ​

完整流程：

User Cancel
→ Runtime marks CANCELLING
→ Signal active execution
→ Executor sends graceful terminate
→ Grace Period
→ Force Kill
→ Verify process / job stopped
→ Cleanup
→ CANCELLED

难点包括：

• subprocess 已脱离父进程；
• shell 启动后台 job；
• remote query 已提交；
• deploy 已进入远端系统；
• browser action 已触发。

所以 Cancel 也要有 Recovery Contract。

例如远端 SQL：

cancel query_id
→ poll status
→ confirm TERMINATED

而不是只把 Run DB 状态改成 cancelled。

高分亮点句 ​

Cancellation 是一条跨 Runtime 和 Execution 的协议，不是一个状态字段。

面试官真正想听什么 ​

• 是否理解逻辑取消和物理停止的区别；
• 是否会清理 Process Tree / Remote Job。

典型追问 ​

1. Force Kill 后 Artifact 怎么办？
2. Tool 不支持 Cancel 怎么办？
3. Cancel 和 Compensation 区别？
4. Cancellation 是否幂等？

Red Flags ​

• “把 run.status 更新成 CANCELLED。”

为什么这样回答 / 本题套路 ​

这是跨层故障题。先指出控制面状态与现实执行的断层，再给传播和 Verification。

3.9 Q23｜Environment Snapshot 和 Runtime Checkpoint 有什么本质区别？ ​

复习优先级：P1｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

Runtime Checkpoint 保存：

任务逻辑状态。

Environment Snapshot 保存：

执行环境状态。

恢复 Checkpoint 不代表环境还存在；恢复 Environment 也不代表副作用语义正确。

2～3 分钟高分回答 ​

Checkpoint

可能有：

current_todo
run_state
approval
operation_id
budget
version

Environment Snapshot

可能有：

filesystem
workspace
installed dependencies
browser profile
environment manifest

Coding Agent Crash 后：

Checkpoint
→ 知道要继续 run_test

Environment
→ 还需要 Repo Diff / Dependency 才能真正继续

所以 Runtime 负责：

“恢复需要什么状态。”

Execution 负责：

“把环境重建出来。”

如果 Environment Snapshot 和 Checkpoint 绑定不一致，就会出现非常难查的 Resume Bug。

高分亮点句 ​

Runtime 恢复的是“任务语义”，Execution 恢复的是“任务的手脚和现场”。

面试官真正想听什么 ​

• 是否分清 State 与 Environment；
• 是否理解长 Coding / Browser Agent 恢复。

典型追问 ​

1. Snapshot 要保存 Process Memory 吗？
2. Container Image 和 Snapshot 区别？
3. Workspace 是否应该独立于 Environment？

Red Flags ​

• “有 Checkpoint 就能恢复 Sandbox。”
• “Snapshot 恢复后 Tool 可以直接重跑。”

为什么这样回答 / 本题套路 ​

这是边界题。用 Coding Agent 恢复现场解释最直观。

3.10 Q24｜Computer Use 为什么必须做动作后 Verification？哪些 Evidence 才足以证明动作成功？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

GUI 动作完成不等于业务动作成功。

Click
≠
Effect

所以 Computer Use 必须：

Execute
→ Re-observe
→ Verify Business Invariant

而且 Verification 尽量使用比“看截图”更强的 Evidence。

2～3 分钟高分回答 ​

点击 Deploy 按钮后，可能：

• 页面没响应； -点错按钮； -权限弹窗遮挡； -后端提交失败； -页面只更新了乐观 UI。

Evidence 强度大概可以理解成：

Mouse action completed
< Screenshot changed
< DOM / Accessibility state
< Backend task ID
< Remote system status
< Business invariant verified

所以我不会把：

“按钮变灰了”

当 Deploy Success。

更强的是：

deployment_id
→ status = SUCCEEDED
→ health check pass

如果条件允许，Verification 最好使用独立于动作通道的证据。

例如：

Browser 点击 Deploy
→ 不只继续看同一页面
→ 通过 Deployment API / Service Health 再确认

这样可以减少“UI 自己说自己成功”的同源错误。

项目映射 ​

研发 Agent / Computer Use 场景特别重要；Data Agent UI 导出也一样，点击 Download 不代表 Artifact 已生成。

高分亮点句 ​

Computer Use 最危险的误区，是把“动作完成”当成“目标完成”。

面试官真正想听什么 ​

• 是否理解 Action Proposal / Action / Effect 三层；
• 是否有 Evidence 强度意识。

典型追问 ​

1. DOM Verification 一定可靠吗？
2. UI 和 Backend 状态冲突听谁的？
3. 无 API 系统怎么验证？

Red Flags ​

• “截图变化就算成功。”
• “模型说成功就成功。”

为什么这样回答 / 本题套路 ​

这是 Verification 题。先建立 Evidence 强弱梯度，再强调业务 Invariant。

3.11 Q25｜Artifact 为什么必须在 Environment Destroy 前完成发现、扫描、持久化和 Provenance 绑定？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Environment 是临时的，Artifact 是交付物。

所以生命周期必须是：

Discover
→ Scan
→ Persist
→ Bind Provenance
→ Export
→ Destroy Environment

而不是先销毁 Sandbox，再去找产物。

2～3 分钟高分回答 ​

常见事故：

Agent 测试成功
→ Sandbox TTL 到期
→ 用户第二天点下载
→ /tmp/report.html 已不存在

所以 Artifact 生命周期必须独立。

持久化前做：

• Secret Scan；
• Malware Scan；
• Size / Type Validation；
• Classification。

然后绑定：

artifact_id
run_id
operation_id
environment_id
producer_step
content_hash
created_at

如果 Artifact 参与最终 Verification，还要把它和 Evidence 关系保存。

高分亮点句 ​

执行环境可以销毁，业务结果不能跟着销毁。

面试官真正想听什么 ​

• 是否理解 Artifact 生命周期；
• 是否会做 Provenance / Scan；
• 是否考虑 Sandbox TTL。

典型追问 ​

1. Artifact 保留多久？
2. Workspace 文件都要变 Artifact 吗？
3. Artifact 版本怎么管理？
4. 大 Artifact 怎么传给模型？

Red Flags ​

• “用户要下载时再去 Sandbox 找文件。”

为什么这样回答 / 本题套路 ​

这是 Lifecycle 题。用“环境短命、产物长命”的生命周期差异推导持久化顺序。

3.12 Q26｜从 10 个 Sandbox（沙箱）到 10 万个后，Execution Control Plane（执行控制面）要新增哪些能力？ ​

复习优先级：P2｜题型：S4 Architecture Evolution

30 秒核心回答 ​

规模上来以后，问题从：

“怎么启动一个 Container”

变成：

怎么治理一个多租户 Compute Fleet。

Execution Control Plane 会需要 Scheduling、Quota、Warm Pool、Image / Snapshot、Identity、Network、TTL、Cost、Provider Routing。

2～3 分钟高分回答 ​

我会拆成七个维度。

Provisioning

Environment Registry
Image / Snapshot
Warm Pool

Scheduling

Region
Capacity
Affinity
Priority

Tenant

Quota
Isolation
Fairness

Security

Execution Identity
Secret Broker
Network Policy

Lifecycle

TTL
Hibernation
Reaper
Cleanup

Data

Workspace
Artifact
Snapshot

Economics

Cost Accounting
Provider Routing
Idle Cost

真正的 Scale 问题包括：

• Cold Start P95；
• Pool Fragmentation；
• Cross-tenant Reuse；
• Image Drift；
• Region Capacity；
• Zombie Environment。

高分亮点句 ​

10 万 Sandbox 的问题已经不是“容器技术”，而是一个专用 Compute Control Plane。

面试官真正想听什么 ​

• 是否有平台规模视角；
• 是否理解 Execution Fabric 会自然平台化。

典型追问 ​

1. Warm Pool 怎么隔离 Tenant？
2. Scheduler 优先级怎么设计？
3. Provider 怎么做多云路由？
4. 资源利用率和安全怎么平衡？

Red Flags ​

• “Kubernetes 自己会调度。”
• “扩 Node 就行。”

为什么这样回答 / 本题套路 ​

这是 Scale / Platform 题。先指出问题类型发生了质变，再按 Fleet 能力分层。

3.13 Q27｜Cold Start、Warm Pool、Snapshot、Hibernation 应怎样在时延和成本之间权衡？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

四种方案本质是在用：

闲置资源 / 存储 / 恢复复杂度换启动时延。

不存在全局最优，应该按任务类型分层。

2～3 分钟高分回答 ​

Cold Start

• 成本低； -启动慢； -状态最干净。

Warm Pool

• 启动最快；
• Idle Cost 高； -池化需要强隔离。

Snapshot

• 启动速度和成本折中； -有 Snapshot Version / Compatibility 问题。

Hibernation

• 适合长等待； -需要持久 Workspace / State； -恢复更复杂。

我会按任务分：

Interactive Coding
→ Warm / Snapshot

Batch Research
→ Cold

Long Human Approval
→ Persist Workspace + Hibernate / Recreate

衡量：

Provision P50/P95
Warm Hit Rate
Idle Cost
Restore Failure
Cross-tenant Risk
Image Drift

项目映射 ​

研发 AI Workflow 等待 Review 两小时，不应该为了保留 Container 一直烧资源。可以持久化 Workspace / Artifact，Runtime Wait，Resume 时重建 Environment。

高分亮点句 ​

不要把“环境保持在线”误认为“任务状态持久化”。

面试官真正想听什么 ​

• 成本 / 时延权衡；
• Runtime / Execution 生命周期分离；
• 是否理解 Hibernation / Recreate。

典型追问 ​

1. Snapshot 安全怎么做？
2. Warm Pool 命中率低怎么办？
3. Browser Profile 要不要跟 Sandbox 一起 Hibernate？

Red Flags ​

• “长任务必须一直保留 Sandbox。”
• “Warm Pool 总是更快所以应该默认开。”

为什么这样回答 / 本题套路 ​

这是性能 / 成本 Trade-off 题。核心是把用户体验、Idle Cost、状态恢复三者一起看。

3.14 Execution 阶段性总结 ​

Execution 的主线可以压缩成：

模型提出 Action
↓
系统决定能不能执行
↓
准备 Environment / Workspace / Identity / Network
↓
执行 Tool / Shell / Browser
↓
收集 Artifact / Evidence
↓
Verification
↓
Cleanup / Persist

真正要记住五句话：

1. Sandbox 是边界，不是完整 Execution Infrastructure。
2. Secret 应该被使用，不应该被模型看见。
3. Network Egress 本身就是 Capability。
4. Action Completed ≠ Business Effect Verified。
5. Environment 可以销毁，Artifact / Evidence 必须有独立生命周期。

四、把 Runtime 与 Execution 真正连起来 ​

4.1 两层分别承担什么 ​

Runtime：

Run State
Checkpoint
Wait / Signal
Retry
Lease / Fencing
Version
Operation Ledger

Execution：

Environment
Workspace
Identity
Secret
Network
Shell / Browser
Artifact
Evidence

二者之间最重要的 Contract 是：

Execution Request
→ operation_id
→ environment requirement
→ identity / permission
→ cancellation token
→ timeout semantics
→ expected artifact / evidence

以及：

Execution Result
→ operation_id
→ actual status
→ external resource id
→ artifact
→ evidence
→ retryability / unknown outcome

4.2 一个真实研发 Agent 长任务怎样串起来 ​

Run R1 创建
→ Runtime 记录 version / budget

Harness 决定修改代码
→ Execution 创建 Workspace / Sandbox

Agent edit / test
→ Artifact: diff
→ Evidence: test report

Runtime checkpoint C1
→ 等 Human Review
→ WAITING

Sandbox 可释放
→ Workspace / Artifact 持久化

Approval Signal 到达
→ Runtime Resume

Execution 重建 Environment
→ restore workspace

Merge Operation OP1
→ Timeout

Runtime / Executor Reconcile
→ remote merge succeeded

Verification
→ PR merged + CI healthy

Run COMPLETE

这个案例把本篇几乎所有高频概念串起来。

4.3 三个最容易混淆的边界 ​

Checkpoint ≠ Environment Snapshot ​

一个保存任务语义，一个保存执行现场。

Approval ≠ Containment ​

Approval 回答：

“这次动作要不要由人确认？”

Containment（隔离约束）回答：

“即使模型、人或外部输入都判断错了，技术边界最多允许它造成多大影响？”

因此高频 Approval 不能替代：

Sandbox
Filesystem Boundary
Network Policy
Short-lived Credential
Resource Scope

Retry ≠ Reconciliation ​

Retry 是再试一次；Reconciliation 是先搞清楚真实世界到底发生了什么。

Approval ≠ Containment ​

Approval 是人确认本次动作；Sandbox / Network / Identity 才是确定性的能力边界。

Anthropic 当前公开工程实践提到 Permission Prompt 长期可能产生 Approval Fatigue（审批疲劳），而 Hard Containment 能从能力边界上限制 Blast Radius。[R3]

五、P7+～P8 面试里怎样讲好这一篇 ​

5.1 不要一上来背分布式系统术语 ​

低质量：

我们有 Checkpoint、Lease、Fencing、Saga、DLQ……

高质量：

先讲一个 Crash Window
↓
说明为什么会产生错误副作用
↓
再推导 Ledger / Idempotency / Reconciliation

让术语服务于 Failure。

5.2 最值得准备的三个真实故事 ​

故事 A：副作用不确定 ​

Timeout / Crash
→ 不知道远端成功没
→ 怎么恢复

故事 B：长等待 ​

CI / Approval / External Job
→ Worker 不应该一直占着
→ Wait / Signal / Resume

故事 C：执行隔离 ​

Sandbox / Secret / Network / Workspace
→ 为什么原边界不够
→ 怎样缩小 Blast Radius

这三个故事几乎能覆盖大多数 Runtime / Execution 追问。

5.3 面试官挑战时怎么答 ​

如果面试官说：

“这么复杂，为什么不用 Redis + Queue 自己写？”

不要马上反驳。

可以说：

“如果目前只有少量长任务、简单 Retry，我也会优先用 runs table + queue + timer。真正让我考虑 Durable Runtime 的 Trigger，是 Wait / Signal、Side-effect Recovery、Version Migration 这些可靠性语义开始被多个业务重复实现。”

如果问：

“为什么每次都审批不就安全了吗？”

可以答：

“审批对高风险动作有价值，但它是概率性的人为监督，不是技术隔离。大量审批还会带来 Approval Fatigue，所以我更希望低风险动作在强 Sandbox / Network / Identity 边界里自动执行，高风险越界动作再审批。”

这类回答比“行业最佳实践就是这样”更有判断力。

六、本篇 2～3 分钟总复述 ​

如果面试官让你整体讲：

“你怎么理解 Agent Runtime 和执行基础设施？”

可以这样回答：

“我会把 Runtime 和 Execution 分成两个责任。Runtime 解决的是 Run 怎么跨时间和故障正确活着，所以核心是 Checkpoint、Wait / Signal / Resume、Operation Ledger、Idempotency、Reconciliation、Lease / Fencing 和 Version。Execution 解决的是动作在哪里真实发生，所以核心是 Environment、Workspace、Execution Identity、Secret、Network、Sandbox、Browser，以及 Artifact / Evidence。

真正生产里最难的是两层交界：比如 Tool 已经成功，但 Worker 在写 Checkpoint 前 Crash，恢复时不能直接 Retry，而要基于 Operation ID 和远端状态做 Reconciliation；或者 Runtime Checkpoint 还在，但 Sandbox 已销毁，就要由 Execution 重建 Workspace / Environment。

所以我的核心判断是：Durable Execution 不是让程序永不失败，而是失败后还能保持业务语义正确；Sandbox 也不是一个 Container，而是限制 Agent Blast Radius 的确定性执行边界。Runtime 负责让任务活着，Execution 负责让任务安全地改变现实世界。”

七、业界实现证据与边界 ​

本篇引用公开实现，只用于验证这些问题已进入真实生产工程，不要求面试背产品 Feature。

• [R1] Restate — Durable Execution / Request Lifecycle / Architecture：通过 Journal 记录 durable step；失败后 Replay 已完成结果；使用递增 Epoch 拒绝旧 Attempt 的迟到事件。
  https://docs.restate.dev/guides/request-lifecycle
  https://docs.restate.dev/references/architecture
  https://docs.restate.dev/develop/ts/durable-steps

• [R2] DBOS — Workflows：Workflow / Step 可持久恢复，支持 Durable Sleep、Workflow Timeout 等长任务语义，并采用 Postgres-native 路线降低独立 Workflow Infrastructure 的复杂度。
  https://docs.dbos.dev/python/tutorials/workflow-tutorial
  https://docs.dbos.dev/

• [R3] Anthropic — How we contain Claude across products / Claude Code sandboxing：强调 Failure Probability × Blast Radius、Sandbox / VM / Filesystem / Egress 等硬边界，以及大量 Permission Prompt 产生 Approval Fatigue 的现实问题。
  https://www.anthropic.com/engineering/how-we-contain-claude
  https://www.anthropic.com/engineering/claude-code-sandboxing

• [R4] OpenAI — Running Codex safely at OpenAI / Codex Sandbox：当前公开实践把 Sandbox、Approval、Managed Network Policy、Identity / Credentials、Agent-native Telemetry 作为联合安全边界；Codex 的公开安全材料也明确区分本地 OS Sandbox 与 Cloud isolated container，并默认收紧网络和 Workspace 写入范围。
  https://openai.com/index/running-codex-safely/
  https://deploymentsafety.openai.com/gpt-5-2-codex/cybersecurity

产品会变化，真正应掌握的是稳定机制：

text

Durable State
Wait / Resume
Side-effect Recovery
Ownership
Version
Isolation
Identity
Network
Evidence
Verification

八、本篇最终记忆锚点 ​

如果只记 14 句话：

1. Harness 管怎么干活，Runtime 管怎么活着，Execution 管手脚在哪里动。
2. Durable Execution 不是不失败，而是失败后保持业务语义正确。
3. State Recovery ≠ Semantic Recovery。
4. Timeout ≠ Failure；它可能只是 Unknown Outcome。
5. Ledger 负责记得做过，Idempotency 负责重复不重复生效，Reconciliation 负责确认现实。
6. Exactly-once 必须先问 Guarantee Boundary。
7. Lease 决定 Owner，Fencing 防止旧 Owner 继续造成影响。
8. Waiting Run 可能远多于 Running Run。
9. Checkpoint ≠ Environment Snapshot。
10. Sandbox 是执行边界，不是完整 Execution Infrastructure。
11. Secret 应该被使用，不应该被模型看见。
12. Network Egress 本身就是 Capability。
13. Action Completed ≠ Business Effect Verified。
14. Environment 可以销毁，Artifact / Evidence 必须有独立生命周期。

九、本篇最容易拉开候选人差距的专家判断 ​

1. **State Recovery ≠ Semantic Recovery。**状态能读回来，不代表现实世界还能安全继续。
2. **Timeout 是 Unknown Outcome，不天然是 Failure。**有副作用动作直接 Retry 可能比不重试更危险。
3. Exactly-once 必须先写清 Guarantee Boundary；消息 Exactly-once 不等于真实副作用 Exactly-once。
4. Lease 只能说明“谁应该执行”，Fencing 才能阻止旧 Owner 继续造成影响。
5. Checkpoint 恢复任务语义，Environment Snapshot 恢复执行现场，两者不是替代关系。
6. Approval 是人为 Gate，Containment 才是确定性 Blast Radius 边界。
7. Waiting Run 的规模和成本可能远大于 Running Run；容量规划不能只看 CPU。