用 Amazon Quick 与 Amazon Bedrock AgentCore 构建对话式供应链智能
From data to decisions: Conversational supply chain intelligence with Amazon Quick and Amazon Bedrock AgentCore
Amazon Quick 与 Amazon Bedrock AgentCore 组合，让供应链管理者用自然语言跨系统提问并直接执行操作。AgentCore 将企业 MCP 服务器暴露为可组合工具层，答案来自实时记录系统与有据可查的文档而非模型记忆，每次变更都需指定人工审批。
让供应链团队直接访问其决策背后的系统。
每条供应链都会持续产生信号：审批中的订单、变化的交货周期、拥堵的港口、波动的价格、中断事件。问题不在于数据稀缺，而在于数据与决策者之间的距离。
要回答“哪些高营收 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 Registry 中的供应链 MCP 服务器。由于管理员已开启注册表集成，四个业务 MCP 服务器已作为连接器卡片出现，连接详情已预先填充，无需手动输入 URL。编排代理作为独立的 MCP 连接器添加。
第 2 步：查询——“显示活跃的中断事件”
“检查活跃的供应中断”会调用 Disruption Alerts 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（Gateways、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 上的智能体，通过 Custom 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 服务器
| 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 Agent | 一个适应角色的 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 中，选择 Settings → Connections → Add Outlook。
- 配置 Activity Feed：在信息流偏好设置中开启电子邮件监控。
- 创建 SC Agent：使用以下指令构建一个智能体：
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，并发布带有“发起紧急 RFQ”操作的警报卡片。
这与传统 BI 的定位对比
| 维度 | 传统商业智能（BI）/ 仪表板 | AgentCore + Amazon Quick |
| 访问模式 | 导航、登录、查找仪表板/报告 | 用自然语言提问。系统查找来源 |
| 洞察时间 | 数分钟到数小时（查找 → 筛选 → 导出 → 关联） | 数秒（提问 → 结合跨系统上下文作答） |
| 多系统关联 | 手动：3-4 个标签页，复制粘贴 | 自动：智能体通过一次查询跨 MCP 服务器进行编排 |
| 行动差距 | 在一个工具中获得洞察 → 切换 → 在另一个工具中行动 | 在同一对话中从洞察到行动 |
| 设置成本 | 数周/数月（仪表板设计、ETL、权限、培训） | 数分钟即可连接，前提是 MCP 服务器已存在 |
| 运行成本 | 固定：无论是否有人查询，管道成本相同 | 基于用量：无服务器可缩容至零，成本随问题数量变化（Lambda + 智能体 token） |
| 信任与准确性 | 与上次 ETL 加载时一样新 | 从记录系统和有依据的文档实时计算，每次写入均需人工把关 |
这并不是“替换一切”的论点。仪表板在趋势可视化、协作分析、监管报告和探索性分析方面仍然更胜一筹。将对话式 AI 用于实时运营决策，将 BI 用于战略分析。它们互补，而非竞争。
角色与用例
一个 Quick Agent 服务于全部三类角色：管理者保持连续性，采购人员以合规意识进行寻源，分析师关联信号。角色也通过行/列级安全性和按角色的 MCP 工具范围界定来限定访问范围，因此采购人员看不到财务数据。
| 角色 | 用例 | 调用的工具 | 结果 |
| SC Manager | 早晨中断检查 | 中断告警 MCP | 中断、收入风险、供应天数 |
| SC Manager | 紧急采购 | 治理 → 报价 MCP | 已验证的替代方案 + RFQ，一个流程 |
| Procurement | 供应商验证、预算权限 | 治理 MCP | 审批、合规、限额 |
| Procurement | RFQ 生成与响应验证 | 报价 MCP | RFQ 已发出 + 响应已验证 |
| Ops Analyst | 跨系统关联 | SC Operations Agent | 多 MCP 推理，一次查询 |
| Ops Analyst | 付款队列、审计、中断趋势 | 发票 / 治理 MCP | AP 账龄、审计日志、模式 |
入门
部署该模式分三个阶段：配置基础设施，将 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 Desktop App（连接 Outlook 以实现电子邮件自动化）。Desktop App 中的对话体验在设置完成后最后进行。
部署基础设施
一切都是开源且脚本化的：克隆 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 验证网关和运行时已就绪。六个 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 安全与权限，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 以卡片形式呈现，订单履行 agent 则手动添加。大规模场景下，通过您的身份提供商联合连接器身份验证，并向组预配连接器，以 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 连接器卡片，其中订单履行 agent 为手动添加
来自注册表的连接器属于 Custom MCP 连接器（与自定义权限相关）。之后移除关联不会删除已创建的连接器。
图 12：使用授权码 OAuth 流程（OAUTH2_AUTHORIZATION_CODE）的 Authenticate 步骤
添加订单履行 agent 连接器
在 Amazon Quick Web 控制台：由于它是 agent 记录，需手动创建其连接器（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
将连接器附加到您的 agent
部署会创建 Supply Chain agent：一个 Quick Space、导入的数据集和 S3 知识库，以及带有指令、起始提示和欢迎消息的 agent。剩下的就是附加连接器。
在 Amazon Quick Web 控制台（agent 设置）：打开部署创建的 Supply Chain agent（默认 id 为 sc-supply-chain-agent）并附加全部五个连接器（四个业务 MCP 加上 sc-order-fulfillment-agent），或将五个连接器 ID 传给设置脚本。
设置主动监控
为实现主动监控，Quick 会按计划或在收到新邮件时运行同一 agent，并将结果发布到 Activity Feed。两条路径都会复用您配置的 agent 和工具。
在 Quick Desktop App（Settings → Connections）：连接 Outlook 并开启邮件监控。然后，在 Quick Chat 中创建两个自然语言计划，一个基于时间（“每天早上，检查是否有新的严重中断”），一个由邮件驱动（“工作时间内每两小时，检查供应商回复并验证”）。agent 会提取定价、运行检查并发布卡片。
在 Amazon Quick 中试用
agent 和连接器就绪后，在 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 服务器和一个角色开始。注册表不断增长，而体验保持不变。
关于作者
Vineet Kachhawaha
Vineet 是 AWS 的全球代理式 AI 高级解决方案架构师，专注于 Amazon Quick。他与企业客户和合作伙伴密切合作，设计、部署和扩展 AI 驱动的解决方案。Vineet 还共同领导了 AWS for Legal Tech 计划，帮助法律和合规组织利用 AI/ML 创造业务价值。他热爱构建和摆弄代理式 AI 解决方案，并认为自己是一名终身学习者。Vineet 经常在 AWS 活动和行业会议上发表演讲，分享他在生成式 AI 和代理式架构方面的专业知识。
Kamlesh Mariwala
Kamlesh 是 Amazon Web Services (AWS) 的生成式 AI 高级专家解决方案架构师，专注于汽车和制造业。他帮助客户设计可扩展、安全且经济高效的架构，利用生成式 AI、代理式 AI 和机器学习来解决复杂的业务问题并加快实现价值的时间。
Sachin Sathaye
Sachin 是 AWS 的数据与 AI GTM 及架构负责人，为企业领导者提供数据与 AI 转型方面的建议。他与 CXO 合作，设计、部署和扩展 AI 驱动的解决方案，将战略转化为可衡量的业务价值，重点关注供应链、商业卓越、新产品导入、制造运营和企业业务服务。Sachin 是《企业代理式 AI 的 12 个要素：价值链》一书的作者，这是一个与供应商无关的框架，用于构建生产级代理式系统，并且是在规模化运营生成式和代理式 AI 方面公认的权威声音。
来源：AWS Machine Learning Blog · aws.amazon.com