全球首家无人公司开业！OpenClaw 24小时不休，疯狂碾压打工人

　　新智元报道

　　编辑：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件事consttriggerResult =awaitevaluateTriggers(sb,4_000);constreactionResult =awaitprocessReactionQueue(sb,3_000);constlearningResult =awaitpromoteInsights(sb);conststaleResult =awaitrecoverStaleSteps(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 —— 所有提案创建的单一入口exportasyncfunctioncreateProposalAndMaybeAutoApprove( sb: SupabaseClient, input: ProposalServiceInput,// 包括 source: 'api' | 'trigger' | 'reaction'):Promise {// 1. 检查每日限制// 2. 检查容量关口（下面解释）// 3. 插入提案// 4. 发出事件// 5. 评估自动批准// 6. 如果批准 → 创建任务 + 步骤// 7. 返回结果}修改后，触发器只返回提案模板。评估器调用这个服务：// trigger-evaluator.tsif(outcome.fired&& outcome.proposal) {awaitcreateProposalAndMaybeAutoApprove(sb, { ...outcome.proposal, source:'trigger', });}

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

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

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

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

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

　　// proposal-service.ts 内部的关口系统constSTEP_KIND_GATES: Record = { write_content: checkWriteContentGate,// 检查每日内容容量 post_tweet: checkPostTweetGate, // 检查推文配额 deploy: checkDeployGate, // 检查部署策略};

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

　　这是post_twee关口的例子：

　　asyncfunctioncheckPostTweetGate(sb: SupabaseClient) {constautopost =awaitgetOpsPolicyJson(sb,'x_autopost', {});if(autopost.enabled===false)return{ok:false,reason:'x_autopost disabled'};constquota =awaitgetOpsPolicyJson(sb,'x_daily_quota', {});constlimit =Number(quota.limit??10);const{ count } =awaitsb .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分钟无进展 → 标记失败 → 检查任务是否应结束constSTALE_THRESHOLD_MS =30*60*1000;const{ data: stale } =awaitsb .from('ops_mission_steps') .select('id, mission_id') .eq('status','running') .lt('reserved_at', staleThreshold);for(conststep of stale) {awaitsb.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检查任务中的所有步骤——任何一步失败意味着整个任务失败，全部完成意味着成功。不再有“因为一步成功就把整个任务标记为成功”的情况。

　　完整架构

　　三层结构，职责清晰：

　　OpenClaw(VPS)：思考+执行（大脑+手）

　　Vercel：审批+监控（控制平面）

　　Supabase：所有状态（共享皮层）

　　现在，这6个智能体每天都在自主运营voxyz.space。

　　它还远非完美——智能体间的协作仍然很基础，「自由意志」主要还是通过基于概率的非确定性来模拟。但系统确实在运行，确实不需要人盯着。

　　参考资料：

　　https://x.com/DeryaTR_/status/2020224124132409535

　　https://x.com/AlexFinn/status/2020178105579737440

　　https://x.com/jitenpai/status/2020292752085282994

　　https://x.com/NoahEpstein_/status/2020158945516462472

　　https://x.com/ihtesham2005/status/2020165638665441685

　　https://x.com/Voxyz_ai/status/2019914775061270747