Decision quality
供应链竞争力，最后会落到每一天的决策质量上。
供应链既是零售企业最重要的竞争优势之一，也是运营上最复杂的环节之一。每一个决策都有可量化的成本代价：库存周转时间缩短一天、缺货率降低一个百分点、提前一小时发现物流异常，这些收益都会在规模里叠加。
真正的问题不是企业有没有数据，而是在正确的时间，基于正确的信息，做出正确判断。如今，这种能力已经触手可及：大型语言模型已经能够可靠调用各类工具，编排框架也日趋成熟，足以协调多个专项智能体以生产级质量完成复杂流程。
如果一个问题要半天才查清，很多异常根本不会被调查。
当提问成本很高，团队只会追几个固定 KPI；当回答一个供应链问题的最小单位从“一名分析师加半天时间”降到“一句话加 30 秒”，团队才会追踪更多边角异常，决策覆盖范围才会扩大。
收集 → 查询 → 洞察 → 行动
数据收集已经基本解决，Agent 要补的是后面三步：自动查询、自动分析、把结论变成可执行动作。
Visibility is not decision
数据可见性，不等于数据驱动决策。
经过多年数字化投资，大多数零售商已经建立了相当完整的数据基础设施：ERP、WMS、TMS、数据湖和各类仪表盘一应俱全。控制塔把多源数据聚合起来，提供可视化和告警，解决了“看见数据”的问题。
但控制塔本质上仍然偏被动：分析逻辑在构建时就已固化，只能展示预定义指标，无法主动推理；迭代周期常常以周或月计。业务人员仍然要通过数据工程团队提需求、等结果，在电子表格里做分析，再靠邮件和会议推动行动。
智能体 AI 代表的是控制塔之后的下一步：从“看数据”到“查数据”，从“被动展示”到“主动推理”。供应链团队无需等待分析师重新做仪表盘或临时写查询，直接用自然语言提出问题，获得结构化分析、根因归因和可立即执行的行动方案。
业务人员难以自助获取数据
SQL 技能门槛、不一致的业务定义和复杂多表关联，让很多问题停在“能不能帮我拉一下数”。
原始数据不能自动变成结论
异常检测、多维钻取和根因归因仍然依赖人工经验，分析质量和速度跟人强相关。
洞察留在报告里，行动靠人协调
即使结论清楚，后续仍要发邮件、拉群、开会和追审批，响应时间以天计。
需要 SQL 技能和数据工程支持
自动将自然语言翻译成 SQL 查询
洞察差距只展示预定义指标
执行异常检测、多维钻取和根因归因
行动脱节分析留在报告里，行动依赖人工协调
生成可执行材料并通知相关团队
Supervisor-worker architecture
架构的关键，是让主管代理理解意图，让专项代理各自做好一件事。
基于一家全球鞋服零售商的匿名化场景，可以把系统拆成九个核心组件：用户接入层、智能体核心层、数据访问与网关层、可观测性层。它不是在现有数据平台旁边再做一个“更漂亮的仪表盘”，而是在数据基础设施之上自动化整条推理链。
业务用户通过 Web UI 访问 Chatbot App，前后端经由 API Gateway 与 Lambda 集成；Amazon Cognito User Pools 统一处理用户认证；DynamoDB 保存对话历史和应用配置，让会话上下文可以持续。
智能体应用基于 Strands 框架构建，部署在 AgentCore Runtime 上，大模型能力由 Amazon Bedrock 提供。AgentCore Identity 负责认证流程和第三方 API 密钥管理，外发认证通过 Outbound Auth 的 Client Credentials 机制完成。
AgentCore Gateway 通过 MCP 访问外部数据源，支持 API 目标和 Lambda 目标；AgentCore Observability 覆盖运行状态、工具调用和执行链路，方便后续审计和质量复盘。
Web UI
业务用户用自然语言发起供应链问题。
Chatbot App
承接对话、上下文和前端状态。
API Gateway + Lambda
把前后端请求接入后端服务。
Cognito
统一用户认证与访问入口。
DynamoDB
保存对话历史和应用配置。
Strands + AgentCore Runtime
运行主管代理和专项代理。
Amazon Bedrock
提供模型能力和工具调用推理。
AgentCore Gateway + MCP
通过 API 目标和 Lambda 目标访问外部数据源。
AgentCore Observability
追踪智能体状态、工具调用和执行链路。
职责拆开，准确性才有空间提升。
实践中的一个重要经验是：把所有能力塞进单一智能体提示词，提示词越长，SQL 生成准确性越容易下降。拆成主管-员工模式后，每个代理可以有自己的语义、工具、错误重试和质量检查；查询代理还能分析 SQL 报错并自动重试，而不是把错误直接甩给业务人员。
- 01
主管代理：解读用户意图，判断简单查询还是复杂分析，并协调流程。
- 02
查询代理：自然语言转 SQL，执行基准查询和周期比较。
- 03
详细代理：发现异常后，按类别、时间段和区域执行多维钻取。
- 04
研究代理：从多个角度调查根因。
- 05
汇总代理：将结果整理为结构化业务报告。
- 06
行动代理：生成通知、审批摘要和工单。
Semantic layer + MCP
两个设计决策，决定系统能不能长期可靠运行。
最常见错误不是 SQL 语法，而是业务定义误解。
- “滞销库存”“履行率”“未付款订单”在不同企业有不同口径
- 把业务术语到 SQL 表达式的映射直接注入查询代理的提示词
- 例如将“履行率”定义为
COUNT(status='delivered') / COUNT(*) - 强制所有查询包含日期筛选器，避免无边界扫描
智能体不直接绑死某个数据库或查询引擎。
- AgentCore Gateway 将 API、Lambda 和现有服务转换为 MCP 工具
- 底层查询引擎迁移时，优先替换 MCP 服务器实现
- 渠道伙伴和数据源变化时，智能体代码不必反复改
- 认证、凭据交换、工具发现和外发调用由网关与身份层统一处理
Channel fulfillment analysis
一次“渠道履行情况如何”的提问，可以形成从查询到行动的完整链路。
以下场景基于零售商实际运营数据做匿名化处理。月度运营回顾中，运营经理提出问题：“我们渠道合作伙伴上个月的订单履行情况如何？有哪些需要关注？”过去这类问题往往需要半天时间、电子表格分析和多轮邮件协调。多智能体流程把它拆成可复盘的步骤。
- 01
主管代理识别复杂分析请求
它不直接给一句笼统回答，而是将任务路由给查询代理，先建立可计算基线。
- 02
查询代理映射业务定义并执行 SQL
“履行绩效”被映射到语义层定义，按渠道执行查询，并与上月数据进行比较。
- 03
渠道 B 履行率异常，环比下降 6.8%
系统识别这不是普通波动，需要进入详细代理的多维钻取。
- 04
详细代理定位到品类与时间窗口
异常集中在鞋类，并且主要发生在当月第二周和第三周。
- 05
研究代理发现信用控制触发
渠道 B 的未付款订单率从 8% 上升到 22%，约 340 个订单因此被冻结。
- 06
汇总与行动代理推动后续处理
系统生成根因报告、行动建议、渠道客户经理通知、信用控制团队通知和订单放行请求摘要，进入审批流程。
How leaders should read it
企业主不需要先买一整套大平台，可以从一个高频决策问题开始。
起点不必很大。先选一个能明确算成本、能明确追责、能明确行动人的问题，例如渠道履行异常、库存冻结、缺货风险、物流延迟或高退货 SKU。把数据源、业务术语、审批边界和人工复核路径定义清楚，再让多智能体系统接管查询、分析、材料生成和通知。
从一个真问题开始
不要先问“我们能不能做 Agent”，而是问“哪个供应链问题每天都在消耗人力和响应时间”。
先建语义层
履行率、滞销、缺货、冻结、异常订单等术语要有统一计算口径，否则自然语言查询只会更快地产生错误。
用 MCP 包住数据源
ERP、WMS、TMS、数据湖、审批系统和消息系统不必一次性重构，但要以可治理工具形式暴露给 Agent。
行动必须有审批边界
Agent 可以建议和生成材料，关键库存、信用和客户动作仍应由授权人员确认。
让每次分析可审查
同样的问题和数据应产生一致路径，SQL、工具调用、根因判断和通知记录都要能回看。
从局部闭环到控制面升级
先跑通一个问题的收集、查询、洞察和行动，再扩展到更多渠道、品类和供应链任务。
这类项目的评估重点，不是模型回答得多漂亮，而是一个 Human + Agent 工作单元能否减少等待、减少误判、缩短行动链路，并让业务负责人愿意在真实运营会上使用它。
Technical context
技术选型要服务于业务闭环，而不是把供应链变成另一个演示场。
AgentCore、Strands 和 MCP 的价值，在于让企业把模型、工具、身份、数据源和可观测性组织到可运行的体系里。正式项目仍要回到企业自身的数据结构、业务口径、权限模型、审批流程和运营节奏。
