TCS 用多智能体编排金融业务测试

TCS 把 AI 用在了测试里最费人工的那段链路：读需求、设计场景、写脚本、跑测试、查失败，再整理审核证据。在约 100 个场景的内部对照中，工程师投入从约 200 小时降到约 24 小时，减少 88%。

但这篇案例值得看的，不只是这个数字。它展示了怎样把生成代码放进有边界、可追踪的工程流程：模型负责分工明确的任务，固定流程负责调度、重试和保存结果，质量工程师继续掌握审核与发布判断。

为什么已经有自动化测试，还要再加一层编排

TCS 服务的是银行、金融服务和保险行业，原文统称 BFSI。这类项目已有传统自动化测试，但自动化通常从「脚本已经写好」开始提速。脚本之前的需求理解、场景设计，以及脚本之后的故障定位、报告整理，依然需要大量人工。

需求变化还会让问题叠加。一个 Jira 用户故事关联了后续故事，早先生成的脚本就可能过时。执行速度再快，也无法自动补齐变化后的验收条件。

因此，TCS 要解决的是从业务需求到测试证据的整条链路。平台接收 Jira stories、业务需求文档（BRD）、Swagger specifications、GitLab 源码目录、上传文件和捕获的 UI 流程，随后生成测试场景、Gherkin feature files，以及可执行的 Java 或 Python 测试。

Gherkin 可以理解为连接业务场景与自动化实现的结构化描述：先明确要验证什么，再落到代码。

作者提出了四项要求：生成结果必须依托项目上下文；同时覆盖 API 和浏览器 UI 测试；租户数据与知识库必须隔离；需求导入到报告输出必须能够重复执行。

真正被自动化的，是测试过程中反复发生的信息转换与任务交接。

这也解释了为什么他们没有停在一个大提示词上。单次生成可以交付一份脚本，却很难同时约束上下文来源、执行环境、失败处理和证据保存。

多个 Agent 怎么合作，才不会变成互相聊天

TCS 将 Agent 作为容器化服务运行在 Amazon Bedrock AgentCore runtime 上，使用 Strands Agents SDK 构建。任务路由由确定性的监督器负责，每个环节有自己的工具、校验规则与上下文。

这里的「确定性」很关键：下一步做什么，主要由明确的流程规则控制，而不是让模型每次临场决定。

平台按职责拆出五类 Agent：

• Generation agent 生成结构化场景、Gherkin 和 Java 或 Python 自动化代码，并校验生成代码。
• Chat agent 先判断请求是查询还是修改，再回答问题或更新当前产物。
• Dynamic task agent 从 BRD 检索信息，整理出包含需求与验收标准的用户故事。
• Incremental agent 沿关联的 Jira 故事链扩展已有场景、Gherkin 或代码。
• Execution agent 获取产物、选择环境、执行测试、分类失败、实施受控修复并保存结果。

分工能否成立，取决于输入是否可靠。项目文档与同步源码被索引进 Amazon Bedrock Knowledge Bases，使用向量嵌入支持检索；材料交给 Agent 前，还要按租户、项目和会话过滤。Amazon S3 保存文档及生成产物，Amazon DynamoDB 保存会话元数据。

对于 UI 自动化，单靠需求文本还不够。独立的捕获服务使用 Puppeteer，把 URL 与自然语言目标转换为 UI 流程文档和 XPath 定位器文档，让后续生成有页面操作与元素定位依据。

AgentCore 在这里承担的是运行基础设施：按需求扩缩容，每个会话运行在独立 microVM 中。Amazon Bedrock 提供模型选择，团队可以按场景设计、代码生成等任务选模型。不过，原文没有披露具体模型名，也没有提供不同模型的效果对照。

自动修复能走多远，必须提前写进流程

执行阶段，平台从生成代码识别测试类型，再分配环境：API 测试进入 Amazon ECS on AWS Fargate；Selenium UI 测试进入由 Amazon EC2 支撑的 Amazon ECS 集群，在虚拟显示环境里运行 Chrome。

UI 执行还可以用 FFmpeg 捕获虚拟显示，生成 HTTP Live Streaming（HLS）流，发布到 Amazon S3，再通过 Amazon CloudFront 分发。日志进入 Amazon CloudWatch，Cucumber 报告存入 Amazon S3，并提供限时访问。

这些产物让审核者能够回看测试发生了什么，而不只是拿到一个成功或失败的状态。

更重要的是失败之后怎么办。TCS 用 LangGraph 将执行 Agent 固定为 fetch、execute、fix、save 流程，并限制重试次数：

fetch 获取测试项目与生成资产，清理文件并识别框架；execute 启动 ECS task、监控状态、获取日志并解析结果。只有失败被归为代码错误，且重试策略允许，才交给修复 Agent。

修复 Agent 收到的是受约束的错误上下文，只提出针对性修改。安全检查会拒绝空文件、意外新增文件，以及文件大小变化过于极端的修改。连接失败、认证失败等环境错误不会进入代码修复环节。最后，save 保存代码、状态、尝试次数、日志、解析结果和报告位置。

自动修复的边界，应该由错误分类、修改校验和重试上限共同决定。

原文没有给出具体重试次数，也没有说明文件大小变化阈值。这是一套可借鉴的流程设计，还不是能够直接照抄的完整配置。

多租户边界同样由基础设施落实。共享控制平面提供 Amazon EKS 集群、管理入口等能力；每个租户拥有独立 Kubernetes namespace、Amazon Cognito user pool、AWS KMS key、Amazon S3 bucket、Amazon DynamoDB tables 和 Amazon Bedrock Knowledge Bases。

租户开通通过 Amazon EventBridge 触发 AWS CodeBuild，再用 AWS CDK 部署。运行期间还有 JWT 校验、角色授权、NetworkPolicy、ResourceQuota、非 root 容器、移除 Linux capabilities、AWS WAF 与 AWS Secrets Manager 等控制。OpenTelemetry、Amazon CloudWatch 和 Container Insights 记录活动与运行状态。会话 microVM 隔离只是其中一层。

我的判断

这篇案例最有价值的地方，是把 Agent 放回了工程约束之中。模型生成内容，流程管理状态，执行器运行测试，工程师审核产物。相比直接让模型读需求并输出脚本，这种方式更容易定位问题究竟出在需求理解、代码生成还是运行环境。

但 88% 的节省要带着口径看。作者称平台已经服务生产中的 BFSI 客户；量化结果来自约 100 个场景的受控内部基准。原流程每个场景约需 2 小时，合计约 200 小时；使用平台后平均约 14 分钟，合计约 24 小时。这里衡量的是工程师投入，不是发布周期缩短了 88%。

原文没有展开场景难度、人工审核耗时如何计入，也没有给出覆盖率、缺陷发现能力、误修率及模型与云资源成本。它证明这组工作负载节省了人工，尚不足以证明测试质量同步提升，或者所有团队都有同等收益。

多 Agent、按任务选模型、独立租户资源各有道理，但作者没有提供它们与更简单方案的对照数据。选型收益仍属于案例经验。对于单项目团队，现有 CI 加一个生成与审核步骤，可能已经能覆盖相当一部分需求；金融多租户平台需要的整套隔离设施，未必是起步条件。

修复检查也有局限。拒绝空文件或异常体积变化，可以拦住部分破坏性修改，却无法判断断言是否被削弱。测试变绿之后，仍要检查它是否继续验证原来的业务要求。

能拿来做什么

• 如果团队已经使用 Jira、Swagger 和自动化测试，可以先把需求、验收标准、参考代码、定位器及测试数据整理成同一项目的上下文，并让生成结果关联来源，减少反复补充提示词的工作。
• 对已有 API 或 Selenium UI 测试，先接通「执行、日志、结果解析、报告保存」链路。生成脚本有了稳定的验证出口，才能判断它是否真正可用。
• 给 AI 编程中的自动修复设置明确入口：只处理可归因的代码错误，限制重试次数，保留每次修改与执行记录；认证和连接故障交回环境排查流程。
• 参照作者的方法，用同一批有代表性的场景比较人工投入，同时记录审核时间、有效断言变化和运行成本，再决定是否扩大自动化范围。