AWS 开源多智能体系统 Deep Insight，详解五大生产化挑战及解法

构建多智能体系统如今已相当简单，但将其推向生产环境才是真正挑战的开始。得益于开源框架和云服务，你可以在几天内搭建出一个智能体。几次工具调用、几行提示词，你就有了一个看起来很令人印象深刻的东西。但一旦团队试图从试点项目迈向真正的业务应用，就会撞上一堵熟悉的墙。如果你曾尝试将智能体投入生产，这些挫折感你一定不会陌生：

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

你调整提示词、添加更多示例、更换模型。但同样的问题反复出现。这是因为智能体并不遵循固定的指令序列，而是根据上下文自行做出判断。仅有指令是不够的。你需要设计智能体的思考方式、何时进行验证，以及出现问题时该怎么做。这正是为什么仅仅依靠提示词工程已经不够，还必须设计智能体的完整认知架构和执行流程，这已变得至关重要。

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

博客系列概览

• 第 1 部分：多智能体系统的 5 大生产挑战以及 Deep Insight 如何解决它们。
• 第 2 部分：超越上下文窗口：上下文工程技术以及 Deep Insight 如何应用它们。
• 第 3 部分：Harness 工程实践：将 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 会生成一个分析计划，提交给用户审批，审批通过后即执行分析。

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

如何试用？

Deep Insight 已在 GitHub 上开源，附有完整的搭建指南，并提供三种部署选项，覆盖从开发到生产的场景。

第一种是自托管（Self-Hosted）版本，通过 CLI 在本地运行。它针对快速迭代进行了优化，可以对每个智能体、提示词和工作流进行完整的代码级访问。大约 10 分钟即可完成搭建，因此非常适合开发。（自托管版本的演示视频可在 YouTube 上观看。）

第二种是网页（Web）版本，一个基于浏览器的 UI，用于上传数据、审阅分析计划（Human-in-the-Loop，即 HITL）以及下载报告，全程无需编写代码，让非开发人员也能轻松使用。（前面的演示视频展示的就是网页版。）

第三种是托管的 AgentCore 版本，这是一个生产部署选项，由 Amazon Bedrock AgentCore 提供支持。Amazon Bedrock AgentCore 是一个可以使用任意框架或模型来大规模构建、连接和优化智能体的平台。此版本将智能体部署在 Amazon Bedrock AgentCore 的一项能力——AgentCore runtime 上。整个系统完全运行在私有虚拟私有云（VPC）内，一个自定义 Code Interpreter 单独托管在 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 模式将有向图形式的执行顺序和智能体流程定义下来。请求依次流向协调器、规划器、计划审查器，然后到达监督器，当收到修改请求时，条件分支会回跳到规划器。通过条件判断下一步，使 HITL 和错误处理等复杂工作流变得简单直接。其次，Agents-as-Tools 模式让监督器仅在需要时将专门智能体（编码器、验证器、报告器、跟踪器）作为工具调用。每个智能体都在独立的上下文中工作，只返回结果，在保留领域专业知识的同时最大限度地减少上下文使用。

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

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

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

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，用户可以审查和修订计划、实时监控进度，并只重新执行失败的步骤。

[第二层] Supervisor（编排者）：专业智能体需要一个指挥者

Supervisor 按顺序执行 Planner 的 full_plan，通过注册在其上的 Tool Use 工具调用第三层智能体（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 变量传递给每个工具智能体，以维护完整上下文并防止信息丢失。

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

每个第三层智能体（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（第一轮）– 将已完成的清单项从 [ ] 更新为 [x]，Supervisor 依此决定是否继续执行。
3. Validator（验证器）——基于源数据重新执行 calculation_metadata.json 中的每一项计算。误差在 0.01 以内视为通过，不匹配则被标记。已验证的计算送入 citations.json，供 Reporter 引用。
4. Tracker（追踪器，第 2 轮）——在检查清单中反映 Validator 的完成状态。
5. Reporter（报告器）——读取 all_results.txt 和 citations.json，生成最终 DOCX 报告的两个版本：带引用和不带引用。
6. Tracker（追踪器，第 3 轮）——反映所有任务的最终完成状态。

Tracker 在每个智能体运行之后执行，以便 Supervisor 追踪进度并强制执行完成规则（在所有条目都变为 [x] 之前不得继续）。由于它仅通过 LLM 推理更新检查清单且不使用工具，几乎不增加开销。

按智能体配置 LLM 模型

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

Supervisor、Coder 和 Reporter 智能体使用 Prompt Caching 缓存其系统提示词和工具定义，在重复调用时最多可将输入 token 成本降低 90%。Coordinator 只运行一次，Validator 和 Tracker 每次运行时的上下文都不同，因此缓存对它们无效，保持禁用。这种选择性缓存策略是经过深思熟虑的成本/性能权衡。

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

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

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

Coder 智能体编写并运行 Python 来进行数据分析。在 Self-Hosted 版本中，它通过 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 和一个运维仪表板。

Web UI（deep-insight-web）

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

图 4：Deep Insight 网页版截图

运维仪表板（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 的多智能体架构并不仅限于数据分析报告生成这一单一领域。以下两个示例表明，分层编排设计原则在完全不同的领域同样有效。

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

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

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

TechRecon 在 AWS re:Invent 2025 上发布（分场会议 SNR203），将 Deep Insight 的架构应用于技术战略。给定一家公司和行业，Researcher 收集技术趋势，Coder 进行分析，Validator 进行验证，Reporter 输出一份格局分析报告和一份技术定位报告。该架构与 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 电子的营销洞察系统以及 re:Invent 2025 上的 TechRecon 案例验证了这些设计原则。

在第 2 部分中，我们将在此架构基础上，探讨用于克服上下文窗口限制的四层上下文工程技术——从架构级隔离到提示词设计、工具优化和验证防护措施——并将我们的方法与 Anthropic 的工程研究进行比较。

Deep Insight 是开源的。欢迎探索代码并为自己的领域进行扩展。

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

关于作者