Amazon Quick 与 Amazon Bedrock AgentCore 如何实现对话式供应链智能
From data to decisions: Conversational supply chain intelligence with Amazon Quick and Amazon Bedrock AgentCore
AWS 展示了用 Amazon Bedrock AgentCore 作为智能层、Amazon Quick 作为界面的对话式供应链方案：企业通过 MCP 服务器把 ERP、监控、采购等系统暴露为可组合的工具层。
让供应链团队直接访问其决策背后的系统。
每条供应链都会不断产生信号：待审批的订单、变化的交付周期、放缓的港口、波动的价格、中断事件。问题不在于数据稀缺，而在于数据与决策者之间的距离。
过去，要回答“当前港口关闭会影响哪些高收入 SKU，代价是多少？”意味着要知道每条信息存放在哪个系统里，然后在领域专家等待的同时手动拼接这些数据。
那位管理者能否改用自然语言提问，并在几秒钟内获得可操作、跨系统的答案？Amazon Bedrock AgentCore 是智能层，将企业级模型上下文协议（MCP）服务器作为可组合的工具层对外提供。Amazon Quick 无需任何设置，即可将其转化为面向不同角色的实际行动。答案来自实时的记录系统和有据可依的文档，而非模型记忆，且每项变更都需等待具名人工审批。在本文中，我们将端到端地介绍这一模式，从 Amazon Quick 中的对话式引导到其背后的 AgentCore 工具层，并向您展示如何自行部署。
问题：数据丰富，洞察匮乏
图 1：领域专业知识掌握在用户手中，而运营数据却分散在 ERP、监控、采购和电子邮件中
每个问题都需要各自的工具：库存数据来自企业资源计划（ERP）系统，中断信息来自电子邮件或新闻，询价单（RFQ）来自采购系统，合规检查来自清单。关联这些信息全靠人工。
从业者的一天
传统上，管理者的早晨要横跨 ERP（库存异常）、监控工具（告警）、采购系统（替代方案）、电子邮件（RFQ）和一个跟踪表：在五个系统之间切换十几次上下文，耗时 45–60 分钟。
而在对话模式下，只需在同一个工具里输入三个提示：“是否有影响我高收入 SKU 的关键中断？”→“评估 TechComp 停产事件，并向经批准的替代供应商发出紧急询价单”→“看起来不错。发送吧。”，几分钟即可完成。
图 2：传统多工具流程与由 AgentCore 编排的单条对话线程的对比
深入剖析：供应链场景演示
以下五个步骤跟踪一次中断事件，从检测到获得批准的紧急询价单，全程都在一次 Amazon Quick 对话中完成。
第 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")串联了 Governance MCP（验证已批准的替代方案）和 Quoting MCP（符合合同的报价），一次请求一条流程。我们的解决方式：由智能体规划和编排调用，因此一次请求即可跨越中断、治理和报价，无需人工交接。
第 5 步：自动跟进
随后用户设置了主动监控（“每天早上如有新的严重中断就提醒我”）。同样的流程也可以在收到供应商来件邮件时无人值守地运行。我们的解决方式：同一个智能体和工具可按计划任务或邮件触发运行，将可供审核的卡片发布到 Activity Feed，供人员批准。
把这五步连起来看，它们是一条单一的运行时序列：
图 3：演示流程的运行时序列，每个结果都返回 Amazon Quick 供审批
解决方案架构
以上就是体验。下面介绍它是如何构建的：该模式将智能层与界面层分离，使二者可以独立演进，Amazon Quick 作为界面，AgentCore 作为智能。
图 4：从 Amazon Quick 到 AgentCore（Gateway、Runtime、Identity、Policy）再到后端的端到端架构，AWS Agent Registry 并列其中
Amazon Bedrock AgentCore：智能层
Amazon Bedrock AgentCore 是一个模块化的智能体平台，用于安全地大规模构建、部署和运营智能体。它的能力远超我们在此用到的部分。该模式涉及其四项服务：
- Runtime – 面向 MCP 服务器和智能体的无服务器托管，具备会话隔离和内置身份管理。
- Gateway – 将 API、AWS Lambda 函数和服务转化为安全的托管端点之后符合 MCP 规范的工具，实现工具访问的标准化。推理由调用方智能体负责。
- Identity – 身份验证和凭证管理，与现有身份提供商兼容。
- Policy – 确定性的授权规则，可用自然语言或 Cedar 编写，会在执行前拦截每一次工具调用，确保智能体在采购和财务数据上不越界。
MCP 协议：工具如何通信
MCP 是一项开放标准，定义 AI 模型如何与外部工具交互。每台服务器暴露具有类型化参数的工具：
{
"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
}这意味着：
- AI 客户端（Quick、自定义智能体、其他 MCP 应用）可以消费同一批服务器。
- 后端（SAP、Oracle、自定义微服务）可以封装为 MCP 服务器。
- 工具发现是自动的。客户端在运行时向注册中心查询 schema。
AWS Agent Registry：发现层
该注册中心是受治理的发现层：发布者提交记录，策展人批准之后，才能通过混合搜索、浏览或注册中心的 MCP 端点被发现。一个值得注意的规模化现实：由于 schema 在运行时被发现，应将每个 schema 视为一份契约，发生破坏性变更时新旧版本并存。
图 5：将 MCP 服务器记录发布到 AWS Agent Registry、策展人批准、管理员将其链接到 Quick，以及获批记录变为连接器卡片
多步骤编排
推理层是 AgentCore Runtime 上的一个智能体，通过自定义 MCP 连接器以直接调用 URL 形式存在的智能体记录，无需 Lambda 或网关。在这里，它就是订单履行智能体。收到一个请求后，它会规划调用哪些工具以及以何种顺序调用：
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 服务器
| MCP 服务器 | 功能 | 示例查询 |
报价引擎（sc-quoting-gateway） |
报价生成、定价规则、验证 | “针对 500 个 SKU-A 的符合合同条件的报价” |
治理引擎（sc-governance-gateway） |
供应商审批、预算权限、法规合规、策略规则 | “SupplierCo 在我们批准的供应商名单上吗？” |
发票处理（sc-invoice-gateway） |
发票审批路由、应付账款账龄、付款计划 | “本周有哪些发票待审批？” |
中断警报（sc-disruption-alert-gateway） |
活跃中断、严重程度、影响评估、缓解措施 | “影响我们亚太供应商的严重中断？” |
订单履行智能体（sc-order-fulfillment-agent） |
跨全部四个业务 MCP 的多步骤编排（AgentCore Runtime、直接调用 URL） | “一家供应商宕机了，寻找替代方案、检查合规性、发出询价单（RFQ）” |
Amazon Quick：企业级 AI 助手
Amazon Quick 通过聊天、智能体、活动动态和自动化工作流，将 AgentCore 工具提供给业务用户，无需任何技术设置。
使用的关键组件
| 组件 | 在此模式中的角色 | 工作原理 |
| Agent Registry 连接 | 将 MCP 服务器呈现为连接器 | 管理员只需链接一次注册表。记录即成为连接器卡片 |
| Quick 智能体 | 一个可自适应角色的单一 SC 智能体 | 针对不同角色（经理、采购、分析师）进行定制 |
| MCP 连接器 | 在聊天中公开 MCP 工具 | 一个卡片连接器可在聊天、智能体和计划任务中公开工具 |
| 活动动态 | 主动警报和操作 | 智能体发布卡片，用户进行操作 |
| 计划任务 | 基于自然语言的循环自动化 | 例如，“每天早上” |
| Outlook 集成 | 电子邮件进入动态 | 供应商回复被解析并验证 |
| 结构化数据连接器 | 查询运营记录 | Quick 查询 Space 数据集（订单、库存、供应商、合同）以进行 MCP 规则检查 |
| Amazon Simple Storage Service (Amazon S3) 知识库 | 对文档进行检索 | 发票、合同、策略存放在 S3 知识库中，通过检索增强生成（RAG）为答案提供依据 |
| CRM 连接器（可选） | 读取客户记录（可选） | CRM（例如 Salesforce）的账户、商机、联系人。也可加载到数据集中 |
自动化活动动态与主动监控
活动动态是 Amazon Quick 的主动化界面，是一个统一的收件箱，智能体在其中发布结果、警报和建议。动态条目具有以下特点：
- 可操作，每条都附带上下文和后续步骤操作。
- 由 AI 分诊，带有优先级指示器（需要回复、跟进、截止日期）。
- 跨来源，涵盖电子邮件、计划任务、智能体运行和外部系统。
- 人在回路中，由智能体提出建议，由人类做出决定。
自动化监控如何工作
AgentCore 工具加上 Amazon Quick 的主动能力，通过共同的 触发器 → 智能体 → 输出 管道，提供了两条路径：基于时间的和由电子邮件驱动的。
图 7：从触发器（计划任务或电子邮件）到自主智能体（assess_disruption_impact、check_supplier_approval、apply_approval_rules、validate_quote）再到可供审核的卡片的三阶段管道
用例：验证来自电子邮件的供应商回复
供应商通过电子邮件回复紧急询价单（RFQ）并附上报价。智能体验证每份回复（是否为已批准的供应商？是否符合采购指南？）并暂存结果。它不会撰写报价单、挑选中标者或开具采购订单（PO）。
阶段 1：设置（一次性，约 5 分钟）
- 连接 Outlook：在 Amazon Quick 中，选择设置 → 连接 → 添加 Outlook。
- 配置活动源：在源的偏好设置中开启邮件监控。
- 创建供应链（SC）智能体：使用以下指令构建一个智能体：
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源卡片携带验证结果和与决策相关的事实：
| 供应商回复：待审核 | 详情 |
| 供应商 | TechSupply Co，✅ 已批准的供应商 |
| SKU / 数量 / 价格 | MCU-7200 · 10,000 件 · $2.45/件 |
| 价格检查 | ✅ 符合采购指南 |
| 操作 | 选择用于 PO · 比较回复 · 拒绝 |
阶段 3：人在回路中
审核人员比较已验证的回复，然后选择一家供应商并开具 PO，或者附带记录在案的理由予以拒绝。选择权和 PO 开具权始终掌握在人工手中。
用例：主动中断监控
由计划触发，同样的模式同样适用：一个每天上午 8:30 运行的智能体检查新的关键或高严重性中断事件，评估影响，将供应不足七天的任何事项标记为紧急（URGENT），并发布一张带有“发出紧急询价单”操作的警报卡片。
与传统 BI 的定位关系
| 维度 | 传统商业智能（BI）/ 仪表盘 | AgentCore + Amazon Quick |
| 访问模式 | 导航、登录、查找仪表盘/报告 | 用自然语言提问。系统会找到数据源 |
| 获得洞察的时间 | 几分钟到几小时（查找 → 筛选 → 导出 → 关联） | 几秒钟（提问 → 结合跨系统上下文给出答案） |
| 跨系统关联 | 手动：3-4 个标签页，复制粘贴 | 自动：智能体通过一次查询在多个 MCP 服务器之间进行编排 |
| 行动差距 | 在一个工具中获得洞察 → 切换 → 在另一个工具中执行操作 | 洞察 → 在同一次对话中完成行动 |
| 设置成本 | 数周/数月（仪表盘设计、ETL、权限、培训） | 在 MCP 服务器就绪后，只需几分钟即可完成连接 |
| 运行成本 | 固定：无论是否有人查询，管道成本都相同 | 按使用量计费：无服务器可缩减至零，成本随提问量变化（Lambda + 智能体 token） |
| 信任与准确性 | 新鲜度取决于上一次 ETL 加载 | 从记录系统和有据可依的文档中实时计算，每次写入都由人工把关 |
这并不是“取代一切”的论调。仪表盘在趋势可视化、协作分析、监管报告和探索性分析方面仍然是更优选择。将对话式 AI 用于实时运营决策，将 BI 用于战略分析。二者是互补，而非竞争。
角色与用例
一个 Quick Agent 服务于三种角色：经理维护业务连续性，采购人员在合规意识下进行采购，分析师关联各类信号。角色还通过行/列级安全和按角色的 MCP 工具范围限定来约束访问范围，因此采购人员无法看到财务数据。
| 角色 | 用例 | 调用的工具 | 结果 |
| SC Manager | 早上中断检查 | Disruption Alerts MCP | 中断情况、面临风险的收入、供应天数 |
| SC Manager | 紧急采购 | Governance → Quoting MCP | 经验证的替代方案 + RFQ，一个流程搞定 |
| Procurement | 供应商验证、预算权限 | Governance MCP | 审批、合规、限额 |
| Procurement | RFQ 生成与响应验证 | Quoting MCP | 发出 RFQ + 响应经验证 |
| Ops Analyst | 跨系统关联分析 | SC Operations Agent | 多 MCP 推理，一次查询搞定 |
| Ops Analyst | 付款队列、审计、中断趋势 | Invoice / Governance 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 服务器（每个都是 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 的访问权限，因为每张表都通过基于 AWS Glue 数据库的 Athena 源提供服务。没有 Athena 授权，数据集创建将失败。
图 9：Amazon Quick Sight 的 Security and permissions，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 控制台中(按用户):四个卡片会出现在 Connectors 页面上(sc-quoting-mcp、sc-governance-mcp、sc-invoice-processing-mcp、sc-disruption-alert-mcp)。通过 OAuth 授权码流程(OAUTH2_AUTHORIZATION_CODE)进行身份验证,使用部署脚本提供的客户端 ID、密钥,以及令牌、授权和重定向 URL。以测试用户身份登录,启用工具,创建并共享。
图 11:四个业务 MCP 连接器卡片,其中订单履约智能体为手动添加
来自注册表的连接器属于 Custom MCP 连接器(与自定义权限相关)。之后移除关联并不会删除已创建的连接器。
图 12:使用授权码 OAuth 流程(OAUTH2_AUTHORIZATION_CODE)的身份验证步骤
添加订单履约智能体连接器
在 Amazon Quick Web 控制台中:由于它是一个智能体记录,需要手动创建其连接器(Connectors → Create for your team → Model Context Protocol → Create new):将其命名为 sc-order-fulfillment-agent,指向部署脚本中的 AgentCore Runtime 直接调用 URL,完成相同的 OAuth 登录,然后创建并共享。
图 13:创建 sc-order-fulfillment-agent 连接器,指向 AgentCore 运行时调用 URL
将连接器附加到您的智能体
部署过程会创建 Supply Chain 智能体:一个 Quick Space、导入的数据集和 S3 知识库,以及带有指令、入门提示词和欢迎消息的智能体。剩下的工作就是附加连接器。
在 Amazon Quick Web 控制台中(智能体设置):打开部署创建的 Supply Chain 智能体(默认 ID 为 sc-supply-chain-agent),附加全部五个连接器(四个业务 MCP 加上 sc-order-fulfillment-agent),或者将五个连接器 ID 传给设置脚本。
设置主动监控
为实现主动监控,Quick 可按计划或响应收到的邮件运行同一智能体,并将结果发布到 Activity Feed。两条路径都复用您已配置的智能体和工具。
在 Quick Desktop App 中(Settings → Connections):连接 Outlook 并开启邮件监控。然后,在 Quick Chat 中创建两个自然语言日程:基于时间的("每天早上检查新的关键中断")和由邮件驱动的("工作时间每两小时检查供应商回复并进行验证")。智能体会提取价格、运行检查并发布卡片。
在 Amazon Quick 中试用
智能体和连接器就绪后,即可在 Amazon Quick Chat 中用自然语言提问。每个提示词都展示了"先数据后规则"的模式。
| 向 Amazon Quick 提问 | 您将得到 |
| “我有哪些供应链工具？” | 五个 MCP 连接器（报价、治理、发票、中断警报、订单履行智能体）及其状态。 |
| “向我展示当前活跃的供应中断。” | 活跃中断及其严重程度、区域、SKU 数量（Disruption Alerts MCP）。 |
| “评估 TechComp 停产的影响。” | 来自你数据集的收入风险、受影响订单、供应天数。 |
| “该供应商是否为已批准的供应商，我们是否有 72,000 美元采购订单的预算权限？” | 来自 Governance MCP 的审批（供应商状态、预算权限、合规性）。 |
| “为该客户生成一份符合合同的 1,000 件报价单。” | 来自 Quoting MCP 的符合合同的报价单，以品牌文档形式呈现。 |
| “一家供应商刚刚宕机了。寻找替代方案、验证合规性，并发布紧急询价单（RFQ）。” | Order Fulfillment Agent 将中断、治理和报价 MCP 串联为一个建议。 |
结论
AgentCore 和 Amazon Quick 是一种可复用的企业 AI 模式：将智能与界面分离。AgentCore 通过标准 MCP 接口将碎片化的后端转变为可组合、可治理、可供 AI 访问的层。Amazon Quick 以自然语言实现了访问的普及化。
其收益在于决策链的缩短：检测、研究、决策、行动和记录，过去需要跨越五个工具，现在只需一次对话。AI 负责研究、关联和验证，人来决策。每一次调用都经过身份验证、授权、策略检查和审计，原本跨五个系统耗时 45-60 分钟的流程可以缩短到几分钟。
这就是从数据丰富但洞察匮乏，到数据丰富且决策就绪的转变。从一个 MCP 服务器和一个角色开始。注册表会不断增长，而体验始终保持不变。
关于作者
来源： AWS Machine Learning Blog · aws.amazon.com