5个多agent系统的生产挑战以及深度透视如何解决这些问题

人工智能

5个多agent系统的生产挑战以及深度透视如何解决这些问题

建立一个多agent系统现在相当直截了当。 把它带到生产是真正的挑战的开始。 由于开源框架和云服务，可以在几天内设置agent. 几个工具的呼叫，几行快速，你有一个东西看起来令人印象深刻。 但一旦团队试图超越飞行员，进入真正的商业应用，他们就撞上了熟悉的墙。 如果你曾经尝试将agent投入生产，这些挫折听起来会很熟悉：

agent为何不遵循我们的商业逻辑

你调整的提示，添加更多的例子，交换模型。 同样的问题不断出现 agents没有遵循固定的指令序列。 他们根据具体情况作出自己的判断。 单靠指示是不够的。 你需要设计agent如何思考，当它被验证时，当事情发生错误时它会做什么。 因此，必须超越快速工程本身，设计agent的整个认知架构和执行流程。

为了正面应对这些挑战，AWS解决方案架构团队建造了Deep Insight，一个生产级的多agent系统。 我们分享团队第一手学到的东西，我们将走过我们如何在真正的生产环境中应用Anthropic(多agent架构，结构化的记事，人性化等)提出的背景工程技术。 我们还叙述了我们在整个过程中(以代码)遇到的权衡，以及我们从AWS上部署和运行agent获得的行动见解。

博客系列概览

- 第1部分：多agent系统中的5个生产挑战以及如何解决它们。

- 第2部分：上下文窗口之外：上下文工程技术及其如何应用。

- 第3部分：实际操作中的哈尼思工程：将深度透视从Dev转移到生产。

这是三部曲系列的第一部分。 它定义了从Strands Agents SDK和Amazon Bedrock到Amazon Bedrock Agent Core，应用程序负载平衡器和AWS 远门，任何生产多agent系统必须解决和显示的每个层如何解决这五个核心挑战。 第2和第3部分涉及背景工程和生产部署。

引入深度透视

深处 Insight是一个多agent系统，将复杂的数据分析转化为自动化的透视。 鉴于一个CSV文件和一个自然语言的提示，专业agents(协调员、规划员、主管、编码员、验证员、报告员和跟踪员)的等级关系在分析方面进行了协作。 它们共同加载数据，进行分析，生成图表，验证计算，并编制专业报告(.docx)。

我们稍后将详细探讨这一架构。 首先，对于演示，我们从虚构的食品公司Yummy Food(英语：Yummy-food-market.csv)中提供广告数据，并附有专栏定义文件(colon definitions.json)，并提供提示：从销售和营销的角度分析这一点，生成图表和见解，并产生一份.docx报告。 深度透视生成分析计划，提交用户审批，一旦批准，即执行分析。

从上传数据，审查分析计划，到实时流媒体和下载成品报告，沿袭显示全程工作流程的深度透视网络演示视频。

我怎么试试？

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

第一个是自控版，通过CLI在当地运行。 它被优化为快速迭代，它在大约10分钟后建立，这使得它非常适合发展。 (YouTube上有自带的演示视频。 )

第二个是Web版本，是一个基于浏览器的UI，用于上传数据，审查分析计划(Human-in-the-Loop，或HITL)，并下载报告，全部没有写代码，使得非开发者可以访问。 (前一个演示视频显示的Web版本正在操作中。

第三个是管理代理Core版本，是由Amazon Bedrock AgentCore提供动力的生产部署选项，是一个在规模上构建，连接，优化agents的平台，拥有任何框架或模型。 这个版本在Agent Core runtime上部署agents，是一种Amazon Bedrock Agent Core的能力。 系统完全运行在私人虚拟私密云层(VPC)内，自定义代码解释器单独托管在AWS Fargate上，agents在孤立的每个用户环境中同时运行。 这是正确的选择，第3部分详细介绍了特派团的部署和行动。

三者都拥有相同的多agent架构，因此agent在开发部署中验证为即时生产。

解决方案概述

建设生产型多agent系统，需要的不只是良好的提示。 你需要正确的技术堆栈和基础设施来解决agents如何合作，如何解释，如何部署，在哪里安全执行代码，以及如何监测操作健康。 深处洞察解决了这五个关键领域的问题。 由于agents同时生成代码和报告内容，我们也在"解决方案细节2"中涵盖了对生产负责的AI控制。

下面的架构图(图1)一目了然地说明了这一点。 绿箱代表Strands Agents多agent结构，它处理上表中的挑战1和2. 我们将在即将到来的解决方案细节1：多agent系统设计部分详细论述这一点。 图表中显示的其余基础设施部分涉及挑战3、4和5，我们将在“解决方案细节2：生产部署和运作”中走过这些挑战。

解决方案细节1：多agent系统设计

深度透视采用多agent架构，其中8个agents合作生产出1个高质量的可交付品。 每个agent在自己的独立上下文中工作，只执行自己的专门任务，只通过压缩结果继续。

协调员引导用户请求，计划员将任务分成独立的步骤，计划审查员收集用户反馈，监督员根据计划援引适当的专用agents. 代码员编写并执行数据分析代码，验证员验证计算，报告员生成最终报告，跟踪器跟踪进度。 我们将分三层解释这一点：

- [第1层] 规划员至规划审查员的协调员：要求分析和制定执行计划。

- [第2层]监制：专用agent管弦乐。

- [第3层] 编码器、验证器、报告器、跟踪器：专门任务执行。

Strands Agents SDK的两种关键模式结合，控制了这些agents的执行流。 首先，Graph图案将agents的执行顺序和流量定义为定向图。 请求流量协调员，计划员，计划审查员，然后是监督员，有条件的分支循环返回规划员处理修订请求。 按条件确定下一步的工作，使HITL和错误处理等复杂的工作流程变得简单明了。 其次，Agents-as-Tools图案允许监理仅在需要时才引用专门的agents(代码，验证器，报告器，跟踪器)作为工具。 每一个在独立的上下文中工作，只返回结果，在保留域专长的同时尽量减少上下文的使用。

本节显示架构如何解决路由，规划和管弦乐。

[第1层]规划员改为规划审查员的协调员

这一层将用户请求变成一个核准的执行计划。

1.1 协调员(路线)：并不是每个请求都需要昂贵的管弦乐

协调员是用户请求的切入点。 它直接处理基本的问候，并将数据分析等复杂任务以交接 to planner标记传递给计划员。

关键的设计决定是模型选择：因为协调员只分类，所以它使用轻量级的Claude Haiku，避免了Opus级别在基本问候上的成本，并做出了快速响应。

规则条件来自协调员的催促：任何需要工具、推理或多步骤思考的请求都由规划者提出。

1.2 规划员(计划制定)：执行前需要分解复杂的分析

在Deep Insight的多agent结构中，规划师agent在跨agents分配任务方面发挥着关键作用。 在实质性工作开始前，它将大任务分解为较小的步骤，每个专业的agent一次执行一次，使每个agent的背景小。

规划师使用Claude Opus模型，并开启扩展思维来制定分析计划。 它将计划组织为[ ]核对表格式，其中具体规定分配给每个agent的具体任务，存储在一个完整的计划变量中。 它将请求分为5至10个明确步骤，如下例所示：

1.3 计划审查员

计划审查员是一个HITL节点，向用户介绍计划并收集批准或修订反馈。 如果有反馈，它会回转计划员修改计划。 经批准后，将任务交给监事。 设置了最大修订数(MAX PLAN REVISIONS)，以防止无限循环。

在Web版本中，计划审查员显示是一种浏览器模式，用户读取计划并批准计划或输入修订反馈。 300秒倒计时自动批准计划如果没有回复到来。

没有规划，agent在运行时间决定一切，一个中程校正使之前的工作失效，用户对进展没有可见度。 与计划员和计划审查员一起，用户可以审查和修改计划，实时监测进度，只重新执行一个失败的步骤。

[第2层]监理(操作员)：专用agents需要导师

主管按顺序执行规划员的完整计划，将第3层agents(编码器、验证器、报告器、跟踪器)作为通过工具使用在其上注册的工具。

监督员的系统即时定义了严格的工作流程规则：

- 强制执行命令：编码器、追踪器、验证器、追踪器、报告器、追踪器：每次agent运行后，追踪器用于跟踪进度，让主管管理总体任务状态。

- 节补齐规则：在当前agent的所有清单项目都标记为[x]之前，监事不移动到下一个agent.

- 上下文保存：主管将线索和全计划变量传递给每个工具agent，保持完整上下文，防止信息丢失。

[第3层] 编码员、验证员、记者、跟踪员：分工驱动质量

每层3 agent(编码器，验证器，报告器，跟踪器)被包裹为PythonAgentTool，并接收来自主管的工具使用呼叫。 每一个都作为独立的 Agent () 实例在 Strands SDK 中创建，有自己的系统即时，模型ID，和工具集。

监督员根据计划员的核对表，按此顺序引用工具使用调用：

- Coder – 装入数据，写和运行分析代码，生成PNG图表，积累所有 results.txt中的结果，并留下计算 metadata.json进行校验。

- Tracker(第1次通过) - 更新从[ ]到[x]完成的核对表项目，监事使用这些核对表项目决定是否进行。

- 校验器 – 从源数据中重新执行每个计算器的计算 metadata.json. 0.01传中匹配，错配被标记。 校验的计算可以引用。 json供记者引用。

- Tracker(第2次通过) - 在核对表中反映验证员的完成状态。

- Reporter – 阅读所有 results.txt和引文.json，以生成最终的DOCX报告，分两个版本，有和无引文。

- 追踪器(第3次通过)

本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Artificial Intelligence

5 production challenges in multi-agent systems and how Deep Insight solved them

Building a multi-agent system is now pretty straightforward. Taking it to production is where the real challenges begin. Thanks to open source frameworks and cloud services, you can set up an agent in a matter of days. A few tool calls, a few lines of prompt, and you have something that looks impressive. But the moment teams try to move beyond a pilot and into real business applications, they hit a familiar wall. If you’ve ever tried to put an agent into production, these frustrations will sound familiar:

Why doesn’t the agent follow our business logic, skip validation steps, or catch edge cases?

You tweak the prompt, add more examples, swap out the model. The same problems keep coming back. That’s because agents don’t follow a fixed sequence of instructions. They make their own judgments based on context. Instructions alone aren’t enough. You need to design how the agent thinks, when it verifies, and what it does when things go wrong. This is exactly why it’s become critical to go beyond prompt engineering alone and design the agent’s entire cognitive architecture and execution flow.

To tackle these challenges head-on, the AWS Solutions Architecture team built Deep Insight, a production-grade multi-agent system. In this post series, we share what the team learned firsthand while building Deep Insight across three posts. We will walk through how we applied Context Engineering techniques proposed by Anthropic (multi-agent architecture, structured note-taking, human-in-the-loop, and more) in a real production environment. We also cover the trade-offs we encountered along the way (with code) and the operational insights we gained from deploying and running this agent on AWS.

Blog series overview

- Part 1: 5 production challenges in multi-agent systems and how Deep Insight solved them.

- Part 2: Beyond the context window: Context Engineering techniques and how Deep Insight applied them.

- Part 3: Harness engineering in practice: moving Deep Insight from dev to production.

This is Part 1 of a three-part series. It defines the five core challenges any production multi-agent system must solve and shows how each layer of the stack addresses them, from Strands Agents SDK and Amazon Bedrock to Amazon Bedrock AgentCore, Application Load Balancer, and AWS Fargate. Parts 2 and 3 cover Context Engineering and production deployment.

Introducing Deep Insight

Deep Insight is a multi-agent system that turns complex data analysis into automated insights. Given a CSV file and a natural-language prompt, a hierarchy of specialized agents (Coordinator, Planner, Supervisor, Coder, Validator, Reporter, and Tracker) collaborates on the analysis. Together they load the data, run analyses, generate charts, validate calculations, and produce a professional report (.docx) with citations.

We will explore the architecture in detail later. First, let’s see it in action. For the demo, we feed advertising data from a fictional food company, Yummy Food (yummy-food-market.csv) with a column definitions file (column_definitions.json), and provide the prompt: Analyze this from a sales and marketing perspective, generate charts and insights, and produce a .docx report. Deep Insight generates an analysis plan, presents it to the user for approval, and, once approved, executes the analysis.

The Deep Insight web demo video that follows shows the full workflow, from uploading data and reviewing the analysis plan to real-time streaming and downloading the finished report.

How can I try it?

Deep Insight is open sourced on GitHub with a full setup guide, and offers three deployment options spanning development to production.

The first is the Self-Hosted version, which runs locally through the CLI. It’s optimized for rapid iteration with full code-level access to every agent, prompt, and workflow. It sets up in about 10 minutes, which makes it well suited to development. (A Self-Hosted demo video is available on YouTube.)

The second is the Web version, a browser-based UI for uploading data, reviewing analysis plans (Human-in-the-Loop, or HITL), and downloading reports, all without writing code, making it accessible for non-developers. (The preceding demo video shows the Web version in action.)

The third is the Managed AgentCore version, a production deployment option powered by Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. This version deploys the agents on AgentCore runtime, a capability of Amazon Bedrock AgentCore. The system runs entirely within a private virtual private cloud (VPC), with a custom Code Interpreter hosted separately on AWS Fargate, and agents run concurrently in isolated per-user environments. It’s the right choice when you need session isolation and private VPC deployment. Part 3 covers its deployment and operations in detail.

All three share the same multi-agent architecture, so an agent validated in development deploys to production as-is.

Solution overview

Building a production multi-agent system takes more than good prompts. You need the right technology stack and infrastructure to address how agents collaborate, how they reason, how you deploy them, where they safely execute code, and how you monitor operational health. Deep Insight solves problems across these five key areas. Because the agents generate both code and report content, we also cover responsible AI controls for production in Solution detail 2.

The following architecture diagram (Figure 1) illustrates this at a glance. The green boxes represent the Strands Agents multi-agent structure, which addresses challenges 1 and 2 from the preceding table. We will cover this in detail in the upcoming Solution detail 1: Multi-agent system design section. The remaining infrastructure components shown in the diagram address challenges 3, 4, and 5, which we will walk through in Solution detail 2: Production deployment and operations.

Solution detail 1: Multi-agent system design

Deep Insight uses a multi-agent architecture in which eight agents collaborate to produce one high-quality deliverable. Each agent works in its own independent context, performs only its specialized tasks, and passes only compressed results onward.

The Coordinator routes user requests, the Planner breaks tasks into discrete steps, the Plan Reviewer collects user feedback, and the Supervisor invokes the appropriate specialized agents according to the plan. The Coder writes and executes data analysis code, the Validator verifies calculations, the Reporter generates the final report, and the Tracker tracks progress. We will explain this across three layers:

- [1st Layer] Coordinator to Planner to Plan Reviewer: Request analysis and execution plan creation.

- [2nd Layer] Supervisor: Specialized agent orchestration.

- [3rd Layer] Coder, Validator, Reporter, Tracker: Specialized task execution.

Two key patterns from the Strands Agents SDK are combined to control execution flow across these agents. First, the Graph pattern defines the execution order and flow of agents as a directed graph. Requests flow Coordinator, Planner, Plan Reviewer, then Supervisor, with a conditional branch looping back to the Planner on revision requests. Determining the next step by condition makes complex workflows like HITL and error handling straightforward. Second, the Agents-as-Tools pattern lets the Supervisor invoke specialized agents (Coder, Validator, Reporter, Tracker) as tools only when needed. Each works in an independent context and returns only results, minimizing context usage while preserving domain expertise.

This section shows how the architecture solves routing, planning, and orchestration.

[1st Layer] Coordinator to Planner to Plan Reviewer

This layer turns a user request into an approved execution plan.

1.1 Coordinator (routing): Not every request needs expensive orchestration

The Coordinator is the entry point for user requests. It handles basic greetings directly and routes complex tasks like data analysis to the Planner with a handoff_to_planner marker.

The key design decision is model selection: because the Coordinator only classifies, it uses the lightweight Claude Haiku, avoiding Opus-level costs on basic greetings and delivering fast responses.

Routing conditions come from the Coordinator’s prompt: any request needing tools, reasoning, or multi-step thinking goes to the Planner.

1.2 Planner (plan creation): Complex analyses need decomposition before execution

In Deep Insight’s multi-agent structure, the Planner agent plays the critical role of distributing tasks across agents. Before substantive work begins, it breaks large tasks into smaller steps, and each specialized agent executes them one at a time, keeping each agent’s context small.

The Planner uses a Claude Opus model with Extended Thinking turned on to develop the analysis plan. It organizes the plan into a [ ] checklist format that specifies concrete tasks assigned to each agent, stored in a full_plan variable. It breaks the request into 5–10 clear steps, as shown in the following example:

1.3 Plan Reviewer

The Plan Reviewer is a HITL node that presents the plan to the user and collects approval or revision feedback. If there is feedback, it loops back to the Planner to revise the plan. If approved, it hands the task off to the Supervisor. A maximum revision count (MAX_PLAN_REVISIONS) is set to prevent infinite loops.

In the Web version, the Plan Reviewer shows a browser modal where the user reads the plan and approves it or enters revision feedback. A 300-second countdown auto-approves the plan if no response arrives.

Without planning, the agent decides everything at runtime, a mid-course correction invalidates previous work, and users have no visibility into progress. With the Planner and Plan Reviewer, the user can review and revise the plan, monitor progress in real time, and re-execute only a failed step.

[2nd Layer] Supervisor (orchestrator): Specialized agents need a conductor

The Supervisor executes the Planner’s full_plan in order, invoking the Layer 3 agents (Coder, Validator, Reporter, Tracker) as tools registered on it through Tool Use.

The Supervisor’s system prompt defines strict workflow rules:

- Mandatory execution order: Coder, Tracker, Validator, Tracker, Reporter, Tracker: after each agent runs, Tracker is invoked to track progress, letting the Supervisor manage overall task state.

- Section completion rule: The Supervisor does not move to the next agent until all checklist items for the current agent are marked [x].

- Context preservation: The Supervisor passes clues and full_plan variables to each tool agent, maintaining full context and preventing information loss.

[3rd Layer] Coder, Validator, Reporter, Tracker: Division of labor drives quality

Each Layer 3 agent (Coder, Validator, Reporter, Tracker) is wrapped as a PythonAgentTool and receives Tool Use calls from the Supervisor. Each is created as an independent Agent() instance in the Strands SDK with its own system prompt, model ID, and toolset.

The Supervisor invokes Tool Use calls in this order, based on the Planner’s checklist:

- Coder – Loads data, writes and runs analysis code, produces PNG charts, accumulates results in all_results.txt, and leaves calculation_metadata.json for verification.

- Tracker (1st pass) – Updates completed checklist items from [ ] to [x], which the Supervisor uses to decide whether to proceed.

- Validator – Re-performs each calculation in calculation_metadata.json from the source data. Matches within 0.01 pass, mismatches are flagged. Verified calculations go to citations.json for the Reporter to cite.

- Tracker (2nd pass) – Reflects the Validator’s completion status in the checklist.

- Reporter – Reads all_results.txt and citations.json to generate the final DOCX report in two versions, with and without citations.

- Tracker (3rd pass) –

Auto-fetched and translated by AI Atlas. All rights belong to the original author.