OpenClaw是个大傻春:批次ID未回写、权限拒绝、文件缺失全纪录

What’s up， 大家！这是我的第 51 篇原创文章。

这是这组 OpenClaw / Hermes 多 Agent 调试复盘的第二篇。第一篇讲总时间线，第三篇讲 Hermes；这一篇只盯 OpenClaw，不把 Hermes 的任务委派、网关协议或飞书回执混进来。

OpenClaw 最让我抓狂的地方，不是它完全不能动，而是它总能动一点、停一点、偏一点，然后留下一个很像“已经努力过”的现场。我已经反复提醒要锁定批次、不要新建任务、不要口头保证、要讲清当前状态，它还是经常像没听懂一样在原地绕。

WF07 在这里只是压力测试工具。它步骤长、状态多、认证链复杂，很适合检查 OpenClaw 这种多 Agent 框架到底有没有执行边界。结果很明显：它最容易在“当前到底跑哪一批、卡在哪一步、谁负责继续”这几个问题上翻车。

OpenClaw 的七类现场问题

OpenClaw 的问题不是单点故障，而是一串现场问题叠在一起：批次未回写、权限边界、文件生成、Kanban 状态、微信认证、worker 中断、归档语义。单看任何一条都像能解释，合起来就会变成“系统看起来一直在干活，但我不知道到底完成了什么”。

这七类问题里，0426 的主清单断点、0518 的认证/DNS 阻塞、0605 的前置检查阻塞是最硬的三条。权限、路径、正文文件和归档语义则更像慢性病：一次不一定致命，但会持续消耗我对系统的信任。

同样重要的是，只有问题分类还不够。凡是没有逐条证据、还残留占位符或空链接的版本，都不能当成正式复盘；这篇只保留能被批次、远端 run 或本地报告验证的槽点。

更重要的是，WF07 不是只跑了几个零散批次。本地执行率报告里能看到从 20260130 到 20260629 的一串历史批次：20260130、20260219、20260225、20260228、20260308、20260311、20260315、20260318、20260322、20260329、20260330、20260406、20260412、20260421、20260426、20260505、20260513、20260518、20260524、20260602、20260607、20260607_20260610、20260625、20260629。下面这张图先把 WF07 原始链路说清楚，后文提到 Step2、Step3、Step4，都是按这张图来理解。

这张批次表不是流水账，它只想说明三件事：WF07 在本地能闭环；OpenClaw 的问题出在远端接管长链路后的断点和回执；不同批次不能互相背锅。

0426：最关键的问题不是采集，而是入主清单断了

0426 这次非常典型。我后来反复追问“到底昨天这些 agent 在干嘛”，原因很简单：OpenClaw 跑了很久，但没有把“当前断点”说清楚。

后来复盘出来的事实是：采集已经有结果，解析也形成了 33 条候选更新，但入库动作没有把这 33 条写入主清单。也就是说，真正续跑点不是重新采集，而是补写 33 条素材记录，再只针对这 33 条继续分析、生产和审核。

0426 正确续跑策略：
1. 备份主清单
2. 从采集解析结果里读取 33 条候选更新
3. 精确匹配本地正文文件
4. 生成 33 条素材记录
5. 更新批次字段到 20260426 的入库断点
6. 只对这 33 条跑后续分析、生产和审核
7. 更新执行率报告和状态表

这个结论出来之前，现场绕了太多弯。最让我愤怒的点，不是某条命令写成 update --update-only，而是 agent 分析没有重点：到底为什么断、怎么接着做、接哪一步，它说不清楚。

OpenClaw 的第一类坑：主 Agent 像单干户

OpenClaw 这类框架最容易出现一种错位：架构上写的是多 Agent 协作，执行上主 Agent 仍然把自己当成唯一操作者。它能调用 skill，就懒得分配；它分不清边界，就把任务往自己身上揽。

WF07 这种任务最怕这个。采集、解析、入库、分析、审核本来就应该各自有明确边界。结果主 Agent 一单干，就会出现下面这种情况：

这也是为什么我会骂得那么狠。不是因为讨厌自动化，而是因为我在 Windows 本地已经跑顺过，到了 OpenClaw 反而变成“谁都像在干活，谁都没把完整链路交出来”。

OpenClaw 的第二类坑：批次状态像流沙

WF07 的核心是批次。没有批次，所有素材都是一锅粥。

0426 的断点本来非常明确：33 条没有进入主清单。可后面现场又出现“主清单回到 20260421 的旧断点”“昨天干的是 wf07-analyze 不是新采集批次”“最后主批次号仍不是 20260426”的混乱。这种混乱不是小问题，它会直接决定后续分析、生产和审核处理的是正确对象还是旧对象。

这个图就是 OpenClaw 0426 的关键问题：它不是完全没跑，而是在“解析出候选更新 → 写入素材记录”这个关键转接处断了。后面再说分析、成文、审核，前提都已经歪了。

OpenClaw 的第三类坑：权限、路径、同步像三把小刀

我后来还追问过：服务器上到底有多少个 research 项目？是不是写到另一个目录去了？这不是无理取闹，因为当一个系统长期出现路径变量、权限、同步问题时，我自然会怀疑它到底在改哪一份文件。

本地复盘记录里能看到多次相关问题：权限污染、路径变量、同步冲突、Windows 与 Ansible 与 OpenClaw 三端 hash、.from_windows 历史残留、磁盘空间、中文路径编码等。任何一个单点看起来都能解释，但加在一起，给我的体验就是“这个系统不稳，证据还不够硬”。

权限拒绝和文件缺失不是比 0426 这个入库断点更核心的主线，但它们会放大我的不信任：你到底读的是不是正式 env，写的是不是正式目录，生成的是不是正式正文文件，最后有没有清单能证明。这些问题一旦说不清，我自然会怀疑所谓多 Agent 只是在换地方制造待排查现场。

**操作流程：**定位权威目录 → 核批次字段 → 核素材数量 → 核执行率报告 → 核三端同步 → 再允许恢复定时

详细步骤：

**验证检查：**如果主清单、报告、远端 run、三端 hash 任何一个指向不同批次，就禁止写“已跑通”。

0518：远端记录显示 Step2 就卡住

远端记录更直观。0518 的运行状态显示：先有微信认证阻塞，后续又进入分析、生产和审核的续跑状态。记录里还有两个关键信息：我扫码时提示系统错误，重试二维码时又遇到 mp.weixin.qq.com DNS 失败。

这说明 OpenClaw 在这里不是“业务跑完了”，而是采集前的认证链就没过去。正确行为应该是：同线程请求我补认证，保留断点，修复网络或 DNS 后从同一任务继续。错误行为是：写一段泛泛总结，或者让我重新发新任务，把原任务现场冲掉。

0518 远端状态能读出四层意思：
1. 任务没有进入业务分析，而是卡在登录认证阶段。
2. 飞书任务卡处在阻塞状态，需要我补认证动作。
3. 前一次扫码提示系统错误，不是我没有配合。
4. 后续重试又遇到微信域名解析失败，说明网络和认证链都没有闭环。

这类证据对我很重要。它把“感觉没跑通”变成了“采集前认证和 DNS 阻塞”，下一步动作才有方向。

0520：二维码没加载全，是严重反馈不是小插曲

0520 的远端飞书任务里，我的反馈非常重，核心意思只有一句：二维码都没加载全，现在到底是怎么发二维码的。公开稿不照抄原始粗口，但这个现场必须写，因为它说明 OpenClaw 的认证链路没有把“生成二维码、发送二维码、看到完整二维码、扫码成功、认证成功”拆开。

如果系统只记录“二维码已发送”，却没有证明图片完整送达、扫码成功、认证成功回传，那我看到的就是一张可能坏掉的二维码和一句含糊的等待。这不是体验细节，这是采集前认证链的硬阻塞。

二维码链路应该分层：
生成二维码 -> 发到飞书 -> 我能看到完整图片 -> 等待扫码 -> 认证成功或认证失败

OpenClaw 在这里傻春的地方，是把“我把二维码发出去了”当成了“认证流程正在正常推进”。我骂得重，正是因为这一步把责任推回给了扫码的人，而系统自己没有证明图片真的可用。

0524 到 0528：同卡续跑靠约束硬拽回来

0524/0528 这一段也不能漏。远端历史显示，后续指令一直在强调：沿原任务和原任务卡从认证与采集断点续跑，不得新建任务编号，不得新建 Kanban 任务卡，不得另起批次。也就是说，系统不是天然守住了断点，而是靠我这边反复纠正和补丁不断把它拉回原链路。

这类问题和 0426 是同一种病：长任务一旦断了，恢复动作必须绑定原批次、原卡、原证据目录。只要新建一个看似干净的任务，历史问题就会被盖住，后面再做本地/远端对账或发布审核就全乱。

更傻春的是，0524 远端记录里还能看到两类强反馈：一类是我追问系统是不是没停、为什么不继续、不报错、现在在干嘛；另一类是我追问“不要只口头说”，要求系统回顾中间实际做过什么、当前到底有哪些任务。对应记录里有多次“后台还有心跳、但最终回执没回来”的情况，也有当前追问卡、WF07 正式业务卡和后台执行器缺最终回执的核查结果。

0605：不是模型问题，是旧批次和磁盘前置不通过

0605 的远端证据要分阶段看。早期有前置检查失败、旧批次未终态和磁盘空间高风险；后续同卡又出现带警告通过、等待微信认证阻塞、不能继续执行等状态。也就是说，这不是一句“模型坏了”或“旧批次入库断点未终态”就能讲完，而是同卡多轮前置检查、阻塞、运行和认证阻塞叠在一起。

这次如果硬写成“模型又坏了”，就是错判。真正的问题是 OpenClaw 没有在进入业务前把前置条件讲清楚、回传清楚、收口清楚。磁盘、旧批次、入库断点未终态，都是可以解释的阻塞；不能解释的是阻塞之后我还得自己追问。

0607：起跑线补齐，不等于 WF07 已经跑完

到 0607，本地记录显示已经完成三段同步、扩容和服务复核：Windows 到 Ansible、Ansible 到 OpenClaw、OpenClaw 服务状态、Hermes 看板、网关健康状态等都做了检查。扩容后根盘空间恢复，服务也处于可用状态。

但这只能叫“起跑线补齐”，不能叫 WF07 全新飞书任务完成。真正的验收仍然要看：飞书新消息是否自动接单，是否建卡，前置检查是否通过，关键步骤是否都有证据记录，最终结果或错误是否自动回同线程。

这就是 OpenClaw 给我的核心教训：别把准备完成当业务完成。

0625 和 0629：不能只挑好写的批次复盘

我后来专门提醒：不止跑了表格里那几个批次。这个提醒是对的。20260625 的执行率报告明确写到，这一批一共有 111 条素材，后续复核到 75 条待加工、37 条文档和 37 条发布记录。它不是小插曲，而是一次大批量 WF07 实践。

0625 的价值在于，它证明系统已经进入“批量、报告、合并门禁、失败明细账、Dashboard”这些真实工程细节。只写 0426、0605、0607，会让读者误以为问题只出在早期试跑。实际情况是：越到后面，批次窗口、证据清单、去重、失败明细、发布审核边界越重要。

0629 也一样。当天 WF07 新批有 27 条候选更新，后续修过“同日 WF01 6 条污染”的统计口径；这和本组三篇 WF01 复盘发生在同一天，更需要分清工作流边界。

0627/0628：二维码已发出，不等于认证成功

0627 的远端会话里，我追问“到底是暂停了还是扫描失败了，我确实已经扫描了”。Hermes/OpenClaw 的回复里承认：历史只看到二维码已发出或等待扫码，没有看到新的完成记录或认证成功回传；二维码已发出只表示系统把图片发出来了，不等于我已经完成扫码，更不等于公众号认证成功。

这个判断本身终于说对了，但它也暴露了前面的问题：为什么要我追问到这一步，系统才把状态拆清楚？如果每次认证恢复都主动说明“二维码已发出、等待扫码、认证成功、认证失败”这几个状态，我就不会被迫猜“现在到底暂停了还是失败了”。

几个特别傻春的对话现场

这些对话的共同点是：我不是在要求系统永不失败，而是在要求系统失败时别装糊涂。OpenClaw 真要像一个调度入口，第一职责就是把状态讲清楚。

我对 OpenClaw 的最低要求

OpenClaw 可以失败，但失败必须留下人能看懂的证据。批次号要回写，权限问题要说清楚，正文文件要能数出来，任务卡阻塞要能追到当前执行，微信认证失败要保留断点，后台执行中断要能区分是模型、会话还是执行层。

公开复盘可以有火气，但不能只有火气。没有证据链的吐槽，只会让下一次排障继续从头猜。

我的建议：把 OpenClaw 当调度入口，不要当万能主脑

OpenClaw 不是完全没价值。它能当入口，能接飞书，能组织任务，能把文件和证据落盘。但至少在 WF07 这种长链路上，它不能被当成“全自动主脑”。

我现在更认可“虾和马单独养”的路线：每个 Agent 各自有清楚边界；采集只采集，分析只分析，写作只写作，审核只审核；统一入口只负责任务契约、状态推进和回执，不要让一个主 Agent 又当老板又当员工又当审计。

龙虾可以很会爬，野马也能跑天涯；别让它们乱拉车，路就不会塌。

如果你也被 OpenClaw、自动化工作流、批次状态和多 Agent 协作折腾过，欢迎在公众号后台回复「多agent」交流。成功经验通常很光鲜，失败现场才最有信息量。

历史文章，请看这里：

2026-05-09：你被骗了！OpenClaw是真的很难用！

2026-04-20：看完教程说部署只需一天？我花了六周才真正搞懂这套AI框架