8.0
热点
AI SCORE
技术实践2026-10-21 01:52
用AgentCore串联供应链数据与对话查询
AWS ML Blog#Agent#AWS#供应链
Editor brief · 编辑速览
案例通过Amazon Bedrock AgentCore将分散的企业系统封装为受治理的工具层，再用Amazon Quick提供统一对话入口。文章附有可自行部署的操作流程。
让供应链团队能够直接访问支撑其决策的系统。
每条供应链都在持续产生信号：待审批的订单、不断变化的交付周期、吞吐放缓的港口、波动的价格，以及各种中断事件。问题不在于数据匮乏，而在于数据与决策者之间的距离。
过去，要回答“哪些高营收 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 编排的单一对话线程对比
以下五个步骤展示了如何在一次 Amazon Quick 对话中，完成从发现中断事件到批准紧急 RFQ 的全过程。
用户询问“我有哪些供应链工具？”，Amazon Quick 随即列出已发布到 AWS Agent Registry 的供应链 MCP 服务器。由于管理员已启用注册表集成，四个业务 MCP 服务器已经以连接器卡片的形式显示，连接详情也已预先填好，无需手动输入 URL。编排智能体则作为独立的 MCP 连接器添加。
“检查当前的供应中断事件”会调用 Disruption Alerts MCP（assess_disruption_impact），返回三起中断事件及其严重程度、所在区域和涉及的 SKU 数量。实现方式：Quick 通过 AgentCore 将请求路由到 MCP 服务器，由后者查询后端监控系统并返回结构化结果，无需查看仪表板或导出数据。
用户打开 TechComp 停产事件。assess_disruption_impact(disruption_id="DISR-002") 会关联订单、客户和库存数据：75 万美元面临风险，涉及 23 个订单，库存仅够维持三天。实现方式：一次 MCP 工具调用会分发到多个权威业务系统，因此经理无需操作 ERP，就能获得汇总后的影响分析。
用户请求缓解建议。recommend_mitigation(disruption_id="DISR-002") 会依次调用 Governance MCP（核验已获批准的替代供应商）和 Quoting MCP（生成符合合同约定的报价），通过一次请求完成一套流程。实现方式：智能体规划调用并安排执行顺序，让一次提问即可覆盖中断分析、治理和报价，无需人工交接。
随后，用户设置主动监控：“如果出现新的严重中断事件，每天早上提醒我。”同一流程也可以由收到的供应商邮件触发，无需人工值守。实现方式：同一个智能体和同一组工具按计划或通过邮件触发运行，将可供审核的卡片发布到 Activity Feed，等待人员批准。
将这五个步骤串联起来，就构成了一条完整的运行时序：
图 3：上述操作流程的运行时序，其中每个结果都会返回 Amazon Quick 等待批准
以上是用户体验，下面介绍它的构建方式：这一模式将智能层与界面层分离，使二者能够独立演进，其中 Amazon Quick 作为界面，AgentCore 提供智能能力。
图 4：从 Amazon Quick 到 AgentCore（Gateway、Runtime、Identity、Policy），再到后端的端到端架构，AWS Agent Registry 位于其旁
Amazon Bedrock AgentCore 是一个模块化的智能体平台，用于安全、大规模地构建、部署和运行智能体。它提供的能力远不止本文使用的这些。其中，四项服务与这一模式有关：
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 服务器。
工具发现是自动完成的。客户端在运行时查询注册表，获取模式定义。
注册表是受治理的发现层：发布者提交一条记录，经审核者批准后，才能通过混合搜索、浏览或注册表的 MCP 端点发现该记录。规模化使用时有一点值得注意：由于模式定义是在运行时发现的，应将每份模式定义视为一份契约；对于破坏性变更，应进行版本管理，让新旧版本并存。
图 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 身份验证、逐工具授权、输入校验、策略评估、速率限制、数据边界强制执行、审计日志记录）
Amazon Quick 通过聊天、智能体、Activity Feed 和自动化工作流，将 AgentCore 工具带到业务用户面前，无需技术配置。
Activity Feed 是 Amazon Quick 提供主动服务的界面，也是一个统一收件箱，智能体会在其中发布结果、告警和建议。信息流条目具备以下特点：
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
动态卡片包含验证结果和决策所需的事实：
阶段 3：人工参与
审核人员比较经过验证的回复，然后选择供应商并签发采购订单，或拒绝并记录原因。供应商选择和采购订单签发仍由人工负责。
用例：主动监控供应中断
同样的模式也适用于定时触发的场景：智能体每天上午 8:30 检查是否有新的严重或高严重性供应中断事件，评估其影响，将库存可供天数不足七天的情况标记为 URGENT，并发布带有 Issue Emergency RFQ 操作的告警卡片。
它与传统 BI 如何配合
这并不是要“替换一切”。在趋势可视化、协作分析、监管报告和探索性分析方面，仪表板仍然更具优势。使用对话式 AI 支持实时运营决策，使用 BI 开展战略分析。两者相辅相成。
用户角色与用例
一个 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 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 对外提供服务，并采用 CUSTOM_JWT 授权；AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项功能）；用于映射各 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）。使用部署脚本提供的客户端 ID、密钥、令牌 URL、授权 URL 和重定向 URL，通过 OAuth 授权码流程（OAUTH2_AUTHORIZATION_CODE）完成身份验证。以测试用户身份登录，启用工具，然后创建并共享连接器。
图 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 Runtime 调用 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 中用自然语言提问。每条提示词都体现了先获取数据、再应用规则的模式。
AgentCore 和 Amazon Quick 构成了一种可复用的企业 AI 模式：将智能能力与交互界面分离。AgentCore 通过标准 MCP 接口，将分散的后端整合为一个可组合、受治理且可供 AI 访问的层。Amazon Quick 则让更多用户能够通过自然语言使用这些能力。
收益在于决策链路的整合：发现、研究、决策、执行和记录，过去需要跨越五种工具，如今在一次对话中即可完成。AI 负责研究、关联分析和验证，人负责决策。每次调用都经过身份认证、授权、策略检查和审计，原本需要在五个系统间耗时 45–60 分钟的日常流程，如今可以缩短至几分钟。
这就是从“数据丰富、洞察匮乏”到“数据丰富、随时可决策”的转变。从一个 MCP 服务器和一个用户角色开始。随着注册表不断扩展，使用体验始终如一。