让供应链团队直接访问其决策背后的系统。
每条供应链都会不断产生信号：待审批的订单、不断变化的交付周期、放缓的港口、波动的价格、中断事件。问题不在于数据稀缺，而在于数据与决策者之间的距离。
过去，要回答“哪些收入最高的 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 Production Halt。 assess_disruption_impact(disruption_id="DISR-002") 关联订单、客户和库存数据：750K 美元面临风险，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 端点被发现。值得注意的一个规模现实是：由于模式是在运行时发现的，应将其视为契约，在发生破坏性变更时对新旧版本同时进行版本管理。
图 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 服务器
| MCP 服务器 | 能力 | 示例查询 |
Quoting Engine (sc-quoting-gateway) |
报价生成、定价规则、验证 | “为 500 个 SKU-A 生成符合合同的报价” |
Governance Engine (sc-governance-gateway) |
供应商审批、预算权限、法规合规、策略规则 | “SupplierCo 是否在我们的已批准供应商名单中？” |
Invoice Processing (sc-invoice-gateway) |
发票审批路由、应付账款账龄、付款计划 | “本周有哪些发票待审批？” |
中断警报 (sc-disruption-alert-gateway) |
活跃中断、严重程度、影响评估、缓解措施 | “影响我们亚太供应商的关键中断？” |
订单履行代理 (sc-order-fulfillment-agent) |
跨所有四个业务 MCP 的多步骤编排(AgentCore Runtime、直接调用 URL) | “一家供应商停摆了,寻找替代方案,检查合规性,发布询价单(RFQ)” |
Amazon Quick:企业 AI 助手
Amazon Quick 通过聊天、代理、活动动态(Feed)和自动化工作流将 AgentCore 工具呈现在业务用户面前,无需任何技术设置。
所使用的关键组件
| 组件 | 在此模式中的角色 | 工作原理 |
| Agent Registry 连接 | 将 MCP 服务器呈现为连接器 | 管理员只需链接一次注册表。记录即成为连接器卡片 |
| Quick Agent | 一个能适应角色的 SC 代理 | 根据角色(经理、采购、分析师)进行定制 |
| MCP 连接器 | 在聊天中暴露 MCP 工具 | 一个卡片连接器可在聊天、代理、计划中暴露工具 |
| 活动动态(Feed) | 主动警报和操作 | 代理发布卡片。用户执行操作 |
| 计划(Schedules) | 周期性的自然语言自动化 | 例如,“每天早上” |
| Outlook 集成 | 电子邮件进入动态 | 供应商回复被解析并验证 |
| 结构化数据连接器 | 查询运营记录 | 用于MCP规则检查的快速查询空间数据集（订单、库存、供应商、合同） |
| Amazon Simple Storage Service (Amazon S3) 知识库 | 对文档进行检索 | S3知识库中的发票、合同、政策，通过检索增强生成（RAG）为答案提供事实依据 |
| CRM连接器（可选） | 读取客户记录（可选） | CRM（例如Salesforce）中的客户、商机、联系人。也可以加载到数据集中 |
自动化活动流（Activity Feed）与主动监控
该 活动流 是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/件 |
| 价格检查 | ✅ 符合采购准则 |
| 操作 | 为采购订单选择 · 比较响应 · 拒绝 |
阶段 3：人机协同
审核人员比较已验证的响应，然后选择供应商并签发采购订单，或以记录在案的理由拒绝。选择权和采购订单始终保留在人工手中。
用例：主动中断监控
通过计划触发，同样的模式适用：每天上午 8:30 的代理检查新的严重或高严重性中断事件，评估影响，将供应不足七天的任何事项标记为 URGENT，并发布带有 Issue Emergency RFQ 操作的警报卡片。
与传统 BI 的契合之处
| 维度 | 传统商业智能（BI）/ 仪表板 | AgentCore + Amazon Quick |
| 访问模式 | 导航、登录、查找仪表板/报告 | 用自然语言提问。系统会找到数据源 |
| 获得洞察的时间 | 几分钟到几小时（查找 → 筛选 → 导出 → 关联） | 几秒钟（提问 → 结合跨系统上下文给出答案） |
| 多系统关联 | 手动：3-4 个标签页，复制粘贴 | 自动：代理通过一次查询跨 MCP 服务器进行编排 |
| 行动差距 | 在一个工具中获得洞察 → 切换 → 在另一个工具中行动 | 洞察 → 在同一次对话中采取行动 |
| 搭建成本 | 数周/数月（仪表板设计、ETL、权限、培训） | 一旦 MCP 服务器就绪，几分钟即可连接 |
| 运行成本 | 固定：无论是否有人提问，管道成本都相同 | 按使用量计费：无服务器可缩减至零，成本随提问量变化（Lambda + 代理令牌） |
| 信任与准确性 | 数据新鲜度取决于上一次 ETL 加载 | 从记录系统和真实依据文档中实时计算，每次写入都由人工把关 |
这不是一个“全部替换”的论点。仪表盘在趋势可视化、协作分析、合规报告和探索性分析方面仍然更优。将对话式AI用于实时运营决策，将BI用于战略分析。两者互补，而非竞争。
角色与使用场景
One 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 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 函数工具的网关目标，以及 sc-order-fulfillment-agent 以容器形式部署在 AgentCore Runtime 上，并使用最小权限 IAM 角色。阶段 2 将合成数据集上传到 Amazon S3。阶段 3 验证网关和 Runtime 处于 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）进行认证，使用来自部署脚本的 client ID、secret 以及 token、授权和重定向 URL。以测试用户身份登录，启用工具，创建并分享。
图 11：四张业务 MCP 连接器卡片，订单履约代理为手动添加
来自注册表的连接器是 Custom MCP 连接器（与自定义权限相关）。稍后移除链接不会删除已创建的连接器。
图 12：使用授权码 OAuth 流程 (OAUTH2_AUTHORIZATION_CODE) 的 Authenticate 步骤
添加订单履约代理连接器
在 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 agent：一个 Quick Space、导入的数据集和 S3 知识库，以及带有指令、入门提示词和欢迎消息的智能体。剩下的工作就是附加连接器。
在 Amazon Quick Web 控制台中（智能体设置）： 打开部署创建的 Supply Chain agent（默认 ID 为 sc-supply-chain-agent），并附加全部五个连接器（四个业务 MCP 加上 sc-order-fulfillment-agent），或者将这五个连接器 ID 传给设置脚本。
设置主动监控
为了实现主动性，Quick 可以按计划或根据收到的电子邮件运行同一智能体，并将结果发布到 Activity Feed。这两种路径都复用您配置的智能体和工具。
在 Quick 桌面应用中（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 服务器和一个角色开始。注册表不断增长，而使用体验保持不变。