企业官网建设流程全解析

你有没有想过一个问题：现在的 AI Agent 能聊天、能写方案、能生成代码，可一旦让它去完成“真实世界里的活儿”——把一堆 CSV 合并、跑一段脚本、修一张图、拉一份网页数据——它立刻变成了只会开口指路的“嘴强王者”。不是 Agent 不够聪明，而是它缺了“手”。这半年我一直在折腾 AI Agent 的落地，踩了一圈坑之后，得到的结论很简单：让 Agent 真正干活，关键不在于给它更强的模型，而在于给它一个云沙箱，让它拥有一个临时 Runtime。

云沙箱解决了什么？一句话：Agent 不再只是“输出文本”，而是真的能在隔离环境里执行代码、操作文件、安装依赖、观察结果，然后根据结果继续调整。这个过程就像你给 Agent 配了一间可以反复使用的临时工坊——用完即毁，安全可控，成本极低。这篇文章我围绕“云沙箱 + Agent + 临时 Runtime”这条主线，把方案选型、架构设计、从零实现和排查经验一次讲透，适合正在做 Agent 开发、工具调用、AI 自动化以及 AI 应用安全测试的朋友。无论你是刚入门还是已经做过几个 Demo，应该都能拿到可以直接抄作业的东西。

1. 为什么 Agent 不能没有 Runtime

1.1 没有执行闭环的 Agent，本质上是“纸上谈兵”

我把 Agent 的发展分成几个阶段。第一阶段是“会聊天”，也就是传统对话机器人，只能根据上下文生成回复。第二阶段是“会调用工具”，模型能通过函数调用去触达外部 API，比如查天气、查订单。第三阶段才是真正有意思的——“会使用环境”，Agent 可以在隔离环境中跑代码、改文件、启动服务、观察输出，并且根据输出自己做下一轮决策。

前两个阶段有一个共同痛点：模型只负责“说话”，不负责“验证”。它给你一段代码，语法对不对、能不能跑、跑出来的结果是否符合预期，模型自己不知道，全靠人肉复制粘贴去验证。一旦任务复杂起来，比如要求“你把这份数据清洗一遍并画几张图”，纯对话式 Agent 根本无力完成，因为它没有一个可执行、可反馈的运行环境。

这就是 Runtime 的价值。Runtime 是程序运行的载体，包括解释器、依赖库、环境变量、文件系统、网络接口等等。有了 Runtime，Agent 生成的代码才能被真实执行，执行结果才能作为反馈进入模型的下一次推理。没有 Runtime 的 Agent 是“建议者”，有了 Runtime 的 Agent 才是“执行者”。

1.2 云沙箱、临时 Runtime 和隔离边界到底是什么关系

很多人把云沙箱和 Runtime 搞混，我拆开说。

Runtime 解决的是“能不能跑”的问题。比如 Python 脚本没有 Python 解释器就运行不了，WebView2 程序没有对应的 Runtime 就起不来。Agent 需要一个完整的 Runtime 来承载它的执行需求。

云沙箱解决的是“在哪跑、怎么跑才安全”的问题。它是一个隔离边界，可以是容器、虚拟机，也可以是进程级的安全机制。Agent 生成的代码不一定可信，尤其当模型被提示词注入攻击或者产生了激烈输出时，直接在你本机执行，轻则弄乱环境，重则泄漏敏感数据。云沙箱就像一个防爆实验室，让 Agent 在可控范围内折腾。

“临时”则是云沙箱的灵魂。沙箱不是一台你长期维护的服务器，而是按需创建、用完即可销毁的临时环境。会话结束就回收，下次任务再重新拉一个干净环境。这样既省成本，又天然避免环境越用越脏。

把三者串起来就是：Agent 的每轮任务都会在云端拉起一个带完整 Runtime 的隔离沙箱，Agent 在里面执行代码、操作文件、调用工具，拿到结果后继续决策，任务结束沙箱销毁。这就是标题里说的“从执行代码升级到拥有一个临时 Runtime”的本质。

1.3 这个能力到底适合谁

如果你属于下面任何一类，云沙箱就是你要补的那块拼图：

• 正在做 Agent 开发或 Agent 编排的人：你给 Agent 接了不少工具，但工具大多只停留在 API 调用层，一旦需要更复杂的操作，沙箱就是质变的起点。
• 做 RPA / AI 自动化的人：把“点击按钮”这类固定流程升级为“让模型自己写脚本执行”，沙箱能给你一个更普适的执行底座。
• 做 AI 应用安全测试的人：你需要安全地让模型去执行不可信代码，沙箱的隔离和审计正好是刚需。
• 独立开发者 / 小团队：如果你想给聊天机器人加“动手能力”，用云沙箱比维护一堆物理机器靠谱得多，成本也低得多。

2. 云沙箱方案的选型逻辑：容器、微虚拟机与进程隔离

2.1 为什么首选容器而不是传统虚拟机

Agent 调用沙箱有一个硬性指标：延迟要低。一次工具调用的响应时间如果超过 5 秒，模型的执行链路就会拖得很长，体验和成本都会崩掉。传统虚拟机启动要几十秒，完全不可接受。而容器技术的最大优势就是轻量：秒级拉起、毫秒级执行。

我目前的方案以 Docker 容器为主，核心原因有三个。

第一，启动速度快。本地预热好的镜像，容器创建加命令执行基本在几十到几百毫秒级别，完全能满足 Agent 交互式操作的需要。第二，镜像体积可控。一个精简的 Python 镜像不到 200MB，磁盘占用和下载时间都还能接受。第三，资源隔离能力开箱即用。cgroups 可以对 CPU、内存、PID 数量、磁盘额度进行精细限制，namespace 提供文件系统和网络隔离，对大多数 Agent 执行场景已经足够了。

容器也不是没有缺点。它和宿主机共享内核，所以理论上存在逃逸风险，更不用说“噪音邻居”问题。如果沙箱里跑的是完全不信任的第三方代码，或者你的业务对安全等级要求特别高，那就得升级到微虚拟机方案。

2.2 微虚拟机、沙箱内核和混合方案怎么选

常见的隔离技术有几种，我做了个对比表格方便你选型：

实际项目里，如果追求极致的反馈速度和开发效率，先用 Docker。当业务规模变大、开始出现多租户需求或者需要防御恶意 Agent 输出时，再考虑引入 gVisor 或 Firecracker。不建议一开始就上微虚拟机，因为它的管理成本和可观测性都会成倍增加，对早期迭代并不友好。

2.3 会话模型决定了你要不要做“临时”

在沙箱里，Agent 和环境的交互模式通常分成三种：一次性执行、长会话 Shell、快照恢复。它们各有各的用处，我分别说一下。

一次性执行适合验证代码。Agent 生成一段脚本，沙箱把脚本跑完，返回 stdout、stderr 和退出码，沙箱销毁。这种模型实现最简单，但对复杂任务不太够用。

长会话 Shell 更像一台“远程小电脑”。Agent 可以连续操作：先安装依赖，再编辑文件，然后跑测试，最后查看结果。每次操作都在同一个容器里发生，状态是连贯的。这也是我日常最常用的模式，因为 Agent 执行任务时天然带有试探性，需要一轮轮观察和调整。

快照恢复解决的是“做到一半环境没了”的问题。比如一个任务耗时很长，中间沙箱因为超时被回收了，快照机制能保存当前状态，下次继续时恢复。Docker 自带 commit 可以做到简易快照，但经常用会产生很多中间镜像，建议你有空的话用 overlayfs 或者专门的存储方案来做。

一句话总结，Agent 云沙箱的“临时”不是让你把沙箱做成消耗品，而是让你把状态管理做成可回收、可恢复的产品设计。

3. 从零搭一套最小“Agent 云沙箱 Runtime”

3.1 最小可用环境的镜像设计

搭建的第一步，是准备一个适合 Agent 工作的基础镜像。我没有用完整版的 python:latest，而是选择 python:3.12-slim，原因很简单：镜像越小，拉起越快，攻击面也越小。但 Agent 执行任务不能只靠 Python，它还需要一些常用工具。下面是我当前的 Dockerfile，你可以直接参考。

FROM python:3.12-slim # 设置非交互安装 ENV DEBIAN_FRONTEND=noninteractive \ PIP_NO_CACHE_DIR=1 \ PYTHONUNBUFFERED=1 # 安装基础工具：curl 用于请求，git 用于拉代码，jq 用于解析JSON RUN apt-get update && apt-get install -y --no-install-recommends \ curl \ git \ jq \ ca-certificates \ && rm -rf /var/lib/apt/lists/* # 创建一个非root用户，Agent 默认用它执行命令 RUN useradd -m -s /bin/bash agent # 预装一些常见 Python 库 RUN pip install --no-cache-dir \ requests \ pandas \ pytest \ pyyaml WORKDIR /workspace USER agent

这里有三个细节值得说明。一是创建非 root 用户。Agent 生成的代码可能包含危险操作，如果默认 root 运行，一旦出现恶意 Command，危害会被放大。二是把工作目录固定为 /workspace，方便后面挂载卷和回收文件。三是只预装通用依赖，其他依赖让 Agent 自己在沙箱里按需安装，这样镜像不会越来越臃肿。

3.2 核心执行接口：让 Agent 能执行命令、查看结果

镜像准备好以后，核心问题就是怎么让 Agent 跟沙箱交互。我的方案是用一个轻量的 FastAPI 服务，把它当作 Agent 和沙箱之间的“控制台”。项目里至少要有三个接口：创建会话、执行命令、销毁会话。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import docker import uuid app = FastAPI() client = docker.from_env() class CommandRequest(BaseModel): session_id: str command: str timeout: int = 60 class SessionCreate(BaseModel): image: str = "agent-runtime:latest" cpus: float = 1.0 memory_mb: int = 512 @app.post("/sessions") def create_session(req: SessionCreate): """创建一个临时沙箱容器""" container = client.containers.run( req.image, command="sleep infinity", detach=True, cpu_quota=int(req.cpus * 100000), mem_limit=f"{req.memory_mb}m", pids_limit=256, network_mode="bridge", working_dir="/workspace", user="agent", ) return {"session_id": container.id, "status": "running"} @app.post("/exec") def exec_command(req: CommandRequest): """在已有沙箱内执行一条命令""" try: container = client.containers.get(req.session_id) except docker.errors.NotFound: raise HTTPException(status_code=404, detail="session not found") res = container.exec_run( ["/bin/bash", "-lc", req.command], stdout=True, stderr=True, tty=False, demux=True, ) stdout, stderr = res.output return { "exit_code": res.exit_code, "stdout": stdout.decode() if stdout else "", "stderr": stderr.decode() if stderr else "", } @app.delete("/sessions/{session_id}") def destroy_session(session_id: str): """销毁沙箱容器""" try: container = client.containers.get(session_id) container.remove(force=True) return {"status": "destroyed"} except docker.errors.NotFound: raise HTTPException(status_code=404, detail="session not found")

这段代码是骨架，里面有三个关键点。

第一，创建容器时用 sleep infinity 保活。因为 exec_run 要求容器在运行状态，如果容器里没有长驻进程，创建之后马上就会退出。sleep infinity 就是让容器一直活着等你来执行命令。

第二，exec_run 里用 demux=True 把 stdout 和 stderr 分离。这样 Agent 能明确区分哪些是正常运行输出、哪些是错误信息，这对它后续决策非常重要。如果混在一起，模型很容易被错误日志误导。

第三，所有执行都走 /bin/bash -lc，意味着命令可以支持管道、变量、多行脚本。Agent 生成的复杂命令也能被正确解析，避免因为参数拆分导致失败。

3.3 为什么必须限制 CPU、内存和 PID 数量

Agent 自动生成的代码有个特点：它可能会写出死循环、内存爆炸的递归，甚至不小心调用 fork 产生大量子进程。如果不做资源限制，一个 session 就能把整台主机拖垮。

我常用的限制参数如下：

在 Docker 里，限制资源是通过 cgroups 实现的，不需要像虚拟机那样预先分配硬件，所以即使在容器上加了 512MB 限制，它也只是“最高限额”，平时不会白白占用内存。你要知道的是，这个限制本身比限制名目更重要，因为 Agent 的试错行为会在你意料不到的路径上产生资源消耗。

3.4 临时是设计出来的，不是口号：TTL 与回收机制

很多初版云沙箱死在哪？不是功能不够，是忘了做 TTL。Agent 会话一旦创建，如果没有人销毁它，它就会一直睡在那里占着内存。虽然 sleep infinity 只占少量资源，但架不住任务一多，几百个僵尸容器会让 Docker Daemon 越来越慢。

我加了一个简单的清理逻辑，放到后台定时任务里执行：

# cleanup.py import docker import time client = docker.from_env() TTL_SECONDS = 600 # 会话最大存活时间，默认10分钟 def cleanup(): for container in client.containers.list(all=True): labels = container.labels if "agent-session" not in labels: continue created = labels.get("created_at", 0) if int(created) + TTL_SECONDS < time.time(): print(f"removing expired session: {container.id}") container.remove(force=True) if __name__ == "__main__": while True: cleanup() time.sleep(60) # 实际部署建议用systemd timer或者cron

注意创建容器时给它打上 agent-session 标签，同时把创建时间也写到 labels 里，这样回收逻辑才能识别哪些容器是 Agent 沙箱、哪些是普通业务容器。这个设计非常基础，但它决定了你的沙箱集群能不能长时间稳定运行。

回收机制里还有一条重要原则：默认宁可多销毁也不能留垃圾。Agent 任务要支持重试，环境丢了重新拉一个就行，千万不要心疼。

4. 沙箱里的 Agent 能干什么：工具、技能与编排

4.1 Skill、Agent、Harness 到底分别是什么

云沙箱不是孤立存在的，它最终要跟 Agent 框架里的技能、编排系统配合。我经常看到有人被 Skill、Tool、Agent、Harness 这几个概念弄糊涂，这里用我的理解讲清楚。

• Skill（技能）：一组可复用的能力包。比如“写正则”是一个 skill，“绘制图表”是一个 skill。在沙箱里往往表现为一段脚本模板或一个函数集合。
• Tool（工具）：更具体的外部接口，比如天气 API、支付接口。沙箱本身也可以被注册成一个 Tool，暴露执行命令、读文件、装依赖这三个能力。
• Agent（智能体）：做决策的主体。它观察输入、分解任务、调用工具、分析反馈，是大脑。
• Harness（编排/框架壳）：装着 Agent 运行的外壳程序，负责调度、记忆管理、多 Agent 协作、日志记录等。沙箱和 API 服务其实可以理解为 Harness 的一部分或底层设施。

四者的关系我用一个类比：Harness 是导演，Agent 是演员，Tool 是舞台上的道具，Skill 是演员会用的表演套路，而云沙箱是整座摄影棚。没有摄影棚，多精彩的戏都拍不出来。

4.2 把沙箱注册成 Agent 工具的三个能力

在接入 Agent 框架时，我建议不要把沙箱暴露成“执行任意命令”的一个大接口，这样太宽泛，模型容易失控。我习惯拆成三个工具：

• run_command(command)：在沙箱里执行单条命令，并返回 stdout、stderr 和退出码。
• write_file(path, content)：向沙箱写入文件，适合让 Agent 先写好脚本再执行，避免命令行转义地狱。
• read_file(path)：读取沙箱内文件内容，适合让 Agent 检查运行结果或日志。

这样做的好处是，模型不需要在一条命令里把“写代码 + 运行 + 读取结果 + 修复”全部塞进去，而是像真正的开发者一样分步操作。每一步的反馈都很清晰，模型的执行成功率会明显提高。

4.3 典型任务：代码调试、数据处理、依赖安装

拿一个实际场景举例。假设任务需求是“把 data 目录下的 30 个 CSV 文件合并成一个大表，并计算每列的平均值”。

在没有沙箱之前，Agent 只能输出一段 pandas 脚本，让你自己跑。有了沙箱之后，Agent 的执行链路是这样的：

1. 调用 read_file 查看 data 目录下的文件名列表。
2. 调用 write_file 写一段 pandas 脚本到 /workspace/merge.py。
3. 调用 run_command 执行 python3 merge.py。
4. 发现报错，读取错误日志，发现某个文件编码不是 UTF-8。
5. 修改脚本，增加 encoding 参数，重跑。
6. 成功后输出结果文件路径，并打印前几行数据作为验证。

你会发现，这不是一次调用完成的，而是一轮又一轮的“执行-观察-修正”循环。云沙箱的价值恰恰在于承载这个循环。没有它，Agent 永远只能给出一个“理论正确”的答案，永远无法应对真实世界的脏数据。

依赖安装是另一个高频场景。Agent 经常会用到镜像里没有的库。我的建议是，让 Agent 先尝试执行 pip install 某库，如果失败就把错误日志给模型，让模型判断是不是包名写错了或者版本冲突，然后换个版本再来。这个环节特别能体现 Runtime 的意义：模型对具体环境的感知，是通过真实的错误反馈构建起来的，而不是凭空猜。

4.4 “建模为工具”和“建模为环境”是完全不同的产品

之前做过一个项目：一开始我们把沙箱封装成一个工具，Agent 每次只能调一次，拿到结果就结束。效果非常差，因为一次调用根本不可能完成一个复杂任务。后来我们改成让它持有“一个会话”，也就是把一个沙箱会话绑定到 Agent 的某次任务生命周期里，它可以在里面反复操作，效果立刻上了一个台阶。

这个体会总结起来就是：工具调用解决“点”的问题，环境持有解决“面”的问题。前者的沙箱是函数，后者的沙箱是“临时电脑”。这也是为什么我在第 2 章特意强调了会话模型。如果你在设计 Agent 时只给了一个“执行命令”的工具，没有“保持会话”的概念，那你其实还没发挥出云沙箱真正的作用。

5. 常见 Runtime 与沙箱故障排查实录

5.1 老遇到“缺少 Runtime 组件”之类的报错怎么破

用沙箱跑程序时，最常见的坑不是代码写错，而是环境里缺少某个 Runtime 组件。比如沙箱内跑一个需要 WebView2 的桌面程序，报错 could not find the webview2 runtime；或者编译一些 Windows 程序时，提示缺少 Microsoft Visual C++ Runtime。还有跑 LabVIEW、NDI、OpenPLC 相关程序时，也会报各种 Runtime Error。

我以前遇到这类报错，第一反应是去网上搜“xxx runtime download”，后来发现这是很低效的做法。更靠谱的思路是先搞清楚程序到底依赖什么：

• 如果是 Windows 程序，用 dumpbin /dependents 或 Process Explorer 查看 DLL 依赖列表；
• 如果是 Linux 程序，用 ldd 命令查看共享库缺失情况；
• 如果程序自带安装器，优先把安装器跑一遍，让安装器自己处理 Runtime 依赖。

这里我想特别强调一点：沙箱是一个精简环境，它不是完整操作系统，很多在物理机上“早就装好了”的运行库，沙箱里根本没有。所以给 Agent 设计镜像时，要先把可能用到的 Runtime 提前预装好，并且记录成文档。等踩多了坑之后你会发现，绝大多数的“runtime error 713”“webview2 runtime not found”本质上不是程序坏了，而是环境没给够。

5.2 “container runtime is not running” 这类容器层故障

用 Docker 或 containerd 做底层时，最让人头疼的是容器运行时服务本身挂掉。典型报错如 container runtime is not running: output: time=...。遇到这种问题，我的排查顺序是这样的：

1. 先看 Docker 服务状态：systemctl status docker
2. 再查 containerd 是否存活：systemctl status containerd
3. 看 Docker Daemon 日志：journalctl -u docker --since "5 minutes ago"
4. 检查磁盘空间：df -h，Docker 在磁盘写满时会拒绝创建新容器，这个场景太常见了。
5. 最后检查 cgroup 驱动是否异常：Docker 和 Kubelet 如果配置的 cgroup driver 不一致，就会报告运行时问题。

曾经有次凌晨收到告警，一堆 Agent 任务全部失败，查了半天发现是磁盘被日志撑满了。容器运行时不是说你装了就能一直跑的，它也是个需要护理的服务。

5.3 Agent 代码把沙箱资源吃光了：OOM、pids limit、僵尸进程

Agent 自动写代码时最容易碰到的资源问题有三个。

一是内存爆掉。沙箱设置了 512MB 内存限制后，Agent 跑个大数据集脚本直接 OOM。查这个最直接的方法是 docker stats 看实时占用，或者看 docker events 里有没有 OOMKilled 事件。

二是 PID 耗尽。如果 Agent 跑出一个 fork 炸弹，哪怕代码是误写的，也会瞬间把 256 个 PID 上限打满，导致后续所有命令都 fork 失败。这种问题用 docker inspect 检查 Pids 字段，或者直接看容器状态里是否显示“pids limit reached”。

三是僵尸容器残留。如果你没有做 TTL 回收，跑完的任务会留下大量 Exited 状态的容器，占用磁盘可写层空间。我建议每天定时执行 docker container prune -f，强制清理退出容器，并且在上层业务逻辑里做好沙箱销毁调用。

5.4 沙箱内网络和依赖下载问题

Agent 在沙箱里执行任务时需要访问外网，比如 pip install、git clone、curl 拉数据。我遇到最多的问题是 DNS 解析失败和访问超时。排查 DNS 可以进入容器跑 cat /etc/resolv.conf 和 nslookup 测试，访问超时要先确认宿主网络是否正常，再试容器内 curl。

还有一个值得注意的点：沙箱网络策略不要做得太死。如果在创建容器时网络模式设置成 none，确实最安全，但 Agent 下载依赖也会全挂。我一般用 bridge 模式，然后在业务侧做域名白名单。注意白名单是“允许优先级”的设计，不是默认全开再拿黑名单拦截，否则很容易漏。

5.5 安全问题：别让 Agent 的“手”变成风险

最后必须谈安全。Agent 运行在云沙箱里其实带来了一个幻觉：有些人觉得已经沙箱了，可以随便让 Agent 执行任何代码。这是不对的。沙箱只隔离执行边界，不隔离业务损失。如果 Agent 去调用你的内部数据库接口、把数据传到外部服务，那沙箱挡不住。

我建议做三层防护。第一层是命令过滤：高危命令要拦截，比如 rm -rf、mkfs、shutdown、格式化等，至少在大模型执行前做一次匹配。第二层是非 root 运行：沙箱内默认用户是 agent，不是 root，即使发生逃逸，权限也不会太高。第三层是日志审计：所有 Agent 执行的命令和读写文件操作都记录到审计日志，一旦出问题能回溯。我见过不少团队在功能上线后才补日志，那个过程非常痛苦。

第三层在技术上是“先有日志再查问题”，在流程上是“先有告警再有响应”。如果连完整的操作日志都没有，万一日后需要追责或者排查，只能抓瞎。

6. 把云沙箱真正接进 Agent 体系的几条经验

6.1 从技术 Demo 到产品化要补的东西

很多人照着网上的教程把沙箱跑通了，但离产品化还差得远。我觉得至少要补五块。

• 身份与配额：每个用户或每个 Agent 能创建多少个会话、占多少资源，必须有限额机制。
• 任务队列：当沙箱数量爆发时，要有排队机制，不能让高并发直接把底层运行时打挂。
• 审计日志：记录每次会话的创建、执行命令、销毁、文件操作，这是安全合规的底线。
• 计费或配额：不一定是真计费，但要让每个任务有配额上限，防止个别 Agent 烧掉过多资源。
• 会话回收：TTL + 心跳检查 + 强制回收，一个都不能少。

这五块做完，你的沙箱才算从“能玩”升级到“能交付”。

6.2 本地 Docker 和云端沙箱集群怎么选

我经常被问到一个问题：是不是一定要上云端集群？本地 Docker 行不行？

答案取决于你的场景。如果是自己开发调试或者内网私有场景，本地 Docker 已经足够，成本低、反馈快。但如果你做的是 SaaS 产品，要同时服务多个用户，那必须用云端沙箱集群。云端的好处是隔离性更强、弹性更大、也更方便统一管理。

我见过一些团队把本地 Docker 直接部署到生产，后来被用户的恶意代码打穿。他们的想法是“反正有 Docker 隔离”，但 Docker 逃逸漏洞不是没出现过。多租户场景一定要慎重评估隔离边界，该上微虚拟机的时候就别省。

6.3 一些掏心窝的话

折腾了这么久，我的最终体会是：让 Agent 拥有一个临时 Runtime，不是锦上添花，而是它从“玩具”走向“工具”的分水岭。云沙箱看着就是个跑代码的容器，但它把 Agent 的试错能力、反馈能力和自我修正能力全部激活了。你可以把沙箱看作 Agent 的“手”，把隔离边界看作“安全套”，两者缺一个都会出事。

如果这篇文章只能带给你一件事，那我希望你记住：别急着堆功能，先把“执行-反馈-修正”的闭环搭起来，哪怕是最简单的 Docker + 三个 API 接口。闭环通了，后面怎么做都是加法；闭环不通，你加再多工具，Agent 还是那个嘴上王者。

最后再分享一个小技巧：给 Agent 配置沙箱时，把容器的默认退出超时设置得比你想象中短一点。我一开始设了 15 分钟，后来生产环境发现大量资源被挂起的会话占着，改成 5 分钟后，整体吞吐直接翻了一倍。资源这东西，宁可让 Agent 重新跑，也不要让它占着茅坑不拉屎。