AWS Deep Insight 如何解决多智能体系统的五大生产挑战

构建多智能体系统如今已相当简单。将其投入生产环境才是真正挑战的开始。得益于开源框架和云服务，你可以在几天内搭建起一个智能体。只需几次工具调用和几行提示词，你就能看到令人印象深刻的成果。但一旦团队试图从试点阶段过渡到实际业务应用，他们就会撞上一堵熟悉的墙。如果你曾尝试将智能体投入生产，这些挫败感听起来会很熟悉：

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

你调整提示词，增加更多示例，更换模型。同样的问题却反复出现。这是因为智能体并不遵循固定的指令序列。它们基于上下文做出自己的判断。仅靠指令是不够的。你需要设计智能体如何思考、何时验证，以及当出现问题时它该如何处理。这正是为什么仅仅进行提示工程是不够的，而必须设计智能体的整个认知架构和执行流程的原因。

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

博客系列概览

• 第一部分：多智能体系统中的 5 个生产挑战及 Deep Insight 的解决方案。
• 第二部分：超越上下文窗口：上下文工程技术及 Deep Insight 的应用。
• 第三部分：实践中的驾驭工程：将 Deep Insight 从开发环境迁移到生产环境。

这是三篇系列文章的第一部分。它定义了任何生产级多智能体系统必须解决的五个核心挑战，并展示了技术栈的每一层如何从 Strands Agents SDK 和 Amazon Bedrock 到 Amazon Bedrock AgentCore、Application Load Balancer 以及 AWS Fargate 来应对这些挑战。第二部分和第三部分将涵盖上下文工程和生产部署。

介绍 Deep Insight

Deep Insight 是一个多智能体系统，它将复杂的数据分析转化为自动化的洞察。给定一个 CSV 文件和一个自然语言提示，由一系列专业智能体（协调器、规划器、监督者、编码者、验证者、报告者和追踪者）组成的层级结构协同完成分析。它们共同加载数据、运行分析、生成图表、验证计算，并生成一份带有引用的专业报告（.docx）。

我们稍后将详细探讨其架构。首先，让我们看看它的实际运行效果。在演示中，我们输入了一家虚构食品公司 Yummy Food 的广告数据（yummy-food-market.csv）以及一个列定义文件（column_definitions.json），并提供提示：从销售和营销角度分析此数据，生成图表和洞察，并制作一份 .docx 报告。 Deep Insight 会生成一个分析计划，将其提交给用户审批，并在获得批准后执行分析。

接下来的 Deep Insight 网络演示视频 展示了完整的工作流程，从上传数据、审查分析计划到实时流式传输和下载完成的报告。

我该如何试用？

Deep Insight 已在 GitHub 上开源，并附有完整的设置指南，提供从开发到生产的三种部署选项。

第一种是 自托管版本，通过 CLI 在本地运行。它针对快速迭代进行了优化，允许对每个智能体、提示词和工作流进行代码级访问。设置大约需要 10 分钟，非常适合开发。（YouTube 上提供了自托管演示视频。）

第二种是 Web 版本，一个基于浏览器的用户界面，用于上传数据、审查分析计划（人在回路，或 HITL）以及下载报告，全程无需编写代码，使其对非开发人员易于访问。（前面的演示视频展示了 Web 版本的实际运行。）

第三种是 托管 AgentCore 版本，一种由 Amazon Bedrock AgentCore 驱动的生产部署选项，这是一个用于大规模构建、连接和优化智能体的平台，支持任何框架或模型。此版本将智能体部署在 AgentCore 运行时上，这是 Amazon Bedrock AgentCore 的一项功能。系统完全在私有虚拟私有云 (VPC) 内运行，自定义代码解释器单独托管在 AWS Fargate 上，智能体在隔离的每用户环境中并发运行。当您需要会话隔离和私有 VPC 部署时，这是正确的选择。第 3 部分详细涵盖了其部署和运维。

所有三个版本共享相同的多智能体架构，因此在开发中验证过的智能体可以原样部署到生产环境。

解决方案概述

构建生产级多智能体系统不仅需要良好的提示词。你需要正确的技术栈和基础设施来解决智能体如何协作、如何推理、如何部署、在哪里安全执行代码以及如何监控运营健康状况等问题。Deep Insight 解决了这五个关键领域的问题。由于智能体生成代码和报告内容，我们在“解决方案详情 2”中还涵盖了生产环境中的负责任 AI 控制。

以下架构图（图 1）直观地展示了这一点。绿色方框代表 Strands Agents 多智能体结构，它解决了前表中提到的挑战 1 和 2。我们将在接下来的“解决方案详情 1：多智能体系统设计”部分中详细介绍。图中显示的其余基础设施组件解决了挑战 3、4 和 5，我们将在“解决方案详情 2：生产部署与运维”中逐一讲解。

图 1：解决方案架构

解决方案详情 1：多智能体系统设计

Deep Insight 采用多智能体架构，其中八个智能体协作以产出一份高质量的交付物。每个智能体在其独立的上下文中工作，仅执行其专门任务，并仅将压缩后的结果传递下去。

图 2：多智能体结构

协调器（Coordinator）路由用户请求，规划器（Planner）将任务分解为离散步骤，计划审查者（Plan Reviewer）收集用户反馈，监督者（Supervisor）根据计划调用相应的专门智能体。编码器（Coder）编写并执行数据分析代码，验证器（Validator）验证计算，报告生成器（Reporter）生成最终报告，跟踪器（Tracker）跟踪进度。我们将在三个层面解释这一点：

• [第一层] 协调器到规划器到计划审查者：请求分析和执行计划创建。
• [第二层] 监督者：专门智能体编排。
• [第三层] 编码器、验证器、报告生成器、跟踪器：专门任务执行。

Strands Agents SDK 中的两个关键模式相结合，以控制这些智能体之间的执行流程。首先，图模式（Graph pattern）将智能体的执行顺序和流程定义为有向图。请求流经协调器、规划器、计划审查者，然后是监督者，并包含一个在修订请求时循环回到规划器的条件分支。通过条件确定下一步，使得 HITL（人机协同）和错误处理等复杂工作流变得简单明了。其次，智能体即工具模式（Agents-as-Tools pattern）允许监督者仅在需要时将专门智能体（编码器、验证器、报告生成器、跟踪器）作为工具调用。每个智能体在独立的上下文中工作并仅返回结果，在保留领域专业知识的同时最小化上下文使用。

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

[第一层] 协调器到规划器到计划审查者

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

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

协调器是用户请求的入口点。它直接处理基本问候，并将数据分析等复杂任务路由到规划器，并带有 handoff_to_planner 标记。

关键设计决策是模型选择：由于协调器仅进行分类，它使用轻量级的 Claude Haiku，避免在基本问候上产生 Opus 级别的成本，并提供快速响应。

# builder.py: conditional edges for routing decisions
builder.set_entry_point("coordinator")
builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner)

路由条件来自协调器的提示词：任何需要工具、推理或多步思考的请求都路由到规划器。

1.2 规划器（计划创建）：复杂分析在执行前需要分解

在 Deep Insight 的多智能体结构中，Planner 智能体承担着在智能体之间分配任务的关键角色。在实质性工作开始之前，它会将大任务分解为较小的步骤，每个专用智能体依次执行这些步骤，从而保持每个智能体的上下文较小。

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

## title
Yummy Food Consumer Purchase Patterns and Advertising Effectiveness Analysis Report

## steps

### 1. Coder: Comprehensive Data Analysis and Insight Generation
- [ ] Load all data files from './data/*' path and understand structure
- [ ] Analyze consumer purchase history (patterns, preferences, customer segments)
- [ ] Analyze advertising data by channel (cost, effectiveness, channel comparison)
- [ ] Category-level analysis (fresh food, convenience food, health food ad effectiveness)
- [ ] Calculate key business metrics (conversion rate, CPA, ROAS, etc.)
- [ ] Generate visualizations (5+ charts, consumer segment charts)
- [ ] Derive strategic marketing insights
- [ ] Generate calculation metadata (for validation)

### 2. Validator: Calculation Verification and Citation Metadata Generation
- [ ] Identify verification targets and extract filter calculations
- [ ] Load data files directly and perform recalculations
- [ ] Verify accuracy of per-channel performance metrics
- [ ] Validate data consistency of visuals and graphs
- [ ] Generate citation metadata (reference numbers for verified items)

### 3. Reporter: Marketing Analysis Report Generation
- [ ] Write report overview
- [ ] Create structured report using verified analysis results
- [ ] Insert visualizations and analysis sections
- [ ] Present marketing strategy recommendations and improvement proposals
- [ ] Generate professional marketing report in DOCX format

1.3 计划审查者（Plan Reviewer）

Plan Reviewer 是一个 HITL 节点，它向用户展示计划并收集批准或修改反馈。如果有反馈，它会返回给 Planner 以修改计划。如果获得批准，它会将任务移交给 Supervisor。设置了最大修改次数（MAX_PLAN_REVISIONS）以防止无限循环。

# builder.py: Plan Reviewer's bidirectional conditional edges
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)

在 Web 版本中，Plan Reviewer 显示一个浏览器模态框，用户在其中阅读计划并批准或输入修改反馈。如果 300 秒倒计时内没有收到响应，系统将自动批准该计划。

图 3：Web UI 中 Plan Reviewer 智能体的执行

没有规划时，智能体在运行时决定一切，中途修正会使之前的工作失效，且用户无法查看进度。有了 Planner 和 Plan Reviewer，用户可以审查和修改计划，实时监控进度，并仅重新执行失败的步骤。

[第 2 层] Supervisor（编排器）：专用智能体需要指挥者

Supervisor 按顺序执行 Planner 的 full_plan，通过 Tool Use 调用注册在其上的第 3 层智能体（Coder、Validator、Reporter、Tracker）作为工具。

# nodes.py: registering sub-agents as tools on the Supervisor
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,
)

Supervisor 的系统提示词定义了严格的工作流规则：

• 强制执行顺序：Coder、Tracker、Validator、Tracker、Reporter、Tracker：每个智能体运行后，调用 Tracker 以跟踪进度，使 Supervisor 能够管理整体任务状态。
• 部分完成规则：在当前智能体的所有清单项目被标记为 [x] 之前，Supervisor 不会移动到下一个智能体。
• 上下文保留：Supervisor 将 clues 和 full_plan 变量传递给每个工具智能体，保持完整上下文并防止信息丢失。

[第 3 层] Coder、Validator、Reporter、Tracker：分工驱动质量

每个第 3 层智能体（Coder、Validator、Reporter、Tracker）都被封装为 PythonAgentTool，并接收来自 Supervisor 的 Tool Use 调用。每个智能体都在 Strands SDK 中作为独立的 Agent() 实例创建，拥有自己的系统提示词、模型 ID 和工具集。

Supervisor 基于 Planner 的清单按此顺序调用 Tool Use：

1. Coder – 加载数据，编写并运行分析代码，生成 PNG 图表，在 all_results.txt 中累积结果，并留下 calculation_metadata.json 以供验证。
2. Tracker（第 1 遍）– 将已完成的清单项目从 [ ] 更新为 [x]，Supervisor 据此决定是否继续。
3. 验证器 – 从源数据重新执行 calculation_metadata.json 中的每项计算。误差在 0.01 以内视为通过，不匹配项会被标记。已验证的计算结果将提交给 citations.json，供报告员引用。
4. 跟踪器（第二遍）– 在检查清单中反映验证器的完成状态。
5. 报告员 – 读取 all_results.txt 和 citations.json，生成最终 DOCX 报告，提供带引用和不带引用两个版本。
6. 跟踪器（第三遍）– 反映所有任务的最终完成状态。

跟踪器在每个智能体之后运行，以便主管跟踪进度并强制执行完成规则（在所有项目标记为 [x] 之前不得继续）。由于它使用 LLM 推理更新检查清单且不使用工具，因此几乎不增加开销。

每个智能体的 LLM 模型配置

Deep Insight 根据每个智能体的角色定制模型和设置。这不是模型选择，而是优化成本和质量的架构决策。

主管、编码员和报告员智能体使用提示缓存来缓存其系统提示和工具定义，在重复调用时可将输入 token 成本降低多达 90%。协调器仅运行一次，而验证器和跟踪器每次运行时的上下文不同，因此对它们而言缓存无效并保持禁用。这种选择性缓存策略是刻意的成本/性能权衡。

解决方案详情 2：生产部署与运维

如果解决方案详情 1 定义了系统做什么，那么本节定义了它在何处以及如何安全运行。从本节开始，所有内容都涵盖生产运维的基础设施决策。具体而言，本节涵盖 LLM 生成代码的安全执行环境，以及团队的操作可见性。

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

Coder 智能体编写并运行 Python 代码以进行数据分析。在自托管版本中，它通过 subprocess.run() 在本地运行，但在生产环境（AgentCore）中，安全性和隔离性至关重要。直接在生产服务器上运行由 LLM 生成的代码存在风险：模型可能会删除系统文件、在无限循环中耗尽资源，或访问其他用户的分析数据。Deep Insight 通过在 AWS Fargate 和 ALB 上为每个会话创建临时容器来解决这一问题。这些组件并非孤立运行。如图 1 所示，AgentCore 运行时、ALB 和 Fargate 任务都运行在同一个私有 VPC 内部。VPC 端点将它们连接到 Amazon Simple Storage Service (Amazon S3)、Amazon Bedrock 和 Amazon Elastic Container Registry (Amazon ECR)，而无需经过公共互联网。安全组限制了哪些组件可以访问 Code Interpreter 容器。AWS Identity and Access Management (IAM) 角色将每个组件的作用范围限定为其所需的 AWS 资源。Amazon CloudWatch 从 AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）收集容器日志和可观测性数据。

• 自定义容器 Docker 镜像：一个预优化的沙箱，包含多智能体系统所需的字体、系统库和 Python 包。
• 容器隔离：每个分析会话都在一个私有 VPC 子网中获得一个独立的 Fargate 容器，该容器没有直接的互联网访问权限。
• 两步执行：LLM 生成的代码经过 base64 编码，通过 HTTP 发送，写入文件（步骤 1），然后通过 subprocess 执行（步骤 2）。
• 会话亲和性：ALB 粘性会话 Cookie 将智能体路由回同一个容器，即使它多次执行代码也是如此。
• 工件管理：当分析完成时，图表、报告和日志会上传到 Amazon S3。容器在一小时后自动终止。

容器隔离保护了基础设施，但它并不管控智能体生成的内容。Validator 智能体会重新验证计算结果。它无法检测隐藏在上传数据中的提示注入指令，也无法筛选 LLM 生成的有害或无依据的文本。对于生产部署，我们建议添加 Amazon Bedrock Guardrails 作为负责任的 AI 控制措施：对用户提示和上传数据应用内容过滤和提示攻击检测，并对智能体输出应用上下文依据检查，以确保报告文本基于源数据和已验证的计算结果。

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

仅靠代码无法构成一个完整的生产系统。团队必须评估系统健康状况、诊断问题并审查结果，因此 Deep Insight 提供了一个 Web UI 和一个运维（Ops）仪表板。

Web UI (deep-insight-web)

一个基于 FastAPI 的 Web 界面，通过 AgentCore Native Protocol (boto3.invoke_agent_runtime()) 与后端通信。用户上传数据并输入提示，然后通过 Server-Sent Events (SSE) 流监控进度。当计划生成后，一个模态框允许用户批准或提供修改反馈（HITL）。完成的报告可以直接下载。支持韩语和英语。

图 4：Deep Insight Web 版本截图

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

运维仪表板是可选的。Deep Insight 在没有它的情况下也能正常运行，但它为有需要的团队增加了以下功能：

• 任务跟踪：所有分析任务指标，包括状态、Token 使用量和耗时，都记录在 Amazon DynamoDB 中。
• 故障告警：当分析失败时，会通过 Amazon SNS 立即向管理员发送电子邮件。
• 管理仪表盘：一个专用的管理仪表盘通过 Amazon Cognito 的 JSON Web Token (JWT) 认证进行保护，以实现安全的任务监控。

图 5：Deep Insight Ops 仪表盘截图

图 6：Deep Insight Ops 仪表盘详细视图

扩展 Deep Insight 架构

Deep Insight 的多智能体架构并不局限于数据分析报告生成这一单一领域。以下两个示例表明，分层编排设计原则在完全不同的领域中依然有效。

案例 1：LG Electronics：基于 Agentic AI 的营销洞察提取系统

LG Electronics 韩国销售部门基于与 Deep Insight 相同的多智能体架构构建了 ChatInsight，此前数据分析请求需要 2-3 周时间，且营销人员与数据科学家之间的意图容易丢失。Coordinator 根据复杂度进行路由，Planner 跟踪任务，Supervisor 编排 Coder 和 Reporter，智能体间的状态通过 all_results.txt 文件累积传递。原本需要 3 天的分析现在只需 30 分钟，生产力提升了 288 倍。不懂 SQL 的营销人员可以让智能体探索数据并提出策略（参见 AWS 技术博客上的 LG Electronics Agentic AI 洞察提取系统）。

图 7：LG Electronics Agentic AI 营销洞察系统架构

案例 2：TechRecon：AI 驱动的技术侦察智能体（re:Invent 2025）

在 AWS re:Invent 2025（场次 SNR203）上展示的 TechRecon 将 Deep Insight 的架构应用于技术战略。给定一家公司和行业，Researcher 收集技术趋势，Coder 进行分析，Validator 进行验证，Reporter 生成 Landscape Analysis（格局分析）和 Technical Position Paper（技术立场文件）。该架构与 Deep Insight 几乎相同，使用 Strands Agents SDK 的 Graph 模式以及 Extended Thinking 和 Prompt Caching 构建，其中 Researcher 取代 Coder 成为主要执行智能体。这表明该设计是一种通用模式：只需替换智能体的角色和提示词，相同的编排结构就能解决完全不同的问题。

图 8：TechRecon 结果

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

结论

构建一个能在生产环境中运行的智能体，关键不在于模型能力，而在于架构。Deep Insight 提供了一个经过验证的答案：

• 工作流管理：Strands Agents SDK 的 Graph 模式定义了智能体之间的执行顺序并实现了 HITL 分支，而 Agents-as-Tools 模式允许 Supervisor 仅在需要时调用专用智能体。
• 推理引擎：我们根据角色分配来自 Amazon Bedrock 的 Claude 模型（先是 Haiku，然后是 Opus，最后是 Sonnet），以优化成本和质量。
• 部署：Amazon Bedrock AgentCore 提供托管运行时，支持会话隔离、私有 VPC 部署和 OpenTelemetry 可观测性。
• 代码执行：Application Load Balancer 加上运行在 Fargate 上的 Amazon Elastic Container Service (Amazon ECS)，在按会话划分的临时沙箱容器中隔离 LLM 生成的代码执行，防止系统文件访问、资源耗尽和意外数据泄露等安全问题。
• 运维：Web UI 的 SSE 流传输和 Ops 仪表盘（DynamoDB + Cognito + SNS）为整个团队提供了可见性。

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

在第二部分中，我们探讨了四种上下文工程（Context Engineering）技术层级，用于在基于该架构的基础上克服上下文窗口限制，涵盖从架构级隔离到提示词设计、工具优化以及验证保障措施，并将我们的方法与 Anthropic 的工程研究进行了比较。

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

• GitHub
• 研讨会：Deep Insight 研讨会（英语 | 韩语）

关于作者

Yoonseo Kim

Yoonseo 是一名解决方案架构师，利用 AWS 技术帮助客户解决业务挑战。她对 AI/ML 有着浓厚的兴趣，专注于帮助客户设计和优化智能体 AI 工作负载，以及支持基础设施和评估环境。

Jesam Kim

Jesam 是一名解决方案架构师，帮助企业客户采用云技术并解决业务挑战。他专注于 AI/ML，包括推荐系统和生成式 AI，帮助客户设计满足其业务需求的架构。

Jiyun Park

Jiyun 是一名解决方案架构师，帮助软件和互联网行业的客户将其工作负载迁移到云端。她与客户合作设计云解决方案，帮助他们实现业务目标。

Kyutae Park

Kyutae，博士 是一名 AI 专家解决方案架构师，帮助跨行业的客户设计和构建应用 AI 工作负载，凭借在机器学习、MLOps 和智能体 AI 方面的丰富经验。他专注于通过智能体 AI 实现智能自动化和运营创新，将自主决策和多智能体协作架构引入现实商业环境。通过这项工作，他帮助客户利用 AWS AI/ML 服务和应用生成式 AI 实现切实的业务成果，并建立可持续的竞争优势。

Gonsoo Moon

Gonsoo 是 AWS 的 AI/ML 专家解决方案架构师。凭借在多种 AI/ML 用例和生产部署方面的经验，他与客户密切合作，解决他们的 AI/ML 挑战。他还与数据科学家、开发人员和分析师分享 AI/ML 知识，旨在为韩国及世界各地的积极变革做出贡献。

Chloe Kwak

Chloe 是 Amazon Web Services 韩国零售团队的资深解决方案架构师。她帮助韩国的零售和电商客户设计可扩展、成本效益高的云架构，并采用 AI/ML 服务以加速其业务成果。