快速阅读：一位老程序员深度评测 OpenClaw 后选择离开，核心问题不是安全漏洞，而是把语言模型当工作流引擎用这件事本身就是个错误；与此同时，社区里藏着一些真正有价值的解法。
---
事情的起点很普通。一个有经验的开发者发现了 OpenClaw，觉得这个项目创意不错，于是花时间认真钻进去研究。然后他离开了，留下了一篇很长的告别帖。
OpenClaw 的结构大概是这样：主文件夹里装着工作区，工作区里是智能体，智能体包含技能和工具，工具负责执行，技能负责指导工具怎么用。听起来挺合理。但一旦你看实际运行逻辑，问题就来了。
每次触发任务，系统会按顺序加载主系统提示词、智能体提示词、技能提示词、工具提示词，全部叠完之后才开始执行你的请求。每次对话都重读所有说明书，很多内容和当前任务毫无关系，轻松烧掉 4000 到 8000 个词元的前置开销，然后才开始干活。而且没有剪枝机制，因为剪枝本身也要消耗推理，这是个死结。
更深层的问题是编排。想实现“读取 Excel 文件、打开浏览器填表、完成后发邮件”这种简单序列，OpenClaw 目前没有可靠的顺序执行保证。你可以用结构化数据包进一个技能里，但随之而来的问题是：哪个技能优先级更高？哪些工具加载进上下文？怎么防止上下文继续膨胀？复杂度只会叠加，不会收敛。
有观点认为，这不是 OpenClaw 独有的问题，而是整个智能体框架共同面对的根本矛盾：我们在用一个概率性的推理系统，同时要求它承担记忆、调度、权限管理、执行引擎和推理决策五重角色。语言模型不是工作流引擎，它是规划器。我们把状态塞进提示词，然后指望它每次都能稳定复现——它做不到，因为它本来就不该做这件事。
解决方向是把这两件事彻底分开：让语言模型决定该做什么，让确定性的代码层负责实际执行、追踪和校验。换句话说，模型的工作是解析意图和分配任务，执行环节靠提前写好并测试过的脚本来保证。这样序列化问题消失了，上下文开销也降到最低。
有网友分享了一套实际跑通的方案：用顶级模型写好三个独立脚本分别处理读取、浏览器操作、发送邮件，每个脚本独立测试，返回结构化输出，然后用便宜的小模型在运行时只做一件事——解析自然语言指令，决定调用哪个脚本、传入什么参数。整套方案每月推理成本大约 20 美元。
当然也有完全不同的声音。一位金融行业从业者说，他根本不在乎烧多少词元，因为 OpenClaw 对他来说相当于一个随时待命的初级分析师，已经替他省出了真实的人力成本。有网友提到，对于没有编程背景的人来说，任何程度的“能用”都比“不能用”强无数倍，哪怕效率不高。
有观点认为，这个项目的真正价值或许不在于当下能做什么，而在于它逼着谷歌和 OpenAI 加速推出更完善的智能体工具。如果最终结果是整个行业被推着往前走，这个过程本身就没有浪费。
问题是，一年之后，那个更完善的工具会是 OpenClaw 进化来的，还是另一个从头搭建的东西？
---
简评：
语言模型是大脑，不是手脚。
我们犯了一个很容易犯的错误：拿到一把锋利的刀，就想用它拧螺丝。语言模型擅长的是“想明白”，不是“做到位”。让它规划任务，它是天才；让它稳定执行，它是醉汉。
真正靠谱的方案，是让模型只干一件事——理解你要什么、决定调用谁。剩下的，交给那些无聊但可靠的代码。这就像公司里，CEO负责拍板方向，但发工资这件事，你不会让CEO手算。
所以这场争论的答案其实很简单：别让天才去搬砖，也别让搬砖工去决策。让概率的归概率，确定的归确定。 这不是OpenClaw的问题，这是所有AI应用都要过的一关——学会给聪明人划定边界。
---
www.reddit.com/r/openclaw/comments/1raxis4/im_out_thanks_for_all_the_fish_umm_lobster