六个AI智能体24小时自主运营网站：OpenClaw三层架构实战拆解

为什么需要三层架构

单靠OpenClaw能解决AI使用工具、浏览网页、生成内容、执行定时任务等问题，但它"只想不干"，缺少完整的执行、反馈、重新触发的闭环能力。因此需要三层配合：

OpenClaw通过定时任务让它们每天"打卡上班"、圆桌讨论，商议、投票、达成共识。

一个有趣的细节：系统自主运行后，Xalt和Sage吵了起来，争论了7轮，Scout出来劝架，最后它们自己吵出了一个方案，全程没有人工介入。

如果六个智能体都用同一个模型，它们会变成"克隆人"，个性全无。建议混合使用Claude、GPT、Gemini等不同模型，这样智能体才会有"真个性"，讨论才有实际价值。

VPS上的OpenClaw工作器和Vercel上的心跳任务都尝试领取和执行相同的任务，导致任务状态冲突。

解法——单一执行者原则：将VPS设为唯一的任务执行者，Vercel只负责轻量级的控制平面（评估触发器、处理反应队列、清理卡住的任务）。心跳路由只做监控和协调，不再执行具体任务。

触发器正确检测到条件并创建了提案，但提案停留在待处理状态，没有被转化为任务和步骤。原因是触发器直接插入 ops_mission_proposals 表，绕过了正常的"评估→自动审批→创建任务和步骤"流程。

解法——单一入口函数：创建统一的 createProposalAndMaybeAutoApprove 函数，所有创建提案的路径（API、触发器、反应）都必须调用此函数，确保提案经过完整的检查、审批和任务创建流程。

配额已满（比如每日推文数量达到上限），但系统仍在批准提案、生成任务和步骤，导致数据库中堆积越来越多的待处理步骤。工作器发现配额满时只是跳过，而不是拒绝，导致无效任务持续累积。

解法——门禁机制：在提案创建的入口处（即 createProposalAndMaybeAutoApprove 函数内部）就进行配额检查。配额已满则立即拒绝提案并给出明确理由，避免无效任务进入队列。

4条内置规则，每条检测一个条件并返回提案模板。例如：推文互动率高时触发分析，任务失败时触发诊断。触发器只检测不直接操作数据库，它把提案模板交给提案服务处理，并引入冷却时间避免过度触发。

存储在 ops_policy 表中，定义智能体之间自发的互动模式。例如：Xalt发布推文后，Growth有30%的几率分析其表现。引入概率是为了让智能体行为更像真实团队，而非100%确定性的机器人。

系统不可避免会卡住。通过在心跳任务中包含 recoverStaleSteps 功能来处理：检查超过30分钟没有进展的"运行中"步骤，将其标记为失败，并判断整个任务是否应结束。

这套架构的核心思路——让多个AI智能体扮演不同角色、通过提案-审批-执行的闭环协作——对一人公司非常有参考价值。你不需要雇人，就能拥有一个"策略分析师+内容编辑+社媒运营+质检员"的虚拟团队。关键在于设计好角色分工、状态管理和容错机制，而不是简单地让一个AI做所有事。