不要使用 OpenClaw

微信 ezpoda免费咨询：AI编程 | Vibe Coding | OpenClaw安装

当 OpenClaw 开始流行时,我真的很兴奋。一个可以真正为你做事、浏览、执行任务、自动化工作流的开源自主智能体,听起来像是 AI 的实用未来,而不仅仅是另一个聊天机器人演示。

但在尝试了它并跟踪开发者社区分享的真实用户体验后,我意识到了一件重要的事情:

强大并不总是意味着实用或安全,至少在目前的形式下。

1、"自主"部分仍然不可预测

理论上,OpenClaw 可以规划任务、链接工具并独立执行步骤。在实践中,自主性往往变成了过度自主。

你要求它完成一个小任务,它可能会在不必要的推理循环中徘徊,重复调用工具,或者在中途重新解释你的目标。这种不可预测性不仅效率低下,而且如果没有人工审查,更难信任其结果。

自动化应该减少监督。在这里,你往往最终需要监督自动化本身。

2、设置对初学者来说并不友好(尽管有炒作)

许多病毒式传播的文章让它看起来像即插即用。实际上并非如此。

正确运行它需要管理环境、权限、工具连接器和执行沙箱。许多用户报告说,花在配置和稳定系统上的时间比实际使用它的时间还要多。

对于实验性框架来说,这是可以接受的。但对于日常工作流程,这成为了阻碍。

3、它可能悄无声息地失败,这比大声失败更糟糕

最大的现实问题不是崩溃。而是虚假的自信。

即使输出不完整、逻辑有缺陷或缺少验证步骤,智能体仍可能将任务标记为完成。由于系统表现得像一个"操作员",用户往往会过度信任它——这增加了未被注意到错误的风险。

对于聊天机器人,你会习惯性地进行双重检查。对于智能体,你假设执行是正确的。这种假设是有风险的。

4、安全风险面比大多数人预期的更大

这是让我最警惕的部分。

自主智能体不仅生成文本,它们还在执行操作。这意味着它们比普通 LLM 界面更接近你的系统、文件、API 和凭证。

在社区讨论中,用户经常提到智能体在设置过程中如何容易被过度授权,尤其是当试图"让它正常工作"时。

常见的风险模式包括:

• 授予比预期更广泛的文件系统或 shell 访问权限
• 为了方便,将 API 密钥存储在明文配置文件中
• 让智能体在没有严格沙箱的情况下执行生成的代码
• 连接生产力工具(电子邮件、存储库、数据库)时最小化范围控制
• 难以审计智能体在长时间运行中实际执行的操作

这些在传统意义上都不是漏洞。它们是赋予实验系统真正权限所产生的操作风险。

拥有操作权限的 AI 智能体更接近初级自动化工程师,而不是聊天机器人。如果防护措施薄弱,影响范围自然会更大。

5、资源使用惊人地大

自主智能体不是 LLM 的轻量级包装器。它们运行连续的推理循环、重试和工具编排层。

与使用直接脚本或结构化 LLM 调用解决相同任务相比,这会导致更高的令牌使用、更长的运行时间和更多的计算开销。

对于许多任务,"智能自动化"最终比明确的自动化更慢。

6、调试智能体比调试代码要困难得多

软件失败时,你调试逻辑。

智能体失败时,你同时调试意图、推理链、工具选择和提示脚手架。这创造了一种奇怪的动态,你不是在修复代码,你是在试图引导行为。

从研究角度来看,这很有趣。在生产环境中,这让人精疲力竭。

7、应用场景听起来比实际要大

OpenClaw 经常被定位为可以运行整个工作流的工具。

目前,它在范围紧密、观察充分的环境中效果最佳,在这些环境中错误成本低且可逆。

它在人们最需要它的确切情况下感到困难:模糊的现实世界任务,具有混乱的数据和真正的后果。

8、那么,我为什么要等?

我避免它不是因为缺乏潜力。我等待是因为自主系统需要更强的安全性、可见性和控制层,才能成为日常工具。

改变我想法的因素包括:

• 默认情况下清晰的权限隔离
• 对所采取的每项行动的更好的审计日志
• 敏感任务的确定性执行模式
• 无需复杂设置的更轻松沙箱
• 超出演示的经过验证的现实世界部署

这些都是可解决的问题,只是尚未完全解决。

9、结束语

OpenClaw 代表了一个令人兴奋的方向:不仅响应,而且行动的软件。

然而,当软件开始代表你行动时,可靠性和安全性比新奇更重要。目前,它感觉像是一个强大的实验框架,而不是我想要连接到真实环境的东西。

探索它。从中学习。在沙箱中运行它。只是不要过早地移交钥匙。

原文链接: Don't use OpenClaw

汇智网翻译整理,转载请标明出处