人工智能

从数据到决策:借助 Amazon Quick 与 Amazon Bedrock AgentCore 实现对话式供应链智能

让供应链团队直接访问其决策背后的系统。

每条供应链都会持续产生信号:审批中的订单、不断变化的交货周期、拥堵的港口、波动的价格、各类中断。问题不在于数据稀缺,而在于数据与决策者之间的距离。

过去,要回答“哪些高营收 SKU 受到当前港口关闭的影响,代价是多少?”,就意味着必须知道每个信息分别存放在哪个系统中,并在领域专家等待的同时手工把它们拼接起来。

那位管理者能否改用自然语言提问,并在几秒钟内获得可执行的跨系统答案?Amazon Bedrock AgentCore 是智能层,将企业模型上下文协议(MCP)服务器作为可组合的工具层对外提供。Amazon Quick 则将其转化为无需任何设置即可供各类角色使用的行动能力。答案来自实时记录系统和有依据的文档,而非模型记忆,并且每一项变更都要等待指定人员确认。在本文中,我们将端到端地介绍这一模式,从 Amazon Quick 中的对话式演示,到其背后的 AgentCore 工具层,并向你展示如何自行部署。

问题所在:数据丰富,洞察匮乏

Diagram showing domain expertise with business users while operational data is split across ERP, monitoring, procurement, and email systems

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

每个问题都需要各自的工具:库存来自企业资源计划(ERP)系统,中断信息来自电子邮件或新闻,报价请求(RFQ)来自采购部门,合规性来自检查清单。关联这些信息全靠手工。

管理者的一天

传统上,管理者的一天早晨要穿梭于 ERP(库存异常)、监控工具(告警)、采购(替代方案)、电子邮件(RFQ)和一个跟踪表之间:在五个系统间花费 45–60 分钟,经历十几次以上的上下文切换。

而在对话式体验中,只需在一个工具里输入三条提示——“有哪些关键中断影响我的高营收 SKU?”→“评估 TechComp 停产事件,并向已批准的替代供应商发出紧急 RFQ”→“看起来不错。发送吧。”——几分钟内即可完成。

Comparison of a traditional multi-tool workflow against a single conversational thread orchestrated by AgentCore

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

深入探讨:供应链场景演示

以下五个步骤在同一个 Amazon Quick 对话中,完整跟踪一次中断从发现到紧急 RFQ 获批的全过程。

第 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 步:自动跟进

随后用户设置主动监控(“如果出现新的关键中断,每天早上提醒我”)。同一流程也可以由收到的供应商电子邮件触发,在无人值守的情况下运行。 我们如何解决:同一代理和工具可按计划或由电子邮件触发运行,将可供审核的卡片发布到活动源,等待人员批准。

把上述五个步骤串联起来,就构成一个单一的运行时序列:

Runtime sequence for the walkthrough in which every result returns to Amazon Quick for human approval

图 3:演示的运行时序列,每个结果都会返回 Amazon Quick 等待批准

解决方案架构

这就是用户体验。下面介绍它是如何构建的:该模式将智能层与界面层分离,使二者可以独立演进,其中 Amazon Quick 作为界面,AgentCore 作为智能层。

End-to-end architecture connecting Amazon Quick to AgentCore gateways, runtime, identity, and policy, with AWS Agent Registry alongside

图 4:从 Amazon Quick 到 AgentCore(网关、运行时、身份、策略)再到后端的端到端架构,AWS Agent Registry 位于其侧

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"} // order, inventory, revenue data
    }
  }] // plus classify_severity, recommend_mitigation, get_escalation_chain
}

这意味着:

  • AI 客户端(Quick、自定义代理、其他 MCP 应用)可以消费相同的服务器。
  • 后端(SAP、Oracle、自定义微服务)可以封装为 MCP 服务器。
  • 工具发现是自动的。客户端在运行时向注册表查询模式。

AWS Agent Registry:发现层

注册表是受治理的发现层:发布者提交记录,管理员审批通过后,该记录才能通过混合搜索、浏览或注册表的 MCP 端点被发现。有一个规模方面的现实值得注意:由于模式是在运行时发现的,因此应将每个模式视为一份契约,在发生破坏性变更时让新版本与旧版本并存。

Flow of publishing an MCP server record to AWS Agent Registry, curator approval, admin linking to Quick, and records becoming connector cards

图 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 控制集。

The uniform AgentCore control set applied before the backend, including IAM auth, per-tool authorization, policy evaluation, and audit logging

图 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) “一家供应商宕机了,寻找替代方案,检查合规性,发出询价单”

Amazon Quick:企业 AI 助手

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

使用的关键组件

组件 在此模式中的角色 工作原理
Agent Registry 连接 将 MCP 服务器呈现为连接器 管理员一次性关联注册表。记录变为连接器卡片
Quick 代理 一个适应角色的 SC 代理 针对角色(经理、采购、分析师)进行定制
MCP 连接器 在聊天中公开 MCP 工具 卡片连接器在聊天、代理、计划中公开工具
活动源 主动警报和操作 代理发布卡片。用户采取行动
计划 重复的自然语言自动化 例如,“每天早上”
Outlook 集成 通过电子邮件进入活动源 解析并验证供应商回复
结构化数据连接器 查询运营记录 快速查询 Space 数据集(订单、库存、供应商、合同)以进行 MCP 规则检查
Amazon Simple Storage Service(Amazon S3)知识库 基于文档的检索 S3 知识库中的发票、合同、政策,通过检索增强生成(RAG)为答案提供依据
CRM 连接器(可选) 读取客户记录(可选) CRM(例如 Salesforce)账户、商机、联系人。也可加载到数据集中

自动化活动源与主动监控

该 活动源 是 Amazon Quick 的主动交互界面,一个统一收件箱,代理在此发布结果、警报和建议。活动源条目具有以下特点:

  • 可操作,每项都带有上下文和后续步骤操作。
  • 由 AI 分诊,带有优先级指示(需要回复、跟进、截止日期)。
  • 跨来源,涵盖电子邮件、日程、代理运行和外部系统。
  • 人在回路中,由代理提出建议、由人做出决定。

自动化监控的工作原理

AgentCore 工具加上 Amazon Quick 的主动能力提供两条路径——基于时间和由电子邮件驱动——通过共同的触发 → 代理 → 输出流水线。

Three-stage pipeline from a schedule or email trigger to an autonomous agent to a review-ready card

图 7:从触发器(计划或电子邮件)到自主代理(assess_disruption_impact、check_supplier_approval、apply_approval_rules、validate_quote)再到可供审核的卡片的三阶段流水线

用例:验证来自电子邮件的供应商回复

供应商通过电子邮件回复紧急 RFQ 并附上报价。代理会验证每一份回复(是否为已批准的供应商?是否符合准则?)并暂存结果。它不会撰写报价、选定中标者或签发采购订单(PO)。

阶段 1:设置(一次性,约 5 分钟)

  1. 连接 Outlook: 在 Amazon Quick 中,选择 设置 → 连接 → 添加 Outlook.
  2. 配置活动源: 在源偏好设置中开启电子邮件监控。
  3. 创建 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.
  1. 创建计划: “在工作时间内每 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,代理会检查是否有新的严重或高严重度中断,评估影响,将任何供应不足七天的项目标记为紧急,并发布一张带有“发起紧急询价”操作的警报卡片。

它与传统 BI 的定位对比

维度 传统商业智能(BI)/仪表板 AgentCore + Amazon Quick
访问方式 导航、登录、查找仪表板/报告 用自然语言提问。系统会找到数据源
洞察所需时间 数分钟到数小时(查找 → 筛选 → 导出 → 关联) 数秒(提问 → 结合跨系统上下文给出答案)
多系统关联 手动:打开 3-4 个标签页,复制粘贴 自动:代理通过一次查询跨 MCP 服务器进行编排
行动缺口 在一个工具中获得洞察 → 切换 → 在另一个工具中行动 在同一对话中从洞察到行动
设置成本 数周/数月(仪表板设计、ETL、权限、培训) 一旦你的 MCP 服务器就绪,数分钟即可连接
运行成本 固定:无论是否有人提问,流水线成本都相同 基于用量:无服务器可缩容至零,成本随提问量变化(Lambda + 代理令牌)
信任与准确性 与上次 ETL 加载时一样新 从记录系统和有依据的文档实时计算,每次写入都需人工把关

这并不是一个“取代一切”的论点。仪表板在趋势可视化、协作分析、监管报告和探索性分析方面仍然更胜一筹。将对话式 AI 用于实时运营决策,将 BI 用于战略分析。二者是互补关系,而非竞争关系。

角色与用例

一个 Quick Agent 即可服务全部三类角色:经理负责维持连续性,采购人员以合规意识进行寻源,分析师负责关联信号。角色还通过行级/列级安全性和按角色划分的 MCP 工具范围来限定可及范围,因此采购人员看不到财务数据。

角色 用例 调用的工具 结果
供应链经理 晨间中断检查 中断警报 MCP 中断情况、面临风险的收入、库存天数
供应链经理 紧急采购 治理 → 报价 MCP 已验证的替代方案 + RFQ,一个流程
采购 供应商验证、预算权限 治理 MCP 审批、合规、限额
采购 RFQ 生成与响应验证 报价 MCP RFQ 已发出 + 响应已验证
运营分析师 跨系统关联 供应链运营代理 多 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 Identity and Access Management(IAM)部署和注册权限的有效凭证(aws sts get-caller-identity 返回目标账户)。
  • 数据层:一个数据库(Snowflake、PostgreSQL/RDS 或 SQLAlchemy 引擎)、一个 Amazon S3 存储桶,以及可选的 Salesforce 组织。
  • 为你的组织设置好 Amazon Quick。
  • (可选)用于电子邮件自动化的 Outlook 账户。

设置涉及两个界面,因此以下每个步骤都会注明其发生位置:浏览器中的 Amazon Quick 网页控制台 (Amazon Quick Sight 权限、Agent Registry 关联、连接器和代理设置)以及 Quick 桌面应用 (连接 Outlook 以实现电子邮件自动化)。桌面应用中的对话体验放在最后,待设置完成后进行。

部署基础设施

一切均为开源且已脚本化:克隆 quick-for-supply-chain 示例位于 aws-samples/sample-amazon-quick-suite-knowledge-hub 仓库中,并遵循其 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 验证网关和运行时处于 Ready 状态。六条 Agent Registry 记录已获批准。

AWS Agent Registry console showing six approved records: four MCP servers, one agent, and one skills record

图 8:AWS Agent Registry 控制台,显示六条已批准的记录(四个 MCP Server、一个 Agent、一个 Skills)

授予 Amazon Quick 访问你的数据的权限

在 Amazon Quick 网页控制台中(浏览器): 在 Amazon Quick Sight 管理页面(Manage Quick Sight → Security and permissions)中,为 Amazon Quick 授予对 S3 存储桶和 Amazon Athena 的访问权限,因为每张表都是通过基于 AWS Glue 数据库的 Athena 数据源提供的。如果没有 Athena 授权,数据集创建会失败。

Amazon Quick Sight Security and permissions page with Amazon Athena selected alongside Amazon S3

图 9:Amazon Quick Sight 的 Security and permissions 页面,Amazon Athena 与 Amazon S3 并列显示

关联注册表并创建连接器

关联注册表是一次性操作,且需要管理员级别权限。创建连接器则是按用户进行的。两者都在 Amazon Quick 控制台中完成。请参阅 AWS Agent Registry 集成指南。

关联注册表(管理员,一次性)

管理员将一个 Agent Registry 关联到 Quick 账户。 在 Amazon Quick 网页控制台中(管理员): 前往 Manage account → Permissions → AWS Agent Registry 并开启该注册表(sc-supply-chain-registry,每个账户一个)。仅显示您账户和区域中、agent-registry 命名空间、AWS_IAM(SigV4)授权且状态为 READY 的注册表。Quick 托管服务角色会将其关联。

Registry linking screen showing only READY, AWS_IAM registries as selectable

图 10:关联注册表,仅可选择状态为 READY、使用 AWS_IAM 的注册表

创建连接器

注册表关联后,已批准的 MCP 服务器记录会变成连接器卡片:四个业务 MCP 作为卡片,订单履约代理则手动添加。规模化时,通过你的身份提供商联合连接器身份验证,并按组预配连接器,以 Cognito 用户池作为衔接点。

在 Amazon Quick 网页控制台中(按用户): 四张卡片会出现在 Connectors 页面上(sc-quoting-mcp, sc-governance-mcp, sc-invoice-processing-mcp, sc-disruption-alert-mcp)。通过 OAuth 授权码流程(OAUTH2_AUTHORIZATION_CODE)进行身份验证,使用部署脚本中的客户端 ID、密钥和令牌、授权 URL 及重定向 URL。以测试用户身份登录,开启工具,创建并共享。

The four business-MCP connector cards on the Connectors page

图 11:四张业务 MCP 连接器卡片,其中订单履约代理为手动添加

Registry-sourced connectors are Custom MCP connectors (relevant for custom permissions). Removing the link later doesn’t delete connectors already created.

The Authenticate step using the authorization-code OAuth flow

Figure 12: The Authenticate step using the authorization-code OAuth flow (OAUTH2_AUTHORIZATION_CODE)

Add the order-fulfillment agent connector

In the Amazon Quick web console: because it is an agent record, create its connector manually (Connectors → Create for your team → Model Context Protocol → Create new): name it sc-order-fulfillment-agent, point it at the AgentCore Runtime direct invocation URL from the deploy script, complete the same OAuth sign-in, create and share.

Creating the sc-order-fulfillment-agent connector pointed at the AgentCore runtime invocation URL

Figure 13: Creating the sc-order-fulfillment-agent connector, pointed at the AgentCore runtime invocation URL

Attach the connectors to your agent

The deployment creates the Supply Chain agent: a Quick Space, imported datasets and S3 knowledge base, and the agent with instructions, starter prompts, and welcome message. What remains is attaching the connectors.

In the Amazon Quick web console (agent settings): open the deployment-created Supply Chain agent (default id sc-supply-chain-agent) and attach all five connectors (four business MCPs plus sc-order-fulfillment-agent), or pass the five connector IDs to the setup script.

Set up proactive monitoring

To make it proactive, Quick runs the same agent on a schedule or on incoming email and posts results to the Activity Feed. Both paths reuse the agent and tools you configured.

In the Quick Desktop App (Settings → Connections): connect Outlook and turn on email monitoring. Then, in Quick Chat, create two natural-language schedules, time-based (“Every morning, check for new critical disruptions”) and email-driven (“Every two hours in business hours, check supplier replies and validate”). The agent extracts pricing, runs the checks, and posts a card.

Try it in Amazon Quick

With the agent and connectors ready, ask in natural language in Amazon Quick Chat. Each prompt shows the data-then-rules pattern.

Ask Amazon Quick What you get
“What supply chain tools do I have?” The five MCP connectors (quoting, governance, invoice, disruption alerts, order-fulfillment agent), with status.
“Show me active supply disruptions.” Active disruptions with severity, region, SKU counts (Disruption Alerts MCP).
“Assess the impact of the TechComp production halt.” Revenue at risk, affected orders, days of supply, from your datasets.
“Is this supplier an approved vendor, and do we have budget authority for a $72,000 PO?” An approval from the Governance MCP (vendor status, budget authority, compliance).
“Generate a contract-aligned quote for 1,000 units for this customer.” A contract-aligned quote from the Quoting MCP, as a branded document.
“A supplier just went down. Find alternatives, verify compliance, and issue an emergency RFQ.” The Order Fulfillment Agent chains disruption, governance, and quoting MCPs into one recommendation.

Conclusion

AgentCore and Amazon Quick are a repeatable enterprise-AI pattern: separate intelligence from interface. AgentCore turns fragmented backends into a composable, governed, AI-accessible layer through standard MCP interfaces. Amazon Quick democratizes access in natural language.

The gain is the collapsed decision chain: detect, research, decide, act, and log once spanned five tools, now one conversation. The AI researches, correlates, validates. The person decides. Every call is authenticated, authorized, policy-checked, and audited, and a 45-60 minute routine across five systems can collapse to minutes.

That is the shift from data-rich, insight-poor to data-rich, decision-ready. Start with one MCP server and one persona. The registry grows and the experience stays the same.


About the authors