全球首家無人公司開業！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