Amazon Quick + AgentCore：把界面层与智能层拆开，MCP 服务器做可组合工具层
- 架构取向：这套参考实现的要点是把"智能"与"界面"分成两层——Bedrock AgentCore 负责把企业后端（ERP、监控、采购、邮件、合规清单）包装成标准 MCP 服务器并治理调用，Amazon Quick 负责把工具暴露给没有技术背景的业务角色。两层可独立演进。
- 流程对比：传统路径下，供应链经理早上要跨 ERP 查库存异常、看监控告警、跑采购找替代供应商、发邮件询价、再记进追踪表，约 45–60 分钟、5 个系统、十几次上下文切换；对话式路径压缩为三次提示——"哪些高收入 SKU 受当前港口关闭影响"→"评估 TechComp 停产并向获批替代方发紧急询价"→"确认，发出"。
- 示例数据链：调用
assess_disruption_impact时一次 MCP 工具调用跨系统扇出，返回 75 万美元风险敞口、23 个受影响订单、3 天库存；recommend_mitigation再串起 Governance MCP（校验获批供应商）与 Quoting MCP（生成合同对齐报价），由编排 Agent 自行规划调用顺序。 - 治理与权限：AWS Agent Registry 承担发现层——发布者提交记录、策展人审批、管理员与 Quick 账号绑定后，记录才变成连接器卡片；AgentCore 侧由 Identity 做认证与凭证管理、Policy 用自然语言或 Cedar 编写确定性授权规则，在每次工具调用执行前拦截，IAM 鉴权、逐工具授权、输入校验、限流、数据边界与审计日志构成统一控制集。
- 人机边界：所有写操作都停在"待审阅卡片"阶段——Agent 可以校验供应商是否获批、报价是否在指导区间、库存是否低于七天，但选择供应商、生成 PO 仍由人执行；Activity Feed 支持按时间表或供应商邮件触发，触发器→Agent→输出的三段流水线在无人值守时也只产出待办，不产出决策。
- 与传统 BI 的定位划分：作者明确这不是替代关系——仪表盘在趋势可视化、协作分析、监管报表与探索性分析上仍更优，对话式查询用于实时运营决策；差异在于建置成本（周/月 vs 分钟级连接，前提是 MCP 服务器已存在）与运行成本（固定管道 vs 按用量、serverless 缩到零）。
- 信息边界：45–60 分钟到分钟的压缩来自博客的示例场景设定，非客户实测；示例基础设施与合成数据集已开源，但 Registry 审批流、Cedar 策略与 OAuth 配置的具体细节需按部署环境自行调整。 🔗 AWS Machine Learning Blog | 开源示例
