多智能体系统的五个生产挑战，以及 Deep Insight 如何解决

#多智能体系统的五个生产挑战，以及 Deep Insight 如何解决

构建一套多智能体系统现在相当直接。把它送上生产，真正的挑战才开始。得益于开源框架和云服务，你可以在几天内搭起一个智能体。几次工具调用、几行提示，你就有了看起来令人印象深刻的东西。但当团队试图越过试点、进入真实业务应用时，他们会撞上熟悉的墙。如果你曾经试过把智能体放进生产，这些挫折会很耳熟：

为什么智能体不遵循我们的业务逻辑、跳过校验步骤，或者抓不住边界情况？

你调整提示，增加更多例子，换掉模型。同样的问题不断回来。那是因为智能体不遵循固定的指令序列。它们根据上下文自己做判断。单靠指示不够。你需要设计智能体如何思考、何时核验，以及出错时做什么。这正是为什么已经变得关键的，是超越单独的提示工程，去设计智能体的整套认知架构和执行流。

为了正面处理这些挑战，AWS 解决方案架构团队构建了 Deep Insight，一套生产级多智能体系统。在这个系列文章中，我们分享团队在构建 Deep Insight 时亲身学到的东西，跨三篇文章。我们将走过如何在真实生产环境中应用 Anthropic 提出的上下文工程（Context Engineering）技术（多智能体架构、结构化笔记、人在回路，以及更多）。我们也会覆盖沿途遇到的取舍（附代码），以及在 AWS 上部署和运行这个智能体所获得的运维洞察。

系列概览

• 第 1 篇：多智能体系统的五个生产挑战，以及 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 Web 演示视频 展示完整工作流，从上传数据和审阅分析计划，到实时流式输出和下载完成的报告。

我如何试用？

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

第一种是 自托管版本，通过命令行在本地运行。它为快速迭代而优化，对每个智能体、提示和工作流都有完整的代码级访问。大约 10 分钟可以搭好，因此很适合开发。（自托管演示视频在 YouTube。）

第二种是 Web 版本，基于浏览器的界面，用于上传数据、审阅分析计划（人在回路，Human-in-the-Loop，HITL）和下载报告，全程不写代码，因此非开发者也能用。（前面的演示视频展示的就是 Web 版本。）

第三种是 托管 AgentCore 版本，由 Amazon Bedrock AgentCore 驱动的生产部署选项。AgentCore 是一个用来大规模构建、连接和优化智能体的平台，不限定框架或模型。这一版本把智能体部署在 AgentCore 运行时上，运行时是 Amazon Bedrock AgentCore 的一项能力。系统完全运行在私有虚拟私有云（virtual private cloud, VPC）内，定制的代码解释器单独托管在 AWS Fargate 上，智能体在按用户隔离的环境中并发运行。当你需要会话隔离和私有 VPC 部署时，这是合适的选择。第 3 篇详细覆盖它的部署和运维。

三者共享同一套多智能体架构，因此在开发中校验过的智能体可以原样部署到生产。

方案概览

构建生产级多智能体系统，不只是好的提示。你需要合适的技术栈和基础设施，以处理智能体如何协作、如何推理、如何部署、在哪里安全执行代码，以及如何监控运行健康。Deep Insight 在这五个关键领域解决问题。因为智能体既生成代码也生成报告内容，我们还在方案细节 2 中覆盖生产所需的负责任人工智能控制。

下面的架构图（图 1）一眼说明这一点。绿色方框代表 Strands Agents 多智能体结构，对应上表中的挑战 1 和 2。我们将在即将到来的“方案细节 1：多智能体系统设计”一节详细覆盖。图中其余基础设施组件对应挑战 3、4 和 5，我们将在“方案细节 2：生产部署与运维”中走过。

图 1：方案架构

方案细节 1：多智能体系统设计

Deep Insight 使用多智能体架构，其中八个智能体协作产出一份高质量交付物。每个智能体在自己独立的上下文中工作，只做自己的专门任务，并且只把压缩后的结果传递下去。

图 2：多智能体结构

协调者路由用户请求，规划者把任务拆成离散步骤，计划审阅者收集用户反馈，主管按计划调用合适的专门化智能体。编码者编写并执行数据分析代码，校验者核验计算，报告者生成最终报告，跟踪者跟踪进度。我们将分三层说明：

• ［第 1 层］协调者到规划者到计划审阅者：请求分析与执行计划创建。

• ［第 2 层］主管：专门化智能体编排。

• ［第 3 层］编码者、校验者、报告者、跟踪者：专门任务执行。

来自 Strands Agents SDK 的两种关键模式被组合起来，以控制这些智能体之间的执行流。首先，图模式 把智能体的执行顺序和流向定义为有向图。请求流经协调者、规划者、计划审阅者，然后到主管，并有一条条件分支在修订请求时回到规划者。按条件决定下一步，使 HITL 和错误处理这类复杂工作流变得直接。其次，智能体即工具模式 让主管只在需要时把专门化智能体（Coder、Validator、Reporter、Tracker）作为工具调用。每一个都在独立上下文中工作并只返回结果，在保留领域专长的同时尽量少用上下文。

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

［第 1 层］协调者到规划者到计划审阅者

这一层把用户请求变成一份已批准的执行计划。

#### 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 的多智能体结构中，规划者智能体承担把任务分发给各智能体的关键角色。在实质工作开始之前，它把大任务拆成更小的步骤，每个专门化智能体一次执行一步，使每个智能体的上下文保持很小。

规划者使用打开了扩展思考（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 计划审阅者

计划审阅者是一个 HITL 节点，把计划呈现给用户并收集批准或修订反馈。如果有反馈，它回到规划者修订计划。如果批准，它把任务交给主管。设置了最大修订次数（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 版本中，计划审阅者显示一个浏览器模态框，用户在其中阅读计划并批准，或输入修订反馈。300 秒倒计时在没有响应时自动批准计划。

图 3：Web 界面中计划审阅者智能体的执行

没有规划时，智能体在运行时决定一切，中途修正会使先前工作失效，用户也看不到进度。有了规划者和计划审阅者，用户可以审阅并修订计划，实时监控进度，并且只重新执行失败的那一步。

［第 2 层］主管（编排者）：专门化智能体需要一个指挥

主管按顺序执行规划者的 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,
)

主管的系统提示定义严格的工作流规则：

• 强制执行顺序：Coder、Tracker、Validator、Tracker、Reporter、Tracker：每个智能体运行之后都调用 Tracker 来跟踪进度，让主管管理整体任务状态。

• 章节完成规则：在当前智能体的全部检查清单项被标为 [x] 之前，主管不进入下一个智能体。

• 上下文保留：主管把线索和 full_plan 变量传给每个工具智能体，保持完整上下文并防止信息丢失。

［第 3 层］编码者、校验者、报告者、跟踪者：分工推动质量

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

主管基于规划者的检查清单，按这个顺序发起工具使用调用：

• Coder——加载数据，编写并运行分析代码，产出 PNG 图表，把结果累积到 all_results.txt，并留下 calculation_metadata.json 供核验。

• Tracker（第 1 遍）——把已完成的检查清单项从 [ ] 更新为 [x]，主管用它决定是否继续。

• Validator——根据源数据重新执行 calculation_metadata.json 中的每一项计算。差值在 0.01 以内算通过，不匹配则被标出。已核验的计算进入 citations.json，供报告者引用。

• Tracker（第 2 遍）——把校验者的完成状态反映到检查清单中。

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

• Tracker（第 3 遍）——反映全部任务的最终完成状态。

Tracker 在每个智能体之后运行，使主管能够跟踪进度并执行完成规则（在全部项为 [x] 之前不往下走）。因为它用 LLM 推理更新检查清单、不使用工具，开销很小。

按智能体的 LLM 模型配置

Deep Insight 按每个智能体的角色定制模型和设置。这不是一次模型挑选。这是为优化成本和质量而做的架构决策。

主管、编码者和报告者使用提示缓存（Prompt Caching）来缓存系统提示和工具定义，在重复调用上把输入 token 成本降低最多 90%。协调者只运行一次，校验者和跟踪者每次以不同上下文运行，因此缓存对它们无效并保持关闭。这种选择性缓存策略是有意的成本/性能取舍。

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

如果方案细节 1 定义了系统做什么，本节定义它在哪里、如何安全运行。从这里开始的一切都覆盖生产运维的基础设施决策。具体而言，本节覆盖 LLM 生成代码的安全执行环境，以及团队所需的运维可见性。

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

编码者智能体编写并运行用于数据分析的 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），而不经过公共互联网。安全组限制哪些组件可以到达代码解释器容器。AWS Identity and Access Management（IAM）角色把每个组件限定到它需要的 AWS 资源。Amazon CloudWatch 收集容器日志，以及来自 AgentCore Observability 的可观测性数据。AgentCore Observability 是 Amazon Bedrock AgentCore 的一项能力。

• 定制容器 Docker 镜像：一个预先优化的沙箱，带有面向多智能体系统的字体、系统库和 Python 包。

• 容器隔离：每次分析会话在私有 VPC 子网中得到一个独立的 Fargate 容器，没有直接的互联网访问。

• 两步执行：LLM 生成的代码被 base64 编码，经 HTTP 发送，写入文件（步骤 1），然后通过 subprocess 执行（步骤 2）。

• 会话亲和：ALB 粘性会话 cookie 把智能体路由回同一个容器，即使它多次执行代码。

• 产物管理：分析完成时，图表、报告和日志上传到 Amazon S3。容器在一小时后自动终止。

容器隔离保护基础设施，但它不管智能体生成什么。校验者智能体重新核验计算。它不检测藏在上传数据里的提示注入指令，也不筛查 LLM 生成文本中的有害或无依据内容。对于生产部署，我们建议增加 Amazon Bedrock Guardrails 作为负责任人工智能控制：对用户提示和上传数据应用内容过滤和提示攻击检测，并对智能体输出应用上下文依据检查，使报告文本立足于源数据和已核验的计算。

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

生产系统不是只有代码就完整。团队必须评估系统健康、诊断问题并审阅结果，因此 Deep Insight 提供 Web 界面和运维仪表盘。

#### Web 界面（deep-insight-web）

一个基于 FastAPI 的 Web 界面，通过 AgentCore 原生协议（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 运维仪表盘截图

图 6：Deep Insight 运维仪表盘详情

扩展 Deep Insight 架构

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

案例 1：LG Electronics：由智能体人工智能驱动的营销洞察提取系统

LG Electronics 韩国销售部门在与 Deep Insight 相同的多智能体架构上构建了 ChatInsight。数据分析请求曾经需要 2–3 周，并且在营销人员与数据科学家之间丢失意图。协调者按复杂度路由，规划者跟踪任务，主管编排编码者和报告者，智能体之间的状态通过 all_results.txt 文件累积传递。曾经需要 3 天的分析现在需要 30 分钟，生产力提升 288 倍。不懂 SQL 的营销人员可以让智能体探索数据并提出策略（见 AWS 技术博客上的 LG Electronics 智能体人工智能洞察提取系统）。

图 7：LG Electronics 智能体人工智能营销洞察系统架构

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

在 AWS re:Invent 2025（session SNR203）上展示的 TechRecon，把 Deep Insight 的架构用到技术战略上。给定一家公司和行业，研究者收集技术趋势，编码者分析，校验者核验，报告者产出一份格局分析（Landscape Analysis）和一份技术立场文件（Technical Position Paper）。架构与 Deep Insight 几乎相同，用 Strands Agents SDK 图模式以及扩展思考和提示缓存构建，研究者取代编码者成为主要执行智能体。它表明该设计是一种通用模式：换掉智能体的角色和提示，同一套编排结构就能解决完全不同的问题。

图 8：TechRecon 结果

（进一步阅读：TechRecon GitHub | AWS re:Invent 会议视频）

结论

构建一个在生产中能工作的智能体，不是模型能力的问题。这是架构的问题。Deep Insight 给出一个已经验证的答案：

• 工作流管理：Strands Agents SDK 的图模式定义智能体之间的执行顺序并实现 HITL 分支，而智能体即工具模式让主管只在需要时调用专门化智能体。

• 推理引擎：我们按角色分配来自 Amazon Bedrock 的 Claude 模型（先 Haiku，然后 Opus，然后 Sonnet），以优化成本和质量。

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

• 代码执行：Application Load Balancer 加上 Fargate 上的 Amazon Elastic Container Service（Amazon ECS），把 LLM 生成代码的执行隔离在按会话的临时沙箱容器中，防止系统文件访问、资源耗尽和非预期数据泄露等安全问题。

• 运维：Web 界面的 SSE 流和运维仪表盘（DynamoDB + Cognito + SNS）为整个团队提供可见性。

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

在第 2 篇中，我们在这一架构之上考察四层用于克服上下文窗口限制的上下文工程技术，从架构级隔离到提示设计、工具优化和核验防护，并把我们的做法与 Anthropic 的工程研究相比较。

Deep Insight 是开源的。查看代码，并为你自己的领域扩展它。

• GitHub

• 研讨会：Deep Insight Workshop（English | Korean）

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/5-production-challenges-in-multi-agent-systems-and-how-deep-insight-solved-them