Agent Infra：Runtime、Sandbox 与可靠执行
Agent Demo 能完成一次工具调用，不代表它能承受 Worker 重启、网络超时和几十万等待中的任务。Agent Infra 面试真正考察的是：当模型把执行路径变得动态以后，你能否继续用分布式系统方法保证副作用、状态和资源都可控。
这一章不把 Gateway → Queue → Worker 当作万能架构图，而是沿着可靠性边界追问：状态写到哪里、超时后能不能重试、Kubernetes 重建 Pod 后谁来恢复业务执行。
真实面经信号：岗位名称不等于只考 Agent 概念。阿里云 Agent Infra 一面同时考了 Go/Java、Spring Bean、gRPC、TCP、MySQL、Redis、RAG 和项目源码；另一篇阿里云 Agent Infra 一面考了缓存系统、并发编程与快速排序。准备这类岗位时，Runtime 设计和传统后端底座缺一不可。
Q：为什么需要 Checkpoint，恢复时从哪里继续？
来源：长任务恢复与状态管理高频题 / 字节数据平台 Agent 一面 / MINISO Agent 开发实习一面 / 哔哩哔哩秋招一面【阿里 Agent Infra 一面题库同题：状态管理、Checkpoint 与保存时机】【拼多多 - Agent 开发岗（工程化 + 数据库）追问：断点恢复（服务重启后加载未完成状态）？】【深圳tuitti视界之外实习一面追问：这时候你是怎样恢复图的运行状态的？】
新手答：“每一步保存消息，Pod 挂了以后读取最后一条继续执行。”
高手答：
我会区分三类持久化数据：
| 数据 | 作用 | 典型内容 |
|---|---|---|
| 事件日志 | 记录已经发生的事实 | 状态转换、模型响应、Tool 执行状态 |
| Checkpoint | 加速恢复 | 当前 Step、Context 引用、Budget、版本 |
| 副作用记录 | 去重和对账 | execution_id、下游请求 ID、结果摘要 |
Checkpoint 应围绕一致性边界保存，而不是机械地“每轮保存一次”。模型已经产生 Tool Call、工具即将分发、工具结果提交、进入人工等待，都是重要边界。
恢复时先取得 Run 的新 lease，加载最近 Checkpoint，再重放后续事件，最后检查未决 Tool Call。只有状态明确为未执行且重试安全时才继续；如果外部操作可能成功但结果未落库，应进入 UNKNOWN，通过下游幂等查询或对账确认，不能直接重放。
Worker 中断时还要验证 Checkpoint 之后的事件是否完整、Artifact 是否已原子提交、原 Worker 的 lease 是否失效。失败点重试不是从某个函数行号继续，而是从最近的可验证业务边界重建输入；过期 Worker 晚到的结果必须被 fencing token 或状态版本拒绝。
差距在哪：新手把 Checkpoint 当消息快照，高手能处理快照之后的事件、并发恢复和不确定副作用。
Q：如何支撑几十万并发 Agent Task，并把它观测清楚？
来源：高并发调度与 Agent Observability 高频题 / 顺极 Agent 开发二面 / 中国电信风控 Agent 二面 / 互联网金融 Agent 开发三面 / 百度 Agent 一面【阿里 Agent Infra 一面题库同题：MQ、背压、多租户、Scheduler 与 Worker 拆分】【拼多多 - Agent 开发岗（工程化 + 数据库）追问：长耗时 Agent 的资源占用及并发优化？】
新手答：“用 MQ 解耦，再水平扩容 Worker，接入日志、指标和链路追踪。”
高手答：
我会先澄清“几十万并发”是活跃会话、等待任务还是同时计算，并给出到达率、平均步骤数、各阶段耗时和 SLO。大量 Run 可能在等待 LLM、Tool 或人工事件，不能都占用 Worker。
控制面按租户、优先级和资源类型分队列；用 visibility timeout/lease、ack、DLQ 和毒任务隔离保证消费；用 weighted fair scheduling、并发配额和 admission control 防止大租户挤占资源；对 LLM、GPU 和外部 Tool 分别实施背压，而不是只按 CPU 扩容。
全量开放前还要把模型分层和成本预算放进准入：简单步骤走低成本模型，复杂或高风险步骤才升级；Run、租户和平台分别设置 Token、金额、并发和 Deadline 上限。容量规划用到达率、各资源阶段服务时间和长尾分布估算，不能把“sub-agent 最多开几个”写成固定常数。容器 CPU/内存水位、GPU/KV 容量、模型配额和外部 Tool 限流必须分别观测，哪个先饱和就在哪一层背压。
Sandbox 容量要单独建模：区分冷启动、预热池、活跃执行和回收中实例，按租户与风险等级设并发配额。扩容信号不只看队列长度，还要看队列等待时间、启动耗时、CPU/内存/磁盘水位和回收失败率。预热复用必须先验证文件、进程、缓存和凭证已清理，否则优先牺牲冷启动时延而保持一次性隔离。
一个 Run 是根 Trace，模型、检索、工具、Sandbox 和状态提交是 Span。核心指标包括任务语义成功率、基础设施失败率、队列等待、端到端延迟、步骤数、Token/Cost 和 UNKNOWN 副作用数。Prompt、Tool 参数和结果可能包含隐私，必须脱敏、采样、分级存储和审计，不能直接放进高基数 Metrics Label。
差距在哪：新手会画 Queue + Worker，高手先定义负载模型，并同时处理公平性、下游瓶颈和可观测数据治理。
Q：一次 Agent 请求的完整执行链路是什么？
来源：字节跳动 Agent 后端开发业务终面 / 阿里控股 Agent Infra 二面 / Agent Runtime 完整管线设计高频题【字节火山引擎 Managed Agent 一面同题】【阿里 Agent Infra 一面题库同题】【深信服Agent开发实习生一面二面，长时间被吊着，最终被横向掉了追问：处理流程可以讲一下吗？整体链路是怎样的？】【百度Agent一面追问：如果问某上市公司去年毛利率下降，Agent 收到 Prompt 后的完整流程是什么？】
新手答：“用户请求模型，模型调用工具，拿到结果后继续推理。”
高手答：
1. Gateway 完成身份、租户、限流和请求幂等校验
2. Control Plane 创建 Run，持久化初始状态和版本快照
3. Scheduler 发放带 lease 的下一步任务
4. Worker 装配 Context，调用模型并持久化响应或 Tool Call
5. Policy 层校验工具、参数、权限、预算和审批要求
6. Tool Runtime 以 execution_id 执行动作
7. 结果进入 SUCCEEDED、FAILED 或 UNKNOWN，并写入事件日志
8. 状态机决定继续、降级、等待、补偿或结束
9. 全链路记录 Trace、成本、版本和审计信息这里记录的是模型响应和结构化决策，不依赖保存模型私有推理过程。Run 还要有最大步骤、总 Deadline、Token/Cost Budget 和取消传播，防止模型循环无限消耗资源。
差距在哪：新手只描述模型循环，高手能指出接入幂等、租约、策略门禁、状态提交和退出条件。
Q：Kubernetes Pod/Deployment 从提交到就绪经历哪些控制链路？
来源：百度 AI Infra 校招面经 / 虾皮 AI Infra 实习一面 / 虾皮 AI Infra 实习二面 / 字节社招一面【阿里 Agent Infra 一面题库追问：Kubernetes Scheduler 基本调度流程】
新手答：“请求交给 API Server，Scheduler 选节点，Kubelet 拉起容器。”
高手答：
客户端请求先经过 API Server 的鉴权、准入和校验，再持久化到 etcd。Deployment Controller 通过 watch/Informer 观察期望状态并创建 ReplicaSet，ReplicaSet 再创建 Pod。Scheduler 为未绑定 Pod 做过滤、评分并写入节点绑定；目标节点上的 Kubelet 调用 CRI 拉镜像和启动容器，按声明协调 CSI 存储与 CNI 网络。探针通过后 Pod 才 Ready，Service 对应的 EndpointSlice 随之更新。
这是一组异步、最终一致的 Reconcile，不是一条同步 RPC。CSI、CNI 的具体调用位置还受运行时、插件和 Kubernetes 版本影响，回答时应说明组件责任，不硬背一条固定时序。
差距在哪：新手背组件顺序，高手能讲清对象所有权、watch/reconcile、调度绑定与数据面就绪的边界。
Q：Tool 已成功但 Runtime 在写状态前宕机，如何避免重复副作用？
来源：分布式幂等与部分失败高频题【多益三面同题】【阿里 Agent Infra 一面题库同题：幂等、Exactly Once 与 Tool 部分成功】【字节agent一面追问：Agent 超时重复下单是高风险问题，你们怎么实现幂等避免重复操作？】【阿里边缘bu 秋招一面 （已过）追问：如果工具调用成功，但 Redis Checkpoint 写入失败，系统如何恢复并避免重复执行？】
新手答：“给 Tool Call 加一个唯一 ID，恢复时查数据库。”
高手答：
唯一 ID 只有被副作用边界识别才有价值。我会为逻辑动作生成稳定的 execution_id，重试时保持不变，并优先把它传给下游作为幂等键：
PENDING → DISPATCHED → RUNNING → SUCCEEDED
├→ FAILED
└→ UNKNOWN- 下游支持幂等键：重复请求返回同一业务结果；
- 同一数据库内：用唯一约束、事务或 Transactional Outbox；
- 下游支持查询：按业务键查询并对账；
- 下游既不幂等也不可查询：超时后标记
UNKNOWN，交由人工确认或补偿流程。
对支付、发消息、删除资源等操作还应增加审批、操作分级和审计。Saga 补偿也不等于回滚，补偿本身可能失败并且必须幂等。
差距在哪：新手只说“去重”，高手知道最危险的是执行结果未知，并能按下游能力选择事务、对账或人工介入。
Q：如果让你设计一个 Agent Runtime，你会怎么拆？
来源：Agent Infra / 平台工程系统设计高频题 / 字节中国交易与广告 AI 应用开发一面【阿里 Agent Infra 一面题库追问：Runtime 定义、Framework 边界与无状态 Worker】【百度 - Agent 研发岗（架构方向）追问：通用 Agent Runtime（兼容多种大模型）如何设计？】
新手答：“接入 LLM，再提供工具、Memory 和日志，最后部署到 Kubernetes。”
高手答：
我会先把一次 Agent Run 建模为可能暂停和恢复的有状态执行，再拆成管理面、控制面和执行面：
Management Plane：Agent/Tool/Skill 注册、版本、发布与租户配置
Control Plane：状态机、租约、调度、超时、配额与恢复
Execution Plane：LLM Worker、Tool Worker、Sandbox
Data Plane：Run State、事件日志、Checkpoint、Artifact、Memory
Observability：Trace、Metrics、Logs、Eval、Cost、AuditRuntime 不应依赖某个 Worker 的本地内存。每次状态转换都带版本号，Worker 通过 lease 领取任务，提交结果时检查 lease 和状态版本，避免过期 Worker 覆盖新结果。暂停等待人工审批时释放 Worker，审批事件到达后再唤醒任务。
LangChain、LangGraph 等 Framework 主要提供 Agent/Graph 的开发抽象；Runtime 负责租约、持久化、恢复、隔离、配额和跨 Framework 的执行治理。两者可以集成，但不能把“Graph 能表达状态”误认为“平台已经具备生产运行语义”。
生产目标通常是 at-least-once 调度 + 幂等副作用，而不是轻易承诺 exactly-once。还要为每个 Run 固定模型、Prompt、Tool 和策略版本，否则恢复后可能在另一套行为定义上继续执行。
取消也是一次并发状态转换，不是发一个中断信号就结束。Runtime 先持久化 CANCEL_REQUESTED，停止派发新 Step，再把取消传播到模型、Tool 和 Sandbox。完成结果与取消同时到达时，用状态版本和明确的转换表决定胜者；过期 Worker 的迟到结果只可审计，不能覆盖终态。
对发送消息、付款、写外部系统等不可逆副作用，取消只能阻止尚未发生的动作；已分发但结果未知的进入 UNKNOWN，通过幂等查询、对账或补偿收敛。最终给用户的结果应区分“已取消且无副作用”、“部分完成”和“结果待确认”，并保留已完成步骤的证据。
差距在哪：新手罗列组件，高手先定义执行语义，再说明状态所有权、并发控制和版本边界。
Q：Agent Sandbox 解决什么问题，为什么容器不一定够？
来源：荣耀 AI Infra 一面 / 百度 AI Infra 面经 / 互联网金融 Agent 开发三面 / 代码执行与隔离设计高频题【阿里 Agent Infra 一面题库追问：隔离选型、资源约束与委托身份】
新手答：“Docker 有 Namespace 和 Cgroup，可以安全运行模型生成的代码。”
高手答：
Sandbox 运行的是不可信代码，目标不只是限制 CPU 和内存，还要控制文件系统、网络、系统调用、凭据、进程树、磁盘和执行时间。容器共享宿主机内核，隔离强度取决于 user namespace、capabilities、seccomp、SELinux/AppArmor 和宿主配置，不能把“用了 Docker”直接等同于安全。
| 场景 | 可选隔离 | 主要代价 |
|---|---|---|
| 内部只读工具 | 加固容器 | 隔离较轻，启动快 |
| 多租户代码执行 | gVisor / Kata | 兼容性或启动开销 |
| 高风险不可信代码 | MicroVM | 镜像、池化和运维成本 |
无论采用哪种方案，都应使用短期身份、只读根文件系统、默认拒绝网络、资源上限和硬 Deadline。复用预热 Sandbox 可以降低冷启动，但必须证明租户间文件、进程、缓存和凭据已经清理；高风险任务更适合一次性销毁环境。
当 Agent 代表用户调用外部系统时，Runtime 应把已认证用户映射为短期、限定 audience/scope 的委托凭证，并在受控传输层注入；长期密钥、刷新令牌和授权决策不能进入 Prompt。模型只提出 Tool Call，Runtime 仍要按用户、租户、工具和资源重新做 AuthZ，高风险操作再绑定审批范围与审计记录。
进程地址空间隔离只能阻止普通进程直接读取彼此内存，不等于完整安全边界；容器仍要面对共享内核、错误授权和网络外泄等攻击面。Namespace 负责隔离“看见什么”，Cgroup 负责约束“能用多少”，两者也都不能替代系统调用和身份权限控制。
隔离单元要与信任边界对齐：高风险且不可信的代码通常按 Run 或 Task 创建一次性 Sandbox，不因为属于同一用户就复用全部环境。若为了性能按用户或租户复用预热实例，必须将工作区、进程树、网络、凭证和资源计量继续按 Task 分区，并在复用前执行可验证的清理。
差距在哪：新手只比较容器技术名称，高手从威胁模型、信任等级和清理边界选择隔离方案。
Q：Agentic RL 采用同步还是异步 Rollout，如何权衡吞吐与稳定性？
新手答：“异步能让 GPU 不空闲，所以一定比同步好。”
高手答：
同步 Rollout 接近 on-policy、批次边界清楚，但慢请求和阶段屏障容易让 Learner 或推理资源空转。异步可以重叠采样与训练，提高吞吐，却会产生 Policy Lag：轨迹来自旧策略，版本差越大，偏差和训练不稳定风险越高。
工程上要给轨迹标记 policy_version，设置最大滞后和有界队列，对过旧样本丢弃、降权或重采；是否使用重要性采样、裁剪等校正必须服从具体算法，不能套一个万能公式。监控应同时看版本滞后分布、队列等待、有效样本量、KL、吞吐和 Reward，而非只看 MFU。
差距在哪：新手只看吞吐，高手能把调度产生的数据陈旧性连接到算法偏差，并给出可观测门槛。
Q：Agent Router 应以什么运行形态存在，请求数据流如何设计？
来源：字节 AI Infra 实习一面【月之暗面（Moonshot）- Agent 应用开发岗追问：如何设计路由机制，将请求交给合适的 Agent？】
新手答：“用一个模型判断请求应该交给哪个 Agent。”
高手答：
Router 可以是进程内库、Workflow 节点或独立服务。低延迟、策略简单时进程内更省开销；多团队共享、策略频繁变化或需要独立扩容审计时，服务化更合适。典型数据流是 Gateway 完成身份和租户解析，Router 提取任务特征、召回候选 Agent/Tool，再结合能力、权限、预算、延迟和健康度打分，最后交给 Runtime 创建带版本快照的 Run。
策略要支持灰度、热更新、回滚和确定性 Fallback，并记录候选集、决策版本与结果反馈。这里讨论的是通用 Router 设计，不把某个项目中的同名组件当成行业标准。
差距在哪：新手只谈分类准确率，高手会交代部署边界、权限门禁、策略版本和端到端数据流。
Q：大量本地端 Agent 与云端 Agent 如何协同？身份、状态、离线和任务迁移边界怎么设计？
新手答：“端侧断网时先缓存，联网后同步到云端；复杂任务都放云上跑。”
高手答：
先按数据所有权拆分，不能做一个“双向同步所有状态”的大接口：
| 状态 | 权威方 | 离线策略 |
|---|---|---|
| 用户身份、授权和配额 | 云端控制面 | 端侧持有短期、限定 scope 的快照，过期后降权或停止高风险动作 |
| 设备能力、实时传感器和本地文件 | 端侧 | 本地读取，按最小必要原则上传摘要或 Artifact 引用 |
| Run 事件、Checkpoint 和副作用 | 创建该 Run 的控制面 | 用单调序号、幂等键和 lease 同步，不能靠最后写入覆盖 |
| 模型、Prompt、Tool 和策略版本 | 云端发布面 | 端侧缓存已签名版本，离线期间固定版本运行 |
断网时端侧只能执行预先授权、可撤销、风险受限的动作，并把事件写入有界本地队列。恢复连接后先做身份续期和版本协商，再按 run_id + event_seq + execution_id 上传；服务端逐条确认，重复事件幂等吸收，冲突进入显式仲裁。KubeEdge 的 EdgeHub和 Device Controller展示了端云连接、上/下行状态和 desired/reported state 分离，但 Agent 的用户授权与副作用语义仍需业务层自己实现。
任务迁移只在语义 Checkpoint 处发生：冻结旧执行者、提交工作区/Artifact 清单、释放 lease，新执行者取得 fencing token 后校验模型与工具版本，再查询未知副作用并继续。没有可迁移状态的本地进程应从可验证步骤重建，而不是复制内存快照后假定外部世界没有变化。
从本地迁到云端前先做能力与数据分类：可携带的是结构化 Run State、已授权 Artifact 和版本化执行契约；设备私钥、本地绝对路径、未授权文件与活进程不直接上传。云端先验证目标 Tool/模型版本和数据驻留约束，不兼容时应停在已验证 Checkpoint 并显式降级，而不是让云端在缺失上下文时猜测继续。
差距在哪：新手只有“缓存后同步”，高手能定义权威状态、离线权限、冲突协议和任务唯一执行权。
Q：Agent 平台或 Runtime 出现新框架时，如何评估迁移收益、兼容老旧服务并决定是否淘汰旧方案？
来源：虾皮 Agent 二面 / 电商 Agent 三面
新手答：“先做 PoC，新框架效果好就逐步迁移，出问题再回滚。”
高手答：
先盘点迁移契约，再比较框架功能：Run 状态机、Tool ABI、消息格式、Checkpoint schema、Artifact、权限、Trace、取消/超时和错误分类。只比较 Demo 成功率，会在迁移长任务和部分失败时付出代价。
我会分四步推进：
- 适配：在旧业务和新 Runtime 之间加防腐层，先统一 Tool/状态/Trace 契约；老服务通过 Adapter 暴露能力，不要求一次性重写。
- 双轨：固定模型、Prompt、数据和预算做离线回放，再用 shadow traffic 对比语义成功率、恢复率、P99、成本和可观测缺口。副作用工具只影子验证，不重复执行。
- 迁移：新 Run 按租户/任务 canary；在途 Run 默认固定旧 Runtime 到结束，只有 Checkpoint 可转换且经过校验时才迁移。
- 退出：预先定义旧平台停止条件、数据导出、回滚窗口和 owner；新框架达不到门槛就终止迁移，而不是形成永久双栈。
框架 API 会演进，版本兼容必须成为发布门禁。Kubernetes 的 API Deprecation Policy说明了稳定 API 不能在同一版本中随意移除；Agent 平台虽不必复制其时间规则，但应采用相同思路：版本化 schema、明确弃用窗口和转换器。Trace 字段也应基于版本化的 OpenTelemetry Semantic Conventions，不要让迁移前后同名指标含义改变。
差距在哪：新手把迁移当换 SDK，高手会治理协议、在途状态、双轨证据、旧服务适配和退出成本。
Q：Kubernetes 在 Agent Infra 中负责什么？
来源：Kubernetes 调度与 Controller 高频题【阿里 Agent Infra 一面题库同题：单 Agent 单 Pod、冷启动与 Reconcile 幂等】
新手答：“负责创建 Pod、自动扩容和故障迁移。”
高手答：
Kubernetes 管的是计算实例和资源期望状态，不负责恢复 Agent 的业务状态。Pod 被重建以后，Run 能否继续取决于外部状态、lease、Checkpoint 和工具幂等。
它适合承担 Worker/Sandbox 生命周期、资源请求与限制、节点选择、弹性伸缩、ServiceAccount 和 NetworkPolicy。Controller 的 Reconcile 是 level-triggered：每次都根据 Desired State 和 Actual State 收敛，必须能处理重复事件、缓存陈旧和部分成功。
“一个 Agent 一个 Pod”还会带来 API Server/etcd 对象规模、Scheduler 吞吐、镜像拉取、IP 消耗、资源碎片和回收压力。短任务可以使用 Worker Pool 或预热 Sandbox；强隔离任务可以保留一任务一环境，但要通过池化和容量规划控制冷启动。
差距在哪：新手把 Kubernetes 当业务恢复系统，高手明确基础设施重调度与 Agent 状态恢复的责任边界。
Q：Kubernetes 的 Request 与 Limit 分别怎样影响调度和资源隔离？
新手答：“Request 是申请资源，Limit 是最多能用的资源。”
高手答：
Request 主要参与调度容量判断，Scheduler 看节点可分配资源与已承诺 Request，而不是瞬时利用率；它也参与 Pod QoS 分类。Limit 由 Kubelet、容器运行时和内核 Cgroup 落实：CPU 超过 Limit 通常被节流，进程不会因此直接退出；内存限制是反应式的，压力下可能触发 OOM Kill。未配置项、默认值以及 Pod 级资源能力会随集群策略和版本变化，不能假设所有集群行为一致。
Agent 平台还要在 Kubernetes 之外做租户并发和任务预算控制，因为“Pod 能调度”不代表 LLM、GPU 或外部 Tool 有容量。
差距在哪：新手只会写 YAML，高手能区分调度承诺、内核执行和业务侧 Admission Control。
Q：Kubernetes Scheduler 的三个队列如何流转？
新手答：“Pod 排队，调度失败就过一会儿重试。”
高手答：
典型实现中，ActiveQ 保存当前可尝试调度的对象；调度失败且暂时没有合适节点时进入 Unschedulable 集合；需要退避的对象进入 BackoffQ，退避到期后再回 ActiveQ。节点容量、标签等相关集群事件发生时，Queueing Hint 或等价机制可以只激活可能受益的对象，避免无差别重试；对象停留过久也要获得再次尝试的机会。
这些是 kube-scheduler 的内部队列，不是 Agent Runtime 的 MQ。具体类型名和 PodGroup 等能力会随版本、特性门控变化，面试应先讲状态转换和触发条件，再补当前版本实现。
差距在哪：新手只说重试，高手能解释失败对象为何沉淀、何时被事件唤醒，以及如何避免热循环。
Q：Agent Worker 或 Sandbox 滚动发布时，如何逐步切流并保护长任务？
新手答：“用 Deployment 滚动更新和 Readiness Probe，新 Pod 好了就切流。”
高手答：
Deployment 通过新旧 ReplicaSet 和 maxSurge、maxUnavailable 控制替换速度；新 Pod 通过 Startup/Readiness Probe 后才应进入 Service Endpoint。旧 Pod 终止前先摘流，执行 preStop 和优雅终止。对长生命周期 Agent，仅靠 HTTP 摘流不够：Worker 要停止领取新 lease，等待可完成步骤 drain；超时任务持久化 Checkpoint、释放租约，由新 Worker 幂等恢复。
还要验证客户端重连、重复请求和版本兼容。PDB 主要约束自愿驱逐，并不保存 Agent 业务状态；不同入口控制器和服务网格的切流细节也不能一概而论。
差距在哪：新手只讲 Pod 数量，高手同时处理 Kubernetes 发布、任务租约、状态恢复和协议兼容。
Q：Ray 的核心调度链路是什么，节点 OOM 或上游故障后如何恢复？
新手答：“Ray 会把任务调度到其他节点，失败后自动重试。”
高手答：
Driver 提交 Task/Actor，Raylet 按资源和放置约束调度 Worker，GCS 保存集群控制元数据，对象通过分布式 Object Store 传递。节点故障后，普通 Task 是否重试取决于 max_retries 等配置；丢失对象只有在 lineage 仍可用、生产任务可重放等条件满足时才能重建。Actor、应用状态和外部副作用另有生命周期，不能承诺透明恢复。
节点内存紧张时，Ray 的 Memory Monitor 可能终止 Worker，但选择和重试策略具有版本边界。Agent Tool 写库、发消息等副作用仍需业务幂等，不能把 Ray 重试当成 exactly-once。
差距在哪：新手把框架重试等同于恢复，高手会逐一检查任务、对象、Actor 和外部副作用的可重建条件。
Q：Agentic RL 的 Rollout、Training 与推理引擎如何编排？
新手答：“推理引擎生成轨迹，训练器算奖励并更新模型，然后同步权重。”
高手答：
系统通常包含 Actor/Learner、Rollout Engine、Reference Policy、Reward，以及算法需要时的 Critic。调度器把 Prompt 分发给 Rollout，轨迹连同模型版本进入奖励与训练阶段；Learner 产出新权重后，通过全量、分片或增量传输到推理侧。切换必须有 policy_version、完整性校验和原子激活，避免某条轨迹混用两版参数。
Actor 与 Rollout 共置可降低权重传输成本，却会产生显存和计算争用；分离部署隔离更好，但增加网络和同步开销。具体角色、同步协议和一致性强度取决于框架，回答应先给不变量，再谈实现。
差距在哪：新手只会画训练循环，高手能说明资源编排、权重版本、轨迹可追溯性和共置取舍。
Q：Agent Infra 为什么能提升 Agent 的能力上限和任务成功率？
新手答：“Infra 更稳定、并发更高，所以 Agent 效果会更好。”
高手答：
Infra 不会直接提高基础模型智力，但会扩大模型可可靠利用的能力：Context 组装提高有效信息密度，Tool/Router 把决策连接到可执行动作，Memory 支撑跨步骤延续，Checkpoint 和幂等让长任务能够恢复，Sandbox 与权限门禁允许系统安全放权，Trace/Eval 则把 Badcase 变成可迭代数据。
最难的是模型语义不确定性与分布式部分失败叠加：一次“成功”既要判断基础设施完成，也要判断任务语义正确。证明收益应在同模型、同任务集下做消融，对比任务成功率、步骤数、工具失败率、恢复率、延迟和成本，避免把流量变化误认为能力提升。
差距在哪：新手把能力等同于可用性，高手能建立基础设施机制、效果指标与反馈闭环之间的因果关系。
Q：Agent 调用 Sandbox 的链路如何容错？Sandbox 运行中崩溃后怎么恢复？
来源：字节 AML / 火山方舟 AI Infra 一面（2026-08-26）
新手答：“让 Kubernetes 重启 Pod，再从 Checkpoint 继续执行。”
高手答：
先把 Sandbox 执行建模成带 execution_id、attempt 和 lease 的状态机：PENDING → DISPATCHED → RUNNING → SUCCEEDED/FAILED/UNKNOWN。调度前持久化执行意图，Sandbox 启动后上报心跳，并持续外传 stdout、错误、资源指标和 Artifact；Runtime 设置启动、空闲、单工具和全局 Deadline，不能等 HTTP 连接自然超时才发现崩溃。
Sandbox 退出时区分正常非零码、OOM、硬超时、节点丢失和控制面失联。只读或幂等动作可在新的一次性环境中重试；可能已产生外部副作用但结果未提交时标记 UNKNOWN，先按幂等键查询或对账，不能盲目重放。恢复使用不可变镜像、输入 Artifact 和最近 Checkpoint，不复用可能残留进程、文件或凭据的脏环境。
Kubernetes 只负责重建计算实例，Agent Runtime 才负责业务状态恢复。控制面还要回收孤儿 Pod、过期 lease、临时卷和短期凭据；在途取消必须传播到 Sandbox，终止后拒绝过期 Worker 提交结果。观测上分别统计启动失败、OOM、超时、节点故障、UNKNOWN 副作用和恢复成功率。
差距在哪：新手把 Pod 重启等同于任务恢复，高手能处理状态提交、未知副作用、环境重建和孤儿资源回收四个故障边界。
Q：Agent Task 适合建模为 Kubernetes CRD 吗？如何权衡声明式管理与高频任务吞吐？
来源：阿里 Agent Infra 一面题库
新手答：“适合。定义一个 AgentTask CRD，再写 Controller 创建 Pod，Kubernetes 会负责状态管理和失败恢复。”
高手答：
先判断对象是否符合 Kubernetes 的资源语义，而不是因为任务跑在集群里就做 CRD。Kubernetes Custom Resources 官方文档建议在对象适合声明式 API、天然属于集群或 Namespace、需要 kubectl/RBAC/审计及 Controller 持续 Reconcile 时使用自定义资源。
因此，长生命周期、数量受控的 AgentPool、SandboxClass、租户执行环境或需要运维人员声明目标状态的 Agent Run 可以建模为 CRD。spec 保存期望状态和不可变版本引用，status 保存 Controller 观察到的阶段、Condition 与关联资源；Reconcile 必须幂等，并处理 Finalizer、取消、过期 Worker 回写和孤儿资源回收。
但每个 LLM Step、Tool Call 或几秒钟完成的高频 Task 不适合直接写成 CR。它们会产生大量创建、状态更新、List/Watch 和删除流量，把业务任务吞吐耦合到 API Server、etcd 和 Controller 队列；Prompt、消息、Trace 和 Artifact 也不适合塞进 Kubernetes 对象。此时应把任务事实放进专用数据库、事件日志和 Queue，只让 CRD 管理较粗粒度的执行环境，并在两侧保存稳定引用。
最终要用对象基数、创建峰值、状态更新频率、保留周期、单对象大小和控制面 SLO 压测决定。需要 Watch 时还要正确处理 resourceVersion、断线重连和 410 Gone，不能把 Watch 当作永久可靠的消息队列。
差距在哪：新手把 CRD 当免费数据库，高手会先判断资源语义，再隔离 Kubernetes 控制面与 Agent 高频执行面的容量和一致性边界。
Q：verl AgentLoop 的运行模型、状态与扩展点是什么？
新手答：“它就是在训练时循环调用模型和工具，生成多轮轨迹给 RL。”
高手答：
先固定版本。以下基于 verl 官方 main 的 commit 8df88be746801b6d87c42e15f9a5a0ec1d5eeeae（核对日期：2026-08-28）。官方 Agent Loop 文档标明该能力从 v0.4.2 加入、状态为 alpha，API 仍可能变化，因此面试回答必须带版本。
它的定位是多轮 Rollout 与 Agentic RL 训练之间的接口：
Trainer 取一个 Prompt Batch
→ AgentLoopManager 分发到 AgentLoopWorker
→ Worker 为每个样本实例化 AgentLoopBase
→ run coroutine 多次请求异步 LLM Server、调用 Tool/环境
→ AgentLoopOutput 返回 token、mask、logprob、turn、reward/metrics
→ Reward 与训练阶段消费轨迹并更新策略这里有三类状态：
- 训练/样本状态：样本索引、
agent_name、policy/step 等轨迹元数据； - 循环内状态：消息、Tool 上下文、环境对象和终止条件，由具体
AgentLoopBase.run实现管理； - 训练输出状态：
prompt_ids、response_ids、response_mask、可选 logprobs/reward、多模态数据和指标。
Observation/Tool Result 会进入模型后续上下文，但不应被误当成策略生成 token；token mask 和 chat template 一致性直接影响训练正确性。AgentLoop 也不自动提供生产 Agent Runtime 的持久 Checkpoint、业务幂等或外部副作用恢复，这些是另一层责任。
扩展自定义 Loop 时，按官方 How to Extend verl继承 AgentLoopBase 并实现异步 run，通过配置注册；Tool 配置和生命周期是独立扩展面。实现必须保持 token-in/token-out，不能把 token decode 成文本、修改后再 encode，否则 Rollout token 与训练 logprob 对不上。异步 Worker 和多推理 Server 用于隐藏 Tool 等待并做请求级负载均衡，但并发数、最大轮数和 Tool 响应长度仍要设上限。
差距在哪：新手只看到 ReAct 循环，高手能说明 Manager/Worker/Base/Output 的责任、训练状态边界、扩展方法和 alpha API 风险。
Q：Agent 状态放在 Sandbox 内、用户状态放在 Sandbox 外时，边界如何设计？
新手答：“临时状态放沙箱，长期用户信息放数据库，任务结束后销毁沙箱。”
高手答：
边界判断不是“临时/长期”两个词，而是谁是事实源、Sandbox 丢失后能否恢复、数据是否允许进入不可信执行域。
Sandbox 内：工作区副本、临时文件、进程、编译缓存、本次 Tool 输入、短期日志
Sandbox 外：Run 事件、Checkpoint、用户画像、授权策略、Secret 引用、Artifact 索引、审计与租约Kubernetes Local Ephemeral Storage明确提醒节点失败时本地临时数据可能丢失，所以 Sandbox 不是业务状态源。需要跨重启保留的文件先生成 manifest、hash 和 Artifact，再由控制面原子确认；只有确认后的引用才能进入 Checkpoint。
用户状态不能全量复制进 Sandbox。Context Builder 按当前任务和权限生成最小只读视图；敏感值尽量只给 opaque reference，需要调用外部系统时由凭证代理注入短期 token。Kubernetes ServiceAccount 文档同样推荐 TokenRequest/投射卷等短期、可轮换凭证，而不是长期静态 token。模型和沙箱内代码都不能决定最终 AuthZ。
状态提交采用 run_id + state_version + execution_id，Sandbox 只提出增量；控制面校验 lease、schema、权限和副作用后再提交。Sandbox 销毁时清理工作区、进程、挂载和凭据；复用池必须验证租户隔离，否则省下的冷启动会换来数据串扰。
差距在哪：新手按保存时长分层，高手按事实所有权、恢复语义和信任边界决定状态位置。
Q：周期性 Agent 任务如何把 Schedule 与每次 Run 分离，并处理时区、漏跑、并发、幂等和失败通知？
新手答：“用定时器每隔一段时间触发 Agent，失败就重试和发告警。”
高手答：
Schedule 是可变更的触发契约，保存调度表达式、时区、有效期、漏跑策略、并发策略、任务模板和通知规则；每个 Run 是某个逻辑触发时刻生成的不可变执行实例，固定 schedule_id + logical_fire_time、输入、配置版本和执行状态。这样修改 Schedule 不会偷偷改写已经创建的 Run，历史也可以按逻辑触发时刻对账。
时区必须显式存 IANA 标识并定义 DST 重复或跳过时的行为，不依赖服务器本地时区。Scheduler 扫描逻辑时间窗口：对短时漏跑可限定 catch-up 窗口补跑，超窗口则记录 MISSED 并通知，避免恢复后瞬间补齐大量过期任务。并发策略至少区分 ALLOW、FORBID 和 REPLACE；REPLACE 仍要遵守取消语义，不能假定旧 Run 的外部副作用已撤销。
创建 Run 时以 schedule_id + logical_fire_time 建唯一约束，调度器用 lease/fencing 避免多实例重复创建；工具副作用再使用稳定 execution_id 做下游幂等。不宣称 exactly-once：失败按错误类型做有界重试，最终进入失败终态或人工队列。通知事件本身也带幂等键，包含最后成功时间、本次失败阶段、重试次数和下次触发时间。
这套语义可参考 Kubernetes CronJob 对时区、错过调度和并发策略的处理，但 Agent Runtime 仍需自己定义 Run 状态、Tool 幂等和通知收敛，不把设计绑定到某个调度框架。
差距在哪：新手只有“定时器 + 重试”，高手把配置和执行实例分开，并为时间语义、重复触发、重叠执行、副作用幂等和可操作告警定义了可恢复契约。
Agent Infra 系统设计答题主线
先定义：负载、SLO、信任边界、任务是否可暂停
再建模：状态机、事件、Checkpoint、lease、执行语义
再执行：Queue、Scheduler、Worker、Sandbox、Kubernetes
再兜底：幂等、UNKNOWN、对账、补偿、审批、恢复
最后治理：多租户、配额、Trace、Eval、Cost、Audit记住一个结论：Agent 带来了动态执行路径，但没有消灭分布式系统的部分失败；Runtime 必须把不确定性收敛成显式状态。
下一篇建议继续看：