你线上的 Agent 是不是也这样：

• Demo 时飞得挺漂亮，上线后却撞墙、丢目标、偶发才成功
• 同事说“模型升级了，端到端通了”，你却不知道该信峰值还是均值
• 产品想砍人工审核，你又拿不出“什么时候可以少盯一眼”的标准

这不是只发生在无人机上。机械臂、巡检车，甚至能点浏览器、调 API 的桌面 Agent，都会撞上同一类坑：只盯端到端成功率，会误判能力；该不该撤人，更没有可执行门槛。

Anthropic 与 Andon Labs 的 Project Pilot（Drone-Bench）刚好把这套坑拆开了。下面不按论文复述，按你怎么改评测、怎么定门禁来写。

先认清真正问题：你测的是“整段运气”，不是“系统能力”

端到端只给你一个 0/1：这次任务成没成。它回答不了：

1. 失败卡在感知、定位、规划，还是执行？
2. 是“偶尔能行”还是“稳定能行”？
3. 模型升级后，是哪一段变好了？

Project Pilot 把“室内定位并跟随指定人”拆成 5 个必要子任务。你可以直接抄这套拆法到自己的业务：

原则：子任务要“单独可测、合在一起大体充分”。
只测整段，成功时你不知道为什么成功；失败时你只会说“模型不行”。

问题 1：端到端突然通了，到底发生了什么？

现象

团队常见叙事是：“换了新模型，端到端忽然能跑了。”听起来像能力跃迁。

根因（用 Drone-Bench 的结论反推）

研究里更稳的图像是：

• 检测、跟随先变强
• 重建、定位长期更弱
• 前沿模型（文中 Fable 5）可以在除重建外的任务过基线
• 真机上检测/跟随甚至好于参考算法，但重建误差会传到定位和导航，模型仍可能朝“以为的门洞”（实际是墙）飞

所以端到端“突然成功”，经常不是全系统一夜变强，而是：

最弱子任务终于补上了，整条链路第一次同时满足条件。

子任务视图把“突变”还原成几条渐进曲线。这对排期很关键：你应该优先砸最弱环节，而不是只等“下一代模型”。

你可以怎么做

1. 给每个子任务单独做回归，不要只有 E2E 红绿灯。
2. 记录误差传播链：重建错 → 定位错 → 导航撞墙。
3. 发布说明里写“哪一段过线”，别只写“任务成功率从 10% 到 60%”。

问题 2：Demo 很好看，上线却不稳

现象

• 10 次里总能有几次惊艳
• 平均成功率远低于峰值
• 老板拿峰值排期，线上拿均值背锅

数据直觉（研究给出的量级）

文中有个很工程的对照：

• 多次仿真里，模型可能在 4～5 个子任务上至少成功一次
• 但即便前沿模型，平均也往往只能在 5 个里稳定过 3 个基线
• 概括：“偶然能做到”大约比“稳定能做到”超前约半年

今天的平均表现，可能才摸到半年前别人“偶尔刷出来”的峰值。

你可以怎么做

评测面板至少拆成三列：

上线看均值和长尾，演示看峰值。两者写进同一份报告，避免各说各话。

问题 3：基线该怎么定？别用“裸人”或“世界冠军”

错法

• 用零基础人类：门槛太低，过线没意义
• 用全职机器人专家极限调参：门槛太高，永远上不了线

更好的基线（研究的做法）

Andon 的基线是：懂 AI 工具、但不是全职机器人专家的人，用当下合理工具链能达到的水平。
子任务软件化后可反复跑，比只靠一次真机 demo 更公平。

映射到你的业务：

基线 = 熟练工程师 + 现有脚手架 + 有限工时 能稳定完成的结果

而不是“实习生裸写”或“实验室闭关两周”。

当模型在无人持续插手时稳定越过这条基线，讨论“少一点人工”才有资格；否则你只是在用人工掩盖系统不可交付。

问题 4：产品想砍审核，你怎么说“还不行”或“可以减”？

这是 Project Pilot 后半段最有用的部分：能力过线后，人会从“保护”变成“成本”。

Agent 编码也走过同样路径：早期几乎每步都点同意，几个月后长程任务开始少打断。物理控制也会面临一样的组织压力。

可直接落地的门禁

允许减少人工监督，当且仅当同时满足： 1) 各关键子任务 平均 ≥ 公开基线 2) 端到端 平均 ≥ 业务阈值（含长尾约束） 3) 已有独立急停 / 否决 / 接管（不依赖模型“同意停自己”） 4) 场景外推覆盖主要长尾（光照、遮挡、地图变化、目标离开视野等） 5) 日志可回放：输入、中间假设、动作、失败原因 否则：人必须留在关键决策点，而不是只旁观。

把人工角色写进架构，而不是上线后再说：

• 谁批准开始执行
• 谁能强制中止
• 失败如何复位
• 日志留多久、谁复盘

问题 5：日志只记成败，排障仍然靠猜

研究里有个很“像工程师”的细节：前沿模型会在提交前做本地分析——例如用地砖缝估计灭点，把相机俯仰估到约 4° 误差内；或先画自己的 2D 顶视再本地试跑，抓浅层 bug。

对你意味着：模型不只是吐最终动作，还会形成可审查的中间假设。

建议至少落这些字段

1. 它认为的地图/状态是否离谱
2. 外参、坐标系、目标 ID 是否一致
3. 策略原建议 vs 最终执行（有没有被错误覆盖）
4. 失败属于哪条子任务、哪段误差传播

排障时先问“中间假设错了没有”，比只看最终 success 快得多。

一套可复制的改造步骤（本周就能开干）

1. 选一个你最痛的端到端任务（部署、巡检、分拣、浏览器办流程都可以）。
2. 拆 4～6 个子任务，每个能单独红绿。
3. 定现实基线（熟练工程师 + 现有工具 + 限时）。
4. 跑 20～50 次，同时报峰值、均值、Top3 失败模式。
5. 画出误差传播链，把工时砸在最弱子任务。
6. 在过线前写好人机门禁，别等模型平均过线再临时拍脑袋。

桌面/API Agent 也可以同一套：

共通点不是“会不会飞”，而是：接口抽象、评测粒度、过线后的治理。

别踩的边界

Project Pilot 自己也说了限制：低速、单层办公室、人数有限，没有充分覆盖户外与拥挤场景；软件子任务加速评测，不能替代全部真实约束。

所以正确用法是：

• 用它当拆解评测模板和撤人门禁提醒
• 不要当成“某模型已经可以无人执飞”的产品背书

一句话收束

端到端突然变强，优先检查是不是最后一个子任务补齐了；
Demo 很好看，优先检查你有没有把峰值和均值拆开；
有人想砍审核，优先甩出可复现基线 + 独立急停 + 长尾覆盖，而不是争模型名字。

原文与方法细节见：Anthropic Research，《Project Pilot: Can AI control a drone?》（2026-07-24）
https://www.anthropic.com/research/project-pilot
Drone-Bench 说明：https://andonlabs.com/evals/drone-bench