主题
运行保障与可观测性
本文讨论 AaaS 平台的运行保障与可观测性，重点覆盖 Sandbox 场景下的 CI/CD、环境准备、Agent 安装、进程监控，以及 FaaS、Worker、Wasm 的等价监控模型。规范中的运行事实与 Trace 模型见 Run、Runtime Connection 和 Tracing。
为什么这一章重要
Agent 平台上线后，真正决定可用性的往往不是 prompt 质量，而是运行保障能力：
- 环境是否一致
- 依赖是否可重复安装
- Agent 进程是否可健康运行
- 故障是否可发现、可重试、可恢复
- 会话、工件和 Trace 是否能在事故后完整留痕
在这方面，Sandbox、FaaS、Worker、Wasm 的监控方式并不相同，但平台必须给出统一的运营视图。
Sandbox 场景的 CI/CD 流
Sandbox 最接近“完整机器环境”，因此也最需要接近传统软件交付的 CI/CD 流。
1. Build 阶段
- 构建基础镜像或运行模板
- 固定系统依赖、语言运行时、包管理器和常用工具版本
- 预热大体积依赖和缓存目录
- 输出镜像版本、依赖清单和安全扫描结果
2. Prepare 阶段
- 根据 execution profile 拉起 Sandbox
- 挂载工作目录、缓存、对象存储凭证和策略配置
- 执行环境准备动作，例如
actions中定义的预处理步骤 - 注入受控 Secret、Config 和网络策略
3. Agent 安装阶段
- 安装 Agent runtime 或具体工具，例如 coding agent CLI、MCP client、浏览器驱动
- 校验版本、可执行文件、模型配置和关键依赖
- 执行 smoke test，确认 runtime attach、输出事件和 Trace 导出链路正常
4. 启动与运行阶段
- 启动 Agent 主进程，并由 supervisor 管理退出码和重启策略
- 与 Runtime Session Gateway 建立 attach 和 heartbeat
- 接收任务输入并持续输出消息、Artifact、Checkpoint 和 Trace
- 对关键子进程、浏览器、PTY、磁盘占用和网络出口做持续监控
5. 收尾与回收阶段
- 在成功、失败、取消时统一上传日志、Trace、工件和检查点
- 按策略保留或销毁工作区
- 释放 Secret、短期租约和临时网络权限
FaaS、Worker、Wasm 的等价 CI/CD 流
Sandbox 的重点是“准备一台可工作的机器环境”；其他执行环境的重点通常不是安装一个长期驻留的 Agent 进程，而是发布正确版本、验证执行链路并持续确认运行健康。
FaaS
- Build 阶段固定函数 bundle、layer、运行时版本和配置模板
- Release 阶段发布版本、别名、灰度比例和回滚策略
- Readiness 阶段执行预热调用，验证下游依赖、Secret 注入和 Trace 导出链路
- Runtime 阶段监控调用时延、超时、冷启动、并发和错误分类
Worker
- Build 阶段固定 consumer 镜像或二进制、依赖锁定和队列协议版本
- Release 阶段配置队列绑定、并发度、lease 参数和滚动发布策略
- Readiness 阶段执行 polling smoke test，验证消息解码、Run 映射和补偿逻辑
- Runtime 阶段监控队列积压、消费速率、lease 续约、重试和死信转移
Wasm
- Build 阶段编译模块、固定 capability manifest、完成签名和策略校验
- Release 阶段按区域、租户或流量比例做 staged rollout
- Readiness 阶段验证实例化、宿主 API 权限和 Trace 导出链路
- Runtime 阶段监控模块加载、实例启动、quota reject、trap 和执行时延
Sandbox 需要重点监控什么
环境准备信号
- Sandbox 准备耗时
- 镜像拉取和依赖安装耗时
- 预处理步骤成功率
- attach 成功率
进程健康信号
- Agent 主进程存活状态
- 子进程树数量与异常退出
- PTY 是否阻塞
- 浏览器或辅助服务是否僵死
资源与会话信号
- CPU、内存、磁盘和网络占用
- 会话 TTL 与 heartbeat 间隔
- 工作区大小和缓存命中率
- Checkpoint 创建耗时与恢复成功率
业务结果信号
- Run 成功率、重试率、取消率
- 输出事件延迟
- Tool 调用成功率
- Artifact 产出率和 Trace 完整度
Sandbox 的运行时监控建议
推荐引入三层监控：
进程层- 监控主进程、子进程、退出码、fd、内存和线程数
会话层- 监控 attach、heartbeat、recover、lease、TTL 和 output lag
任务层- 监控 Run 状态、Attempt 切换、工具调用、Artifact、Checkpoint 和 Span
这三层必须能通过 runId、sessionId、runSpaceId、traceId 关联起来，否则排障成本会很高。
FaaS 如何提供类似的监控能力
FaaS 通常没有长期驻留进程，因此“进程监控”要转化为“调用级和实例级健康信号”：
- 发布阶段监控函数版本、别名、灰度比例和回滚状态
- 运行阶段监控调用成功率、时延、超时、并发、冷启动和错误分类
- 平台侧通过 Run / Attempt 记录某次调用映射到哪个函数版本
- 通过 Trace 把一次 FaaS 调用与上游 Agent Run 关联起来
在 FaaS 中，不需要心跳监控单个长期进程，但需要重点监控：
- 调用是否按预期开始
- 调用是否在超时窗口内结束
- 失败是否可以安全重试
- 输出事件和 Trace 是否完整落到平台
Worker 如何提供类似的监控能力
Worker 通常以消费者形式运行，监控重点是“队列推进能力”和“租约健康”：
- 队列长度、积压时长、消费速率
- lease 或 visibility timeout 是否被及时续约
- 单任务执行时长、重试次数和死信转移
- worker 进程存活、polling 失败率和批次大小
- Run 与队列消息的映射关系是否稳定
如果 Worker 承担编排器或后台推进职责，还要监控：
- 状态推进延迟
- 补偿执行成功率
- 终态投影延迟
Wasm 如何提供类似的监控能力
Wasm 运行环境的重点不在“进程树”，而在“实例生命周期与资源配额”：
- 模块加载成功率和实例化耗时
- CPU 配额、内存上限、系统调用或宿主 API 拒绝率
- 输入输出大小和执行时延
- 模块版本、签名和策略检查结果
- Trace 导出和错误归一化情况
如果 Wasm 用在边缘场景，还要监控：
- 区域分布
- 边缘回源比例
- 策略缓存命中率
把 Sandbox 的监控能力翻译到其他环境
关键不是要求 FaaS、Worker、Wasm 复制 Sandbox 的进程树视角，而是把相同的运营目标投影成各自可观测的健康信号。
| 运营目标 | Sandbox | FaaS | Worker | Wasm |
|---|---|---|---|---|
| 环境准备 | prepare、attach、工作区挂载 | deploy、warmup、env inject、预热调用 | consumer bootstrap、queue bind、config fetch | module load、capability check、instance warmup |
| Agent 安装或版本就绪 | runtime install、依赖校验、smoke test | bundle / layer 固定、函数版本校验 | 镜像 bake、init hook、协议版本校验 | module build、签名校验、host shim 检查 |
| 运行健康 | supervisor、process tree、heartbeat | invoke success、timeout、并发、cold start | lease renew、poll loop、consumer heartbeat | trap、quota reject、exec latency |
| 故障恢复 | checkpoint、session recover、workspace 保留 | 幂等重试、事件重放、安全回滚 | requeue、compensation、dead letter | stateless replay 或轻量快照 |
| 观测完整性 | logs、spans、artifact completeness | invocation trace completeness | queue-to-run trace continuity | edge trace completeness |
统一运营视图应该长什么样
尽管不同执行环境监控重点不同，平台层仍然应该把它们投影到同一组运营对象：
Run- 用户能否感知成功、失败、取消、超时和继续执行
Attempt- 某次执行落在哪个 provider、环境、版本和空间
Session- 是否成功 attach、heartbeat、recover 和释放
Artifact / Checkpoint- 是否产出、能否恢复、是否需要保留
Trace- 是否完整覆盖模型调用、工具调用、内部步骤和错误链路
推荐的统一监控指标
| 指标类别 | Sandbox | FaaS | Worker | Wasm |
|---|---|---|---|---|
| 启动健康 | prepare、attach、进程启动 | deploy、cold start、invoke start | poll、lease、consumer start | module load、instance start |
| 执行健康 | heartbeat、process exit、tool latency | duration、timeout、error code | lag、retry、dead letter | quota reject、trap、latency |
| 状态恢复 | checkpoint、session recover | retry safety、idempotency | requeue、compensation | stateless replay 或轻量快照 |
| 观测质量 | logs、spans、artifact completeness | invocation trace completeness | queue to run trace continuity | edge trace completeness |
运营建议
对 Sandbox
- 把环境准备、依赖安装和 Agent 安装纳入正式 CI/CD，而不是只靠运行时脚本
- 用 supervisor 管理 Agent 进程，不要把单个 CLI 进程直接当作生产守护进程
- 为每个执行画像定义最小健康检查和最大启动时间
对 FaaS
- 关注版本发布、冷启动和幂等安全，而不是试图模拟长期心跳
- 让平台保存函数版本到 Attempt 快照中，便于问题追溯
对 Worker
- 把队列积压和死信率当作一等生产信号
- 明确后台推进失败时谁来补偿和谁来告警
对 Wasm
- 优先把它用于轻量、可限制、易审计的步骤
- 不要强行让 Wasm 承担复杂依赖和长期会话主任务