BoxAgnts 运行时（1）——运行时工程决定 Agent 未来

过去一年里，AI Agent 项目层出不穷------自主编程助手、浏览器自动化工具、多 Agent 编排框架......每周都有新玩家入场。但一个尴尬的事实是：大多数 Agent 在生产环境中仍然频繁失败，而且失败的原因惊人地一致------它们缺乏一个可信的运行时。

行业花费了巨大精力优化模型如何思考，却几乎没有人关注 Agent 如何执行。这种不平衡正在变得越来越危险。

提示词工程解决了简单的那部分

提示词工程在 LLM 早期阶段确实不可或缺。通过思维链、ReAct 循环、规划 Agent 等技术，我们大幅提升了模型的推理质量。

但这些技术也制造了一个危险的错觉：

只要模型足够聪明，系统就足够可靠。

一旦 Agent 开始与真实系统交互------读写文件、执行命令、调用 API、操作数据库------这个假设瞬间崩塌。提示词可以影响推理，但提示词无法强制执行安全边界。

真正的问题始于工具执行

大多数现代 AI Agent 最终都会收敛到同一种架构：

复制代码

LLM → 工具选择 → Python 函数 → Shell / 网络 / 文件系统

模型决定调用哪个工具、传递什么参数、何时停止。在 BoxAgnts 的设计中，我们对此有清醒的认识。看一下 boxagnts/query/src/query.rs 中的查询循环（run_query_loop）------这是整个系统的心脏：

arduino 复制代码

// run_query_loop 的核心逻辑：
// 1. 向 API 发送对话
// 2. 处理流式响应
// 3. 检测工具调用请求并分发执行
// 4. 将工具结果反馈给模型
// 5. 处理自动压缩、token 限制恢复、预算超支等边界条件

这个循环暴露了一个根本问题：模型成为了运行时决策引擎，但这个引擎本身并不可信。 提示注入攻击已经证明 LLM 可以通过网页、文档、工具响应、检索结果被操控。

这意味着 Agent 无法安全地假设自己的推理可信、外部内容可信、工具输出可信。然而许多 Agent 运行时仍然允许无限制执行------这本质上是一个架构矛盾。

AI Agent 需要运行时边界

传统软件基础设施早就假设了应用会失败、进程会崩溃、服务可能被攻破。这就是我们构建容器、虚拟机、进程隔离、能力系统的原因。

有趣的是，AI Agent 正在反向行驶------许多 Agent 以不受限的 shell 访问、不受限的文件系统访问、不受限的网络访问运行。相当于给 LLM 赋予了 root 权限。 这与生产级基础设施完全不相容。

BoxAgnts 在这个问题上的态度很明确。看一下 boxagnts/tools/src/tool.rs 中 Tool trait 的设计：

rust 复制代码

pub trait Tool: Send + Sync {
    fn name(&self) -> &str;
    fn description(&self) -> &str;
    fn permission_level(&self) -> PermissionLevel;
    fn input_schema(&self) -> Value;
    async fn execute(&self, input: Value, ctx: &ToolContext) -> ToolResult;
}

每个工具都有明确的 PermissionLevel------ReadOnly、Write、Execute 或 None。这不是装饰性的标签，而是运行时强制执行的约束。在 filter_tools_for_agent 函数中，我们根据 Agent 的 access level（full / read-only / search-only）动态裁剪可用工具集。

正确的做法不是想办法让模型更可信，而是让运行时对不可信模型具有弹性------这是一个根本的哲学转变。

运行时工程改变了设计哲学

大多数 AI 框架以工作流为中心：提示词串联、Agent 规划、记忆管理、工具注册。这些有用，但忽略了运行时行为。运行时工程引入了一套完全不同的优先级：

工作流中心思维	运行时中心思维
模型如何推理？	执行边界是什么？
哪些提示词提高准确率？	哪些能力被允许？
工具如何串联？	工具如何隔离？
记忆如何持久化？	状态如何被安全治理？

在 BoxAgnts 中，运行时负责能力隔离、权限治理、资源约束、工具生命周期管理、状态持久化和故障隔离。模型只是更大执行系统中的一个组件------这就是可靠基础设施的正确构建方式。

为什么 Rust 对 Agent 基础设施越来越重要

大多数 AI 工具用 Python 构建------这在实验阶段是合理的。但运行时基础设施有不同要求：内存安全、确定性行为、低开销、单二进制部署。

BoxAgnts 选择 Rust 的原因很简单。看 Cargo.toml，整个项目编译为一个静态链接的可执行文件。没有 Python 环境配置、没有 pip install、没有虚拟环境------下载即运行。

css 复制代码

# 启动 BoxAgnts
boxagnts --workspace-dir /path/to/workspace --port 30001

更关键的是，Rust 的所有权语义与能力安全哲学天然契合。在 boxagnts/wasm-sandbox/src/run.rs 中，RunOption 结构体显式定义了每个 WASM 执行实例的边界：

rust 复制代码

pub struct RunOption {
    pub work_dir: Option<String>,          // 文件系统边界
    pub allowed_outbound_hosts: Option<Vec<String>>,  // 网络边界
    pub wasm_timeout: Option<u32>,         // 时间边界
    pub wasm_max_memory_size: Option<u32>, // 内存边界
    pub wasm_fuel: Option<u32>,            // 燃料（指令数）边界
}

每一种资源都被明确约束------这不是巧合，而是 Rust 的所有权模型从语言层面就鼓励的思维模式。

WebAssembly 不仅仅是部署格式

大多数开发者仍然把 WASM 视为前端技术------这已经过时了。WebAssembly 正日益成为一个安全的执行基座。对于 AI Agent，这一点至关重要。

BoxAgnts 中的 WASM 工具不是用 Python 子进程执行的，而是通过 Wasmtime 运行时在沙箱中运行。boxagnts/wasm-tools/src/wasm_tool.rs 展示了这个模式：

rust 复制代码

// WasmTool 将 WASM 模块包装为统一 Tool 接口
let result = boxagnts_wasm_sandbox::run::execute(
    wasm_file,     // WASM 模块路径
    None,          // 调用函数名
    Some(args),    // 参数
    options,       // 运行时约束（内存/网络/超时）
    None,
).await;

所有 WASM 工具------file-read、file-write、file-edit、bash、web-fetch、file-glob------都通过同一个沙箱运行时执行。模型不能直接访问主机系统，运行时是唯一的网关。

多 Agent 系统增加了运行时隔离的需求

BoxAgnts 支持 Managed Agent 模式------Manager 负责规划，多个 Executor 并行执行。在 boxagnts/query/src/managed_orchestrator.rs 中，系统提示词明确描述了这种架构：

复制代码

你是 MANAGER，在 manager-executor 架构中负责规划和推理。
你将所有实现工作委托给 executor agent（使用 Agent 工具）。
每个 executor 在自己的隔离上下文中运行。

没有运行时隔离，一个被攻破的 Agent 可以污染其他 Agent、上下文污染扩散、能力升级难以控制。这就是为什么每个 WASM 工具执行都有独立的 RunOption 实例、独立的内存空间、独立的能力边界。

AI 基础设施的下一层

当前 AI 技术栈高度聚焦于模型层：模型 API → 提示词框架 → Agent 工作流。底层仍然缺失一层：运行时基础设施------沙箱执行、能力管理、资源治理、持久状态、编排控制。

BoxAgnts 的模块架构反映了这一层的重要性：

bash 复制代码

boxagnts/
├── api/          ← 模型 API（OpenAI/Anthropic/Google/...）
├── core/         ← 核心类型和常量
├── gateway/      ← API 网关和 Cron 调度
├── query/        ← Agent 查询循环和编排
├── tools/        ← 工具系统和权限模型
├── wasm-sandbox/ ← WASM 沙箱运行时（Wasmtime）
├── wasm-tools/   ← WASM 工具封装
├── mcp/          ← MCP 协议客户端
└── workspace/    ← 工作空间和配置

注意 wasm-sandbox/ 是整个基础设施的底层------它在 tools 的下方，所有工具执行都必须经过它。这不是事后添加的安全层，而是从一开始就嵌入架构的设计。

结语

AI 行业目前主要将 Agent 视为推理系统------这种框定是不完整的。Agent 是执行系统，而执行系统需要运行时架构。

BoxAgnts 的开源实践表明：AI Agent 的未来不在于让模型更聪明，而在于让执行更安全。当你的 Agent 可以读写文件、执行命令、操纵基础设施时，运行时就不再是实现细节------它是整个系统的基石。

这是一个值得每一位 AI 基础设施开发者认真思考的命题。

BoxAgnts 运行时（1）——运行时工程决定 Agent 未来

提示词工程解决了简单的那部分

真正的问题始于工具执行

AI Agent 需要运行时边界

运行时工程改变了设计哲学

为什么 Rust 对 Agent 基础设施越来越重要

WebAssembly 不仅仅是部署格式

多 Agent 系统增加了运行时隔离的需求

AI 基础设施的下一层

结语

相关资源