全球首家無人公司開業！OpenClaw 24小時不休，瘋狂碾壓打工人

•

【新智元導讀】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<ProposalServiceResult> {  // 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<string, StepKindGate> = {  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。

它還遠非完美——智能體間的協作仍然很基礎，「自由意志」主要還是通過基於機率的非確定性來模擬。但系統確實在運行，確實不需要人盯著。 (新智元)


鉅亨網
官方號
客服
號守則&聲明
© Copyright 2000-2025 Anue鉅亨網 All rights reserved.