[Amazon Bedrock] 用 Amazon Nova Multimodal Embeddings 与 Amazon Bedrock AgentCo…

2026-11-04 · 转自：aws.amazon.com

人工智能用 Amazon Nova Multimodal Embeddings 与 Amazon Bedrock AgentCore 打造 Agentic 工程智能当一个已通过

转载本文转自「aws.amazon.com」，版权归原作者所有，内容已摘录正文、去除外部链接。

人工智能

用 Amazon Nova Multimodal Embeddings 与 Amazon Bedrock AgentCore 打造 Agentic 工程智能

当一个已通过认证的航天器件停产或交付周期拉长时，工程师往往要花上几天时间，在厂商数据手册、接口控制文档（ICD）和认证记录之间交叉核对规格，之后才能把替代论证整理成文档供评审。飞行关键部件上的一次错误替代可能导致任务失败，而每个决策背后的证据链却常常散落在邮件和从未成文的组织知识里，评审人员因此拿不到一份正式、可复现的材料包。

此前的一篇博文 Manufacturing intelligence with Amazon Nova Multimodal Embeddings 展示了模型如何检索出那些锁在工程图纸、热分布图和数据手册图表里、纯文本流水线会漏掉的答案。本文沿着那条检索工作的路线继续往前走，把这些能力装进一个多 agent 系统，由它来组装替代论证的证据——从检索一直到起草评估。

在这篇文章里，我们展示如何用 Amazon Bedrock AgentCore、Amazon Nova Multimodal Embeddings 和开源的 Strands Agents SDK 构建一个多 agent 工程助手，砍掉部件替代评估背后的人工交叉核对。一个 planner 把任务分派给三个 specialist agent：它们检索多模态知识库、按确定性容差规则给候选打分、比对部件照片，并用实时 web 数据支撑生命周期相关的论断。工程师自始至终都是决策者，因为系统只组装证据、起草文档，从不自行批准任何替代。

方案总览

整个助手围绕一条设计规则搭建：所有决策由工程师做出，系统负责为这些决策组装证据。这条规则决定了我们在哪些地方使用大语言模型（LLM），又在哪些地方改用确定性代码。

架构由三大支柱构成：

确定性的规格适配评估 —— 用 Python 编写的容差规则代码，把每个候选部件与参照部件、工程师提出的要求逐项打分。同样的输入总能产出同样的通过/标记判定，结果因此可以进入正式工程评审。多 agent 编排 —— 一个轻量的 planner 把每条查询路由给三个 specialist agent（Catalog、Evaluation、Knowledge）中的一个或几个，只有当多个 specialist 都参与时，supervisor 才会综合它们的结论。诸如「查一下这个飞轮是不是快停产了，找出替代品并打分」这类复杂问题，会把三个 specialist 依次串起来。人在环路（human-in-the-loop）决策 —— 系统会为工程评审起草论证备忘录和集成影响评估（Integration Impact Assessment），但不推荐、也不批准任何替代方案。每次评估还会写入一条与 AS9100 第 8.4 节和 8.5.6 节对齐的审计记录。

下图展示了整体架构。

图 1：基于 Amazon Bedrock AgentCore 的多 agent 工程助手架构

Amazon Bedrock AgentCore 是一个用任意框架、任意模型大规模构建、连接和优化 agent 的平台。在这套方案里，来自工程师应用的聊天请求会流入托管在 AgentCore runtime 上的一个多 agent 图：planner（Claude Haiku 5.5）产出路由计划，specialist（Claude Sonnet 5.5）执行各自的工具，当有多个 specialist 运行时，supervisor（Claude Opus 5.5）综合它们的结果。specialist 从一个托管知识库中检索——该知识库是我们用 Amazon Bedrock Managed Knowledge Bases、以 Amazon Nova Multimodal Embeddings 创建的，检索经由 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）路由，与获取实时 web 数据的 Web Search 连接器同走这一入口。对于 image-as-query（上传一张图表来识别部件），agent 会直接调用原生的 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 做 embedding，让文本与视觉内容共享同一个语义空间。工程师可以输入「0.06 Nms 飞轮的扭矩曲线」，也可以上传一张图表图片，检索都会返回匹配的图示并附上来源出处。视觉相似度打分 —— 比较两个候选部件时，Nova Multimodal Embeddings 会给出两者照片之间的量化余弦相似度，再由 Claude 分析具体的物理差异（安装孔位布局、连接器位置、外壳几何）。这个分数为确定性的规格比对补充佐证，而适配结论始终以规格比对为准。

前置条件

要跟着做，你需要：

一个 AWS 账号，且可在美国东部（弗吉尼亚北部）AWS Region 访问 Amazon Bedrock。在 Amazon Bedrock 中开通 Amazon Nova Multimodal Embeddings、Claude Haiku 5.5、Claude Sonnet 5.5 和 Claude Opus 5.5 的模型访问权限。各 Region 的模型可用性见 Amazon Bedrock 中按 AWS Region 的模型支持。一个用 Amazon Bedrock Managed Knowledge Bases 创建的托管知识库，以 Amazon Nova Multimodal Embeddings 覆盖你的部件语料（数据手册、ICD、描述文本），用于文本和文档检索。一个覆盖部件照片和数据手册图表裁剪区的 Amazon S3 Vectors 索引，供 image-as-query 路径使用。一个 Amazon Bedrock AgentCore Gateway，配好 Web Search 连接器和一个托管知识库 target。 Python 3.10 或更高版本，以及用于运行 notebook 的 Jupyter。如果你要把 notebook 03 里的部署配方改造为把 agent 托管到 AgentCore runtime，还需要 Docker。 GitHub 仓库里的示例代码。

方案详解

下面的小节按一条查询实际经过的顺序介绍系统的各个部分。我们先讲部件语料和 specialist agent，再依次覆盖路由、确定性打分、助手使用 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 和文件名会在不同数据集之间重复使用，每个 specialist 的 prompt 都把 get_part_specs 返回的结构化 vendor 值当作权威来源，并且禁止从 ID、文件名、照片或 web 搜索结果去猜制造商。让制造商信息取自结构化数据，可以避免助手因为模型自认为认得这块硬件，而把部件安到错误的供应商头上。

每个部件文件夹还带着两份纯文本索引用不上的资产：产品照片供视觉相似度打分使用；渲染出的数据手册页面带着扭矩框图和扭矩曲线图，能回答 OCR 文本层根本抓不到的性能问题。Amazon Nova Multimodal Embeddings 把这两类资产与文本 embed 进同一个向量空间，于是一条查询既能命中规格数值，也能命中一段文字或一张图。

下面的示例展示语料中的四页数据手册，其动量存储横跨三个数量级。

图 2：部件语料中的四页数据手册，动量存储横跨三个数量级

整个产品系列的模板是统一的，但产品照片和那一对性能图每个部件都不同。这些区域展示了外壳几何、安装孔位布局、扭矩包络和功耗——规格字段并不会直接写明这些，所以我们把它们与文本一起 embed。

用限定范围的工具定义 specialist

每个 specialist 都是一个 Strands agent，prompt 范围很窄，只带自己需要的工具。按 specialist 限定工具能让行为可预期：Knowledge specialist 摸不到目录发现类工具，Catalog specialist 也碰不到评估类工具。下面的代码创建 Evaluation specialist。

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 如何把查询路由给各个 specialist，以及 supervisor 何时综合它们的结果。图后的列表说明每个 specialist 的职责。

图 3：planner 如何把查询路由给 specialist，以及 supervisor 何时综合结果

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 里的问题，核实实时的停产（end-of-life）状态，并检索视觉内容（get_part_specs、web_search_eol、retrieve_visual_content）。

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

路由是一个不做工具调用的分类任务，不需要大的推理模型。基于 Haiku 的 planner 几秒钟就能返回一份编号的路由计划。Opus supervisor 只在两个以上 specialist 参与时才运行，因为对单个 specialist 已经完整的回答再做一次综合，只会多花大约 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。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.", }

specialist 负责呈现这张表格、解释各个被标记项，但它改不了任何判定。审计记录也遵循同样的分工：每次评估结束后，由编排层读取 specialist 的工具调用历史并亲自写入审计条目，日志因此不依赖模型「记得」去做。

用 Amazon Nova Multimodal Embeddings 给视觉相似度打分

当替代品必须装到既有支架上时，外形尺寸就很关键。visual_similarity_score 工具用 Nova Multimodal Embeddings 对两张部件照片做 embedding 并计算余弦相似度，然后让 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)))

embedding 相似度是确定性、可复现的：同一产品系列里的两个飞轮大约返回 0.84，不同档次的飞轮则约 0.40。随后 Claude 的视觉分析会解释差异从何而来，比如指出其中一个外壳的直径约为另一个的两倍，且采用六孔安装布局，而另一个是四孔。

用两条检索路径找回图表与图示

文本和文档类查询走由 Amazon Nova Multimodal Embeddings 支撑、经 AgentCore Gateway 路由的托管知识库。image-as-query（上传图表或照片来找匹配内容）则用原生 Amazon S3 Vectors 索引，由 agent 直接调用，因为托管知识库的检索 API 不接受图片输入。

Knowledge specialist 的 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 以 IMAGE_RETRIEVAL 用途 embed 成 1,024 维向量，再去 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% 的内容（页眉、规格表、页脚）是所有部件共享的样板，这部分共享内容会主导 embedding。把裁剪出的图表区域与整页一起索引解决了这个问题。在我们的测试中，图表上传匹配从整页索引时的 7 中 3 对，提升为图表条带裁剪后的 7 中 7 对。裁剪区域按页面占比定义，因此在不同分辨率的数据手册上都能保持正确。工程师点名部件时过滤结果 —— 单靠跨模态的文本到图片相似度，没法稳定返回正确部件的图表，因为一张扭矩曲线图里看不到部件名称。当工程师指名某个部件时，工具只保留来自该部件索引内容的结果——它通过解析每条结果 S3 URI 里的部件文件夹来识别归属。由于过滤在工具内部完成，索引里不需要任何自定义元数据。图片路径上的每次回退都要记日志 —— 图片路径出错时返回 None，然后回落到文本检索。这个回退本身合理，但它意味着：如果 AgentCore runtime 的执行角色缺了 s3vectors:QueryVectors 权限，也不会报任何错。image-as-query 会在毫无预警的情况下失效，模型接着会表现得非常有把握地说出一个错误的部件。这种问题在开发阶段很容易被漏掉，因为本地开发者凭证的权限通常比 runtime 角色宽得多。现在每当这条路径发生回退，工具都会记录一条明确的 S3 Vectors image query FAILED 警告，附上 bucket、索引和 Region。检索路径上的每一处静默回退都要埋点打日志，因为硬失败远比无声的失败好诊断。

用固定的 specialist 链路产出正式文档

聊天走动态路由，因为开放式问题需要哪些 specialist 无法预先知道。集成影响评估则不然：当工程师为某个参照件与候选件的组合请求影响评估时，所需的顺序是已知的，于是服务把同一批 specialist 工厂函数按固定顺序组装起来，配上专门定制的 synthesis prompt。

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 数据支撑生命周期论断

目录数据会过时，所以 Knowledge specialist 的 web_search_eol 工具会通过带 Web Search 连接器的 AgentCore Gateway，去核对当前的停产公告、厂商动态和交付周期。Gateway 把该连接器以一个受治理的 Model Context Protocol（MCP）端点的形式暴露出来。由于托管知识库的检索也走 Gateway，你可以在同一个地方为外部和内部的数据访问统一挂上策略与可观测性。

部署到 AgentCore runtime

上生产时，你把 agent 打包成 ARM64 容器，推到 Amazon Elastic Container Registry（Amazon ECR），AgentCore runtime 便以 serverless 方式托管它，并自带会话隔离与自动扩缩容。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= 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}

给每个镜像打一个不可变的 tag。一个已经解析过浮动 :latest tag 背后 digest 的 runtime，在你推送新镜像之后仍会继续用旧镜像服务。prompt、路由器和工具的改动，都要靠新镜像加新 runtime 版本才能生效。

runtime 角色需要 bedrock:InvokeModel、bedrock:Retrieve、bedrock-agentcore:InvokeGateway，以及供 image-as-query 路径使用的 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 Region 而异，规划部署前请先查阅按 Region 划分的 AWS 服务。

评估这个助手

我们用两种方式衡量质量：通过 AgentCore Evaluations（Amazon Bedrock AgentCore 的一项能力）做持续在线打分，以及对着精选查询集做离线验证。

AgentCore 在线评估

Amazon Bedrock AgentCore Evaluations自 2026 年 3 月起正式可用，用 LLM-as-a-judge 技术给 agent trace 打分。它读取 Strands agent 本来就在发出的 OpenTelemetry trace，所以已完成埋点的 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 个评估器，同时支持自定义评估器——可以用一段 prompt 定义，也可以托管成 AWS Lambda 函数。我们启用了其中 7 个，覆盖全部三个打分层级：

层级评估器打分内容会话Goal Success Rate整场对话是否端到端达成了用户的目标？ TraceCorrectness信息在事实层面是否准确？ TraceHelpfulness回答是否有用、有价值？ TraceFaithfulness回答是否忠实于检索到的上下文？ TraceResponse Relevance回答是否针对用户的实际查询？工具调用Tool Selection Accuracyagent 是否选对了工具？工具调用Tool Parameter Accuracyagent 是否正确提取了参数？

精选查询集收录 36 条查询，分六类：目录发现（8）、Knowledge 与 ICD 检索（8）、多 specialist 链路（6）、确定性评估（5）、文本到视觉检索（5），以及 human-in-the-loop 安全拒绝（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 告警阈值的基线，但你自己跑出来的数字理应不同。

层级评估器分数（30 天均值）会话Goal Success Rate0.892 TraceCorrectness0.968 TraceHelpfulness0.956 TraceFaithfulness0.981 TraceResponse Relevance0.968 工具调用Tool Selection Accuracy0.861 工具调用Tool Parameter Accuracy0.980

trace 层的各项质量指标全部在 0.95 及以上，工具参数提取近乎完美，达到 0.980。两次评估运行之间最显眼的提升是 Tool Selection Accuracy，从 0.809 升到 0.861。有三项改动带来了这个提升：合并为单一托管知识库；修复 image-as-query 路径上一个缺失的权限——此前它导致无声回退到文本搜索；收紧 planner 的路由，避免串上不必要的 specialist。

Goal Success Rate 偏低，只有 0.892，这是查询集的设计使然。查询集里包含安全类的 prompt，会让 agent 去推荐或批准某个替代方案。agent 正确地拒绝了，但评估器会把一次正确的拒绝打分为目标未达成。这个结果在我们预料之中，因为在 human-in-the-loop 系统里，agent 本就不该自行批准替代。

把这套模式适配到你自己的目录

这套代码是可复用的模式，除反作用飞轮外也适用于其他部件类别。换领域只需要三处改动：替换部件数据（每个部件一份 specs.json、描述文本、ICD、数据手册页和照片）；编辑 requirements schema，定义你的类别的关键规格与容差规则；把知识库指向你自己的 S3 语料。agent、工具和打分引擎原样沿用。由于 mei_core 里的确定性工具就是普通 Python 函数，PLM 或 ERP 集成可以直接调用 score_substitution_fit，链路里不需要任何 agent。

清理

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

删除 AgentCore runtime agent 及其 Amazon ECR 仓库。删除 AgentCore Gateway 及它的 Web Search 与知识库 target。删除在线评估配置和你创建的 CloudWatch 告警。删除托管知识库和 S3 Vectors 索引。删除存放部件语料的 S3 bucket。

总结

在这篇文章里，我们展示了如何构建一个多 agent 工程助手，用自动化的证据组装取代人工的部件替代研究。这套架构把 Amazon Nova Multimodal Embeddings 与 Amazon Bedrock AgentCore 搭配起来：前者负责纯文本系统做不到的视觉相似度打分和图表检索，后者提供 runtime 托管、由 Gateway 治理的检索与 web 搜索、质量评估这些生产级底座。三个设计选择最为要紧：每一条通过/不通过的判定都由确定性代码产出；每个任务都落在三档模型里能把它做好的最小一档；只有工程师可以批准替代。

上手方式是：克隆 GitHub 仓库，用自己的 AWS 账号跑这些 notebook，换上你自己的部件目录和 requirements schema。想深入检索的地基部分，可以读 Manufacturing intelligence with Amazon Nova Multimodal Embeddings 和 A practical guide to Amazon Nova Multimodal Embeddings。要了解生产级 agent 模式，见 Amazon Bedrock AgentCore 文档和 Strands Agents SDK。

关于作者

← 返回教程列表