用 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 节对齐的审计跟踪条目。

下图展示了该架构。

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

Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，支持任意框架或模型。在该解决方案中，来自工程师应用程序的聊天请求流入托管在 AgentCore runtime 上的多智能体图：规划器（Claude Haiku 5.5）生成路由计划，专家智能体（Claude Sonnet 5.5）执行各自的工具，当有多个专家智能体运行时，由监督者（Claude Opus 5.5）综合它们的结果。专家智能体从我们使用 Amazon Nova Multimodal Embeddings 通过 Amazon Bedrock Managed Knowledge Bases 创建的管理知识库中检索，并经 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 以两种不同的角色出现：

1. 多模态检索 – 数据手册、ICD 和性能图表使用 Nova Multimodal Embeddings 进行嵌入，使文本和视觉内容共享同一个语义空间。工程师可以输入“0.06 Nms 轮子的扭矩曲线”或上传图表图像，检索会返回匹配的图表并附带来源归属。
2. 视觉相似度评分 – 当比较两个候选零件时，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 或更高版本，以及用于运行 notebook 的 Jupyter。
• Docker，如果你要调整 notebook 03 中的部署配方，将智能体托管在 AgentCore runtime 上。
• 来自 GitHub 仓库 的示例代码。

解决方案演练

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

完整代码示例是 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）。
• Knowledge – 回答来自数据手册和 ICD 的问题，检查实时停产状态，并检索视觉内容（get_part_specs、web_search_eol、retrieve_visual_content）。

用小型模型做路由，用大型模型做综合

路由是一项不调用工具的 classification 任务，因此不需要大型推理模型。基于 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 代码，针对手写需求 schema 运行。该 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 路由。以图像为查询（上传图表或照片以查找匹配内容）使用直接从 agent 调用的原生 Amazon S3 Vectors 索引，因为托管知识库检索 API 不接受图像输入。

Knowledge 专家的 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 将生命周期声明建立在实时网络数据之上

目录数据会过时，因此 Knowledge 专家的 web_search_eol 工具通过带有 Web Search 连接器的 AgentCore Gateway 检查当前的停产通知、供应商公告和交货时间。Gateway 将该连接器暴露为受治理的模型上下文协议（MCP）端点。由于 Gateway 还处理托管知识库检索，你可以在一个地方为外部和内部数据访问附加策略和可观测性。

部署到 AgentCore 运行时

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

图 4：从 agent 代码到托管 AgentCore runtime 端点的部署路径

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}

为每个镜像分配一个不可变标签。如果某个 runtime 已经解析了某个会变动的 :latest 标签背后的摘要，那么在你推送新镜像后，它仍会继续提供旧镜像。提示词、路由器和工具的变更都需要新镜像和新 runtime 版本才能生效。

对于 image-as-query 路径，runtime 角色需要 bedrock:InvokeModel、bedrock:Retrieve、bedrock-agentcore:InvokeGateway 和 s3vectors:QueryVectors。Notebook 03 中展示的 Cedar 策略编码了 human-in-the-loop 规则，要求在生成备忘录之前先进行评估，并在每次替换决策时记录审计日志条目。目前，应用程序在自己的逻辑中执行这些规则，而将策略附加到 Cedar 授权引擎是下一步工作。

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

评估助手

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

AgentCore 在线评估

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

我们使用在线评估，并将结果发布到 Amazon CloudWatch 以用于仪表板和告警。GitHub 仓库中的 Notebook 05 创建了一个在线评估配置，并向已部署的 runtime 发送测试查询，以生成用于评分的会话。

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

精选查询集包含六大类共 36 条查询：目录发现（8 条）、知识与 ICD 检索（8 条）、多专家链（6 条）、确定性评估（5 条）、文本到视觉检索（5 条），以及人在回路安全拒绝（4 条），用于验证 Agent 拒绝推荐或批准。除安全类查询外，每条查询都带有预期的目录零件 ID；安全类查询的预期结果是拒绝。

export AGENTCORE_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-east-1:ACCOUNT:runtime/YOUR_RUNTIME
jupyter lab 05_evaluation.ipynb

结果

AgentCore 会持续对实时会话进行采样，因此每位评估器的分数都是动态聚合值，会随着流量累积和 Agent 变更而波动。以下数字是合成数据集运行的一次快照。请将它们作为设置 CloudWatch 告警阈值的基线，并预期你自己运行得到的数字会有所不同。

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

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

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

该代码是一种可复用模式，适用于反应轮之外的其它零件类别。切换领域需要三项变更：替换零件数据（每个零件包含一个 specs.json、描述、ICD、数据表页面和照片），编辑需求 schema 以定义你所在类别的关键规格和公差规则，并将知识库指向你的 S3 语料库。Agent、工具和评分引擎无需改动即可沿用。由于 mei_core 中的确定性工具是普通 Python 函数，PLM 或 ERP 集成可以直接调用 score_substitution_fit，无需在回路中引入 Agent。

清理

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

1. 删除 AgentCore 运行时 Agent 及其 Amazon ECR 仓库。
2. 删除 AgentCore Gateway 及其 Web Search 和知识库目标。
3. 删除 在线评估配置 以及你创建的 CloudWatch 告警。
4. 删除 托管知识库 和 S3 Vectors 索引。
5. 删除存放零件语料库的 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 解决方案。他拥有两个物理学研究生学位和一个工程学博士学位。