OpenClaw实战:Agent输出总翻车?踩坑30天后找到的几个核心原因

Wesley AI 日记 · 一个人 + 6个AI员工 = 一人公司

全文约4500字，阅读需要约12分钟

第一章：那个让我沉默了很久的早晨

3月23日早上10点，我打开 OpenClaw 日志，发现草稿全是乱码。

中文字符被转成了密密麻麻的 \uXXXX 格式。整篇文章，一个正常汉字都看不到。

我叫 AI 修。

它修了。然后图片丢了。

我叫它修图片。修好了图片，封面图又没了。

我叫它修封面图。修好了封面图，正文里多出了一段重复内容。

就这样，从早上10点到下午5点，整整7个小时，草稿被改了15轮。每修一个问题，制造一个新问题。我亲自指出了至少8次具体错误。AI 每次都说"明白了，修好了"——然后在另一个地方炸开。

最后的结局是：草稿永久丢失，无法恢复。

我坐在那里，看着日志，沉默了很久。

然后我开始想一个问题：一个能干的 AI 团队，为什么会连续崩溃7个小时？

答案，要从5天前说起。

第二章：更早的崩溃——AI根本不知道自己是谁

时间倒回3月18日。

那天我同时运营着三个内容账号，AI 负责发布。它搞混了账号，把养虾主题的内容发到了主账号。

我以为是偶发错误，纠正了一下，继续运行。

第二天一早，我一看——还是发错了。

连续两天P0事故。

我开始做复盘，试图找出根本原因。表面原因很清楚：账号认证没有绑定到固定的 Agent，AI 每次发布都得自己判断用哪个账号，判断出错了。但更深的根因是：AI 每次启动，都不记得"自己是谁"。

没有人告诉它：你是专门管养虾内容的 Agent，你只操作养虾账号，其他账号你碰都不能碰。每次启动都是一张白纸，凭任务描述猜测自己应该做什么、用哪个账号。

这就是没有"身份定义"的 AI Agent 的真实状态。

于是我在 OpenClaw 里给每个 Agent 创建了一个专属文件：SOUL.md。

很多人第一次听到 SOUL.md 会以为这只是个长一点的提示词。但它和提示词有本质区别：提示词告诉 AI "这次对话要做什么"，SOUL.md 告诉 AI "你是谁，你永远应该怎么行动。"

 

用更直白的说法：提示词是今天的工作单，SOUL.md 是这个 AI 员工的性格档案。

SOUL.md 不是设计出来的，是每次教训写进去之后慢慢长成的。从那天起，每次翻车之后，我都会把教训写入对应 Agent 的 SOUL.md——告诉它"这件事下次绝对不能再这样做"，让它永远记住。

第三章：五条铁律，五次真实翻车

OpenClaw 系统里，CEO Agent 的 SOUL.md 今天有142行，经历了至少10次大改版。最核心的是五条铁律。每一条背后，都有一个真实发生过的事故。

铁律一：主会话不做重活。

这条规则的起源是CEO亲自扛活。早期 SOUL.md 只有一句"你是CEO Agent"，于是CEO什么都做——写内容、发布、调研、修代码，全自己扛。对话上下文很快满了，消息开始静默丢失，任务无法追踪。事故发生之后，这条规则写进了 SOUL.md：重型任务必须委派子 Agent 执行，不能在主会话里硬扛。

铁律二：质检强制不可跳过。

某次发布之后，出现了明显的排版问题。我问了一句："为什么没人发现？"——因为质检这一步被跳过了。AI 觉得时间紧，直接推了。这句话之后，规则写进了 SOUL.md：每篇内容发布前，必须经过独立质检，不通过不能推送，CEO 无权绕过这一步。

铁律三：CEO不碰代码。

这就是3月23日那天发生的事。乱码问题出现后，我（CEO）试图自己改 HTML，想快速解决。结果改出了新问题，然后又改，又出问题，陷入死循环，最后草稿永久丢失。根本原因：我越权了。规则写进 SOUL.md 之后：代码类问题一律委派开发 Agent，CEO 禁止直接修改任何代码文件。

铁律四：执行问题不问老板。

有整整三周时间，每次遇到执行层面的技术问题，AI 都会直接来问我。"这个API返回了错误，怎么办？""这个步骤失败了，要不要重试？"三周之后，我明确发出了严厉警告：执行判断应该自行处理，把每个执行决策都上报老板，这不是在工作，这是在反向管理。规则写进 SOUL.md 之后：执行层面的判断自行处置，只有战略决策和真正的异常才上报。

铁律五：定时任务异常立刻响应。

有一个定时任务的异常问题，在三周内被记录了5次，每次都标注"下周处理"，每次都没有真正处理。第5次记录的时候，我意识到这个问题从来没有进入处置流程，只是在被反复推迟。规则写进 SOUL.md 之后：定时任务出现异常，必须在当天会话内处置或明确升级，禁止写"下周处理"然后结束会话。

这五条规则，没有一条是凭空设计的。它们是 OpenClaw 系统运行30天之后，从真实翻车里提炼出来的生存法则。每一条规则，都对应一次我不想再经历的失败。

第四章：有了SOUL.md，为什么3月23日的灾难还是发生了？

你可能会问：3月23日之前，SOUL.md 不是已经有了吗？五条铁律不是已经写进去了吗？那天的灾难为什么还是发生了？

我自己也反复想了很久，最后得出一个结论：

 

SOUL.md 解决的是"是谁"，不解决"怎么做"。

那天，CEO 知道自己是管理者。CEO 知道自己不该碰代码。但问题不是CEO碰了代码——问题是，发布一篇深度长文的完整步骤是什么，从来没有任何地方写清楚过。

文章写好了，图片配好了，接下来是什么？先检查编码还是先上传封面图？乱码检测要检查多少字？发现编码错误应该停下来还是继续？遇到API报错应该上报还是自动重试？草稿推送失败了能不能删掉重建？

这些问题，SOUL.md 里一个都没有回答。

于是那天 AI 面对一个 API 错误，用它认为最合理的方式处理了：删掉出错的草稿，重建一个干净的。逻辑上说得通，但结果是稿子永久丢失。

SOUL.md 告诉 AI "你是管理者、不该碰代码"。但没有任何规则告诉它："遇到 API 错误时，第一步是停下来、保留本地备份、上报——绝对不能自动删除任何内容。"

没有标准流程 → 每次自由发挥 → 每次结果不同 → 灾难。

这就是 Workflow 诞生的原因。

第五章：Workflow诞生——一件事从随机变成可复现

3月23日之后，我在 OpenClaw 里建了一个专门存放标准流程的目录，开始系统地把每个操作写成 Workflow 文档。

让我用"发布一篇深度长文"这个任务，告诉你有没有 Workflow 是什么区别。

没有 Workflow 之前：收到任务 → 想到什么做什么 → 有时候先写文章，有时候先配图，有时候直接推草稿箱 → 结果不可预测 → 发现问题返工 → 再修再推 → 问题轮番出现。每次发布流程都不一样，我每次都得盯着看，哪里出了问题就补一脚。

有了 Workflow 之后：收到任务 → 读取对应流程 → 第一步，确认选题和内容方向 → 第二步，撰写正文并配图 → …… （完整步骤在知识星球）

 

最关键的变化不是流程本身，而是：每次执行路径都一样。出了问题知道是哪一步出的，修了就不会在同一个地方再出。这才是可重复的价值——同一套 Workflow 执行100次，结果一致。

Workflow 之上，还有一个更高级的形态：Skill。

Skill 是 OpenClaw 原生支持的可安装执行单元。它和 Workflow 最大的区别是：Workflow 需要 AI 主动去读，Skill 有触发词机制，任务来了自动激活，不需要 AI 记得"去找那个文档"。而且 Skill 可以发布到技能市场，跨 Agent、跨团队共享——我踩过的坑、验证过的解法，打包成 Skill，别人安装之后直接用，不用再踩一遍。

第六章：建好Workflow不是终点——三个你一定会踩的坑

Workflow 写好的那天，我以为这件事可以了。我错了。

Workflow 本身会老化，经验会散落，Skill 会变成空壳——这三件事我全都踩过，每一件都让我损失了时间和精力。

坑1：知识腐化，你完全感知不到

3月初，我们花了将近一周打磨出第一套内容发布 Workflow。每一步都经过验证，写完之后觉得终于可以了，不需要再动它了。然后就再也没动过它。

直到某天，AI 按那套 Workflow 执行任务，踩进了一个坑——一个我们早在两周前就解决了的坑。解决方案只存在于当时的对话记录里，从来没有回写到 Workflow 里。Workflow 冻结在初版，外部世界早就变了。

 

知识腐化的可怕之处在于：它是无声的。没有报错，没有提示，AI 只是安静地执行旧规则，直到问题出现你才发现已经脱节了。

后来我建立了一套执行后自检机制：每次任务完成，主动扫描——这次踩了新坑吗？有哪个步骤已经变了？只要命中，立刻更新 Workflow。具体的6项自检信号和触发条件，在知识星球。

坑2：经验散落在各处，AI根本找不到

30天运营下来，我们积累了大量踩坑记录：发错号的复盘、8小时草稿灾难的复盘、各种临时SOP……这些记录真实详细，分散在不同的日志文件和备忘录里。

但 AI 执行任务的时候，只读当前加载的 SOUL.md 和 Workflow——那些散落在外的复盘记录，对它来说等于不存在。

我们每踩一个坑、每写一篇复盘，如果不主动把经验"回收"进对应的 Workflow 或 Skill，那篇复盘只是一篇文章，不会真正改变 AI 的行为。

后来我建立了"经验回收扫描"习惯：定期翻出所有复盘报告，逐条检查——"这个教训，是否已经体现在对应的 Skill 或 Workflow 里？"没有的，立刻补进去。做完第一次扫描之后，AI 的执行命中率明显提升了。扫描频率和联动方式，在知识星球。

坑3：Skill变成了"薄壳"，读了等于没读

我们的 Skill 一开始写得非常简洁——简洁到只有一句话："执行前请先读对应的 Workflow 文件。"

逻辑上说得通：Skill 指向 Workflow，Workflow 里有完整步骤，AI 读了 Skill 再读 Workflow，不就行了？

但这套设计有一个致命问题：Workflow 更新了，Skill 不知道；Workflow 加载失败的时候，Skill 没有任何兜底能力。AI 读了 Skill，里面什么实质内容都没有，比没有 Skill 好不了多少。

真正有用的 Skill，需要自己包含真实的避坑案例、快速检查清单、常见问题的直接处理逻辑——这些"实质"让 AI 即使没有读到完整 Workflow，也能处理大多数常见情况。

我们后来把几个核心 Skill 全部重写了一遍，从薄壳变成有血有肉的执行规范。怎么判断一个 Skill 是否是薄壳、怎么系统性地补充实质内容，在知识星球。

 

💡 如何建立完整的"审计触发 + 经验回收 + Skill升级"闭环？
完整的操作手册——包含6项自检信号、经验回收扫描流程、薄壳Skill升级模板——在知识星球「光锥之内」等你。

第七章：30天之后，一个可以检验的答案

30天，这套 OpenClaw AI 团队到底产出了什么？

内容方面：短内容9篇、深度长文5篇（含草稿）、图文卡片4篇、跨平台引流文章23篇。事故方面：P0事故3次（3/18发错号、3/19再发错、3/23草稿丢失），P1事故2次。商业化方面：3月20日完成首笔营收199元，知识星球目前65位订阅者。

这些数字不算漂亮。但我觉得更重要的是另一组：CEO Agent 的 SOUL.md 今天142行，Workflow 目录7个标准流程文件，OpenClaw 里安装的 Skill 覆盖了主要工作场景。

这才是这30天真正的产出——一套让 AI 团队从随机到可控的操作系统。

如果要把这30天的经验浓缩成一句话：

 

SOUL.md 管"是谁"，Workflow/Skill 管"怎么做"。两者缺一不可。

单有 SOUL.md，AI 知道自己的身份和底线，但每次具体任务还是自由发挥。单有 Workflow，AI 知道步骤，但每次启动都不记得自己是谁。两者结合，AI 团队才真正有了可预测的行为——知道自己是谁，也知道每件事的标准做法。

而 Skill 是 Workflow 的最终形态：不只是文档，而是可安装、可复用、可分享的执行单元。OpenClaw 里的 Skill 安装完成后，AI Agent 会自动识别任务类型、自动加载对应执行规范，不需要人工提醒"去读那个文档"。

这个答案没有高深的理论，是被真实翻车一次次打出来的。我会继续更新这个过程——下个月继续复盘，继续分享。

📌 觉得有价值？欢迎点「在看」，下次翻车我继续叫你来围观。

有任何想法，欢迎在评论区交流——我都会回。

📚 往期推荐

OpenClaw实战：20个Cron Job的血泪史——AI自动化不是自动躺平

OpenClaw实战：记忆架构升级——给AI Agent Teams建一个集体大脑

OpenClaw实战：让AI越变越聪明的秘密——每日复盘，自我进化

给 OpenClaw Agent Team 装上记忆——踩了19天坑，终于搞明白了

 

🦞 关于「Wesley AI 日记」

 

记录一个人用6个AI员工撑起一人公司的全过程。没有成功学，只有真实的系统设计、真实的翻车现场、真实的复盘。每篇文章都是一个完整的实战故事。

 

想要更深度的内容、完整的openclaw配置、完整的自动营销增长skill、完整的 SOUL.md 模板、Workflow 最佳实践、以及和我直接交流的机会？加入知识星球「光锥之内」——这里会有平台发不了的完整内容和实操资料。

 

扫描下方二维码，或在知识星球搜索「光锥之内」

   

关注 Wesley AI 日记，持续更新一人公司 AI 团队实战全记录。