1730项任务、4台转正、成功率没公布:智元6台G2便利店连跑24小时,真正值钱的是那份没人给的考核表

1730项任务、4台转正、成功率没公布:智元6台G2便利店连跑24小时,真正值钱的是那份没人给的考核表

Part One:收官数字很好看,但最该看的那个数字没出现

2026年11月2日上午10点,上海徐汇区一家正常营业的便利店里,六台智元精灵G2人形机器人开始上班。24小时后,11月3日上午10点,这场叫"机器人打工不能停"的直播挑战收官。

官方公布的账是这些:

  • 累计完成1730项任务
  • 接待顾客 683次、商品取送 369件、咖啡制作 147次、早餐服务 126次、补货巡检 277次、桌面清洁 128次
  • 直播全网 超200万人 在线观看
  • 4台成功"转正"

前四项是任务量,最后一项是人员淘汰率——6台里过了4台,2台没过。

但有一组数字,是智元自己在前一天就明确说要考核、却到收官都没公布的:

智元具身研究中心副总裁任光辉对媒体表示,公司将跟踪任务成功率、首次尝试成功率、响应时间、端到端时间、单位时间合格交付、人工接管频次、恢复时间、系统可用性。

这八项,一项都没披露。 收官给出的全是任务计数。

这不是吹毛求疵。任务计数和成功率是两套完全不同的账,而且后者才是决定"能不能真上岗"的那套。下面用代码把这两套账摊开。

# Task counts vs. success rates: why the same 1730 means wildly different things
def task_count_vs_success(total_tasks=1730, robots=6, hours=24):
    """
    Given only the task count, back out what different success rates imply.
    """
    scenarios = {}

    for rate in [0.99, 0.95, 0.90, 0.80, 0.70]:
        success = int(total_tasks * rate)
        fail = total_tasks - success
        # Rough assumption: one human intervention per failure (optimistic)
        interventions = fail
        per_robot_hours = hours
        interventions_per_robot_hour = interventions / (robots * per_robot_hours)

        scenarios[f"{rate:.0%}"] = {
            "successful tasks": success,
            "failed tasks": fail,
            "implied interventions": interventions,
            "interventions per robot-hour": f"{interventions_per_robot_hour:.2f}",
        }

    return scenarios

print(f"{'Success rate':<14}{'Success':<10}{'Fail':<8}{'Interventions':<16}{'Per robot-hour'}")
print("-" * 68)
for rate, d in task_count_vs_success().items():
    print(f"{rate:<14}{d['successful tasks']:<10}{d['failed tasks']:<8}"
          f"{d['implied interventions']:<16}{d['interventions per robot-hour']}")

这张表说明的是:同一个"1730",对应的人工介入频次可能相差十倍以上。

  • 如果成功率 99%,24小时只需处理约 17 次异常,平均每台机器人每 8 小时才需要人管一次——基本可以算无人值守;
  • 如果成功率 90%,要处理 173 次,平均每台每小时 1.2 次——这不叫无人值守,叫"六个人在旁边盯着随时救场";
  • 如果 80%,每台每小时 2.4 次——这是演示,不是上岗。

而"4台转正、2台没过"这个信息,反过来暗示成功率不是特别高:如果六台都稳,没必要淘汰两台。 淘汰说明考核确实存在一条线,只是那条线划在哪,没公开。

这不是要否定这次挑战。恰恰相反,敢在正常营业的门店里跑满 24 小时、还全程直播让人挑刺,这个动作本身比数字更有价值。 但作为技术分析,必须把"任务量"和"成功率"分开看——因为这两者在工程上要解决的问题完全不同。

Part Two:六岗位、四班次——便利店为什么是具身智能的"标准化考场"

这次挑战的岗位设计值得单独说,因为它是按便利店的真实服务链拆的,不是按机器人的能力拼的。

工牌名岗位职责
阿豪迎宾门口接待、顾客咨询、陪聊
火宝取货按订单到货架取商品
倦王补货巡检巡视货架、发现空缺主动补货
咖少咖啡师专职制作咖啡
叮酱收银值守收银台,兼顾熟食服务
冷姐保洁店内桌面清洁

六个岗位串起来,正好覆盖一家便利店"迎客—取货—制作—收银—补货—保洁"的完整流程。这个拆法有个隐含判断:具身智能现阶段不该追求"一台机器人什么都会",而该追求"一台机器人把一个岗位做稳"。

时间维度上,24小时被切成四个班次,对应真实的客流曲线:

# Four shifts, and what each one actually tests
def shift_breakdown():
    shifts = [
        {
            "shift": "early-morning breakfast rush",
            "time window": "06:00-10:00",
            "traffic": "spiky, high per-customer urgency",
            "technical focus": "peak concurrency, queue backlog, coffee + hot food handoff",
        },
        {
            "shift": "midday peak probation",
            "time window": "11:00-14:00",
            "traffic": "highest density, most interference",
            "technical focus": "multi-robot contention, aisle obstruction, path conflicts",
        },
        {
            "shift": "evening peak stress test",
            "time window": "17:00-21:00",
            "traffic": "high and sustained",
            "technical focus": "sustained load, battery/thermal, accumulated error",
        },
        {
            "shift": "late-night solo watch",
            "time window": "22:00-06:00",
            "traffic": "near zero",
            "technical focus": "idle self-practice, memory consolidation, autonomous restocking",
        },
    ]
    return shifts

for s in shift_breakdown():
    print(f"\n[{s['shift']}] {s['time window']}")
    print(f"  traffic      : {s['traffic']}")
    print(f"  tests        : {s['technical focus']}")

四个班次考的东西完全不同,这是这次挑战设计上最聪明的地方。

早高峰考的是并发与节拍:一杯咖啡 147 次里有多少集中在早高峰?如果 147 次里 80 次挤在 4 小时内,就是每小时 20 杯,平均 3 分钟一杯——这要求制作流程的每一步都不能卡。午高峰考的是多机争抢:两台理货机器人加一台保洁在狭窄通道里来回走,路径规划和死锁避免是硬考验。晚高峰考的是疲劳:连续工作十几小时后,电池、关节温升、定位漂移都会累积。深夜考的是自主性:没人的时候它会不会自己找活干、会不会把白天的经验沉淀下来。

而"深夜独立值守"这一班,才是这次挑战最有含金量的部分。 因为白天有人围观、有流量、有镜头,出了问题马上能被发现;深夜没人看,如果机器人能自己补货、自己巡检、自己加练,那才叫真自主。

Part Three:“无人值守"到底无人到什么程度

Pandaily 的报道里有一句关键表述:

AgiBot says the test ran with no human in the loop, meaning no human demonstrations or manual on-site tuning.

这个定义很具体,值得逐字读:没有人工示教,没有现场手动调参。 也就是说,机器人不是被人遥控着做的,也不是工程师在旁边不停改参数改出来的。

但要区分三种"无人”:

# Three levels of "unmanned" — the challenge only proves the first two
def unmanned_levels():
    return {
        "L1: no teleoperation": {
            "meaning": "robots decide and execute actions themselves, no human driving",
            "proven by": "task counts + livestream (actions visibly autonomous)",
            "evidence strength": "strong",
        },
        "L2: no on-site tuning": {
            "meaning": "engineers don't adjust parameters on site during the run",
            "proven by": "official statement",
            "evidence strength": "medium (self-reported)",
        },
        "L3: no human intervention on failure": {
            "meaning": "when the robot fails, it recovers by itself without a human stepping in",
            "proven by": "would require publishing intervention counts",
            "evidence strength": "not disclosed",
        },
    }

for level, d in unmanned_levels().items():
    print(f"\n{level}")
    for k, v in d.items():
        print(f"  {k:20s}: {v}")

L1 和 L2 这次基本证成了,L3 没有。 而 L3 恰恰是商业落地的分水岭——因为如果每次失败都要人介入,那"无人便利店"的经济账根本不成立:省下的人力又花回去盯机器人了。

这也能解释为什么"4台转正"这个结果是有意义的:转正考核大概率就是在评 L3。 通过的那 4 台,是在 24 小时里靠自己把绝大多数异常兜住了;没通过的 2 台,是在某些环节必须靠人。

Part Four:Genie Master 的三层闭环——调度、记忆、反哺

六台机器人背后是一个共享大脑:Genie Master(精灵大师)具身智能体框架。它的设计思路可以拆成三层。

                    ┌──────────────────────────────────────┐
                    │         Genie Master (shared brain)  │
                    │                                      │
                    │  ┌────────────────────────────────┐  │
                    │  │  L1  调度层                     │  │
                    │  │  · task assignment by scene     │  │
                    │  │  · six-robot contention resolve │  │
                    │  │  · priority by customer waiting │  │
                    │  └──────────────┬─────────────────┘  │
                    │                 │                    │
                    │  ┌──────────────▼─────────────────┐  │
                    │  │  L2  执行层 (Embodied Execution │  │
                    │  │       Protocol)                 │  │
                    │  │  · task judgment → action       │  │
                    │  │  · real-time perception adjust  │  │
                    │  │  · result feedback upstream     │  │
                    │  └──────────────┬─────────────────┘  │
                    │                 │                    │
                    │  ┌──────────────▼─────────────────┐  │
                    │  │  L3  学习层                     │  │
                    │  │  · daily success/failure review │  │
                    │  │  · long-term memory storage     │  │
                    │  │  · corrected policy → training  │  │
                    │  │  · idle-time self-practice      │  │
                    │  └────────────────────────────────┘  │
                    └──────────────────────────────────────┘
                              │              │
              ┌───────────────┘              └──────────────┐
              ▼                                             ▼
     ┌─────────────────┐                          ┌─────────────────┐
     │  6 × G2 robots  │                          │  training data  │
     │  (each a worker │                          │  (feeds back to │
     │   session)      │                          │   action model) │
     └─────────────────┘                          └─────────────────┘

第一层是调度。 六台机器人不是各干各的,而是共享一个调度器:谁去接待、谁去补货、谁去做咖啡,按现场情况分配。这里最难的其实不是分配本身,而是争抢的处理——两台理货机器人都想去补同一个货架、保洁机器人要过的通道正好被理货机器人占着,这类冲突在真实门店里每分钟都在发生。

# Multi-robot contention: how a simple priority scheduler behaves under load
import random

def simulate_contention(robots=6, minutes=60, task_rate=1.2, seed=42):
    """
    Simplified: at each minute, task_rate new tasks arrive on average;
    each robot can handle one task; conflicts arise when >1 robot wants the same zone.
    """
    random.seed(seed)
    zones = ["entrance", "shelf_A", "shelf_B", "coffee", "checkout", "cleaning"]
    busy = {z: 0 for z in zones}
    queue = 0
    conflicts = 0
    served = 0

    for m in range(minutes):
        arrivals = 0
        # Poisson-ish arrivals
        while random.random() < task_rate / 60 * 10:
            arrivals += 1
        queue += arrivals

        for _ in range(robots):
            if queue <= 0:
                break
            zone = random.choice(zones)
            if busy[zone] > 0:
                conflicts += 1
                continue
            busy[zone] = random.randint(2, 6)  # task takes 2-6 minutes
            queue -= 1
            served += 1

        for z in zones:
            if busy[z] > 0:
                busy[z] -= 1

    return {
        "tasks arrived": served + queue,
        "tasks served": served,
        "backlog": queue,
        "zone conflicts": conflicts,
        "conflict rate": f"{conflicts / max(served,1):.1%}",
    }

for k, v in simulate_contention().items():
    print(f"  {k:18s} {v}")

这个模拟当然是简化的,但它指向一个真实问题:多机协同的瓶颈往往不在单机能力,而在资源冲突。 六台机器人在一家便利店那么小的空间里,冲突率不会低。而每发生一次冲突,就多一次等待、多一次重规划、多一次顾客看见"机器人在那儿犹豫"。

第二层是执行。 Genie Master 通过一套 Embodied Execution Protocol(具身执行协议) 把"任务判断—动作执行—结果反馈"串成闭环。这个协议的作用,是把上层的"去补个货"翻译成下层的具体动作序列,再把执行结果(成功/失败/卡住)结构化地回传。

第三层是学习。 这是整个设计里最有意思的部分:

  • 每天汇总所有成功和失败的作业记录;
  • 有用的经验存进长期记忆,同类任务直接复用;
  • 修正过的策略转成训练数据,反哺动作模型;
  • 空闲时段自主加练。

用代码表达这个循环:

# The learning loop: memory reuse vs. policy update, two different paths
def learning_loop(days=30, tasks_per_day=1730, success_0=0.88):
    """
    Two mechanisms work in parallel:
      1) memory reuse: solved cases retrieved directly (fast, no retraining)
      2) policy update: corrected trajectories become training data (slow, generalizes)
    """
    success = success_0
    memory = 0          # reusable cases in long-term memory
    policy_gain = 0.0   # cumulative generalization gain
    history = []

    for d in range(1, days + 1):
        # memory grows from solved tasks, with decay for stale cases
        memory = int(memory * 0.98 + tasks_per_day * success * 0.15)

        # policy gain compounds slowly, saturating
        policy_gain += 0.004 * (1 - policy_gain / 0.12)

        # combined effect: memory gives immediate lift, policy gives lasting lift
        memory_lift = min(memory / 20000 * 0.05, 0.05)
        success = min(success_0 + memory_lift + policy_gain, 0.995)

        if d % 5 == 0 or d == 1:
            history.append((d, memory, f"{success:.3f}"))

    return history

print(f"{'Day':<6}{'Memory cases':<16}{'Success rate'}")
print("-" * 36)
for d, mem, rate in learning_loop():
    print(f"{d:<6}{mem:<16}{rate}")

这段代码想说明一个结构性判断:长期记忆和策略更新是两条不同的曲线。

记忆复用是快的、局部的——今天遇到的坑,明天直接查表绕过去。但它的天花板很低,因为记忆只覆盖"见过的场景",而且会随场景变化而失效(代码里用 0.98 的衰减模拟这一点)。

策略更新是慢的、通用的——修正后的轨迹变成训练数据,模型真的学到了"遇到这种情况该怎么调",能泛化到没见过的场景。但它需要时间、需要数据量、需要训练算力。

两者叠加,才是"边上岗边进化"的真实含义。 而这也解释了为什么智元要强调"空闲时段自主加练"——夜间那 8 小时几乎没客流,是唯一不占用营业时间的训练窗口。

Part Five:刁难测试里的三个技术点,比任务数更能说明水平

直播里有两位"特邀体验官"专门来出难题,这些题目反而比 1730 这个数字更能说明系统成熟度。三个最有代表性:

第一题:有糖/无糖可乐,只说"拿无糖的"。

两个瓶子外观几乎一样,标签差异极小。机器人的做法是**“耳朵听懂、眼睛确认"双重校验**——语音识别出"无糖”,然后视觉去核对标签上的"无糖"字样,两者一致才取。

# Dual verification: voice + vision must agree before acting
def dual_verify(voice_intent, vision_labels, threshold=0.85):
    """
    voice_intent: attribute extracted from speech, e.g. "sugar_free"
    vision_labels: list of (label, confidence) from visual inspection
    """
    best = max(vision_labels, key=lambda x: x[1])

    if best[0] != voice_intent:
        return {
            "action": "abort_and_ask",
            "reason": f"vision says '{best[0]}', voice says '{voice_intent}'",
            "confidence": best[1],
        }

    if best[1] < threshold:
        return {
            "action": "re_scan",
            "reason": f"label confidence {best[1]:.2f} below threshold {threshold}",
            "confidence": best[1],
        }

    return {
        "action": "grasp",
        "reason": "voice and vision agree with high confidence",
        "confidence": best[1],
    }

# Case A: clear label
print("Case A (clear label):")
for k, v in dual_verify("sugar_free", [("sugar_free", 0.94), ("regular", 0.05)]).items():
    print(f"  {k:12s} {v}")

# Case B: ambiguous / low confidence
print("\nCase B (ambiguous):")
for k, v in dual_verify("sugar_free", [("sugar_free", 0.71), ("regular", 0.28)]).items():
    print(f"  {k:12s} {v}")

# Case C: conflict
print("\nCase C (conflict):")
for k, v in dual_verify("sugar_free", [("regular", 0.88), ("sugar_free", 0.11)]).items():
    print(f"  {k:12s} {v}")

这个逻辑看着简单,但它是安全性的关键设计:宁可"再扫一次"或"问一句",也不要在不确定的时候硬取。在便利店场景里,取错一瓶可乐是小事;但如果这个模式被搬到药房、仓库、产线,“不确定就停"和"不确定也做"的差别就是事故与无事故的差别。

第二题:把整个口香糖货架打乱,看能不能归位。

机器人的做法是不靠标签位置、靠视觉盘点逐格归位。这点很关键:如果系统是"记住第 3 格是薄荷味”,那货架一乱就全废;而如果是"看到这盒是什么,再找它该在哪",那就是真的理解了商品和货架的关系。

# Two paradigms for shelf restocking — and why only one survives disorder
def restocking_paradigms():
    return {
        "position memory": {
            "logic": "remember item i belongs at slot j",
            "works when": "shelf layout never changes",
            "fails when": "items are shuffled, layout changes, new SKUs arrive",
            "robustness": "low",
        },
        "visual inventory": {
            "logic": "recognize each item, then find its correct slot",
            "works when": "recognition is reliable",
            "fails when": "packaging is visually near-identical (e.g. sugar-free vs regular)",
            "robustness": "high",
        },
        "hybrid (what was shown)": {
            "logic": "recognize item + cross-check slot constraints + verify after placing",
            "works when": "recognition + spatial reasoning both hold",
            "fails when": "heavy occlusion or new packaging never seen",
            "robustness": "highest, at higher compute cost",
        },
    }

for name, d in restocking_paradigms().items():
    print(f"\n[{name}]")
    for k, v in d.items():
        print(f"  {k:14s}: {v}")

第三题:人站在通道中间当路障,再丢个箱子堵路。

机器人的反应是"遇人先停再绕,箱子挡路就再绕"。

这个"先停"两个字,是整个系统里最不该被忽视的设计。因为人形机器人在商业空间里移动,最危险的不是走错路,而是在犹豫的时候还在动。停下来重新规划,即使慢几秒,也比"一边算一边往前挪"安全得多。

# Obstacle policy: stop-first vs. keep-moving, and the safety math
def obstacle_policy(robot_mass_kg=45, speed_mps=1.0, reaction_s=0.3):
    """
    Simplified stopping-distance comparison.
    """
    results = {}

    # Policy A: stop first, then re-plan
    stop_distance_a = speed_mps * reaction_s + (speed_mps ** 2) / (2 * 2.0)
    results["A: stop then re-plan"] = {
        "stopping distance (m)": f"{stop_distance_a:.2f}",
        "extra time (s)": "2.5-4.0 (re-planning)",
        "collision risk": "very low",
    }

    # Policy B: keep moving while computing
    stop_distance_b = speed_mps * (reaction_s + 0.8) + (speed_mps ** 2) / (2 * 2.0)
    results["B: compute while moving"] = {
        "stopping distance (m)": f"{stop_distance_b:.2f}",
        "extra time (s)": "0.3-0.8",
        "collision risk": "elevated (path may change underfoot)",
    }

    return results

for policy, d in obstacle_policy().items():
    print(f"\n{policy}")
    for k, v in d.items():
        print(f"  {k:22s}: {v}")

算一下就知道,“先停"多花的是 2-3 秒,“边算边走"省下的是 2-3 秒,但风险差了一个量级。 在人机混场的商业空间里,这个交换毫无疑问是值得的。

Part Six:用1730倒推——这个数字背后的节拍与并发

1730 项任务 / 24 小时 / 6 台机器人,平均下来是什么节拍?

# Back-of-envelope: what 1730 tasks over 24 hours actually implies
def task_pacing():
    total = 1730
    robots = 6
    hours = 24
    breakdown = {
        "customer reception": 683,
        "item fetch/delivery": 369,
        "coffee making": 147,
        "breakfast service": 126,
        "restocking/shelf check": 277,
        "table cleaning": 128,
    }

    print(f"Total tasks: {total}")
    print(f"Per robot: {total/robots:.1f} tasks over {hours}h")
    print(f"Per robot-hour: {total/(robots*hours):.1f} tasks")
    print(f"Average interval: {robots*hours*60/total:.1f} min between tasks\n")

    print(f"{'Task type':<24}{'Count':<8}{'Share':<9}{'Per hour (all robots)'}")
    print("-" * 66)
    for name, count in breakdown.items():
        share = count / total
        per_hour = count / hours
        print(f"{name:<24}{count:<8}{share:<9.1%}{per_hour:.1f}")

    # Implied concurrency at peak
    print("\nPeak-hour implication (assume 30% of daily tasks in 4 peak hours):")
    peak_tasks = total * 0.30
    peak_hours = 4
    peak_rate = peak_tasks / peak_hours
    print(f"  peak task rate: {peak_rate:.1f} tasks/hour")
    print(f"  per robot at peak: {peak_rate/robots:.1f} tasks/hour "
          f"(≈ 1 task every {60/(peak_rate/robots):.1f} min)")

task_pacing()

跑出来的关键数字是:平均每台机器人每小时约 12 项任务,也就是大约每 5 分钟一项。 如果按 30% 任务集中在 4 个高峰小时估算,峰值时每台机器人每小时要处理约 22 项,也就是不到 3 分钟一项。

这个节拍是什么概念?咖啡机出一杯咖啡通常要 1-2 分钟,加上取杯、放盖、递给顾客,3 分钟一项基本是满负荷。也就是说,这次挑战在峰值时段,机器人不是在"演示能力”,而是在逼近产能上限。

而逼近上限时,最能暴露问题。 这也是为什么"4台转正"这个结果值得注意——如果只有 2 台在高负荷下稳住了,说明系统的稳定性边界大概就在那个位置。

Part Seven:和智元自己的历史基线比,这次的位置在哪

智元有个习惯:喜欢用直播说话。把历史数据排一下,能看出这条能力曲线:

# AgiBot's public live-demo track record, for context
def historical_baselines():
    return [
        {
            "date": "2025-07",
            "scene": "Fulin Precision Mianyang plant (A2-W)",
            "duration": "3 hours",
            "reported result": "zero failures",
            "metric type": "claimed zero-failure",
        },
        {
            "date": "2025-08",
            "scene": "24h summer city walk (A2)",
            "duration": "24 hours",
            "reported result": "completed",
            "metric type": "completion, no task rate",
        },
        {
            "date": "2025-11",
            "scene": "106km walk Suzhou→Shanghai (A2)",
            "duration": "56 hours, 15 battery swaps",
            "reported result": "completed",
            "metric type": "endurance, no manipulation",
        },
        {
            "date": "2026-06",
            "scene": "Nanchang Longqi plant, 8× G2",
            "duration": "6 consecutive days, 8am-7pm",
            "reported result": "99.99% task success",
            "metric type": "explicit success rate",
        },
        {
            "date": "2026-11",
            "scene": "Shanghai Xuhui convenience store, 6× G2",
            "duration": "24 hours",
            "reported result": "1730 tasks, 4/6 passed",
            "metric type": "task counts only",
        },
    ]

print(f"{'Date':<10}{'Duration':<32}{'Reported':<28}{'Metric'}")
print("-" * 96)
for b in historical_baselines():
    print(f"{b['date']:<10}{b['duration']:<32}{b['reported result']:<28}{b['metric type']}")

这张表最有意思的地方是最后两行的反差。

2026年6月的南昌龙旗工厂,智元给了明确的 99.99% 成功率——因为工厂质检是结构化的、可判定的:这一片屏幕有没有划痕,这个音频有没有杂音,合格就是合格,不合格就是不合格,分母清晰。

2026年11月的便利店,只给了任务计数。这不是智元退步了,而是便利店场景的"成功"本来就难定义:

  • 接待顾客 683 次,什么叫成功?顾客笑了算成功,还是顾客走了算成功?
  • 咖啡制作 147 次,洒了一点算不算失败?顾客说"有点凉"算不算失败?
  • 桌面清洁 128 次,擦完还有人看见油渍算不算失败?

工厂的成功率之所以能精确到小数点后两位,是因为它有一个机械的判定标准;便利店没有。 这恰恰说明:具身智能从"结构化场景"走向"非结构化场景”,第一个撞上的不是能力墙,而是度量墙。

而这个度量问题,不是智元一家的问题。整个行业在往服务场景走的时候,都会遇到同一件事:你不知道怎么定义成功,就不知道自己在进步还是在原地踏步。

Part Eight:判断与边界

第一,这次挑战的真正价值不在 1730,而在它把"非结构化场景"摆上了台面。 之前的工厂质检、产线作业,本质还是"结构化的世界"——光照可控、物料固定、判定明确。便利店是第一个真正的"非结构化考场":顾客随时穿行、商品随时被打乱、同一个动作每次条件都不同。敢在这里跑 24 小时,比在实验室跑 2400 小时更能说明问题。

第二,成功率不公布,是这次最大的信息缺口,而且这个缺口是结构性的。 前面已经论证过:1730 这个数字在 99% 和 80% 两种成功率下,对应的人工介入频次相差十倍以上。而在商业落地里,“需要多少人工兜底"直接决定经济模型成不成立。所以这个数字不是"忘了说”,而是目前还不好说——这本身就是一个诚实的信号。

第三,精细操作仍然是硬边界。 报道里反复提到两个例子:把一袋彩虹糖挂上挂钩,角度差一点就可能带落其他商品;夹一块黄金糕,力道分毫之差就是"掉了"和"碎了"的区别。这两件事人类闭着眼睛都能做,机器人却要动用视觉、力控、轨迹规划的全套。 这提醒我们:具身智能的进展是不均衡的——移动、导航、抓取标准件已经相当成熟,但柔性物体、易碎品、精细挂载这些"手上的活",仍然是最难的一段。

第四,Genie Master 的"记忆+训练"双路径,方向是对的,但效果需要时间验证。 记忆复用能快速提升"见过的场景",策略更新才能提升"没见过的场景"。而这次 24 小时挑战,最多只能验证前者——因为它只在一个店、一天之内。真正的泛化能力,要等这套系统复制到第二个店、第三个城市才能看出来。

第五,“4台转正"这个淘汰率,其实是整场挑战最诚实的一笔。 如果六台全过,会显得考核是走过场;如果只过一两台,会显得能力不行。四比二,既证明系统确实能撑住连续作业,也承认了还有三分之一不稳定。在一个所有人都在吹"通用具身智能"的行业里,愿意公布淘汰率,比愿意公布任务数更难得。

一个可跟踪的框架:以后看这类"机器人上岗"的新闻,别只看任务总数,看四个数——① 成功率(尤其首次尝试成功率,因为它决定要不要重试);② 人工接管频次(每小时多少次,这是经济模型的生死线);③ 连续作业时长与性能衰减曲线(跑 8 小时和跑 24 小时是两回事);④ 场景复制成本(换个店要重新调多久,这决定能不能规模化)。 这四个数都不公布的时候,任务总数基本只能当宣传看。

来源:人民财讯/证券之星《智元机器人24小时便利店累计完成1730项任务》(2026-11-03);新民晚报《24小时在便利店打工,智元精灵G2完成1730项任务》(2026-11-03);上观新闻/文汇报《6台机器人挑战便利店打工24小时,网友"云监督”》(2026-11-02)、《浦东机器人24小时"转正大考"累计完成1730项任务》(2026-11-03);Pandaily, “Six AgiBot G2 Humanoids Run a Shanghai Convenience Store for 24 Hours, Logging 1,730 Tasks”(2026-11-04)。文中的成功率反推、调度模拟、学习循环模型、双重校验逻辑、避障策略对比、节拍测算均为基于公开信息的推演与示意,非官方数据;智元尚未公布任务成功率与人工接管频次,引用时应注明该口径缺失。