最后更新：2026 年 3 月
架构概览
Claw-Stack 使用 Sidecar 模式包装 OpenClaw——一个与主进程共同部署的辅助进程，在不接触上游源码的情况下拦截智能体动作、执行策略、管理记忆并协调共识。
Sidecar 模式
Sidecar 模式是一种部署模型，辅助进程与主应用程序一起运行，在不修改主应用程序的情况下对其进行扩展。在 Claw-Stack 中，sidecar 作为本地服务运行，OpenClaw 智能体在定义的策略关口与其通信——在工具调用之前、在跨智能体交接之前、以及在任何被标记为高风险的操作之前。
这种设计意味着 OpenClaw 的更新可以干净地应用。不需要维护自定义补丁，不存在上游合并冲突的风险，也不会被锁定在特定的 OpenClaw 版本上。
┌─────────────────────────────────────────────────────────┐
│ 用户 / 编排器 │
└──────────────────────┬──────────────────────────────────┘
│ 指令
▼
┌─────────────────────────────────────────────────────────┐
│ Claw-Stack 运行时 │
│ ┌──────────────┐ ┌─────────────┐ ┌───────────────┐ │
│ │ 策略关口 │ │ 记忆总线 │ │ 共识中枢 │ │
│ └──────┬───────┘ └──────┬──────┘ └───────┬───────┘ │
└─────────┼─────────────────┼──────────────────┼──────────┘
│ 已批准 │ 上下文 │ 投票
▼ ▼ ▼
┌─────────────────────────────────────────────────────────┐
│ OpenClaw（未修改的上游） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 智能体 A │ │ 智能体 B │ │ 智能体 C │ ... │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────┘
层级
1. 策略关口
所有智能体的每个工具调用在执行前都要经过策略关口。关口检查智能体声明的策略，根据白名单验证调用，然后允许、阻止或将操作上报到人工审批队列。
2. 记忆总线
记忆总线位于智能体和其存储层之间。当智能体读写记忆时，总线将请求路由到相应的层级——MEMORY.md 用于即时事实，结构化主题文件用于有组织的知识，向量索引用于语义搜索。
3. 共识中枢
在执行任何被策略归类为高风险的操作之前，共识中枢收集所有活跃智能体的投票。默认阈值为 2/3 同意。如果未达成共识，操作将上报给人工操作员，而不是直接被阻止。
为何不直接修改 OpenClaw？
Fork 或修补 OpenClaw 会带来随着每次上游发布而增长的维护负担。Sidecar 模式让 Claw-Stack 可以独立演进——添加新的记忆后端、新的共识算法或新的策略运算符——而无需触及智能体执行引擎。这也使 Claw-Stack 未来能适用于其他智能体运行时；sidecar 接口并非 OpenClaw 专用。
常见问题
sidecar 会给每个智能体操作增加延迟吗？
会，但开销很小。策略关口检查是对编译后策略 AST 的进程内查找——在现代硬件上通常不到 1 毫秒。记忆读取根据层级增加 2–10 毫秒。共识投票增加的延迟最多，但仅适用于明确标记的高风险操作。
如果 Claw-Stack 运行时崩溃会怎样？
配置为"失败关闭"模式的智能体在运行时不可达时将停止执行工具调用——这是安全设计。"失败开放"模式的智能体继续运行但没有策略执行。推荐的生产设置是所有智能体都使用失败关闭模式。
Claw-Stack 可以跨多台机器分布式运行吗？
当前架构针对单主机部署。共识和记忆层设计为与 OpenClaw 实例共同部署。多主机支持在路线图上，但尚未实现。
Authors: Qiushi Wu & Orange 🍊