AWS 多智能体系统用于航空部件替代评估：确定性代码做判定，大模型做检索、路由与合成

航空工程师面对一个已停产或交期过长的合格部件时，需要花数天时间在供应商数据手册、接口控制文档和资质记录之间交叉比对，才能写出一份替代论证供评审。错误的替代在飞行关键部件上可能导致任务失败，而支撑每个决策的证据链往往散落在邮件和未记录的机构知识中，没有正式的可重复审查包。

AWS 机器学习博客描述了一套多智能体工程助手，试图压缩这个手动交叉比对过程。其核心设计规则只有一条：工程师做每个决定，系统组装支撑该决定的证据。这条规则决定了哪里使用大语言模型、哪里使用确定性代码。

架构由三个支柱定义。第一，确定性规格适配评估：用 Python 编写的容差规则代码，将每个候选部件与参考部件及工程师声明的需求逐项比对。因为相同输入始终产生相同的通过/标记结论，结果可以进入正式工程审查。第二，多智能体编排：一个轻量规划器将查询路由到三个专家智能体（目录、评估、知识），仅当两个以上专家贡献了结果时，一个监督者才进行综合。第三，人在回路决策：系统起草论证备忘录和集成影响评估供工程审查，但不推荐或批准替代。每次评估还写入与 AS9100 第 8.4 和 8.5.6 节对齐的审计条目。

模型分层是这套架构中一个务实的成本-延迟选择。路由是分类任务，不涉及工具调用，不需要大推理模型，基于 Haiku 的规划器在几秒内返回编号路由方案。专家智能体使用 Sonnet 执行工具。Opus 监督者仅在两个以上专家贡献时运行，因为综合单个专家已完整的答案会增加约 8 秒延迟而没有质量收益。

确定性评分引擎是整个系统可审计性的基础。规格适配评估作为普通 Python 代码运行，对照手写的分类需求模式。模式为每个部件类别定义关键规格和容差规则，score_substitution_fit 逐项比较、计数通过和标记、并呈现生命周期风险。因为结论必须可复现，此步骤不涉及任何大语言模型。专家智能体呈现结果表并解释标记，但不能改变判定。

Amazon Nova 多模态嵌入在此方案中承担两个不同角色。在多模态检索中，数据手册、接口控制文档和性能图表被嵌入同一语义空间，工程师可以输入文字查询或上传图表图片，检索返回匹配图表并附来源归属。在视觉相似度评分中，当两个候选部件被比较时，Nova 多模态嵌入对其照片计算余弦相似度，然后 Claude 分析具体可观察差异（安装孔位、连接器位置、外壳几何）。这个分数为确定性规格比较提供辅助证据，但判定本身基于规格比对。

作者分享了构建检索路径时的三个实践教训。第一，索引前裁剪图表：整页数据手册约 90% 的内容（页眉、规格表、页脚）是所有部件共享的样板，会主导嵌入向量。裁剪图表区域后，图片上传匹配从 7 个部件中 3 个正确提升到 7 个全部正确。第二，当工程师指定部件名时过滤结果：跨模态文本到图片相似度不能可靠返回正确部件的图表，因为扭矩曲线图片中没有可见部件名。第三，记录图片路径上的每次静默回退：缺少 s3vectors:QueryVectors 权限不会报错，图片查询静默降级为文本检索，模型随后以高置信度给出错误部件名。

评估结果方面，所有轨迹级质量指标得分在 0.95 以上，工具参数提取接近满分 0.980。工具选择准确率从 0.809 提升到 0.861，主要归因于合并为单一托管知识库、修复图片查询路径的缺失权限、以及收紧规划器路由避免串联不必要的专家。目标成功率 0.892 较低，因为查询集包含安全类提示——智能体正确拒绝推荐或批准替代，但评估器将正确拒绝计为未达成目标。

需要明确的是，所有评估数字来自虚构制造商 AnyCompany 的合成数据集上的自报测试，未经真实工程评审或独立复现验证。该方案展示的是一个可复用的架构模式：在判定结论需要可审计和可复现的领域，将确定性代码与 LLM 推理严格分离，LLM 处理模糊检索和叙述合成，代码处理精确比对和最终判定。