AWS开源Deep Insight多智能体系统：8 个代理分工，用三层架构解决生产环境五类问题
AWS解决方案架构团队称已构建并开源Deep Insight：输入CSV文件和自然语言提示，由 8 个代理协作完成分析并输出带引用的DOCX报告。该团队将生产问题归为五类，并分别对应Strands Agents SDK、Amazon Bedrock、Bedrock AgentCore、Fargate与ALB、DynamoDB与SNS与Cognito。
AI解读：AWS解决方案架构团队作者Yoonseo Kim称，多智能体原型几天能搭好，进入生产就会遇到执行流程失控、模型被乱用、运维不可靠、AI生成代码执行不安全、监控缺失五类问题，并称Deep Insight逐项对应解决。
Deep Insight的 8 个代理分三层：Coordinator负责路由，Planner生成 5 到 10 步计划，Plan Reviewer供用户审批，Supervisor按计划把Coder、Validator、Reporter、Tracker当工具调用；Coder与Validator留下的数字需重算，误差 0.01 以内才算通过。
模型按角色分配：Coordinator用Claude Haiku，Planner用开启Extended Thinking的Opus，Supervisor、Coder、Validator、Reporter、Tracker用Sonnet；Supervisor、Coder、Reporter开启Prompt Caching，AWS称重复调用时输入token成本最多降 90%。
三种部署：自托管CLI约 10 分钟配置完成，面向开发；Web版可上传数据、审查计划并下载报告，面向非开发者；托管版运行在Amazon Bedrock AgentCore runtime，整个系统在私有VPC内，代码解释器单独跑在Fargate上，按用户隔离会话。
Web版计划审批弹窗有 300 秒倒计时，无人响应则自动批准；计划修订次数上限为MAX_PLAN_REVISIONS，执行节点数上限设为 25，以防止流程陷入循环。
来源是AWS博客系列第一篇，披露的是演示与架构说明，未给出生产效果数据，也未说明除演示数据外的客户使用情况。
AWS解决方案架构团队在AWS Machine Learning博客发文，介绍其构建并开源的多智能体系统Deep Insight，以及该系统在生产环境中应对的五类问题。文章作者为Yoonseo Kim，属于三篇系列的第一篇，后续两篇分别讲Context Engineering与生产部署。
按文中描述，Deep Insight接收一个CSV数据文件、一份列定义文件和一句自然语言提示，由 8 个代理协作生成分析图表和一份带引用的DOCX报告。示范数据为虚构食品公司Yummy Food的广告数据，提示为“从销售与营销角度分析，生成图表和洞察，并产出 .docx报告”。
五类问题与对应组件
文章把生产化难点归为五项：多代理间的执行流程控制、每个代理该用哪个大模型、代理完成后能否可靠运行、AI生成代码的安全执行、系统的监控与告警。作者称，仅靠改提示词、加示例、换模型，这些问题仍会反复出现，因此需要设计代理“怎么想、何时验证、出错怎么办”。
- 执行流程：用Strands Agents SDK的Graph模式定义代理顺序和人在环分支，用Agents as Tools模式让Supervisor按需调用专门代理。
- 模型选择：Coordinator用Haiku做基础路由，Planner用Opus做规划，执行类代理用Sonnet。
- 生产运行：Amazon Bedrock AgentCore提供托管运行时、监控、会话隔离和私有VPC部署。
- 代码执行安全：AWS Fargate加Application Load Balancer，为每次会话提供临时沙箱容器，运行自建Code Interpreter。
- 监控告警：Amazon DynamoDB、Amazon Simple Notification Service（SNS）和Amazon Cognito支撑管理后台与故障告警。
8 个代理如何分工
Deep Insight的代理分三层。第一层是Coordinator将请求路由给Planner，Planner用开启Extended Thinking（约 8,192 tokens）的Opus把任务拆成 5 到 10 个带勾选项的步骤，存入full_plan；Plan Reviewer把计划交给用户审批，有修改意见则回到Planner，批准后交给Supervisor。
第二层Supervisor按full_plan顺序把第三层的Coder、Validator、Reporter、Tracker注册为工具并按需调用。其系统提示规定执行顺序为Coder、Tracker、Validator、Tracker、Reporter、Tracker：每个代理跑完都调用Tracker更新进度，当前代理的清单项全部标记为完成后才进入下一个。
第三层各代理在独立上下文中只做自己的任务并把结果压缩后传出。Coder加载数据、写并执行分析代码、产出PNG图表和calculation_metadata.json；Validator从源数据重算，误差在 0.01 以内视为通过，通过的条目写入citations.json供Reporter引用；Reporter读取结果与引用，生成带引用和不带引用两个版本的DOCX。Tracker只用LLM推理、不调用工具，开销较小。
模型与缓存的取舍
文章称，为每个代理单独配置模型和参数，是基于成本与质量的架构选择，并非简单的模型挑选。Supervisor、Coder、Reporter启用了Prompt Caching，缓存系统提示和工具定义，作者称重复调用时输入token成本最多降低 90%。Coordinator只运行一次，Validator和Tracker每次上下文不同，因此未启用缓存。
三种部署方式与内置限制
Deep Insight已在GitHub开源并提供三种部署方式。自托管版通过CLI本地运行，约 10 分钟完成配置，可访问每个代理、提示和工作流的代码，面向快速迭代。Web版提供浏览器界面，可上传数据、审查分析计划并下载报告，不需要写代码。托管版部署在Amazon Bedrock AgentCore runtime上，系统在私有VPC内运行，Code Interpreter单独托管在AWS Fargate，代理按用户隔离会话并发运行。作者称三种方式共用同一套多代理架构，因此在开发环境验证过的代理可直接部署到生产。
文中还给出若干限制：Plan Reviewer的浏览器弹窗有 300 秒倒计时，超时自动批准计划；修订次数上限由MAX_PLAN_REVISIONS控制，执行节点数上限设为 25，用于防止死循环。来源为系列第一篇，生产部署与运维细节留待第三篇，文中未给出该系统在生产环境的效果数据。