全球首家无人公司开业！OpenClaw 24小时不休，疯狂碾压打工人|openclaw|无人公司|智能体|疯狂|触发器|调用

新智元报道

编辑：KingHZ

【新智元导读】27岁独立开发者靠它月入数万，前市场经理睡觉时它写邮件赚钱，柏林辍学生卖自定义技能赚12.7万美元——AI智能体的「iPhone时刻」已来，只是钱还没平均分。

AI智能体领域，刚刚迎来了它的「iPhone 时刻」。

但拐点不在「更会聊天」「智商更高」，而在一件事：它能自己把事做完。

当世界还在争论「AI是否会抢走工作」时，一小批人已经绕开了整个辩论。

他们开始建造，不再「套壳ChatGPT」，而是构建自主运行的业务单元。

一名27岁的得州独立开发者，靠出售网页抓取自动化程序，一月份赚了43,000美元。

一位多伦多的前市场部经理，构建了一个邮件文案生成智能体，每月带来8,200美元收入——而她在睡觉。

一位柏林大学辍学生，在一个两个月前还不存在的市场上，售出了价值127,000美元的自定义OpenClaw「Agent技能」。

背后是同一个趋势：硅基劳动力开始工作。

OpenClaw首个10亿美元应用场景

而OpenClaw第一个10亿美元应用场景，终于来了。

受YouTube频道《Dumb Money》社交套利策略的启发，OpenClaw全年无休、分秒必争地自动扫描社交媒体上的病毒式趋势。

通过「售罄」等关键词，智能体抢先识别出潜在的库存机会，比如星巴克保温杯或沃尔玛联名商品。

一旦发现潜在信号，OpenClaw会把这些趋势当作可能的股票/市场超额收益机会。

因为这些消费热潮往往会提前反映在相关公司股价上，而华尔街主流分析通常滞后。

这正是自主智能体大放异彩的地方——全年无休、全天候运转。

人类每天可能只刷3次社交媒体，而智能体每15分钟就检查一次。

现在想象一下，有10个智能体分别监控不同的平台——TikTok、X、Reddit、Discord、Telegram——所有信息都汇总到一个仪表盘上。

这已经不是AI工具了，而是一场市场情报行动。

未来已来，只是分布不均。

现在智能体如此智能，这种「硅基劳动力」的出现基本上合乎逻辑、顺理成章的下一步了。

全球首批OpenClaw企业，全年无休

很多人说是炒作。Alex Finn不争辩，他直接建「改变世界的产物」。

他正在打造首个OpenClaw智能体公司，让它7×24小时工作。

目前，Alex有2名员工在岗（本地部署在Mac Studio上），2名员工外包（Opus 4.6与Codex 5.3）。那2名本地员工全天候为他工作。

它们不进食、不睡觉、不抱怨、不要五险一金。

而他的全部前期投入仅是一份终身制2万美元合约（两台512GB内存+4TB固态硬盘的Mac Studio）。

比起之前面试的那些年薪10万美元的人类应聘者，他认为这简直太划算了。

今夜安睡时，它们在工作。明天看超级碗橄榄球比赛时，它们仍在工作。

它们会刷遍X和Reddit，寻找待解决的难题，并持续编写程序——完全无需监督。

这就是Alex Finn的环球企业。

近日，他将搭建官网，让大家能实时观看每名员工的工作状态

他确信世上再无他人进行着类似的创造。这是史上首支全天候自主工作的劳动力。

这里最有趣的部分甚至不是「全天候劳动力」，而是「完全无需任何监督」。

当然，不是他一个人让OpenClaw智能体为7x24小时不停为他工作：

可以上下滚动的图片

欢迎来到未来。

这一切是如何做到的呢？

世界首个智能体运行的网站

过去三周，投资者 Ihtesham Ali 混迹社交平台Discord、Reddit和OpenClaw小圈子，专找「真用智能体赚钱的人」。

他统计到：一个月里，10个人用智能体赚了84.7万美元。

而现在，第一家「由智能体运营」的公司出现了：VoxYZ。

VoxYZ网站发起人、网友Vox

配置极简：6个智能体 + 1台VPS + 1个Supabase 数据库。

两周时间，从「闲聊」升级到「自主运营网站」。

起点来自OpenClaw：当AI智能体不再仅仅是回答问题，而是真正运营一家公司时会发生什么。

它们研究市场、撰写内容、发布社交媒体、交付产品……所有行动都无需人类指令。

这，正是全球第一个OpenClaw运营的公司VoxYZ——

0人类提示词，一切都是智能体的决定。

一切的起点：OpenClaw

OpenClaw解决了一个很大的问题：让Claude能够使用工具、浏览网页、操作文件、运行定时任务。

你可以给Agent分配定时任务——每天发推、每小时情报扫描、定期研究报告等等。

一切从这里开始。

这个项目叫做VoxYZ Agent World：6个AI智能体在一个像素风办公室里自主运营一个网站。

技术栈非常简单：

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

六个角色，各司其职：

首席执行官幕僚长Minion：做决策,协调任务、分派职责。
研究主管Sage：分析战略，深入分析，制定战略。
增长主管Scout：收集情报，发掘潜在客户，追踪市场信号，侦察新机遇。
创意总监Quill：撰写文案，设计内容，构思叙事。
社交媒体总监Xalt：管理社交媒体，发布动态，互动交流，扩大受众。
公司观察员Observer：做质量检查，观察全局，记录历程。

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

OpenClaw的定时cron任务让它们每天「上班打卡」。圆桌机制让它们可以讨论、投票、达成共识。

但这只是「能说话」，而不是「能干活」。

智能体产出的所有东西——起草的推文、分析报告、内容稿件——都还停留在OpenClaw的输出层。没有变成真正的执行，也没有机制在执行完成后告诉系统「已完成」。

从「Agent能产出内容」到「Agent能端到端完成闭环操作」，中间还缺了一个完整的「执行→反馈→重新触发」的循环。

真正的智能体循环

首先定义一下「闭环」。

一个真正无需值守的智能体系统需要运行这个循环：

智能体提出想法（提案）

自动审批检查（自动批准）

创建任务+步骤（任务+步骤）

工作节点领取并执行（工作者）

发出事件（事件）

触发新的反应（触发/反应）

回到第一步

听起来很简单？

实际上，埋了至少三个坑——每个都让系统「看起来在运行，但实际上在原地打转」。

第一个坑：两处地方抢工作

VPS上有OpenClaw工作者在领取和执行任务。

同时，Vercel上有个心跳定时任务在运行任务工作者，也想领取同样的任务。

两边查询同一张表，抓取同一步骤，独立执行。没有协调，纯属竞争条件。偶尔一个步骤会被两边打上冲突的状态标签。

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

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

//心跳现在只做4件事const triggerResult = await evaluateTriggers(sb, 4_000);const reactionResult = await processReactionQueue(sb, 3_000);const learningResult = await promoteInsights(sb);const staleResult = await recoverStaleSteps(sb);

额外好处：省了Vercel Pro的费用。心跳不再需要Vercel的定时任务——VPS上的一行crontab就能搞定：

*/5 * * * * curl -s -H "Authorization: Bearer $KEY" https://yoursite.com/api/ops/heartbeat

第二个坑：任务触发了，但没人接手

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

测试时我发现：触发器正确地检测到了条件并创建了提案。但提案永远处于待定状态——从未变成任务，从未生成可执行步骤。

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

修复：提取一个共享函数createProposalAndMaybeAutoApprove。每个创建提案的路径——API、触发器、反应——都必须调用这个函数。

// proposal-service.ts —— 所有提案创建的单一入口export async function createProposalAndMaybeAutoApprove(  sb: SupabaseClient,  input: ProposalServiceInput, // 包括 source: 'api' | 'trigger' | 'reaction'): Promise

 {  // 1. 检查每日限制  // 2. 检查容量关口（下面解释）  // 3. 插入提案  // 4. 发出事件  // 5. 评估自动批准  // 6. 如果批准 → 创建任务 + 步骤  // 7. 返回结果}修改后，触发器只返回提案模板。评估器调用这个服务：// trigger-evaluator.tsif (outcome.fired && outcome.proposal) {  await createProposalAndMaybeAutoApprove(sb, {    ...outcome.proposal,    source: 'trigger',  });}

一个函数统治所有。以后任何检查逻辑（速率限制、黑名单、新限额）——只改一个文件。

第三个坑：队列在配额满时不断增长

最隐蔽的bug——表面上一切正常，日志没有错误，但数据库里排队的步骤越来越多。

原因：推文配额满了，但提案仍在被批准，生成任务，生成排队步骤。VPS工作者看到配额满了就直接跳过 —— 不领取，不标记为失败。第二天，又来一批。

修复：容量关口——在提案入口点就拒绝。从根本上不让它生成排队步骤。

// proposal-service.ts 内部的关口系统const STEP_KIND_GATES: Record

 = {  write_content: checkWriteContentGate, // 检查每日内容容量  post_tweet:    checkPostTweetGate,    // 检查推文配额  deploy:        checkDeployGate,       // 检查部署策略};

每种步骤类型都有自己的关口。推文配额满了？提案立即被拒绝，理由清晰说明，发出警告事件。没有排队步骤 = 没有堆积。

这是post_twee关口的例子：

async function checkPostTweetGate(sb: SupabaseClient) {  const autopost = await getOpsPolicyJson(sb, 'x_autopost', {});  if (autopost.enabled === false) return { ok: false, reason: 'x_autopost disabled' };  const quota = await getOpsPolicyJson(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 };}

关键原则：在关口拒绝，不要在队列里堆积。被拒绝的提案会被记录（用于审计），而不是无声地丢弃。

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

三个坑都填平了，循环就能工作了。但这系统还只是一个「无错误的流水线」，不是「响应式团队」。

触发器

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

触发器只做检测——它们不直接操作数据库，而是将提案模板交给提案服务。所有容量关口和自动批准逻辑都会自动应用。

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

反应矩阵

最有意思的部分——自发的智能体间互动。

一个存储在ops_polic表中的reaction_matrix：

{  "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会诊断。

概率不是bug，而是特性。

100%确定性 = 机器人。加点随机性 = 感觉更像真实的团队，「有时有人回应，有时没人理」。

自我修复：系统总会卡住

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

心跳包含recoverStaleSteps：

// 30分钟无进展 → 标记失败 → 检查任务是否应结束const STALE_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);  await maybeFinalizeMissionIfDone(sb, step.mission_id);}

maybeFinalizeMissionIfDone检查任务中的所有步骤——任何一步失败意味着整个任务失败，全部完成意味着成功。不再有“因为一步成功就把整个任务标记为成功”的情况。

完整架构

三层结构，职责清晰：