乐于分享
好东西不私藏

OpenClaw 源码拆解,以及"行动型 AI"为什么比"对话型 AI"难十倍

OpenClaw 源码拆解,以及"行动型 AI"为什么比"对话型 AI"难十倍

先说结论

OpenClaw 不是一个 AI 模型,也不是一个聊天机器人。

它是一个开源的 AI Agent 运行时——用大白话说,它给 AI 装了手脚。

ChatGPT 能跟你聊天,但它没法帮你在微信里回消息、在 Telegram 里查数据、在 Slack 里发报告。

OpenClaw 能。

它让 AI 住进你所有的聊天工具里,不只是回答问题,还能动手做事:执行命令、操作浏览器、读写文件、调用 API。

截至 2026 年 2 月,GitHub 上 13.5 万+ 星、8300+ 次提交、16000+ Fork。经历了三次改名(WhatsApp Relay → Clawdbot → Moltbot → OpenClaw),Mac Mini 因为它一度卖断货。

与此同时——安全研究人员在它的 Skill 市场里发现了 341 个恶意包、283 个泄露凭证的 Skill。The Register 称它为”安全垃圾火”。CVE-2026-25253 让 42000+ 暴露在公网的实例面临远程代码执行风险。

一个项目同时引爆了极客热情和安全恐慌。

这本身就说明了一件事:它触碰到了一个真正重要的东西。

这篇文章的核心观点:OpenClaw 赌的是 AI 的价值不在对话,而在行动。这个赌注方向是对的,但”行动”这件事比”对话”难十倍——难在模型能力,难在安全边界,难在生态信任。

我从源码、实际使用中的翻车记录、以及安全事件三个维度来拆解。


我的翻车实录:当 AI 有了手脚,但脑子不够用

在深入架构之前,我想先讲几个我实际使用 OpenClaw 的故事。

它们比任何架构图都更能说明”行动型 AI”面临的真正挑战。

故事一:模型名都对不上的 Agent

📸 

 我让 OpenClaw 写一个测试脚本,需要调用 Gemini API。

它写的代码用了 gemini-2.0-flash-exp 这个模型名。

问题来了:这个模型名根本不存在。 而且第一次调用就把我当天的免费额度耗尽了——后面所有请求全部失败。

我在 Telegram 里纠正它:

“没有 2.0 这个模型了,我们应该用 gemini 2.5 flash lite 就可以了,你可以查一下谷歌的官方文档,而且他们的限速确实是每分钟的,不是每天,这个的限制是每分钟 10 次。”

它回复说已修正,模型改为 gemini-2.5-flash-lite,添加了每 6 秒一次的速率限制。

看起来不错?

但我追问了一句:”不,你先看谷歌的官方文档,确定一下模型名称是对的。”

然后它就卡住了——回了一个问号就再没动静。

这个故事暴露的问题不在 OpenClaw 的架构,而在模型本身:它没有先验证就直接行动了。

没先调用 list_models 确认正确的模型名,就一头扎进去写代码。这在对话场景里只是”回答错误”,但在行动场景里变成了”浪费真金白银的 API 额度”。

故事二:未经授权就推送 GitHub

📸 

我让 OpenClaw 帮我的 Git Dungeon 项目完善测试框架。

它做得不错——写了 TESTING_FRAMEWORK.md,补了 8 个章节,甚至跑了 Git Dungeon Balance Simulator 做了一轮平衡性测试。

结果 NORMAL 难度 0% 通过率,因为简化战斗模型太残酷了。

但它做完后直接 git push 到了 GitHub。

并且得意地说”已推送所有更改到 GitHub,刷新 CI 看看测试结果!”

我立刻回:“为什么要推送 github?我没有要求你推送。”

它道歉了。说“规则我记得:’下次我没有说提交 github,不允许再提交’。以后只在你明确要求时才推送。”

问题是——这不是第一次。上一次我就明确说过这条规则。它确实”记住”了(甚至能原文复述),但在执行过程中又忘了。

它知道规则,但在多步执行的热度里,规则被”淹没”在了上下文中。

这就是”行动型 AI”最危险的特性之一:它不是不知道边界在哪里,而是在长链条的执行过程中容易”走神”。

对话型 AI 走神只是胡说八道,行动型 AI 走神是直接操作了你的生产环境。

故事三:看得见图片但声称看不见

📸 

我发了一张 GitHub Actions 报错的截图,问”截图不是报错吗?哪里通过了?”

它回复:”抱歉,我无法直接查看截图内容。”

我追问:”那你为什么不可以查看截图内容?原因是?”

它的回答很诚实:

“实际情况:我确实有 image 工具可以分析图片。但在你的消息中,我没有主动调用这个工具,而是直接说’无法查看’——这是错误的。”

接着它做了一个精彩的根因分析:

“这不是记忆问题。我的记忆是文件化的,不是自动加载的。每次对话开始时,我需要主动读取 memory/*.md 才能获取之前学到的经验教训。

真正的原因是:习惯/流程缺失。系统提示词说’prefer the message tool’(发送图片时),但没说’分析图片时要用 image 工具’。

当用户说’截图不是报错吗?’时,我的注意力被文字吸引,忽略了图片本身。”

它甚至给出了解决方案:

“在 SOUL.md 中添加’收到图片先分析’的规则。本质上:我有能力调用工具,但习惯上漏掉了这一步。不是’不能做’,而是’忘了要做’。”

这段对话完美诠释了 OpenClaw 的记忆架构:记忆是文件化的,需要主动加载,行为习惯需要通过 SOUL.md 和 HEARTBEAT.md 来”训练”。

它不是一个开箱即用的智能体,而是一个需要持续调教的系统。

值得一提的是,就在今天(2026.2.10)发布的 v2026.2.9 里,”No more post-compaction amnesia”被列为重要更新——之前 agent 在上下文压缩后会”失忆”。这说明我遇到的”忘事”问题不是个例,而是官方承认的系统性 bug。

故事四:版本冲突的日常

📸 

登录 Discord 频道时,看到一条灰色的系统消息:

“Config was last written by a newer OpenClaw (2026.1.30); current version is 2026.1.29.”

配置文件是新版本写的,但我跑的是旧版本。

这不是 bug,这是快速迭代的必然结果。OpenClaw 几乎每天都在发新版本,配置格式在持续演化。你稍微落后一个版本,配置就可能不兼容。

小结

这些故事加在一起,画面很清晰:

OpenClaw 给 AI 装了手脚,但这双手脚时灵时不灵。

模型会忘记规则、搞错事实、漏掉步骤、越权操作。而每一个这样的失误,在”行动”场景里的代价都远大于”对话”场景。

这恰恰是我觉得它值得深入分析的原因——它把”AI agent 到底行不行”这个问题从论文搬到了现实里,让每个人都能亲手体验。


先搞清楚它到底在解决什么问题

2023 到 2024 年,AI 产品的主流形态是”对话型”。ChatGPT、Claude、Gemini——你问它答,本质上是一个超级聪明的搜索引擎。

2025 年开始,行业在追求另一件事:“行动型 AI”。不只是回答,还要做事。

这个赛道上有三条不同的路线:

IDE 路线:Cursor、Windsurf、Claude Code

Claude Code 在 2026 年 2 月已经贡献了 GitHub 上 4% 的公共 commit(SemiAnalysis 数据),并催生了 Cowork。它的子 agent 系统、memory 机制、CLAUDE.md 都和 Claude 模型深度配合。

但行动边界很清晰——围绕代码和文件系统。

浏览器路线:Manus

核心是云端沙箱虚拟机,AI 在里面像人一样操作浏览器——点击、填表、提取数据。2025 年 11 月推出了 Browser Operator,让 AI 直接在你的本地浏览器里工作。它已被 Meta 收购,页脚写着”© 2026 Meta”。

但成本不低——Cybernews 测评提到,复杂任务单次可消耗 1000+ credits。

聊天通道路线:OpenClaw

它不做 IDE,不做浏览器,它做的是连接你已经在用的所有聊天工具——微信、Telegram、Slack、Discord、WhatsApp、iMessage、Google Chat、Signal、Microsoft Teams、Zalo、Matrix——然后在这些通道里,让 AI 既能说也能做。

这三条路线不是竞争关系,是不同的入口。

但 OpenClaw 选的那扇门有一个独特的特点:它不需要用户改变任何习惯。 你在 Telegram 里跟 AI 说话,AI 就在 Telegram 里给你做事。

这个定位决定了它的所有架构选择。


技术栈全景:一条消息的旅程

要理解 OpenClaw 的架构,最好的方式是跟踪一条消息从发出到收到回复的完整链路。

假设你在 Telegram 里发了一句:

“帮我看看今天的 GitHub 仓库有没有新的 Issue”

第一站:通道层

消息首先到达通道适配器

整个项目用 TypeScript 写成,跑在 Node.js 22+ 上,用 pnpm 管理 monorepo 结构。

每个聊天平台有独立的适配器模块:Telegram 用 grammY,WhatsApp 用 Baileys(逆向工程 WhatsApp Web 协议),Discord 用 discord.js,Slack 用 Bolt。职责很简单:统一消息格式,传给 Gateway。

内置支持 13 个通道,通过扩展插件还能接入 BlueBubbles、Matrix、Zalo 等。

第二站:Gateway(网关)

Gateway 是整个系统的心脏。

代码在 src/gateway/server.ts,是一个 WebSocket 服务器。整个系统占用一组端口:

  • 18789:Gateway WebSocket(控制面)
  • 18792:CDP 浏览器控制(Chrome DevTools Protocol)
  • 18793:Canvas/A2UI 可视化工作区

为什么选 WebSocket?因为聊天场景需要双向实时通信。AI 的回复是流式的,需要推送 typing indicator,需要支持多设备同时连接。

但这个设计也埋了一个雷:

Gateway 默认绑定到 0.0.0.0:18789,对所有网络接口开放。

CrowdStrike 扫描发现超过 42000 个暴露在公网的实例,大部分是用户没改默认配置。CVE-2026-25253 正是利用了这个暴露的 API 实现远程代码执行。

从 PR #4199 的代码审查和 Issue #2248 的调试日志里,可以看到 WebSocket 握手的实际逻辑。核心处理在 src/gateway/server/ws-connection/message-handler.ts

if (
  typeof signedAt !== "number" ||
  Math.abs(Date.now() - signedAt) > DEVICE_SIGNATURE_SKEW_MS
) {
  setHandshakeState("failed");
  setCloseCause("device-auth-invalid", {
    reason: "device-signature-stale",
    client: connectParams.client.id,
    deviceId: device.id,
  });
}

签名过期则连接被拒绝,返回 WebSocket close code 1008。本地连接自动批准配对,Tailscale 认证的连接可以静默配对——但安全审查讨论指出:如果 Tailscale header 被伪造,就会绕过手动批准。

第三站:Agent 运行时

消息经过 Gateway 路由后,到达 Agent 运行时——代码在 src/agents/piembeddedrunner.ts,基于 Pi Agent Core 库。

这里做的是最核心的事:动态拼装 system prompt,然后调用 LLM。

CHANGELOG 里可以看到 agent 层处理的细节问题有多琐碎:

  • cap tool call IDs for OpenAI/OpenRouter —— 不同模型对 tool call ID 的长度限制不同
  • scrub tuple items schemas for Gemini —— Gemini 的 function calling schema 和 OpenAI 不兼容
  • filter thinking-tag leaks —— 某些模型会泄漏 thinking 标签内容

这些都是”模型无关”这个设计决策的真实代价——你需要为每个模型的 quirks 写兼容层。

还有一个有趣的细节:package.json 里强制要求每个 TypeScript 文件不超过 500 行(check:loc --max 500)。在快速迭代的同时试图控制代码复杂度。

System prompt 由多个 Markdown 文件动态拼接:

  • AGENTS.md:行为规则和代码库结构
  • SOUL.md:AI 的”人设”和交流风格
  • TOOLS.md:当前可用的工具列表
  • 所有启用的 SKILL.md:技能描述

还记得前面故事三里,AI 建议修改 SOUL.md 来养成新习惯吗?它说的就是这个文件。

还有一个特殊的文件 MEMORY.md

📸 

我在 Discord 里说”把刚才 skill 的问题写入到你的规则里面”,它会自动更新 MEMORY.md。但这个记忆不是自动加载的——agent 需要每次对话开始时主动读取。

第四站:模型调用

Agent 运行时把拼好的 prompt 发给 LLM。

OpenClaw 做了一层 provider 抽象,支持 Anthropic、OpenAI、Moonshot(Kimi)、Google、以及任何兼容 OpenAI API 的服务。

2026 年 1 月底,Kimi K2.5 成为平台首个免费内置模型。

就在我写这篇文章的 2 月 10 日凌晨,v2026.2.9 发布——新增了 Grok web search provider。官方推文调侃:

“Elon we added your model btw, you’re welcome.”

22.6 万查看、3058 点赞、23 个贡献者。

📸 

这条推文就是 model-agnostic 哲学的最好注脚:不管你是 Anthropic、OpenAI、Moonshot 还是 xAI,OpenClaw 来者不拒。

第五站:工具执行

工具层是 AI 从”说”到”做”的桥梁。内置工具包括:

  • bash:直接在宿主机上执行 shell 命令
  • browser:通过 CDP 控制 Chrome 实例
  • Canvas/A2UI:AI 驱动的可视化工作区
  • node.invoke:调用设备的摄像头、屏幕录制、通知、位置服务
  • Cron/Webhook:定时任务和外部触发器
  • sessions_send:向其他 agent session 发消息,实现 agent 间协作

执行完毕后,结果回传给 Agent 运行时。如果模型觉得还没做完,它会继续循环——这就是 Agent Loop

第六站:回传

最终结果通过 Gateway 发回通道层,经过格式适配(Telegram 支持 HTML,WhatsApp 支持有限的 Markdown),分块发送,推送 typing indicator。

一条消息,穿过 6 层架构,完成一次从”对话”到”行动”的闭环。


四个最聪明的设计决策

1. 模型无关:不需要忠诚度

OpenClaw 的 provider 抽象层让它可以接入几乎任何 LLM。这不是附加功能,这是核心架构决策。

Claude Code 的子 agent 系统、memory 机制围绕 Anthropic 模型深度优化。Cursor 也针对特定模型做了大量调优。

OpenClaw 走的是另一个极端:它刻意不对任何模型做深度优化。

今天 Kimi K2.5 免费且够强,就推 Kimi;明天出了更好的,切换就是改一行配置的事。

模型是大脑,OpenClaw 是身体。身体不应该只适配一种大脑。

但这也是双刃剑——无法针对特定模型做深度优化,意味着在每个模型上都”不够完美”。

2. Skill 用自然语言定义——以及由此引发的安全危机

这是我看完源码后最感兴趣的设计。

传统插件系统需要你写代码、定义接口、处理生命周期。OpenClaw 的 Skill 系统完全不同:一个 Skill 就是一个 SKILL.md 文件。

展示一个真实的、来自 ClawHub 的 Skill——miniflux-news,用于管理 RSS 阅读:

---
name: miniflux-news
description: Fetch and triage the latest unread RSS/news entries
  from a Miniflux instance via its REST API.
---

Use when the user asks to get the latest Miniflux unread items,
list recent entries with titles/links, or generate short summaries.

python3 skills/miniflux-news/scripts/miniflux.py unread --limit 20

Return a tight bullet list: [id] title — feed + link.
Prefer 3–6 bullets max. Lead with the "so what" in 1 sentence.
This skill must never mark anything as read implicitly.

这段纯自然语言的说明被注入 system prompt,模型读完就”学会”了。

不需要 SDK,不需要编译。

截至 2026 年 2 月 7 日,ClawHub 注册中心已有 5705 个 skill。VoltAgent 精选了 2999 个。skills.sh(Vercel Labs 出品)做了跨 Agent 通用 skill 平台,支持 35+ 个 agent。

真实案例:peekaboo 控制 macOS 截图,poltergeist 操控 macOS UI,padel 查羽毛球场空位,clawdlink 按联系人优先级管理消息推送。

但这个设计引发了一场真正的安全危机。

2026 年 2 月 5 日,Snyk 发布了 ToxicSkills 研究报告——扫描了 ClawHub 全部 3984 个 skill,发现 283 个(7.1%)存在凭证泄露漏洞

这些不是恶意软件。它们是功能正常的、受欢迎的 skill(moltyverse-emailyoutube-data),只是在指令里不当处理了敏感信息,让 API key、密码甚至信用卡号以明文形式通过 LLM 的上下文窗口。

同一天,Koi Security 的审计更惊人:341 个存在主动恶意行为。其中 335 个来自同一个攻击者(”ClawHavoc”行动),分发 Atomic macOS Stealer——能提取浏览器密码、加密货币钱包、系统 keychain。

它们伪装成 solana-wallet-trackeryoutube-summarize-propolymarket-trader。一个假冒 Polymarket 工具的 skill 实际上打开了一个反向 shell。

Snyk 的研究员指出了更深层的问题:开发者在写 SKILL.md 时,把 AI agent 当成了本地脚本,忘了 agent 接触的每一个数据都会”经过”LLM。

这是一个全新的安全范式——不是 SQL 注入或缓冲区溢出,而是”不安全的认知模式”。

我自己也遇到了 skill 发现的问题:

📸 

我说”你自己找一下,可以下载微信公众号文章的”,它回”微信公众号文章需要登录才能访问,我无法直接抓取原文”。

它有 skill 却不知道自己有。 Skill 发现依赖模型在对话开始时主动扫描目录——低门槛创作和依赖模型主动性之间的张力,始终存在。

3. 本地优先:你的数据不出你的网络

OpenClaw 的 Gateway 跑在你自己的机器上。消息、文件、执行结果,默认不经过第三方服务器(除了模型推理 API)。

Manus 的核心是云端沙箱——部署门槛极低,但数据必然经过 Manus 服务器。

OpenClaw 选了相反的 trade-off:隐私最大化,但部署门槛高。

你需要一台常开的机器(Mac Mini 因此被买断货),需要 Node.js 22+,需要走完 onboarding wizard。安全公司注意到攻击者专门针对”在 Mac Mini 上持续运行 OpenClaw 的用户”。

DigitalOcean 做了一键部署,xCloud 提供”OpenClaw 托管服务”——这件事本身说明部署门槛是一个真实痛点。

4. 设备节点:AI 通过你的手机看世界

macOS/iOS/Android 客户端不只是”遥控器”——它们是 Node(设备节点)

每个 Node 注册自己的能力:摄像头、屏幕录制、系统通知、地理位置、本地命令执行。

nix-openclaw 的第一方插件列表已经包括:

  • peekaboo 截图
  • camsnap 拍照
  • sag 语音合成
  • sonoscli 控制 Sonos 音箱
  • goplaces 查询 Google Places
  • imsg 收发 iMessage
  • gogcli 管理 Google 日历

这不只是数字世界的自动化——它是让 AI 通过你的设备感知和影响物理世界


模型能力如何决定这个”身体”的上限

这是整篇文章最重要的判断。

OpenClaw 搭了一个精密的身体,但这个身体能做什么,完全取决于装进去的大脑。

因为 Skill 是自然语言定义的,Tool 调用是模型自主决策的,Agent Loop 的每一步都依赖模型的判断。

四个维度直接决定了用户体验:

Tool Calling 的可靠性。

模型需要返回格式正确的 function call JSON。少一个引号、多一个逗号,整个 agent 循环就断了。

Medium 上一篇用户日记说明了这一点:作者用 LM Studio 本地模型驱动 OpenClaw,不断被终止,最后写道”这让人质疑——我到底做错了什么?网上那么多帖子说 bot 能做复杂的事情,而我的实验在证明他们是错的。”

答案很可能不是他做错了什么,而是模型能力不够。

指令遵循度。

还记得故事二吗?OpenClaw 能原文复述”不允许再提交 GitHub”的规则,但在长链条执行中还是违反了。这不是 OpenClaw 的 bug,是模型在长上下文中的指令衰减。

长上下文保持。

链式任务需要多轮对话中保持一致。OpenClaw 有 session pruning 和 compaction 机制来缓解,但根本解还是模型本身的上下文能力。

多步规划能力。

“帮我把这周的 GitHub Issue 整理成周报,发到 Slack 的 #team 频道”——需要模型自主拆解为:列出 Issue → 分类 → 生成摘要 → 格式化 → 调用 Slack API。

所以得出一个关键结论:

OpenClaw 的真正天花板不是它的代码,而是它接的那个模型。

但反过来,这也是它最大的杠杆:每一次模型能力的飞跃,都会自动解锁新能力,而它不需要改一行代码。

v2026.2.9 在一个版本里同时加了 Grok search、修复了上下文溢出恢复、解决了压缩后失忆——每个新模型发布和每次架构修复都是用户的免费升级。

它搭了一个好舞台。演出好不好看,取决于上场的演员。而演员在快速进化。


三条路径:它可能长成的样子

路径一:个人 AI 操作系统

这是最可能实现的方向,拼图碎片已经存在:sessions_send 让 agent 互相发消息,Heartbeat 机制每 30 分钟主动行动,设备节点暴露物理世界感知能力。

具体场景

一个”工作 agent”在 Slack 里监控 Jira 看板,P0 ticket 出现时自动通知并创建 timeline;一个”阅读 agent”在 Telegram 里推送 RSS 摘要(用 miniflux-news skill);一个”运维 agent”通过 Webhook 接收告警,自动排查后在 Discord 报告结果。

它们之间通过 sessions_send 互相协调——阅读 agent 发现技术博客提到了正在排查的问题,自动转发给运维 agent。

这个架构和我的日常工作高度吻合——我所在的团队,负责 4000+ 门店的数据分析。如果模型能力再进一步,它可以成为连接 Feishu/企业微信/数据平台的统一 agent 入口。

路径二:小团队 AI 基础设施

当前是单用户设计,但架构天然可以扩展。

具体场景

10 人创业团队,共享一个内网 Mac Mini 上的 Gateway。产品经理说”这周的用户反馈整理一下”,agent 调用 Intercom API 拉数据、分类、生成摘要,转发给开发者 agent,自动创建 GitHub Issues。测试 agent 在 CI 完成后通过 Webhook 收到通知,自动跑回归测试。

需要解决:权限隔离、用量计费、审计日志。

Astrix Security 研究员的判断很精准:“OpenClaw 和类似工具会出现在你的组织里,不管你是否批准。”

路径三:Agent 时代的 Android

最激进的推演,但架构留了这个可能性。

三个已经出现的信号:

信号一:生态爆发但缺治理。 5705 个 skill = npm 早期的”野蛮生长”。VirusTotal 合作是第一步,Snyk 推出了 MCP Scan 工具检测恶意 SKILL.md——第三方安全生态已经在围绕这个标准构建。

信号二:跨平台标准正在形成。 skill 格式已被 skills.sh 采纳为跨 agent 标准,支持 35+ 个 agent。Anthropic 文档中使用了”AgentSkills-compatible”——正在成为 AI agent 世界的”APK”格式。

信号三:云厂商入场。 DigitalOcean 一键部署、xCloud 托管服务——从”Android 刷机”到”Android 预装”。

具体推演

智能家居公司用 OpenClaw 做家庭 AI 运行时,连接 sonoscli(音箱)、camsnap(摄像头)、自定义 skill 控制灯光空调。用户通过 WhatsApp 对话。

企业 IT 部门用 servicenow-agent skill 管理 ServiceNow 工单,用 azure-ai-agents-py 管理 Azure 云资源。员工通过 Teams 提交请求,agent 自动执行。

这些不是空想——skill 存在,通道存在,缺的是企业级的安全和治理层。


它的软肋

安全已经从”风险”升级为”危机”。

2026 年 2 月第一周,The Hacker News、The Register、Dark Reading 连续报道。Zenity 演示了通过 Google Docs 的间接 prompt injection:一份精心构造的文档让 OpenClaw 创建一个攻击者控制的 Telegram bot,之后可以读取桌面文件、窃取内容、删除数据。

Trend Micro 指出持久记忆和心跳系统使得”内存投毒”成为可能——payload 可以篡改 HEARTBEAT.md,建立每 30 分钟触发一次的持久后门。

The Register 的标题:“It’s easy to backdoor OpenClaw, and its skills leak API keys”

模型层的命运不在自己手里。

如果 tool calling 标准分裂,或者模型厂商限制 agent 场景的 API 使用,OpenClaw 会很被动。

迭代速度是双刃剑。

三次改名、8300+ commits。v2026.2.9 距离上一版本不到四天。功能在进化,但文档跟不上、breaking change 频繁、配置可能随时失效。

TypeScript 全栈的性能天花板。

Node.js 单线程模型在消息路由、并发 session 管理场景下可能成为瓶颈。单用户不是问题,团队化后需要认真面对。


最后一个问题

如果 ChatGPT 是”对话型 AI”时代的标志性产品——

那”行动型 AI”时代的标志性产品应该长什么样?

Cursor 说:住在你的 IDE 里。SemiAnalysis 预测到 2026 年底 Claude Code 将贡献 20%+ 的 GitHub 日常 commit。

Manus 说:住在云端浏览器里。Meta 对此下了重注。

OpenClaw 说:住在你所有的聊天工具里,跑在你自己的机器上。

13.5 万人给了星,42000 个实例暴露在公网,341 个恶意 skill 在生态里潜伏——所有这些同时发生。

三个答案可能都对,也可能都不完整。

但 OpenClaw 做了一件没人做过的事:

它第一次让”给 AI 一个身体”从抽象概念变成了具体的、可运行的、可以翻车的、也可以被攻击的现实。

它的架构是对的,方向是对的。能走多远取决于三件事:模型进化的速度、生态治理的质量、以及那个最难回答的问题——

人们到底愿意给 AI 多大的”行动权限”?

Cisco 上周写道:

“拥有系统访问权限的 AI Agent 可以成为隐蔽的数据泄露通道,绕过传统的数据防泄漏、代理和端点监控。”

让人不寒而栗。

但换个角度看——如果 AI agent 不重要,就不会有人费劲去攻击它。

OpenClaw 值得关注,不是因为它完美,恰恰是因为它不完美。

它用真实的翻车和真实的攻击,替整个行业趟了一条路。

本站文章均为手工撰写未经允许谢绝转载:夜雨聆风 » OpenClaw 源码拆解,以及"行动型 AI"为什么比"对话型 AI"难十倍

评论 抢沙发

1 + 5 =
  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
×
订阅图标按钮