AWS解决方案架构团队：多智能体系统投产的核心瓶颈是架构而非提示词

搭建一个多智能体原型如今已经很容易。开源框架和云服务让团队几天内就能跑通一个看起来不错的演示。但AWS解决方案架构团队在构建Deep Insight的过程中发现，真正的问题从原型走向生产应用时才开始。团队的核心判断是：智能体不遵循固定指令序列，它们根据上下文自主判断。因此仅靠提示工程不够，你需要设计智能体如何思考、何时验证、出错时怎么办。

Deep Insight是一个面向数据分析报告生成的多智能体系统：给定CSV文件和自然语言提示，一组分工明确的智能体协作完成数据加载、分析、图表生成、计算验证和报告输出。团队将其架构分为三层。第一层是请求分析层：Coordinator路由用户请求，Planner将复杂任务拆解为5到10个步骤的检查清单，Plan Reviewer将计划呈现给用户审批或要求修改。第二层是编排层：Supervisor按计划顺序调用第三层的专家智能体。第三层是执行层：Coder写分析代码，Validator重新验算，Reporter生成最终报告，Tracker更新进度状态。

控制执行流的关键是Strands Agents SDK中的两个模式。Graph模式将智能体间的执行顺序定义为有向图，条件分支使人工审批和错误处理变得直接——用户要求修改计划时，流程回环到Planner而非从头重来。Agents-as-Tools模式让Supervisor按需将Coder、Validator等专家智能体注册为工具调用，每个智能体在独立上下文中工作，只返回压缩结果，从而在保留专业能力的同时控制上下文窗口占用。

按角色分配模型是另一项架构决策而非简单的模型选择。团队将Claude Haiku用于Coordinator的快速路由分类，避免在简单问候上消耗Opus级成本；将Claude Opus配合Extended Thinking用于Planner的深度规划；将Claude Sonnet用于Supervisor、Coder、Validator和Reporter的执行层。Supervisor、Coder和Reporter启用Prompt Caching缓存系统提示和工具定义，团队称重复调用时输入token成本可降低最高90%；Coordinator只运行一次，Validator和Tracker每次上下文不同，因此对它们禁用缓存。这是一种有意识的成本与性能权衡。

生产部署面临的安全问题与架构设计同等重要。Coder生成的Python代码不能直接在生产服务器上运行——模型可能删除系统文件、在无限循环中耗尽资源、或访问其他用户的分析数据。Deep Insight的解决方案是在AWS Fargate上为每个分析会话创建独立的临时容器，运行在私有VPC子网中且无直接互联网访问，容器在一小时后自动终止。ALB的粘性会话cookie确保同一智能体的多次代码执行路由回同一容器。

团队明确承认当前架构的一个边界：容器隔离保护基础设施，但不治理智能体生成的内容。Validator重新验算数字，但不检测上传数据中隐藏的提示注入指令，也不筛查LLM生成文本中的有害内容。团队建议生产部署额外加入Amazon Bedrock Guardrails进行内容过滤和上下文接地检查，但这不在当前开源版本中。

LG电子韩国销售部门基于相同架构构建了ChatInsight系统。团队报告称，原先整个数据分析请求周期需要2到3周（包括市场人员与数据科学家之间意图传递的损耗），其中具体分析步骤从3天缩短到30分钟，他们将其表述为288倍的生产力提升。这一数字来自AWS团队对自家客户系统的描述，未提供独立基准方法论或误差范围。

这篇是系列第一部分，定义五大生产挑战并展示架构如何逐层应对。第二部分将讨论上下文工程的具体技术，第三部分覆盖从开发到生产的部署运维。Deep Insight已开源，提供本地CLI、浏览器Web界面和AgentCore托管三种部署方式，三者共享同一多智能体架构。