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)。文中的成功率反推、调度模拟、学习循环模型、双重校验逻辑、避障策略对比、节拍测算均为基于公开信息的推演与示意,非官方数据;智元尚未公布任务成功率与人工接管频次,引用时应注明该口径缺失。