共计 6680 个字符，预计需要花费 17 分钟才能阅读完成。
【新智元导读】一名 27 岁的独立开发者凭借其项目月入过万，前市场经理在睡觉时利用 AI 赚取收入，而一位来自柏林的辍学生通过售卖定制技能获得了 12.7 万美元的收益——AI 智能体的“iPhone 时刻”已经来临，但赚取的财富仍然不均。
在 AI 智能体的世界里，终于迎来了它的“iPhone 时刻”。
然而，这个转折点并不在于“更擅长对话”或“智力更高”，而是因为 它能独立完成任务。
在全球仍在争论“AI 是否会取代人类工作”的同时，一小部分人已经跳出了这个争论的框架。
他们开始着手构建，而不是仅仅“依赖 ChatGPT”，而是创造出自主运作的商业单元。
一位来自德克萨斯州的 27 岁独立开发者，凭借自动化网页抓取工具，一月份的收入达到了 43,000 美元。
一位生活在多伦多的前市场经理，开发了一款邮件文案生成的智能体，每月为她带来 8,200 美元的收益——而她在睡梦中。
一位柏林的辍学生，在仅仅两个月前还不存在的市场中，成功销售了价值 127,000 美元的自定义 OpenClaw“Agent 技能”。
其背后反映出同一个趋势：硅基劳动力开始崭露头角。
OpenClaw 首个十亿美元的应用场景
而 OpenClaw 的第一个十亿美元应用场景终于显现。
受到 YouTube 频道《Dumb Money》社交套利策略的启发，OpenClaw 不断自动监测社交媒体上的流行趋势。
通过“售罄”等关键词，智能体能够提前识别潜在的库存机会，比如星巴克的保温杯或沃尔玛的联名商品。
一旦捕捉到信号，OpenClaw 便将这些趋势视为可能的股票或市场超额收益的机会。
因为这些消费热潮往往会提前反映在相关公司的股价变化上，而华尔街的主流分析通常会滞后。
这正是自主智能体大放异彩的地方——全年无休、全天候运作。
人类每天可能只会查看社交媒体三次，而智能体则每 15 分钟就会进行一次检查。
想象一下，十个智能体同时监控不同的平台——如 TikTok、X、Reddit、Discord 和 Telegram——所有信息汇聚到一个仪表盘上。
这不再只是 AI 工具，而是一场全面的市场情报行动。
未来已经到来，只是发展不均。
现在智能体的智能程度如此之高，硅基劳动力的出现几乎是理所当然的下一步。
全球首批 OpenClaw 企业，全年无休
许多人认为这只是炒作。Alex Finn 并不争辩，他选择直接去建造“改变世界的产品”。
他正在创办第一家 OpenClaw 智能体公司，让其实现 7×24 小时的运作。
目前，Alex 有两名员工在本地（部署在 Mac Studio 上）工作，另有两名员工为外包（Opus 4.6 与 Codex 5.3）。这两名本地员工全天候为他服务。
它们无需进食、休息、抱怨，也不需要五险一金。
而他的所有前期投入仅为一份终身合约，金额为 2 万美元（包括两台 512GB 内存和 4TB 固态硬盘的 Mac Studio）。
与之前面试过的那些年薪 10 万美元的人类候选人相比，他认为这简直是超值的选择。
当他安然入睡时，这些智能体仍在工作；明天观看超级碗橄榄球比赛时，它们依旧在忙碌。
它们会不断浏览 X 和 Reddit，寻找待解决的问题，并持续编写程序——完全无需监督。
这就是 Alex Finn 所打造的全球企业。
智能体革命：VoxYZ 网站的崛起与未来展望
最近，他计划建立一个官方网站，以便让公众实时查看每位员工的工作状态。
他深信全球再无其它人能够创造出如此成果。这是历史上首个全天候自主运作的劳动力系统。
然而，最引人注目的并非是“全天候劳动力”，而是这一切都“完全不需要任何监控”。
当然，OpenClaw 智能体的 7 ×24 小时不间断工作并非他一人之功：
可上下滚动的图片
欢迎您来到未来的世界。
这一切究竟是如何实现的呢？
全球首个智能体运营网站
在过去的三周，投资者 Ihtesham Ali 活跃于 Discord、Reddit 等社交平台，专门寻找“真正利用智能体赚钱的人”。
他统计发现：在一个月内，有十人通过智能体共赚得 84.7 万美元。
而如今，第一家“由智能体管理”的公司诞生了：VoxYZ。
VoxYZ 网站的创始人，网友 Vox
其配置极为简约：6 个智能体 + 1 台 VPS + 1 个 Supabase 数据库。
仅仅两周时间，从“闲聊”进化到“自主运营网站”。
这一切的起点是 OpenClaw：当 AI 智能体不仅仅是回答问题，而是实际管理一家公司时将会发生什么。
它们会对市场进行研究、撰写内容、发布社交媒体信息、交付产品……所有行动完全不需要人类的指挥。
这正是全球首个由 OpenClaw 运营的公司 VoxYZ——
0 个人类提示词，所有决策均由智能体自主做出。
一切的源头：OpenClaw
OpenClaw 解决了一个重大的难题：使 Claude 能够使用工具、浏览网页、操作文件及执行定时任务。
您可以为智能体设定定时任务——例如每天发布推文、每小时进行情报扫描、定期生成研究报告等等。
这一切都始于此。
该项目名为VoxYZ Agent World： 6 个 AI 智能体在一个像素风格的办公室中自主运营一个网站。
其技术栈极为简单：
智能体系统的高效运作与挑战
六个角色各司其职：
六位角色各自担任不同职能：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
第二个问题：任务已触发，却无人处理
他设计了四个触发器：推文热度自动分析、任务失败自动诊断、内容发布自动审核、成熟见解自动推广。
在测试中我发觉：触发器能够准确识别条件并生成提案。然而，提案始终处于待定状态——从未转化为任务，也未产生可执行的步骤。
问题所在：触发器直接插入到 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',});}一个函数贯穿始终。未来任何检查逻辑（速率限制、黑名单、新限额）——只需修改一个文件。
第三个问题：队列在配额满时持续增长
最隐秘的错误——表面上看一切正常，日志没有报错，但数据库中排队的步骤却在不断增加。
原因：推文配额已达到上限，但提案仍在继续被批准，生成任务并产生排队步骤。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};}关键原则：在关口拒绝，不要在队列中造成堆积。被拒绝的提案会被记录（用于审计），而不会默默丢弃。
让系统生动起来：触发器与反应矩阵
经过填补三个问题后，循环便能正常运作。然而，这套系统仍然只是一条「无错误的流水线」，并非「响应式团队」。
触发器
四个内置规则——每个规则针对一个条件并返回相应的提案模板：
触发器仅负责检测——它们不直接操作数据库，而是将提案模板传递给提案服务。所有的容量限制和自动批准逻辑都会自动生效。
冷却时间至关重要。如果没有设置，某条热门推文可能在每个心跳周期（每五分钟）都触发一次分析。
反应矩阵
最引人注目的部分——自主智能体间的互动。
存储在 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 会诊断。概率不是错误，而是特性。
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：负责管理所有状态（共享层）
如今，这六个智能体每天都在独立管理 voxyz.space。
尽管如此，系统仍有改进的空间——智能体之间的协作尚且基础，「自由意志」的体现主要依赖于基于概率的非确定性模拟。然而，系统确实在有效运行，并不需要人为的持续监督。
OpenClaw的模式听起来太过理想化，是否会面临技术漏洞或道德风险？