OpenClaw架构深度剖析：从Gateway到Agent Runtime，拆解这个GitHub史上增长最快的AI Agent框架

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

我花了两周时间读了OpenClaw的核心源码，跑了几组性能测试，也对比了同类型的开源Agent框架（LangChain Agent、AutoGPT、CrewAI等）。这篇文章把我的理解整理出来，重点聊三件事：

OpenClaw的整体架构设计思路是什么，为什么这么设计
核心模块的实现细节，包括Gateway、Agent Runtime、记忆系统、工具调用链
跟同类框架比，它的技术选型有什么优劣
文章会比较长，但尽量每个部分都能独立阅读。如果你只关心某个模块，可以直接跳过去。

整体上看，它分为四层：

这个选择决定了OpenClaw的产品形态：它不是一个你需要打开网页去用的工具，而是嵌入到你已有的通信流里。你在飞书里跟它说话，它就在飞书里回你。

从架构角度看，消息驱动带来两个好处：

这也是它能在100天内爆发的关键原因之一：安装摩擦极低。

这个抽象做得不错的地方在于 sendStream 方法——它考虑到了LLM的流式输出特性。大多数平台的消息API不原生支持流式发送，所以各Channel实现里需要自行处理buffer和分段发送的逻辑。比如飞书的实现是先发一条消息，然后通过消息更新API不断追加内容，模拟打字机效果。

 ┌─────────┐

GPT plus 代充 只需 145 ┌──────→│ IDLE │←────────┐ │ └────┬────┘ │ │ │ 收到消息 │ 超时/结束 │ ▼ │ │ ┌─────────┐ │ │ │PROCESSING│────────┤ │ └────┬────┘ │ │ │ 需要工具调用 │ │ ▼ │ │ ┌─────────┐ │ └───────│TOOL_EXEC│─────────┘ └─────────┘

三个状态：

这避免了并发请求导致的上下文混乱问题。

async acquire(conversationId: string): Promise

if (this.currentConcurrent >= this.maxConcurrent) { return false; // 并发上限，排队等待 }

bucket.tokens–; this.currentConcurrent++; return true;

}

OpenClaw的策略是：

先保证系统提示词和用户消息（不可压缩）
然后分配最近对话历史（按轮次从近到远，超出预算的截断）
剩余预算分给记忆检索和Skill上下文
工具定义放最后，如果预算实在不够就裁剪工具数量
// 简化后的Token预算分配逻辑
function allocateTokenBudget(maxTokens: number): TokenBudget {
const systemPromptReserve = 2000; // 系统提示词固定预留
const userMessageReserve = 1000; // 当前用户消息预留
const toolDefReserve = 3000; // 工具定义预留

const remaining = maxTokens - systemPromptReserve - userMessageReserve - toolDefReserve;

权限检查：每个工具有一个权限等级（safe / moderate / dangerous），用户在config.yaml中配置哪些等级需要人工确认。默认dangerous级别的工具（如文件删除、系统命令）每次执行前都会请求用户授权。

沙箱隔离：系统命令类工具通过子进程执行，配合文件路径白名单和命令黑名单做基础隔离。这里的沙箱不是内核级的（不像Docker那样做namespace隔离），更接近于一个应用层的访问控制。

超时与熔断：每个工具调用有独立的超时时间（默认30秒），连续3次超时后该工具会被临时禁用，防止Agent陷入死循环。

return { error: '用户拒绝了此操作' };

} }

// 2. 沙箱执行 const sandbox = new Sandbox({ allowedPaths: context.config.security.allowedPaths, blockedCommands: context.config.security.blockedCommands, timeout: tool.timeout || 30000 });

try ; } catch (err) 已临时禁用（连续失败${this.maxFailures}次）}; } return { error: err.message }; }

NVIDIA的NemoClaw选择了另一条路，用OpenShell运行时提供内核级隔离。从安全角度看这是正确的方向，但也增加了部署复杂度。

用户提出的主要需求（1-3句话）
最终的解决方案或结论
用户透露的偏好或个人信息（如有）
未解决的遗留问题（如有）

GPT plus 代充 只需 145输出JSON格式。

这个设计的巧妙之处在于用AI来管理AI的记忆——不需要人工打标签或分类，模型自己判断什么值得记住。

性能数据：我在自己的MacBook Pro（M3, 16GB内存）上测试，1万条记忆片段的检索延迟在50ms以内，内存占用约200MB。对个人用户来说完全够用，但如果记忆条目到了10万级别，可能需要考虑分片或者换用更高效的索引方案。

打开 memory/ 目录，里面就是一堆Markdown文件，你可以随时查看Agent”记住了什么”，也可以直接编辑或删除。这跟那些把记忆塞进数据库黑盒里的方案形成了鲜明对比。

这个设计带来了真实的信任感——用户不需要猜测AI是否在背后存了什么奇怪的东西。

OpenClaw面向的是终端用户，目标是”装上就能用”。它牺牲了灵活性，换来了极低的上手成本。两者面向的人群其实不太重叠——如果你在做一个需要深度定制Agent逻辑的产品，LangChain更合适；如果你只是想有个AI助手帮你干活，OpenClaw更直接。

OpenClaw更务实，它本质上是一个人机协作系统：用户给指令，Agent执行，遇到不确定的情况回来问用户。这种设计在当前模型能力下更可靠。

延迟的大头在模型API调用，本地处理（上下文组装、记忆检索、工具执行）加起来通常不超过200ms
内存占用可控，基线约180MB，每增加一个并发会话大约增加60-80MB
多工具链式调用的延迟是线性叠加的，因为每次工具调用的结果需要注入上下文再调用模型，无法并行
P99延迟波动大，主要受网络质量和API服务端负载影响
与AutoGPT的简单对比
同样的测试环境下，用AutoGPT跑相同的”三步工具链调用”任务，平均延迟在25-40秒之间。主要原因是AutoGPT的自主规划阶段会做更多轮的模型调用，而OpenClaw是用户直接给指令、Agent直接执行，少了规划的开销。

不过这不是一个公平的对比——两者的设计目标不同。AutoGPT试图做的事情更难，延迟高是为完全自主的能力买单。

架构层面，OpenClaw做了很多正确的取舍。消息驱动架构、本地优先策略、三层记忆模型——这些选择不一定是技术上最优的，但在”个人AI助手”这个产品定位下是最合理的。它没有过度工程化，保持了难得的简洁。

工程质量层面，代码可读性不错，核心模块的抽象清晰，但测试覆盖率偏低（我目测核心模块的单测覆盖率在40-50%左右）。考虑到项目的爆发式增长速度，这可以理解，但长期来看需要补上。

安全层面，应用层沙箱确实是当前最大的技术债。NemoClaw的内核级方案方向正确，但引入了额外的部署复杂度，跟OpenClaw”简单即正义”的初心有些矛盾。这个矛盾怎么解，是项目后续发展的关键问题之一。

可持续性层面，创始人离开后项目交给基金会运营，这在开源界不罕见。但OpenClaw的代码库还处于快速演进期，需要一个强有力的技术委员会来把控方向。目前这方面的信息还不够透明。

总的来说，OpenClaw是一个在正确的时间、用正确的方式解决了一个真实问题的项目。它的架构不花哨但管用，代码不完美但清晰。作为一个技术人，我尊重这种”把简单的事情做到位”的工程哲学。

至于它能火多久、生态能做多大，那就不只是技术能决定的了。

以上是个人阅读源码后的理解，可能有不准确的地方，欢迎在评论区指正。

OpenClaw架构深度剖析：从Gateway到Agent Runtime，拆解这个GitHub史上增长最快的AI Agent框架

相关推荐