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

构建多智能体系统如今已经相当简单。真正的挑战始于将其投入生产。得益于开源框架和云服务，你可以在几天内搭建一个智能体。几次工具调用、几行提示词，就能得到一个看起来令人印象深刻的东西。但当团队试图超越试点、进入真实业务应用时，就会撞上那堵熟悉的墙。如果你曾尝试把智能体投入生产，这些挫折听起来会很熟悉：

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

你调整提示词、增加更多示例、更换模型。同样的问题却不断重现。这是因为智能体并不遵循固定的指令序列。它们会根据上下文自行做出判断。仅有指令是不够的。你需要设计智能体如何思考、何时进行验证，以及出错时该怎么做。正因如此，不能只停留在提示词工程，而要设计智能体的整体认知架构与执行流程，这一点已变得至关重要。

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

博客系列概览

• 第 1 篇：多智能体系统的 5 个生产挑战，以及 Deep Insight 如何解决它们。
• 第 2 篇：超越上下文窗口：Context Engineering 技术，以及 Deep Insight 如何应用它们。
• 第 3 篇：实践中的 Harness 工程：将 Deep Insight 从开发推向生产。

这是三篇系列中的第 1 篇。它定义了任何生产级多智能体系统都必须解决的五个核心挑战，并展示技术栈的每一层如何应对这些挑战，从 Strands Agents SDK 和 Amazon Bedrock 到 Amazon Bedrock AgentCore、Application Load Balancer 和 AWS Fargate。第 2 篇和第 3 篇涵盖 Context Engineering 与生产部署。

介绍 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 上开源，并附有完整的安装指南，提供从开发到生产的三种部署选项。

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

第二种是 网页版，这是一个基于浏览器的界面，用于上传数据、审阅分析计划（人在回路，即 HITL）以及下载报告，全程无需编写代码，便于非开发人员使用。（前面的演示视频展示了网页版的实际操作。）

第三种是 托管式 AgentCore 版本，这是由 Amazon Bedrock AgentCore 提供支持的生产部署选项。Amazon Bedrock AgentCore 是一个可大规模构建、连接和优化智能体的平台，支持任意框架或模型。该版本将智能体部署在 AgentCore runtime 上，这是 Amazon Bedrock AgentCore 的一项能力。系统完全运行在私有虚拟私有云（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 跟踪进度。我们将分三层加以说明：

• [第 1 层] 从 Coordinator 到 Planner 再到 Plan Reviewer：请求分析与执行计划创建。
• [第 2 层] Supervisor：专用智能体编排。
• [第 3 层] Coder、Validator、Reporter、Tracker：专用任务执行。

来自 Strands Agents SDK 的两种关键模式被结合起来，以控制这些智能体之间的执行流。首先，Graph 模式将智能体的执行顺序与流程定义为有向图。请求依次流经 Coordinator、Planner、Plan Reviewer，然后到达 Supervisor，并在收到修订请求时通过条件分支回环到 Planner。按条件决定下一步，使 HITL 和错误处理等复杂工作流变得简单直接。其次，Agents-as-Tools 模式让 Supervisor 仅在需要时将专用智能体（Coder、Validator、Reporter、Tracker）作为工具调用。每个智能体在独立上下文中工作并只返回结果，从而在保留领域专长的同时尽量降低上下文占用。

本节说明该架构如何解决路由、规划与编排问题。

[第 1 层] 从 Coordinator 到 Planner 再到 Plan Reviewer

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

1.1 Coordinator（路由）：并非每个请求都需要高成本的编排

Coordinator 是用户请求的入口。它直接处理基本问候，并将数据分析等复杂任务连同 handoff_to_planner 标记路由到 Planner。

关键的设计决策在于模型选择：由于 Coordinator 只做分类，它使用轻量级的 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)

路由条件来自 Coordinator 的提示词：任何需要工具、推理或多步思考的请求都会交给 Planner。

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

在 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：Plan Reviewer 智能体在 Web UI 中的执行

如果没有规划，智能体会在运行时决定一切，中途修正会使先前的工作失效，用户也无法了解进度。有了 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. 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 runtime、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 容器。
• 2 步执行：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 版截图

Ops 仪表板 (deep-insight-web/ops)

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 Tech Blog 上的 LG Electronics Agentic AI Insight Extraction System）。

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

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

该方案在 AWS re:Invent 2025（session 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 案例验证了这些设计原则。

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

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

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

关于作者

Yoonseo Kim

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

Jesam Kim

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

Jiyun Park

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

Kyutae Park

Kyutae，Ph.D. 是一名 AI 专家解决方案架构师，凭借在机器学习、MLOps 和智能体 AI 方面的丰富经验，帮助各行业客户设计并构建应用型 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 服务以加速实现其业务成果。