TCS 用专用代理分解测试工作流，以 LangGraph 有界循环约束自动修正
印度IT服务公司TCS在AWS博客上介绍了其为银行、金融和保险客户构建的Agentic测试编排器。核心设计判断是：单一提示无法为多阶段工程工作流提供足够控制，因此将测试生命周期拆分为场景生成、Gherkin转换、代码生成、验证和执行等专用代理，由确定性监督者路由，并用LangGraph状态图约束修正循环的重试次数和安全性检查。TCS内部基准显示在约100个测试场景上每场景平均工时从约2小时降至约14分钟，但该数据为厂商自报，未经独立复现。
传统测试自动化改善了执行速度，却没有触及BFSI发布流程中最慢的环节。印度IT服务公司TCS在AWS机器学习博客（与TCS的Varun Valsan合写）中描述了这个具体问题：团队仍需创建场景、将其转换为脚本、维护定位器和依赖关系、诊断失败。当关联的用户故事发生变化时，为较早故事生成的脚本会迅速过时。
TCS认为，单一生成式AI提示同样无法为多阶段工程工作流提供所需控制。他们的回应不是用一个更大的提示，而是将测试生命周期分解为专用任务，每个任务拥有自己的代理、工具、验证规则和上下文。一个确定性监督者负责路由工作，而执行工作流控制重试、错误分类、持久化和报告。
具体而言，平台包含五类专用代理：生成代理创建结构化场景并转换为Gherkin、生成Java或Python自动化代码并验证；聊天代理将请求分类为信息查询或更新请求；动态任务代理检索BRD上下文并产出结构化用户故事；增量代理跨关联Jira故事链扩展已有产物而非从头开始；执行代理获取产物、选择环境、运行测试、分类失败、施加受控修正并保存结果。
修正循环的设计是这篇文章对实践者最有参考价值的部分。执行代理将获取、执行、修正和保存步骤定义为LangGraph工作流。LangGraph的显式状态图给出固定步骤顺序和有界重试循环。当失败被分类为代码错误且重试策略允许时，修正代理接收约束后的错误上下文并提出针对性修正。安全检查会拒绝空文件、意外新增文件或文件大小的极端变化。环境错误——如连接或认证失败——不会被发送给代码修正器。
TCS在约100个测试场景的代表性BFSI工作负载上测量了效果：手动流程每场景约需2小时工程师工时（全量约200小时），使用编排器后平均约14分钟（全量约24小时），报告为88%的工时减少。文章明确标注这来自受控内部基准，实际结果因工作负载、应用复杂度和团队而异。
这个架构的可迁移认识不在于88%这个数字——它未经独立复现——而在于对单提示控制不足的工程诊断，以及用确定性路由、代理专业化、状态图约束修正和安全检查边界来替代它的具体设计选择。对于需要在受监管环境中使用生成式AI辅助工程工作流的团队，这些机制比性能声明更具参考价值。