【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 个专业 AgentAgent职责工具Supervisor理解意图、编排流程调用其他 5 个 AgentQuery Agent自然语言 → SQL基础数据查询MCP>YAML 配置驱动所有 Agent 定义在一个 YAML 里不用写代码id:supply-chain-insight-agentdefault_agent_id:supervisormcp_servers:-id:data-queryname:Data Query MCPurl:http://data-query-server/mcpmcp_type:sseagents:-id:supervisorname:Insight Supervisorsystem_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_agentname:query_agentsystem_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(statusdelivered) / COUNT(*)放在 Query Agent 的 System Prompt 里。运营说查滝销品Agent 就知道对应的 SQL 条件是库存周转天数超过 90 天。业务规则变了比如滝销标准从 90 天改成 60 天改语义层定义就行不用动代码。Sub-Agent 封装为 ToolStrands SDK 里子 Agent 被包装成 Tool 给 Supervisor 调用def_create_tool_agent(self,agent_id,...):asyncdefagent_function(objective:str,context:strNone):agentAgent(nameagent_name,modelmodel,system_promptsystem_prompt,toolstools,pluginsplugins,)...returntool(agent_function,nameagent_id,descriptiondescription)tool()装饰器把 async function 变成 Strands Tool。Supervisor 调用query_agent(objective查华东上周各品类销量)就像调普通函数一样。这样 Supervisor 完全不关心子 Agent 内部实现。Query Agent 是直连数据库还是走 MCPSupervisor 不需要知道。MCP 协议解耦数据源Query Agent 通过 MCPModel 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模型BedrockClaude 系列状态存储DynamoDBAPI 层API Gateway Lambda认证Cognito数据层MCP Server 对接各类数据库实战场景渠道履约分析运营经理在月度回顾时问了一句“这个月各渠道的履约表现怎么样有没有需要重点跟进的”这是个典型的开放式分析问题——没指定具体指标没限定维度需要系统自己判断怎么看和看什么。传统模式下回答这个问题登录各渠道系统导出数据 → Excel 合并清洗 → 手动计算指标 → 逐个渠道对比 → 写分析报告至少半天。Multi-Agent 系统 30 秒搞定过程是这样的Step 1Supervisor 理解意图调 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 Agent5 秒出结果。Detail/Research/Summary/Action 全跳过——简单问题不浪费 token 和时间。数据架构底层数据通过 AWS Glue 做 ETL 清洗和标准化存在 Amazon S3 分层raw/processed。Agent 发出的查询通过 MCP Server 转成 SQL 打到数据层。这套数据架构的好处是 Agent 层和数据层完全解耦。项目中期我们把查询引擎从一个方案换成了云原生查询服务SQL 方言、连接方式、认证机制全变了。因为走 MCPAgent 代码一行没改——只换了 MCP Server 的实现。扩展方向跑了一个月运营团队提了几个后续需求知识库增强RAG目前业务知识通过语义层注入 System Prompt规则明确、量可控的时候够用。但随着覆盖面扩大——行业知识品类季节性规律、历史案例过去类似异常怎么处理的、行动模板库不同异常对应的处理流程——会超出 Prompt 容量。下一步准备引入知识库作为 Agent 的检索工具不改现有架构加一个 MCP 数据源就行。主动预警不等用户提问Agent 定时扫核心指标异常时自动出报告推到运营群。其实现在已经有个简单版——Supervisor 每天早 8 点跑一遍但还不够智能阈值是硬编码的。跨部门协作供应链问题经常牵扯财务、销售、物流。未来可以让供应链 Agent 和其他业务域的 Agent 对话生成跨部门的联合应对方案。为什么选 Strands AgentCoreMulti-Agent 框架很多我们试过几个后选了 Strands AgentCore原生集成Agent 定义、运行时管理、监控都在同一平台MCP 原生支持换数据源不用改 Agent 代码配置驱动新增 Agent 改 YAML 就行。我们后来加了 Forecast Agent预测库存就加了一段 YAML没写一行新代码开源Strands SDK 开源 MIT出问题能看源码排查不足也有Strands 还比较新社区生态和文档还在建设中。但对已经在用 Bedrock 的团队集成成本是低的。踩坑记录Supervisor 编排过度一开始所有问题都跑 5 个 Agent。简单问题“上周销量多少”也要过一遍 Detail Research又慢又费钱。后来加了分流——简单问题只走 Query Agent。语义层漂移业务术语的定义经常变语义层没跟着改就会查出错误数据。必须有流程保证语义层和业务规则同步。上下文传递Detail Agent 需要 Query Agent 的输出才能下钻。通过context参数传递上游结果Supervisor 负责拼接上下文。错误处理Query Agent 的 SQL 报错Supervisor 要能识别并给用户有用的反馈。不能把ORA-00942: table or view does not exist直接怼给运营。冷启动语义层语义层需要大量业务知识填充。我们找运营团队整理了 200 个常用术语定义前后花了两周。而且不同团队对同一个术语的理解不一样——滾销品在渠道运营和仓储运营那里定义就不同。最后拉了个对齐会把所有术语定义统一了一版。token 成本控制全流程 5 个 Agent 各调一次 LLM复杂问题单次分析消耗 10K token。我们的策略是分流简单问题只走 1-2 个 Agent另外 Summary Agent 和 Action Agent 用了较小的模型不需要复杂推理省一些。调试困难多 Agent 链路出错时定位麻烦。重度依赖 AgentCore 的 OpenTelemetry 链路追踪——每个 Agent 的输入输出、工具调用、耗时都能在 CloudWatch 里看到。没有这个能力多 Agent 的维护成本高得吓人。参考链接官方博客完整架构细节https://aws.amazon.com/cn/blogs/china/multi-agent-architecture-retail-practice/Strands Agents SDKhttps://github.com/strands-agents/sdk-pythonAgentCore 文档https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore.htmlMCP 协议https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore-mcp.html