2026 年，AI Agent 正在完成从「会聊天」到「会干活」的关键一跃：自己写代码并运行、操作浏览器查资料、调用一连串工具完成复杂任务。而让 Agent 放心「动手」的前提，是给它一个既安全又高效的执行环境——沙箱（Sandbox）因此成为 Agent 基础设施的事实标配。
阿里云容器计算服务 ACS 推出的 Agent Sandbox，以 MicroVM 级隔离、每分钟 15000 实例的弹性和内存级休眠唤醒，成为生产级 AI 智能体的沙箱算力底座。但一个新问题随之而来：隔离做得越好，沙箱内部就越像黑盒——Agent 在里面调了哪个模型、跑了什么代码、访问了哪些外部服务，运维和安全团队很难看清。
现在，这块拼图补齐了：云监控 2.0 的 OpenTelemetry 无侵入监控（OBI）正式支持 ACS Sandbox 场景。不改一行代码、不重新构建镜像，沙箱内 AI Agent 的每一次模型调用、工具执行和外部访问，都会自动生成标准的调用链与指标。
沙箱底座：隔离、弹性与状态
AI Agent 执行的代码有一个显著特点：很多是大模型现场生成的。这些代码不可信、不可预测，绝不能与生产业务跑在同一个容器里。Agent Sandbox 给出的答案是 MicroVM 级别的隔离运行环境：每个沙箱独享内核，计算、网络、存储端到端隔离，即使沙箱内代码出现任何异常行为，也被牢牢锁在「箱子」里。
安全之外，是为 Agent 场景量身定制的三组能力。
大规模低延迟弹性。 Agent 任务往往是突发的：一次强化学习训练（AgentRL）可能瞬间需要数千个环境，一个在线服务（Agent Serving）的高峰期请求汹涌而至。Agent Sandbox 支持最高每分钟 15000 个沙箱的创建规模，配合 Warm Pool 预热池可实现百毫秒级拉起，镜像缓存加速让拉取耗时缩短 90% 以上。公开案例中，MiniMax 曾在 10 秒内拉起 5000 个沙箱。
状态保持。 运行中的沙箱支持按需休眠，内存状态完整保留，1~10 秒内快速唤醒；配合 Checkpoint/Restore，Agent 的执行状态可存、可迁移、可克隆。多轮会话中断时不必销毁重建，休眠期间不收取 CPU 与内存费用，按秒计费的模式让「随用随停」真正省钱。
开放生态。 提供 E2B 兼容 SDK 与 Kubernetes 原生的 Sandbox CR 两种接入方式，兼容 AgentScope、LangGraph 等主流 Agent 框架，覆盖 Code Interpreter（代码执行）、Browser Use（浏览器操作）等典型沙箱场景。
监控盲区：越安全越像黑盒
沙箱解决了「敢不敢跑」的问题，但「跑得怎么样」依然是一团迷雾。把传统 APM 方案逐一搬过来，会发现三条路都走不通。
SDK 埋点埋不进去。 传统应用监控靠在代码里集成 SDK 或挂载语言探针。可沙箱里跑的代码是大模型即时生成的，五花八门、不可预置；Agent 框架本身也横跨 Python、Node.js 等多种语言。你不可能要求模型「生成代码时顺便埋好监控点」。
主机级采集无处安放。 ACS 是 Serverless 形态的容器计算服务，没有用户可见的节点，传统 DaemonSet 方式的主机级监控组件没有立足之地；MicroVM 的强隔离更是把「从宿主机看进去」这条路彻底堵死。
沙箱生命周期太短。 百毫秒创建、用完即毁、随时休眠——等你登录上去排查问题，现场早已销毁。以主机为中心的监控模型，根本跟不上这种「朝生暮死」的节奏。
结果就是：Agent 任务失败了，不知道是模型响应慢、工具超时还是代码报错；token 成本涨了，不知道消耗在哪个环节；安全团队想审计沙箱内代码到底访问了什么外部地址，只能翻网络日志人肉比对。
OBI 方案：零改造实现AI Agent可观测
OBI（OpenTelemetry eBPF Instrumentation，OpenTelemetry 无侵入监控）换了一个思路：不进入应用，而是站在应用与内核之间。
OBI 在内核和库函数层面拦截应用通信，解析协议语义，直接输出标准 OpenTelemetry 遥测数据。这意味着无论沙箱里跑的是 Go、Java、Python、Node.js 还是 .NET，无论用什么 HTTP 框架、连什么数据库、调哪家大模型，都无需修改任何代码即可自动采集监控数据——对「代码由模型现场生成」的沙箱场景，这几乎是唯一可行的解法。
在 ACS Sandbox 环境中，OBI 以 Sidecar 形式与沙箱工作负载相伴运行：安装 ARMS 探针接入助手 ack-onepilot（5.2.2 及以上版本）后，只需给工作负载 YAML 增加几行标签，OBI Sidecar 便会自动注入，采集的数据统一汇聚到云监控 2.0 控制台。（沙箱内运行 eBPF 需要特定的 Linux 内核权限，通过工单为账号开通即可。）
能力清单：链路、指标与 GenAI 语义
接入之后，能看到什么？
第一层是经典应用监控的全家桶：应用拓扑、调用链路、异常事务、慢事务、SQL 分析。沙箱内 Agent 的每一次对外调用都会生成 Trace——慢在模型推理还是工具执行，一条调用链看穿。
第二层，才是这次升级真正的亮点：AI Agent 可观测。OBI 内置了对 OpenAI、Anthropic、Google Gemini、通义千问（Qwen）四大 GenAI Provider 的协议级追踪，自动识别 LLM 调用并按 GenAI 语义规范生成遥测数据：
- LLM 调用：模型名、token 消耗、耗时、错误状态自动提取；
- Tool Call：从模型响应中自动解析工具调用信息，Agent「决定用什么工具」一目了然；
- MCP、Embedding、Rerank、向量检索：RAG 管线的核心环节全部覆盖。
如果你的模型流量走的是 vLLM、LiteLLM 等自建推理服务或 LLM 网关，只需在配置中声明对应 Host，OBI 同样会按 OpenAI 兼容协议解析，纳入 AI Agent 可观测视图。
对沙箱场景，这些数据同时回答了三个问题：性能——任务慢在哪个环节；成本——token 到底消耗在哪类调用上；安全——沙箱内不可信代码访问了哪些外部地址，全部旁路记录，天然就是一份审计底账。
三步接入：安装、打标签、看数据
整个接入过程不需要动应用代码。
第一步，在容器服务控制台为 ACS 集群安装 ack-onepilot 组件（5.2.2 及以上版本）。
第二步，为目标工作负载的 YAML 增加 OBI 标签：
labels:
apsara.apm/application-type: obi # 标明此应用通过 OBI 接入
armsPilotAutoEnable: 'on'
armsPilotCreateAppName: "你的应用名"
armsPilotAppWorkspace: "工作空间名"第三步，等待约 2 分钟，打开云监控 2.0 控制台：在「应用监控」查看拓扑与调用链，在「AI Agent 可观测」查看模型与工具调用明细。
第四步，到云监控2.0 AI Agent应用查看监控数据：
写在最后
Agent 基础设施的竞争，正在从「跑得起来」进入「跑得明白」的阶段。ACS Agent Sandbox 负责让 AI Agent 安全、弹性地执行，OBI 负责让每一次执行透明可见——两者合在一起，生产级 Agent 的「安全」与「可观测」第一次可以同时成立，而代价是 0 行代码改造。
如果你正在构建 Agent 应用，欢迎从官方文档《通过 OBI 接入 ACS 应用》开始体验：https://help.aliyun.com/zh/cms/cloudmonitor-2-0/access-acs-applications-through-opentelemetry-non-intrusive-monitoring-obi
