【Bedrock AgentCore】Multi-Agent 架构实战：用 6 个 Agent 打通零售供应链数据→洞察→行动全链路

【Bedrock AgentCore】Multi-Agent 架构实战：用 6 个 Agent 打通零售供应链数据→洞察→行动全链路

最近接了个零售供应链的需求：运营团队每天 60% 时间花在"帮我查个数"上，从提需求到拿到分析结果平均 3 天。老板的原话是------"能不能让运营自己查？直接问就出结果？"

一开始想做 Text-to-SQL，让运营用自然语言查数据。做完发现不够------查到数据后他们还是不知道异常在哪、为什么异常、该怎么处理。

最后用了 Multi-Agent 架构：6 个 Agent 各管一段，从查数据到出报告到建议行动，全自动。基于 Strands Agents SDK + Bedrock AgentCore 搝管，跑了一个月效果还行。

这篇把架构、代码、踩坑都说一遍。如果你也在做供应链或者类似的数据分析类 Agent 项目，应该能少走点弯路。

痛点拆解

供应链运营的数据分析痛点可以拆成三层：

查询壁垒 ：运营不会写 SQL，每次想看个数据都得提需求排队。
洞察缺位 ：数据分析师给了数据，运营也不一定看得出规律------"发货完成率从 95% 掉到 88%"，但这到底严重严重？哪个环节出了问题？
行动脱节：就算分析出来了，从"发现问题"到"落地行动"还有一段路------该调哪个参数？通知谁？发什么邮件？

一个 Agent 搞不定。查数据需要 SQL 能力，分析需要业务知识，出报告需要总结能力，建议行动需要流程知识------每个环节需要的上下文完全不同。

Supervisor-Workers 架构

选了 Supervisor 模式：一个主管 Agent 负责理解意图和编排调用，下挂 5 个专业 Agent：

Agent	职责	工具
Supervisor	理解意图、编排流程	调用其他 5 个 Agent
Query Agent	自然语言 → SQL，基础数据查询	MCP data-query
Detail Agent	多维度下钻（品类/区域/渠道）	MCP data-query
Research Agent	排查根因	MCP data-query + 知识库
Summary Agent	生成结构化报告	无外部工具
Action Agent	转化为可执行行动	通知/工单 API

YAML 配置驱动

所有 Agent 定义在一个 YAML 里，不用写代码：

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，不浪费其他 Agent 的 token。

语义层设计

Agent 要查数据，先得理解业务术语。语义层做了术语到 SQL 的映射：

## 业务术语 → 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 条件是库存周转天数超过 90 天。

业务规则变了（比如滝销标准从 90 天改成 60 天），改语义层定义就行，不用动代码。

Sub-Agent 封装为 Tool

Strands SDK 里，子 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="查华东上周各品类销量") 就像调普通函数一样。

这样 Supervisor 完全不关心子 Agent 内部实现。Query Agent 是直连数据库还是走 MCP，Supervisor 不需要知道。

MCP 协议解耦数据源

Query Agent 通过 MCP（Model Context Protocol）调用数据源：

• Agent 调用 MCP Server 的 query 工具
• MCP Server 连接实际数据库，执行 SQL，返回结果
• 换数据源只需换 MCP Server 配置

mcp_type: sse 用 Server-Sent Events 通信，适合返回大数据集。

完整技术栈

组件	选型
Agent 框架	Strands Agents SDK（开源 MIT）
运行环境	Bedrock AgentCore Runtime
模型	Bedrock（Claude 系列）
状态存储	DynamoDB
API 层	API Gateway + Lambda
认证	Cognito
数据层	MCP Server 对接各类数据库

实战场景：渠道履约分析

运营经理在月度回顾时问了一句："这个月各渠道的履约表现怎么样？有没有需要重点跟进的？"

这是个典型的开放式分析问题------没指定具体指标，没限定维度，需要系统自己判断"怎么看"和"看什么"。传统模式下回答这个问题：登录各渠道系统导出数据 → Excel 合并清洗 → 手动计算指标 → 逐个渠道对比 → 写分析报告，至少半天。

Multi-Agent 系统 30 秒搞定，过程是这样的：

Step 1：Supervisor 理解意图，调 Query Agent 查基础数据

Query Agent 自动把"履约表现"映射为语义层中定义的核心指标（发货完成率、平均履约时效），按渠道维度查本月数据，和上月同期对比。结果出来：渠道 B 的发货完成率较上月同期下降超 5%。

Supervisor 判定为异常，自动进入下钻。

第二步：Detail Agent 多维度下钻

按品类和时间维度拆解渠道 B 的数据------发现异常集中在运动鞋品类，其他品类正常。时间维度上看，下降从月中开始。

第三步：Research Agent 排查根因

从多个方向查运动鞋品类在渠道 B 的履约异常原因：查库存水位、查补货记录、查仓库产能。最终定位到：该渠道对应的仓库上周有设备检修，产能降了 30%，导致运动鞋这种高 SKU 量品类积压。

第四步：Summary Agent 生成报告

结构化输出：渠道 B 运动鞋品类履约异常，根因是仓库设备检修导致产能下降 30%，预计本周恢复正常产能。

第五步：Action Agent 执行行动

自动发两个动作：(1) 给渠道 B 运营对接人发通知，告知履约延迟原因和预计恢复时间；(2) 生成临时调货申请摘要，建议从邻近仓库调运动鞋库存补缺。

从提问到出报告加行动建议，30 秒。以前这事至少半天，还得跨三个部门协调。

再看一个简单场景：运营问"上周华东总销量多少"。Supervisor 判断为简单查询，只调 Query Agent，5 秒出结果。Detail/Research/Summary/Action 全跳过------简单问题不浪费 token 和时间。

数据架构

底层数据通过 AWS Glue 做 ETL 清洗和标准化，存在 Amazon S3 分层（raw/processed）。Agent 发出的查询通过 MCP Server 转成 SQL 打到数据层。

这套数据架构的好处是 Agent 层和数据层完全解耦。项目中期我们把查询引擎从一个方案换成了云原生查询服务，SQL 方言、连接方式、认证机制全变了。因为走 MCP，Agent 代码一行没改------只换了 MCP Server 的实现。

扩展方向

跑了一个月，运营团队提了几个后续需求：

知识库增强（RAG）：目前业务知识通过语义层注入 System Prompt，规则明确、量可控的时候够用。但随着覆盖面扩大------行业知识（品类季节性规律）、历史案例（过去类似异常怎么处理的）、行动模板库（不同异常对应的处理流程）------会超出 Prompt 容量。下一步准备引入知识库作为 Agent 的检索工具，不改现有架构，加一个 MCP 数据源就行。

主动预警：不等用户提问，Agent 定时扫核心指标，异常时自动出报告推到运营群。其实现在已经有个简单版------Supervisor 每天早 8 点跑一遍，但还不够智能，阈值是硬编码的。

跨部门协作：供应链问题经常牵扯财务、销售、物流。未来可以让供应链 Agent 和其他业务域的 Agent 对话，生成跨部门的联合应对方案。

为什么选 Strands + AgentCore

Multi-Agent 框架很多，我们试过几个后选了 Strands + AgentCore：

• 原生集成：Agent 定义、运行时管理、监控都在同一平台
• MCP 原生支持：换数据源不用改 Agent 代码
• 配置驱动：新增 Agent 改 YAML 就行。我们后来加了 Forecast Agent（预测库存），就加了一段 YAML，没写一行新代码
• 开源：Strands SDK 开源 MIT，出问题能看源码排查

不足也有：Strands 还比较新，社区生态和文档还在建设中。但对已经在用 Bedrock 的团队，集成成本是低的。

踩坑记录

1. Supervisor 编排过度：一开始所有问题都跑 5 个 Agent。简单问题（"上周销量多少"）也要过一遍 Detail + Research，又慢又费钱。后来加了分流------简单问题只走 Query Agent。

2. 语义层漂移：业务术语的定义经常变，语义层没跟着改就会查出错误数据。必须有流程保证语义层和业务规则同步。

3. 上下文传递 ：Detail Agent 需要 Query Agent 的输出才能下钻。通过 context 参数传递上游结果，Supervisor 负责拼接上下文。

4. 错误处理 ：Query Agent 的 SQL 报错，Supervisor 要能识别并给用户有用的反馈。不能把 ORA-00942: table or view does not exist 直接怼给运营。

5. 冷启动语义层：语义层需要大量业务知识填充。我们找运营团队整理了 200+ 个常用术语定义，前后花了两周。而且不同团队对同一个术语的理解不一样------"滾销品"在渠道运营和仓储运营那里定义就不同。最后拉了个对齐会，把所有术语定义统一了一版。

6. token 成本控制：全流程 5 个 Agent 各调一次 LLM，复杂问题单次分析消耗 10K+ token。我们的策略是分流（简单问题只走 1-2 个 Agent），另外 Summary Agent 和 Action Agent 用了较小的模型，不需要复杂推理，省一些。

7. 调试困难：多 Agent 链路出错时定位麻烦。重度依赖 AgentCore 的 OpenTelemetry 链路追踪------每个 Agent 的输入输出、工具调用、耗时都能在 CloudWatch 里看到。没有这个能力，多 Agent 的维护成本高得吓人。

参考链接

• 官方博客（完整架构细节）：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
• MCP 协议：https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore-mcp.html