TCS 如何用 Amazon Bedrock AgentCore 构建智能体测试编排器

本文与 Tata Consultancy Services (TCS) 的 Varun Valsan 共同撰写。

Tata Consultancy Services (TCS) 为银行、金融服务和保险 (BFSI) 客户运行大规模测试，在这些场景中，发布过程中最慢的环节很少是编写应用代码。更大的制约来自后续的一系列工作：解读需求、设计场景、编写和维护自动化、准备执行环境、调查失败原因，以及为评审整理证据。

BFSI 客户需要在保持金融服务所要求的管控的同时提高测试吞吐量。目标并不是取代质量工程师，而是消除重复性的转换和执行工作，让工程师能把更多时间花在风险分析、探索性测试和发布决策上。这些行业需求为 TCS 提出了四项具体要求。第一，每个测试都必须基于项目特定的上下文，而不是通用提示。第二，必须同时覆盖 API 和基于浏览器的 UI 测试，以匹配 BFSI 应用的构建方式。第三，安全性至关重要，因此每个租户的数据和知识存储都必须隔离。最后，必须提供一条从需求摄入到测试证据和报告的可重复路径，使收益能够在各团队和各个发布版本中持续保持。在本文中，我们将展示 TCS 如何构建一个智能体测试编排器，将需求转化为可执行、受治理的测试，以及这为其 BFSI 测试团队带来了哪些改变。

为什么传统自动化和系统还不够

TCS 已经为其客户使用传统测试自动化，这确实提高了执行速度。但它并未触及那些缓慢的工作：团队仍然必须创建场景、将其转换为脚本、维护定位器和依赖关系，并诊断失败原因。当一个关联的用户故事发生变化时，为较早故事生成的脚本可能很快就会过时。单一的生成式 AI 提示也无法提供多阶段工程工作流所需的控制力。

因此，TCS 设计了 Agentic Test Orchestrator，将测试分解为专门的任务。每个任务都有自己的智能体、工具、验证规则和上下文。一个确定性的监督器负责路由工作，而一个执行工作流负责控制重试、错误分类、持久化和报告。

为了运行这些智能体，TCS 选择了 Amazon Bedrock AgentCore，这是一项可在任意框架或模型下大规模构建、连接和优化智能体的服务。有三项能力促成了这一决定。第一，Amazon Bedrock 提供多种模型选择，因此每个智能体都能使用适合其任务的模型，例如场景设计或代码生成，并且 TCS 可以在新模型推出时采用它们。第二，AgentCore 运行时（Amazon Bedrock AgentCore 的一项能力）可随需求扩展，因此众多租户的测试人员可以同时运行生成和执行会话，而无需 TCS 自行配置或调优智能体服务器。第三，运行时在各自隔离的 microVM 中运行每个会话，这为 TCS 的多租户平台提供了会话级隔离，而无需自行构建该层。这些能力共同让 TCS 能够将工程精力集中在测试逻辑上，而不是智能体基础设施上，从而缩短了将平台交付给 BFSI 客户的时间。

解决方案概述

下图展示了该平台跨五个阶段的端到端流程，底层是每租户安全层。来自 Jira、业务需求文档（BRD）和 GitLab 的输入进入租户 Web 应用，该应用运行在 Amazon Elastic Kubernetes Service（Amazon EKS） 上，位于 Amazon CloudFront 之后，并通过 Amazon Cognito 登录。TCS 使用 Amazon Bedrock AgentCore 运行时托管平台的专业化代理，这些代理使用 Strands Agents SDK 构建。这些代理生成测试、与测试人员一起完善测试，并管理测试的执行。Amazon Elastic Container Service（Amazon ECS） 运行生成的测试。Amazon Simple Storage Service（Amazon S3） 和 Amazon DynamoDB 存储结果，Amazon CloudWatch 捕获日志。在整个过程中，AWS WAF、Amazon Cognito、AWS Key Management Service（AWS KMS） 和 AWS Secrets Manager 实施每租户的安全与隔离。

图 1：高层解决方案架构

TCS Agentic Test Orchestrator 是构建在 AWS 上的多租户软件即服务（SaaS）解决方案。测试人员通过 Jira 故事、业务需求文档（BRD）、Swagger 规范、上传的文档、GitLab 源代码文件夹或捕获的 UI 流程提供需求。平台随后根据这些输入生成测试场景、Gherkin 功能文件和可执行的 Java 或 Python 测试。它在 Amazon ECS 上运行这些测试，存储产物和结果，并在每租户 Web 应用中显示进度和报告。后续各节描述平台的每个部分如何满足 TCS 设定的四项要求之一。

1. 将控制平面与每个租户应用平面分离

TCS 要求严格隔离每个租户的身份、数据和密钥，因此平台采用池化计算，同时隔离数据与身份。共享控制平面提供 Amazon EKS 集群、容器注册表、管理门户、租户注册表、入门自动化、Amazon CloudFront 分发和 AWS WAF 保护。每个租户应用平面获得自己的 Kubernetes 命名空间、Amazon Cognito 用户池、AWS KMS 密钥、Amazon S3 存储桶、Amazon DynamoDB 表和 Amazon Bedrock Knowledge Bases。这种分离为每个 BFSI 租户提供了金融服务管控所要求的数据和密钥边界。

租户入门是事件驱动的。管理 API 写入待处理租户记录，通过 Amazon EventBridge 发出事件，并启动一个 AWS CodeBuild 项目，该项目使用 AWS Cloud Development Kit（AWS CDK）部署租户基础设施。此模式使租户配置可重复，同时保留 TCS 所需的租户特定身份和数据边界。

2. 让每个代理基于项目上下文

TCS 的第一项要求是生成内容应反映每个项目的领域，而不是通用提示，因此平台内置了上下文基础。平台将上传的需求和生成的产物存储在 Amazon S3 中，将会话元数据存储在 Amazon DynamoDB 中。项目文档和同步的源文件使用向量嵌入在 Amazon Bedrock Knowledge Bases 中建立索引。在材料到达代理之前，检索会按租户、项目和会话上下文进行过滤，因此一个客户的上下文不会影响另一个客户的测试。

这个上下文层支持 BFSI 团队表达需求的多种方式：Jira 故事及关联的故事链、BRD、Swagger 定义、参考代码、定位器文档、设置模块、测试数据以及 GitLab 源文件夹。对于 UI 自动化，一个独立的捕获服务使用 Puppeteer 将 URL 和自然语言目标转换为 UI 流程文档和 XPath 定位器文档。

3. 使用专用代理而非单个大型提示词

由于单个提示词无法为受监管的工作流提供所需的控制力，该平台将工作分配给多个专用代理，这些代理使用 Strands Agents SDK 在 Amazon Bedrock AgentCore 运行时中作为容器化服务运行。一个生成运行时将请求路由到专用的场景、Gherkin、代码生成和验证工具。其他运行时支持对话式优化、BRD 到故事的转换、跨关联 Jira 故事的增量生成以及测试执行。每个代理负责生命周期中的一个阶段。以下是每个专用代理的简要概述：

生成代理：创建结构化场景，将其转换为 Gherkin，生成 Java 或 Python 自动化代码，并验证生成的代码。

聊天代理：将请求分类为信息查询或更新请求，然后回答或修订当前活动工件。

动态任务代理：检索 BRD 上下文，并生成包含需求和验收标准的结构化用户故事。

增量代理：在关联的 Jira 故事链中扩展场景、Gherkin 或代码，而非从头开始。

执行代理：获取工件，选择执行环境，运行测试，对失败进行分类，应用受控修复，并保存最终结果。

4. 将 API 和 UI 测试路由到正确的执行环境

TCS 需要同时覆盖 API 和基于浏览器的 UI 测试，这两者对基础设施有不同的要求，因此执行代理从生成的代码中检测测试类型并进行相应路由。API 测试被路由到 AWS Fargate 上的 Amazon ECS。Selenium UI 测试被路由到由 Amazon Elastic Compute Cloud (Amazon EC2) 支持的 Amazon ECS 集群，执行器可在其中通过虚拟显示运行 Chrome。

对于 UI 运行，执行器可以使用 FFmpeg 捕获虚拟显示，并将 HTTP Live Streaming (HLS) 流发布到 Amazon S3，通过 Amazon CloudFront 进行分发。测试日志发送到 Amazon CloudWatch，生成的 Cucumber 报告存储在 Amazon S3 中，并设置限时访问。

5. 控制执行与修正循环

为使自动修正对 BFSI 流水线足够安全，执行代理将其获取、执行、修复和保存步骤定义为 LangGraph 工作流。LangGraph 的显式状态图赋予 TCS 固定的步骤顺序和有界的重试循环，而 AgentCore 运行时负责托管、扩展和隔离运行该工作流的代理。获取节点检索测试项目和生成的资产，清理文件并检测框架。执行节点启动选定的 ECS 任务，监控状态，检索日志并解析结果。

当失败被归类为代码错误且重试策略允许时，修复代理会收到受限的错误上下文，并提出有针对性的修正。安全检查会拒绝空文件、意外的新文件或文件大小的极端变化。环境错误（例如连接或身份验证失败）不会发送给代码修复器。保存节点会持久化最终代码、状态、尝试次数、日志、解析结果和报告位置。

6. 安全与运营控制

由于该解决方案服务于受监管的 BFSI 租户，它在身份、网络、数据和应用层都应用了控制措施。在身份方面，独立的 Amazon Cognito 用户池分别服务于平台管理员和每个租户，并带有后端 JSON Web Token (JWT) 验证和基于角色的授权。在数据方面，每个租户拥有自己的 AWS KMS 密钥和加密的 Amazon S3 存储，DynamoDB 访问按租户限定范围，AWS Secrets Manager 保存 Jira 和 GitLab 凭据。在 Amazon EKS 上的工作负载层面，Kubernetes 命名空间、NetworkPolicy 和 ResourceQuota 将租户隔离开来，容器以非 root 身份运行并丢弃 Linux 能力。在网络边缘，AWS WAF 托管规则和请求速率控制保护平台。流量通过 Amazon CloudFront 和 Application Load Balancer 以 HTTPS 传输，响应带有严格的安全标头。在所有这些之上，OpenTelemetry 追踪捕获代理活动，而 Amazon CloudWatch 日志和 Container Insights 提供应用和执行可观测性。

成果

TCS 为其 BFSI 客户在生产环境中运行 Agentic Test Orchestrator。为了量化节省的工作量，TCS 在一个约 100 个测试场景的代表性 BFSI 工作负载上，将该解决方案与现有流程进行了对比测量。在手动流程中，每个场景大约需要两小时的工程师工作量来设计、编写脚本和执行，整个集合约需 200 小时。使用 Agentic Test Orchestrator 后，每个场景的平均工作量约为 14 分钟，使相同工作负载降至约 24 小时。在此对比中，工作量减少了 88%。（这些数字来自 TCS 在约 100 个场景上运行的受控内部基准测试。实际结果因工作负载、应用复杂度和团队而异。）

对 TCS 而言，工作量数字不如其背后的运营模式重要。需求摄取、生成、执行、修正和报告现在形成一个可追溯的工作流，而不是一连串断开的交接。质量工程师审查和治理 AI 生成的产物，而不是手工构建它们，这使他们的时间回归到手动流程所挤占的风险分析、探索性测试和发布决策上。这就是 TCS 想要达到的成果。

结论

TCS 着手解决的问题不仅仅是测试执行缓慢。问题在于从业务需求到可信测试证据的碎片化手动路径。这是 BFSI 发布中消耗工程时间却不增加保障的部分。在本文中，我们展示了 TCS 如何在 AWS 上构建 Agentic Test Orchestrator，通过结合上下文检索、专用代理、工作负载感知执行、按租户隔离的服务和可观测基础设施来弥合这一差距。

其结果是一种可复用的模式，可将生成式 AI 应用于软件质量工程，而不必将测试简化为单一提示词。Amazon Bedrock AgentCore 负责托管和扩展各代理，Amazon Bedrock 和 Amazon Bedrock Knowledge Bases 提供 AI 能力和项目上下文，Amazon EKS 托管按租户划分的应用层，Amazon ECS 提供适配用途的执行能力，AWS 的安全、存储、集成和可观测性服务则支撑整个生命周期。对于 TCS 的 BFSI 团队而言，收益在于更快、更一致的测试流程，将工程师的时间重新投入到风险、质量和发布决策上。

如需了解更多并在您自己的环境中部署该解决方案，请访问 AWS Marketplace 中的 TCS Agentic Test Orchestrator。如果您希望获得帮助，将此模式应用于您自己的测试工作流，请联系 AWS 团队。如有疑问或类似用例？欢迎在评论区分享。

关于作者

Varun Valsan

Varun 是 Tata Consultancy Services（TCS）的生成式 AI 团队负责人，负责领导面向企业客户的代理式 AI 解决方案的设计与交付。他主导了 TCS Agentic Test Orchestrator 的开发，将生成式 AI 和多代理架构应用于软件质量工程。

Rahul Singh

Rahul 是 AWS 的高级解决方案架构师，帮助全球系统集成商和企业客户在 AWS 上设计安全、可扩展的解决方案。他专注于生成式 AI、代理式架构和应用现代化。

Punyajit Bhattacharya

Punyajit 是 AWS 的高级客户解决方案经理，与客户合作加速其云采用和转型之旅，推动大规模项目交付并实现可衡量的业务成果。