从单团队到五十团队：自主 QA agent 的 Serverless 转容器决策框架

QA团队在交付复杂产品时，全天候都在产生测试失败。每个失败都需要一张缺陷工单，包含复现步骤、截图、复现率和回归标签。手动处理每个失败要花10到15分钟。一个团队每周有30多个失败，乘起来就是整整一个工程日，全耗在本应自动化的文档工作上。

我构建了一套系统来彻底消除这项工作。它不是仪表盘，也不是通知机器人，而是一个自主agent：它观察测试结果，做出判断——这是新缺陷、重复缺陷还是回归？——并在无人干预的情况下采取行动。它会提交结构化的缺陷、附上截图、计算复现率、按构建版本检测回归，并通知对应的人。团队只需标记FAIL，然后继续干活。

这套系统目前跑在Lambda上。对单个团队来说，它运行得非常完美。但其他团队也想要呢？当你需要服务10个、50个甚至100个团队时，会发生什么？架构决策的有趣之处正在这里——不是因为Lambda不行了，而是因为工作负载特征发生了变化，进入了另一种工具更合适的领域。

我构建了什么（以及它为什么有效）

架构很简洁：一条EventBridge规则每15分钟触发一次Lambda函数。该函数轮询测试管理API，通过决策引擎处理失败（对照DynamoDB做去重检查，对照上一次构建结果做回归检测），再通过JIRA API提交缺陷。基础设施总成本：每月不到5美元。

在这里，Lambda是正确的选择，原因有三：

• 零运维开销：没有服务器，没有扩缩容配置，没有补丁。部署完就不用管了。
• 成本与用量成正比：一个团队每月大约产生200次调用。按Lambda的定价，这基本等于免费。
• 迭代快：决策引擎在第一个月里改了20多个版本。Lambda的部署模型让我能在几秒内发布变更。

上线几周内，这套系统提交的缺陷就比团队手动产出的更完整、更一致。零遗漏失败。回归在几分钟内就被发现，而不是几天。QA被打断询问状态的情况降到了零，因为任何人都可以通过Slack直接查询系统。每周节省8到10小时。

其他团队注意到了。“我们也能用吗？”成了一个反复出现的问题。答案看起来很简单——每个团队再部署一个实例。但在规模化时，工作负载特征会发生变化，从而改变架构决策。

扩展决策

Lambda能很好地处理单租户的agent工作负载。多租户规模下的挑战不在于Lambda做不到，而在于工作负载特征发生了转变：

从无状态事件到长时运行的上下文：单个团队的轮询周期几秒就结束。但跨项目关联——比如“这是不是我们在三个团队中都看到的同一种失败模式？”——需要在一次处理中分析数百条结果及其相互关系。这是完全不同的计算特征。

从隔离调用到共享资源争用：当50个函数按同一个EventBridge计划触发时，它们会同时打到TestRail和JIRA的API上。你需要集中式限流、连接池和背压——这些模式更适合持久化的共享基础设施。

从单团队到多租户隔离：每个团队都需要有保障的资源、网络边界和限定范围的凭证。隔离模型变得和计算模型同样重要。

Lambda最近的发布分别解决了其中不少问题——Managed Instances解决了连接持久化，Durable Functions打破了长时运行工作流15分钟的上限，Tenant Isolation提供了原生的租户边界。对许多多租户工作负载来说，这些能力大幅缩小了差距。

但对于这个特定工作负载——需要同时具备持久连接、跨租户分析、GPU推理和命名空间级隔离的长时运行agent——决策框架指向一种容器原生、运维体验类似serverless的执行模型。这正是EKS Auto Mode的用武之地。

决策框架

这促使我建立了一个简单的决策标准——不是Lambda对容器，而是你的工作负载实际表现出哪些特征？

“对我这个工作负载的决定性因素：我需要同时具备右列的全部特征。合在一起，它们在容器原生环境里组合得更自然。”

我这个工作负载的决定性因素在于：我需要同时具备右列的所有特征。跨团队模式检测需要共享的分析上下文。基于ML的缺陷分类需要突发GPU。按团队隔离需要命名空间级边界。集中式限流需要持久化的共享服务。每一项在Lambda中都能单独解决。但合在一起，它们在容器原生环境里组合得更自然。

规模化带来的能力：跨团队智能

多租户规模下最有意思的架构能力不是按团队的自动化，而是跨团队模式检测。这正是这次扩展工作值得做的原因。

跨团队失败关联

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）