EdgeClaw:安全高效的端云协同智能体框架,解决OpenClaw的隐私和成本问题

面壁智能开源EdgeClaw,解决OpenClaw数据安全和token成本问题。三级安全协同+性价比感知协同,安全又省钱!

原文标题:面壁智能发布 EdgeClaw 智能体框架,主打安全和省钱

原文作者:AI前线

冷月清谈:

面壁智能联合发布并开源EdgeClaw,一个安全高效的端云协同智能体框架,旨在解决OpenClaw使用过程中数据泄露和token成本过高的问题。EdgeClaw通过三级安全协同机制实现本地数据加密和安全隔离,并利用性价比感知协同机制灵活调用不同价格的模型,在保证安全的前提下优化成本。该框架以OpenClaw插件形式加载,开发者无需修改业务逻辑即可实现端云协同隐私保护和性价比节省。EdgeClaw的未来规划包括优化Router、Memory、SkillHub和UI,以支持更广泛的端侧设备部署和更高效的本地化任务处理。

怜星夜思:

1、EdgeClaw提到的“双轨记忆”机制,云端只能看到脱敏后的对话历史,本地模型才能访问完整信息。这个设计在实际应用中,会不会影响智能体在云端的长期记忆和学习能力?如果云端模型无法访问原始数据,它还能否进行有效的知识更新和推理?
2、EdgeClaw的性价比感知协同,用本地小模型做LLM-as-Judge,这个思路很棒!大家觉得这种方式在实际应用中,判断的准确率能达到多少?如果判断错误,把复杂度高的任务分配给了低价模型,会造成什么影响?
3、EdgeClaw未来要构建SkillHub,整合端侧智能体服务关注的特定Skill。大家觉得哪些Skill是端侧智能体最需要的?或者说,哪些类型的任务在端侧处理会更有优势?

原文内容

作者 | OpenBMB

当前大火的 OpenClaw,让越来越多开发者和个人用户意识到个人智能体发挥的巨大作用。然而在实际使用过程中,有两个问题被使用者广泛提及:一是用户个人数据会被 OpenClaw 上传给云端大模型,造成一定程度的个人数据泄露;另一方面是 OpenClaw 执行过程中拼接的超长上下文带来 token 浪费,造成了较高的使用成本。

3月19日,我们正式发布并开源由 THUNLP,中国人民大学,AI9Stars,面壁智能 与 OpenBMB 基于 OpenClaw 联合开发的安全高效端云协同智能体框架 EdgeClaw,通过三级安全协同性价比感知协同机制,解决 OpenClaw 使用过程中本地数据泄漏、token 花费成本高等问题。通过部署在 DGXSpark、MacMini 等桌面端设备上,给使用者带来安全高效的本地龙虾使用体验。

➤  GitHub 链接🔗 https://github.com/Openbmb/EdgeClaw

EdgeClaw:安全高效端云协同智能体

当下 AI Agent 架构中,端侧长期被忽视——所有数据与任务一股脑涌向云端,隐私泄露与算力浪费由此而生。

EdgeClaw 通过 三级安全协同机制 实现本地数据加密与安全隔离,通过 性价比感知协同机制 灵活调用不同费用模型,实现简单任务使用低价模型、复杂任务调用高阶模型。安全协同和性价比感知协同运行在 同一管线 中,通过权重和两阶段短路策略协同工作。

EdgeClaw 主体功能实现以 OpenClaw 插件形式加载,配合端云协同的智能转发能力,开发者无需修改业务逻辑,即可在 EdgeClaw 中实现“公开数据上云、敏感数据脱敏、私密数据落地”的无感端云协同隐私保护与性价比节省。

三级安全协同机制

EdgeClaw 的一个核心创新是自研三级安全协同机制:通过在 OpenClaw 执行流程中植入 Hook,EdgeClaw 能自动将每一条用户消息、工具调用参数和 Agent 输出按敏感程度分为三级:

  • S1:默认模式(信息将在云端处理),可直接用云端模型处理。

  • S2 脱敏模式(信息将在脱敏后处理),自动脱敏,将企业的敏感信息模糊化(如把「王小二」变成「员工 A」)后,再发往云端。

  • S3:安全模式(信息将强制在本地处理),物理隔离,敏感数据完全留在本地,由预装的 MiniCPM 系列模型离线处理。

对于隐私文件,EdgeClaw 识别为 S3 等级并由本地模型离线处理

在三级分类基础上,EdgeClaw 使用了基于规则检测器和本地 LLM 检测器的双检测引擎,两个引擎可组合叠加,通过 checkpoints 配置按场景灵活启用。

与此同时,EdgeClaw 还维护了一套「双轨记忆」机制——云端模型只能看到脱敏后的对话历史,只有本地模型才能访问包含完整信息的记忆内容,从根本上杜绝了隐私数据通过上下文窗口泄露给第三方云服务的风险。

性价比感知协同机制

在典型的 AI 编程助手工作流中,大部分请求是查文件、看代码、简单问答——用最贵的模型处理这些任务会造成大量浪费。性价比感知协同用本地小模型做 LLM-as-Judge,把请求按复杂度分级路由到不同价位的云端模型。

表 路由模型配置示例

实际测试中,以典型编程助手工作流为例,性价比感知协同机制可将 60–80% 的请求路由到更便宜的模型。

可组合路由管线

安全协同和性价比感知协同运行在同一管线中,通过权重和两阶段短路策略协同工作。管线设计遵循安全优先:安全路由器高权重先跑,有敏感数据就直接短路处理,不浪费时间再判断复杂度。只有安全通过(S1)后,才启动性价比感知协同优化成本。

未来规划

EdgeClaw 将持续迭代,进化为支持更广泛端侧设备部署的软件系统。未来的开发计划包含如下四个部分:

  • EdgeClaw Router。聚焦安全高效端云协同,结合更多端侧硬件与模型,实现更灵活多样的本地模型选择。

  • EdgeClaw Memory。优化 OpenClaw 记忆,实现面向任务的记忆机制,实现智能体真正配合用户执行长期复杂任务的能力。

  • EdgeClaw SkillHub。构建聚焦支持本地化任务的 Skill Hub,整合端侧智能体服务关注的特定 Skill 并内置高频使用 Skill。对于主流的基于 AI 模型实现的 Skill 实现端侧模型替代,进一步提高使用效率。

  • EdgeClaw UI。支持更加端侧场景友好的前端 UI 设计,增加本地 GPU 使用率、本地 token 使用量等端侧用户关注的性能监控指标。

EdgeClaw 聚焦构建安全高效的端云协同智能体,未来将继续保持开源。欢迎广大开发者与行业伙伴一起参与贡献,共同打造“多、快、好、省”的端侧智能体解决方案。

会议推荐

OpenClaw 出圈,“养虾”潮狂热,开年 Agentic AI 这把火烧得不可谓不旺。在这一热潮下,自托管 Agent 形态迅速普及:多入口对话、持久记忆、Skills 工具链带来强大生产力。但这背后也暴露了工程化落地的真实难题——权限边界与隔离运行、Skills 供应链安全、可观测与可追溯、记忆分层与跨场景污染、以及如何把 Agent 纳入团队研发 / 运维流程并形成稳定收益。

针对这一系列挑战,在 4 月 16-18 日即将举办的 QCon 北京站上,我们特别策划了「OpenClaw 生态实践」专题,将聚焦一线实践与踩坑复盘,分享企业如何构建私有 Skills、制定安全护栏、搭建审计与回放机制、建立质量 / 效率指标体系,最终把自托管 Agent 从可用的 Demo 升级为可靠的生产系统。

今日荐文


图片
你也「在看」吗?👇

我觉得可以考虑类似负载均衡的策略,如果本地算力不足,可以动态地将任务迁移到云端处理,同时对数据进行加密和脱敏,这样既保证了效率,又兼顾了安全。

其实价格只是考量的一部分,如果能把响应时间也考虑进来可能更完美。比如用户愿意多花一点钱,换取更快的响应,或者反过来,不着急的话就用更便宜的模型。

这个问题问到了点子上!EdgeClaw的三级安全机制,确实需要在安全和效率之间找到平衡。

* **S1模式(云端处理)*理论上速度最快,但隐私风险最高。
**S2模式(脱敏处理)*在一定程度上保护了隐私,但脱敏操作本身可能会引入误差,影响处理精度。
**S3模式(本地处理)**安全性最高,但本地算力肯定不如云端,尤其是在处理复杂任务时,速度可能会成为瓶颈。MiniCPM系列模型的能力是关键,如果模型足够强大,本地处理的体验也能得到保证。

个人觉得,实际应用中需要根据具体场景灵活调整三种模式的比例,找到一个最佳的平衡点。比如,对于对实时性要求不高的任务,可以优先选择S3模式;而对于需要快速响应的任务,则可以选择S1或S2模式。

安全问题确实需要重视。可以考虑引入代码审计、沙箱隔离等机制,对Skill进行安全检测,确保其不会对用户数据造成损害。同时,可以建立用户评价体系,让用户对Skill进行评分和评论,帮助其他用户选择可靠的Skill。

这个问题让我想到了A/B测试。EdgeClaw是否可以考虑引入A/B测试机制,将一部分请求同时分配给高价模型和低价模型,比较它们的处理结果,从而评估小模型的判断准确性?通过不断地A/B测试,可以持续优化小模型的性能,提高性价比感知协同机制的效率。

我觉得这个问题有点像经典的“不可能三角”,安全、成本和功能往往难以兼得。EdgeClaw的思路是尽量找到一个平衡点,但具体到每个用户,可能都需要根据自己的实际情况进行调整。比如,对于安全性要求极高的场景,可以牺牲一些功能性;而对于一些不太敏感的应用,可以选择更高的效率。关键在于给用户提供足够的灵活性和选择权。

我猜测,EdgeClaw 可能会采用一些置信度或阈值的方法来提高判断的准确性。比如,只有当小模型对任务复杂度的判断结果达到一定的置信度时,才会将其分配给低价模型;否则,默认交给高价模型处理。另外,也可以考虑引入一些校正机制,比如定期抽查小模型的判断结果,如果发现错误率过高,就及时调整模型或参数。