5 production challenges in multi-agent systems and how Deep Insight solved them

多智能体系统生产环境中的五大挑战及 Deep Insight 的解决方案 | 人工智能

多智能体系统生产环境中的五大挑战及 Deep Insight 的解决方案

构建多智能体系统如今已变得相对简单。真正具有挑战性的部分是将其投入生产环境。得益于开源框架和云服务，团队可以在几天内搭建出一个智能体。只需几次工具调用、几行提示语，就能创建出看似令人印象深刻的应用。但当团队试图从试点阶段转向实际业务应用时，往往会遇到熟悉的瓶颈。如果你曾尝试将智能体投入生产环境，以下这些困扰一定会引起共鸣：

为什么智能体不遵循我们的业务逻辑？为什么它会跳过验证步骤？为什么无法捕捉到边缘情况？

你调整提示语、增加更多示例、更换模型。但同样的问题反复出现。这是因为智能体并不遵循固定的指令序列，而是基于上下文自行判断。仅靠指令本身是不够的。你需要设计智能体的思考方式、验证时机以及在出现问题时的应对策略。这正是为什么必须超越单纯的提示工程，设计智能体的完整认知架构和执行流程变得至关重要。

为了解决这些挑战，AWS 解决方案架构团队构建了 Deep Insight，这是一个生产级的多智能体系统。在本系列文章中，我们将通过三篇文章分享团队在构建 Deep Insight 过程中的第一手经验。我们将详细讲解如何在真实生产环境中应用 Anthropic 提出的上下文工程（Context Engineering）技术（包括多智能体架构、结构化笔记、人机协作等）。同时，我们也将探讨在实施过程中遇到的权衡取舍（附带代码示例），以及在 AWS 上部署和运行该智能体所获得的运营洞察。

博客系列概览

• 第1部分：多智能体系统生产环境中的五大挑战及 Deep Insight 的解决方案。
• 第2部分：突破上下文窗口限制：上下文工程技术及其在 Deep Insight 中的应用。
• 第3部分：工程实践：将 Deep Insight 从开发环境部署到生产环境。

这是三部分系列文章的第1部分。本文将定义任何生产级多智能体系统必须解决的五大核心挑战，并展示从 Strands Agents SDK 和 Amazon Bedrock 到 Amazon Bedrock AgentCore、应用负载均衡器（Application Load Balancer）和 AWS Fargate 等各层技术如何逐一解决这些挑战。第2和第3部分将分别探讨上下文工程和生产部署相关内容。

Deep Insight 介绍

Deep Insight 是一个将复杂数据分析转化为自动化洞察的多智能体系统。给定一个 CSV 文件和自然语言提示，由协调者（Coordinator）、规划者（Planner）、监督者（Supervisor）、编码者（Coder）、验证者（Validator）、报告者（Reporter）和追踪者（Tracker）组成的智能体层级将协作完成分析。它们共同加载数据、执行分析、生成图表、验证计算，并最终生成包含引用的完整报告（.docx）。

我们将在后面详细探讨其架构。首先，让我们看看它如何运作。在演示中，我们使用一家虚构食品公司 Yummy Food（yummy-food-market.csv）的广告数据，并配合列定义文件（column_definitions.json），提供如下指令：从销售和营销角度进行分析，生成图表和洞察，并生成 .docx 报告。Deep Insight 会生成分析计划，提交给用户审批，审批通过后执行分析。

内容

输入

CSV 数据文件（

yummy-food-market.csv

）+ 列定义文件（

column_definitions.json

）

示例指令

“从销售和营销角度进行分析，生成图表和洞察，并生成 .docx 报告。”

输出

DOCX 报告（两个版本，一个包含引用，一个不包含）加图表图形（PNG）

接下来的 Deep Insight 网页演示视频将展示完整工作流程，包括上传数据、审查分析计划、实时流式传输以及下载最终报告。

我如何尝试使用它？

Deep Insight 在 GitHub 上开源并提供完整的设置指南，提供三种部署选项，覆盖从开发到生产环境的场景。

第一种是 自托管版本，通过 CLI 本地运行。它针对快速迭代进行了优化，可完全访问每个代理、提示和工作流程的代码层。设置时间约为 10 分钟，非常适合开发环境。（可在 YouTube 上观看自托管演示视频。）

第二种是 网页版，提供基于浏览器的界面，用于上传数据、审查分析计划（人机协作模式，HITL）以及下载报告，无需编写代码，适合非开发人员使用。（前面的演示视频展示了网页版的实际操作。）

第三种是 托管 AgentCore 版本，基于 Amazon Bedrock AgentCore 的生产部署选项，这是一个用于大规模构建、连接和优化代理的平台，支持任意框架或模型。此版本在 AgentCore 运行时（Amazon Bedrock AgentCore 的一项功能）上部署代理。系统完全运行在私有虚拟私有云（VPC）内，代码解释器托管在 AWS Fargate 上，代理在隔离的用户环境中并发运行。当需要会话隔离和私有 VPC 部署时，这是最佳选择。第三部分将详细说明其部署和操作方式。

所有三种版本共享相同的多代理架构，因此在开发环境中验证的代理可直接部署到生产环境。

解决方案概述

构建一个生产级的多代理系统不仅需要优秀的提示词，还需要合适的科技栈和基础设施，以解决代理如何协作、如何推理、如何部署、在哪里安全执行代码以及如何监控运行状态等问题。Deep Insight 在以下五个关键领域解决了这些问题。由于代理会生成代码和报告内容，解决方案细节 2 中还涵盖了生产环境中的负责任 AI 控制措施。

| 挑战 | 技术 | 方法 | |------|------|------| | “我们如何在多个代理之间控制执行流程？” | Strands Agents SDK | 使用 Strands 的 Graph 模式定义代理间的执行顺序，实现人机协作分支。使用 Strands 的 Agents as Tools 模式，使 Supervisor 可按需调用专用代理（Coder、Validator、Reporter、Tracker）作为工具。 | | “每个代理应使用哪种大语言模型（LLM）？” | Amazon Bedrock | |

选择适合每个角色的 Claude 模型：Haiku 用于基础路由，Opus 用于规划，Sonnet 用于执行。

“如何可靠地在生产环境中运行一个完成的代理？”

Amazon Bedrock AgentCore

托管运行时，具备监控、会话隔离和私有 VPC 部署功能。

“如何缓解执行 AI 生成代码带来的安全问题？”

AWS Fargate + 应用负载均衡器（ALB）

通过自定义代码解释器，使用会话级临时沙箱容器实现隔离代码执行。

“如何监控和管理系统？”

Amazon DynamoDB + Amazon 简单通知服务（Amazon SNS）+ Amazon Cognito

管理员仪表板和故障预警系统。

以下架构图（图 1）可一目了然地展示整体方案。绿色方框代表 Strands Agents 多代理结构，该结构解决了前表中挑战 1 和 2。我们将在后续的解决方案详情 1：多代理系统设计部分详细说明。图中显示的其余基础设施组件则对应解决挑战 3、4 和 5，相关内容将在解决方案详情 2：生产部署与运营部分进行讲解。

图 1：解决方案架构

解决方案详情 1：多代理系统设计

Deep Insight 采用多代理架构，其中八个代理协作生成高质量交付成果。每个代理在独立上下文中运行，仅执行其专业任务，并仅传递压缩后的结果。

图 2：多代理结构

协调器负责路由用户请求，规划器将任务分解为离散步骤，计划审核员收集用户反馈，监督器根据计划调用合适的专用代理。编码器编写并执行数据分析代码，验证器验证计算过程，报告器生成最终报告，跟踪器追踪进度。我们将通过以下三个层级进行说明：

• [第一层] 协调器 → 规划器 → 计划审核员：请求分析与执行计划创建。

• [第二层] 监督器：专用代理编排。

• [第三层] 编码器、验证器、报告器、跟踪器：专用任务执行。

Strands Agents SDK 中的两个关键模式组合使用，用于控制这些代理间的执行流程。首先，图模式将代理的执行顺序和流程定义为有向图。请求流经协调器、规划器、计划审核员后到达监督器，当收到修订请求时会通过条件分支返回规划器。通过条件判断确定下一步，使 HITL 和错误处理等复杂工作流变得简单直观。其次，代理作为工具模式使监督器仅在需要时才将专用代理（编码器、验证器、报告器、跟踪器）作为工具调用。每个代理在独立上下文中运行，仅返回结果，在减少上下文使用的同时保留领域专业知识。

本节将展示架构如何解决路由、规划和编排问题。

[第一层] 协调器 → 规划器 → 计划审核员

这一层级将用户请求转化为获批的执行计划。

#### 1.1 协调器（路由）：并非所有请求都需要昂贵的编排

协调器是用户请求的入口点。它直接处理基本问候，通过 handoff_to_planner 标记将复杂任务（如数据分析）路由给规划器。

关键设计决策是模型选择：由于Coordinator仅负责分类，因此使用轻量级的Claude Haiku模型，避免在基础问候等场景中产生Opus级别成本，同时实现快速响应。

# builder.py: 用于路由决策的条件边
builder.set_entry_point("coordinator")
builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner)

路由条件来源于Coordinator的提示词：任何需要工具、推理或多步骤思考的请求都会被路由到Planner。

#### 1.2 Planner（计划创建）：复杂分析需要在执行前进行分解

在Deep Insight的多智能体架构中，Planner代理负责在代理之间分配任务的关键角色。在实质性工作开始之前，它会将大型任务分解为更小的步骤，每个专业代理按顺序执行任务，保持每个代理的上下文规模较小。

Planner使用开启Extended Thinking功能的Claude Opus模型来制定分析计划。它将计划组织为[ ]清单格式，明确指定分配给每个代理的具体任务，存储在full_plan变量中。它将请求分解为5-10个清晰步骤，如下例所示：

## title
美味食品消费者购买模式与广告效果分析报告

## steps

### 1. Coder：全面数据分析与洞察生成
- [ ] 从'./data/*'路径加载所有数据文件并理解结构
- [ ] 分析消费者购买历史（模式、偏好、客户群体）
- [ ] 按渠道分析广告数据（成本、效果、渠道对比）
- [ ] 分类级别分析（生鲜食品、便利食品、健康食品广告效果）
- [ ] 计算关键业务指标（转化率、CPA、ROAS等）
- [ ] 生成可视化图表（5+图表、客户群体图表）
- [ ] 推导战略营销洞察
- [ ] 生成计算元数据（用于验证）

### 2. Validator：计算验证与引用元数据生成
- [ ] 识别验证目标并提取过滤计算
- [ ] 直接加载数据文件并重新计算
- [ ] 验证各渠道性能指标准确性
- [ ] 验证可视化图表数据一致性
- [ ] 生成引用元数据（已验证项目的参考编号）

### 3. Reporter：营销分析报告生成
- [ ] 编写报告概述
- [ ] 使用验证后的分析结果创建结构化报告
- [ ] 插入可视化图表和分析章节
- [ ] 呈现营销策略建议和改进建议
- [ ] 生成专业营销报告（DOCX格式）

#### 1.3 计划审核员

计划审核员是一个HITL节点，它向用户展示计划并收集批准或修订反馈。如果有反馈，它会循环回Planner进行计划修订。如果获得批准，它会将任务交给监督员。设置最大修订次数（MAX_PLAN_REVISIONS）以防止无限循环。

# builder.py: 计划审核员的双向条件边
builder.add_edge("plan_reviewer", "planner", condition=should_revise_plan)
builder.add_edge("plan_reviewer", "supervisor", condition=should_proceed_to_supervisor)
builder.set_max_node_executions(25)

在网页版中，计划审核员会显示一个浏览器模态窗口，用户可阅读计划并批准或输入修订反馈。如果300秒内未收到响应，系统将自动批准计划。

图3：Web UI中Plan Reviewer代理的执行

在没有规划的情况下，代理在运行时决定所有操作，中途修正会使之前的工作失效，且用户无法查看进度。通过引入Planner和Plan Reviewer，用户可以审查和修改计划，实时监控进度，并仅重新执行失败的步骤。

[第二层] 监督者（编排器）：专业代理需要指挥者

监督者按顺序执行Planner的full_plan，通过Tool Use调用注册在其上的第三层代理（Coder、Validator、Reporter、Tracker）作为工具。

# nodes.py：在监督者上注册子代理作为工具
agent = strands_utils.get_agent(
    agent_name="supervisor",
    system_prompts=apply_prompt_template(prompt_name="supervisor", prompt_context={}),
    model_id=os.getenv("SUPERVISOR_MODEL_ID", os.getenv("DEFAULT_MODEL_ID")),
    prompt_cache_info=(True, "default"),
    tool_cache=True,
    tools=[coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool],
    streaming=True,
)

监督者的系统提示定义了严格的流程规则：

• 强制执行顺序：Coder → Tracker → Validator → Tracker → Reporter → Tracker：每个代理运行后都会触发Tracker来跟踪进度，使监督者能够管理整体任务状态。

• 阶段完成规则：监督者不会在当前代理的检查表项未全部标记[x]前切换到下一个代理。

• 上下文保留：监督者将线索和full_plan变量传递给每个工具代理，保持完整上下文并防止信息丢失。

[第三层] Coder、Validator、Reporter、Tracker：分工协作提升质量

每个第三层代理（Coder、Validator、Reporter、Tracker）都封装为PythonAgentTool，并接收来自监督者的Tool Use调用。每个代理都在Strands SDK中作为独立的Agent()实例创建，拥有各自的系统提示、模型ID和工具集。

| 代理 | 角色 | 工具 | 关键输出 | |------------|------------------|--------------------------------------------|----------------------------------| | Coder | 数据分析、图表生成、洞察推导 | write_and_execute_tool, bash_tool, file_read, skill_tool | *.png图表，<br>`calculation_metadata.json | | Validator | 数值计算复核、引用生成 | write_and_execute_tool, bash_tool, file_read | citations.json`<br>validation_report.txt | | Reporter | DOCX报告生成 | - | final_report.docx<br>final_report_with_citations.docx | | Tracker | 检查表进度更新 | 无（仅LLM推理） | 更新后的full_plan |

监督者根据Planner的检查表按以下顺序调用Tool Use：

• Coder：加载数据，编写并运行分析代码，生成PNG图表，将结果累积到all_results.txt，并留下calculation_metadata.json供验证。

• Tracker（首次调用）：将检查表项从[ ]标记为[x]，监督者据此决定是否继续执行。

• Validator：从源数据重新执行calculation_metadata.json中的每个计算。误差在0.01以内通过，不匹配项会被标记。验证后的计算结果存入citations.json供Reporter引用。

• Tracker（二次调用）：在检查表中反映Validator的完成状态。

• Reporter：读取all_results.txt和citations.json，生成带引用和不带引用的两个版本最终DOCX报告。

• Tracker（三次调用）：反映所有任务的最终完成状态。

Tracker 在每个代理运行后执行，使 Supervisor 能够跟踪进度并强制执行完成规则（所有项目未标记完成前禁止继续）。由于它通过 LLM 推理更新检查清单且不使用工具，因此仅产生极少的额外开销。

每个代理的 LLM 模型配置

Deep Insight 根据每个代理的角色定制模型和设置。这不是模型选择问题，而是架构层面的决策，旨在优化成本和质量。

| 模型 | 扩展思考 | 提示缓存 | 功能描述 | |------|----------|----------|----------| | Haiku | 禁用 | 否 | 快速路由：成本最小化 | | Opus | 启用（约 8,192 个标记） | 是 | 深度思考：高质量规划 | | Sonnet | 是 | 是 | 执行编排：缓存实现成本节约 |

功能特性：

• 代码生成/执行：缓存对重复调用有效
• 数值验证：每次使用不同数据，缓存无意义
• 报告生成：对长提示缓存有效
• 状态更新：轻量任务，缓存无意义

Supervisor、Coder 和 Reporter 代理使用提示缓存技术，通过缓存系统提示和工具定义，在重复调用时可将输入标记成本降低高达 90%。Coordinator 仅运行一次，Validator 和 Tracker 每次运行上下文不同，因此缓存对其无效且保持禁用。这种选择性缓存策略是明确的成本/性能权衡。

解决方案细节 2：生产部署与运维

如果解决方案细节 1 定义了系统功能，那么本节将定义系统如何在何处安全运行。从这里开始的所有内容均涉及生产环境的基础设施决策。具体而言，本节涵盖 LLM 生成代码的安全执行环境，以及团队的运维可见性。

1. 代码执行：LLM 生成代码需要安全执行环境

Coder 代理编写并运行 Python 进行数据分析。在自托管版本中，它通过 subprocess.run() 本地运行，但在生产环境（AgentCore）中，安全性和隔离性至关重要。直接在生产服务器上运行 LLM 生成的代码存在风险：模型可能删除系统文件、在无限循环中耗尽资源，或访问其他用户的分析数据。Deep Insight 通过 AWS Fargate 和 ALB 的会话级临时容器解决此问题。这些组件并非完全隔离，如图 1 所示，AgentCore 运行时、ALB 和 Fargate 任务均运行在相同私有 VPC 内。VPC 端点通过私有网络连接至 Amazon S3、Amazon Bedrock 和 Amazon ECR，无需经过公共互联网。安全组限制哪些组件可以访问代码解释器容器。AWS IAM 角色将每个组件权限限制为其所需的 AWS 资源。Amazon CloudWatch 从 AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）收集容器日志和可观测性数据。

• 自定义容器 Docker 镜像：为多代理系统预优化的沙箱，包含字体、系统库和 Python 包
• 容器隔离：每个分析会话在私有 VPC 子网中获得独立的 Fargate 容器，无直接互联网访问
• 两步执行流程：LLM 生成代码先进行 base64 编码，通过 HTTP 发送并写入文件（步骤 1），再通过 subprocess 执行（步骤 2）
• 会话亲和性：ALB 的粘性会话 cookie 可确保代理在多次执行代码时仍路由到相同容器

• 制品管理：分析完成后，图表、报告和日志会上传至 Amazon S3。容器在运行一小时后会自动终止。

容器隔离保护了基础设施，但它无法控制代理生成的内容。验证器代理会重新验证计算结果。它无法检测上传数据中隐藏的提示注入指令，也无法筛查大型语言模型生成文本中可能存在的有害或无依据内容。对于生产环境部署，我们建议添加 Amazon Bedrock 防护措施作为负责任的人工智能控制手段：对用户提示和上传数据应用内容过滤和提示攻击检测，并对代理输出进行上下文关联性检查，确保报告文本始终基于源数据和验证过的计算结果。

2. 运维与监控：团队需要可见性

仅靠代码无法构建完整的生产系统。团队需要评估系统健康状况、诊断问题并审查结果，因此 Deep Insight 提供了 Web 界面和运维仪表板。

#### Web 界面 (deep-insight-web)

基于 FastAPI 的网页界面，通过 AgentCore 原生协议 (boto3.invoke_agent_runtime()) 与后端通信。用户上传数据并输入提示后，可通过服务器发送事件 (SSE) 流式传输监控进度。生成计划后，弹窗允许用户批准或提供修订反馈（人工干预）。完成的报告可直接下载。支持韩语和英语。

图 4：Deep Insight 网页版截图

#### 运维仪表板 (deep-insight-web/ops)

运维仪表板是可选组件。Deep Insight 即使不使用它也能正常运行，但它为需要的团队提供了以下功能：

• 任务追踪：所有分析任务指标（包括状态、令牌使用量和耗时）均记录在 Amazon DynamoDB 中。

• 故障告警：当分析失败时，会通过 Amazon SNS 立即向管理员发送电子邮件。

• 管理员仪表板：专用管理员仪表板通过 Amazon Cognito 的 JSON Web Token (JWT) 认证实现安全任务监控。

图 5：Deep Insight 运维仪表板截图

图 6：Deep Insight 运维仪表板详细视图

扩展 Deep Insight 架构

Deep Insight 的多代理架构不仅限于数据分析报告生成的单一领域。以下两个案例展示了分层编排设计原则在完全不同领域中的有效性。

案例 1：LG 电子：基于智能代理的人工智能营销洞察提取系统

LG 电子韩国销售部门基于与 Deep Insight 相同的多代理架构构建了 ChatInsight，解决了此前数据分析请求需要 2-3 周且市场人员与数据科学家之间意图丢失的问题。协调器按复杂度路由任务，规划器跟踪任务，监督器协调编码器和报告器，代理间状态通过 all_results.txt 文件逐步传递。原本需要 3 天的分析现在仅需 30 分钟，生产效率提升 288 倍。不懂 SQL 的市场人员现在可以让代理探索数据并提出策略（参见 AWS 技术博客上的 LG 电子智能代理人工智能洞察提取系统）。

图 7：LG 电子智能代理人工智能营销洞察系统架构

案例 2：TechRecon：人工智能驱动的技术侦察代理（re:Invent 2025）

在 AWS re:Invent 2025（会议编号 SNR203）上展示的 TechRecon 将 Deep Insight 的架构应用于技术战略。给定一家公司及其所属行业，研究员收集技术趋势，编码器进行分析，验证器进行验证，报告员生成技术图景分析和技术立场论文。该架构几乎与 Deep Insight 完全一致，使用 Strands Agents SDK 的图模式、扩展思维和提示缓存构建，研究员取代编码器成为主要执行代理。这表明该设计是一种通用模式：交换代理角色和提示内容，相同的编排结构可以解决完全不同的问题。

图 8：TechRecon 结果

（阅读更多：TechRecon GitHub | AWS re:Invent 会议视频）

结论

构建一个能够在生产环境中运行的代理，不取决于模型能力，而取决于架构设计。Deep Insight 提供了经过验证的解决方案：

• 工作流管理：Strands Agents SDK 的图模式定义了代理之间的执行顺序，实现了 HITL 分支逻辑，而代理即工具模式使监督者仅在需要时调用专用代理。

• 推理引擎：我们根据角色（Haiku、Opus、Sonnet）分配 Amazon Bedrock 的 Claude 模型，以优化成本和质量。

• 部署：Amazon Bedrock AgentCore 提供托管运行时，支持会话隔离、私有 VPC 部署和 OpenTelemetry 可观测性。

• 代码执行：应用负载均衡器加上 Fargate 上的 Amazon 弹性容器服务（Amazon ECS），在每会话临时沙箱容器中隔离 LLM 生成的代码执行，防止系统文件访问、资源耗尽和意外数据泄露等安全问题。

• 运维：Web 界面的 SSE 流式传输和运维仪表板（DynamoDB + Cognito + SNS）为整个团队提供可视化支持。

LG 电子的营销洞察系统和 re:Invent 2025 上的 TechRecon 案例验证了这些设计原则。

在第二部分中，我们将探讨基于该架构的上下文工程技巧的四个层级，从架构级隔离到提示设计、工具优化和验证保障，同时与 Anthropic 的工程研究进行对比。

Deep Insight 是开源项目。探索代码并将其扩展到您的领域。

• GitHub

• 工作坊：Deep Insight 工作坊（英文 | 韩文）

关于作者

'"`