你线上的 Agent 是不是也这样Demo 时飞得挺漂亮上线后却撞墙、丢目标、偶发才成功同事说“模型升级了端到端通了”你却不知道该信峰值还是均值产品想砍人工审核你又拿不出“什么时候可以少盯一眼”的标准这不是只发生在无人机上。机械臂、巡检车甚至能点浏览器、调 API 的桌面 Agent都会撞上同一类坑只盯端到端成功率会误判能力该不该撤人更没有可执行门槛。Anthropic 与 Andon Labs 的 Project PilotDrone-Bench刚好把这套坑拆开了。下面不按论文复述按你怎么改评测、怎么定门禁来写。先认清真正问题你测的是“整段运气”不是“系统能力”端到端只给你一个 0/1这次任务成没成。它回答不了失败卡在感知、定位、规划还是执行是“偶尔能行”还是“稳定能行”模型升级后是哪一段变好了Project Pilot 把“室内定位并跟随指定人”拆成 5 个必要子任务。你可以直接抄这套拆法到自己的业务子任务无人机场景映射到你的 AgentReconstruct场景建图 / 障碍图环境/状态模型是否可信Localize当前在地图哪运行时状态估计对不对Navigate跨房间路径与纠偏长程规划与闭环修正Detect按参考图找到目标目标识别 / 实体绑定Follow居中跟随、保持距离持续控制 / 策略执行原则子任务要“单独可测、合在一起大体充分”。只测整段成功时你不知道为什么成功失败时你只会说“模型不行”。问题 1端到端突然通了到底发生了什么现象团队常见叙事是“换了新模型端到端忽然能跑了。”听起来像能力跃迁。根因用 Drone-Bench 的结论反推研究里更稳的图像是检测、跟随先变强重建、定位长期更弱前沿模型文中 Fable 5可以在除重建外的任务过基线真机上检测/跟随甚至好于参考算法但重建误差会传到定位和导航模型仍可能朝“以为的门洞”实际是墙飞所以端到端“突然成功”经常不是全系统一夜变强而是最弱子任务终于补上了整条链路第一次同时满足条件。子任务视图把“突变”还原成几条渐进曲线。这对排期很关键你应该优先砸最弱环节而不是只等“下一代模型”。你可以怎么做给每个子任务单独做回归不要只有 E2E 红绿灯。记录误差传播链重建错 → 定位错 → 导航撞墙。发布说明里写“哪一段过线”别只写“任务成功率从 10% 到 60%”。问题 2Demo 很好看上线却不稳现象10 次里总能有几次惊艳平均成功率远低于峰值老板拿峰值排期线上拿均值背锅数据直觉研究给出的量级文中有个很工程的对照多次仿真里模型可能在 45 个子任务上至少成功一次但即便前沿模型平均也往往只能在 5 个里稳定过 3 个基线概括“偶然能做到”大约比“稳定能做到”超前约半年今天的平均表现可能才摸到半年前别人“偶尔刷出来”的峰值。你可以怎么做评测面板至少拆成三列指标含义用途峰值best-of-N能力上界研究/探索均值avg可交付性上线门槛长尾p05/失败模式风险是否要人盯上线看均值和长尾演示看峰值。两者写进同一份报告避免各说各话。问题 3基线该怎么定别用“裸人”或“世界冠军”错法用零基础人类门槛太低过线没意义用全职机器人专家极限调参门槛太高永远上不了线更好的基线研究的做法Andon 的基线是懂 AI 工具、但不是全职机器人专家的人用当下合理工具链能达到的水平。子任务软件化后可反复跑比只靠一次真机 demo 更公平。映射到你的业务基线 熟练工程师 现有脚手架 有限工时 能稳定完成的结果而不是“实习生裸写”或“实验室闭关两周”。当模型在无人持续插手时稳定越过这条基线讨论“少一点人工”才有资格否则你只是在用人工掩盖系统不可交付。问题 4产品想砍审核你怎么说“还不行”或“可以减”这是 Project Pilot 后半段最有用的部分能力过线后人会从“保护”变成“成本”。Agent 编码也走过同样路径早期几乎每步都点同意几个月后长程任务开始少打断。物理控制也会面临一样的组织压力。可直接落地的门禁允许减少人工监督当且仅当同时满足 1) 各关键子任务 平均 ≥ 公开基线 2) 端到端 平均 ≥ 业务阈值含长尾约束 3) 已有独立急停 / 否决 / 接管不依赖模型“同意停自己” 4) 场景外推覆盖主要长尾光照、遮挡、地图变化、目标离开视野等 5) 日志可回放输入、中间假设、动作、失败原因 否则人必须留在关键决策点而不是只旁观。把人工角色写进架构而不是上线后再说谁批准开始执行谁能强制中止失败如何复位日志留多久、谁复盘问题 5日志只记成败排障仍然靠猜研究里有个很“像工程师”的细节前沿模型会在提交前做本地分析——例如用地砖缝估计灭点把相机俯仰估到约 4° 误差内或先画自己的 2D 顶视再本地试跑抓浅层 bug。对你意味着模型不只是吐最终动作还会形成可审查的中间假设。建议至少落这些字段它认为的地图/状态是否离谱外参、坐标系、目标 ID 是否一致策略原建议 vs 最终执行有没有被错误覆盖失败属于哪条子任务、哪段误差传播排障时先问“中间假设错了没有”比只看最终 success 快得多。一套可复制的改造步骤本周就能开干选一个你最痛的端到端任务部署、巡检、分拣、浏览器办流程都可以。拆 46 个子任务每个能单独红绿。定现实基线熟练工程师 现有工具 限时。跑 2050 次同时报峰值、均值、Top3 失败模式。画出误差传播链把工时砸在最弱子任务。在过线前写好人机门禁别等模型平均过线再临时拍脑袋。桌面/API Agent 也可以同一套物理 Agent数字 Agent建图 / 定位页面/状态理解是否正确导航多步工具编排是否偏航检测 / 跟随目标实体是否绑对急停权限、沙箱、人工确认共通点不是“会不会飞”而是接口抽象、评测粒度、过线后的治理。别踩的边界Project Pilot 自己也说了限制低速、单层办公室、人数有限没有充分覆盖户外与拥挤场景软件子任务加速评测不能替代全部真实约束。所以正确用法是用它当拆解评测模板和撤人门禁提醒不要当成“某模型已经可以无人执飞”的产品背书一句话收束端到端突然变强优先检查是不是最后一个子任务补齐了Demo 很好看优先检查你有没有把峰值和均值拆开有人想砍审核优先甩出可复现基线 独立急停 长尾覆盖而不是争模型名字。原文与方法细节见Anthropic Research《Project Pilot: Can AI control a drone?》2026-07-24https://www.anthropic.com/research/project-pilotDrone-Bench 说明https://andonlabs.com/evals/drone-bench
