用 Amazon Nova Multimodal Embeddings 与 Bedrock AgentCore 构建智能体工程智能助手

当合格的航空航天部件停产或面临较长交货周期时，工程师需要花费数天时间，在供应商数据表、接口控制文档（ICD）和鉴定记录之间交叉核对规格，然后才能编写替代理由说明以供审查。飞行关键部件上的错误替代可能导致任务失败，而每个决策背后的证据链往往分散在电子邮件和未记录的机构知识中，因此审查者没有正式、可重复的审查材料包。

此前的一篇博文使用 Amazon Nova Multimodal Embeddings 实现制造智能展示了该模型如何检索锁定在工程图、热图和数据表图表中、纯文本流水线会遗漏的答案。本文接续该检索工作，将这些能力置于一个多智能体系统中，从检索到起草评估，组装替代证据。

在本文中，我们展示如何构建一个多智能体工程助手，利用 Amazon Bedrock AgentCore、Amazon Nova Multimodal Embeddings 和开源 Strands Agents SDK，减少部件替代评估背后的人工交叉核对工作。规划器将工作路由到三个专家智能体，它们搜索多模态知识库、依据确定性公差规则对候选部件评分、比较部件照片，并将生命周期声明建立在实时网络数据之上。工程师始终是决策者，因为系统只组装证据并起草文档，从不自行批准替代。

解决方案概述

该助手围绕一条设计规则构建：工程师做出每一个决策，系统为其组装证据。这条规则决定了我们在何处使用大语言模型（LLM），以及在何处改用确定性代码。

三大支柱定义了该架构：

确定性规格匹配评估 – 用 Python 编写的公差规则代码，依据参考部件和工程师陈述的要求对每个候选部件评分。由于相同的输入始终产生相同的通过/标记判定，结果可以进入正式工程审查。
多智能体编排 – 一个轻量级规划器将每个查询路由到三个专家智能体（Catalog、Evaluation、Knowledge）中的一个或多个，仅当多个专家参与时，才由监督者综合其发现。诸如“检查该轮是否即将停产、寻找替代品并对其评分”之类的复杂问题会按顺序串联全部三个专家。
人在回路决策 – 系统起草理由备忘录和集成影响评估以供工程审查，但不推荐或批准替代。每次评估还会写入一条符合 AS9100 第 8.4 和 8.5.6 节的审计跟踪记录。

下图展示了该架构。

图 1：Amazon Bedrock AgentCore 上多智能体工程助手的架构

Amazon Bedrock AgentCore 是一个平台，可用于使用任意框架或模型大规模构建、连接和优化智能体。在此解决方案中，来自工程师应用程序的聊天请求会流入托管在 AgentCore 运行时上的多智能体图：规划器（Claude Haiku 5.5）生成路由计划，专家智能体（Claude Sonnet 5.5）执行各自的工具，当有多个专家智能体运行时，由监督器（Claude Opus 5.5）综合它们的结果。专家智能体从我们使用 Amazon Bedrock Managed Knowledge Bases 创建、采用 Amazon Nova Multimodal Embeddings 的托管知识库中检索，并通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）以及用于获取实时网络数据的 Web Search 连接器进行路由。对于以图像为查询（上传图表以识别零件）的情况，智能体直接调用原生 Amazon S3 Vectors 索引，因为托管知识库检索 API 不接受图像输入。Amazon S3 Vectors 是 Amazon Simple Storage Service（Amazon S3）的一项能力。一个独立的固定链（Knowledge、Evaluation、Supervisor）生成正式的 Integration Impact Assessment（IIA）文档。

Amazon Nova Multimodal Embeddings 以两种不同的角色出现：

多模态检索 – 数据表、ICD 和性能图表使用 Nova Multimodal Embeddings 进行嵌入，使文本和视觉内容共享同一个语义空间。工程师可以输入“0.06 Nms 车轮的扭矩曲线”或上传图表图像，检索会返回匹配的图表并附带来源归属。
视觉相似度评分 – 当比较两个候选零件时，Nova Multimodal Embeddings 会生成它们照片之间的定量余弦相似度，Claude 则分析具体的物理差异（安装模式、连接器位置、外壳几何形状）。该分数为确定性的规格比较提供佐证，而适配结论正是基于该比较得出的。

先决条件

要继续操作，您需要：

一个 AWS 账户，并可在美国东部（弗吉尼亚北部）AWS 区域访问 Amazon Bedrock。
在 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 创建的托管知识库，针对您的零件语料库（数据表、ICD、描述）使用 Amazon Nova Multimodal Embeddings 进行文本和文档检索。
针对您的零件照片和数据表图表裁剪图建立的 Amazon S3 Vectors 索引，用于以图像为查询的路径。
一个带有 Web Search 连接器和托管知识库目标的 Amazon Bedrock AgentCore Gateway。
Python 3.10 或更高版本以及用于运行笔记本的 Jupyter。
Docker，如果您要调整笔记本 03 中的部署配方以在 AgentCore 运行时上托管智能体。
来自 GitHub 仓库的示例代码。

解决方案演练

以下各节按查询使用系统的顺序描述系统的各个部分。我们先从零件语料库和专家智能体开始，然后介绍路由、确定性评分、助手使用 Nova Multimodal Embeddings 的两种方式、生成正式文档的固定链，以及部署到 AgentCore 运行时。

完整代码示例是 GitHub 仓库中的五个 Jupyter notebook，每个 notebook 均可独立运行。这些 notebook 从 mei_core 导入，该文件是同一文件夹中 agent 和工具模块的自包含副本，并且它们包含各自的部件数据、图表裁剪和评估查询集。你可以在 notebook 中运行本文的每个代码片段，无需其他应用代码。

构建部件语料库

示例数据集是来自虚构制造商（AnyCompany）的七个反作用轮，动量存储范围从 0.003 到 5.0 Nms。每个部件是一个文件夹，将结构化数据与工程师实际阅读的源文档配对，这种组合使语料库成为多模态。specs.json 文件保存驱动确定性评分的机器可读字段，而 ICD、产品照片和渲染的数据表页面则承载结构化字段所遗漏的视觉和叙述细节。

data/synthetic-parts-data/rw_rl_0060/
├── specs.json # structured specs + lifecycle fields
├── description.txt # flat text for text retrieval
├── AC-ICD-00068-RW3-0.06-Interface-Control-Document-v2.2.pdf
├── datasheet_page.png # rendered datasheet page
├── datasheet_chart.png # cropped chart region (image-as-query index)
└── photo.png # product image (visual similarity + chart matching)

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 将两者嵌入与文本相同的向量空间，因此查询可以匹配规格值、段落或图表。

以下示例展示了语料库中的四个数据表页面，跨越三个数量级的动量存储。

图 2：部件语料库中的四个数据表页面，跨越三个数量级的动量存储

模板在整个系列中重复，但产品照片和一对性能图表随每个部件变化。这些区域展示了外壳几何形状、安装模式、扭矩包络和功耗，这些是规格字段未直接声明的，因此我们将它们与文本一起嵌入。

定义具有限定工具的专家

每个专家都是一个 Strands agent，具有狭窄的提示和仅所需的工具。为每个专家限定工具可保持行为可预测，因为 Knowledge 专家无法访问目录发现工具，而 Catalog 专家无法访问评估工具。以下代码创建 Evaluation 专家。

from strands import Agent

def create_evaluation_specialist() -> Agent:
    """Evaluation Specialist: deterministic spec-by-spec comparison and scoring."""
    return Agent(
        name="evaluation_specialist",
        system_prompt="""You are the Evaluation Specialist. Your job is to run
deterministic, spec-driven comparisons between parts.
...
RULES:
- Your comparisons are deterministic (code, not opinion)
- NEVER recommend or approve --- present evidence and flags; the engineer decides
- Always include the disclaimer that this is evidence only""",
        tools=[score_substitution_fit, compare_parts, visual_similarity_score,
               check_qualification_status, generate_substitution_memo],
        model="us.anthropic.claude-sonnet-5-5",
    )

下图展示了规划器如何将查询路由到专家，以及主管何时综合其结果。其后的列表描述了每个专家的功能。

图 3：规划器如何将查询路由到专家以及主管何时综合结果

Catalog – 通过知识库搜索和详尽的规格过滤（kb_search、filter_parts_by_spec、get_part_specs、get_substitution_requirements）发现部件。
Evaluation – 对候选进行确定性评分并视觉比较部件（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 秒延迟，且没有质量提升。

# Step 1: Planner (fast model) plans the routing (may be multi-step).
plan_response = planner(planning_prompt)
ordered_specialists = _parse_specialist_plan(str(plan_response))

# Step 2: Execute specialists in sequence, passing context forward
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"

# Step 3: Synthesize only when 2+ specialists ran.
if len(ordered_specialists) == 1:
    final_text = steps[0]["response"]
else:
    final_text = str(supervisor(synthesis_prompt))

将工作拆分到三个模型层级，使成本与延迟匹配每个阶段。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,  # per-spec pass/flag/review status
    "counts": counts,
    "out_of_tolerance": out_of_tolerance,
    "lifecycle": {...},  # obsolescence and lead-time flags
    "summary": summary,
    "disclaimer": "Evidence only. This tool does not recommend or approve "
                  "a substitution; the engineer decides.",
}

专家展示此表并解释标记，但不能更改结论。审计追踪遵循同样的分工。每次评估后，编排层读取专家的工具调用历史并自行写入审计条目，因此日志记录不依赖于模型记得去做。

使用 Amazon Nova Multimodal Embeddings 对视觉相似度评分

当替代品必须适配现有支架时，外形尺寸很重要。visual_similarity_score 工具使用 Nova Multimodal Embeddings 嵌入两张零件照片并计算余弦相似度，然后要求 Claude 描述具体的可观察差异。

def embed_image(image_bytes):
    """Embed one image with Nova MME (IMAGE_RETRIEVAL) -> 1024-d vector."""
    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'])

# cosine similarity of the two photo embeddings
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 不接受图像输入。

知识专家的 retrieve_visual_content 工具为两条路径提供单一接口。工程师可以将需求文档中的性能曲线粘贴到聊天中，并询问哪个零件与之匹配，或者改用文本查询描述图表。

# Image-as-query: embed the uploaded image with Nova MME, exactly as the
# datasheet crops and photos were embedded at indexing time.
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 以 1,024 维度和 IMAGE_RETRIEVAL 用途进行嵌入，然后与 S3 Vectors 索引匹配：

# Query the native S3 Vectors index and collapse to the best vector per part.
emb = embed_query_image(image_bytes)
s3v = boto3.client('s3vectors', region_name=REGION)
fetch_k = max(top_k * 6, 12)  # each part has several vectors; dedupe below
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)  # cosine distance -> similarity
    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]

由于一个零件贡献多个向量（其照片、整个数据手册页面以及每个裁剪的图表区域），结果在到达模型之前会按每个零件的最佳评分向量去重。

在构建检索路径时，我们学到了三个实践教训：

在建立索引前裁剪图表 – 整页数据手册页面作为索引条目效果很差，因为一页中大约 90% 的内容（页眉、规格表、页脚）是所有零件共享的样板内容，而这些共享内容会主导嵌入向量。将裁剪后的图表区域与整页一起建立索引解决了这个问题。在我们的测试中，图表上传匹配在整页索引时 7 个零件中只有 3 个正确，而使用图表带状裁剪后达到 7 个全部正确。我们将裁剪区域定义为页面的比例分数，这样在不同分辨率的数据手册上都能保持正确。
当工程师指定零件时过滤结果 – 仅靠跨模态文本到图像的相似度无法可靠地返回正确零件的图表，因为扭矩曲线图像中不包含可见的零件名称。当工程师指定了具体零件时，工具只保留该零件已索引内容中的结果，它通过从每个结果的 S3 URI 中解析零件文件夹来识别。由于过滤在工具内运行，因此无需索引中的自定义元数据即可工作。
记录图像路径上的每一次回退 – 图像路径在出错时返回 None 并回退到文本检索。这种回退是合理的，但这意味着 AgentCore 运行时执行角色上缺少 s3vectors:QueryVectors 权限不会引发错误。图像作为查询的功能会在无警告的情况下停止工作，然后模型会以很高的表面置信度命名错误的零件。这个问题在开发过程中很容易被忽视，因为本地开发者凭证通常比运行时角色拥有更广泛的权限。现在，每当该路径回退时，工具会记录一条明确的 S3 Vectors image query FAILED 警告，包含存储桶、索引和区域。为检索路径中的每一个静默回退添加监测，因为硬失败比静默失败更容易诊断。

使用固定的专家链生成正式文档

聊天使用动态路由，因为无法预先知道自由形式问题需要哪些专家。集成影响评估的工作方式不同。当工程师请求对参考零件和候选零件对进行影响评估时，所需的顺序已经确定，因此服务以固定顺序组合相同的专家工厂函数，并使用专门构建的综合提示。

# 1. Knowledge Specialist --- ICD/datasheet interface detail for both parts
knowledge_text = str(knowledge(knowledge_prompt))

# 2. Evaluation Specialist --- structured field delta + qualification check
evaluation_text = str(evaluation(evaluation_prompt))

# Deterministic structured delta for exact summary stats
comparison = compare_parts(reference_id, candidate_id)

# 3. Supervisor --- synthesize into the six-section IIA document
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 仓库中的 Notebook 03 以参考配方的方式演示了这一部署流程，涵盖 Dockerfile、构建和推送命令、执行角色权限以及 Cedar 策略。该 notebook 仅展示这些步骤，并不实际运行它们。其中的 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

# Build the container for ARM64 (required by AgentCore Runtime)
docker buildx build --platform linux/arm64 -f agentcore/Dockerfile \
  -t mfg-engineering-intelligence:${TAG} --load .

# Push the immutable tag to 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。Notebook 03 中展示的 Cedar 策略编码了人在回路规则，要求在执行备忘录之前先进行评估，并在每次替换决策时记录审计日志条目。目前，应用程序在其自身逻辑中执行这些规则，而将策略附加到 Cedar 授权引擎是下一步工作。

Amazon Nova Multimodal Embeddings 现已在 AWS GovCloud (US) 中可用，这对于受数据驻留、ITAR 和 FedRAMP 要求约束的航空航天与国防项目至关重要，这些要求规定了工作负载可以在何处运行。本文所依赖的多模态检索和视觉相似性能力可在 AWS GovCloud (US) 边界内访问。Amazon Nova Multimodal Embeddings 和 Amazon Bedrock AgentCore 功能的可用性因 AWS 区域而异，因此在规划部署之前，请查看按区域划分的 AWS 服务。

评估助手

我们通过两种方式衡量质量：一是通过 AgentCore Evaluations（Amazon Bedrock AgentCore 的一项能力）进行持续的在线评分，二是针对精选查询集进行离线验证。

AgentCore 在线评估

Amazon Bedrock AgentCore Evaluations 自 2026 年 3 月起正式可用，它使用 LLM-as-a-judge 技术对智能体轨迹进行评分。它会读取 Strands 智能体已经发出的 OpenTelemetry 轨迹，因此经过插桩的智能体无需更改应用程序即可接受评估。该服务提供两种模式。在线评估持续对实时生产会话进行采样，而按需评估则运行适合持续集成和持续交付 (CI/CD) 流水线的程序化测试。

我们使用在线评估，并将结果发布到 Amazon CloudWatch 以用于仪表板和告警。GitHub 仓库中的 Notebook 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,
)

该服务内置了十三个评估器，同时支持由提示词定义或作为 AWS Lambda 函数托管的自定义评估器。我们启用了七个，涵盖所有三个评分级别：

级别	评估器	评分内容
会话	目标成功率	对话是否端到端地实现了用户的目标？
轨迹	正确性	信息是否事实准确？
轨迹	有用性	响应是否有用且有价值？
轨迹	忠实性	响应是否忠实于检索到的上下文？
Trace	响应相关性	响应是否解决了用户的实际查询？
工具调用	工具选择准确性	智能体是否选择了正确的工具？
工具调用	工具参数准确性	智能体是否正确提取了参数？

精选查询集包含六大类共 36 条查询：目录发现（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 天平均值）
会话	目标成功率	0.892
Trace	正确性	0.968
Trace	有用性	0.956
Trace	忠实性	0.981
Trace	响应相关性	0.968
工具调用	工具选择准确性	0.861
工具调用	工具参数准确性	0.980

所有 trace 级质量指标得分均达到或超过 0.95，工具参数提取接近完美，为 0.980。两次评估运行之间最显著的改进是工具选择准确性，从 0.809 升至 0.861。三项变更推动了这一提升：整合为单一托管知识库、修复图像作为查询路径上缺失的权限（该问题曾导致静默回退到文本搜索），以及收紧规划器的路由以避免串联不必要的专家。

目标成功率较低，为 0.892，这是由查询集的设计方式决定的。查询集包含安全类提示，要求智能体推荐或批准替换。智能体正确拒绝了，但评估者将正确拒绝计为未达成目标。我们预期这一结果，因为在人在回路系统中，智能体不得自行批准替换。

将该模式适配到你自己的目录

该代码是一种可复用模式，适用于除反作用轮之外的其他零件类别。切换领域需要三项更改：替换零件数据（每个零件一个 specs.json、描述、ICD、数据表页面和照片），编辑需求 schema 以定义你所在类别的关键规格和容差规则，并将知识库指向你的 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 管理的检索与网络搜索以及质量评估等生产级支撑。三项设计选择最为关键：每个通过/不通过的判定都由确定性代码生成；每项任务都运行在三种模型层级中能够胜任该任务的最小层级上；只有工程师才能批准替换。

要开始使用，请克隆 GitHub 仓库，使用你自己的 AWS 账户运行这些 notebook，并替换为你自己的零件目录和需求 schema。要深入了解检索基础，请阅读 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 解决方案。他拥有两个物理学研究生学位和一个工程学博士学位。