OpenClaw 还不是答案：写在一周烧完 3 亿 Token 后

OpenClaw 很火，但深度体验一周、烧完 3 亿 Token 后，我的结论是：它还不是答案。

OpenClaw 点燃了「AI Agent 落地」的期待，但它目前的交互设计还不够成熟。问题不是「AI 不够聪明」，而是「纯自然语言交互」在执行型任务中存在根本缺陷。

我把 AI 工具分成四种交互模式，每种适合不同的场景。看完你就能判断：OpenClaw 适合你吗？如果不适合，你应该用什么？

一、现象与落差：OpenClaw 热潮下的实测体验

OpenClaw 最近太火了——GitHub 星标疯涨，线下交流活动一场接一场，连周边服务都供不应求。这背后是大家对「AI 真正能干活」的期待——谁不想拥有一个自己的贾维斯呢？

我也是抱着这个期待，趁着春节假期折腾了一周，烧了差不多 3 亿 Token。结果呢？落差挺大的。

它未经授权就把我的工作资料上传到 GitHub；我逐句讲解规则，它还是输出不了我想要的东西。问了下身边的朋友，发现遇到类似问题的不是一个两个。

OpenClaw 能快速掀起热潮，我觉得本质是两大基础条件的成熟：一是国内开源模型厂商与云厂商的市场化竞争，推动 Token 成本大幅下降，让 24 小时在线的 AI Agent 从技术概念变为可落地的现实；二是自然语言交互的低门槛特性，契合了大众「轻量指挥、解放双手」的核心需求，让大家对 OpenClaw 的能力有了无限的想象空间。

在讨论 OpenClaw 之前，我们需要先区分两类完全不同的 AI：

对话型 AI（如 ChatGPT）：像一个顾问，给你建议、帮你写文案、回答问题，但最终「用不用」「怎么用」，由你决定。它的输出是「信息」，你可以轻松判断对错，错误成本几乎为零。

执行型 AI Agent（如 OpenClaw）：像一个助手，直接帮你做事——操作电脑、整理文件、甚至访问你的工作系统。它的输出是「行动」，可能修改你的数据、发送你的邮件，错误成本可能很高。

核心问题在于：我们——或者说大多数用户——习惯了用「对话型 AI」的方式（自然语言）来指挥「执行型 AI」。这就像让一个助手自己去理解「看着办」这样的模糊指令——结果自然难以让人满意。

二、猜谜游戏：自然语言控制 AI 的三大核心缺陷

用自然语言指挥 AI 干活，看起来是最符合直觉的方式——说一句话，它就把事办了。但问题恰恰出在这里：自然语言太模糊了，而 AI 执行需要精确的指令。这个矛盾，是 OpenClaw 目前最大的软肋。

用一个案例来说明：让 AI「整理一下桌面文件」。

这就是「对话型」和「执行型」的核心差异：前者输出「建议」，后者输出「行动」。行动需要更高的可控性，因为行动往往不可逆。

缺陷一：自然语言的模糊性与 AI 执行的精确性形成根本矛盾

人类日常工作指令中的「整理」「优化」「处理」等词汇，背后隐含着基于行业经验、工作场景的默认上下文，但 AI 无法识别这类隐性信息，同一指令会因理解偏差产生完全不同的执行结果。

你说「把这个 PPT 优化一下」，AI 不知道你是想美化排版、精简内容、还是调整逻辑结构。在对话型 AI 中，它会给你三个版本的优化建议让你选；但在执行型 AI 中，它可能直接按自己的理解改完了——结果可能完全不是你想要的。

缺陷二：纯对话模式无法承载复杂工作的流程化需求

面对多步骤、需中断回溯或并行执行的工作任务，用户无法实时掌握 AI 的执行进度，既无法判断其是否卡在某个环节，也无法及时干预调整。你让 AI「帮我整理本周工作并生成周报发到群里」，AI 可能已经完成了前两步，却在「发到群里」这一步出错了——但你完全不知道它卡在哪，想纠正也不知道从何下手。

缺陷三：黑箱式执行缺乏安全与信任的建立基础

手握系统操作权限的 AI，其执行逻辑与下一步操作完全不可预测，误删数据、误操作系统的案例屡见不鲜。信任的建立依赖于过程的透明化与可干预性，行为不可控的 AI，始终无法让用户放心交付核心工作。

业内爆火的 Edict「三省六部制」开源项目，从侧面印证了这一核心问题——用古典官制的规划、审核、执行、制衡逻辑为 AI 强行套上流程枷锁，这一设计虽巧妙解决了部分流程可控问题，却也透露出一种无奈：当下的 AI Agent 缺乏内置的可控工作流机制，纯自然语言交互模式在专业闭环工作中难以奏效。

三、人机协作范式：四种交互模式的深度对比

那问题来了：如果纯自然语言不靠谱，正确的交互方式应该是什么？

我用一个坐标系来分析这个问题——

• 横轴：AI 执行自主性 —— AI 能在多大程度上独立决策、自动执行
• 纵轴：人类表达成本 —— 让 AI 按意图执行，人类需要付出多少努力

这个坐标系真正的重点是：谁来消化歧义？

可拖拽工作流（左下）：人提前消化歧义。成本低但自主性也低，因为人把意图提前结构化成了流程图，实际上是人替 AI 做了一部分「理解」的工作。歧义在执行前就被消除了。

AI 原生浏览器（右下）：上下文帮忙消化歧义。表达成本低，是因为任务和上下文天然对齐——你在一个页面上说「帮我填这个表」，AI 看得见你看的东西，歧义空间极小。视觉上下文充当了「隐式约束」。

IDE 内嵌式 AI（中间）：结构化降低歧义。成本中等，是因为「选择 + 指令」的交互方式本身就携带了精确的上下文——你选中一段代码，就等于告诉 AI「我只关心这部分」。这种结构化输入天然降低了歧义空间，而不是让 AI 去猜。

OpenClaw / 纯自然语言（右上）：AI 自己反复消化歧义。成本高，是因为任务链路长 + 上下文需要人工构建，AI 看不见你脑子里的目标，自然需要反复对齐。歧义在执行过程中不断涌现，每次都需要用户介入澄清。

所以问题的关键不是「AI 够不够聪明」，而是「歧义在哪个环节被消化、由谁来消化」。可拖拽工作流把歧义消化前置到设计阶段，AI 浏览器让上下文帮忙消化歧义，IDE 内嵌式用结构化输入降低歧义——而 OpenClaw，把歧义消化全部留给执行环节，用户需要在 AI 每次「理解偏差」后反复修正，成本自然居高不下。

模式一：纯自然语言交互（代表：OpenClaw）

工作方式：用户用日常语言描述需求 → AI 理解意图并执行 → 执行过程不可见 → 结果直接呈现。

优点：零学习成本，人人可用；最大灵活性，理论上能处理任何任务；24 小时在线，随时响应。

问题：意图理解的「猜谜游戏」（每次都需要补充说明，沟通成本高）；执行过程的「黑箱」（发现问题时，可能已造成不可逆影响）；错误恢复的困境（误删文件、发错邮件，修复成本极高）。

适用场景：输出结果可轻易验证的任务（写文案、翻译、回答问题），错误成本低，不会造成实质性损失。

模式二：IDE 内嵌式 AI（代表：Claude Code、Cursor、Windsurf）

工作方式：AI 深度集成到工作环境 → 用户通过「选择 + 指令」精准描述意图 → AI 先输出计划，用户确认后执行 → 过程实时可见，可随时接管。

优点：上下文精准注入（选择代码片段就等于明确告诉 AI「我只关心这部分」）；计划模式——先看再做（AI 先展示要做什么，用户审核后执行，相当于给 AI 装了「刹车」）；执行透明可控（每一步操作都有日志，发现问题可以随时中断）。

核心启示：不是 AI 更聪明，而是交互方式更可控。这套模式的核心，是把「让 AI 猜测意图」变成「让人类精准表达意图」。

延伸：Claude Cowork——从编程到知识工作

2026 年 1 月，Anthropic 发布了 Claude Cowork，定位是「Claude Code for the rest of your work」。它将 Claude Code 的可控交互理念，从编程场景扩展到知识工作场景——给 Claude 指定一个文件夹，描述你想要的结果，它就能自主规划步骤并执行。

它比 OpenClaw 更可控，因为继承了 Claude Code 的框架设计：计划模式（先展示要做什么，你确认后再执行）；实时日志（每一步操作都可见，可随时接管）；明确边界（在指定的文件夹范围内操作，不会「越界」）。这正是 OpenClaw 缺失的——不是 AI 不够聪明，而是缺少可控的交互框架。

模式三：AI 浏览器类原生代理（代表：Dia、Tabbit）

工作方式：AI 能「看见」网页，像人一样点击、输入、滚动 → 用户用自然语言描述任务 → AI 在浏览器中执行操作。

优点：网页即上下文，降低向 AI 描述的表达成本；理论上能完成「订机票」「填表单」等任务。

问题：产品形态较新，发展路径尚不明朗——豆包 AI 手机遭国内厂商封杀的案例表明，这类产品的商业模式、生态接受度都还在探索中。

适用场景：信息获取、网页阅读、简单自动化操作，适合愿意尝鲜早期产品的用户。

模式四：可拖拽工作流（代表：Coze、Dify、n8n、Zapier）

工作方式：用可视化的流程图设计工作流 → 每个节点定义明确的输入/输出 → AI 只在指定节点执行指定任务。

优点：流程可视化（一眼看清 AI 会执行哪些步骤，可以调试、测试每个节点）；边界清晰（AI 能做什么、不能做什么，都在流程中定义）；可复用（一次设计，反复使用）。

问题：灵活性差，只能做预设流程内的事；设计成本高，需要提前想清楚所有步骤，不适合临时性、变化多的任务。

适用场景：工作流程固定、重复执行的任务，有专业团队设计维护。

回到 OpenClaw：它选择了「高自主性 + 高表达成本」的模式，却没有解决表达成本高的问题。用户需要反复解释意图，AI 却仍然可能理解偏差，执行过程又不可见，最终结果难以让用户满意。

真正能「干活」的 AI，需要的不是更高的自主性，而是更低的表达成本和更高的透明度。

四、实用指南：如何选择适合你的 AI 工具？

OpenClaw 适合谁？

坦白说，在它的交互设计得到根本改进之前，我不建议急着安装使用。

适合尝试的：想体验「AI Agent 能做什么」的好奇者；不涉及敏感数据的探索性任务。

暂不适合的：需要精确执行的生产工作；涉及敏感数据的操作。

想尝试「AI 帮你干活」的生产场景？建议从 Claude Cowork 开始——它继承了可控的交互框架，更靠谱。

五、核心结论：OpenClaw 为何不是最终答案？

首先，必须肯定 OpenClaw 的价值——它是 AI Agent 领域当之无愧的启蒙者与探路者。它让千万用户亲手体验到了 AI Agent 的落地可能性，推动了 Skill、MCP 等核心技术的快速普及。这确实是一个很酷的产品。

但讲到底，OpenClaw 仍只是 AI Agent 落地的一个起点。它演示了「AI 能干活」的可能性，却未能交付「AI 能靠谱、规模化干活」的解决方案。

核心原因在于交互方式存在的严重问题：缺少低成本、高可控的交互方式。纯自然语言交互让用户付出高昂的沟通成本，却难以保证执行结果的准确性。相比之下，IDE 内嵌式 AI 通过「选择 + 指令」、计划预览、实时日志等机制，让用户能以中等成本实现高可控执行。

它让我看到了 AI Agent 落地的美好前景，却未能打通从「能做」到「做好、做稳、做规模化」的最后一公里。这正是它无法成为最终答案的核心原因。

六、延伸思考：Harness Engineering

上面这四种模式，换一个角度看，其实是四种不同的 harness 设计。

「Harness」这个词来自赛车运动——安全带、头颈约束系统、防滚架，整套东西不是为了让车手跑慢，是为了让他敢把车开到极限。AI 的 harness 是同一个逻辑：不是限制 AI，是让它在一个明确定义的结构里工作，让你敢把更高权限交给它。

可拖拽工作流的 harness 是流程图——每个节点的输入输出被精确定义，歧义在编排阶段就消化了。IDE 内嵌式 AI 的 harness 是代码上下文 + 计划确认——选中的代码片段是隐式约束，plan mode 是强制的确认节点。AI 原生浏览器的 harness 是界面视觉上下文——网页结构本身替用户承担了大量的歧义消化工作。

而 OpenClaw 的 harness 几乎是空的——它的 AI 运行在一个几乎无约束的上下文里，除了用户每次用自然语言重新构建的那些隐性规则。

Harness engineering 因此是一门具体的工程实践，不是抽象的设计哲学。它问的问题是：你能用什么结构，把「仍然在用户脑海里的上下文」提前编码进系统？

几个典型的 harness 设计动作：

精确的工具 schema。给 AI 的 tool 定义越精确，AI 的行为就越可预测。get_file_content(path: str) -> str 比 do_file_operation(instruction: str) 的 harness 质量高出不止一个量级——前者把歧义消灭在接口设计里，后者把歧义留给了运行时。

结构化的上下文注入。CLAUDE.md、Skills、project-level instructions——把「你是谁、这里的规则是什么、不该做什么」编码成文档结构，而不是靠自然语言每次重说。这是上下文 harness，让 AI 每次执行时都带着同一套隐性约束启动。

显式的执行边界。容器挂载（只能访问 /groups/A，不能访问宿主机）、白名单权限（只能调用这几个 MCP 工具）——把「AI 不该做什么」变成物理约束，而不是逻辑检查。OpenClaw 缺的不是 AI 智能，是这层边界。

强制的确认节点。Plan mode 在不可逆操作前要求人工确认——这是 harness 里成本最低、收益最高的安全装置。它的本质不是「不信任 AI」，而是承认「语言表达永远有歧义」，在歧义还有机会被纠正的地方，强制留一个人工干预的窗口。

这四种设计动作，对应的正是「谁来消化歧义」这个问题的四种不同工程化答案：在接口设计时消化、在上下文注入时消化、在执行边界时消化、在确认节点时消化。

2026 年初，harness engineering 作为一个独立工程方向获得了业界正式认可——Mitchell Hashimoto（Terraform 作者）首次明确命名，OpenAI、Anthropic、Google 随后将其纳入各自的 AI 工程实践框架，Martin Fowler（Thoughtworks）也发表了正式方法论。它已经是区分「靠谱 AI 工具」和「有趣 AI 玩具」的核心变量。OpenClaw 是一个很酷的玩具，但它的 harness 太薄——这才是它「还不是答案」的工程学解释。

写在最后：与其追 AI 热点，不如找到自己的 AI 节奏

烧完三亿 Token 后，我最大的感受是：OpenClaw 还不是答案，但它让我们看到了问题所在。

问题不是「AI 够不够强」，而是「我们用什么样的方式跟 AI 协作」。纯自然语言交互像个黑箱，你说了、它做了、结果猜谜一样。真正靠谱的 AI 工具，应该让你「看得见、管得住、成本低」。

不同的 AI 交互方式，本质上是为了追求更加便捷的方式补充更多的上下文，让 AI 给出可靠的输出。然而，更多的上下文，仍然在我们的脑海里——仍然需要我们用更加精准、清晰的方式向 AI 表达，或者向人表达。

OpenClaw？等它进化到 2.0 版本，加入可控的交互框架再说。

写于一周高强度 AI 使用后，杭州。