From data to decisions: Conversational supply chain intelligence with Amazon Quick and Amazon Bedrock AgentCore

从数据到决策：使用 Amazon Quick 和 Amazon Bedrock AgentCore 的对话式供应链智能 | 人工智能

从数据到决策：使用 Amazon Quick 和 Amazon Bedrock AgentCore 的对话式供应链智能

为供应链团队提供直接访问其决策背后系统的通道。

每个供应链都会持续产生信号：待审批的订单、变动的交货周期、放缓的港口、波动的价格、中断事件。问题不在于数据稀缺，而在于数据与决策者之间的距离。

过去回答“哪些高收入 SKU 受到当前港口关闭的影响，这会带来什么成本？”意味着需要知道每个数据片段存储在哪个系统中，并在领域专家等待的同时手动拼接这些信息。这位经理能否改用自然语言提问，并在几秒钟内获得跨系统的可操作答案？Amazon Bedrock AgentCore 是智能层，将企业模型上下文协议（Model Context Protocol，MCP）服务器作为可组合的工具层暴露出来。Amazon Quick 则为无需任何设置的用户角色将这一能力转化为实际操作。答案来自实时的主系统和基于文档的记录，而非模型记忆，每次变更都需要指定的人类确认。在本文中，我们将从 Amazon Quick 的对话式操作流程到其背后的 AgentCore 工具层，完整演示这一模式，并展示如何自行部署。

问题：数据丰富但洞察不足

图 1：领域专业知识由用户掌握，而运营数据则分散在 ERP、监控、采购和电子邮件中

每个问题都需要单独的工具：库存来自企业资源计划（ERP）系统，中断信息来自电子邮件或新闻，采购请求（RFQ）来自采购系统，合规性来自检查表。相关性分析需要手动操作。

一天的生活

传统上，经理的早晨需要在 ERP（库存异常）、监控工具（警报）、采购（替代方案）、电子邮件（RFQ）和跟踪器之间切换：在五个系统中花费 45 至 60 分钟，进行十余次上下文切换。

通过对话，只需在同一工具中输入三个提示：“是否有影响我高收入 SKU 的重大中断？”→ “评估 TechComp 停产并向已批准的替代方案发出紧急 RFQ” → “看起来不错。发送它。”，几分钟内即可完成。

图 2：传统多工具流程与由 AgentCore 协调的单一对话流程对比

深度解析：供应链场景演示

以下五个步骤演示了从检测到批准的紧急 RFQ 的整个过程，全部在一次 Amazon Quick 对话中完成。

步骤 1：发现 – “我有哪些工具？”

用户询问“我有哪些供应链工具？”，Amazon Quick 会列出在 AWS Agent 注册表中发布的供应链 MCP 服务器。由于管理员已启用注册表集成，四个业务 MCP 服务器已作为连接器卡片显示，连接信息已预填充，无需手动输入 URL。编排代理作为其自身的 MCP 连接器添加。

步骤 2：查询 – “显示活跃的中断”

“检查活跃的供应链中断”会调用中断警报 MCP（assess_disruption_impact）：三个中断事件，分别标明严重程度、地区和 SKU 数量。我们的解决方案：Quick 通过 AgentCore 将请求路由到 MCP 服务器，该服务器查询后端监控系统并返回结构化结果，无需仪表板或导出。

步骤 3：深入分析 – “评估关键事件”

用户打开 TechComp 生产暂停功能。assess_disruption_impact(disruption_id="DISR-002") 将订单、客户和库存数据相关联：75万美元面临风险，23个订单，3天的供应量。解决方案：一次 MCP 工具调用会扩散到各个系统，管理者无需接触 ERP 即可获得综合影响分析。

第 4 步：操作 – “获取缓解建议”

用户请求缓解措施。recommend_mitigation(disruption_id="DISR-002") 将治理 MCP（验证已批准的替代方案）和报价 MCP（合同对齐报价）串联成一个流程。解决方案：代理会规划并排序调用，使单次请求跨越中断、治理和报价流程，无需人工交接。

第 5 步：自动化后续跟进

用户随后设置主动监控（“每天早上提醒我是否有新的关键中断”）。相同的流程也可以通过来自供应商的入站电子邮件自动运行。解决方案：相同的代理和工具可通过计划任务或电子邮件触发运行，将待审核的卡片发布到活动流中供人员批准。

从端到端来看，这五个步骤构成一个单一的运行时序列：

图 3：操作流程的运行时序列，所有结果均返回 Amazon Quick 以供批准

解决方案架构

这就是用户体验。以下是实现方式：该模式将智能层与界面层分离，使两者可以独立演进，Amazon Quick 作为界面，AgentCore 作为智能层。

图 4：从 Amazon Quick 到 AgentCore（网关、运行时、身份、策略）再到后端的端到端架构，AWS Agent 注册表并行存在

Amazon Bedrock AgentCore：智能层

Amazon Bedrock AgentCore 是一个模块化智能平台，用于安全地构建、部署和大规模运营代理。它提供的功能远不止于此。其中四个服务与该模式相关：

• 运行时 – 用于 MCP 服务器和代理的无服务器托管，具有会话隔离和内置身份验证。

• 网关 – 将 API、AWS Lambda 函数和服务转换为 MCP 兼容工具，通过安全的托管端点标准化工具访问。推理由调用代理执行。

• 身份 – 认证和凭证管理，兼容现有身份提供商。

• 策略 – 确定性授权规则，以自然语言或 Cedar 编写，会在每次工具调用执行前拦截，确保代理在采购和财务数据处理上保持在指定范围内。

MCP 协议：工具如何通信

MCP 是 AI 模型与外部工具交互的开放标准。每个服务器通过类型化参数暴露工具：

{
  "server_name": "sc-disruption-alert-gateway",
  "tools": [{
    "name": "assess_disruption_impact",
    "parameters": {
      "disruption_id": {"type": "string"},
      "context": {"type": "object"} // 订单、库存、收入数据
    }
  }] // 加上 classify_severity、recommend_mitigation、get_escalation_chain
}

这意味着：

• AI 客户端（Quick、自定义代理、其他 MCP 应用）可以使用相同的服务器。

• 后端（SAP、Oracle、自定义微服务）可以封装为 MCP 服务器。

• 工具发现是自动的。客户端在运行时查询注册表获取模式。

AWS Agent 注册表：发现层

注册中心是受管控的发现层：发布者提交记录，管理员审批后，记录才能通过混合搜索、浏览或注册中心的MCP端点被发现。一个值得关注的规模现实是：由于模式在运行时被发现，应将每个模式视为一份合同，新旧版本并行处理以应对重大变更。

图5：将MCP服务器记录发布到AWS代理注册中心，管理员审批记录，管理员将其链接到Quick，已批准的记录变为连接器卡片

多步骤编排

推理层是AgentCore运行时上的一个代理，通过自定义MCP连接器在直接调用URL处的代理记录，无需Lambda或网关。此处是订单履约代理。给定一个请求，它会规划调用哪些工具以及调用顺序：

用户："一个供应商刚刚宕机了。寻找替代方案，验证合规性，发出紧急询价单。"
中断警报MCP -> 识别中断
治理MCP -> 批准的替代方案 + 合规性 + 预算权限
报价MCP -> 与合同对齐的报价
-> 一个整合后的推荐

安全与治理架构

每个工具调用在到达后端之前都会经过相同的AgentCore控制集。

图6：后端之前的统一AgentCore控制集（IAM认证、按工具授权、输入验证、策略评估、速率限制、数据边界强制、审计日志）

此模式中的MCP服务器

MCP服务器

功能

示例查询

报价引擎

sc-quoting-gateway

报价生成、定价规则、验证

“SKU-A 500件的合同对齐报价”

治理引擎

sc-governance-gateway

供应商审批、预算权限、法规合规、策略规则

“SupplierCo在我们的批准供应商名单上吗？”

发票处理

sc-invoice-gateway

发票审批路由、应付账款账龄、付款计划

“本周有待审批的发票有哪些？”

中断警报

sc-disruption-alert-gateway

活跃中断、严重性、影响评估、缓解措施

“影响我们亚太供应商的关键中断有哪些？”

订单履约代理

sc-order-fulfillment-agent

跨所有四个业务MCP的多步骤编排（AgentCore运行时、直接调用URL）

“一个供应商宕机了，寻找替代方案，检查合规性，发出询价单”

Amazon Quick：企业级AI助手

Amazon Quick通过聊天、代理、活动流和自动化工作流将AgentCore工具前置给业务用户，无需任何技术设置。

使用的关键组件

组件

在此模式中的作用

工作原理

代理注册中心连接

将MCP服务器作为连接器呈现

管理员只需链接一次注册中心。记录变为连接器卡片

Quick代理

一个适应角色的SC代理

根据角色（经理、采购、分析师）进行定制

MCP连接器

在聊天中暴露MCP工具

卡片连接器在聊天、代理、计划中暴露工具

活动流

主动警报和操作

代理发布卡片。用户进行操作

计划

重复的自然语言自动化

例如，“每天早上”

Outlook集成

将电子邮件导入流

解析并验证供应商回复

结构化数据连接器

查询运营记录

Quick查询Space数据集（订单、库存、供应商、合同）进行MCP规则检查

Amazon简单存储服务（Amazon S3）知识库

文档检索

发票、合同、政策存储在S3知识库中，通过检索增强生成（RAG）技术进行答案 grounding

CRM连接器（可选）

读取客户记录（可选）

CRM（如Salesforce）账户、商机、联系人。也可加载到数据集中

自动化活动流与主动监控

活动流是Amazon Quick的主动界面，是一个统一的收件箱，代理人员在此发布结果、警报和建议。活动流条目包括：

• 可操作，每项都包含上下文和下一步操作

• AI分类，带有优先级标识（需回复、需跟进、截止日期）

• 跨来源，涵盖电子邮件、日程、代理执行和外部系统

• 人机协作，代理提出建议由人工最终决定

自动监控的工作原理

AgentCore工具结合Amazon Quick的主动功能，通过通用的触发器→代理→输出管道，提供两种路径：基于时间的路径和基于电子邮件的路径。

图7：从触发器（计划或电子邮件）到自主代理（评估中断影响、检查供应商批准、应用批准规则、验证报价）再到待审卡片的三阶段管道

使用案例：验证供应商的电子邮件回复

供应商通过电子邮件对紧急RFQ进行定价回复。代理验证每个回复（是否为批准供应商？是否符合指南？）并分阶段处理结果。它不会起草报价单、选择中标方或发出采购订单（PO）。

阶段1：设置（一次性，约5分钟）

• 连接Outlook：在Amazon Quick中选择设置 → 连接 → 添加Outlook

• 配置活动流：在活动流偏好设置中开启电子邮件监控

• 创建SC代理：构建一个代理，使用以下指令：

供应链采购助手。当供应商对RFQ进行定价回复时：1) 提取SKU、数量、价格；2) 验证批准供应商（治理MCP）；3) 检查价格是否符合指南（报价MCP）；4) 发布待审卡片（批准供应商、符合指南）；不要起草采购订单或选择供应商

• 创建计划：“工作时间每2小时检查一次新供应商回复并进行验证”

阶段2：运行时（全自动）

计划 -> 来自"TechSupply Co"的电子邮件（MCU-7200，10,000件 @ $2.45/件） -> 治理MCP：是否批准？ | 报价MCP：是否符合指南？ -> "供应商回复 - 准备审核"卡片

卡片携带验证结果和决策相关事实：

供应商回复：准备审核

详情

供应商

TechSupply Co，✅ 已批准供应商

SKU / 数量 / 价格

MCU-7200 · 10,000件 · $2.45/件

价格检查

✅ 符合采购指南

操作

选择生成PO · 对比回复 · 拒绝

阶段3：人工参与环节

审核人员比较验证后的回复，选择供应商并发出PO，或记录原因拒绝。选择和PO生成由人工完成。

使用案例：主动中断监控

计划触发的相同模式适用：每天上午8:30的代理检查新出现的重大或高严重性中断，评估影响，将供应周期少于7天的标记为URGENT，并发布带有"发起紧急RFQ"操作的警报卡片。

与传统BI的结合位置

维度

传统商业智能（BI）/仪表板

AgentCore + Amazon Quick

访问模式

导航、登录、找到仪表板/报告

自然语言提问。系统自动定位数据源

洞察时间

分钟到小时（查找 → 过滤 → 导出 → 关联）

秒（提问 → 基于跨系统上下文回答）

多系统关联

手动操作：3-4 个标签页，复制粘贴

自动操作：代理跨 MCP 服务器协调处理一个查询

行动差距

在一个工具中获得洞察 → 切换 → 在另一个工具中采取行动

在同一对话中实现洞察 → 行动

设置成本

数周/数月（仪表板设计、ETL、权限、培训）

一旦 MCP 服务器就绪，只需几分钟即可连接

运行成本

固定成本：无论是否有人提问，管道成本保持不变

按使用量计费：无服务器架构可扩展至零，成本与问题数量挂钩（Lambda + 代理令牌）

信任与准确性

与最后一次 ETL 加载一样新鲜

实时从主系统和有据可查的文档中计算，每次写入均由人工审核

这不是一个“全面替代”的论点。仪表板在趋势可视化、协作分析、监管报告和探索性分析方面仍然更胜一筹。使用对话式 AI 进行实时运营决策，使用 BI 进行战略分析。它们是互补关系，而非竞争关系。

角色与使用场景

一个 Quick Agent 可服务于所有三个角色：经理确保连续性，采购部门在合规意识下进行采购，分析师进行信号关联。通过行/列级安全性和按角色划分的 MCP 工具范围限制访问权限，因此采购部门无法查看财务数据。

角色 | 使用场景 | 调用工具 | 结果 ---|---|---|--- SC Manager | 早间中断检查 | 中断警报 MCP | 中断情况、面临的风险收入、供应天数 | 紧急采购 | 治理 → 报价 MCP | 已验证的替代方案 + 询价单，一站式流程 采购 | 供应商验证、预算权限 | 治理 MCP | 审批、合规性、限制 | 询价单生成和响应验证 | 报价 MCP | 发布询价单 + 验证响应 运营分析师 | 跨系统关联 | SC 运营代理 | 多 MCP 推理，一次查询 | 支付队列、审计、中断趋势 | 发票 / 治理 MCP | 应付账款账龄、审计日志、模式

入门指南

部署该模式分为三个阶段：部署基础设施、将 Amazon Quick 连接到您的数据和注册中心，然后启用监控。

先决条件

开始之前：

• 包含 Amazon Bedrock AgentCore 和 AWS Agent Registry 的 AWS 账户。

• AWS 命令行界面（AWS CLI）v2、AWS 无服务器应用程序模型（AWS SAM）CLI 和 Docker（代理作为 arm64 容器运行）。

• Python 3.12 或更高版本，注册步骤需要 Boto3 1.43.94 或更高版本。

• 具有 AWS 身份和访问管理（IAM）权限的活动凭证，用于部署和注册（aws sts get-caller-identity 返回目标账户）。

• 数据层：数据库（Snowflake、PostgreSQL/RDS 或 SQLAlchemy 引擎）、Amazon S3 存储桶，可选 Salesforce 组织。

• 为您的组织设置的 Amazon Quick。

• （可选）用于电子邮件自动化的 Outlook 账户。

设置涉及两个界面，因此以下每个步骤都会标明发生位置：浏览器中的 Amazon Quick Web 控制台（Amazon Quick Sight 权限、Agent Registry 链接、连接器和代理设置）以及 Quick 桌面应用（连接 Outlook 以实现电子邮件自动化）。桌面应用中的对话体验在设置完成后最后启用。

部署基础设施

所有内容均为开源且脚本化：克隆 aws-samples/sample-amazon-quick-suite-knowledge-hub 仓库中的 quick-for-supply-chain 示例并遵循其 README.md，或使用 Kiro 等编码代理指向它。

README.md 包含三个阶段。阶段1部署AgentCore堆栈：身份层（Amazon Cognito用户池和应用客户端、授权码OAuth流程、测试用户），四个业务规则MCP服务器（每个服务器均为由AgentCore网关（Amazon Bedrock AgentCore功能）托管的AWS Lambda函数，使用CUSTOM_JWT授权），网关将每个Lambda函数的工具进行映射，以及以最小权限IAM角色在AgentCore运行时中作为容器部署的sc-order-fulfillment-agent。阶段2将合成数据集上传至Amazon S3。阶段3验证网关和运行时是否就绪。六个Agent注册表记录已获批准。

图8：AWS Agent注册表控制台显示六个已批准记录（四个MCP服务器、一个代理、一个技能）

授予Amazon Quick访问数据的权限

在Amazon Quick网页控制台（浏览器）中：从Amazon Quick Sight管理页面（管理Quick Sight → 安全与权限）向S3存储桶和Amazon Athena同时授予Amazon Quick访问权限，因为每个表均通过AWS Glue数据库上的Athena源提供。若未授予Athena权限，数据集创建将失败。

图9：Amazon Quick Sight安全与权限设置，显示Amazon Athena与Amazon S3并列

链接注册表并创建连接器

注册表链接为一次性且管理员级别操作。创建连接器为按用户操作。两者均在Amazon Quick控制台中完成。参见AWS Agent注册表集成指南。

#### 链接注册表（管理员，一次性操作）

管理员将一个Agent注册表链接到Quick账户。在Amazon Quick网页控制台（管理员）中：进入管理账户 → 权限 → AWS Agent注册表并启用注册表（sc-supply-chain-registry，每个账户仅一个）。仅显示您账户和区域内的注册表、agent-registry命名空间、AWS_IAM（SigV4）授权且状态为READY的注册表。Quick管理的服务角色将完成链接。

图10：链接注册表时，仅可选择状态为READY且使用AWS_IAM的注册表

#### 创建连接器

注册表链接完成后，已批准的MCP服务器记录将变为连接器卡片：四个业务MCP作为卡片，订单履约代理需手动添加。在大规模部署时，可通过身份提供商进行连接器认证的联合，并通过Cognito用户池作为连接点将连接器分配至用户组。

在Amazon Quick网页控制台（按用户）中：四个卡片将显示在连接器页面（sc-quoting-mcp、sc-governance-mcp、sc-invoice-processing-mcp、sc-disruption-alert-mcp）。通过OAuth授权码流程（OAUTH2_AUTHORIZATION_CODE）进行认证，使用部署脚本中的客户端ID、密钥、令牌、授权和重定向URL。以测试用户身份登录，启用工具，创建并共享。

图11：四个业务-MCP连接器卡片，订单履约代理需手动添加

基于注册表的连接器为自定义MCP连接器（适用于自定义权限）。后续移除链接不会删除已创建的连接器。

图12：使用授权码OAuth流程（OAUTH2_AUTHORIZATION_CODE）的认证步骤

#### 添加订单履约代理连接器

在Amazon Quick网页控制台中：由于这是一个代理记录，需手动创建其连接器（连接器 → 为您的团队创建 → 模型上下文协议 → 创建新连接器）：命名为sc-order-fulfillment-agent，指向部署脚本中的AgentCore运行时直接调用URL，完成相同的OAuth登录，创建并共享。

图13：创建sc-order-fulfillment-agent连接器，指向AgentCore运行时调用URL

将连接器附加到您的代理

部署过程会创建供应链代理：一个快速空间、导入的数据集和S3知识库，以及包含指令、启动提示和欢迎信息的代理。剩余需要完成的是附加连接器。

在Amazon Quick网页控制台（代理设置）中：打开部署创建的供应链代理（默认ID为sc-supply-chain-agent），并附加所有五个连接器（四个业务MCP加上sc-order-fulfillment-agent），或向设置脚本传递这五个连接器ID。

设置主动监控

为了实现主动监控，Quick会按照计划或在收到电子邮件时运行相同的代理，并将结果发布到活动流中。两种方式都会复用您配置的代理和工具。

在Quick桌面应用（设置→连接）中：连接Outlook并开启电子邮件监控。然后在Quick Chat中创建两个自然语言计划，基于时间的计划（"每天早晨检查新的重大中断"）和基于电子邮件的计划（"工作时间每两小时检查供应商回复并验证"）。代理会提取价格信息、执行检查，并发布卡片。

在Amazon Quick中试用

当代理和连接器准备就绪后，在Amazon Quick Chat中用自然语言提问。每个提示都会展示数据-规则模式。

向Amazon Quick提问

您将获得

“我有哪些供应链工具？”

五个MCP连接器（报价、治理、发票、中断警报、订单履约代理），附带状态信息。

“显示活跃的供应链中断。”

活跃中断信息，包含严重程度、地区、SKU数量（来自中断警报MCP）。

“评估TechComp生产停滞的影响。”

来自您的数据集的潜在收入损失、受影响订单、供应天数。

“这家供应商是经过批准的厂商吗？我们是否有72,000美元采购订单的预算权限？”

来自治理MCP的批准信息（供应商状态、预算权限、合规性）。

“为该客户生成一份符合合同的1,000件产品报价。”

来自报价MCP的符合合同的报价，作为品牌文档。

“一家供应商刚刚停摆。寻找替代方案，验证合规性，并发出紧急RFQ。”

订单履约代理将中断、治理和报价MCP串联成一个推荐方案。

结论

AgentCore和Amazon Quick构成了可重复的企业级AI模式：将智能与界面分离。AgentCore通过标准MCP接口将碎片化的后端转化为可组合、受管控、可被AI访问的分层架构。Amazon Quick通过自然语言使访问民主化。

收益体现在决策链的压缩：过去需要五种工具完成检测、研究、决策、执行和日志记录，现在只需一次对话。AI负责研究、关联和验证，人类负责决策。每次调用都会经过身份验证、授权、策略检查和审计，原本需要45-60分钟跨五个系统的操作现在可以压缩到几分钟内完成。

这标志着从数据丰富但洞察匮乏到数据丰富且决策就绪的转变。从一个MCP服务器和一个角色开始，注册表会不断扩展，但用户体验始终保持一致。

作者简介

'" /think