AWS 团队详解 Deep Insight 多智能体系统的 5 个生产挑战与解法

发生了什么

AWS 解决方案架构团队在 AWS Machine Learning Blog 发布三篇系列文章的第一篇，介绍其自建的多智能体系统 Deep Insight，并梳理生产化过程中必须解决的五个挑战。Deep Insight 已开源在 GitHub，提供自托管 CLI、Web 界面和基于 Amazon Bedrock AgentCore 的托管部署三种方式。

系统接收一个 CSV 数据文件、列定义文件和自然语言提示，由 Coordinator、Planner、Plan Reviewer、Supervisor、Coder、Validator、Reporter、Tracker 八个智能体分层协作，最终产出带引用和不带引用两个版本的 DOCX 报告及 PNG 图表。演示数据为虚构食品公司 Yummy Food 的广告投放数据。

五个挑战与对应方案

原文列出的五个问题分别是：跨智能体的执行流程控制、每个智能体该用哪个大语言模型、成品智能体如何可靠上线运行、如何降低 AI 生成代码执行的安全风险、以及如何监控和管理系统。

对应方案为：用 Strands Agents SDK 的 Graph 模式定义执行顺序并实现人工介入分支，用 Agents-as-Tools 模式让 Supervisor 按需调用专业智能体；在 Amazon Bedrock 上按角色选择 Claude 模型，Haiku 负责路由、Opus 负责规划、Sonnet 负责执行；用 AgentCore 托管运行时提供会话隔离和私有 VPC 部署；用 AWS Fargate 加 Application Load Balancer 为每次会话提供临时沙箱容器执行代码；用 DynamoDB、SNS 和 Cognito 搭建管理后台与失败告警。

编辑部观察

这篇材料的价值在于把多智能体系统的工程细节写到了可复用的粒度，而不是停留在架构图层面。例如原文明确说明 Supervisor、Coder、Reporter 开启 Prompt Caching 以降低重复调用的输入 token 成本，而 Validator 和 Tracker 因每次上下文不同而关闭缓存；Validator 对计算结果按 0.01 误差内判定通过。这些取舍属于作者团队的自述经验，读者应视为一种参考实现而非通用结论。

原文也主动划出了边界：容器隔离保护的是基础设施，不能识别上传数据中隐藏的提示注入指令，也不能筛查生成文本的有害内容，因此建议生产环境额外接入 Amazon Bedrock Guardrails。

实践建议

如果要把这套结构迁移到自己的业务，可以先确认三件事：哪些步骤必须由人确认计划、哪些计算需要独立复核、生成代码在哪个隔离环境中执行。原文提到的 LG Electronics 营销洞察系统和 re:Invent 2025 的 TechRecon 案例，都是替换智能体角色和提示词后复用同一编排结构的尝试，可作为评估该模式通用性的参照。