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

本文由我们与塔塔咨询服务公司（TCS）的 Varun Valsan 共同撰写。

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

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

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

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

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

为了运行这些智能体，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 capabilities。在网络边缘，AWS WAF 托管规则和请求速率控制保护着平台。流量通过 HTTPS 经由 Amazon CloudFront 和 Application Load Balancer 传输，响应携带严格的安全标头。在所有这些之上，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 团队。有问题或有类似的用例？欢迎在评论中分享。