Amazon Deploys AI Agents Across Fleet of 1M Robots

亚马逊在百万台机器人机群中部署AI智能体 Amazon Robotics 正使用 Aurora 等联邦式 AI 副驾驶取代传统运营仪表盘，以缩短维修时间并将系统可用性提升超过 25%。 Julie Mitchell 介绍了 Amazon Robotics 如何应对在 300 多个履约中心管理超 100 万台移动机器人的挑战。她推介了 AI 副驾驶 Aurora，该系统能将运营数据综合转化为自然语言诊断和自动化维护工作流，使可用性提升超过 25%，并淘汰了 80% 的传统仪表盘。演讲还概述了相关的架构洞察（例如联邦式子智能体与神经符号推理），并分享了渐进式自主以及智能体间互操作性等未来战略布局。 Amazon Robotics 面临的主要运营挑战并非单个机器人的复杂性，而是在庞大的履约中心进行规模化管理与协同调度。 (0:04) 亚马逊在全球 300 多个履约设施中部署了超过 1,000,000 台机器人，与超过 1,000,000 名员工协同工作。 (0:04) 应用自动化的目的在于扩展人类能力、提升安全性并降低运营成本，而非单纯取代人类员工。 (0:04) 15 年来，亚马逊的机器人部署使网络效率提升了 25%，并将员工工伤率降低了 43%。 (0:04) 亚马逊下一代 Shreveport 履约中心在实现效率提升 25% 的同时，对专业工程与维护岗位的需求增加了 30%。 (5:12)

Julie Mitchell of Amazon Robotics reports that managing large-scale warehouse automation requires replacing fragmented dashboards with federated AI agents that translate complex data into actionable operational workflows. Orchestrating Scale Across Robotic Networks (0:04) Amazon operates more than 1,000,000 robots across over 300 fulfillment centers, spanning more than 10 robotic solutions that touch over 75% of customer shipments. Mitchell states that the primary bottleneck is not individual machine design, but coordinating the six core capabilities: storing, identifying, manipulating, packing, sorting, and moving items across thousands of machines and workers. With managers handling up to 50 equipment alerts per shift, every lost second can incur millions in costs. Over 15 years, Amazon reports a 25% efficiency gain alongside a 43% reduction in injury rates. Mitchell emphasizes that automation is intended to extend human capacity rather than replace labor; for example, the 2025 Shreveport, Louisiana facility achieved a 25% efficiency boost over prior generations while employing 2,000 workers and requiring 30% more skilled engineering and maintenance roles. Additionally, Amazon's Mechatronics Apprenticeship Program has trained over 7,000 workers, resulting in wage increases exceeding 40%. Aurora and Eliminating Dashboard Overload (7:10) To address operational fatigue caused by proliferating monitoring software, Amazon introduced the Aurora co-pilot to streamline facility diagnostics into a single interface. Demonstrating the tool at the BDL4 fulfillment center near New York City, Mitchell illustrated how Aurora aggregates telemetry across hardware systems like Robin, Pegasus, Artemis, Cardinal, and Proteus, pinpointing root bottlenecks such as faulted Robin stations instead of leaving floor managers to search through disjointed systems. Once an issue is isolated, Aurora can draft a complete Reliability Maintenance Engineering work order populated with diagnostic contexts and links to repair documentation. Deploying Aurora eliminated 80% of dock operations dashboards, compressed root-cause data investigations from 20 minutes to 5 seconds, improved system availability by more than 25%, and significantly decreased Mean Time to Repair. Data Governance and Federated Agent Architecture (12:44) Reflecting on operational rollouts, Mitchell noted that AI agents fail without robust data foundations, as disparate alarm taxonomies and unstructured standard operating procedures trigger hallucinations that undermine operator confidence. Ground teams also required automated push notifications and shift summaries, as actively querying a pull interface was impractical during live warehouse shifts. To manage technical complexity, Amazon abandoned a single monolithic agent in favor of a federated multi-agent orchestrator that routes tasks like a hospital triage nurse. The architecture employs neuro-symbolic reasoning, coupling the natural-language capabilities of large language models with deterministic fault trees and standardized procedures to ensure safety and auditability. The system is designed to be model-agnostic, enabling Amazon to integrate future protocols and swap model backends without rewriting the entire framework. Amazon Robotics' Strategic Roadmap (19:00) Mitchell outlined four strategic focus areas for Amazon's AI robotics platform: progressing along an 'Observe to Recommend to Act' spectrum toward supervised autonomy, and providing self-service authoring tools so floor-level process experts can update workflows without central developer intervention. The roadmap also prioritizes establishing agent-to-agent interoperability with outside vendors and legacy system deprecation, ensuring older diagnostic interfaces are phased out entirely rather than maintained in parallel with AI systems. While AI agents have reduced dashboard sprawl and downtime, Amazon's strategy relies on resolving data hygiene issues, balancing probabilistic AI outputs with deterministic safety rules, and ensuring on-site operational staff actively adopt automated workflows.

根据亚马逊机器人团队 Julie Mitchell 的阐述，亚马逊物流自动化面临的核心瓶颈并非单个机器人的制造难度，而是数百万台设备与人类员工在超大规模下的协同与运维复杂度；为此亚马逊推出以 Aurora 为代表的 AI 智能体，推动运维体系从被动的静态监控仪表盘向主动的端到端人机协作演化，以显著削减停机成本并优化作业流程。 规模化协同挑战与人机共存理念 (0:04) 亚马逊在全球300多个物流运营中心部署了超过100万台机器人，涵盖10余种不同的自动化解决方案，与上百万名员工共同协作，处理全网超过75%的客户订单。在物流体系中，存储、识别、抓取操作、包装、分拣与搬运这六大核心能力必须高度流畅地衔接。Mitchell 强调，亚马逊推进自动化的核心宗旨不是替代人类员工，而是通过提高作业安全性和吞吐量来增强员工能力，并在投资回报最高的技术环节进行针对性规模化。在部署机器人的15年间，亚马逊网络整体效率提升了25%，同时将员工工伤发生率降低了43%；其机电一体化学徒计划已帮助超过7000名员工完成技能转型，薪资增幅超40%。值得注意的是，2025年在路易斯安那州什里夫波特（Shreveport）启用的新一代运营中心虽然效率相比前代提升了25%且雇佣了2000余名员工，但由于设备密度与精密性提高，该设施对专业工程与维护技术岗位的需求反而增加了30%。 消除监控过载与Aurora智能体实践 (7:10) 在复杂的物流中心现场，各类机械故障警报每班次可能触发多达50次，造成巨大的运维干扰。Mitchell 指出，软件开发团队往往倾向于走阻力最小的路径，即不断堆砌复杂的监控仪表盘与指标图表，但如何让凌晨两点值守的一线操作员实现极简操作，才是极具挑战的工程难题。为此亚马逊开发了出库远程助手 Aurora，这是一个集中的 AI 协作者，旨在提供单一交互入口。在纽约市郊 BDL4 运营中心的实际运行中，操作员只需用自然语言询问出库码头的头号问题，Aurora 即可瞬间扫描 Robin、Pegasus、Artemis、Cardinal、Proteus 以及容器流和暂存区等多个系统的实时数据，将原本耗时20分钟的根因排查缩短至5秒对话。在快速锁定出现故障的 Robin 拣选站为主要瓶颈后，Aurora 能在获得操作员确认后直接生成可靠性维护工程（RME）工单，并附带故障上下文、指标影响、排错指引及备件更换手册链接。这一转变使系统整体可用性提升超25%，大幅缩短了平均修复时间（MTTR），并使出库操作团队精简了80%的原有监控仪表盘与数据界面。 数据治理底座与神经符号架构设计 (12:44) 总结在数百个运营中心落地 AI 智能体的经验，Mitchell 指出 AI 无法弥补低质量的数据基础。若缺乏统一的警报分类标准和规范的标准作业程序（SOP），智能体极易产生模型幻觉并破坏一线操作员的信任；亚马逊在编写智能体代码前耗费数月重构了底层数据卫生和操作规程。在交互形态上，一线主管疲于应对繁忙的现场，缺乏主动提问（拉取模式）的时间，更依赖自动生成的班次摘要与推送警报（推送模式）；而工程与技术专家则需要使用拉取接口进行深度调查。架构方面，亚马逊放弃了最初的单体智能体构架，转而采用类似医院分诊护士机制的联邦式多智能体编排器，将专业任务路由给专门的子智能体，并确保架构具备模型无关性以适配未来模型更新及模型上下文协议（MCP）。此外，针对物理运营的高风险特性，亚马逊引入神经符号推理（Neuro-Symbolic Reasoning），将大语言模型的自然语言理解能力与确定性的硬性故障树及 SOP 相结合，确保操作的可审计性与物理安全性；在评价指标上，工程团队摒弃了提问量等活动指标，完全聚焦于停机时间减少与修复提速等业务成效。 四大未来战略与渐进式自主演进 (19:00) 面向未来，Mitchell 公布了亚马逊推进 AI 赋能机器人的四大战略重点。第一是“渐进式自主”（Progressive Autonomy），推动智能体沿着“观察—建议—执行”的路径演化，在充分保障现场安全的前提下逐步实现故障的自主闭环修复。第二是“自服务工作流编写”，赋能一线流程专家直接修改 SOP 与智能体工作流，打破凡事依赖中央软件团队提交工单的技术壁垒。第三是“智能体间互操作性”，促进内部 AI 智能体跨越亚马逊自身网络边界，与外部软硬件供应商系统进行动态协同通信。第四是“彻底退役遗留工具”，在智能体体系成熟后全面关停淘汰传统监控看板和旧诊断应用，避免新旧系统并行带来的认知负担与运维冗余。 Mitchell 总结认为，物理世界的自动化转型本质上要求软件主动适配一线人员的操作习惯，而非强迫操作人员去学习复杂的专业软件；然而，智能体要从当前的决策辅助全面跨越至无人工干预的安全自主执行，依然取决于严密的底层数据治理、神经符号架构对物理安全边界的严格把控，以及跨厂商智能体协作标准的真正成熟。

## Background 该视频由行业会议频道 Ai4 于 2026 年 8 月 21 日发布在 YouTube 上，主讲人为亚马逊机器人（Amazon Robotics）机器人分拣总监 Julie Mitchell。视频简介介绍了亚马逊如何利用 AI 智能体化解全球最大移动机器人车队面临的运维与诊断难题，通过自然语言排障与智能维护建议为一线工程师赋能，实现人机协同而非机器替代人类。 ## TL;DR 演讲深入剖析了亚马逊在覆盖全球 300 余座设施、超百万台机器人的超大规模物流网络中，如何解决异构多机器人协同及出货码头的运维调度痛点。为了终结一线操作员在传统海量监控面板中搜寻故障的“寻宝游戏”，亚马逊推出了出货远程智能助手 Aurora，支持通过自然语言一键跨系统诊断瓶颈根因并自主创建精准维护工单。实际部署不仅将一线监控工具精简了 80%、系统可用性提升超 25%，还验证了“数据先行”、“Push/Pull 双模交互”、“联邦多智能体架构”及“神经符号结合”等关键工业落地法则。最后，演讲披露了亚马逊机器人未来在渐进式自主执行、自助编排与跨组织智能体互操作等维度的研发布局。 ## Atmosphere & style 整场演讲呈现出一种严谨务实、直击痛点的硬核工业工程风格，发言人摒弃了空洞的 AI 营销话术，将叙事视角牢牢锚定在车间一线操作员面对突发警报的真实困境中。叙事语调沉稳笃定且极具同理心，将复杂的系统架构与一线工人的实际体验紧密交织，既传递出掌管百万级硬件网络的工程底气，又生动展现了先进 AI 从“冷冰冰的监控面板”蜕变为“24/7 全天候副驾”的技术温度与赋能力量。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=EICsZom3nHk&t=4s) 亚马逊机器人覆盖存储、识别、操作、包装、分拣和搬运六大核心领域，处理全网超 75% 订单，其最大工程挑战在于海量异构设备间的全局协同编排。 - [02:03](https://www.youtube.com/watch?v=EICsZom3nHk&t=123s) 自动化战略的核心是扩展员工能力而非取代人类，全球部署逾 100 万台移动机器人的同时使运营效率提升超 25%、工伤率降低超 43%。 - [05:12](https://www.youtube.com/watch?v=EICsZom3nHk&t=312s) 高度自动化催生了更多高端工程需求，2025 年启用的 Shreveport 标杆仓对专业可靠性、维护与工程（RME）岗位的需求反而逆势增长了 30%。 - [07:10](https://www.youtube.com/watch?v=EICsZom3nHk&t=430s) 为破解盲目堆砌看板造成的“仪表盘过载”，亚马逊研发了 Aurora 智能体，实现跨多设备统一检索、故障根因定界与 RME 工单自主闭环。 - [10:18](https://www.youtube.com/watch?v=EICsZom3nHk&t=618s) AI Agent 让系统主动适应人，将现场排障耗时从 20 分钟缩短至 5 秒，系统可用性提升超 25%，日常监控界面数量精简了 80%。 - [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 工业 AI 落地必须“数据先行”，在编写 Agent 代码前先梳理并结构化指标体系与标准作业程序（SOP），避免在劣质数据上强推 AI 损害现场信任。 - [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 交互设计需兼顾 Push（主动推送警报/班次摘要）与 Pull（工程深度下钻分析）双重模式，单靠让现场员工主动提问会导致使用率停滞。 - [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 放弃单体 Agent，构建类似“分诊护士+专科医生”的联邦解耦架构，不仅适应异构业务子领域，更能实现底层模型的即插即用热替换。 - [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 实体物理决策必须采取神经符号结合（Neuro-Symbolic）方法，将 LLM 的概率性自然语言推理与确定性的 SOP 故障树严格结合，确保安全可审计。 - [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 考核 AI 项目必须严格锚定系统可用性、MTTR 修复时间等真实商业结果，坚决避开处理告警数量等表面活跃度的虚荣指标陷阱。 - [19:00](https://www.youtube.com/watch?v=EICsZom3nHk&t=1140s) 未来团队将聚焦渐进式自主执行、一线专家自助式工作流编排、跨组织 Agent 互操作，并最终彻底淘汰传统监控工具以实现 Agent 原生体验。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=EICsZom3nHk&t=4s) 亚马逊出货码头的运营现实与多机器人编排挑战 在大型亚马逊履约中心（Fulfillment Center）的出货码头（Ship Dock），现场主管面临着极高强度的调度压力：一个班次内可能有上百万件包裹必须准时发出，现场数千台机器人与数千名员工紧密协同。当管理人员在处理千头万绪的日常事务时，某台设备突然亮起“发动机故障灯”警报，主管不得不放下手头的一切工作去现场排查；而在一个班次里，类似的警报可能会响动多达 50 次，运营人员急需在海量噪音中迅速判断处置优先级。 亚马逊机器人（Amazon Robotics）网络覆盖了六大核心功能领域：存储（Store）、识别（Identify）、操作（Manipulate）、包装（Pack）、分拣（Sort）和搬运（Move），共同处理全网超过 75% 的亚马逊订单。这些独立的自动化子系统本身已经极其精密，但它们绝非孤立运作，而是紧密咬合、互相交接任务。前置系统的任何停机都会直接波及下游设备，整个网络必须在每栋建筑、每个班次中实现无缝编排。真正的工程挑战不在于单个机器人的复杂性，而在于成千上万台异构设备协同运转时的全局编排。 ```mermaid flowchart LR accTitle: Amazon Robotics 6 Core Competencies A["存储 Store"] --> B["识别 Identify"] B --> C["操作 Manipulate"] C --> D["包装 Pack"] D --> E["分拣 Sort"] E --> F["搬运 Move"] ``` ### [02:03](https://www.youtube.com/watch?v=EICsZom3nHk&t=123s) 亚马逊机器人的自动化哲学与百万级网络规模 亚马逊机器人的核心原则十分明确：“我们制造机器人不是为了取代人类，而是为了扩展员工的能力边界（extend what our people are capable of doing）。”这一理念具体体现在三个战略维度： 1. **提升安全性**：让机器人承担重物搬运、单调枯燥及重复性极高的体力劳动； 2. **降低综合成本**：降低成本并不意味着裁员，而是指在相同的物流基础设施空间内，大幅提升整体吞吐量与处理产能； 3. **战略性规模扩张**：技术部署绝不仅看可行性或实现难度，而是严格评估何处能产生最大价值，并将资源精准投向关键业务瓶颈。 在这一策略下，AI 智能体的定位同样是增强一线操作员的能力，让他们工作更聪明、更迅捷、更高效。目前，亚马逊在全球 300 多座运营中心部署了超过 100 万台移动机器人，涵盖 10 多种不同的机器人解决方案，支持着超过 100 万名员工的日常作业。在实验室里做小规模测试时，遇到问题拿白板和对讲机就能解决；但在百万台设备的跨国超大网络中，操作员每为了调试系统多点一次鼠标、设备每额外停机一秒，都会造成数百万美元的损失。系统易用性与极致简化在这里不是锦上添花的附加功能，而是维持网络运转的运营刚需。 - **全网运行规模**：全球 300+ 栋建筑、100 万+ 台机器人、10+ 类机器人系统，服务 100 万+ 名员工。 - **效率与安全双赢**：全网运营效率提升超 25%，员工工伤发生率降低超 43%。 - **员工技能升级**：机电一体化学徒项目（Mechatronics Apprenticeship Program）已累计培训逾 7,000 名员工，助其薪资水平提升超 40%。 ### [05:12](https://www.youtube.com/watch?v=EICsZom3nHk&t=312s) 2025 年 Shreveport 标杆仓：先进自动化与高技能岗位协同 2025 年在路易斯安那州什里夫波特（Shreveport, Louisiana）启动的全新高度自动化运营中心，集中展现了亚马逊最新一代自动化硬件与 AI Agent 系统的深度融合。 这座标杆建筑在效率提升 25% 的同时，依然雇佣了超过 2,000 名全职员工。更关键的是，高度复杂的自动化环境催生了更高端的人才需求，该设施对熟练维护保养与工程技术人员（RME 团队）的需求岗位数量反而增长了 30%。通过现场视频巡礼可以看到，大规模自动化不仅没有减少人类参与，反而促成了现场操作人员向高技能工程与维护岗位的全面跃迁。 ### [07:10](https://www.youtube.com/watch?v=EICsZom3nHk&t=430s) 破局“仪表盘过载”：Aurora 智能体诞生与实战诊断演示 面对日益复杂的系统，工程团队往往容易陷入一个误区：不断堆砌新的监控工具、制作新的仪表盘、增加新的指标，这是阻力最小的研发路径。但真正困难的工程挑战，是为凌晨两点独自站在车间现场、面对停滞包裹茫然无措的一线操作员，打造出一套真正极致简化的解决方案。 为此，亚马逊开发了出货远程智能助手 Aurora（Amazon Robotics Outbound Remote Assistant）。Aurora 的核心理念是“一个智能体、一个统一界面、一次自然语言对话”，充当 24/7 全天候在线的运营副驾（Co-pilot）。 以纽约市附近的 BDL4 运营中心出货码头为例，现场演示展现了 Aurora 的自主智能流程： 1. **自然语言提问**：操作主管询问“BDL4 出货码头当前最严重的问题是什么？” 2. **多源实时分析**：Aurora 瞬间跨系统检索并分析 Robin、Pegasus、Artemis、Cardinal、Proteus 等各型机器人、容器流（Container Flows）、集货区健康度（Staging Health）及底层设备指标数据。 3. **优先级排序**：输出按业务影响程度排序的前五大问题，直接定位当前吞吐量瓶颈为一台发生故障的 Robin 机械臂工位。 4. **自主创建工单**：Aurora 主动询问并获得授权后，直接调用后端系统生成 RME（可靠性、维护与工程）工单，自动打包注入工位详情、关联指标、影响评估、故障排查步骤及需要检修/更换的具体零部件。 5. **智能文档绑定**：工单中直接附带该故障部件官方更换培训手册的精准链接，使现场技术人员在数分钟内即可闭环处置。 ```mermaid flowchart TD accTitle: Aurora AI Agent Diagnostic Flow User["操作主管发起自然语言查询"] --> Aurora["Aurora 统一智能体"] Aurora --> MultiData["多源实时分析<br>(Robin/Pegasus/Proteus/指标/容器流)"] MultiData --> Rank["输出 Top 5 问题<br>(按实际业务影响加权排序)"] Rank --> RootCause["精准定界根因<br>(例如: Robin 机械臂故障)"] RootCause --> AutoTicket["自主生成 RME 运维工单<br>(包含现场数据、排障指引与更换手册)"] ``` ### [10:18](https://www.youtube.com/watch?v=EICsZom3nHk&t=618s) AI Agent 带来的三大范式转变与业务成效 相比于传统的静态数据看板，AI Agent 为物理运营系统带来了三个颠覆性的核心能力： - **易用性（Usability）**：一线员工无需经过繁琐培训去学习记忆数百个独立监控软件和界面，直接使用自然语言即可对话交互。 - **可诊断性（Diagnosability）**：AI 具备跨数百个异构数据源综合推理与模式识别的能力，将原本长达 20 分钟的“排障寻宝游戏（scavenger hunt）”缩短为 5 秒钟的简短问答。 - **可维护性（Maintainability）**：当网络中引入新型机器人、新硬件组件或新数据流时，Agent 可以自行学习其运行逻辑与排障模式，省去了在全网反复对数千名操作员开展新工具再培训的沉重负担。 这种范式转变的本质在于：“我们不再强迫所有操作员去被动适应系统，而是让系统主动适应操作员。”经过一年的实际部署，该方案取得了显著成效： - **系统可用性提升**：整体设备可用性（System Availability）提升超过 25%，非计划停机与生产中断大幅减少。 - **平均修复时间改善**：大幅缩短 MTTR（Mean Time to Repair），从报障到精准定位再到维修派单全流程提速。 - **工具链极简收敛**：一线操作员日常管理出货码头所需的监控仪表盘与软件界面数量**精简了 80%**。 ### [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 实体工业场景部署 AI Agent 的五大核心经验 在跨数百栋建筑的实际规模化落地过程中，团队总结出了五条关键经验，这对于任何涉及供应链、工厂及物理实体运营的 AI 建设均具备通用参考价值： ```mermaid flowchart TD accTitle: Neuro-Symbolic Multi-Agent Architecture UserQuery["用户查询 / 现场告警"] --> Triage["分流智能体 (Triage Nurse)"] subgraph FederatedAgents["联邦专职智能体层 (Model Agnostic)"] A1["设备健康 Agent"] A2["流程优化 Agent"] A3["告警通知 Agent"] end Triage --> A1 Triage --> A2 Triage --> A3 subgraph NeuroSymbolic["神经符号治理层 (Deterministic Governance)"] LLM["LLM 自然语言推理 (Probabilistic)"] <--> SOP["标准作业程序 SOP & 故障树 Fault Trees (Deterministic)"] end FederatedAgents --> NeuroSymbolic NeuroSymbolic --> OutputPush["Push: 实时移动告警/班次摘要 (现场主管)"] NeuroSymbolic --> OutputPull["Pull: 交互式下钻分析 (工程团队)"] ``` 1. **数据先行，模型在后（Start with your data first）** “绝不能把 AI 生搬硬套在劣质数据之上（You cannot bolt AI onto bad data）。”如果底层警报分类混乱、指标定义模糊、标准作业程序（SOP）没有规范文档化，Agent 不仅会给出毫无用处的回答，更会迅速摧毁一线操作团队对 AI 的信任。团队在编写第一行 Agent 代码之前，耗费数月梳理结构化数据体系与 SOP，这一前期投入在后续迭代中带来了十倍的效率回报。 2. **区分 Push（推送）与 Pull（拉取）双重交互模式** 现场操作团队处于快节奏的生产一线，根本没有闲暇主动打开对话框询问 AI，他们需要的是**Push 模式**（主动警报、班次摘要直接推送到工作流中）；而后台支持与工程团队则需要探索式分析与下钻排查，适合**Pull 模式**。团队早期仅上线了 Pull 模式导致使用率停滞，而在补全 Push 机制后，系统采纳率迎来了爆发式增长。 3. **放弃单体 Agent，转向联邦解耦架构（Federated Architecture）** 物理运营环境涉及设备健康、流程调度、告警分发等多个极度复杂的垂直域，单个庞大的单体 Agent 无法兼顾。架构设计如同医院就医：患者首先接触分诊护士（Triage），随后被精准转诊至各专科医生。这种联邦多智能体模式实现了模型解耦（Model Agnostic），当某一细分领域出现更优模型时，可随时单点热插拔替换，同时契合了 MCP（模型上下文协议）与 Agent-to-Agent 的工业标准演进方向。 4. **神经符号结合（Neuro-Symbolic Approach）：不可单靠 LLM 做物理决策** 大语言模型（LLM）擅长理解自然语言、总结信息和提供建议，但其本质是概率性的；而物理生产运营要求极高的确定性与安全性。因此，必须将 LLM 的自然语言推理能力与确定性的标准作业程序（SOP）和故障树（Fault Trees）严格结合。由神经模型负责推理，符号规则负责硬性约束，确保决策过程百分之百具备可审计性、一致性与可信度。 5. **考核业务实质影响，而非系统表面活跃度（Tie AI to business outcomes）** 不要陷入统计“处理了多少条警报”、“输出了多少条建议”等虚荣指标的陷阱，必须严格衡量业务结果：系统可用性是否提升？排障时间是否压缩？工具复杂度是否下降？当指标转向实质商业价值时，AI 才真正从“另一个额外工具”转变为一线员工不可或缺的底层基础设施。 ### [19:00](https://www.youtube.com/watch?v=EICsZom3nHk&t=1140s) 亚马逊机器人的未来四大战略押注 在技术持续演进的背景下，亚马逊机器人团队公布了未来一年的四大核心研发方向： - **渐进式自主（Progressive Autonomy）**：推动智能体从当前的“观察分析（Observe）”与“建议推荐（Recommend）”，逐步向更大范围的“自主执行处置（Act）”演进，稳步扩大无人干预的自愈闭环。 - **自助式工作流编排（Self-Service Workflow Authoring）**：将流程构建工具赋权给最懂一线业务的车间专家，让他们无需向中央工程团队提需求发工单，即可自行编排、迭代和发布现场 SOP 与排障逻辑。 - **跨组织 Agent 互操作（Agent-to-Agent Interoperability）**：依托开放的工业协议标准，让不同组织、不同系统边界之外的异构智能体能够互相通信、协同推理并联合作业。 - **彻底淘汰传统监控工具（Replacing Legacy Monitoring Tools Entirely）**：目前 Agent 仍会在回答中提供传统工具的跳转链接以建立信任，未来将全面退役和废除这些割裂的旧系统，实现由 Agent 原生驱动的全新统一交互体验。 演讲最后，发言人对负责 Aurora 架构研发的软件开发经理 Karthik Mohan，以及致力于将 AI Agent 应用于亚马逊硬件体系的硬件业务主管 Paul Mitchell 表达了致谢。 ## Notable quotes > [02:03](https://www.youtube.com/watch?v=EICsZom3nHk&t=123s) 我们制造机器人不是为了取代人类，而是为了扩展员工的能力边界（extend what our people are capable of doing）。 — Julie Mitchell > [02:03](https://www.youtube.com/watch?v=EICsZom3nHk&t=123s) 系统易用性与极致简化在这里不是锦上添花的附加功能，而是维持网络运转的运营刚需。 — Julie Mitchell > [07:10](https://www.youtube.com/watch?v=EICsZom3nHk&t=430s) 真正困难的工程挑战，是为凌晨两点独自站在车间现场、面对停滞包裹茫然无措的一线操作员，打造出一套真正极致简化的解决方案。 — Julie Mitchell > [07:10](https://www.youtube.com/watch?v=EICsZom3nHk&t=430s) 一个智能体、一个统一界面、一次自然语言对话 — Julie Mitchell > [10:18](https://www.youtube.com/watch?v=EICsZom3nHk&t=618s) 我们不再强迫所有操作员去被动适应系统，而是让系统主动适应操作员。 — Julie Mitchell > [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 绝不能把 AI 生搬硬套在劣质数据之上（You cannot bolt AI onto bad data）。 — Julie Mitchell > [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 现场操作团队处于快节奏的生产一线，根本没有闲暇主动打开对话框询问 AI，他们需要的是 Push 模式；而后台支持与工程团队则需要探索式分析与下钻排查，适合 Pull 模式。 — Julie Mitchell > [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 必须将 LLM 的自然语言推理能力与确定性的标准作业程序（SOP）和故障树（Fault Trees）严格结合。由神经模型负责推理，符号规则负责硬性约束，确保决策过程百分之百具备可审计性、一致性与可信度。 — Julie Mitchell > [12:39](https://www.youtube.com/watch?v=EICsZom3nHk&t=759s) 不要陷入统计“处理了多少条警报”、“输出了多少条建议”等虚荣指标的陷阱，必须严格衡量业务结果。 — Julie Mitchell ## Mentioned Amazon Robotics, Julie Mitchell, Aurora, Robin, Pegasus, Artemis, Cardinal, Proteus, BDL4 运营中心, 什里夫波特运营中心 (Shreveport), 机电一体化学徒项目 (Mechatronics Apprenticeship Program), RME (Reliability, Maintenance and Engineering), MCP (Model Context Protocol), Karthik Mohan, Paul Mitchell ## Video description Julie Mitchell - Director, Robotic Sortation, Amazon Robotics What if the most complex robotic systems in the world could tell you exactly what's wrong, and how to fix it, before you even ask? Amazon Robotics operates one of the largest fleets of mobile robots on the planet, and as these systems grow in scale and sophistication, so does the challenge of keeping them usable, diagnosable, and maintainable. We're leveraging AI to cut through that complexity, turning mountains of operational data into intuitive insights that empower engineers and technicians at every level. Attendees will learn how Amazon Robotics is applying AI to transform the operator experience, from natural-language diagnostics that surface root causes in seconds, to intelligent maintenance recommendations that reduce downtime and cognitive load. You'll walk away with practical patterns for making complex automated systems more accessible to the humans who run them. Join us to see how AI isn't replacing the people behind robotics, it's giving them superpowers. [Source](https://www.youtube.com/watch?v=EICsZom3nHk)

[2:03] Julie Mitchell: 我们制造机器人不是为了取代人类，而是为了扩展员工的能力边界（extend what our people are capable of doing）。 [2:03] Julie Mitchell: 系统易用性与极致简化在这里不是锦上添花的附加功能，而是维持网络运转的运营刚需。 [7:10] Julie Mitchell: 真正困难的工程挑战，是为凌晨两点独自站在车间现场、面对停滞包裹茫然无措的一线操作员，打造出一套真正极致简化的解决方案。 [7:10] Julie Mitchell: 一个智能体、一个统一界面、一次自然语言对话 [10:18] Julie Mitchell: 我们不再强迫所有操作员去被动适应系统，而是让系统主动适应操作员。 [12:39] Julie Mitchell: 绝不能把 AI 生搬硬套在劣质数据之上（You cannot bolt AI onto bad data）。 [12:39] Julie Mitchell: 现场操作团队处于快节奏的生产一线，根本没有闲暇主动打开对话框询问 AI，他们需要的是 Push 模式；而后台支持与工程团队则需要探索式分析与下钻排查，适合 Pull 模式。 [12:39] Julie Mitchell: 必须将 LLM 的自然语言推理能力与确定性的标准作业程序（SOP）和故障树（Fault Trees）严格结合。由神经模型负责推理，符号规则负责硬性约束，确保决策过程百分之百具备可审计性、一致性与可信度。 [12:39] Julie Mitchell: 不要陷入统计“处理了多少条警报”、“输出了多少条建议”等虚荣指标的陷阱，必须严格衡量业务结果。

[0:00] Julie Mitchell: what if the most complex robotic systems in the world could tell you exactly what's wrong, and how to fix it, before you even ask? [7:10] Julie Mitchell: building another complex dashboard or metric is often the path of least resistance for software developers, but making operations truly simple for a floor operator working a 2 a.m. shift is the hardest engineering problem [7:10] Julie Mitchell: creating software that adapts to the operator rather than forcing operators to adapt to software [19:00] Julie Mitchell: Observe → Recommend → Act

[0:04] So great to see everybody here. Thank you for  coming to listen to how we use AI to simplify [0:10] robotics at Amazon. So I want to first start by  asking you to do something for me. I'd like you [0:16] to imagine you are a ship dock area manager at  one of our very busy Amazon fulfillment centers. [0:22] You have a million orders that need to leave  your building and you have thousands of robots [0:28] and thousands of people working together to try to  make that happen. You're already juggling a bunch [0:34] of things when suddenly a check engine light goes  off in one of your pieces of equipment. You have [0:40] to decide you're going to drop everything you're  working on to go investigate this alarm. Now, [0:46] multiply that by 50 alarms during your shift. You  need help prioritizing on what to do next. That is [0:52] exactly the problem we're solving with our agents  and I'm going to tell you about our journey doing [0:56] that today. These are the six core competencies  that Amazon Robotics delivers to our network. [1:05] We store, identify, manipulate, pack, sort, and  move over 75% of Amazon's orders. These each one [1:14] of these systems are sophisticated in and of it  their own right, but they don't work in isolation. [1:20] Each one works together handing off work to each  other affecting the uptime of each subsequent [1:26] system in our network and they have to seamlessly  orchestrate in every building in every shift and [1:34] that's exactly the challenge that we have. The  problem is not the complexity in any single [1:39] robot. It's the orchestration of all of them  and that's exactly what our agents are solving. [1:47] I just want to let the team know in the back  for AV there's no um speaker notes on the on [1:52] the screen down there. Our philosophy at Amazon  Robotics is clear. We do not build robotics to [2:03] replace our people. We are building our automation  to extend what our people are capable of doing. [2:10] And to us that means three things. First, we  deploy our robotics to improve safety in our [2:16] building. We employ our robots to handle the heavy  lifting, the mundane and repetitive tasks in our [2:22] building. Next, we use our robotics to lower cost.  But by lowering cost, we don't mean that that [2:29] uh replaces our people. What we're talking about  is lowering cost by expending the throughput and [2:36] capacity through the same infrastructure. And  next, we use our robotics to scale strategically. [2:42] So, we don't just deploy our systems where it's  technically feasible or where it's easy to do. We [2:50] look at where it adds the most value and we target  our resources there. And this journey is exactly [2:56] how we think about our AI strategy. We are not  just deploying AI to automate our operators out of [3:04] the loop. We're deploying AI to help extend what  our operators are capable of doing. We think about [3:09] how we can make them smarter, faster, and more  effective at their jobs. So, here are some numbers [3:16] to illustrate our scale. We have deployed over a  million robots globally across over 300 buildings, [3:24] and we have over 10 distinct types of robotic  solutions that support over a million employees. [3:31] Now, I'm not telling you these numbers to impress  you. What I'm talking about is that the scale of [3:38] Amazon Robotics is our challenge. It is easy if  you're running a small pilot in a lab to manage [3:45] issues with a whiteboard and a walkie-talkie.  But when you're running a million robots across [3:51] hundreds of buildings globally, you need help. And  every single extra operator click that's required [4:00] to debug your system and every single second of  extra downtime costs us millions. So usability [4:10] and simplification for us isn't a nice to have.  For us it's an operational imperative. And at this [4:19] point we've been deploying our robotic automations  for over 15 years across the Amazon fulfillment [4:24] network. And we are very proud of the success  we've had operating at this massive scale. So [4:30] we've proven when done right, you can have it all.  You can have efficiency, safety, and productivity. [4:38] And here are some numbers to demonstrate  that. So we have improved the efficiency [4:42] of our network by over 25%. And at the same time,  we reduced our employee injury rates by over 43%. [4:52] and we take care of the people who take care  of our system. We have upskilled over 7,000 [4:58] employees through our mechatronics apprentichip  program which has yielded those individuals over [5:04] 40% higher paying salaries. So now I'd like  you take you on a quick tour of our latest [5:12] highly automated building we launched in 2025  in Shreport, Louisiana. This building uses our [5:19] latest automation coupled with our AI agents, and  it still is 25% more efficient while employing [5:28] over 2,000 employees. In this building, with  its latest automation, there still is 30% [5:36] more roles required in skilled maintenance and  engineering tasks. So, take a look. Heat. Heat. [6:27] [music] [6:27] [music] [6:31] [music] [6:31] [music] [6:31] [music] [6:32] Heat. Heat. [music] [6:55] Heat. Heat. [6:59] [music] [7:02] [music] [7:05] [music] [7:08] [music] [7:10] So, here's the uncomfortable truth we had to  confront. What we've learned is building complex [7:17] systems is easy. building another tool, another  dashboard, another metric, that is the path of [7:25] least resistance for our engineering teams. But  making something simple, and I mean truly simple, [7:32] for the operator that's sitting on the floor  at 2 a.m. trying to figure out why packages [7:37] aren't moving, that's the hardest engineering  problem that we have to solve as a team. And [7:43] that's exactly what we've used our AI agents to  solve. So, we asked ourselves, what if we could [7:50] make it so easy to run the ship dock it would be  impossible to get it wrong? What if the system [7:57] was so smart it could tell you exactly what you  needed to do, what needed to be fixed, and what [8:03] was broken? What if you never had to open another  dashboard again? Well, that's Aurora, our Amazon [8:10] Robotics outbound remote assistant. Aurora is one  agent, one interface, one conversation to help [8:18] our teams figure out what to do next. We think of  this system as a co-pilot for our operations team [8:25] that needs to keep our building running 24/7.  So again, I'd like you to imagine you're an ops [8:32] leader at one of our very busy Amazon ship docks.  This one is a building outside of New York City we [8:38] call BDL4. This is how Aurora is going to help you  with the challenge of getting a million orders out [8:43] of your building today. Here's Aurora's autonomous  intelligence in action. Let's ask Aurora a simple [8:49] question. What are the top issues on the outbound  dock at BDL4? Aurora is now analyzing realtime [8:56] operational data across all systems, Robin,  Pegasus, Artemis, Cardinal, Proteius, Container [9:03] Flows, Staging Health, and equipment health  metrics. Here are the top five issues Aurora [9:08] has identified prioritized by operational impact.  Aurora has automatically analyzed patterns across [9:15] multiple data sources to surface what matters  most. Aurora offers to create a ticket for the [9:20] faulted robin which it has identified as the top  issue impacting throughput. Aurora autonomously [9:27] creates an RME ticket through the backend system,  creating a work order with all relevant context, [9:33] station details, metrics, impact analysis and  remediation procedures, everything RME needs to [9:39] triage and resolve the issue. Aurora provides the  newly created ticket link. Aurora has consolidated [9:46] all failure information for the RME team,  including issue summary with a description of the [9:52] Robin Station fault. key metrics like error rates  and performance impact, troubleshooting steps with [9:59] identified components that need inspection  or replacement, and a direct link to the part [10:04] replacement training manual for reference. This  is Agentic AI at work. From question to analysis [10:10] to action to documentation, all automated, all  intelligent, all within minutes, so you can focus [10:17] on your teams. So why should you use AI agents  instead of just building a simpler and easy to use [10:24] dashboard? Well, AI has unlocked three fundamental  things that make it a gamecher that we couldn't [10:31] handle with static metrics alone. First is the  usability. Our operators can talk to the system in [10:37] plain language. They don't have to learn hundreds  of different interfaces and hundreds of different [10:43] tools to find the data they need. Next is the  diagnosibility. So we can simplify and reason [10:51] with AI over hundreds of data sources to get to  the root cause and turn a 20inut scavenger hunt [10:58] as to what are the patterns that are leading to  this failure into a 5second conversation. And last [11:05] is the maintainability. As we add more robotic  systems, more components, more data sources, [11:11] our agents can reason over them and learn it for  our operators. So we don't have to go out and [11:17] train operators, thousands of operators across our  network every time we want to add a new tool. So [11:23] the paradigm shift that we see is not that we're  using AI to simplify our system. We're actually [11:29] creating a system that adapts to the operator  instead of forcing all of our operators to adapt [11:34] to the system we want to give him. So we're about  a year into our journey and we have uh seen some [11:43] pretty impressive results so far. Um, so we've  been able to improve our system availability by [11:50] over 25%. So that means that there's more robots  running, less downtime, and less interruptions [11:57] to our operations teams. We've also been able to  improve our meanantime to repair metrics. So that [12:03] means when something does break, we're able to  create a a trouble ticket automatically. We're [12:10] able to point to the problem very quickly  and get our systems up and running faster. [12:15] And the outcome I'm most proud of is the reduction  in tooling that we've seen across our operations [12:20] teams. So we have been able to reduce 80%  of the different data dashboards and in [12:26] interfaces that they've had to manage in order  to learn how to run their doc. So in summary, [12:32] we've used our AI agents to collapse all the  complexity that it takes to run our system. [12:39] So, I'm going to shift gears and I've told you  what we've built and the results we've seen, [12:44] but now I want to tell you about what we've  learned over the last year. Uh, we have deployed [12:51] this agent now across hundreds of buildings. Um,  and uh, we have had some pretty hard one lessons [12:58] learned. Um, these lessons we think apply to  whether you're building supply chains, factories, [13:04] any other physical operation. We've distilled  them down to five lessons that I'm going to [13:08] take you through in detail in the next slides. So  the first one is the most important which is start [13:16] with your data first. We learned the hard way uh  you cannot bolt AI onto bad data. If you if your [13:25] alarm taxonomies are inconsistent, if your metric  definitions are not clear, and if your standard [13:32] operating procedures are not documented, your  agent will not only give you responses that are [13:38] not helpful, but they will quickly erode the trust  of your operations teams. Garbagged in and garbage [13:44] out, we all know that saying that applies tenfold  when you're trying to use agents to make realtime [13:50] operational decisions. So we've invested months  in our structured data and operating procedures [13:57] in order to clarify those uh before we even wrote  a single line of agent code. And we found this [14:05] investment paid back 10fold in fewer iteration  cycles and faster time and value. So if you take [14:12] one thing from this talk is start with your data  not with your model. The next was that you need [14:17] both a push and pull experience. Our operations  teams are standing in a live building managing [14:24] hundreds of things. They don't have time to come  to the agent and ask it a question. They need the [14:30] agent to come to them. What that means for us  is we send proactive alerts, automated shift [14:37] sum shift summaries, real-time notifications  that we push directly into their workflows. But [14:44] our engineering and support teams have different  needs. They want to explore, learn, ask questions, [14:52] generate visualizations and triage. So they need a  pull model. We made the mistake early of building [15:00] only the pull experience from our operations team  and we saw adoption stagnate. But once we flipped [15:07] over and provided them a push notification, our  adoption skyrocketed. So the lesson here is know [15:14] your personas and meet them where they're at. You  can't build a one-sizefits-all model. Lesson three [15:23] was that we a single monolithic agent cannot  do it all. And we tried this at the beginning, [15:31] but in our environment with equipment help, the  dashboards, workflow optimizations, alerting and [15:38] notifications. This environment was too diverse  for a single monolithic agent to handle it all. So [15:45] we switched over to a federated architecture, an  orchestration that routes requests to specialized [15:51] agents. We think of it like a hospital. When you  go into a hospital, you don't want you will not [15:58] get one doctor that can diagnose you head to toe.  You go to a triage nurse that routes you to the [16:03] right specialist. That's exactly the pattern that  we've built with our agents. And now here's the [16:09] strategic benefit that we learned by doing this.  Each specialized agent that we build can exist on [16:15] its own model. So that means we're model agnostic.  We when a better better model comes along for any [16:22] one of our particularized specialized agents,  we can swap in that new model and not have to [16:27] rewrite the whole system. When we started doing  this over a year ago, this was not the norm. We [16:34] sort of found our way into this pattern. But  now industry standards like MCPs and agentto [16:39] agent models are making this architecture the way  it's going in the future and we realize this is [16:45] the absolutely the right direction to go into. So  the next lesson and if you're operating physical [16:51] systems like we are this one is the one that you  should underline. You cannot rely on LLMs alone [16:58] to do your reasoning. They are incredible  at understanding natural language. They are [17:05] great at summarizing information and providing  recommendations but they are probabilistic and [17:12] in real time operations you need some certainty.  So what we've approached the u method of is you [17:21] using a neuro symbolic approach. This means  we can use our LLMs to do the reasoning, [17:28] but we create standard operating procedures and  fault trees to do the governing. And this gives [17:34] us the flexibility of natural language with the  rigor of established operational procedures. This [17:41] is how we maintain audibility, consistency,  and trust at scale across our systems. So if [17:47] you're in any domain where physical systems  are involved, this pattern is non-negotiable. [17:55] And our last lesson is you need to tie  your AI system to a business outcome. It [17:59] might be tempting to report on your  AI agent productivity as the number [18:04] of alarms you process or the number of  recommendations you make to your teams, [18:09] but really what you want to be measuring is the  impact you had. Did we actually simplify the [18:15] system? Did we simplify the usability? Did we  improve the time that it takes to diagnose it? [18:21] When we switched from measuring Aurora's  activity to measuring Aurora's impact, we [18:27] saw huge adoption from our operations team because  they understood the value they were getting out [18:32] of using it. It wasn't just another tool. It  became an infrastructure they depended on. [18:41] So, bringing it all together, these are  the five major lessons we've learned. Um, [18:46] it's been great to hear all the  talks through this conference. [18:49] um seeing similar patterns, but I look forward  to connecting with all of you after and seeing [18:53] if there's anything on this list that might  be different that we haven't learned yet. [19:00] And we know that this is just the beginning  of our journey. There is so much more value [19:05] we plan to extract from our operations  teams using AI. So, I wanted to share [19:10] with you the four big bets that we're making in  the coming year. First is progressive autonomy. [19:17] Today our agent acts or advises and recommends  and on a small set of capabilities it will act. [19:26] We plan to expand this capability along  that axis where we can first observe then [19:32] recommend then act. That's the progression we  plan to go down. Next is self so selfservice [19:40] workflow authoring today. We understand our  operations as they exist now and we can build [19:47] the standard operating procedures and workflows  for our operations teams, but we'd like to hand [19:53] that power over to the people that understand  the processes very deeply and want to evolve [19:59] and change them over time. We'd like them to  be able to self-service these workflows and [20:04] implement them without having to create engineer  an engineering ticket to our central teams. Next [20:10] is agentto agent operability. Today our systems  and agents can operate in the environment that [20:17] we've created for them. But tomorrow with this  new industry protocols I mentioned we expect them [20:24] to be able to a reason across very far uh agents  well outside of our own organizational boundary. [20:33] And lastly, we are working on replacing  legacy monitoring tools entirely, [20:37] not just augmenting them. Today, when our  agent reasons and provides a recommendation, [20:42] it'll provide links back to the existing tools  to be able to create that trust and close loop [20:48] with our operations teams. But tomorrow, they're  not going to need even links to the legacy tools. [20:53] We will eliminate and deprecate those systems  altogether. We are still early but we know that [20:59] there is significant amount of change and value  that's coming. Um and we look forward to sharing [21:05] that with you. So I'd like to thank you for our  time. Uh these this is the contact information [21:13] of the folks here. Um Karthik Mowen is here is  the SDM who built Aurora for us. Paul Mitchell a [21:19] hardware uh leader at who's applying AI agents  to our Amazon hardware. Thank you very much.