用 6 个 Agent 接管供应链数据分析：从"帮我查个数"到自动出报告

供应链团队的日常

做过零售供应链运营的人应该都有体感：一线运营人员 60% 的时间花在"查数据"上。

不是他们不想做分析，是查数据这事儿太折腾了。想知道"华东地区上周哪些品类库存周转变差了"，得先找数据分析师写 SQL，分析师排期到后天，结果出来发现还要再下钻——哪些 SKU 拖了后腿？是补货慢了还是动销跌了？又得排一轮。

等分析结果出来，问题可能已经过了处理窗口。

这个痛点其实可以拆成三层：

查询壁垒：运营不会写 SQL，每次提数都要排队
洞察缺位：拿到数据后从数字到结论还有一段路，很多人看不出问题在哪
行动脱节：好不容易分析出来了，从洞察到执行又断了——该调哪个参数？给谁发通知？

为什么想到用 Multi-Agent

最开始想的是做一个 Text-to-SQL 的工具，让运营直接用自然语言查数据。做完发现不够用——查到数据后，运营还是不知道该怎么分析、怎么行动。

一个 Agent 干不了这么多事。查数据、分析异常、研究根因、写报告、触发行动，每一步的上下文和技能要求都不一样。硬塞到一个 Agent 里，System Prompt 得写几千字，推理质量直线下降。

所以选了 Supervisor-Workers 模式：一个主管 Agent 负责理解意图和编排调用，下面挂一串专业 Agent 各司其职。

架构：6 个 Agent 各管一段

用户提问
  ↓
Supervisor Agent（理解意图，编排流程）
  ├─→ Query Agent（自然语言 → SQL，拿基础数据）
  ├─→ Detail Agent（多维度下钻，找异常点）
  ├─→ Research Agent（排查根因）
  ├─→ Summary Agent（生成结构化报告）
  └─→ Action Agent（转化为可执行行动）

每个 Agent 的职责：

Supervisor：接收用户问题，判断需要调用哪些 Agent、什么顺序。它不干具体活，只管编排
Query Agent：把自然语言翻译成 SQL，从数据源拿数据，做同比环比计算
Detail Agent：拿到初步数据后，按品类、区域、渠道等维度下钻，找到具体异常点
Research Agent：针对异常点研究根因——是供应商延迟了？促销力度不够？还是季节性波动？
Summary Agent：把分析结果整理成结构化报告，带关键数据和结论
Action Agent：把洞察转化为具体动作——调整补货计划、发预警邮件、更新促销策略

Supervisor 的编排逻辑

Supervisor 的 System Prompt 里定义了标准分析流程：

id: supply-chain-insight-agent
default_agent_id: supervisor

mcp_servers:
  - id: data-query
    name: Data Query MCP
    url: http://data-query-server/mcp
    mcp_type: sse

agents:
  - id: supervisor
    name: Insight Supervisor
    system_prompt: |
      对于综合分析类问题，按以下流程：
      1. 通过 query_agent了解基本情况和同比变化
      2. 判断是否存在异常（同比变化 > 5%）
      3. 如有异常，通过 detail_agent 做多维度下钻
      4. 通过 research_agent研究根因
      5. 通过 summary_agent生成总结报告
    agent_tools:
      - query_agent
      - detail_agent
      - research_agent
      - summary_agent
      - action_agent

  - id: query_agent
    name: query_agent
    system_prompt: |
      负责基础数据查询和同比分析。
    mcp_tools:
      - data-query:query

关键设计：Supervisor 不是每次都调用所有 Agent。简单查询（"上周销量多少"）只调 Query Agent，复杂分析才走全流程。这样既省 token 又快。

语义层：让 Agent 说"人话"

Agent 要查数据，首先得理解业务术语。"库存周转天数"在数据库里是什么字段？"滞销品"的判断标准是什么？

我们用语义层做了一层映射：

## 业务术语 → SQL 映射
- 库存周转天数 = stock_qty / NULLIF(sold_qty_30d / 30.0, 0)
- 滞销品 = 库存周转天数 > 90
- 畅销品 = sold_qty_7d/7.0 > sold_qty_30d/30.0 * 1.5
- 发货完成率 = COUNT(status='delivered') / COUNT(*)

这个语义层放在 Query Agent 的 System Prompt 里，Agent 生成 SQL 的时候会参考这些定义。不用每次都猜"滞销品到底是 60 天还是 90 天"。

语义层的好处还有一个：业务规则变了，只改语义层定义，不用改代码。

Sub-Agent 包装为 Tool

在 Strands Agent 框架里，子 Agent 是包装成 Tool 给 Supervisor 调用的：

def _create_tool_agent(self, agent_id, ...):
    async def agent_function(
        objective: str,
        context: str = None
    ):
        agent = Agent(
            name=agent_name,
            model=model,
            system_prompt=system_prompt,
            tools=tools,
            plugins=plugins,
        )
        ...
    return tool(agent_function, name=agent_id, description=description)

tool() 装饰器把一个 async function 变成 Strands 的 Tool 对象。Supervisor 调用 query_agent(objective="查华东地区上周各品类销量") 跟调普通工具一样，底层实际上是启动了一个完整的 Agent 执行链。

这个设计的好处是 Supervisor 不需要知道子 Agent 的内部实现。Query Agent 是直连数据库还是走 MCP 协议，Supervisor 不关心。

MCP 协议解耦数据源

数据查询通过 MCP（Model Context Protocol）协议，把数据源和 Agent 解耦：

Query Agent 调用 MCP Server 的 query 工具
MCP Server 负责连接实际数据库、执行 SQL、返回结果
换数据源只需要换 MCP Server，Agent 代码不用动

配置里的 mcp_type: sse 表示用 Server-Sent Events 做通信，适合流式返回大数据集。

配置驱动：YAML 管所有 Agent

所有 Agent 的定义都在一个 YAML 文件里，包括 System Prompt、可用工具、模型选择。好处是：

新增一个 Agent 不用改代码，加一段 YAML 就行
调整编排逻辑只改 Supervisor 的 System Prompt
不同环境（开发/测试/生产）用不同配置文件

技术栈总览

整个系统的技术栈：

Agent 框架：Strands Agents SDK
运行环境：Bedrock AgentCore Runtime
模型：Bedrock（Claude 系列）
数据存储：DynamoDB（Agent 状态和配置）
API 层：API Gateway + Lambda
认证：Cognito
数据源：通过 MCP Server 对接各类数据库

实际效果

以"华东地区上周履约情况"这个问题为例：

Supervisor 判断这是综合分析类问题，启动全流程
Query Agent 查询华东各品类的发货完成率和同比变化
Supervisor 发现 3 个品类发货完成率同比下降超 5%
Detail Agent 按仓库、渠道下钻，发现某仓库是主要拖累
Research Agent 分析根因：该仓库上周有设备检修，产能下降 30%
Summary Agent 输出报告：3 个品类异常，根因是设备检修，预计本周恢复
Action Agent 建议：临时从相邻仓库调货，通知相关渠道预期延迟

全流程 30 秒左右，以前这套分析下来至少半天。

实际效果

以"华东地区上周履约情况"这个问题为例：

Supervisor 判断这是综合分析类问题，启动全流程
Query Agent 查询华东各品类的发货完成率和同比变化
Supervisor 发现 3 个品类发货完成率同比下降超 5%
Detail Agent 按仓库、渠道下钻，发现某仓库是主要拖累
Research Agent 分析根因：该仓库上周有设备检修，产能下降 30%
Summary Agent 输出报告：3 个品类异常，根因是设备检修，预计本周恢复
Action Agent 建议：临时从相邻仓库调货，通知相关渠道预期延迟

全流程 30 秒左右，以前这套分析下来至少半天。

为什么选 Strands + AgentCore

多 Agent 框架有很多选择，我们最终用了 Strands Agents SDK + Bedrock AgentCore Runtime，主要因为：

原生集成：Strands 和 AgentCore 是一套东西，Agent 定义、运行时管理、监控都在同一个平台上
MCP 原生支持：数据源对接用 MCP 协议，换数据库不用改 Agent 代码
YAML 配置驱动：新增 Agent 不用写代码，改配置文件就行
开源：Strands SDK 开源（MIT），可以看到内部实现

当然也有不足——Strands 还比较新，社区生态还在建设中，文档和最佳实践没有那么丰富。但对于已经在用 Bedrock 的团队来说，集成成本是低的。

踩过的坑

Supervisor 编排过度：一开始 Supervisor 对所有问题都跑全流程，简单查询也要过 5 个 Agent，又慢又费 token。后来在 System Prompt 里加了分流逻辑——简单问题只走 Query Agent。
语义层维护：业务术语的定义经常变（"滞销品"标准从 90 天改成 60 天），需要有流程保证语义层和业务规则同步。
子 Agent 上下文传递：Detail Agent 需要知道 Query Agent 的查询结果才能做下钻。我们用 context 参数传递上游 Agent 的输出，Supervisor 负责拼接。
错误传播：Query Agent 的 SQL 报错了，Supervisor 要能识别并给用户有意义的反馈，而不是把原始错误信息透传出去。

写在最后

Multi-Agent 架构在供应链场景的核心价值是打通了数据→洞察→行动的全链路。运营人员不再需要等数据分析师排期，也不用自己从一堆数字里找规律——Agent 帮你查、帮你分析、帮你出报告、帮你建议下一步该干什么。

当然这个架构不是银弹，冷启动时语义层需要大量业务知识来填充，而且 Agent 的推理质量高度依赖 System Prompt 的设计。

完整的架构细节和代码参考：

官方博客：https://aws.amazon.com/cn/blogs/china/multi-agent-architecture-retail-practice/
Strands Agents SDK：https://github.com/strands-agents/sdk-python
AgentCore 文档：https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore.html

posted @ 2026-04-15 10:23 亚马逊云开发者阅读(7) 评论(0) 收藏举报

刷新页面返回顶部

亚马逊云开发者

进入亚马逊云科技开发者网站，请锁定 https://dev.amazoncloud.cn 帮助开发者学习成长、交流，链接全球资源，助力开发者成功。

用 6 个 Agent 接管供应链数据分析：从"帮我查个数"到自动出报告

供应链团队的日常

为什么想到用 Multi-Agent

架构：6 个 Agent 各管一段

Supervisor 的编排逻辑

语义层：让 Agent 说"人话"

Sub-Agent 包装为 Tool

MCP 协议解耦数据源

配置驱动：YAML 管所有 Agent

技术栈总览

实际效果

实际效果

为什么选 Strands + AgentCore

踩过的坑

写在最后

公告