从现状来看， openclaw 远未达到生产环境的标准，它更像是一个为了验证思路而匆忙写就的学术demo。目前它的构建高度依赖 vibe coding，但这种大力出奇迹的模式迟早崩溃，未来的演进方向必然是转向使用 Rust 或 Zig 这样更高效、更严谨的系统级语言，并且使用更好的工程结构来控制复杂度。

在使用 openclaw 的过程中，我最深恶痛绝的就是直接让 Agnet 直接去操作 JSON 等底层配置文件。AI 本质上是在算概率，输出具有不可控的随机性。如果允许 AI 拥有直接以字符级别改写系统配置的权限，无异于在没有安全检查的情况下运行一段不可信的代码。只要 AI 产生一次小小的幻觉写错了一个字符，就可能引发整个系统的状态崩塌。至少要把配置文件都藏起来，只留下一套鲁棒的命令行接口（CLI）来控制交互的复杂度。

与此同时，传统的工作流与GUI 并不应该被舍弃。目前的 openclaw在使用 token 上过于粗放，我有一些工作流放在里面也只是以 markdown 格式存储，但是坦白来说常用工作流还不如迁移到 n8n 上只让 openclaw 来触发即可。在我的早期实践中，当我使用 openclaw 运行工作流时，如果工作流过长，Agent 可能会因为上下文而性能降低，无法规范统一。为了监控中间结果，我还不得不在 Notion 中专门创建了一个 database 用于更新记录。但是，可以很明显地看到，它更新记录时的表现并不稳定。所以，正常的方式应该是让 openclaw 运行一段时间的工作流。如果稳定且有固定需求，就迁移到其他的工作流平台上。

使用 AI Agent 直接操纵文本文件还有一个巨大的弊端，就是没有快照功能。也就是说，我的状态是无法修复的，这对于重要工作来说绝对是不可饶恕的。我想这也是为什么大家虽然鼓吹 coding agent 更加适用于 Obsidian 而不是 Notion，但是 Obsidian 却推出了 CLI 的原因。有了每一次具体操作的概念，我们就有了记录的基础。 从这一点上来说，我现在很看好 Notion，我已经看到了 Custom Agent 能做的事情。