跳转至

EdgeClaw — 端云两栖龙虾框架

Ch01.663 EdgeClaw — 端云两栖龙虾框架

📊 Level ⭐⭐ | 4.8KB | entities/edgeclaw-openbmb.md

EdgeClaw

面壁智能联合清华大学、OpenBMB社区开源的Agent框架，"端云两栖"架构。

基本信息

  • 开源地址: https://github.com/Openbmb/edgeclaw
  • 发布: 2026年3月19日
  • 配套硬件: EdgeClaw Box（开箱即用）
  • 核心模型: MiniCPM系列（端侧）+ 云端大模型

核心设计

隐私路由（Privacy Routing）：S1/S2/S3三级数据分类，决定本地还是云端处理。 本地引擎：MiniCPM系列，处理绝密数据和日常琐事，零Token消耗，断网可用。

深度分析

端云协同的本质是任务分发而非模型集成。EdgeClaw的S1/S2/S3路由机制，本质上是将AI任务按数据敏感度解耦为三个平面：S1公开数据平面（云端智商）、S2脱敏数据平面（混合处理）、S3绝密数据平面（本地忠诚）。这种设计避免了"用一个模型解决所有问题"的工程陷阱，而是让不同能力的模型各司其职。 隐私路由的商业护城河在于数据主权确认。在FA投研、冷库盘点等场景中，用户最大的顾虑并非AI能力不足，而是"数据出去了回不来"。S3强制本地物理隔离的价值，不仅是技术合规，更是心理契约——它让企业愿意把最核心的BP、财务数据交给系统，因为数据主权从未转移。 MiniCPM的端侧定位：不是替代云端，而是承接被云端拒绝的任务。大量文本清洗、信息抽取等高频琐事，如果全部走云端API，Token成本会快速侵蚀ROI。MiniCPM承接这些"不值得花大钱但必须做"的任务，实现零Token消耗的同时，也降低了云端模型的调用负载。这种"边缘过滤"架构，在规模化后会形成显著的成本优势。 开源策略的双重意图：OpenBMB社区的开源姿态，一方面吸引开发者生态构建工具链，另一方面通过硬件（EdgeClaw Box）锁定高价值变现路径。开源框架本身不赚钱，但配套硬件和企业级支持服务可以。 "端云两栖"修正了Agent架构的一个根本假设：过去行业默认"本地模型=弱模型"，因此本地只能处理简单任务，云端处理复杂任务。但EdgeClaw证明，本地模型的"弱"是场景错配而非能力上限——当任务匹配时（如S3绝密信息的即时处理），本地模型的表现反而比云端更可靠。

实践启示

场景选择优先于技术选型。在决定是否采用EdgeClaw架构前，先盘点组织内部的数据敏感度分布：如果S3级绝密数据占比高（如法律、金融、医疗），端云两栖的ROI会快速显现；如果主要是S1公开数据，直接调用云端API的复杂度更低。 路由策略需要动态校准。S1/S2/S3的边界并非静态——随着业务发展，原本属于S1的公开数据可能因为合作方要求变成S2。Agent框架需要支持路由策略的热更新，而非硬编码分类逻辑。 端侧模型的选型应偏向"够用就好"。MiniCPM的成功印证了端侧模型不需要SOTA，只需要在小场景上做到足够好。追求更大的端侧模型反而会增加硬件成本和推理延迟，抵消零Token的优势。 硬件配套是可信度的锚点。EdgeClaw Box的存在，让企业客户有了一个"看得见摸得着"的数据安全承诺。纯软件方案在企业采购中往往面临"出了事谁负责"的质疑，硬件产品即使不赚钱，也是信任的实体化锚点。 关注混合场景的路由自动化程度。当前EdgeClaw的路由依赖显式的数据分类，但在实际部署中，用户并不愿意手动标记每一份数据的敏感等级。未来的进化方向是：让模型自己判断数据归属哪个等级（S0/S1/S2/S3），人类只需处理边界case。

与本文相关