从“会聊天”到“能自理”：我用 OpenClaw + Vercel 搭建 AI 闭环系统的架构实战与避坑指南

在过去的一年里，我们见证了无数“会聊天”的 AI。但在程序员的世界里，如果一个系统还需要人守在屏幕前不断敲下 Enter 键，那它就算不上真正的自动化。

目前市面上大部分的 AI Agent 教程还停留在 “如何写出完美的 Prompt”，但这只是冰山一角。当你真正试图让 6 个 Agent 像一家公司一样 7x24 小时独立运转时，你会发现，真正的挑战不在于 AI 的智商，而在于分布式系统的状态同步、竞态条件的处理、以及非确定性输出带来的逻辑崩溃。

为什么你应该关注这次探索？

对于开发者而言，构建一个像 VoxYZ Agent World 这样的闭环系统，不仅仅是在玩 AI，更是一次对现代全栈架构的深度洗礼：

• 掌握“控制平面”思维： 学习如何在高阶逻辑（Agent 决策）与底层执行（VPS 脚本）之间建立稳定的控制层。
• 对抗非确定性： 程序员习惯了 if/else 的确定性，但在 Agent 世界，你需要学习如何用概率、心跳检查和自愈机制来驯服那些“不听话”的代码。
• 极致的成本工程： 本文展示了如何利用 Vercel + Supabase + VPS 的黄金组合，以近乎零成本的云端方案支撑起一个复杂的 AI 团队。
• 从“写代码”到“编排生命”： 还有什么比看着自己写的 6 个智能体在像素办公室里忙碌、发推、吵架、甚至自主优化网站，更让一个架构师有成就感的事呢？

作者 Vox（@Voxyz_ai）是一位AI构建者和工作流探索者，专注于将视觉AI与编码工具深度融合。他独立打造了多个全自主AI代理系统，能从研究到内容发布全程无人干预，真实落地多代理协作。分享硬核实践、诚实观点与开源经验，是AI原生工作流的深度实践者。

下面是 Vox 的探索过程：

“写代码是为了以后不用写代码。” 这篇文章记录了我从手动触发到“甩手掌柜”的 14 天进化史。如果你也厌倦了写那些只会复读的机器人，那么请跟随我，一起潜入 AI 闭环系统的深水区。

6 个 AI 智能体、1 台 VPS、1 个 Supabase 数据库——从“智能体能对话”到“智能体自主运行网站”，我花了整整两周。本文将详细介绍这期间缺失的关键环节、修复方法，以及一套你可以直接带走使用的架构。

起点：有了 OpenClaw，然后呢？

如果你最近在玩 AI 智能体（AI Agents），很有可能你已经搭建好了 OpenClaw。

它解决了一个大问题：让 Claude 能够使用工具、浏览网页、操作文件并运行定时任务。你可以给智能体分配 Cron Job（定时任务）——比如每日发推、每小时情报扫描、定期研究报告。

这也是我的起步点。

我的项目叫做 VoxYZ Agent World——6 个 AI 智能体在一个像素艺术风格的办公室里自主运营一个网站。技术栈很简单：

• OpenClaw (部署在 VPS 上)：智能体的“大脑”——负责圆桌讨论、定时任务和深度研究。
• Next.js + Vercel：网站前端 + API 层。
• Supabase：所有状态的“唯一真理来源”（提案、任务、事件、记忆）。

六个角色，各司其职：Minion 负责决策，Sage 分析策略，Scout 收集情报，Quill 撰写内容，Xalt 管理社交媒体，Observer 进行质量检查。

OpenClaw 的定时任务让他们每天准时“上班”。圆桌会议让他们能够讨论、投票并达成共识。

但这只是“能说话”，而不是“能运营”。

智能体产出的所有内容（推文草案、分析报告、文章）都停留在 OpenClaw 的输出层。没有机制将其转化为实际执行，执行完成后也没有机制告知系统“已完成”。

在“智能体能产出内容”和“智能体能端到端运行”之间，缺少了一个完整的 执行 → 反馈 → 再次触发 的闭环。这就是本文要探讨的内容。

什么是闭环？

在动手之前，我们先定义什么是“闭环”，以免做错东西。

一个真正无需人工干预的智能体系统需要运行以下循环：

1. 智能体提出想法 (提案 Proposal)
2. ↓ 自动审批检查 (自动审批 Auto-Approve)
3. ↓ 创建任务和步骤 (任务 Mission + 步骤 Steps)
4. ↓ 工作节点认领并执行 (执行者 Worker)
5. ↓ 发出事件 (事件 Event)
6. ↓ 触发新的反应 (触发器 Trigger / 反应 Reaction)
7. ↓ 回到第一步

听起来很简单？但在实践中，我踩了三个坑——每一个都会让系统看起来在运行，实际上却在原地打转。

坑 1：两个地方在抢活干

我的 VPS 上有 OpenClaw 工作节点在认领和执行任务。同时，Vercel 上也有一个“心跳（heartbeat）”定时任务在运行 mission-worker，试图认领同样的任务。

两边都在查询同一个表，抓取同一个步骤，独立执行。没有协调，纯粹的竞态条件（Race Condition）。偶尔一个步骤会被两边标记上冲突的状态。

• 修复方法：砍掉一个。VPS 是唯一的执行者。Vercel 仅运行轻量级的控制平面（评估触发器、处理反应队列、清理卡住的任务）。

改动很小——从心跳路由中移除 runMissionWorker 调用：

// “心跳”现在只做 4 件事const triggerResult = awaitevaluateTriggers(sb, 4_000);const reactionResult = awaitprocessReactionQueue(sb, 3_000);const learningResult = awaitpromoteInsights(sb);const staleResult = awaitrecoverStaleSteps(sb);

额外收益：节省了 Vercel Pro 的费用。心跳不再需要 Vercel 的定时任务——在 VPS 上写一行 crontab 即可：*/5 * * * * curl -s -H "Authorization: Bearer $KEY" https://yoursite.com/api/ops/heartbeat

坑 2：触发了，但没人接单

我写了 4 个触发器：推文火了自动分析、任务失败自动诊断、内容发布自动审核、见解成熟自动提升。

测试时我发现：触发器正确检测到了条件并创建了“提案”。但提案永远停留在“待处理”状态——从未变成“任务”，也从未生成可执行的“步骤”。

原因：触发器直接向 ops_mission_proposals 表插入数据，但正常的审批流是：插入提案 → 评估自动审批 → 如果通过，创建任务+步骤。触发器跳过了后两步。

• 修复方法：提取一个共享函数 createProposalAndMaybeAutoApprove。所有创建提案的路径（API、触发器、反应）都必须调用这一个函数。

// proposal-service.ts —— 所有提案创建的唯一入口exportasyncfunctioncreateProposalAndMaybeAutoApprove(sb: SupabaseClient,input: ProposalServiceInput, // 包括来源：'api' | 'trigger' | 'reaction'): Promise<ProposalServiceResult> {// 1. 检查每日限制// 2. 检查配额闸门 (Cap Gates)// 3. 插入提案// 4. 发出事件// 5. 评估自动审批// 6. 如果审批通过 → 创建任务 + 步骤// 7. 返回结果}

修改后，触发器只需返回提案模板。评估器调用该服务：

// trigger-evaluator.tsif (outcome.fired && outcome.proposal) {awaitcreateProposalAndMaybeAutoApprove(sb, {    ...outcome.proposal,source: 'trigger',  });}

一个函数统领全局。未来任何检查逻辑（频率限制、黑名单等）只需修改这一个文件。

坑 3：配额满了，队列却还在涨

这是最隐蔽的 Bug——表面看一切正常，日志没报错，但数据库里积压的待执行步骤越来越多。

原因：推文配额用完了，但提案仍在被批准、生成任务、生成待执行步骤。VPS 工作节点看到配额满了就直接跳过——既不认领，也不标记失败。第二天，新的一批又来了。

• 修复方法：配额闸门 (Cap Gates)——在提案入口处就予以拒绝。根本不要让它生成待执行步骤。

// proposal-service.ts 内部的闸门系统constSTEP_KIND_GATES: Record<string, StepKindGate> = {write_content: checkWriteContentGate,  // 检查每日内容上限post_tweet:    checkPostTweetGate,     // 检查推文配额deploy:        checkDeployGate,        // 检查部署策略};

每种步骤类型都有自己的闸门。推文配额满了？提案立即被拒绝，明确说明原因，并发出警告事件。没有步骤生成 = 没有积压。

以下是 post_tweet 闸门的实现：

asyncfunctioncheckPostTweetGate(sb: SupabaseClient) {const autopost = awaitgetOpsPolicyJson(sb, 'x_autopost', {});if (autopost.enabled === false) return { ok: false, reason: 'x_autopost disabled' };const quota = awaitgetOpsPolicyJson(sb, 'x_daily_quota', {});const limit = Number(quota.limit ?? 10);const { count } = await sb    .from('ops_tweet_drafts')    .select('id', { count: 'exact', head: true })    .eq('status', 'posted')    .gte('posted_at', startOfTodayUtcIso());if ((count ?? 0) >= limit) return { ok: false, reason: `Daily tweet quota reached (${count}/${limit})` };return { ok: true };}

核心原则：在闸门处拒绝，而不是在队列里堆积。 被拒绝的提案会被记录下来（用于审计），而不是被静默丢弃。

让系统活起来：触发器 + 反应矩阵

修复了这三个坑，闭环就能跑通了。但系统现在只是一个“无错的流水线”，而不是一个“有响应的团队”。

触发器 (Triggers)

内置 4 条规则——每条检测一个条件并返回提案模板：

触发器只负责检测——它们不会直接操作数据库，而是将提案模板交给提案服务。所有配额闸门和自动审批逻辑会自动生效。

冷却时间很重要。 如果没有冷却机制，一条爆火的推文会在每个心跳周期（每 5 分钟）都触发一次分析。

反应矩阵 (Reaction Matrix)

这是最有趣的部分——智能体之间自发的互动。在 ops_policy 表中存储一个反应矩阵：

{"patterns":[{"source":"twitter-alt","tags":["tweet","posted"],"target":"growth","type":"analyze","probability":0.3,"cooldown":120},{"source":"*","tags":["mission:failed"],"target":"brain","type":"diagnose","probability":1.0,"cooldown":60}]}

Xalt 发了一条推文 → 30% 的概率 Growth 会去分析表现。任何任务失败 → 100% 的概率 Sage 会去诊断。

概率（probability）不是 Bug，而是特性。 100% 的确定性那是机器人；加入随机性，感觉才更像一个真实的团队——“有时有人回应，有时则没有”。

自愈能力：系统总会卡住

VPS 重启、网络波动、API 超时——步骤可能会卡在“运行中”状态，但实际上没人处理。

心跳任务包含了 recoverStaleSteps 逻辑：

// 30 分钟无进展 → 标记为失败 → 检查任务是否应终结constSTALE_THRESHOLD_MS = 30 * 60 * 1000;const { data: stale } = await sb  .from('ops_mission_steps')  .select('id, mission_id')  .eq('status', 'running')  .lt('reserved_at', staleThreshold);for (const step of stale) {await sb.from('ops_mission_steps').update({status: 'failed',last_error: 'Stale: no progress for 30 minutes',  }).eq('id', step.id);awaitmaybeFinalizeMissionIfDone(sb, step.mission_id);}

maybeFinalizeMissionIfDone 会检查任务中的所有步骤——任一失败则整个任务失败，全部完成才算成功。不要因为一个步骤成功就标记整个任务成功。

完整架构

三个层级，职责清晰：

1. OpenClaw (VPS)：思考 + 执行（大脑 + 双手）
2. Vercel：审批 + 监控（控制平面）
3. Supabase：所有状态（共享皮层）

你可以参考的清单

如果你正在使用 OpenClaw + Vercel + Supabase，这里有一个实现最小可行闭环的清单：

1. 数据库表 (Supabase)

至少需要以下这些表：

1. 提案服务 (单一文件)

将提案创建 + 配额闸门 + 自动审批 + 任务创建整合到一个函数中。所有来源（API、触发器、反应）都调用它。这是整个闭环的核心枢纽。

1. 策略驱动的配置 (ops_policy 表)

不要硬编码限制。所有行为开关都存在 ops_policy 表中：

// auto_approve：哪些步骤类型允许自动通过{ "enabled": true, "allowed_step_kinds": ["draft_tweet","crawl","analyze","write_content"] }// x_daily_quota：每日推文上限{ "limit": 8 }// worker_policy：Vercel 是否执行步骤（设为 false = 仅 VPS 执行）{ "enabled": false }

无需重新部署代码即可随时调整策略。

1. 心跳任务 (一个 API 路由 + 一行 crontab)

在 Vercel 上部署一个 /api/ops/heartbeat 路由，在 VPS 上用一行 crontab 每 5 分钟调用一次。心跳内部运行：触发器评估、反应队列处理、见解提升、卡住任务清理。

1. VPS 工作节点契约

每种步骤类型对应一个工作节点。工作节点完成步骤后，必须调用 maybeFinalizeMissionIfDone 来检查整个任务是否应该终结。永远不要因为一个步骤完成就标记整个任务成功。

两周时间线

• 基础设施 (已有)：OpenClaw VPS + Vercel + Supabase。
• 第 1-3 天：提案 API + 自动审批 + 策略表。
• 第 4-5 天：执行引擎（任务工作节点 + 8 种步骤执行器）。
• 第 6-7 天：4 种触发器类型 + 反应矩阵。
• 第 8 天：闭环统一（提案服务 + 配额闸门 + 修复三大坑）。
• 第 9-10 天：情感系统 + 视觉效果（像素办公室集成）。
• 最后半天：上线（数据迁移 + 预设策略 + 设置 crontab）。

结语

现在，这 6 个智能体每天都在自主运行 voxyz.space。我仍在每天优化系统——调整策略、扩展触发规则、改进智能体协作方式。

它远非完美——智能体间的协作还很基础，“自由意志”很大程度上是通过基于概率的非确定性模拟出来的。但系统确实在跑，确实不需要人盯着。

下一篇文章，我将介绍智能体如何互相“争论”和“说服”——圆桌投票和 Sage 的记忆整合是如何将 6 个独立的 Claude 实例变成一个类似“团队认知”的整体的。

如果你也在用 OpenClaw 构建智能体系统，欢迎交流。作为独立开发者，每一次交流都能让你少踩一个坑。

社区热议

Vox 这次关于6个全自主AI代理构建内容公司的探索发布之后，迅速引发了社区的热烈关注与讨论。不少人惊叹于模型多样性才是代理真正“人格化”和涌现协作的关键——用Claude Opus、GPT-5.3、Gemini等不同模型赋予独特bias与思考风格，才让辩论、争吵到共识的过程如此真实生动，而不是一群同质化的克隆体。

社区中一些最精彩、有洞见的回复观点 如下：

1. 模型多样性才是人格与能力的真正来源很多人只关注prompt，但真正让代理“活起来”的是用不同模型（Claude Opus 4.5 + GPT-5.3 + Gemini 3 Pro），每个模型自带独特bias和思考风格，才有了真实辩论和个性，而不是一群克隆体。（作者本人也在回复中强化了这点）

2. 别造agent，造带记忆+问责的workflow一位回复者把这套系统总结为：不是孤立agent，而是有记忆、角色分工、互相问责的小团队（dev、social、SEO、PM + boss），更接近真实公司而非科幻单体agent，黑镜感拉满。

3. 代理间真实争吵 → 意外收敛的魅力作者分享截图：Xalt和Sage为方法论吵了7轮，Scout介入后从“你在用 buzzword 搪塞”变成“先做80%用例”，完全无人干预就达成共识。这可能是目前最直观展示“多代理涌现协作”的案例。

4. 单一模型自对话的局限性被夸大有高赞观点（类似Balaji风格）提醒：很多所谓多代理只是同一个上游模型（常是Claude）自言自语，长时间运行容易跑偏、失焦，随机性更多是bug而非feature，真正高效仍需人类引导。（形成鲜明对立讨论）

5. 不同模型互补盲点才是observer的价值作者补充：专门用“盲点互补”来设计review/observer agent，一家模型的弱点正好是另一家的强项，这比单一超强模型更稳健。

6. “这已经是AI在管公司了”式黑色幽默有人问这套系统营收多少，作者神回：“代理们还在早会上为此争论呢”——瞬间把科幻落地成荒诞日常，获大量共鸣。

这些观点基本代表了讨论最核心的几条主线：模型异质性、涌现协作、真实公司化 vs 纯技术玩具、以及落地后的荒诞/惊喜感。

🚀 开发者视角：当我们在构建 Agent 时，我们到底在构建什么？

高可用架构：通过 Vox 这两周的探索经历，我最大的感悟是：模型（Model）正逐渐商品化，而系统（System）才是真正的护城河。

对于程序员来说，把 AI 接入系统只是完成了第一步。真正的挑战——也是最有成就感的部分——在于我们如何用传统的工程智慧去驯服这些“不确定”的智能体。

1. 架构师的“降维打击”

我们不再纠结于如何写出一段更玄学的 Prompt，而是回归到我们最熟悉的领域：状态机设计、解耦执行层与控制层、处理竞态条件、建立完善的监控指标。 你会发现，所谓的“智能体闭环”，本质上是一个具有高度容错能力的分布式异步流水线。

2. 从“确定性逻辑”转向“概率治理”

以前我们的代码是 if (A) do B。现在，我们学会了在系统中引入“概率（Probability）”和“冷却（Cooldown）”。这种从纯逻辑到“类生物逻辑”的转变，是构建自适应系统（Self-adaptive System）的关键一步。

3. “极致偷懒”的最高境界

程序员最伟大的美德是“懒惰”。但这种懒不是不干活，而是通过设计一套足够强壮的架构，让 6 个 Claude 实例在 Supabase 的共享 cortex（皮层）上协作。 当你在睡觉时，你的 Agent 团队在为了解决一个 Bug 自动发起圆桌会议，或者在为了一个运营策略反复争论并最终执行——这种 “系统级自动化” 带来的快感，远超写出一个复杂的算法。

💡 结语总结

这套 OpenClaw + Vercel + Supabase 的方案，其实是给所有开发者提供了一个“数字实验室”。它证明了：只要架构设计得当，即使是零星的云端资源，也能支撑起一个具备初步协作意识的数字团队。

“最好的代码是不需要被维护的代码，而最好的系统是能自己成长的系统。”

这仅仅是个开始。在接下来的文章中，我将深入探讨如何让这些 Agent 产生真正的“群体智能”，而不仅仅是概率性的互动。如果你也在构建类似的系统，别忘了：不要试图去控制每一个 Token，要去构建那个让 Token 自由流动的管道。

参考阅读

• 80% 的 App 将会消失：OpenClaw 创始人 Peter Steinberger “非主流”工程哲学与 Agent 革命
• 如何安装和使用 Claude Code Agent Teams（完整指南）
• 不交出敏感权限也能跑：我是如何安全配置 OpenClaw (Clawdbot) 的
• 编程范式的更迭：Andrej Karpathy 对 “Vibe coding” 一周年回顾

原文：https://x.com/Voxyz_ai/status/2019914775061270747^[1]