当客户问:“我的投资组合是否平衡?”,财务顾问需要当前的估值、针对客户风险承受能力的压力测试以及实时市场数据,以制定他们可以捍卫的建议。财务顾问团队很久以前就通过分工解决了这个问题:投资组合经理对这本书进行估值,风险分析师对其进行压力测试,市场研究人员提出外部观点,顾问写出最终答案。多智能体系统遵循相同的方法,每个代理负责一个域,协调员协调专家做出最终响应。在这篇文章中,我们展示了如何在亚马逊弹性 Kubernetes 服务(亚马逊 EKS)、亚马逊 Bedrock 和亚马逊 Bedrock AgentCore 上构建该系统,并在每个层面进行身份验证、跟踪、成本控制和沙盒化代码执行。
类似的模式也适用于整个金融服务行业(FSI)。零售银行希望代理商同时对客户账本、欺诈信号和产品目录进行推理。保险公司需要能够协调承保、索赔和精算模型的代理人。资本市场需要将头寸、风险和实时报价相结合的代理商。不同的领域,相同的结构要求。几位狭隘的专家,一位协调员,每一个跳跃都有大量的企业基础架构。
最后一部分是代理框架和生产代理人工智能平台之间的差距。开源框架可以很好地处理编排、工具调用和多回合推理。差距是核心工作流程之外的一切:代理之间的身份验证、工具授权、合规审查员可以跟踪的跟踪、限制模型支出的单一地点以及运行模型刚刚编写的代码的安全方式。尽管这些注意事项可能不适用于概念验证,但它们是生产部署的必备条件。
生产 FSI 多智能体平台必须做什么:
-每个代理都必须拥有一个具有自己的提示、工具和范围权限的狭窄域名,因此治理审查是针对每个代理进行的,而不是针对一个巨大的提示进行的。
-架构必须对每个代理间调用和每个工具调用进行身份验证,并跟踪整个请求。当审计询问谁要求哪个代理做什么,代表谁做什么时,答案已经浮出水面了。
-LLM 呼叫必须通过中央网关进行路由,该网关处理速率限制、响应缓存、模型备份(例如,Claude Sonnet 回退到 Claude Haiku)和每个代理的支出跟踪。
-基础模型推理必须在 Amazon Bedrock 上的 AWS 账户内运行,这样推理数据就不会离开 AWS 账户边界。
-模型生成的任何代码(估值数学、模拟、转换)都必须在隔离的短暂沙箱中运行,不能访问 pod 机密、生产数据或集群网络。
-代理生命周期必须通过版本控制清单进行声明式管理,这样,新的专业代理将经历与集群上的任何其他工作负载相同的审查、批准和部署流程。
架构
在这篇文章中,我们设计了一个分层平台,将代理身份、工具访问、LLM 路由和安全代码执行分成独立的组件。每个层都是可部署、可观察和可管理的。该平台在 Amazon EKS 自动模式下运行,该模式管理 Amazon EKS 数据平面的计算自动扩展、联网、存储和安全。这就把集群配置留给了 Terraform,剩下的交给 GitOps 了。
本文重点介绍亚马逊 EKS、亚马逊 Bedrock 和亚马逊 Bedrock AgentCore 如何组合在一起以支持金融服务的多智能体系统。该参考实现包括四个使用 Strands Agents SDK 编写的代理、一个模型上下文协议(MCP)工具服务器、一个兼容 OpenAI 的 LLM 网关(LitellM)和一个面向整个系统的策略感知代理网关。
图 1。Amazon EKS 自动模式下的多智能体平台,带有 Amazon Bedrock 和 Amazon Bedrock AgentCore。
关键组件
Amazon EKS 自动模式
以普通的 Kubernetes 部署方式运行平台中的所有工作负载(代理、工具、网关、跟踪)。我们无需管理节点组或容器网络接口 (CNI) 插件即可获得命名空间、基于角色的访问控制 (RBAC)、Horizontal Pod Autoscaler (HPA)、GitOps 和 Pod 身份。AWS 负责计算自动扩展、安全补丁和基础设施操作,因此您可以专注于代理逻辑。
亚马逊基岩
处理所有基础模型推断。Claude Sonnet 4.6 是主要模型;Claude Haiku 4.5 是后备模型。请求不会离开 AWS 账户边界,Amazon Bedrock 可以无差别地处理管理模型基础设施的繁重工作。
Amazon Bedrock AgentCore
提供代理可以使用的三种托管功能:
-AgentCore 内存:保存协调器的跨会话客户档案(风险承受能力、目标、先前的建议)。
-AgentCore 代码解释器:在隔离的临时沙箱中运行模型生成的 Python 代码,提供安全审查人员所需的执行边界。
-AgentCore 浏览器:为市场数据代理提供可管理的无头浏览器,用于实时报价,因此我们不必将 Chromium 运送到每个 pod 中。
代理网关 (agentgateway.dev)
一个策略感知代理,位于每个代理和 MCP 工具服务器的前面。它终止针对 EKS OIDC 发行人的 Kubernetes ServiceAccount JWT,对每条路由的 jwt.sub 索赔强制执行 CEL 授权,并将 OTLP 跟踪导出到 Jaeger。其中一个组成部分就是我们如何为代理对代理 (A2A) 和模型上下文协议 (MCP) 提供相同的身份验证、授权和跟踪故事。
模型上下文协议 (MCP)
标准化代理与工具的交谈方式。我们的金融工具(get_stock_price、calculate_portfolio_value、score_risk、get_market_trends)存在于通过 MCP 可流式 HTTP 公开的单个 FastAPI JSON-RPC 服务器中。添加新工具只需要新功能和网关路由,无需更改代理代码。
代理对代理协议 (A2A)
一种协议,用于定义代理如何发现、委派和相互响应。财务顾问协调员使用 A2A 将任务委派给投资组合分析师、风险评估和市场数据代理人。由于每个 A2A 呼叫都流经网关,因此身份验证和授权规则是在网络层执行的,而不是在每个代理内部强制执行的。
LitelLM
一个兼容 OpenAI 的网关,可将 LLM 请求路由到 Amazon Bedrock。它对每个虚拟密钥强制执行每个 RPM 和 TPM 限制,在 Redis 中缓存响应,在限制或错误时从 Sonnet 回退到 Haiku,并将每次请求的支出持续到 PostgreSQL 上。这就是多智能体成本控制的用武之地。
Crossplane 加上 ArgoCD (GitOps)
Crossplane 托管资源声明每个代理的 AgentCore 内存、浏览器、代码解释器、IAM 角色和 Pod 身份关联。ArgoCD 的带有同步波浪的应用程序决定性地推动了平台的发展。添加新的专业代理是 Helm 值文件中的一个条目。
考虑一个典型的咨询问题:“考虑到该客户的风险承受能力和当今的市场,他们的投资组合是否平衡?”该应用程序使用短暂的 Kubernetes ServiceAccount JWT 调用 /agents/financial-advisor。代理网关针对 EKS OIDC 发行人验证代币,对 jwt.sub 索赔执行 CEL 授权政策。然后,该请求被转发到协调器代理。协调员从 AgentCore Memory 读取客户的个人资料(风险承受能力、目标、先前的建议)。然后,它通过网关向其专业代理发出三个并行的 A2A 呼叫。
图 2。跨四个代理的单一咨询请求的协调流程。
投资组合分析师代理通过调用 MCP 工具(get_stock_price、calculate_portfolio_value)对客户的头寸进行估值,并在 AgentCore Code Interpreter 中运行估值数学运算。风险评估代理在自己的代码解释器会话中根据客户规定的风险承受能力对分配进行评分。市场数据代理通过 AgentCore 浏览器提取实时报价快照。协调员将这三份专家的答复组合成一个统一的建议。
从安全角度来看,代理和 MCP 工具服务器之间的东西向流量停留在群集网络内,不会穿越公共互联网。代理使用 EKS Pod Identity 向 AWS 服务进行身份验证以代入 IAM 角色。这提供了最低权限的访问权限,无需在容器镜像或 Kubernetes Secrets 中嵌入静态凭证。LitellM pod 在我们允许的特定模型上承担仅限于 bedrock: invoke* 的 IAM 角色,在基础设施层强制实施模型级访问控制。每个 AgentCore 资源(内存、代码解释器、浏览器)都只绑定到一个代理的服务账户。每个专业代理只能访问自己的内存存储、自己的代码解释器沙箱和自己的浏览器会话。此隔离模型将每个代理限制为其自己的资源和权限。
实施要点
我们已经在 AWS 示例 GitHub 存储库中发布了参考实现。它包括用于 EKS 集群的 Terraform、ArgoCD 应用程序排行榜、AgentCore 的 Crossplane 组合、四个 Strands 代理和 MCP 工具服务器。运行 scripts/bootstrap.sh 将在大约 30 分钟内将一个干净的 AWS 账户带到一个工作平台。自述文件涵盖了先决条件和分步说明。
本节研究了关键配置决策并解释了每项决策背后的理由。
限制具有作用域能力的代理
每个代理都是用开源 Strands Agents SDK 编写的小型 Python 服务。三件事定义了代理的行为:限定范围的系统提示、允许其调用的 MCP 工具列表以及它必须使用的 AgentCore 功能。专家代理无法直接联系其他专家。网关将在专业路线上拒绝除协调员以外的任何 JWT 主题。
# financial-advisor/agent.py(摘录)@tool def ask_portfolio_analyst(任务:str)-> 字典:返回 a2a_client.call_agent(“投资组合分析师”,任务)@tool def ask_risk_assement(任务:str)-> 字典:返回 a2a_client.call_agent(“风险评估”,任务)@tool def ask_market_data(任务:str)-> dict:返回 a2a_client.call_agent(“市场数据”,任务)工具作为 MCP 服务器
这些金融工具存在于单个 FastAPI JSON-RPC 服务中,该服务实现了 MCP 可流式传输 HTTP。每个工具都有类型化架构和单元测试。当我们以后需要新工具时(例如选择税段),我们会将其添加到 MCP 服务器并通过网关进行路由。代理代码未更改。
A2A 和 MCP 通过一个策略感知网关
代理网关是 A2A 和 MCP 进行身份验证和身份验证的唯一场所。针对 EKS OIDC 发行人的身份验证是严格的 JWT。授权是 JWT 声明中的 CEL 表达式。对于专业路由,我们在 jwt.sub 上匹配为协调者的 ServiceAccount;对于 MCP 路由,我们匹配呼叫者是在清单中声明该工具的代理之一。
# AgentGatewayPolicy(摘录)规范:匹配:路线:投资组合分析师身份证:-表达式:| jwt.sub == “系统:服务账户:金融服务:金融顾问-sa”使用 LitellM 进行中央 LLM 路由
来自每个代理的每个 LLM 呼叫都会转到与 OpenAI 兼容的 Litellm 终端节点。LitellM 会检查虚拟密钥的 RPM 和 TPM 预算,检查 Redis 缓存中是否有匹配的提示,然后才会点击 Amazon Bedrock。如果主模型受限或出现错误,LitellM 会透明地从 Claude Sonnet 4.6 退回到 Claude Haiku 4.5。
LitellM 将每个请求的费用记录到 PostgreSQL 数据库,并提供一个 /spend API 端点,用于按代理、型号或时间范围查询支出。在没有集中式 LLM 路由层的情况下运行多智能体平台会给成本归因带来挑战。
使用 AgentCore 代码解释器安全执行代码
投资组合分析师和风险评估代理都在运行时生成 Python 代码,用于估值数学、分配检查和相关性计算。对于 FSI 工作负载,在代理容器中运行该代码不是一个选项:错误完成可能会读取密钥、调用集群 API 或出口数据。取而代之的是,每位专家都必须通过 Crossplane 连接到自己的 AgentCore 代码解释器。代理发送代码,代码解释器返回 stdout,代理解析结构化结果。该 pod 不执行生成的代码。安全边界由 AWS AgentCore 管理。
# portfolio-analyst/agent.py(摘录)llm_result = inner(“写出重视投资组合的 Python... 仅返回代码”)代码 = extract_python(llm_result.message ["content"] [0] [“文本”])输出 = CodeInterpreter (AWS_REGION) .invoke (code_interput_id=CI_ID,code=code) 返回 json.loads (output.stdout)使用 AgentCore 内存的跨会话内存
协调代理使用 AgentCore Memory 来保存顾问通常在 CRM 中保存的客户背景信息:风险承受能力、既定目标、先前的建议和限制。Orchestrator 每时每刻都会检索此上下文,并在客户确认新指南时对其进行更新。AgentCore 内存是为每个代理配置的,并以 actor_id 和 session_id 为密钥,因此专家无法读取协调器的上下文,并且客户端会话彼此隔离。
使用 AgentCore 浏览器的实时市场数据
市场数据代理使用 AgentCore 浏览器从金融数据提供商那里获取实时市场报价。浏览器在 pod 外部运行,这意味着我们不会在代理映像中提供 Playwright 或 Chromium。图像保持小巧,启动速度快且易于验证。
GitOps 开始使用 ArgoCD 和 Crossplane
两个简短的 Terraform 堆栈创建集群并安装 ArgoCD。其他一切都是 GitOps。Sync Waves 顺序推出:首先是 Crossplane 核心,然后是提供商,然后是代理网关,然后是 LitellM,然后是金融服务图表。在那张图表中,每个条目都进入。Values.Agents 提供跨平台内存、浏览器、代码解释器、IAM 角色、角色策略、PodIdentityAssociation、部署、ServiceAccount、AgentGatewayBackend 和 HttpRoute 以及 AgentGatewayPolicy。添加另一个合规性检查代理需要一个条目,如以下示例所示:
代理:-名称:合规检查角色:专家图片:{存储库:金融服务代理,标签:合规-v1} agentcore:内存:false 浏览器:false CodeInterpreter:false CodeInterpreter:真实工具:[]可观测性和 FinOps
该解决方案可以扩展为将 Jaeger 配置为从代理网关接收 OpenTelemetry 协议 (OTLP),因此每个用户请求都会生成一条涵盖协调器、其专家、他们的 MCP 工具调用以及 AgentCore 交互的跟踪记录。LitellM 公开了请求数、代币、延迟和每个模型支出的 Prometheus 指标,并保留了对 PostgreSQL 的每个请求的支出。要进行生产监控设置,请使用适用于 Prometheus 的亚马逊托管服务和 Amazon Managed Grafana,并将 LitellM 的 DATABASE_URL 指向亚马逊关系数据库服务 (Amazon RDS)。
设计注意事项
-该架构可以自然扩展,以支持额外的专业代理和不同的财务工作负载。添加新的专业代理是 Helm 值文件中的一个条目。Crossplane 呈现每个代理的 AgentCore、IAM 和 Pod Identity 资源,网关图表呈现路由和策略。新代理的范围正是通过标准 GitOps 管道审查的一个拉取请求。
-对于需要确定性数学(估值、风险评分、税收优化)的域名,让代理生成代码并在 AgentCore 代码解释器中运行,而不是将数学嵌入到提示符中。LLM 处理推理和决策逻辑。Python 处理数字。这种分离支持可重复和可审计的计算。
-将每个代理的范围限定为特定的 MCP 工具和特定的 AgentCore 资源。在网关层而不是代理代码内部强制执行范围界定。这旨在防止即时注入攻击到达网关不允许的路由,从而提供不依赖于模型正确行为的深度防御。
-在主动回退模式下运行 LLM 网关,而不是循环模式。留下 Claude Sonnet,供编曲家在质量最重要的领域进行推理。通过具有自己的支出限额的单独的 LitellM 虚拟密钥将机械子任务(汇总、JSON 整形、工具参数填充)路由给 Claude Haiku。那一个路由决定通常是合理的月度账单和令人惊讶的账单之间的区别。高级实现可以通过 LitellM 的虚拟密钥系统引入每位代理的支出上限和警报阈值。
-从一开始就开启追踪功能。在第一次合规性审查之后,将分布式跟踪改造为多智能体系统是困难的。从网关导出的 OTLP 是轻量级的,从一开始就使事件审查、审计响应和性能调试显而易见。
-将代理提示视为版本控制的工件。每位专家的系统提示对工作流程逻辑、合规状况和输出格式预期进行编码。审查并通过与应用程序代码相同的 GitOps 管道将其推出。这提供了对每个代理在任何时间点被指示执行的操作的全面可审计性。
-根据延迟要求对代理进行分层。面向客户的协调器可以将 minReplicas 维持在 1 或更多,以实现可预测的冷启动延迟。专业代理可以从较低的最低限度进行扩展,因为他们只能在委派给时调用,从而优化计算成本,同时保持协调层的响应能力。
-跟踪数据和 AgentCore 代码解释器执行日志共同构成了现成的证据、代理、提示、工具、代码、输出链,合规团队可以将其用作可解释性工件。
-对于 AgentCore 内存,确认 KMS 加密模型,设置明确的保留期或 TTL,使用删除 API 进行清除,并在内存不可用时在编排器中失败关闭。
-规划区域故障转移:ArgoCD 应用程序和 Crossplane 组合不受区域限制,可以将第二个 EKS 集群作为主动-被动目标,内存状态可从记录系统复制或重构。
结论
多智能体系统允许 FSI 组织构建看起来像其想要支持的咨询团队的软件。专家在狭窄的领域开展工作。协调员协调专家并撰写最终答案。共享平台处理身份、授权、跟踪、成本控制和安全代码执行。
在 Amazon EKS 自动模式下运行这种模式,对亚马逊基岩进行推断,在 Amazon Bedrock AgentCore 上运行这种模式,为平台团队提供了可以逐步采用的蓝图。你不必在 “实验框架” 和 “我们自己构建的自定义平台” 之间做出选择。您可以从一名协调员和一名专家开始,然后将下一位专家添加为可通过 GitOps 部署到您的 Kubernetes 集群的拉取请求。参考实现存储在 AWS 示例 GitHub 存储库中。
准备好探索更多了吗?查看金融服务 AWS 博客,了解专为应对金融服务行业独特挑战而设计的其他模式和解决方案。