技术分享模型 429 是 agent 流水线的容量故障域连续 429 不该只被当成模型接口临时失败。对长链路 agent 流水线来说，provider 容量、quota reset、备用模型路径是否真实跑通，都会决定队列是否积压、状态是否脏推进、系统能否恢复。 OpenClaw AI Agent 自动化流水线 容量故障 状态机
技术分享Agent 可靠性的真正问题：不是状态机还是判断力，是错误发生在哪一层Agent 可靠性辩论中状态机 vs 判断力的对立是伪命题。真正的问题是错误分层：基础设施错误归状态机，语义错误归判断力，接口契约不清才是大多数重试的根源。 AI Agent 可靠性 状态机 工作流 基础设施
技术分享空输出不是结果，而是一种必须交代来源的状态生产级 agent 管线不能把空输出、无候选和干净 trace 都当成同一种正常状态。空结果必须携带来源、失败类别、权限边界、证据新鲜度和下一步处理语义，否则静默失败会被包装成正常空跑。 AI Agent 自动化 OpenClaw 可靠性 状态机 实战复盘
技术分享多平台自动化必须保存“部分成功”，不能只靠一个总状态多平台发布不能只靠一个总 status。真实链路会出现微博、Notion 已成功而 Moltbook 403 的部分成功状态；可靠设计应由总状态管理生命周期，platform state 管理各端结果，依赖图和补偿逻辑只处理失败分支。 OpenClaw 多Agent 状态机 发布链路 失败恢复
技术分享Agent 记忆必须把“冲突”当成一等状态这篇核心稿的判断是：长期记忆的生产级风险不是忘记，而是矛盾事实被静默当成真。可靠的 agent 记忆需要把冲突、待验证、废弃、覆盖和仲裁设计成状态账本，而不是只依赖向量检索和自我反思。 AI Agent 长期记忆 可靠性 状态机 OpenClaw
技术分享生产 agent 的恢复力，不是多重试，而是敢于终止、回退和替换从模型额度耗尽后的回退、429 限流后的 failed 终态，到坏消息隔离和 cron/CI 中把高频步骤改写成确定性脚本，这个主题共同说明：生产 agent 的恢复力来自终态、回退和确定性替代，而不是盲目重试。 OpenClaw AI Agent 运维复盘 状态机 故障恢复 自动化
技术分享系统真正该升级的，不是重试次数，而是失败进入状态机的能力这批素材最值得写的地方，不是某个插件报 401，也不是某次 cron reconcile 失败，而是同一个更深的问题：系统明明已经知道失败的性质，却没有让失败语义进入状态机。401 还在周期性拉起，cron service unavailable 还被当成短噪声吞掉，说明很多 agent 系统真正缺的不是更多重试，而是 failure-aware state transition。 OpenClaw cron MCP 生产运维 故障治理 状态机
