从数据到决策：用 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）、监控、采购和电子邮件中

每个问题都需要自己的工具：库存来自企业资源计划（enterprise resource planning, ERP）系统，中断来自电子邮件或新闻，询价单（request for quotation, RFQ）来自采购，合规来自检查清单。关联是手工的。

一天的工作

经理的早晨传统上横跨 ERP（库存异常）、监控工具（告警）、采购（替代方案）、电子邮件（RFQ）和一个跟踪表：45–60 分钟，五个系统，十几次以上的上下文切换。

改成对话，则是同一工具里的三条提示：“有没有影响我高收入 SKU 的严重中断？”→“评估 TechComp 停产，并向已批准的替代供应商发出紧急 RFQ”→“可以。发出去。”，几分钟内完成。

图 2：传统多工具流程，对比由 AgentCore 编排的单一对话线程

深入：供应链场景演练

下面五步在一次 Amazon Quick 对话中，把一次中断从发现走到一份已批准的紧急 RFQ。

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

用户问“我有哪些供应链工具？”，Amazon Quick 列出发布在 AWS Agent Registry 中的供应链 MCP 服务器。因为管理员已经打开注册表集成，四个业务 MCP 服务器已经显示为连接器卡片，连接细节已预填，无需手工输入 URL。编排智能体作为它自己的 MCP 连接器加入。

步骤 2：查询——“给我看进行中的中断”

“检查进行中的供应中断”调用中断告警 MCP（assess_disruption_impact）：三条中断，带有严重程度、区域和 SKU 计数。我们如何解决：Quick 经 AgentCore 把请求路由到 MCP 服务器，后者查询后端监控并返回结构化结果，没有仪表盘，也没有导出。

步骤 3：下钻——“评估最严重的那一条”

用户打开 TechComp 停产。assess_disruption_impact(disruption_id="DISR-002") 关联订单、客户和库存数据：75 万美元处于风险中，23 笔订单，三天供应量。我们如何解决：一次 MCP 工具调用扇出到多个记录系统，因此经理不必接触 ERP 就能得到合并后的影响读数。

步骤 4：行动——“给出缓解建议”

用户要求缓解措施。recommend_mitigation(disruption_id="DISR-002") 串联治理 MCP（核验已批准的替代方案）和报价 MCP（与合同一致的报价），一次请求完成一条流程。我们如何解决：智能体规划并排列这些调用的顺序，因此一次提问就横跨中断、治理和报价，没有手工交接。

步骤 5：自动跟进

用户随后设置主动监控（“如果有新的严重中断，每天早上提醒我”）。同一流程也可以从一封入站供应商邮件无人值守地运行。我们如何解决：同一智能体和工具按日程或邮件触发运行，把可供审阅的卡片发到活动信息流，由人批准。

端到端看，这五步是一条运行时序列：

图 3：演练的运行时序列，每一个结果都回到 Amazon Quick 供批准

方案架构

那是体验。下面是它如何构建：该模式把智能层与界面层分开，使二者可以独立演进，Amazon Quick 作为界面，AgentCore 作为智能。

图 4：从 Amazon Quick 到 AgentCore（网关、运行时、身份、策略）再到后端的端到端架构，旁边是 AWS Agent Registry

Amazon Bedrock AgentCore：智能层

Amazon Bedrock AgentCore 是一个模块化的智能体平台，用于安全地大规模构建、部署和运行智能体。它提供的比我们这里用到的更多。其中四项服务与本模式相关：

• 运行时（Runtime）——MCP 服务器和智能体的无服务器托管，带会话隔离和内建身份。

• 网关（Gateway）——把 API、AWS Lambda 函数和服务变成安全托管端点后面、与 MCP 兼容的工具，从而标准化工具访问。推理属于发起调用的智能体。

• 身份（Identity）——身份验证和凭据管理，与现有身份提供者兼容。

• 策略（Policy）——确定性授权规则，用自然语言或 Cedar 编写，在执行前拦截每一次工具调用，使智能体在采购和财务数据上保持在自己的范围内。

MCP 协议：工具如何通信

MCP 是人工智能模型与外部工具交互方式的开放标准。每个服务器暴露带类型参数的工具：

{
  "server_name": "sc-disruption-alert-gateway",
  "tools": [{
    "name": "assess_disruption_impact",
    "parameters": {
      "disruption_id": {"type": "string"},
      "context": {"type": "object"} // order, inventory, revenue data
    }
  }] // plus classify_severity, recommend_mitigation, get_escalation_chain
}

这意味着：

• 人工智能客户端（Quick、定制智能体、其他 MCP 应用）可以消费同一批服务器。

• 后端（SAP、Oracle、定制微服务）可以被包装成 MCP 服务器。

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

AWS Agent Registry：发现层

注册表是受治理的发现层：发布者提交一条记录，策展人批准它，然后它才可通过混合搜索、浏览或注册表的 MCP 端点被发现。有一个规模上的事实值得注意：因为模式在运行时被发现，应把每一份模式当作一份契约，对破坏性变更采用新旧并存的版本管理。

图 5：把 MCP 服务器记录发布到 AWS Agent Registry，策展人批准，管理员把它链接到 Quick，已批准记录变成连接器卡片

多步编排

推理层是 AgentCore Runtime 上的一个智能体，通过自定义 MCP 连接器以其直接调用 URL 上的一条智能体记录存在，没有 Lambda，也没有网关。这里它是订单履行智能体（Order Fulfillment Agent）。给定一次请求，它规划调用哪些工具以及以什么顺序调用：

User: "A supplier just went down. Find alternatives, verify compliance, issue an emergency RFQ."
Disruption Alerts MCP -> identify the disruption
Governance MCP -> approved alternatives + compliance + budget authority
Quoting MCP -> contract-aligned quote
-> one consolidated recommendation

安全与治理架构

每一次工具调用在到达后端之前，都经过同一套 AgentCore 控制。

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

本模式中的 MCP 服务器

Amazon Quick：企业人工智能助手

Amazon Quick 通过聊天、智能体、活动信息流和自动化工作流，把 AgentCore 工具放到业务用户面前，无需技术配置。

使用的关键组件

自动化活动信息流与主动监控

活动信息流（Activity Feed）是 Amazon Quick 的主动界面，一个统一收件箱，智能体在其中发布结果、告警和建议。信息流条目是：

• 可执行的，每一条都带有上下文和下一步动作。

• 由人工智能分拣的，带有优先级指示（需要回复、跟进、截止）。

• 跨来源的，横跨电子邮件、日程、智能体运行和外部系统。

• 人在回路中，智能体提议，人做决定。

自动监控如何工作

AgentCore 工具加上 Amazon Quick 的主动能力，给出两条路径，基于时间和由电子邮件驱动，经过共同的触发 → 智能体 → 输出流水线。

图 7：三阶段流水线，从触发（日程或电子邮件）到自主智能体（assess_disruption_impact、check_supplier_approval、apply_approval_rules、validate_quote），再到可供审阅的卡片

用例：从电子邮件校验供应商回复

供应商通过电子邮件回复紧急 RFQ，并附上价格。智能体逐条校验（是已批准供应商吗？在指引范围内吗？）并暂存结果。它不撰写报价、不挑选中标者、也不签发采购订单（purchase order, PO）。

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

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

• 配置活动信息流：在信息流偏好中打开电子邮件监控。

• 创建供应链智能体：用这些指示构建一个智能体：

Supply chain procurement assistant. On a supplier RFQ reply with pricing: 1) extract SKU(s), quantities, pricing; 2) validate approved vendor (Governance MCP); 3) check pricing within guidelines (Quoting MCP); 4) post a review-ready card (approved-supplier, within-guidelines); do NOT draft a PO or select a supplier.

• 创建日程：“在工作时间每 2 小时检查一次新的供应商回复并校验它们。”

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

Schedule -> email from "TechSupply Co" (MCU-7200, 10,000 units @ $2.45/unit) -> Governance MCP: approved? | Quoting MCP: within guidelines? -> "Supplier Response - Ready for Review" card

信息流卡片带有校验结果和与决策相关的事实：

阶段 3：人在回路中

审阅者比较已校验的回复，要么选择一家供应商并签发采购订单，要么拒绝并记录原因。选择和采购订单留在人这里。

用例：主动的中断监控

由日程触发时，同一模式适用：每天上午 8:30 的智能体检查新的严重或高严重程度中断，评估影响，把供应量不足七天的任何事项标为 URGENT，并发布一张带有“发出紧急 RFQ”动作的告警卡片。

它与传统商业智能并排放在哪里

这不是“替换一切”的论点。仪表盘在趋势可视化、协作分析、监管报告和探索性分析上仍然更好。对话式人工智能用于实时运营决策，商业智能用于战略分析。它们互补，而不是竞争。

角色与用例

一个 Quick Agent 服务全部三个角色：经理保持连续性，采购在具备合规意识的情况下寻源，分析师关联信号。角色也限制可达范围，通过行/列级安全以及按角色限定 MCP 工具，使采购看不到财务数据。

开始使用

部署该模式分三个阶段：供应基础设施，把 Amazon Quick 连接到你的数据和注册表，然后打开监控。

先决条件

开始之前：

• 一个具备 Amazon Bedrock AgentCore 和 AWS Agent Registry 的 AWS 账户。

• AWS Command Line Interface（AWS CLI）v2、AWS Serverless Application Model（AWS SAM）CLI，以及 Docker（该智能体作为 arm64 容器运行）。

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

• 具备 AWS Identity and Access Management（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 Gateway 前置的 AWS Lambda 函数，AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，使用 CUSTOM_JWT 授权），把每个 Lambda 函数的工具映射起来的网关目标，以及 AgentCore Runtime 上作为容器的 sc-order-fulfillment-agent，并配有最小权限 IAM 角色。阶段 2 把合成数据集上传到 Amazon S3。阶段 3 核验网关和运行时为 Ready。六条 Agent Registry 记录被批准。

图 8：AWS Agent Registry 控制台，六条已批准记录（四个 MCP Server、一个 Agent、一个 Skills）

授予 Amazon Quick 访问你的数据

在 Amazon Quick Web 控制台（浏览器）中： 从 Amazon Quick Sight 管理页（Manage Quick Sight → Security and permissions）授予 Amazon Quick 对 S3 存储桶和 Amazon Athena 的访问，因为每张表都通过 Athena 数据源、建在一个 AWS Glue 数据库之上来提供。没有 Athena 授权，数据集创建会失败。

图 9：Amazon Quick Sight 的安全与权限，Amazon Athena 与 Amazon S3 并列

链接注册表并创建连接器

链接注册表是一次性的、管理员级别的。创建连接器是按用户的。两者都发生在 Amazon Quick 控制台中。见 AWS Agent Registry 集成指南。

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

管理员把一个 Agent Registry 链接到 Quick 账户。在 Amazon Quick Web 控制台（管理员）中： 进入 Manage account → Permissions → AWS Agent Registry，并打开注册表（sc-supply-chain-registry，每个账户一个）。只有你的账户和区域中、agent-registry 命名空间、AWS_IAM（SigV4）授权、且状态为 READY 的注册表才会出现。由 Quick 托管的服务角色来链接它。

图 10：链接注册表，只有 READY、AWS_IAM 的注册表可选

#### 创建连接器

注册表链接之后，已批准的 MCP 服务器记录变成连接器卡片：四个业务 MCP 作为卡片，订单履行智能体手工添加。在规模上，通过你的身份提供者联合连接器身份验证，并把连接器供应给组，以 Cognito 用户池作为接缝。

在 Amazon Quick Web 控制台（按用户）中： 四张卡片出现在连接器页面（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 Web 控制台中： 因为它是一条智能体记录，手工创建它的连接器（连接器 → 为你的团队创建 → Model Context Protocol → 新建）：把它命名为 sc-order-fulfillment-agent，指向部署脚本给出的 AgentCore Runtime 直接调用 URL，完成同样的 OAuth 登录，创建并共享。

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

把连接器挂到你的智能体上

部署会创建供应链智能体：一个 Quick Space、导入的数据集和 S3 知识库，以及带有指示、起始提示和欢迎消息的智能体。剩下的是挂上连接器。

在 Amazon Quick Web 控制台（智能体设置）中： 打开部署创建的供应链智能体（默认 id sc-supply-chain-agent），挂上全部五个连接器（四个业务 MCP 加上 sc-order-fulfillment-agent），或者把五个连接器 ID 传给设置脚本。

设置主动监控

要让它主动起来，Quick 按日程或在收到电子邮件时运行同一智能体，并把结果发布到活动信息流。两条路径都复用你已配置的智能体和工具。

在 Quick 桌面应用（设置 → 连接）中： 连接 Outlook 并打开电子邮件监控。然后在 Quick Chat 中创建两条自然语言日程，基于时间（“每天早上检查新的严重中断”）和由电子邮件驱动（“在工作时间每两小时检查供应商回复并校验”）。智能体提取价格、运行检查，并发布一张卡片。

在 Amazon Quick 中试用

智能体和连接器就绪后，在 Amazon Quick Chat 中用自然语言提问。每一条提示都展示先数据、后规则的模式。

结论

AgentCore 与 Amazon Quick 是一种可重复的企业人工智能模式：把智能与界面分开。AgentCore 通过标准 MCP 接口，把碎片化的后端变成可组合、受治理、人工智能可访问的一层。Amazon Quick 用自然语言把访问民主化。

收益是被压缩的决策链：发现、研究、决定、行动和记录，曾经横跨五个工具，现在是一次对话。人工智能负责研究、关联、校验。人做决定。每一次调用都经过身份验证、授权、策略检查和审计，而横跨五个系统的 45-60 分钟例行工作可以压缩到数分钟。

这就是从数据丰富、洞察贫乏，转向数据丰富、决策就绪。从一个 MCP 服务器和一个角色开始。注册表增长，体验保持不变。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/from-data-to-decisions-conversational-supply-chain-intelligence-with-amazon-quick-and-amazon-bedrock-agentcore