以观书法
108.85M · 2026-02-05
坦白说,我刚刚从“OpenClaw 能跑起来”的兴奋中缓过神来,现在脑子里只剩两件事:
这东西太强了,以及,我不敢再让它随便碰我的主力机。
以下是我作为一个刚踩完坑的程序员,最真实的感受。
我花了一个晚上,按照文档在云服务器上把 OpenClaw 跑了起来。Gateway 启动,WhatsApp 连上,我随手发了句:
接下来的 20 分钟,我看着它在终端里自己 git clone、翻看 diff、写总结,最后真的把整理好的报告发到了 Slack。那一刻,我鸡皮疙瘩都起来了——这不就是我梦寐以求的“数字分身”吗?
它给我的震撼主要有三点:
真正的本地优先与数据主权
它跑在我自己的机器上,配置、记忆、日志全在本地磁盘。我可以随时拔掉网线,它照常干活,这种掌控感是 ChatGPT 这类云端产品给不了的。
ReAct + 工具调用的成熟闭环
它内置了成熟的 ReAct 循环,能自主规划、调用工具、观察结果并修正。我甚至看到它为了完成一个任务,自己写了个 Python 脚本,执行失败后自动 pip install依赖,再重试,最后把脚本存成了 Skill 供下次复用。
多模型与多通道的抽象
我可以随意在 Claude、GPT、DeepSeek 之间切换,甚至可以同时跑多个 Agent 协作。所有聊天平台都通过一个本地 Gateway 接入,更换前端 UI 不影响后端逻辑,架构非常清爽。
当我开始让它接管更多日常任务时,那种“强大到可怕”的感觉愈发强烈。
commit一次,以便随时回滚。真正让我从“真香”转向“不安”的,是逐渐暴露的安全问题。
高权限 + 高暴露面
OpenClaw 默认 127.0.0.1:18789,看似安全,但在云服务器和 Docker 环境中,这个端口很容易通过反向代理暴露出去。一旦配置不当,就等于把服务器 root 权限交给了全世界。我花了一整晚加固防火墙,强制开启 Token 认证,才稍微安心。
明文存储的密钥
官方文档轻描淡写地让我把 API Key 写在配置文件里。我很快意识到,这些密钥会以明文形式存在于磁盘上,甚至可能在各种备份中被长期保留。如果这台机器被入侵,后果不堪设想。我不得不手动将密钥迁移到专门的密钥管理工具中。
防不胜防的提示词注入
我让它总结一封邮件,结果它“很听话”地把邮件内容连同附件链接一起发给了发件人。我这才明白,模型无法区分“指令”和“数据”。任何包含指令的邮件、网页或文档都可能成为攻击载体,诱导 Agent 做出危险行为。我被迫为所有涉及敏感信息的操作都加上了人工审批环节。
失控的资源占用
有一次我让它长时间坚控一个任务,结果它为了“不中断”,疯狂重试,占满了 CPU 和内存。我不得不给它加上资源限制和“自杀”机制,确保它不会拖垮整个系统。
现在的我,对 OpenClaw 的感情非常矛盾。
一方面,我真心佩服它的架构设计和工程实现,它让我看到了 AI Agent 落地的巨大潜力。另一方面,我每天都在担心:我的 .env文件是否安全?那个定时任务会不会哪天删掉我的重要数据?我发给它的代码里,是否潜藏着恶意指令?
OpenClaw 就像一把没有刀鞘的利刃,锋利到令人惊叹,但也危险到让人心惊胆战。它迫使我重新思考“权限”、“边界”和“信任”这些基础问题。
如果你也想尝试,我的建议是:
rm -rf的机器。OpenClaw 不是“淘汰 80% App”的终点,而是 AI 接管我们数字生活的一个危险起点。我很庆幸自己是第一批“吃螃蟹”的人,但我也清楚地知道,这只“龙虾”,我暂时还不敢把它养在真正的生产环境里。