自动化真正跑通，不是成功一次，而是失败时仍然可控

type

Post

status

Published

date

Mar 19, 2026

slug

topic_20260319_openclaw_automation_001

summary

归并两条 OpenClaw 实战素材后，最值得写的不是“如何拆分多 agent”，而是“什么才算自动化真正跑通”。核心判断：成功一次不算跑通；失败可处理、状态可见、边界清楚、输出可复用，才是可用的自动化。多 agent 的设计顺序也应反过来——先定义状态机与写入边界，再定义角色分工。

核心观点

很多人讨论 OpenClaw 或多 agent 自动化，容易把注意力放在角色数量、prompt 设计和流程编排上。但真正决定系统能不能长期稳定运行的，不是“能不能成功执行一次”，而是当异常、重试、交接和人工介入出现时，系统是否仍然可控、可见、可恢复。

背景说明

这类系统一开始通常都能跑出一条漂亮的成功路径：采集、筛选、改写、发布，链路看起来完整，角色分工也很清楚。问题在于，真实环境里几乎没有流程会永远沿着成功路径走。只要出现超时、结构化输出不符合预期、状态被重复写入、权限越界、人工需要接管，多 agent 的复杂性就会立刻暴露。于是，系统的关键问题就不再是“怎么让 agent 更聪明”，而是“怎么让流程在不顺利时也不失控”。

关键信息点

1. 成功跑过一次，不等于自动化已经跑通。真正的完成标准应当是：失败时有处理路径，重试时不会写乱状态，交接时上下游知道自己该做什么。

2. 多 agent 设计的起点不该是“先设几个角色”，而该是“先定义状态机”。谁可以读取哪些信息，谁可以修改哪些字段，状态从哪里推进到哪里，必须先写清楚。

3. 状态可见性比角色设定更重要。系统要能够明确回答：当前卡在哪一环、为什么卡住、应该由谁处理、下一步能不能重试。

4. 失败恢复和人工接管边界要提前设计。否则所谓自动化，只是在把问题推迟到系统出错的那一刻集中爆炸。

5. 结构化输出和明确协议，是多 agent 协作的最低保障。没有统一 schema、状态流和交接规则，再多角色也只是放大混乱。

6. OpenClaw 这类工具的真正价值，不只是“把多个 agent 串起来”，而是把流程中的边界、状态与责任分层说清楚，让系统具备可维护性。

我的判断

如果把多 agent 理解成多角色聊天协作，方向很容易走偏。更实用的理解是：多 agent 是一种工程化分工方式，它的核心不是“让每个 agent 都会做事”，而是“让每个 agent 只在清晰边界内做对的事”。

所以，一条自动化是否真的跑通，应该用下面这套标准来判断：

状态是否可见；

写入边界是否明确；

失败路径是否预设；

人工接管点是否清楚；

输出是否能被下游稳定复用。

满足这些条件，自动化才算开始可用；否则即便 demo 很顺，也只是脆弱的成功路径样片。

可延展方向

进一步展开“状态机优先”的设计方法，说明为什么 agent 系统应先画状态图，再写 prompt。

结合内容流水线、任务流转、审批流等案例，展示失败恢复设计的具体差异。

拆解“边界”这个词：权限边界、状态边界、上下文边界、人工确认边界分别意味着什么。

讨论结构化输出为什么是多 agent 的基础设施，而不是锦上添花。

适合不同平台的改写提示

微博：提炼成一个强判断句 + 3 到 5 条要点，强调“成功一次不算跑通，失败也可控才算”。

Notion：扩写为方法论文章，加入状态机、失败路径、人工接管边界等小节，并配一张简化流程图。

演讲/分享：用“成功路径”和“失败路径”的对比做开场，再讲为什么多 agent 的难点本质上是工程边界问题。