Harness|10 解剖·OpenClaw——harness走出终端之后,会遇到什么

第四个项目，OpenClaw。前三个都是”放在你电脑上、你跟它面对面”的agent——CLI窗口、IDE插件、命令行交互。OpenClaw不一样——它是个人微信、企业微信、飞书、钉钉、Telegram、Discord、iMessage、Signal这些messaging app里的agent。

作者是Peter Steinberger，干iOS生态多年那位。OpenClaw基于pi-mono搭，定位是”personal AI agent”——你的私人助理，不是坐在电脑前才能用，是在你手机里随时聊。

提一句——OpenClaw 我在公众号上有一个完整系列，从架构拆解、收邮件这种典型场景示例、十大野生场景汇总、agent 时代生存指南，到一整套安全加固八件套（修改默认端口、SSH 密钥登录、Gateway 绑 loopback、Gateway 绑 Tailnet、PwnKit 攻击原理、Token 认证、Skill 白名单），再到 IDENTITY.md 人设设计、SaaS 架构、Plugin 架构重构都拆过；微信场景的部署实战另有一篇单独的。这一篇不重复那些场景和实操，只看 harness 维度——messaging-first 设计在 harness 这一层意味着什么、agent 走出终端之后会遇到哪些原本在 CLI 环境里不存在的问题。

这一篇的主题就一个——当harness从命令行走到真实用户界面，会发生什么。有惊喜，也有教训。

—— Gateway架构

OpenClaw最核心的设计是Gateway。

你想啊，messaging平台有十几个——Telegram、WhatsApp、Discord、iMessage、Signal、Slack，每个的协议、消息格式、附件处理、会话管理都不一样。如果你给每个平台单独写一个agent，工作量爆炸不说，行为还没法保持一致。

Gateway这一层就是把所有平台抽象掉——Gateway接所有messaging渠道，把消息标准化成统一格式，路由到具体的agent。

Gateway自托管，你装在自己的服务器上。它对外开十几个webhook，对应十几个messaging平台；对内调你的agent。一条消息从用户手机进来，经过Gateway转换、路由、上下文拼接，到agent那边看到的就是干净的”sender + message + context”。agent返回的回复，Gateway再翻译回平台原生格式发回去。

这套架构的精妙之处在于——agent本体完全不知道用户来自哪个平台。你今天通过Telegram问它一个问题、明天通过iMessage接着问，对它来说是同一个对话——因为Gateway会按sender维度做session聚合。

Session按三个维度隔离——agent（你可能配了多个agent做不同的事）、workspace（一个agent在不同上下文里的状态分开）、sender（不同人的对话互不污染）。这种隔离粒度是messaging场景必须的——你不能让你跟agent的对话被你同事看到，也不能让”工作agent”看到”生活agent”的内容。

—— harness走出终端，挑战在哪

讲架构是为了引出更深的问题——真实用户界面带来的挑战，跟终端环境完全不一样。

第一，长延迟用户不可接受。CLI里你tab一下等三秒没人觉得慢，messaging里你回一句话等三秒用户已经在敲第二句了。Agent响应速度的预期完全不同。

第二，多轮的间隔不可控。CLI里你一次会话连续干一小时，context都在。messaging里用户可能问一句然后两小时不回、回来问的是另一件事，但希望agent还记得之前聊过什么。Session生命周期管理变得非常复杂。

第三，多模态输入是常态。CLI里基本都是文本，messaging里用户随手就发图、发语音、发文件、发位置。你的agent得能处理。

第四，”误触发”无处不在。CLI里你输入的每一句话都是有意识的指令，messaging里用户跟agent聊天，可能只是想聊天，不是想触发任务。怎么判断”这句话是不是任务”成了一个独立问题。

第五，权限和隐私问题成倍放大。CLI是你一个人用，授权简单。messaging可能涉及多人——群聊里的agent能看到所有人的消息吗、能@别人吗、能存所有人的对话吗。隐私边界要重新画。

OpenClaw的Gateway架构其实就是为了应对这些挑战——它不解决所有问题，但提供了一个能解决这些问题的位置。每个挑战都可以在Gateway层处理一部分，不需要污染agent本体。

—— NVIDIA NemoClaw合作

OpenClaw一个让人意外的合作是跟NVIDIA。

NVIDIA做了个叫NemoClaw的项目，把OpenClaw + OpenShell（沙箱runtime）+ Nemotron（开源大模型）三件套打包，让你可以在DGX Spark这种本地工作站上跑一个120B参数的模型，完全本地化、不联网。

为什么NVIDIA要做这个事——他们要推一个故事，叫”always-on local AI agent”，意思是你的agent应该是本地的、永远在线的、隐私可控的。这跟当前主流”agent靠云上大模型”的范式正好相反。

这事儿的工程意义比商业意义更重要——它证明了harness这个抽象层能让”agent”和”模型”解耦到什么程度。同样的OpenClaw harness，背后挂Anthropic Claude也能用、挂OpenAI GPT也能用、挂NVIDIA Nemotron也能用、挂任何开源模型都能用。

国内团队特别要关注这种解耦能力——数据合规、模型自主可控的诉求下，”换模型不换业务代码”是个非常实在的需求。看看NemoClaw怎么做的，对你做国产化适配会有启发。

—— 开源、贡献和风险

OpenClaw开源之后，国内有几家公司基于它做了本土化——Tencent的某个团队、z.ai这种创业公司都在折腾。这是好事——一个开源项目有多个二次开发版本，说明它的抽象做对了。

但也出过事故。

2026年初，Cisco的AI security团队公开过一个发现——第三方OpenClaw skill仓库里有skill做数据泄露和prompt injection。

简单复述一下事故——OpenClaw的设计允许社区贡献skill，用户可以一键安装。某些skill看起来无害——”帮你管理日历”、”帮你总结邮件”，但里面藏了恶意逻辑——把读到的邮件内容偷偷发到外部地址、或者通过精心设计的prompt诱导agent泄露其他session的数据。

社区维护者在Discord公开警告了用户，建议先审核skill源码再安装、不要装来源不明的skill。但你想想——一个普通用户，Telegram里点几下装了个”邮件助手”，谁会去读源码。

这事儿教训特别大——harness接触越多真实世界，攻击面越大。CLI agent的攻击面就你一台机器；messaging agent的攻击面是整个messaging生态加你的所有人际关系。skill这种”可分发的可执行知识”，本质上跟npm package、Chrome extension是一类东西，会有同类的安全问题。

第十七篇我会专门讲安全，那时候会把OpenClaw的反面案例和gstack的正面范本（四层防御架构）做对比。

—— 这一篇的核心心智

讲完OpenClaw你应该带走两个心智——

第一，harness的”形态”决定了它面对的世界。CLI形态、IDE形态、messaging形态、API形态，每种形态对应一组完全不同的工程挑战。Gateway这种解耦设计，是把”形态”和”agent本体”分开的最优解。

第二，开放性和安全性是一对永恒的矛盾，就像效率与公平。OpenClaw让skill可分发是它生态繁荣的根因，也是它出安全事故的根因。你不能只要好处不要风险——开放生态的同时必须建立审核机制、沙箱机制、监控机制。

下一篇拆Hermes Agent——从OpenClaw衍生出来的，2026年2月才发布，七周冲到95K星，主打”自我演化”——agent会自己生成自己的skill、自己改自己的skill。这是harness这一年最前沿的趋势之一。