容器限定的是爆炸半径，而不是行为
当团队第一次为 agent 搭建沙箱时，讨论通常从隔离技术开始。Firecracker microVM、gVisor、seccomp 配置、cgroup 限制、只读根文件系统。这些技术真实且有用，但它们回答的问题比大多数人以为的要窄。它们限定的是损害可能落在哪里，而不是限定 agent 被允许尝试什么。
一个共享宿主网络命名空间的沙箱，已经在问题最关键的部分上让步了。agent 仍然可以访问内部元数据服务、包仓库、模型提供商、公司 wiki，以及任何信任宿主 IP 的服务。文件系统隔离无法约束一个真正的能力面是出站 HTTP 加一组 API 凭证的 agent。你可以把根文件系统挂载为只读，却仍然看着 agent 通过一条被允许的出站路径把数据库外泄，因为真正关键的能力从来不是文件描述符，而是 token。
这就是为什么以容器为先的框架往往会产出看起来严谨、行为上却很宽松的沙箱。分析的单位错了。有用的单位是每一步的能力集合，而这个集合会随着运行的推进而变化。
以能力预算作为设计原语
值得围绕其构建的设计原语，是附着在运行每一步上的能力预算。一步是一个有界的工作单元：一次工具调用、一个模型回合、一次浏览器导航、一条执行器指令。每一步声明它所需的能力。运行时在该步持续期间精确授予这些能力，之后不再保留。
一个具体的机制是这样的。编排器持有一个策略引擎和一个短期凭证代理。在一步执行之前，agent 提交一个能力请求：一份结构化文档，指明资源、操作和预期范围。
{
"step": "fetch_invoice_pdf",
"capabilities": [
{"type": "http", "host": "billing.internal", "methods": ["GET"], "paths": ["/invoices/*/pdf"]},
{"type": "fs", "mount": "/tmp/run-7f3a", "mode": "write"}
],
"ttl_seconds": 30
}
策略引擎根据该运行累积的预算和任务声明的范围来评估请求。如果通过，代理会签发一个限定到该主机、方法和路径的凭证，TTL 以秒计。该步执行。凭证过期。下一步从零开始，必须重新请求。
升级是有意思的情形。当某一步需要当前预算之外的东西时，它必须提交一份显式的升级请求。该请求本身就是一个带策略决策的日志事件：由谁或什么批准、依据哪条规则、何时过期。这把权限蔓延从无声的漂移变成了可审计的序列。它也让运行的能力历史成为一等产物，而这正是当第四十步出问题时你真正想要的东西。
撤销必须能在运行中途进行。这一约束排除了在任务开始时签发的长期 token。如果 agent 持有的唯一凭证是一个生命周期为一小时、限定到任务的 bearer token，那么当 agent 行为漂移、任务前提被证明为假，或有人察觉到问题时，运行时无法收回权限。短期、限定到步骤的凭证让撤销变成“不续签”的问题。这比试图使一个已经在十几个服务间流转的 token 失效要小得多，也可靠得多。
这个权衡是真实的，值得直说。限定到步骤的凭证会成倍增加 token 交换次数，在关键路径上增加一个代理，并引入单个长期 token 所没有的延迟和故障模式。现在每一步都依赖于代理可用且策略引擎正确。采用这一模式的团队要在运维复杂度上付出代价，他们应当审慎决定任务的风险画像是否值得这个成本。对于一个对公开数据做只读摘要的 agent，往往不值得。对于一个持有生产系统写权限的 agent，通常值得。
浏览器和桌面 agent
浏览器和桌面 agent 在构造上就持有广泛的常驻权限。浏览器驱动可以点击任何东西、向任何地方输入、导航到会话 cookie 允许的任何地方。桌面 agent 往往能做得更多。能力预算无法由容器来强制执行，因为容器承载的是一个拥有完整常驻凭证的完整用户会话。它必须在驱动层强制执行。
在实践中，这意味着驱动会拦截导航、表单提交、文件下载、剪贴板访问，以及任何跨越信任边界的调用，并逐一对照当前步骤声明的能力进行检查。一个声明“读取定价页”的步骤不应能够提交表单，即使 DOM 提供了表单。这是驱动层的策略，也是唯一让检查有意义的层，因为它是真正执行动作的那一层。
物理和机器人 agent
物理 agent 增加了软件沙箱所没有的第二个预算维度：运动包络和力限制。机械臂的能力集合不仅包括它能调用哪个 API，还包括它能移动到哪里、多快、用多大的力。这些限制由控制器强制执行，并且必须以同样的方式按步骤限定范围。一个声明“从 A 箱取物”的步骤应携带一个排除 B 箱的运动包络，以及适合该物体类别的力上限。升级到更宽的包络是一个带日志的策略决策，与网络能力完全一样。
这之所以重要，是因为其故障模式不可逆。撤销一个 HTTP token 能阻止数据泄露。撤销一个运动包络会让机械臂停在轨迹中途，这是一个不同的工程问题，涉及减速曲线和安全状态。能力模型相同；撤销语义不同。
评估 harness
评估 harness 应当运行与生产相同的 capability enforcement，否则测试结果就不是证据。这是最常被跳过的步骤，也是最削弱评估价值的步骤。如果 harness 授予 agent 的是生产能力的超集，那么测得的 agent 成功率反映的是一个并不存在的系统。如果 harness 强制执行的是子集，agent 会在生产环境中本可通过的任务上表现为失败。
正确的模式是让 harness 针对生产所用的同一策略引擎和同一代理运行，使用相同的能力声明，并把策略拒绝当作一等的评估结果，而不是基础设施噪声。一个通过三次升级才完成任务的 agent，其行为不同于一个在预算内完成任务的 agent，harness 应当能够告诉你发生的是哪一种。
这改变了什么
容器问题并没有消失。当能力检查失败、agent 仍然做出意外之举时，隔离技术仍然决定会发生什么。纵深防御才是重点。但容器是第二道防线，不是第一道。第一道防线是一个能力预算：按步骤声明、在该步骤持续期间授予、仅通过带日志的策略决策升级，并且在运行仍在进行时即可撤销。
从容器入手的团队，往往会得到一个技术上令人印象深刻、运维上却很宽松的沙箱，因为能力面从未被枚举过。从能力预算入手的团队，最终会清楚地掌握 agent 在每一刻能做什么，并得到一个按残余风险而非按整个问题来定尺寸的容器。后一种顺序前期工作更多，而在事故期间工作要少得多。
封面照片：panumas nikhomkhai / Pexels。