Amazon Quick 与 Amazon Bedrock AgentCore 构建对话式供应链智能方案
From data to decisions: Conversational supply chain intelligence with Amazon Quick and Amazon Bedrock AgentCore
AWS 介绍如何用 Amazon Quick 和 Amazon Bedrock AgentCore 构建对话式供应链智能方案，让用户通过自然语言查询跨系统数据并获取建议。方案以 MCP 服务器连接业务系统，由 AgentCore 编排工具调用，并由 Amazon Quick 展示结果；采购等变更仍由指定人员审批。文章还提供从部署基础设施、连接数据与注册表到配置主动监控的操作步骤。
文章拆解了从 MCP 服务发现、跨系统查询到人工审批的完整流程，并提供部署步骤，可参考其分层架构组织企业供应链智能体。
让供应链团队直接访问支撑其决策的系统。
每条供应链都会持续产生信号：待审批的订单、不断变化的交货周期、日渐拥堵的港口、波动的价格以及各类中断。问题不在于数据稀缺，而在于数据与决策者之间存在距离。
过去，要回答“哪些营收最高的 SKU 受到当前港口关闭的影响，代价是多少？”，就得知道每条信息分别存在哪个系统里，再趁领域专家等待时手动把它们拼接起来。
如果这位经理能用日常语言提问，并在几秒钟内获得可执行的跨系统答案，会怎样？Amazon Bedrock AgentCore 是智能层，可将企业级模型上下文协议（MCP）服务器作为可组合的工具层开放出来。Amazon Quick 则无需任何设置，就能让不同角色将其转化为行动。答案来自实时记录系统和有依据的文档，而非模型回忆；任何变更都必须等待指定人员批准。本文将端到端介绍这一模式，从 Amazon Quick 中的对话式演示，到背后的 AgentCore 工具层，并展示如何自行部署。
问题：数据丰富，洞察匮乏
图 1：领域专业知识掌握在用户手中，而运营数据则分散在 ERP、监控、采购和电子邮件中
每个问题都需要用到不同的工具：从企业资源规划（ERP）系统获取库存信息，从电子邮件或新闻中了解中断情况，通过采购部门提交询价请求（RFQ），并对照清单核查合规性。数据关联工作需要手动完成。
日常工作的一天
传统上，经理的早晨要在 ERP（库存异常）、监控工具（警报）、采购部门（替代方案）、电子邮件（RFQ）和跟踪表之间奔波：在五个系统中花费 45–60 分钟，切换上下文十多次。
通过对话，只需在一个工具中输入三条提示：“有哪些重大中断影响了我营收最高的 SKU？”→“评估 TechComp 停产事件，并向已批准的替代供应商发出紧急 RFQ”→“看起来不错。发出去。”，几分钟即可完成。
图 2：传统的多工具流程与由 AgentCore 编排的单一对话线程对比
深入解析：供应链场景演示
以下五个步骤将在一段 Amazon Quick 对话中，演示如何追踪一次中断，从发现问题到获批的紧急 RFQ。
步骤 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") 会关联订单、客户和库存数据：面临风险的金额为 $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 服务器。
- 工具发现是自动完成的。客户端会在运行时向注册表查询架构。
AWS Agent Registry：发现层
注册表是受治理的发现层：发布者提交记录，管理者审核批准，之后才能通过混合搜索、浏览或注册表的 MCP 端点发现该记录。有一点规模化实践值得注意：由于架构是在运行时发现的，应将每个架构视为一份契约；遇到不兼容变更时，应同时保留新旧版本。
图 5：向 AWS Agent Registry 发布 MCP 服务器记录，由管理者审批，再由管理员将其关联到 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 服务器 | 功能 | 示例查询 |
报价引擎 (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 通过聊天、代理、Activity Feed 和自动化工作流，将 AgentCore 工具提供给业务用户，无需进行技术设置。
所用关键组件
| 组件 | 此模式中的作用 | 工作方式 |
| Agent Registry 连接 | 将 MCP 服务器作为连接器提供 | 管理员只需连接一次注册表。记录会变成连接器卡片 |
| Quick Agent | 一个可适应不同角色的 SC 代理 | 根据用户角色（经理、采购人员、分析师）进行定制 |
| MCP 连接器 | 在聊天中提供 MCP 工具 | 卡片式连接器可在聊天、代理和计划中提供工具 |
| Activity Feed | 主动警报和操作 | 代理发布卡片。用户采取行动 |
| 计划 | 定期执行的自然语言自动化 | 例如，“每天早晨” |
| Outlook 集成 | 将电子邮件导入 Feed | 解析并验证供应商回复 |
| 结构化数据连接器 | 查询运营记录 | Quick 查询 Space 数据集（订单、库存、供应商、合同），用于 MCP 规则检查 |
| Amazon Simple Storage Service (Amazon S3) 知识库 | 检索文档内容 | 将发票、合同和政策存储在 S3 知识库中，通过检索增强生成 (RAG) 为答案提供依据 |
| CRM 连接器（可选） | 读取客户记录（可选） | CRM（例如 Salesforce）中的客户、商机、联系人。也可以加载到数据集中 |
自动化 Activity Feed 和主动监控
Activity Feed 是 Amazon Quick 的主动式界面，是一个统一收件箱，代理会在其中发布结果、警报和建议。Feed 项目具有以下特点：
- 可执行，每项均包含上下文和后续操作。
- 由 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，智能体会检查是否出现新的严重或高严重级别的供应中断，评估影响，将供应量不足 7 天的情况标记为“紧急”，并发布带有“发起紧急 RFQ”操作的警报卡片。
与传统 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 连接到数据和注册表，以及启用监控。
先决条件
开始之前：
- 拥有 AWS 账户，并可使用 Amazon Bedrock AgentCore 和 AWS Agent Registry。
- 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 提供入口；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 连接器卡片，以及手动添加的订单履行代理
从注册表获取的连接器属于自定义 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 的符合合同条款的报价，以品牌化文档形式呈现。 |
| “一家供应商刚刚停摆。寻找替代方案、验证合规性，并发出紧急询价。” | 订单履约代理将供应中断、治理和报价 MCP 串联起来，生成一项建议。 |
结论
AgentCore 和 Amazon Quick 构成了一种可重复应用于企业的 AI 模式：将智能与界面分离。AgentCore 通过标准 MCP 接口，将碎片化的后端系统转变为可组合、受治理且可由 AI 访问的层。Amazon Quick 则让每个人都能通过自然语言轻松访问这些能力。
其优势在于缩短了决策链：过去需要跨五种工具完成的检测、调研、决策、执行和记录，如今只需一次对话。AI 负责调研、关联和验证，人来做决策。每次调用都经过身份验证、授权、策略检查和审计；原本需要在五个系统中花费 45-60 分钟的例行工作，如今可缩短至几分钟。
这就是从数据丰富、洞察不足转向数据丰富、决策就绪。先从一个 MCP 服务器和一种用户角色入手。注册表不断扩展，使用体验始终如一。
作者简介
Vineet Kachhawaha
Vineet 是 AWS 的高级全球 Agentic AI 解决方案架构师，专注于 Amazon Quick。他与企业客户和合作伙伴密切合作，设计、部署并扩展 AI 驱动的解决方案。Vineet 还共同牵头了 AWS for Legal Tech 计划，帮助法律和合规组织利用 AI/ML 创造业务价值。他热衷于构建和钻研 Agentic AI 解决方案，并认为自己是终身学习者。Vineet 经常在 AWS 活动和行业会议上发表演讲，分享他在生成式 AI 和 Agentic 架构方面的专业知识。
Kamlesh Mariwala
Kamlesh 是 Amazon Web Services (AWS) 的生成式 AI 高级专家解决方案架构师，专注于汽车和制造业。他帮助客户设计可扩展、安全且经济高效的架构，运用生成式 AI、Agentic AI 和机器学习解决复杂业务问题，并加快实现价值的速度。
Sachin Sathaye
Sachin 是 AWS 数据与 AI 市场推广及架构负责人，为企业领导者的数据和 AI 转型提供建议。他与企业高管合作，设计、部署并扩展 AI 驱动的解决方案，将战略转化为可衡量的业务价值，重点关注供应链、商业卓越、新产品导入、制造运营和企业业务服务。Sachin 著有《The 12 Factors of Enterprise Agentic AI: A Value Chain》，该书提出了一个供应商无关的框架，用于构建可投入生产的 Agentic 系统；他也是推动生成式 AI 和 Agentic AI 大规模投入实际运营的知名倡导者。
来源：AWS Machine Learning Blog · aws.amazon.com