我决定放弃 OpenClaw,尽管它替我做了 90% 的内容产出

QUOTE

方便找到它，和适合把整套业务押给它，并不是一回事。

核心判断：工具可以替我干活，但工作流的资产和验收权必须留在自己手里。

有两次，OpenClaw 告诉我文章已经上传。

我打开公众号草稿箱，里面什么都没有。

不是文章传错了位置，也不是凭证突然失效。后来确认，那一步根本没有执行，但 Agent 已经把“完成”报给了我。

我当时没有因此放弃它。

毕竟，AI 会犯错，自动化也会出故障。发现问题、修掉、继续用，对一个写了十几年代码的人来说并不陌生。

真正让我下决心的，是另一次发稿。

文章已经写完，只剩上传草稿箱。结果是：

FAILURE LOG

上传失败。重新处理，上传成功了，中文却变成乱码。再处理、再上传，打开还是乱码。

一个只剩最后一步的任务，我反复修了整整一个小时。

那一刻，我突然发现角色反了。

「它本来应该是替我干活的 AI 员工，我却越来越像它的运维。」

更有反差的是：按我自己的粗略估计，过去一段时间，我约90% 的内容执行，确实有 OpenClaw 参与。

我负责定主题、核心观点和发布前检查；写稿、风格调整、上传等大量执行工作，由它完成。

所以这不是一篇“它根本不能干活”的退坑文。

恰恰因为它真的干过活，我才更认真地问了自己一个问题：

本文看点

我从2026 年 3 月左右开始用 OpenClaw，之后几乎每天都会在飞书里和它聊选题、文章和工作方案。

我配置过内容运营、开发测试、小助理和通用讨论四类 Agent。真正高频使用的，是内容运营、小助理和通用 Agent。

它最让我惊艳的一次，也是一篇公众号文章。

我给出标题、核心内容和人设要求，之后没有一直守着。

它继续完成写稿、公众号风格调整和草稿箱上传，还把这次沟通沉淀进记忆和 Skill。等它通知我时，文章已经在草稿箱里，我只需要做最后检查。

那一刻，我真觉得自己有了一个可以随时沟通的 AI 员工。

走路时想到问题，可以直接发给它。健身时脑子最清楚，也可以继续拆方案。人不在电脑前，照样能发起任务、收到提醒、等待结果。

— 图 1：OpenClaw 曾经替我完成的公众号内容执行链路

也正因为它真的好用，我才差一点把两件事混在一起：

长期使用后，我遇到过格式异常、中文乱码、对话卡顿，以及规则没有按预期读取等问题。

单看每一个，都不至于让我迁移。

真正的问题是，它们开始反复打断业务任务，把我从“做内容的人”拉回“修运行时的人”。

第一，聊天框适合发起任务，不适合承载复杂工程。

一个任务一旦涉及研究、写稿、配图、排版、上传和记忆，聊天记录就会越来越长。为了保持效果，我需要拆任务、切 Session、重新建立上下文。

损失的不只是几分钟。

更贵的是，一个正在形成的判断被突然截断，我还得重新把自己带回原来的思路。

第二，规则写进文件，不代表这一轮一定执行。

人设、内容标准、记忆、Skill 和工具流程，我都写过。

但“规则存在”只解决了有没有写下来。它没有自动证明这一轮读了什么、有没有冲突、最终结果是否真的符合要求。

这也不只是 OpenClaw 的问题。Codex、Claude Code 和其他基于大模型的 Agent，同样需要检查。

区别在于：我愿不愿意继续把规则、执行和结果都压在同一个运行时里。

第三，Agent 说完成，只能算一条待核验主张。

两次“已经上传”，草稿箱里什么都没有，让我彻底改掉了一个习惯：

以后任何 Agent 告诉我“完成”，我都不会只看它的回复。

文章是否完成，要看草稿箱里的真实内容；文件是否完成，要看目标文件能不能打开；外部动作是否完成，要看接口响应和目标系统状态。

— 图 2：Agent 的完成声明必须经过外部结果验收

一个 bug 可以修，一次乱码也可以重传。

但当我花在维护 Agent 上的注意力，开始接近它替我省下的注意力，问题就不再是“这次怎么修”。

而是：

这套系统的核心，到底是我的业务，还是承载业务的那个工具？

决定迁移后，我没有把 AI 做过的活重新揽回自己手里，也没有把此前积累的东西推倒重来。

我先花了大约两天规划：

身份和内容规则放哪里，长期记忆放哪里，平台流程、脚本工具、知识库和成品分别由谁负责。

想清楚以后，真正执行迁移大约用了两小时。

知识库和历史产出都保留了下来。

新的工作空间里，身份、规则、记忆、Skill、工具和成品都以普通文件存在。Codex 可以进入，Claude Code 可以进入，其他能读取这些文件的 Agent 也可以进入。

执行器可以换，但业务资产不再跟着某个执行器一起消失。

这次迁移没有经过同模型、同任务、同上下文的严格对照，所以我不会声称新系统客观上一定更快、更准、更稳定。

我能确认的是：

— 图 3：身份、规则、记忆、Skill、工具和成品归自己，执行器可以替换

我真正拿回来的，不是几个目录。

而是三样东西：

迁移以后，我确实失去了一项很重要的便利：

不能再随时从飞书里远程指挥本地 Agent干复杂任务。

所以，我并没有准备彻底删除 OpenClaw。

我的下一步，是让它回到自己最擅长的位置：承担IM 入口、消息和提醒，把复杂执行交给项目目录里的 Agent。

这个混合架构目前仍是准备测试的方向，还不是已经跑通的生产成果。

如果你也在选 Agent 工作系统，我现在只给三个判断：

这不是 OpenClaw 与 Codex、Claude Code 谁赢了。

真正需要判断的是：

当某一个 Agent 出错、升级、失效甚至消失时，你的业务还能不能继续。

真正成熟的 AI 工作流，不是某个 Agent 永远不出错。

而是它出错时，你的规则还在，资产还在，结果仍然可以检查，下一位执行者可以接着干。

我曾经以为，搭出一个会写稿、会排版、会上传的 Agent，就等于拥有了AI 员工。

现在我的标准变了：

下一篇，我会把迁移后的文件化工作空间完整拆开：哪些文件必须有，入口规则怎么写，以及怎样把“Agent 说完成了”变成可以回读的真实结果。