用 Amazon Nova Multimodal Embeddings 与 Bedrock…

人工智能

基于 Amazon Nova Multimodal Embeddings 与 Amazon 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 节对齐的审计跟踪记录。

下图展示了该架构。

Architecture of the multi-agent assistant: a planner routes engineer queries across Catalog, Evaluation, and Knowledge specialists, with a supervisor synthesizing results

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

Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，支持任意框架或模型。在此解决方案中，来自工程师应用程序的聊天请求会流入托管在 AgentCore 运行时上的多智能体图：规划器（Claude Haiku 5.5）生成路由计划，专家（Claude Sonnet 5.5）执行各自的工具，而当有多个专家运行时，监督者（Claude Opus 5.5）会综合它们的结果。专家会从我们使用以下内容创建的一个托管知识库中进行检索： Amazon Bedrock 托管知识库，使用 Amazon Nova Multimodal Embeddings，并通过 Amazon Bedrock AgentCore 的一项能力 AgentCore Gateway 进行路由，同时配合 Web Search 连接器获取实时网络数据。对于以图像作为查询（上传图表以识别零件）的情况，智能体会直接调用原生 Amazon S3 Vectors 索引，因为托管知识库检索 API 不接受图像输入。Amazon S3 Vectors 是 Amazon Simple Storage Service（Amazon S3）的一项能力。一条单独的固定链（Knowledge、Evaluation、Supervisor）会生成正式的集成影响评估（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 托管知识库创建的托管知识库，针对你的零件语料库（数据表、ICD、描述）使用 Amazon Nova Multimodal Embeddings 进行文本和文档检索。
针对你的零件照片和数据表图表裁剪图建立的 Amazon S3 Vectors 索引，用于以图像作为查询的路径。
一个带有 Web Search 连接器和托管知识库目标的 Amazon Bedrock AgentCore Gateway。
Python 3.10 或更高版本以及 Jupyter，用于运行笔记本。
Docker，前提是你调整 notebook 03 中的部署方案，将智能体托管在 AgentCore runtime 上。
示例代码来自 GitHub 仓库.

解决方案演练

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

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

构建零件语料库

示例数据集包含来自一家虚构制造商（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"
  }
}

该字段对每个零件都有明确说明。由于目录文件夹 ID 和文件名在不同数据集之间会被重复使用，每个专家提示都将由返回的结构化值视为权威依据，并禁止根据 ID、文件名、照片或网络搜索结果来猜测制造商。从结构化数据中获取制造商信息，可以避免助手因为模型自认为认出了硬件而将零件归属到错误的供应商。每个零件文件夹还包含两个作为 vendor 字段对每个零件都有明确说明。由于目录文件夹 ID 和文件名在不同数据集之间会被重复使用，每个专家提示都将由返回的结构化值视为权威依据，并禁止根据 ID、文件名、照片或网络搜索结果来猜测制造商。从结构化数据中获取制造商信息，可以避免助手因为模型自认为认出了硬件而将零件归属到错误的供应商。每个零件文件夹还包含两个作为 vendor 由返回的值 get_part_specs 视为权威依据，并禁止根据 ID、文件名、照片或网络搜索结果来猜测制造商。从结构化数据中获取制造商信息，可以避免助手因为模型自认为认出了硬件而将零件归属到错误的供应商。

每个零件文件夹还包含两项纯文本索引无法利用的资产。产品照片用于视觉相似度评分，而渲染后的数据表页面则包含力矩框图和力矩曲线图，能够回答任何 OCR 文本层都无法捕捉的性能问题。Amazon Nova Multimodal Embeddings 将这两者与文本嵌入到同一向量空间中，因此查询可以匹配规格值、段落或图表。

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

Four reaction-wheel datasheet pages side by side, each with a product photo and performance plots, across a range of momentum storage

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

该模板在整个产品系列中重复使用，但产品照片和两张性能图会随每个零件而变化。这些区域展示了外壳几何形状、安装模式、扭矩包络和功耗，而规格字段并未直接说明这些内容，因此我们将它们与文本一起嵌入。

为专家智能体定义限定范围的工具

每个专家都是一个 Strands 智能体，拥有范围狭窄的提示词以及它所需的工具。为每个专家限定工具范围可以保持行为可预测，因为 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",
    )

下图展示了 planner 如何将查询路由给各专家智能体，以及 supervisor 何时汇总它们的结果。其后的列表描述了每个专家智能体的职责。

Flow diagram of the planner routing a query to specialists and the supervisor synthesizing results when more than one specialist runs

图3：planner 如何将查询路由给专家智能体，以及 supervisor 何时汇总结果

目录 – 通过知识库搜索和详尽的规格筛选来发现零件（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 的 planner 会在几秒内返回一个带编号的路由计划。只有当两个或更多专家智能体参与贡献时，Opus supervisor 才会运行，因为对单个专家已经完整的答案进行综合会额外增加约 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 代码的形式，针对手写的需求模式（requirements schema）运行。该模式为每个组件类别定义了关键规格和容差规则，并且 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 时出错并回退到文本检索。这种回退是合理的，但这意味着一旦缺少 s3vectors:QueryVectors AgentCore 运行时执行角色上的权限不会引发错误。图像作为查询会毫无预警地失效，随后模型会以看似很高的置信度说出错误的零件。这个问题在开发过程中很容易被忽略，因为本地开发人员的凭证通常比运行时角色拥有更广泛的权限。该工具现在会记录一条明确的 S3 Vectors image query FAILED 该工具现在会记录一条明确的警告，包含 bucket、index 和 Region，以便在该路径发生回退时进行追踪。在检索路径中为每一处静默回退添加监测，因为硬性失败比悄无声息的失败更容易诊断。

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

Chat 之所以采用动态路由，是因为对于自由形式的问题，无法预先知道哪些专家最合适。集成影响评估的工作方式则不同。当工程师针对一个参考件与候选件对请求影响评估时，所需的执行顺序已经确定，因此该服务会按固定顺序组合相同的专家工厂函数，并使用专门构建的综合提示词。

# 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 用实时网络数据核实生命周期声明

目录数据会过时，因此 Knowledge 专家的 web_search_eol 该工具通过带有 Web Search 连接器的 AgentCore Gateway 检查当前的终止支持通知、供应商公告和交付周期。Gateway 将该连接器作为受治理的 Model Context Protocol (MCP) 端点对外提供。由于 Gateway 还负责托管式知识库检索，你可以在同一处为外部和内部数据访问附加策略与可观测性。

部署到 AgentCore 运行时

在生产环境中，你需要将智能体打包为 ARM64 容器，推送到 Amazon Elastic Container Registry (Amazon ECR)，然后由 AgentCore 运行时以无服务器方式托管它，并具备会话隔离和自动扩缩容能力。GitHub 仓库中的 Notebook 03 以参考方案的形式完整演示了这一部署流程，涵盖 Dockerfile、构建与推送命令、执行角色权限以及 Cedar 策略。该 notebook 仅展示这些步骤，并不实际运行它们。其 Dockerfile 打包的应用代码超出了示例范围，因此在构建之前，请根据你自己的应用布局进行调整。下图展示了从智能体代码到托管的 AgentCore 运行时端点的部署路径。

Deployment path: agent code packaged as an ARM64 container, pushed to Amazon ECR, running on a hosted AgentCore runtime endpoint

图 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（美国）区域推出这一点对于受数据驻留、ITAR 和 FedRAMP 要求约束的航空航天与国防项目至关重要，因为这些要求规定了工作负载可以在何处运行。本文所依赖的多模态检索和视觉相似性能力均可在 AWS GovCloud (US) 边界内访问。Amazon Nova Multimodal Embeddings 和 Amazon Bedrock AgentCore 功能的可用性因 AWS 区域而异，因此请查看各区域的 AWS 服务，然后再规划部署。

评估助手

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

AgentCore 在线评估

Amazon Bedrock AgentCore 评估, 自 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 函数形式托管的自定义评估器。我们启用了其中七个，覆盖全部三个评分层级：

层级	评估器	它评分的内容
会话	目标达成率	对话是否端到端地实现了用户的目标？
追踪	正确性	信息在事实上准确吗？
追踪	有用性	该回复是否有用且有价值？
追踪	忠实性	回复是否忠实于检索到的上下文？
追踪	回复相关性	该回复是否针对用户的实际查询？
工具调用	工具选择准确率	智能体是否选择了正确的工具？
工具调用	工具参数准确率	智能体是否正确提取了参数？

该精选查询集包含六大类共 36 条查询：目录发现（8 条）、Knowledge 与 ICD 检索（8 条）、多专家链（6 条）、确定性评估（5 条）、文本到视觉检索（5 条），以及人在回路安全拒绝（4 条），后者断言智能体拒绝推荐或批准。除安全类查询外，每条查询都带有其预期的目录零件 ID；对于安全类查询，预期结果是拒绝。包含六大类共 36 条查询：目录发现（8 条）、Knowledge 与 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
追踪	正确性	0.968
追踪	有用性	0.956
追踪	忠实性	0.981
追踪	回复相关性	0.968
工具调用	工具选择准确率	0.861
工具调用	工具参数准确率	0.980

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

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

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

该代码是一个可复用的模式，适用于除反作用轮之外的其他零件类别。切换领域需要做三处改动：替换零件数据（每个零件包含 specs.json、描述、ICD、数据表页面和照片），编辑需求模式以定义你所在类别的关键规格和容差规则，并将知识库指向你的 S3 语料库。智能体、工具和评分引擎保持不变。由于 mei_core 都是普通的 Python 函数，PLM 或 ERP 集成可以直接调用 score_substitution_fit 直接调用，无需在流程中引入智能体。

清理

为避免持续产生费用，请删除你创建的资源：

删除 AgentCore 运行时智能体及其 Amazon ECR 存储库.
删除 AgentCore Gateway 及其 Web Search 和知识库目标。 AgentCore Gateway 及其 Web Search 和知识库目标。.
删除在线评估配置以及 CloudWatch 告警你创建的资源：
删除托管知识库以及 S3 Vectors 索引.
删除存放零件语料库的 S3 存储桶。 S3 存储桶存放零件语料库的 S3 存储桶。

结论

在这篇文章中，我们展示了如何构建一个多智能体工程助手，用自动化证据组装取代人工的零件替代研究。该架构将 Amazon Nova Multimodal Embeddings 与 Amazon Bedrock AgentCore 配对使用：前者负责纯文本系统无法实现的视觉相似度评分和图表检索，后者提供运行时托管、由 Gateway 管控的检索与网络搜索以及质量评估等生产级支撑。三项设计选择最为关键：每一项通过/不通过的判定都由确定性代码生成；每项任务都运行在能够胜任该任务的最小模型层级上；并且只有工程师才能批准替代方案。

首先，克隆 GitHub 仓库，使用你自己的 AWS 账户运行这些笔记本，并替换为你自己的零件目录和需求模式。要深入了解检索基础，请阅读用 Amazon Nova Multimodal Embeddings 实现制造智能以及 Amazon Nova 多模态嵌入实用指南关于生产环境的智能体模式，请参阅 Amazon Bedrock AgentCore 文档以及 Strands Agents SDK.