多智能体系统落地生产环境的 5 个难题，Deep Insight 如何解决

AWS ML Blog 2026-10-22T07:36:47+08:00

现在搭建一个多智能体系统并不难。真正的挑战在于把它推向生产环境。借助开源框架和云服务，几天内就能做出一个智能体。几次工具调用、几行提示词，看起来效果还不错。但一旦团队想从试点走向真实业务应用，就会撞上一堵熟悉的墙。

如果你试过把智能体投入生产，下面这些困扰一定不陌生：智能体为什么不按我们的业务逻辑走？为什么跳过验证步骤、漏掉边缘情况？你调整提示词、补充示例、换模型，同样的问题还是反复出现。原因在于，智能体并不是按固定指令序列执行的，它会根据上下文自行判断。光靠指令不够，你得设计智能体如何思考、何时验证、出错时怎么办。这正是为什么只做提示词工程已经不够，必须设计智能体完整的认知架构和执行流程。

为了正面解决这些问题，AWS 解决方案架构团队构建了 Deep Insight——一个生产级的多智能体系统。在这个系列文章中，我们将分三篇分享团队在构建 Deep Insight 过程中的一手经验。我们会讲到如何把 Anthropic 提出的上下文工程（Context Engineering）技巧——多智能体架构、结构化笔记、人机协同（human-in-the-loop）等——落地到真实生产环境。也会涉及过程中遇到的取舍（附代码），以及在 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 文件加上一句自然语言提示，一组分工明确的智能体（协调者、规划者、监督者、编码者、校验者、报告者和追踪者）便会协作完成分析。它们会一起加载数据、执行分析、生成图表、校验计算，最终产出一份带引用的专业报告（.docx 格式）。关于这套架构的细节，我们稍后再展开。先来看看实际效果。

在演示中，我们喂给它一份虚构食品公司 Yummy Food 的广告数据（yummy-food-market.csv），附带一份列定义文件（column_definitions.json），并给出提示：

从销售和营销的角度分析这份数据，生成图表和洞察，并输出一份 .docx 报告。

Deep Insight 会先生成一份分析计划，交给用户确认；用户批准后，才真正执行分析。

内容输入

CSV 数据文件（yummy-food-market.csv）
列定义文件（column_definitions.json）

示例提示

“从销售和营销的角度分析这份数据，生成图表和洞察，并输出一份 .docx 报告。”

输出

DOCX 报告（两个版本：一份带引用，一份不带引用）
图表图片（PNG）

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

如何试用

Deep Insight 已在 GitHub 上开源，配有完整的环境搭建指南，并提供三种部署方式，覆盖从开发到生产的各种场景。第一种是自托管版本，通过 CLI 在本地运行。它针对快速迭代做了优化，代码层的每个智能体、每条提示、每个工作流都完全开放。大约 10 分钟就能完成初始化，非常适合开发阶段。

（YouTube 上有自托管版本的演示视频。）第二个是 Web 版，浏览器界面，支持上传数据、审核分析计划（Human-in-the-Loop，简称 HITL，即需要人工介入的环节）、下载报告，全程不用写代码，非开发者也能上手。（前面的演示视频展示的就是 Web 版的实际操作。）第三个是托管 AgentCore 版，面向生产环境的部署方案，底层依托 Amazon Bedrock AgentCore 平台——这个平台可以在任意框架、任意模型上大规模构建、连接和优化智能体。该版本把智能体部署在 AgentCore Runtime 上，这是 Amazon Bedrock AgentCore 提供的一项能力。整个系统运行在私有虚拟私有云（VPC）内，自定义代码解释器单独托管在 AWS Fargate 上，各智能体在按用户隔离的环境中并发运行。如果你需要会话隔离和私有 VPC 部署，这个版本就是合适的选择。第 3 部分详细介绍了它的部署与运维。三个版本共用同一套多智能体架构，因此在开发阶段验证过的智能体可以直接部署到生产。

方案概览

构建生产级多智能体系统，光有好提示词远远不够。你还需要合适的技术栈和基础设施，来解决这些问题：智能体之间如何协作、如何推理、如何部署、在哪里安全执行代码、以及如何监控运行健康状况。Deep Insight 在五个关键领域逐一给出了解法。由于智能体会同时生成代码和报告内容，我们在「方案详解 2」中还专门介绍了生产环境下的负责任 AI 管控措施。

挑战	技术方案	思路
如何控制多个智能体之间的执行流程？	Strands Agents SDK	用 Strands 的 Graph 模式定义智能体之间的执行顺序，并实现需要人工介入的分支逻辑。再用 Strands 的 Agents as Tools 模式，让 Supervisor 按需把专职智能体（Coder、Validator、Reporter、Tracker）当作工具调用。
每个智能体该用哪个大语言模型（LLM）？	Amazon Bedrock	按角色挑选合适的 Claude 模型：Haiku 负责基础路由，Opus 负责规划，Sonnet 负责执行。

生产环境中的五个挑战及 Deep Insight 的解决方式

“如何让一个已完成的 agent 在生产中稳定运行？”——Amazon Bedrock AgentCore 托管运行时，提供监控、会话隔离和私有 VPC 部署。

“如何降低执行 AI 生成代码带来的安全风险？”——AWS Fargate 加应用负载均衡器（ALB），通过自定义代码解释器（Code Interpreter）为每个会话分配临时沙箱容器，隔离代码执行。

“如何监控和管理整个系统？”——Amazon DynamoDB、Amazon Simple Notification Service（Amazon SNS）和 Amazon Cognito，搭建管理后台和故障告警系统。

下图（图 1）一目了然地展示了整体架构。绿色方框是 Strands Agents 的多 agent 结构，对应上表中第 1、2 项挑战，我们会在后面的“方案详解 1：多 agent 系统设计”中展开。图中的其余基础设施组件对应第 3、4、5 项挑战，将在“方案详解 2：生产部署与运维”中说明。

图 1：方案架构

方案详解 1：多 agent 系统设计

Deep Insight 采用多 agent 架构，由八个 agent 协作产出一份高质量交付物。每个 agent 都在独立的上下文中工作，只做自己擅长的任务，并且只把压缩后的结果传给下游。

图 2：多 agent 结构

Coordinator 负责分发用户请求，Planner 把任务拆成一个个具体步骤，Plan Reviewer 收集用户反馈，Supervisor 按计划调用相应的专业 agent。Coder 编写并执行数据分析代码，Validator 校验计算结果，Reporter 生成最终报告，Tracker 跟踪进度。

我们分三层来说明：

第一层：Coordinator → Planner → Plan Reviewer，负责分析请求、制定执行计划。
第二层：Supervisor，负责调度各专业 agent。
第三层：Coder、Validator、Reporter、Tracker，负责执行具体任务。

要控制这些 agent 之间的执行流程，我们组合使用了 Strands Agents SDK 中的两种关键模式。

首先，图模式把代理的执行顺序和流程定义成一张有向图。请求依次流经协调器、规划器、计划审查器，再到监督器；如果需要修改，条件分支会回环到规划器。用条件判断下一步走向，人机协同（HITL）和错误处理这类复杂工作流就变得很直接。其次，代理即工具模式让监督器只在需要时，把专用代理（编码器、验证器、报告器、追踪器）当作工具调用。每个代理在独立的上下文中工作，只返回结果，既节省上下文用量，又保留各自的领域专长。本节说明这套架构如何解决路由、规划和编排问题。

【第一层】协调器 → 规划器 → 计划审查器

这一层负责把用户请求变成一份获批的执行计划。

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)

路由条件由 Coordinator 的提示词决定：只要请求涉及工具调用、推理或多步思考，就交给 Planner。

1.2 Planner（制定计划）：复杂分析要先拆解再执行

在 Deep Insight 的多智能体架构里，Planner 负责把任务分配到各个智能体，是个关键角色。真正开始干活之前，它先把大任务拆成小步骤，再由每个专精的智能体逐个执行，从而让每个智能体只需关注一小块上下文。

Planner 使用 Claude Opus 模型，并开启了扩展思考（Extended Thinking）来制定分析计划。它把计划组织成 [ ] 复选框清单的形式，明确写出每个智能体要执行的具体任务，保存在 full_plan 变量中。它会把请求拆成 5～10 个清晰的步骤，示例如下：

## title

美味食品消费者购买模式与广告效果分析报告

## steps

### 1. Coder：全面数据分析与洞察生成

- [ ] 从 './data/*' 路径加载所有数据文件并理解其结构

- [ ] 分析消费者购买历史（模式、偏好、客户分群）

- [ ] 按渠道分析广告数据（成本、效果、渠道对比）

- [ ] 品类层面分析（生鲜、便利食品、健康食品的广告效果）

- [ ] 计算关键业务指标（转化率、CPA、ROAS 等）

- [ ] 生成可视化图表（5 张以上，含消费者分群图）

- [ ] 提炼战略性营销洞察

- [ ] 生成计算元数据（用于校验）

### 2. Validator：计算核验与引用元数据生成

- [ ] 确定核验对象，提取筛选计算过程

- [ ] 直接加载数据文件并重新计算

- [ ] 核验各渠道绩效指标的准确性

- [ ] 校验可视化结果与图表的数据一致性

- [ ] 生成引用元数据（为已核验条目分配参考编号）

### 3. Reporter：营销分析报告生成

- [ ] 撰写报告概述

[ ] 使用已核验的分析结果创建结构化报告
[ ] 插入可视化图表和分析章节
[ ] 呈现营销策略建议与改进方案
[ ] 生成 DOCX 格式的专业营销报告

1.3 计划审核员（Plan Reviewer）

计划审核员是一个 HITL（Human-in-the-Loop，人在回路）节点，负责把计划呈现给用户，收集批准或修改反馈。如果收到反馈，就回到规划器（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 版本中，计划审核员会弹出浏览器模态框，用户阅读计划后可以选择批准，或输入修改反馈。如果 300 秒内没有响应，系统会自动批准计划。

图 3：Web UI 中的计划审核员 agent 执行过程

如果没有规划环节，agent 会在运行时临时决定一切，中途纠偏会让之前的工作作废，用户也无法看到进度。有了规划器和计划审核员，用户可以审阅和修改计划、实时监控进度，失败时只需重新执行出错的步骤。

[第二层] 主管（Supervisor）：编排器——专职 agent 需要一位指挥

主管按照规划器的 full_plan 顺序执行，通过 Tool Use（工具调用）机制把第三层的 agent（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 把线索和 full_plan 变量传给每个工具智能体，保持完整上下文，防止信息丢失。

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

第三层的每个智能体（Coder、Validator、Reporter、Tracker）都封装为 PythonAgentTool，接收来自 Supervisor 的工具调用（Tool Use）。每个智能体都是 Strands SDK 中独立的 Agent() 实例，拥有自己的系统提示词、模型 ID 和工具集。

智能体	职责	工具	关键输出
Coder	数据分析、图表生成、洞察推导	write_and_execute_tool、bash_tool、file_read、skill_tool	*.png 图表、calculation_metadata.json
Validator	数值计算复核、引用生成	write_and_execute_tool、bash_tool、file_read	citations.json、validation_report.txt
Reporter	生成 DOCX 报告	write_and_execute_tool、bash_tool、file_read	final_report.docx、final_report_with_citations.docx
Tracker	更新清单进度状态	无（仅靠 LLM 推理）	更新后的 full_plan

Supervisor 按照 Planner 给出的清单，依次发起工具调用：

Coder – 加载数据，编写并运行分析代码，生成 PNG 图表，把结果汇总到 all_results.txt，并留下 calculation_metadata.json 供后续验证。
Tracker（第一轮） – 把已完成的清单项从 [ ] 更新为 [x]，Supervisor 据此判断是否继续。
Validator – 从源数据重新执行 calculation_metadata.json 中的每一项计算。误差在 0.01 以内视为通过，不一致则标记出来。通过验证的计算写入 citations.json，供 Reporter 引用。
Tracker（第二轮） – 把 Validator 的完成状态反映到清单中。

Reporter：读取 all_results.txt 和 citations.json，生成最终 DOCX 报告，并输出两个版本：带引用和不带引用。

Tracker（第三轮）：汇总所有任务的最终完成状态。每执行完一个 agent，Tracker 都会运行一次，Supervisor 据此掌握进度、执行完成规则——所有事项都打上 [x] 之前，不准推进下一步。Tracker 只靠大模型推理更新清单，不调用工具，因此几乎不增加额外开销。

为每个 agent 单独配置模型

Deep Insight 会针对每个 agent 的职责，单独设置模型和参数。这不仅是在挑模型，更是一项架构决策，目的是在成本和质量之间找到最佳平衡。

Agent	模型	扩展思考	Prompt 缓存	定位
Coordinator	Haiku	关闭	否	快速分流：成本最低
Planner	Opus	开启（约 8,192 tokens）	否	深度思考：高质量规划
Supervisor	Sonnet	关闭	是	执行编排：靠缓存省钱
Coder	Sonnet	关闭	是	代码生成与执行：重复调用时缓存收益明显
Validator	Sonnet	关闭	否	数值校验：每次数据都不同，缓存没意义
Reporter	Sonnet	关闭	是	报告生成：长提示词下缓存收益明显
Tracker	Sonnet	关闭	否	状态更新：任务很轻，无需缓存

Supervisor、Coder 和 Reporter 三个 agent 启用了 Prompt 缓存，把系统提示词和工具定义缓存起来，重复调用时输入 token 成本最多可降低 90%。Coordinator 只运行一次；Validator 和 Tracker 每次的上下文都不一样，缓存起不到作用，因此一律关闭。哪些开、哪些不开，都是有意为之的成本与性能权衡。

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

如果方案细节一回答的是「系统做什么」，这一节讲的就是「系统在哪里跑、怎么跑才安全」。从这里开始，内容都围绕生产运维的基础设施决策展开：一是为 LLM 生成的代码提供安全的执行环境，二是让团队能看清系统的运行状况。

1. 代码执行：LLM 生成的代码需要安全沙箱

Coder agent 会编写并运行 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（Amazon Bedrock AgentCore 提供的一项能力）的可观测性数据。

自定义容器 Docker 镜像：预先优化好的沙箱，含字体、系统库，以及多 agent 系统所需的 Python 包。
容器隔离：每个分析会话分到一个独立的 Fargate 容器，位于私有 VPC 子网中，没有直接公网访问。
两步执行：LLM 生成的代码先做 base64 编码，通过 HTTP 发送，写入文件（第 1 步），再通过 subprocess 执行（第 2 步）。
会话粘性：借助 ALB 的粘性会话 cookie，agent 多次执行代码时会被路由回同一个容器。
产物管理：分析完成后，图表、报告和日志会上传到 Amazon S3。容器在一小时后自动终止。

容器隔离保护了基础设施，却约束不了 agent 生成的内容。Validator agent 会重新核验计算结果，但它检测不出上传数据里藏的提示注入指令，也不会筛查 LLM 生成的文本是否有害或缺乏依据。

面向生产部署时，我们建议把 Amazon Bedrock Guardrails 作为一项负责任的 AI 控制措施：对用户输入的提示词和上传的数据应用内容过滤和提示词攻击检测；对智能体的输出做上下文事实校验，确保报告内容都基于源数据和经过验证的计算结果。

2. 运维与监控：团队需要看得见系统状态

光有代码，生产系统还不算完整。团队必须能判断系统是否健康、排查问题、复核结果，因此 Deep Insight 提供了 Web UI 和运维仪表盘。

Web UI（deep-insight-web）

这是一个基于 FastAPI 的网页界面，通过 AgentCore 原生协议（boto3.invoke_agent_runtime()）与后端通信。用户上传数据、输入提示词后，可以通过服务器推送事件（Server-Sent Events，SSE）流式查看进度。计划生成后，会弹出对话框，让用户批准或提出修改意见（HITL，人在环路中）。最终报告可以直接下载。界面支持韩语和英语。

图 4：Deep Insight Web 版截图

运维仪表盘（deep-insight-web/ops）

运维仪表盘是可选的。没有它，Deep Insight 也能正常运行；但对有需要的团队来说，它额外提供以下功能：

任务跟踪：所有分析任务的指标都会记录到 Amazon DynamoDB，包括状态、token 用量和耗时。
失败告警：分析失败时，通过 Amazon SNS 立刻给管理员发邮件。
管理后台：独立的管理仪表盘，用 Amazon Cognito 的 JSON Web Token（JWT）认证保护，可以安全地监控任务。

图 5：Deep Insight 运维仪表盘截图

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

扩展 Deep Insight 的架构

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

案例 1：LG 电子——基于 Agentic AI 的营销洞察提取系统

LG 电子韩国销售部门基于与 Deep Insight 相同的多智能体架构，搭建了 ChatInsight。过去，数据分析请求要花 2–3 周，营销人员与数据科学家之间的意图还在传递中不断丢失。现在，Coordinator 按复杂度分流，Planner 跟踪任务，Supervisor 调度 Coder 和 Reporter，智能体之间的状态通过 all_results.txt 文件累积传递。原本 3 天的分析现在 30 分钟完成，效率提升 288 倍。不会 SQL 的营销人员也能让智能体探索数据、提出策略（详见 AWS 技术博客上的 LG 电子 Agentic AI 洞察提取系统）。

Figure 7: LG Electronics Agentic AI marketing insight system architecture

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

TechRecon 在 AWS re:Invent 2025 上亮相（session SNR203），把 Deep Insight 的架构用到了技术战略上。给定一家公司和所属行业，Researcher 收集技术趋势，Coder 做分析，Validator 做验证，Reporter 产出《Landscape Analysis》和《Technical Position Paper》。这套架构与 Deep Insight 几乎一致，基于 Strands Agents SDK 的 Graph 模式构建，并用上了 Extended Thinking 和 Prompt Caching，只是把主执行智能体从 Coder 换成了 Researcher。这说明该设计是一种通用模式：换掉智能体的角色和提示词，同一套编排结构就能解决完全不同的另一类问题。

Figure 8: TechRecon results

（延伸阅读：TechRecon GitHub | AWS re:Invent Session Video）

结论

做一个能在生产环境跑起来的智能体，关键不在模型能力，而在架构。Deep Insight 给出了一套经过验证的答案：

工作流管理：Strands Agents SDK 的 Graph 模式定义了智能体之间的执行顺序，并实现 HITL 分支；Agents-as-Tools 模式则让 Supervisor 只在需要时调用专用智能体。

推理引擎：我们按角色分配 Amazon Bedrock 上的 Claude 模型（先 Haiku，再 Opus，最后 Sonnet），在成本和质量之间取得平衡。

部署：Amazon Bedrock AgentCore 提供托管运行时，支持会话隔离、私有 VPC 部署和 OpenTelemetry 可观测性。代码执行：应用负载均衡器（ALB）配合 Amazon Elastic Container Service（Amazon ECS）on Fargate，把 LLM 生成的代码隔离在按会话创建的临时沙箱容器中运行，避免访问系统文件、耗尽资源、意外泄露数据等安全问题。运维：Web UI 的 SSE 流式输出和 Ops 仪表盘（DynamoDB + Cognito + SNS）让整个团队都能掌握系统状态。LG 电子的营销洞察系统和 re:Invent 2025 上的 TechRecon 案例，都验证了这些设计原则。

在第二部分中，我们会在这一架构之上，探讨四层上下文工程（Context Engineering）技术，用来突破上下文窗口的限制——从架构级隔离，到提示词设计、工具优化和验证保障，并与 Anthropic 的工程研究做对比。

Deep Insight 是开源的。你可以浏览代码，也可以将它扩展到自己的业务领域。

GitHub Workshop：Deep Insight Workshop（英文 | 韩文）

关于作者

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

Jesam Kim
Jesam 是一名解决方案架构师，帮助企业客户采用云技术、解决业务难题。他专注 AI/ML 领域，包括推荐系统和生成式 AI，帮客户设计符合业务需求的架构。

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

Kyutae Park
Kyutae 博士是一名 AI 专家解决方案架构师，帮助各行业客户设计和构建应用型 AI 工作负载。他在机器学习、MLOps 和智能体 AI 方面经验丰富。

他专注智能自动化和基于智能体 AI（Agentic 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 服务来加速业务成果的落地。

查看原文