多智能体系统中的5个生产挑战以及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 在本地运行。它针对快速迭代进行了优化，可完全在代码层面访问每一个 agent、提示词和工作流。它大约 10 分钟即可完成设置，因此非常适合开发。（Self-Hosted 演示视频可在 YouTube.)

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

第三种是 Managed 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层] 协调器 → 规划器 → 计划审核员：请求分析与执行计划创建。
• [第2层] 监督器：专业化智能体编排。
• [第3层] 编码器、验证器、报告器、跟踪器：专业化任务执行。

来自 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：Web UI 中 Plan Reviewer 代理的执行

如果没有规划，代理会在运行时决定一切，中途修正会使之前的工作失效，而且用户对进度没有可见性。有了 Planner 和 Plan Reviewer，用户可以审查和修订计划、实时监控进度，并仅重新执行失败的步骤。

[第 2 层] Supervisor（编排器）：专用代理需要一位指挥

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

# 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 在每个 agent 之后运行，以便 Supervisor 跟踪进度并执行完成规则（在所有项均为 [x] 之前不得继续）。由于它仅通过 LLM 推理更新清单且不使用工具，因此几乎不增加开销。

每个 agent 的 LLM 模型配置

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

监督者、编码器和报告器智能体使用 Prompt Caching 缓存其系统提示词和工具定义，将重复调用的输入 token 成本最多降低 90%。协调器只运行一次，验证器和追踪器每次运行时上下文都不同，因此缓存对它们无效，保持禁用。这种选择性缓存策略是深思熟虑的成本/性能权衡。

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

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

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

Coder agent 编写并运行 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 从 Amazon Bedrock AgentCore 的一项能力 AgentCore Observability 收集容器日志和可观测性数据。

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

容器隔离保护的是基础设施，但它并不管控行智能体生成的内容。Validator agent 会重新验证计算。它无法检测隐藏在上传数据中的提示词注入指令，也无法筛查 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(分会议 SNR203)上展示的 TechRecon 将 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 流式传输和运维仪表板(DynamoDB + Cognito + SNS)为整个团队提供了全面的可见性。

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

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

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

• GitHub
• 研讨会:Deep Insight Workshop(英语 | 韩语)

关于作者