Blue Origin：用多智能体加速月球硬件研发

航天硬件的时间困局

Blue Origin 是一家航空航天制造与航天飞行服务公司，业务覆盖运载火箭、载人飞行器和月球着陆器等复杂系统。传统月球硬件研发采用跨专家顺序推进的需求、仿真与原型循环，整体周期以年计。问题不在于某个环节效率低，而在于串行依赖本身：结构等热分析，热分析等材料参数，材料选型又受制造工艺约束。

对正在推进月球着陆器项目的 Blue Origin 而言，这种节奏构成直接的业务矛盾。航天项目的时间窗口由发射计划和合同节点决定，不会因为设计周期长而自动延后。企业技术副总裁 Will Brennan 在官方案例中提到，2 至 3 人的小团队配合大规模 AI 智能体团队，可以交付数十人的工作量。核心问题因此是：能否在不降低工程安全标准的前提下，把多学科串行迭代变成可自动执行的循环？

平台构成与智能体分层

Blue Origin 的做法不是把大语言模型接入某个设计工具，而是构建名为 BlueGPT 的企业内部 AI 生态系统，它同时包含安全 LLM 网关、智能体市场和多智能体编排平台。平台让员工创建专业智能体，并连接内部专有知识库、自定义工具和多种模型。

底层基础设施方面，官方案例列出多项 AWS 服务：Amazon EKS 承担智能体运行时，托管 MCP 服务器、数据提取和制造执行系统等微服务；Amazon OpenSearch 用于构建 RAG 知识库；Amazon RDS 提供结构化数据存储；AWS Lambda 处理事件驱动计算；Amazon EC2 P5 与 G5 实例提供 GPU 仿真算力，Spot 实例用于成本控制。Amazon Bedrock 承担安全 LLM 网关角色；Strands Agents SDK 是模型驱动的智能体编排框架，官方描述其强调由 LLM 推理主导，而非依赖僵硬的工作流控制，同时把 AI 应用开发时间从数周压缩到数小时或数天。Amazon Bedrock AgentCore 提供会话级与持久化记忆，使智能体跨任务协作时保留上下文。

图 1

BlueGPT 平台层级与系统边界

整个智能体架构采用分层协调模型，由专业领域智能体根据问题复杂度和上下文调整行为。（DataHub 判断：该机制意味着任务不必走同一条固定流水线，而由协调层决定参与者与执行顺序；前提是官方对"分层协调"的描述对应可动态组合的调度逻辑，官方未展开调度规则。）

TEAREx：人机协作闭环

TEAREx 全称 Thermal Energy Advanced Regolith Exchanger，官方描述其在优化腔体中向月球土壤存取热能，用于帮助月面系统度过长达两周的月夜。这类硬件同时受热、结构、材料与制造工艺约束，跨学科协同复杂度高。项目组装了监督、资料、需求、设计和分析等专业智能体团队，与 2 至 3 名人类工程师协同：人类负责方向设定、约束定义与最终验收，智能体承担检索、计算、仿真和迭代。

图 2

TEAREx 硬件外观

工作流程上，智能体连接 AI 原生工具，在 GPU 加速实例上运行复杂物理仿真，依据工程要求评估结果、修改设计并循环执行，直到满足规格。官方另有一项独立结果声明：通过自动化拓扑优化循环交付质量优化设计，说明迭代中的"设计修改"包含拓扑优化这类具体工程计算。官方用"autonomously"描述该闭环的执行方式，但未描述改造前的人工操作步骤。此外，Operations 团队通过 AI 中介与供应商沟通设计变更，该场景的实施细节官方未展开。

图 3

人机分工、控制点与自动迭代边界

从单一项目到组织级渗透

TEAREx 不是 BlueGPT 的唯一应用。AWS 案例称 BlueGPT 已在公司内部创建并部署超过 2,700 个智能体，上月产生 350 万次交互，企业采用率 70%。这三项描述平台整体，与 TEAREx 项目结果不同口径。制造环节，团队用智能体改进工单并将不合格项处理速度提升 70%；软件开发方面，案例称 95% 的软件工程师已使用生成式 AI 工具编写代码。这些数字对应不同场景与统计口径，不能加总为"全公司效率提升"。

已完成的智能体被保留在市场中，可重新组合用于其他硬件部件，即 TEAREx 中验证过的五类智能体不是一次性脚本。AWS 高级解决方案架构师 Jay Naves 在案例中指出，Strands Agents SDK 使团队能够快速构建和迭代智能体，把 AI 应用开发时间从数周压缩到数小时或数天。官方案例还提到 Blue Origin 正在构建企业知识图谱、测试自主月球车的自定义模型，并计划把智能体工作流扩展到 New Glenn 轨道火箭与月球着陆器项目。官方未披露复用带来的成本影响。

结果口径与证据边界

官方案例中有两个加速数字，出现在不同层级：页面级摘要写"accelerate lunar hardware development by 75%"，属于平台整体加速表述；TEAREx 详细结果列表写"Reduce hardware development by 90% — from years to days"，指向单一项目结果。官方未解释两者的计算关系，本文按语境层级分别标注，不作合并或矛盾判断。其余结果：分析工作流加速 6 倍（4 天→4 小时）；Strands Agents SDK 带来的 10 倍开发提速；平台级的 2,700+ 智能体、350 万次月交互、70% 采用率、不合格项处理提速 70%、95% 软件工程师使用率。

口径限制集中在三处：90% 与 6 倍未披露计算基线，"多年"是历史平均、最近一次同类项目还是工程估算，"数天"是日历天还是工时，均未说明；分析任务的数量、类型与是否含人工复核未披露；70% 采用率的分母未定义。案例由 AWS 发布，属供应商官方客户案例，未见独立第三方审计；平台建设成本、模型调用成本和运维团队规模未提及。官方结果列表末条为打造"可用于月球部署的"智能体设计硬件，是设计目标声明，认证与飞行状态不在披露范围内。官方页面末尾另出现"Lunar battery solar charging system 100%"字样，未附口径说明且未收录进本文事实包，本文按不可核实项排除。

图 4

结果口径分层与证据缺口

迁移判断

DataHub 判断：该路径对拥有大量内部专有知识、设计流程依赖跨学科串行协作的工程密集型企业，以及已使用物理仿真工具但仿真—评估—改型循环仍由人工驱动的制造团队，参考价值较高。前提是瓶颈与 Blue Origin 类似，落在迭代循环的等待与协调成本上，而非单次计算速度；依据是官方披露的智能体分工与自动迭代闭环，并非官方对适用范围的声明。

DataHub 判断：复制该结构需要三项条件——足以支撑 RAG 的内部知识积累、具备可编程接口的仿真工具、以及能承担平台前期投入的组织规模。前提是官方描述的网关、知识库、记忆与市场作为一套整体存在；官方未披露投入规模，因此投入门槛只是结构推断。