龙虾机器人多 Agent · 沙箱隔离架构

一个 Agent 能做的事有限,但把问题拆给一组专业 Agent,每个在自己的沙箱里工作,结果汇总到协调者 —— 这是 OpenClaw Multi-Agent v4.15 的架构。本文把我们在多 Agent 编排、沙箱隔离、权限传递上的工程选择讲清楚:分工、围栏、协作。

一 · 为什么要多 Agent Why Multi-Agent

单 Agent 的瓶颈在于:

• 上下文窗口塞不下所有工具定义 + 所有知识 + 当前任务
• 不同子任务对 prompt 风格、温度、工具集的需求是矛盾的(查资料要准,写文案要有创意)
• 一个错误会污染整个会话,难以回滚

把复杂任务拆成多个专业 Agent,让它们在沙箱里并行工作,协调者做"监工 + 汇总",在工程上就是 分而治之 + 故障隔离。这是 Anthropic、Manus、Devin 共同验证的路径。

二 · 三层拓扑 Orchestrator · Workers · Tools

三 · 沙箱隔离三个梯度 Sandbox Tiers

不是所有任务都需要一台完整 VM。按开销和信任度,我们把沙箱切成三级:

1. Pure function sandbox
   只读、无副作用:文本处理、JSON 计算、正则。直接在主进程跑,微秒级。
2. WASM sandbox
   需要执行用户提交的脚本:Rust/Python-lite 编译到 WASM,跑在 Wasmtime,有内存上限、CPU 限时、没有文件 / 网络。毫秒级启动。
3. Container sandbox
   要真实文件系统、网络、pip install:启动一个 Firecracker microVM 或 gVisor 容器,capability-whitelist + 出站代理。秒级启动,用完即毁。

"够用的最弱沙箱",是安全原则也是性能原则。你不会为了跑一段字符串处理就启动一台 VM。

四 · 权限传递 Capability Propagation

沙箱外的世界(数据库、内部 API、云资源)绝不能对 worker 全开。我们用 capability token 模式:

// 伪代码 · 最小权限传递
cap = orchestrator.issue(
  tenant_id = "corp_A",
  scopes    = ["db:read:orders", "llm:call"],
  ttl       = 300,  // 5 min
  max_cost  = 0.20, // USD
)
worker.run(task, capability=cap)
// worker 只能做 cap 授权的事;超时自动失效

每个 token 指纹会写入 audit log,事后能逐步回放"谁在什么沙箱里调用了什么工具,用了多少 tokens/美元"。这对企业 SaaS 尤其关键 —— 出事能查到责任。

五 · 协调:共享黑板 + 事件总线 Blackboard Pattern

多 Agent 之间不用 RPC 互相调用,而是共享一块"黑板"。每个 worker 把中间结论写到黑板,其它 worker 订阅关心的 key。

• 避免 N×N 的消息复杂度
• 任何 worker 失败,协调者看到黑板上缺了哪块就补
• UI 直接 live-render 黑板,用户看得到每一步思考

六 · 失败模式 Failure Modes

多 Agent 的三大翻车场景,我们用工程手段逐一堵上:

1. 无限委派 · orchestrator 不断下派子任务套娃 → 用 depth 限制 + 预算上限
2. 工具风暴 · worker 疯狂调用 API → token bucket + circuit breaker
3. 冲突写回 · 两个 worker 同时改同一条数据 → 乐观锁 + 事务日志

辉火云 · OpenClaw Multi-Agent · 2026-04-22
Orchestrator · Sandbox · Capability · Blackboard