全球首家無人公司開業！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件事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檢查任務中的所有步驟——任何一步失敗意味著整個任務失敗，全部完成意味著成功。不再有“因為一步成功就把整個任務標記為成功”的情況。

完整架構

三層結構，職責清晰：

• 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