正文 · AI 翻译
当一个已获认证的航空航天零部件停产或交付周期变长时，工程师要花数天时间，对照供应商数据手册、接口控制文件（ICD）和认证记录中的规格，然后撰写替代论证供审核。飞行关键部件的错误替代可能导致任务失败；然而，每项决定背后的证据链往往散落在电子邮件和未成文的机构知识中，因此没有供审核人员检查的正式、可重复使用的材料包。上一篇文章《使用 Amazon Nova Multimodal Embeddings 实现制造业智能》展示了该模型如何检索纯文本处理流程无法获取的工程图、热性能曲线和数据手册图表中的答案。本文承接上述检索工作，将这些能力用于一个多智能体系统，从检索到起草评估报告，汇集替代方案的证据。本文展示如何使用 Amazon Bedrock AgentCore、Amazon Nova Multimodal Embeddings 和开源 Strands Agents SDK 构建多智能体工程助手，减少零部件替代评估中人工交叉核对的工作。一个规划智能体将工作分配给 3 个专业智能体，它们搜索多模态知识库、根据确定性的公差规则为候选件评分、比较零部件照片，并用实时网络数据佐证生命周期相关说法。工程师始终是决策者，因为系统只汇集证据和起草文档，绝不自行批准替代方案。解决方案概览 该助手围绕一项设计原则构建：每项决定都由工程师作出，系统负责汇集相应证据。这项原则决定了我们在哪些环节使用大语言模型（LLM），又在哪些环节使用确定性代码。该架构由 3 大支柱构成：确定性的规格匹配评估——用 Python 编写的公差规则代码，根据参考零部件和工程师提出的要求，为每个候选零部件评分。由于相同的输入总会产生相同的通过或标记结果，这些结果可纳入正式工程审核。多智能体编排——一个轻量级规划智能体将每个查询交给 3 个专业智能体（Catalog、Evaluation、Knowledge）中的 1 个或多个；仅当超过 1 个专业智能体参与时，监督智能体才会汇总其发现。对于“检查这个轮子是否即将停产、寻找替代品并为其评分”等复杂问题，系统会依次调用全部 3 个专业智能体。人在回路中的决策——系统起草供工程审核的替代论证备忘录和集成影响评估，但不推荐或批准替代方案。每次评估还会写入一条符合 AS9100 第 8.4 节和第 8.5.6 节要求的审计记录。下图展示了该架构。图 1：基于 Amazon Bedrock AgentCore 的多智能体工程助手架构 Amazon Bedrock AgentCore 是一个可使用任何框架或模型、大规模构建、连接和优化智能体的平台。在本解决方案中，来自工程师应用程序的聊天请求进入托管在 AgentCore 运行时上的多智能体图：规划智能体（Claude Haiku 5.5）生成路由计划，专业智能体（Claude Sonnet 5.5）执行各自的工具；当超过 1 个专业智能体运行时，监督智能体（Claude Opus 5.5）汇总其结果。专业智能体从我们使用 Amazon Bedrock Managed Knowledge Bases 和 Amazon Nova Multimodal Embeddings 创建的托管知识库中检索信息；请求通过 Amazon Bedrock AgentCore 的一项功能 AgentCore Gateway 路由，同时使用 Web Search 连接器获取实时网络数据。对于以图像作为查询的情况（上传图表以识别零部件），智能体直接调用原生 Amazon S3 Vectors 索引，因为托管知识库的检索 API 不接受图像输入。Amazon S3 Vectors 是 Amazon Simple Storage Service（Amazon S3）的一项功能。 一条独立的固定流程（知识、评估、主管，依次执行）生成正式的集成影响评估（IIA）文档。Amazon Nova Multimodal Embeddings 发挥两种不同的作用：多模态检索——使用 Nova Multimodal Embeddings 为数据表、接口控制文档（ICD）和性能图表生成嵌入，使文本和视觉内容处于同一个语义空间。工程师可以输入“0.06 Nms 飞轮的扭矩曲线”，也可以上传图表图像，检索结果会返回匹配的图表并注明来源。视觉相似度评分——比较两个候选零件时，Nova Multimodal Embeddings 会计算其照片之间的定量余弦相似度，Claude 则分析具体的物理差异（安装孔位、连接器位置、外壳几何形状）。该分数为确定性的规格比较提供辅助证据，而适配结论以规格比较为依据。前提条件 要跟随操作，你需要：一个可在美国东部（弗吉尼亚北部）AWS 区域访问 Amazon Bedrock 的 AWS 账户。在 Amazon Bedrock 中拥有 Amazon Nova Multimodal Embeddings、Claude Haiku 5.5、Claude Sonnet 5.5 和 Claude Opus 5.5 的模型访问权限。关于各区域的模型可用性，请参阅《Amazon Bedrock 中各 AWS 区域支持的模型》。使用 Amazon Bedrock Managed Knowledge Bases 创建的托管知识库，并以 Amazon Nova Multimodal Embeddings 对零件语料库（数据表、ICD、描述）进行文本和文档检索。针对零件照片和数据表图表裁剪图建立的 Amazon S3 Vectors 索引，用于以图像作为查询的检索路径。一个配置了 Web Search 连接器和托管知识库目标的 Amazon Bedrock AgentCore Gateway。用于运行笔记本的 Python 3.10 或更高版本以及 Jupyter。如果要改用笔记本 03 中的部署方案，在 AgentCore 运行时上托管代理，还需要 Docker。GitHub 仓库中的示例代码。解决方案详解 以下各节按照查询使用系统各部分的顺序进行说明。我们先介绍零件语料库和专用代理，然后介绍路由、确定性评分、助手使用 Nova Multimodal Embeddings 的两种方式、生成正式文档的固定流程，以及如何部署到 AgentCore 运行时。完整的代码示例是 GitHub 仓库中的 5 个 Jupyter 笔记本，每个笔记本均可独立运行。这些笔记本从 mei_core 导入模块；mei_core 是同一文件夹中代理和工具模块的一份独立副本。笔记本还包含各自的零件数据、图表裁剪图和评估查询集。无需其他应用程序代码，你就可以通过这些笔记本运行本文中的每个代码片段。组织零件语料库 示例数据集包含虚构制造商（AnyCompany）的 7 款反作用飞轮，动量存储范围为 0.003–5.0 Nms。每个零件对应一个文件夹，将结构化数据与工程师实际阅读的源文档放在一起；这种组合使语料库具有多模态特性。specs.json 文件保存用于确定性评分的机器可读字段，而 ICD、产品照片和渲染后的数据表页面则提供结构化字段未涵盖的视觉和文字细节。data/synthetic-parts-data/rw_rl_0060/ ├── specs.json # 结构化规格 + 生命周期字段 ├── description.txt # 用于文本检索的纯文本 ├── AC-ICD-00068-RW3-0.06-Interface-Control-Document-v2.2.pdf ├── datasheet_page.png # 渲染后的数据表页面 ├── datasheet_chart.png # 裁剪后的图表区域（以图像作为查询的索引） └── photo.png # 产品图像（视觉相似度 + 图表匹配） specs.json 文件同时记录工程规格和生命周期概况，使助手能够在判断规格适配性的同时提示停产和交货周期风险。 { "name": "AnyCompany RW3 0.06", "category": "reaction_wheel", "vendor": "AnyCompany", "model": "RW3-0.06", "momentum_storage_nms": 0.06, "max_torque_mnm": 20, "mass_g": 235, "voltage_v": "28", "voltage_range_v": "7.5 to 36", "operating_temp_c": "-30 to +70", "interface": "RS-422 or Redundant RS-485", "qual_standard": "AnyCompany internal (flight heritage qualified)", "lifecycle": { "lifecycle_status": "Active", "production_status": "Full production", "estimated_years_to_eol": "10+", "last_time_buy": "Not announced", "typical_lead_time_weeks": 10, "lead_time_risk": "Low", "bathtub_region": "Useful life (highly mature)", "recommended_screening": "Standard flight acceptance" } } 每个部件的 vendor 字段都已明确给出。由于目录文件夹 ID 和文件名会在不同数据集中重复使用，每个专家的提示都将 get_part_specs 返回的结构化 vendor 值视为权威信息，并禁止根据 ID、文件名、照片或网络搜索结果猜测制造商。从结构化数据中获取制造商信息，可以避免助手因自以为认出了硬件而将部件错误地归属于其他供应商。每个部件文件夹还包含两项纯文本索引无法使用的素材。产品照片用于视觉相似度评分，而渲染的数据表页面包含扭矩框图和扭矩曲线图，可回答 OCR 文本层无法捕获的性能问题。Amazon Nova Multimodal Embeddings 将两者与文本嵌入同一向量空间，因此查询可以匹配规格值、段落或图表。以下示例展示了语料库中的 4 页数据表，涵盖跨越 3 个数量级的动量存储量。图 2：部件语料库中的 4 页数据表，涵盖跨越 3 个数量级的动量存储量。该模板在整个产品系列中重复使用，但产品照片和两张性能图会随每个部件而变化。这些区域展示了外壳几何形状、安装孔位、扭矩范围和功耗，而规格字段并未直接说明这些信息，因此我们将它们与文本一起嵌入。为专家定义限定范围的工具。每个专家都是一个 Strands 智能体，配有范围明确的提示，且只能使用所需工具。按专家限定工具范围可以使行为更可预测，因为知识专家无法使用目录发现工具，而目录专家无法使用评估工具。以下代码创建评估专家。from strands import Agent def create_evaluation_specialist() -> Agent: """评估专家：按规格逐项进行确定性比较和评分。""" return Agent( name="evaluation_specialist", system_prompt="""你是评估专家。你的工作是在部件之间进行确定性的、由规格驱动的比较。... 规则：- 你的比较必须是确定性的（基于代码，而非意见）- 绝不推荐或批准——只提供证据和标记；由工程师决定 - 始终附上声明，说明这些内容仅供参考，属于证据""", tools=[score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo], model="us.anthropic.claude-sonnet-5-5", ) 下图展示规划器如何将查询路由到各位专家，以及主管何时综合他们的结果。其后的列表说明每位专家的职责。图 3：规划器如何将查询路由到专家，以及主管何时综合结果。目录——通过知识库搜索和穷尽式规格筛选来发现部件（kb_search、filter_parts_by_spec、get_part_specs、get_substitution_requirements）。评估——以确定性方式为候选部件评分，并对部件进行视觉比较（score_substitution_fit、compare_parts、visual_similarity_score、check_qualification_status、generate_substitution_memo）。 知识——回答数据手册和 ICD 中的问题，检查实时停产状态，并检索视觉内容（get_part_specs、web_search_eol、retrieve_visual_content）。使用小模型进行路由，使用大模型进行综合。路由是一项不调用工具的分类任务，因此不需要大型推理模型。基于 Haiku 的规划器会在几秒内返回编号的路由计划。只有当两名或更多专家参与时，Opus 监督模型才会运行，因为对单名专家已经完整的回答再进行综合，会增加约 8 秒的延迟，却不会提高质量。# 步骤 1：规划器（快速模型）规划路由（可能包含多个步骤）。plan_response = planner(planning_prompt) ordered_specialists = _parse_specialist_plan(str(plan_response)) # 步骤 2：按顺序运行专家，并向后传递上下文 accumulated_context = "" for spec_name in ordered_specialists: specialist = specialists[spec_name] specialist_response = specialist(spec_prompt) accumulated_context += f"\n[{spec_name.upper()}]: {specialist_response}\n" # 步骤 3：仅当运行了 2 名或更多专家时才进行综合。if len(ordered_specialists) == 1: final_text = steps[0]["response"] else: final_text = str(supervisor(synthesis_prompt)) 将工作分配给 3 个模型层级，可以使每个阶段的成本和延迟与任务相匹配。Haiku 对查询进行分类，Sonnet 运行工具，Opus 撰写综合答案，而这一步最需要保证回答质量。保持评分的确定性。规格匹配度评估作为普通 Python 代码运行，依据的是手工编写的需求模式。该模式定义了每类组件的关键规格和容差规则；score_substitution_fit 会逐项比较规格，统计通过项和标记项，并指出生命周期风险。由于结论必须能够在工程评审资料中复现，这一步不涉及 LLM。{ "categories": { "reaction_wheel": { "critical_specs": [ {"field": "voltage_v", "label": "Bus voltage (V)", "rule": "match", "required_from_user": true}, {"field": "mass_g", "label": "Mass (g)", "rule": "candidate_lte_reference_within_pct", "tolerance_pct": 20, "required_from_user": false} ] } } } 该工具返回结构化结论，并附有明确的免责声明：return { "spec_results": results, # 每项规格的通过／标记／待审核状态 "counts": counts, "out_of_tolerance": out_of_tolerance, "lifecycle": {...}, # 停产和交货期标记 "summary": summary, "disclaimer": "仅供提供证据。本工具不建议或批准替代；由工程师决定。", } 专家会展示此表并解释各项标记，但不能更改结论。审计记录也遵循同样的职责分工。每次评估后，编排层会读取专家的工具调用历史，并自行写入审计条目，因此记录日志不依赖模型记得去做。使用 Amazon Nova Multimodal Embeddings 评估视觉相似度。当替代件必须装入现有支架时，外形尺寸就很重要。visual_similarity_score 工具使用 Nova Multimodal Embeddings 对两个零件的照片生成嵌入并计算余弦相似度，然后请 Claude 描述具体可观察到的差异。 def embed_image(image_bytes): """使用 Nova MME（IMAGE_RETRIEVAL）将一张图像嵌入为 1024 维向量。""" b64 = base64.b64encode(image_bytes).decode('utf-8') fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg' body = { 'taskType': 'SINGLE_EMBEDDING', 'singleEmbeddingParams': { 'embeddingPurpose': 'IMAGE_RETRIEVAL', 'embeddingDimension': 1024, 'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt, 'source': {'bytes': b64}}, }, } resp = bedrock.invoke_model( modelId='amazon.nova-2-multimodal-embeddings-v1:0', body=json.dumps(body), accept='application/json', contentType='application/json', ) result = json.loads(resp['body'].read()) return np.array(result['embeddings'][0]['embedding']) # 计算两张照片嵌入向量的余弦相似度 emb_a, emb_b = embed_image(photo_a_bytes), embed_image(photo_b_bytes) similarity = float(np.dot(emb_a, emb_b) / (np.linalg.norm(emb_a) * np.linalg.norm(emb_b))) 嵌入向量的相似度具有确定性且可复现：同一产品系列的两个轮子的相似度约为 0.84，不同类别的轮子约为 0.40。随后，Claude 的视觉分析会解释造成差异的原因，例如指出一个外壳的直径大约是另一个的两倍，而且一个采用六孔安装方式，另一个采用四孔安装方式。通过两条检索路径检索图表和示意图 文本和文档查询通过由 Amazon Nova Multimodal Embeddings 支持的托管知识库进行，并经由 AgentCore Gateway 路由。以图像作为查询（上传图表或照片以查找匹配内容）时，代理直接调用原生 Amazon S3 Vectors 索引，因为托管知识库的检索 API 不接受图像输入。Knowledge 专家的 retrieve_visual_content 工具为这两条路径提供统一接口。工程师可以将需求文档中的性能曲线粘贴到聊天中，询问哪个零件与之匹配，也可以改用文本查询描述该图表。# 以图像作为查询：使用 Nova MME 嵌入上传的图像，方式与建立索引时嵌入数据表裁剪图和照片的方式完全相同。 def embed_query_image(image_bytes): b64 = base64.b64encode(image_bytes).decode('utf-8') fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg' body = {'taskType': 'SINGLE_EMBEDDING', 'singleEmbeddingParams': { 'embeddingPurpose': 'IMAGE_RETRIEVAL', 'embeddingDimension': 1024, 'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt, 'source': {'bytes': b64}}}} r = bedrock.invoke_model(modelId=NOVA_MME_MODEL_ID, body=json.dumps(body), accept='application/json', contentType='application/json') return json.loads(r['body'].read())['embeddings'][0]['embedding'] 在图像路径中，上传的图像通过 Nova Multimodal Embeddings 以 IMAGE_RETRIEVAL 用途嵌入为 1,024 维向量，然后与 S3 Vectors 索引进行匹配：# 查询原生 S3 Vectors 索引，并为每个零件保留最佳向量。 emb = embed_query_image(image_bytes) s3v = boto3.client('s3vectors', region_name=REGION) fetch_k = max(top_k * 6, 12) # 每个零件有多个向量；在下方去重 resp = s3v.query_vectors( vectorBucketName=S3_VECTOR_BUCKET, indexName=S3_VECTOR_INDEX, queryVector={'float32': emb}, topK=fetch_k, returnDistance=True, returnMetadata=True, ) best = {} for v in resp.get('vectors', []): meta = v.get('metadata', {}) or {} pid = meta.get('part_id', '') if not pid: continue sim = 1.0 - v.get('distance', 1.0) # 余弦距离转换为相似度 if pid not in best or sim > best[pid]['score']: best[pid] = {'part_id': pid, 'score': sim} ranked = sorted(best.values(), key=lambda r: r["score"], reverse=True)[:top_k] 由于一个零件对应多个向量（其照片、整页数据表以及每个裁剪出的图表区域），结果在送达模型之前会按零件去重，只保留每个零件得分最高的向量。 在构建检索路径的过程中，我们总结了3条实用经验：在建立索引前裁剪图表——完整的数据表页面并不适合作为索引条目，因为页面约90%的内容（页眉、规格表、页脚）是所有部件共有的模板内容，而这些共有内容会主导嵌入表示。同时为裁剪后的图表区域和完整页面建立索引解决了这个问题。在我们的测试中，使用整页索引时，上传图表的匹配结果在7个部件中有3个正确；使用图表区域裁剪图建立索引后，7个部件全部匹配正确。我们将裁剪区域定义为页面的比例，因此在不同分辨率的数据表上也能保持准确。当工程师指明部件时筛选结果——仅凭跨模态文本到图像相似度，无法可靠地返回正确部件的图表，因为扭矩曲线图中看不到部件名称。当工程师指明某个具体部件时，该工具只保留来自该部件已索引内容的结果，并通过解析每条结果的S3 URI中的部件文件夹来识别该部件。由于筛选在工具中进行，索引无需自定义元数据也能实现这一功能。记录图像路径上的每次回退——图像路径发生错误时返回None，然后回退到文本检索。这种回退是合理的，但也意味着，即使AgentCore运行时执行角色缺少s3vectors:QueryVectors权限，也不会引发错误。以图像作为查询的功能会在没有警告的情况下停止工作，而模型随后会以表面上很高的置信度说出错误的部件。开发期间很容易漏掉这个问题，因为本地开发者凭证通常比运行时角色拥有更广泛的权限。现在，只要该路径发生回退，工具就会记录明确的“S3 Vectors image query FAILED”警告，其中包含存储桶、索引和区域。应检测并记录检索路径中的每一次静默回退，因为明确的故障比悄无声息的故障更容易诊断。通过固定的专家链生成正式文档。聊天功能采用动态路由，因为无法预先知道自由形式问题需要哪些专家。集成影响评估则采用不同方式。当工程师要求评估一对参考部件和候选部件的影响时，所需流程已确定，因此服务会按固定顺序组合相同的专家工厂函数，并使用专门设计的综合提示词。# 1. 知识专家——提取两个部件的ICD/数据表接口细节 knowledge_text = str(knowledge(knowledge_prompt)) # 2. 评估专家——生成结构化字段差异并检查资质要求 evaluation_text = str(evaluation(evaluation_prompt)) # 用确定性方法计算结构化差异，以获得精确的汇总统计 comparison = compare_parts(reference_id, candidate_id) # 3. 监督专家——综合生成包含6个部分的IIA文档 markdown = str(supervisor(synthesis_prompt)) 最终文档涵盖接口变更、机械集成、电气集成、热集成、资质差异和供应链影响。叙述性部分需要由LLM综合生成，因为引脚分配和协议细节必须从ICD的文字描述中提取。汇总统计数据（匹配项、差异项、字段总数）直接根据compare_parts的输出计算，因此与叙述内容并列显示的数字是准确的。通过AgentCore Gateway中的实时网络数据核实生命周期相关说法。目录数据会过时，因此知识专家的web_search_eol工具通过带有Web Search连接器的AgentCore Gateway，查询当前的停产通知、供应商公告和交货周期。Gateway将该连接器作为受治理的模型上下文协议（MCP）端点提供。由于Gateway还负责托管式知识库检索，您可以在同一处为外部和内部数据访问附加策略和可观测性。部署到AgentCore运行时。在生产环境中，您将代理打包为ARM64容器，推送到Amazon Elastic Container Registry（Amazon ECR），再由AgentCore运行时以无服务器方式托管，并提供会话隔离和自动扩缩容。 GitHub 仓库中的笔记本 03 以参考操作流程的形式介绍这一部署过程，涵盖 Dockerfile、构建和推送命令、执行角色权限以及 Cedar 策略。该笔记本展示这些步骤，但不会执行。其 Dockerfile 打包了超出示例范围的应用程序代码，因此请在构建前根据自己的应用程序目录结构进行调整。下图展示了从智能体代码到托管 AgentCore 运行时端点的部署路径。图 4：从智能体代码到托管 AgentCore 运行时端点的部署路径 export TAG=mei-$(date +%Y%m%d-%H%M%S) export ACCOUNT=<your-account-id> export ECR=${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com/mfg-engineering-intelligence # 为 ARM64 构建容器（AgentCore Runtime 要求） docker buildx build --platform linux/arm64 -f agentcore/Dockerfile \\ -t mfg-engineering-intelligence:${TAG} --load . # 将不可变标签推送到 Amazon ECR aws ecr get-login-password --region us-east-1 \\ | docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com docker tag mfg-engineering-intelligence:${TAG} ${ECR}:${TAG} docker push ${ECR}:${TAG} 为每个镜像指定不可变标签。如果运行时已经解析了可变的 :latest 标签所对应的摘要，那么即使推送了新镜像，它仍会继续提供旧镜像。提示词、路由器和工具的变更都需要新镜像和新的运行时版本才能生效。对于以图像作为查询的路径，运行时角色需要 bedrock:InvokeModel、bedrock:Retrieve、bedrock-agentcore:InvokeGateway 和 s3vectors:QueryVectors 权限。笔记本 03 中展示的 Cedar 策略编码了人工参与审核规则：生成备忘录之前必须先进行评估，每项替代决策都必须写入审计日志。目前，应用程序在自身逻辑中执行这些规则；下一步是将该策略附加到 Cedar 授权引擎。Amazon Nova Multimodal Embeddings 现已在 AWS GovCloud（美国）推出。这对受数据驻留、ITAR 和 FedRAMP 要求约束的航空航天及国防项目很重要，因为这些要求规定了工作负载可以在哪里运行。本文依赖的多模态检索和视觉相似性功能可以在 AWS GovCloud（美国）边界内使用。Amazon Nova Multimodal Embeddings 和 Amazon Bedrock AgentCore 功能的可用性因 AWS 区域而异，因此在规划部署前，请查看“按区域划分的 AWS 服务”。评估助手 我们通过两种方式衡量质量：使用 Amazon Bedrock AgentCore 的一项功能 AgentCore Evaluations 持续进行在线评分，以及针对精选查询集进行离线验证。AgentCore 在线评估 Amazon Bedrock AgentCore Evaluations 自 2026 年 3 月起正式推出，采用以大语言模型作为评判者的技术对智能体跟踪记录评分。它读取 Strands 智能体已经发出的 OpenTelemetry 跟踪记录，因此已配置检测功能的智能体无需更改应用程序即可接受评估。该服务提供两种模式。在线评估持续抽样实时生产会话；按需评估则运行适合纳入持续集成和持续交付（CI/CD）流水线的程序化测试。我们使用在线评估，并将结果发布到 Amazon CloudWatch，供控制面板和告警使用。GitHub 仓库中的笔记本 05 创建在线评估配置，并向已部署的运行时发送测试查询，以生成用于评分的会话。config = eval_client.create_online_config( config_name=CONFIG_NAME, agent_id=RUNTIME_ID, sampling_rate=SAMPLING_RATE, evaluator_list=[ "Builtin.GoalSuccessRate", "Builtin.Correctness", "Builtin.Helpfulness", "Builtin.Faithfulness", "Builtin.ResponseRelevance", "Builtin.ToolSelectionAccuracy", "Builtin.ToolParameterAccuracy", ], auto_create_execution_role=True, enable_on_create=True, ) 该服务内置 13 个评估器，同时支持通过提示词定义或以 AWS Lambda 函数形式托管的自定义评估器。 我们启用了 7 个评估器，涵盖全部 3 个评分层级：层级 评估器 评估内容 会话 Goal Success Rate 对话是否从头到尾实现了用户目标？跟踪 Correctness 信息在事实上是否准确？跟踪 Helpfulness 回复是否有用、有价值？跟踪 Faithfulness 回复是否忠实于检索到的上下文？跟踪 Response Relevance 回复是否切合用户的实际问题？工具调用 Tool Selection Accuracy 代理是否选对了工具？工具调用 Tool Parameter Accuracy 代理是否正确提取了参数？精心整理的查询集包含 36 条查询，分属 6 类：目录发现（8）、知识和 ICD 检索（8）、多专家链（6）、确定性评估（5）、以文本检索视觉内容（5），以及人类参与决策的安全拒绝（4）；最后一类用于断言代理会拒绝提出建议或给予批准。除安全类查询的预期结果为拒绝外，每条查询都附有预期的目录零件 ID。export AGENTCORE_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-east-1:ACCOUNT:runtime/YOUR_RUNTIME jupyter lab 05_evaluation.ipynb 结果 AgentCore 持续对实时会话采样，因此每个评估器的分数都是动态汇总值，会随流量累积和代理变化而变动。以下数字是合成数据集运行结果的一个快照。可将其作为设置 CloudWatch 告警阈值的基线，并预期您自己的运行结果会有所不同。层级 评估器 分数（30 天平均值）会话 Goal Success Rate 0.892 跟踪 Correctness 0.968 跟踪 Helpfulness 0.956 跟踪 Faithfulness 0.981 跟踪 Response Relevance 0.968 工具调用 Tool Selection Accuracy 0.861 工具调用 Tool Parameter Accuracy 0.980 所有跟踪层级的质量指标得分均达到或超过 0.95，工具参数提取的得分为 0.980，接近完美。两次评估运行之间最显著的改进是 Tool Selection Accuracy，从 0.809 提高到 0.861。这一提升由 3 项变更推动：整合为单个托管知识库、修复图像作为查询输入的路径上缺失的权限（此前这一问题导致系统悄然回退到文本搜索），以及收紧规划器的路由逻辑，避免串联不必要的专家。Goal Success Rate 较低，为 0.892，这是查询集的设计所致。查询集包含安全类提示，要求代理建议或批准替代方案。代理正确地予以拒绝，但评估器将正确的拒绝计为目标未达成。我们预期会出现这一结果，因为在人类参与决策的系统中，代理不能自行批准替代方案。将这一模式应用于您自己的目录 这套代码是一种可复用的模式，除反作用轮外，也适用于其他零件类别。切换领域需要进行 3 项更改：替换零件数据（每个零件的 specs.json、描述、ICD、数据表页面和照片），编辑需求模式以定义该类别的关键规格和公差规则，并将知识库指向您的 S3 语料库。代理、工具和评分引擎均可保持不变。由于 mei_core 中的确定性工具是普通 Python 函数，PLM 或 ERP 集成可以直接调用 score_substitution_fit，无需代理参与。清理 为避免持续产生费用，请删除您创建的资源：删除 AgentCore 运行时代理及其 Amazon ECR 存储库。删除 AgentCore Gateway 及其 Web Search 和知识库目标。删除在线评估配置和您创建的 CloudWatch 告警。删除托管知识库和 S3 Vectors 索引。删除存放零件语料库的 S3 存储桶。结论 在本文中，我们展示了如何构建多代理工程助手，以自动汇集证据取代人工开展的零件替代研究。 该架构将 Amazon Nova Multimodal Embeddings 与 Amazon Bedrock AgentCore 相结合：前者负责纯文本系统无法处理的视觉相似度评分和图表检索，后者提供运行时托管、由 Gateway 管控的检索和网络搜索，以及质量评估等生产环境基础设施。其中，3 项设计选择最为重要。每一项通过或不通过的判定都由确定性代码作出；每项任务都交给能够胜任它的 3 个模型层级中最小的一个；只有工程师可以批准替代方案。要开始使用，请克隆 GitHub 代码库，使用您自己的 AWS 账户运行笔记本，并接入您自己的零部件目录和需求模式。要深入了解检索基础，请阅读《Manufacturing intelligence with Amazon Nova Multimodal Embeddings》和《A practical guide to Amazon Nova Multimodal Embeddings》。有关生产环境中的智能体模式，请参阅 Amazon Bedrock AgentCore 文档和 Strands Agents SDK。关于作者 Aishwarya Gavili Aishwarya 是 Amazon Web Services（AWS）的解决方案架构师，为从太空初创企业到大型企业的商业航空航天和卫星客户提供支持，帮助他们设计和部署关键任务云解决方案。她专注于面向制造和工程工作流程的检索增强生成管道及多模态智能体系统，帮助受监管行业的客户将新兴 AI 能力转化为实用、可投入生产的解决方案。Adewale Akinfaderin Adewale 是 AWS 的科学技术负责人，领导 Amazon Bedrock 和 1P Models GTM 团队的应用科学与评估工作。他关于基础模型、智能体检索和神经符号 AI 的研究发表于 COLM、EMNLP 和 TACL，以及 NeurIPS、ICLR、ACL、KDD 和 AAAI 的研讨会。他还帮助全球客户设计和大规模部署生成式 AI 解决方案。他拥有 2 个物理学研究生学位和 1 个工程学博士学位。