BoxAgnts 运行时（7）——沙箱执行，重塑 Agent 基础设施

AI 行业发展迅猛。每周都有新的 Agent 框架、编程助手、自主工作流引擎或多 Agent 平台出现。大多数讨论聚焦于模型能力------推理性能、规划能力、上下文窗口大小、工具选择准确性。

然而，有一个更根本的问题受到的关注要少得多：

大多数 AI Agent 缺乏一个可信的执行环境。

当前 Agent 系统正变得越来越能够与真实世界交互------执行代码、修改仓库、浏览网站、访问数据库、操作云基础设施。随着它们获得操作权限，执行安全------而不是模型智能------正在成为决定性挑战。

行业在优化智能，而不是执行

大多数 AI 基础设施投资集中在让模型更聪明的技术上------更大的模型、更好的推理、更长上下文、更复杂规划。这些技术回答的问题是"Agent 如何做出更好的决策？"

但生产系统必须回答另一个问题： "当决策错误时会发生什么？"

传统软件工程早就假设了失败会发生，因此设计了故障隔离、权限边界、进程约束、资源治理和恢复机制。许多 AI 系统仍然缺少这些属性------它们依赖"模型会正确行为"的脆弱假设。

BoxAgnts 的设计拒绝了这个假设。在 boxagnts/query/src/query.rs 中，查询循环内置了多层防御：

rust 复制代码

// 查询循环的保护机制
const MAX_TOKENS_RECOVERY_LIMIT: u32 = 3;   // 恢复尝试上限
const MAX_TOKENS_RECOVERY_MSG: &str = "...";  // 恢复消息

// 循环内包含：
// - turn 计数器（防止无限循环）
// - max_tokens 恢复机制（防止 token 耗尽死循环）
// - 预算检查（防止成本失控）
// - cancel_token 取消信号（可随时中断）

这些不是提示词级别的"建议"，而是运行时级别的硬约束。

AI Agent 是执行系统，不是聊天机器人

把 Agent 视为高级聊天界面是一个过时且危险的看法。现代 Agent 可以创建文件、运行命令、调用 API、更新数据库、部署基础设施------一旦 Agent 产生行动而非文本，错误的后果呈指数级扩大。

BoxAgnts 的核心执行循环清楚地展示了 Agent 的执行系统本质：

sql 复制代码

User Request → LLM Planning → Tool Selection → Tool Execution → Environment Modification

关键步骤不是规划，是执行。而且每一步执行都在运行时约束之下。

为什么当前架构是脆弱的

大多数 Agent 的架构本质是：

复制代码

LLM → 工具调用 → Python 运行时 → Shell 命令 → 主机系统

不是 Python 的问题------是信任边界的问题。模型决定了执行什么、访问什么、何时停止，但模型本身暴露在提示注入、对抗性文档和不可信内容之中。这形成了"不可信规划器 → 可信执行"的架构悖论。

BoxAgnts 通过在 Planner 和 Executor 之间插入运行时边界来解决这个问题：

scss 复制代码

LLM (Planner)
    ↓
Query Loop (run_query_loop --- 执行治理)
    ↓
Tool Interface (permission_level 检查)
    ↓
WASM Sandbox (硬性约束)
    ↓
Host Resources (受保护)

每一层都是一个独立的治理点，层与层之间不存在隐式信任。

沙箱作为一等运行时原语

BoxAgnts 将沙箱化执行从"可选特性"提升为"架构基础"。所有 WASM 工具默认在沙箱内运行，沙箱是系统最底层的基础设施组件（boxagnts/wasm-sandbox/），位于 tools 和 gateway 的下方。

这种设计确保了安全不是事后修补------无论上层如何变化，执行约束始终生效。

工具运行时与工作流引擎是不同的层

AI 生态系统中一个常见混淆是工作流引擎和运行时引擎的关系。

工作流引擎（chains、graphs、planners）决定"应该发生什么"。运行时引擎决定"允许发生什么"。

BoxAgnts 中有三个明确的编排层：

Query 层 （boxagnts/query/）：工作流编排------管理对话循环、自动压缩、上下文管理
Tool 层 （boxagnts/tools/ + boxagnts/wasm-tools/）：工具接口------权限检查、参数验证
Sandbox 层 （boxagnts/wasm-sandbox/）：执行约束------内存限制、网络白名单、超时控制

工作流协调，运行时治理。两者都必要，但只有运行时提供安全保证。

多 Agent 系统使隔离更加重要

BoxAgnts 的 Managed Agent 模式支持并行 Executor，每个在独立沙箱中运行。这提升了专业化和可扩展性，但也放大了风险。

没有适当隔离，恶意输出会传播、上下文污染会扩散、能力升级变得可能、调试变得几乎不可能。BoxAgnts 的应对方案是进程级的思维------每个 Executor 有独立能力、隔离资源、独立上下文、可选 Git worktree 隔离。这完全仿照了现代操作系统中的进程隔离模型。

资源治理

BoxAgnts 通过 WASM 运行时对所有 Executor 实施系统级资源控制：

治理维度	实现
CPU 使用	`wasm_fuel`（指令级燃料） + `wasm_timeout`
内存使用	`wasm_max_memory_size` + `wasm_max_wasm_stack`
网络访问	`allowed_outbound_hosts` + `block_networks` + `block_url`
文件访问	`work_dir` + `map_dirs`（精确目录挂载）
Token 预算	`total_budget_usd`（Managed Agent 模式）
并发控制	`max_concurrent_executors`

没有这些治理的 Agent，自由度越高，破坏潜力越大。

AI Agent 需要运行时工程

AI 行业花了多年在提示词工程、模型工程和工作流工程上。一门新学科正在浮现：运行时工程------关注执行边界、能力系统、资源治理、故障隔离、沙箱化工具和编排安全。

随着 Agent 获得对真实环境的控制权限，运行时工程不再是一种选择，而是基础设施的必须品。

未来看起来更像操作系统

当前许多 AI 产品被设计为应用程序。未来的 AI 基础设施更像操作系统------提供调度、隔离、权限、进程管理和资源治理。

BoxAgnts 的模块架构已经呈现出这种雏形：

arduino 复制代码

操作系统                 BoxAgnts
─────────              ─────────
进程调度      ←→       Query Loop（run_query_loop）
进程隔离      ←→       WASM Sandbox
文件权限      ←→       PermissionLevel + RunOption
网络过滤      ←→       allowed_outbound_hosts + block_networks
内存管理      ←→       wasm_max_memory_size
超时控制      ←→       wasm_timeout + wasm_fuel
任务调度      ←→       Cron Scheduler（gateway/cron/）
状态管理      ←→       Workspace 持久化（workspace/）

这不是巧合------当 AI Agent 成为自主执行单元时，管理它们需要操作系统级的思维。 提示词工程只是用户态的工具，真正的安全保证来自内核态的运行时。

结语

下一代 AI 系统将不由模型智能单独定义，而由执行可靠性定义。当前架构依赖的"模型正确则系统正确"假设在生产环境中不成立。

BoxAgnts 的工程实践表明正确方向是：沙箱化执行、能力隔离、资源治理、确定性边界、安全编排。这些是运行时问题，解决它们将成为 AI 基础设施领域未来十年最重要的工程挑战。

AI Agent 的未来不只是让模型更聪明------而是让执行变得可信。