2026新库实测：sbxloop 1.5.24 让 AI Agent 在 Docker 沙箱中安全自治，告别环境混乱

2026新库实测：sbxloop 1.5.24 让 AI Agent 在 Docker 沙箱中安全自治，告别环境混乱

本文面向 Python / AI 开发者，结合 2026年09月 前后的工具与生态变化做一次可落地的盘点。

为什么 AI Agent 需要沙箱？从环境地狱到安全自治

如果你最近在认真玩 AI Agent，不管是用 LangChain 搭链、写 AutoGPT 式的循环，还是自己撸一个 ReAct 模式，大概率都撞上过同一堵墙：环境地狱。

不是开玩笑。上周我在本地跑一个需要调用 faster-paddle 做 OCR 的 Agent，刚装好 Rust 工具链和 ONNX Runtime，结果发现系统里的 OpenCV 版本和它冲突；修完 OpenCV，另一个依赖又把 numpy 从 2.x 降回了 1.26。最后 Agent 没跑起来，我的虚拟环境先碎了一地。这还只是依赖问题------更头疼的是安全。

AI Agent 的本质是"有手有脚"的程序。它能执行 shell 命令、读写文件、调用网络 API。一旦你把一个解析 HWP 文档的 Agent 放上生产服务器，它要读用户上传的文件，就必然接触到文件系统权限边界。如果 Agent 的代码里有一个 prompt injection 漏洞，攻击者完全可能让 Agent 去读 /etc/passwd 或者把私钥发出去。你总不能指望每一行模型生成的代码都是安全的。

还有一个被低估的问题是可复现性。今天 Agent 跑得好好的，明天某个 pip 包发了个新版本，行为就变了。Python 3.15 都出 RC2 了，RISC-V 也正式支持了，生态演进这么快，你上个月调通的 Agent 工作流，下个月可能就静默失败。CI 里跑测试还能锁版本，但 Agent 是常驻服务，它内部动态装的依赖你怎么锁？

所以答案很直接：把 Agent 关进 Docker 沙箱。容器天然隔离文件系统、网络和进程，依赖锁在镜像里，权限通过 capability 控制。但光有 Docker 不够------Agent 不是跑一次就完事的脚本，它是一个带循环、有状态、需要和宿主机通信的进程。

这就是 sbxloop 1.5.24 想解决的问题。它的设计理念很干脆：把"Agent 循环"和"执行环境"彻底解耦。你在宿主机上编排逻辑------决定下一步调哪个工具、怎么处理模型输出------但真正跑代码、碰文件、联网的活儿，全部丢进一个按需创建的 Docker 沙箱里。沙箱内跑一个 sbxloop-worker，负责接收任务、执行、返回结果，协议是现成的。

好处是双重的。安全上，Agent 即使被注入恶意指令，它也只能在容器里折腾，碰到挂载卷边界就停手。环境上，每个任务或每个 Agent 实例可以拥有独立的镜像快照，依赖冲突从根上消失。代码层面，你不需要在宿主机上装任何 Agent 的运行时依赖，只需要一个 Docker 客户端：

from sbxloop import SandboxSession

with SandboxSession(image="python:3.12-slim") as sbx:
    result = sbx.run("import faster_paddle; print('ok')")

当然，沙箱不是银弹。镜像拉取延迟、容器启动开销、以及跨沙箱的状态同步，都是你需要接受的代价。但比起在裸环境里裸奔，这点成本换来的安全自治，怎么算都值。

sbxloop 1.5.24 核心概念与安装实战

先把最核心的问题说清楚：为什么我们需要一个 sbxloop 这样的编排层，而不是直接 docker run 一把梭？

如果你写过超过一周的 Agent 脚本，大概率遇到过这种场景：项目里装了 requests 2.31 和 2.32 两个版本，因为不同 Agent 依赖冲突；或者某个 Agent 需要读 /etc/passwd，结果把宿主机信息泄露给了 prompt。这些问题的根源在于------Agent 的运行环境没有边界 。sbxloop 的思路很直接：把"循环决策"和"执行环境"彻底拆开。

核心架构拆解

sbxloop 1.5.24 的架构可以理解为四个咬合紧密的齿轮：

1. Agent Loop（决策大脑） ：这是跑在你宿主机 Python 进程里的主循环。它负责调用 LLM、解析输出、决定下一步动作。它本身不执行任何危险操作，只产出"意图"。
2. Docker Sandbox（执行躯干） ：每个具体的工具调用（比如 subprocess.run、os.remove）都被封装成一个 Job，扔进一个全新的、一次性 Docker 容器里执行。容器跑完即焚，不留残余。
3. 隔离凭据域（Credential Domain） ：这是 1.5.x 版本我最喜欢的设计。以前我们把 API Key 放在环境变量里，Agent 一读就全暴露了。现在你可以为每个 Sandbox 单独注入一个加密的凭据域，比如 SBX_CRED_DOMAIN=github_token，只有该容器内的 Worker 能解密，宿主机上的主进程反而看不到明文------权限最小化。
4. Worker 运行时（执行末梢） ：这个就是需要单独安装的 sbxloop-worker 包。它跑在 Sandbox 容器内部，负责接收主循环下发的 JSON-RPC 指令、执行 Python 代码、回传 stdout/stderr 和退出码。

安装实战

安装很简单，但注意必须分两处装：

# 宿主机：编排层
pip install sbxloop==1.5.24

# 宿主机：用于构建沙箱镜像的基础依赖（可选，但推荐）
pip install sbxloop-worker==1.5.24

为什么宿主机也要装 sbxloop-worker？因为你需要用它的 CLI 来预构建沙箱镜像 ，否则每次启动都要现场 pip install，慢得怀疑人生。验证一下：

python -c "import sbxloop; print(sbxloop.__version__)"  # 1.5.24
sbxloop-worker --version  # 如果提示找不到命令，检查是否装了 worker

一个坑：务必保证两个包的版本号严格一致 。sbxloop 主包和 worker 之间走的是 protobuf 协议，如果版本错位（比如主包 1.5.23、worker 1.5.24），你会看到极其诡异的 TypeError: Descriptor for 'JobResult' is not a message type 错误，且堆栈完全不可读。

对比一下传统做法：以前你用 subprocess 直接跑外部工具，环境变量是全局的，文件系统是共享的。现在用 sbxloop，你写的是这样的代码：

from sbxloop import AgentLoop, SandboxSpec

loop = AgentLoop(
    sandbox=SandboxSpec(image="python:3.12-slim", credential_domain="prod_github"),
)
result = loop.run_job("git status --porcelain", timeout=30)
print(result.exit_code, result.stdout)

这段代码的语义是：git status 在隔离容器里执行，它读不到你宿主机上的 SSH 私钥，也改不了你的项目文件，除非你显式挂载卷。这种"显式优于隐式"的安全边界，正是 sbxloop 区别于 docker-py 裸调用的价值所在。

快速上手：在 Docker 沙箱中运行你的第一个 Agent 循环

安装好 sbxloop 之后，你会发现它的 API 设计相当克制------没有花哨的装饰器，核心就三个概念：SandboxSpec（沙箱长什么样）、AgentTask（跑什么任务）、LoopRunner（怎么循环）。这种"配置与执行分离"的思路，比那种把环境参数硬编码进 Agent 逻辑的写法干净得多。

先看一个最简示例：让一个 Agent 在容器里反复执行"读取 /workspace/counter.txt，加一后写回"，同时打印每次迭代的思考摘要。这模拟了真实场景中 Agent 维护状态、处理持久化数据的过程。

from sbxloop import SandboxSpec, AgentTask, LoopRunner

spec = SandboxSpec(
    image="python:3.12-slim",
    workdir="/workspace",
    mount_readonly={"/etc/ssl/certs": "/etc/ssl/certs"},  # 只读挂载，避免证书问题
    resource_limits={"memory": "512m", "cpu": "1.0"},
    network_policy="none",  # 先断网，防止 Agent 乱抓数据
)

task = AgentTask(
    system_prompt="你是一个文件操作助手。每次循环读取 counter.txt，若不存在则创建并置0，然后加一写回。用一句话总结当前计数。",
    max_steps=5,
    output_schema={"summary": "string"},  # 强制结构化输出
)

runner = LoopRunner(spec=spec, task=task)
result = runner.run()

注意几个细节：mount_readonly 我特意只挂了证书目录，因为很多 Agent 框架默认要访问系统 CA 证书，但你又不想让它写宿主机任何路径。network_policy="none" 是 1.5.24 新增的硬隔离选项------如果你跑的是内部知识库问答 Agent，这一步能直接掐断数据外泄的路径。

跑起来后，日志输出非常像 CI 流水线：

[step 1] container started (id: 8f3a2c9d)
[step 1] agent action: read_file(path=/workspace/counter.txt) -> not found
[step 1] agent action: write_file(path=/workspace/counter.txt, content="1")
[step 1] summary: 已创建计数器文件，当前值1
[step 2] container reused (id: 8f3a2c9d)  # 注意这里！
[step 2] agent action: read_file(path=/workspace/counter.txt) -> "1"
...

看到 container reused 了吗？这是 sbxloop 和裸 docker run 最大的区别：它在同一个沙箱实例里跑完整个循环，而不是每步都新开容器。对比之前我试过的 docker-py 手动方案，每步都要 docker exec + 文件复制，代码量至少翻三倍，而且很难处理 Agent 中途崩溃后的状态恢复问题。

有几个坑必须提醒你。第一，output_schema 不是摆设------如果你的 Agent 返回的 JSON 不匹配 schema，LoopRunner 会直接报 SchemaValidationError 并终止循环，这比事后解析脏数据要省心得多。第二，resource_limits 别设太大，512MB 内存对大多数文本处理 Agent 绰绰有余，设大了反而容易在宿主机上堆积不可控进程。

最后说说日志观察的技巧。runner.run() 默认返回一个 LoopResult 对象，里面有每步的 token 消耗和耗时。我建议你第一次跑的时候把 verbose=True 传进去，能看到完整工具调用链------这比事后看汇总日志更容易理解 Agent 的决策路径。等你熟悉了流程，再关掉 verbose 节省输出量。

隔离凭据域：让 API 密钥安全地注入沙箱

凭据管理一直是 Agent 沙箱方案里最容易被低估的环节。很多团队把代码和依赖关进容器，却把 OPENAI_API_KEY 直接写死在镜像环境变量里------这等于给沙箱装了个透明玻璃门，锁了个寂寞。sbxloop 1.5.24 这次主打的 "isolated credential domains" 就是冲着这个痛点来的，思路很直接：沙箱隔离的不只是文件系统，更应该是密钥的可见边界。

它的核心机制是把凭据分成独立的"域"（domain），每个域绑定特定的沙箱或任务组。你在宿主机配置好一个域，里面存了 ANTHROPIC_API_KEY、DATABASE_URL 这类敏感项，然后通过 sbxloop 的调度 API 指定哪个 Agent 能用哪个域。代码上大概是这种感觉：

from sbxloop import SandboxCredentialDomain, AgentLoop

domain = SandboxCredentialDomain(
    name="web-researcher",
    secrets={
        "TAVILY_API_KEY": "...",
        "SLACK_WEBHOOK_URL": "...",
    },
    allowed_backends=["docker://python:3.12-slim"],
)

loop = AgentLoop.with_domain(domain)
result = loop.run_sandboxed(
    task="搜索近期RISC-V相关Python进展并汇总",
    sandbox_id="sb-2026-0912",
)

注意，domain 不会把密钥烧进镜像，而是在容器启动时通过临时文件描述符或匿名管道注入。宿主机上的进程能看到明文，但沙箱内部的子进程只能通过 sbxloop-worker 1.5.24 提供的受控 API 读取。也就是说，即便 Agent 被提示注入攻破，它拿到的也只是当前域内的密钥，没法横向翻出另一个域里的 AWS Secret。

对比一下 naive 做法：直接把 os.environ["OPENAI_API_KEY"] 传进去，Agent 可以打印、外传、甚至写进日志文件。而 sbxloop 的做法是给每个密钥加了读取次数限制和审计钩子------worker 端每次访问密钥都会记录调用栈，方便事后回溯到底是哪一步泄露了。这个特性在调试多步 Agent 时尤其救命，你能精确看到是"搜索工具"还是"总结模块"碰了密钥。

权限控制上，sbxloop 支持按沙箱标签做匹配。比如你有个沙箱跑 untrusted 代码，就给它配一个只读的、不含任何 LLM 密钥的域；而负责调度的主 Agent 用完整域。这种"最小权限"原则在编排层就落实了，比在代码里到处写 if 判断要干净得多。

当然也有代价。域切换需要额外的握手开销，每次启动沙箱大约多 30~50ms 的延迟，对于高频短任务（比如单个 API 调用）会有点肉疼。另外，如果你习惯把所有密钥堆在一个 .env 里，sbxloop 的域机制会强迫你重新梳理配置结构，初期有点烦。但考虑到 2026 年供应链攻击的频率，这点重构成本换来的隔离边界，我觉得值。

与 sbxloop-worker 协作：构建高性能的 Agent 后端

聊完主控端，我们把目光转向沙箱里的"干活人"------sbxloop-worker。如果你把 sbxloop 主库比作调度中心，那 worker 就是派驻到每个 Docker 容器里的现场经理。它负责处理协议模型（把主控的指令翻译成沙箱能懂的任务）、维护 Agent 后端（比如你写好的 ReAct 循环或工具调用逻辑），并最终驱动任务执行。没有它，主控端再聪明，也只是对着空容器喊话。

sbxloop-worker 1.5.24 的设计思路很务实：它不关心你的 Agent 是 LangChain 还是裸写的 while 循环，它只定义了一套清晰的入站/出站协议 。这意味着你可以把任何 Python 可调用对象注册成一个"任务处理器"。配置起来非常直接，核心就是继承 BaseWorker 并实现 handle_task：

# worker_app.py
from sbxloop_worker import BaseWorker, JobContext

class MyCodeAgent(BaseWorker):
    async def handle_task(self, ctx: JobContext):
        # ctx.payload 是主控端发来的 JSON 参数
        code = ctx.payload["code_to_review"]
        # 在这里执行你的静态分析或测试逻辑
        result = run_my_analysis(code)
        # 返回结果会通过协议回传给 sbxloop 主控
        return {"status": "ok", "findings": result}

if __name__ == "__main__":
    worker = MyCodeAgent()
    worker.run()  # 默认监听容器内 127.0.0.1:9876

这段代码跑在沙箱里，主控端通过 Docker 网络或挂载的 socket 与它通信。我特别喜欢的一点是，worker 进程与沙箱生命周期解耦：你可以让一个容器常驻，连续处理多个任务，避免每次冷启动 Python 解释器带来的 200-500ms 开销。对比之前我用过的一些方案------比如直接在容器 entrypoint 里跑 python -c "..." 或者用 docker exec 每次注入代码------sbxloop-worker 的优势在于有状态复用。比如你的 Agent 需要维护内存中的 embedding 索引或数据库连接池，worker 常驻就能让这些资源跨任务存活，性能提升是数量级的。

任务分发上，sbxloop 主控默认采用简单轮询，但如果你在 sbxloop.yaml 里给 worker 打上标签（比如 capability: code-review），主控就能按需路由。这比 RabbitMQ 那套轻量太多，但对单机多沙箱的编排场景足够精准。有个坑得提醒：worker 的 handle_task 必须做到可重入，因为失败重试时主控可能重新投递任务。千万别在里面写全局状态，否则第二次执行时数据就脏了。

另外，新版 worker 对 Python 3.15 的 RC 版本适配得不错，我测试时没遇到异步事件循环的兼容问题。不过如果你要用 RISC-V 的 Docker 镜像，记得确认 worker 轮子是否发布了对应架构的包------目前 PyPI 上官方 wheel 主要还是 x86_64 和 arm64。

实战案例：构建一个自治研究 Agent（自动搜索并总结）

沙箱里跑一个自治 Agent：从搜索到总结全自动

理论说再多，不如直接看一个能跑的例子。下面我用 sbxloop 1.5.24 搭配 sbxloop-worker，搭一个"网络研究员"Agent------给它一个主题，它能自己决定搜什么、抓哪些页面、最后吐出一份结构化摘要。整个过程在 Docker 沙箱内完成，宿主机除了拿到最终结果，连一个临时文件都不会碰。

任务定义：把"研究"拆成可执行步骤

sbxloop 的核心思路是把 Agent 的循环逻辑（思考、调工具、观察结果）编排成可复用的任务。我先定义一个 ResearchTask，它包含两个阶段：先用 search_web 工具获取候选 URL，再对每个 URL 执行 fetch_and_summarize。

from sbxloop import SandboxTask, task

@task(name="research_agent", version="1.5.24")
def research_flow(topic: str, max_sources: int = 5):
    # 阶段一：搜索
    urls = search_web(topic, top_k=max_sources)
    # 阶段二：逐个抓取并总结
    summaries = []
    for url in urls:
        raw = fetch_page(url)
        summary = summarize(raw, max_words=200)
        summaries.append({"url": url, "summary": summary})
    return merge_summaries(summaries)

注意这里有个关键设计：每个阶段都在独立的沙箱步骤里执行 。这意味着如果 fetch_page 碰到恶意 JS 或异常重定向，它只污染当前步骤的沙箱，不会影响后续循环。这在传统 Agent 框架里很难做到------它们是单进程跑完所有工具调用，一个库把环境搞脏了，整个 Agent 就废了。

网络配置：沙箱不是"断网监狱"

有人会担心沙箱隔离 = 没法联网。sbxloop 的网络模型比较灵活：默认是 isolated（无网络），但你可以在任务级别声明需要的网络策略。我的研究 Agent 需要访问公网，所以这样配置：

sandbox_config = {
    "network": {
        "mode": "egress_only",   # 只允许出站连接
        "dns": True,
        "allow_private_ips": False  # 防止 SSRF 打到内网
    },
    "resources": {"memory": "512m", "cpu": "1.0"}
}

egress_only 是个很实用的中间态------容器能访问外网，但宿主机无法反向连进沙箱。allow_private_ips: False 这行尤其重要：很多抓取库会跟随重定向，如果某个恶意页面把你引向 http://169.254.169.254（云元数据服务），没有这层限制，你的云凭证就泄露了。sbxloop 把这个做成默认关闭，比让你自己写 SSRF 防护要省心得多。

sbxloop-worker：沙箱内的"打工仔"

任务定义好了，实际在沙箱里干活的是 sbxloop-worker。它运行在容器内部，负责接收宿主机派发的步骤、执行代码、回传结果。我比较喜欢它的"协议模型"设计------worker 和宿主机之间通过版本化的消息协议通信，不是简单的 exec 字符串，所以调试时能看到清晰的结构化日志。

# 宿主机侧启动编排
sbxloop run research_agent --topic "RISC-V CPython 支持进展" --sandbox-config sandbox_config.json

执行过程中，宿主机侧会流式输出每个步骤的状态：搜索完成 (3 个结果)、抓取 https://... 成功、摘要生成中...。如果某一步超时或崩溃，sbxloop 默认策略是重试一次，然后跳过该来源继续跑------不会因为一个坏链接毁掉整个研究任务。

结果回收：只拿你想要的

任务跑完后，结果通过 collect_artifacts() 回收。这里有个细节：沙箱的完整文件系统会被丢弃 ，只有你显式标记为 artifact 的数据才会传回宿主机。

with research_flow(topic="RISC-V Python 3.15") as run:
    result = run.collect_artifacts()
    print(result["final_report"])

我特意对比过用裸 Docker + 自写胶水代码的方案：自己写的话，你得管理容器生命周期、处理日志转发、设计结果传输协议，还要考虑失败重试------至少多写 300 行代码。sbxloop 把这些变成了声明式配置，而且它的隔离粒度是"步骤级"而非"任务级"，这意味着同一个 Agent 可以在不同沙箱策略间切换，比如让 fetch_page 步骤用更严格的资源限制，而 summarize 步骤分配更多内存跑大模型。

当然也有取舍。每次步骤切换都有 Docker 容器启动开销，实测在本地 SSD 上大约 150--300ms，比进程内函数调用慢一两个数量级。但如果你的 Agent 涉及不可信输入或第三方 API，这点延迟换来的安全隔离，我觉得相当划算。

进阶技巧：监控、日志与错误恢复

跑起来只是第一步，能稳定跑完一个 72 小时的批处理任务才是真本事。sbxloop 的监控能力藏在两个地方：一是宿主侧的 LoopMonitor，二是沙箱内的 worker 心跳。默认情况下，每个循环周期结束，sbxloop 都会通过 on_step_complete 回调抛出结构化事件，你可以直接接 Prometheus 或写 JSONL。我个人习惯是给每个沙箱打上 task_id 标签，配合 sbxloop-worker 1.5.24 里新增的 job_runner 状态上报，能精确看到当前 Agent 是卡在工具调用还是长文本生成上------这比盲目看 stdout 靠谱得多。

日志收集这块，别指望直接读 Docker stdout。沙箱里的 Python 进程、Shell 命令、甚至 apt 安装日志，全混在一起时你会疯掉。sbxloop 内置了 collect_logs() 方法，它在沙箱内执行 journalctl 或读取 /var/log/ 下指定文件，然后以 tar 流的方式传回宿主机。有个坑得提醒你：默认只保留最近 100 条循环记录，如果你需要完整审计轨迹，记得在创建沙箱时设置 log_retention="full"。另外，强烈建议把沙箱内的 PYTHONUNBUFFERED=1 环境变量加上，否则 Python 的缓冲输出会让你在排查崩溃时少掉最后三行关键报错。

错误恢复是长跑任务的分水岭。sbxloop 的重试机制不是简单的 try/except 包一层，它分三层：工具调用级、循环周期级、沙箱级。工具调用失败（比如某个 API 超时），默认重试 3 次，指数退避；循环周期内 Agent 抛出未捕获异常，max_retries_per_step=5 会强制重建该步的上下文快照并重新执行；最狠的是沙箱级恢复------当 Docker 容器本身 OOM 或网络断开，sbxloop 会基于最新的 checkpoint 镜像拉起一个新沙箱，从失败的那一步续跑。

from sbxloop import SandboxLoop

loop = SandboxLoop(
    image="my-agent-base:latest",
    retry_policy={
        "tool_call": {"max_retries": 3, "backoff": 2.0},
        "step": {"max_retries": 5, "checkpoint": True},
        "sandbox": {"max_restarts": 2, "resume_from": "last_ckpt"},
    },
    on_error=lambda ctx: notify_slack(ctx.task_id, ctx.error),
)

注意，resume_from="last_ckpt" 依赖你在代码里显式调用 checkpoint() 方法，否则它只能从循环开头重启。我见过不少团队栽在这：以为沙箱级恢复是银弹，结果 checkpoint 没打，重启后 Agent 忘了前 20 步的工具调用结果，产生幻觉输出。另一个反直觉的点是，重试并不总是好事------如果你的 Agent 在循环里调用外部付费 API，工具级重试可能导致重复扣费。建议在 retry_policy 里对幂等性差的工具单独设 max_retries=0，宁可失败跳步，也别烧钱重试。最后，on_error 回调里一定要捕获异常，别让监控代码自己挂了，否则你会陷入"监控系统没监控"的尴尬。

总结与展望：sbxloop 在 AI 工程化中的位置

先说结论：sbxloop 1.5.24 不是又一个"玩具级"的 Agent 框架，它更像是一个务实的运维层协议 。它没有去重新发明调度算法，而是把 Docker 的隔离能力做成了 Agent 循环的"安全带"。如果你受够了每次跑实验都要手动 docker rm -f 清理僵尸容器，或者担心 Agent 拿着你的云厂商 Key 乱调 API，这个库值得花半小时试一下。

它的核心优势在于隔离凭证域 （isolated credential domains）。这一点在真实生产里比任何花哨的提示词工程都重要------当你的 Agent 需要调用内部工单系统或数据库时，你不再需要把生产 Key 直接灌进 LLM 的上下文窗口，而是让 sbxloop 在沙箱内临时注入、用完即焚。配合 sbxloop-worker 1.5.24 在沙箱内跑 job runner，整个结构像是给每个子任务发了一张"限时门禁卡"。

但局限性也很明显。它只解决"环境混乱"，不解决"逻辑错误" 。如果 Agent 在沙箱里写了一段死循环代码，或者调用了 os.remove 删错了目录，sbxloop 本身不会帮你兜底------它依赖 Docker 的资源限制（--memory、--cpus），但如果你没设好，沙箱照样会被拖垮。另外，它默认绑定 Docker 守护进程，这意味着在 Kubernetes 或 Firecracker 这类轻量虚拟机环境里，它的抽象层会显得有点"重"。

对比一下其他方案：Firecracker 是微虚拟机，启动快但隔离更强，适合多租户 SaaS；gVisor 是用户态内核，兼容性好但性能损耗略高。sbxloop 站在它们中间------它不追求"强隔离"，而是追求"够用且可编排"。如果你要跑不可信的外部代码，选 Firecracker；如果你只是要管住自家 Agent 的乱跑，sbxloop 的 Docker 沙箱配合 --network=none 已经能挡住 90% 的意外。

展望未来，我希望 sbxloop 能补上两块短板：一是快照回滚 ，目前它支持挂载卷，但还没有像 overlayfs 那样对 Agent 的每一次"思考-行动"做增量快照；二是跨主机调度 ，现在的 sbxloop-worker 更适合单机，如果 Agent 需要横向扩展到多台机器，得自己写一层分发逻辑。好消息是 Python 3.15 RC2 正在测试，RISC-V 也正式进了 CPython------这类底层生态的推进，会让沙箱在异构硬件上跑得更顺。

最后给个实操建议：别一上来就全量接入，先挑一个高频且低风险的子任务（比如"让 Agent 定期抓取网页并解析 Markdown"），用 sbxloop 包一层，对比一下加沙箱前后的调用耗时和失败率。你会发现，多花的那 200 毫秒启动时间，换来的却是"再也不用半夜爬起来清僵尸进程"的安心。