夯爆了！又一款开源企业级一站式AI智能测试平台！（附平台架构、技术选型）

国庆节前，我在 AI 进化社 里做了一轮针对学员所在企业 AI 使用现状调研。

几个数字先摆出来。

近 95% 的学员企业已经启动了 AI 转型，一半的人提到自己公司「多部门大规模使用」。但企业里实际落地的 AI 项目，80% 集中在知识库管理、开发提效这两类门槛最低的场景，RPA、Agent、智能质检这类深度业务项目渗透率不足 40%。一边几乎全员启动，一边集体停在浅水区。

中间卡着什么？

其实在调研结果，企业领导们对 AI 提效的要求中已经给出了答案：要提效量化指标、要业务打通、要替代重复人力。

具体到产研岗，「测试全流程 AI 化」是出现频率最高的一项，比如：「测试用例 80% 由 AI 自己跑」「周迭代改日迭代」这样的量化硬指标在企业里，已经成为了常态。

一句话概括：AI大势所趋，上面要结果，下面缺能力。

这就是 2026 年测试团队的真实处境，也是AI 智能测试平台实战专项要解决的问题。

1024 程序员节将至，给大家准备了专属节日福利，见文末~

1. 这个项目在 AI 进化社的定位

「AI 进化社」截止目前围绕 AI 测试能力建设，已经沉淀了不少知识干货。

比如，在AI 测试实战系列中，我们把接口和 UI 自动化里的单点能力一个个拆开验证过：文档智能解析、测试数据构造、脚本批量生成、执行调度、失败自动诊断、报告生成，每一环都做成了能独立跑的 Agent Skill （目前针对AI测试全流程，已经沉淀了30多个专项自研Skill了）。

在LLM大模型与Agent测评体系专栏中，我们更新了十几篇教程，该专栏搭建起了完整的 AI 测评知识体系，串联起 AI 测评全流程：从评测方法论、测评集搭建、指标设计、评分方案，到 Promptfoo、DeepEval、RAGAS、Langfuse 等主流评测工具选型与实操，搭配 RAG、Agent 真实项目测评实战，最终完成评测能力工程化，打通 CI 门禁与平台化落地，实现从 0 到 1 一体化掌握大模型、AI Agent 测评落地能力。

但，这些内容有一个共同的局限，它们大多是用于解决工作中某类具体场景的问题。而不同场景下的问题，需要用的工具、方法、技术手段皆会不一样，缺少统一的载体。

而我们这个AI智能测试平台项目，核心目标就是把这些分散的能力收拢、整合，沉淀成一套统一、可复用的企业级解决方案。它也是 AI 进化社 2026 年最重磅综合实战项目，目标是带着大家从零搭建一站式 AI 智能测试平台，覆盖自动化（单元、接口、Web、App）、性能、安全、测评、RAG、Agent、Harness全场景，打通并实现各类测试能力和业务场景深度结合。

值得一提的是，该项目会作为AI 进化社子专栏的方式来连载更新，内容形式上，采用图文教程加视频讲解双形式连载。

• 图文教程，包含保姆级完整的开发细节，设计思路、架构决策和完整代码（零基础也能也看的懂）；
• 视频教程，侧重带操作演示和完整实操过程，核心知识真人讲解，边看边搭跟着做。两种形式内容互补，节奏一致。

2. 为什么必须是平台，不能是一堆工具

先看一个很多团队正在经历的场景。

团队里几个骨干各自用 AI 用得风生水起。有人拿大模型生成接口用例，有人写了自己的脚本生成提示词，有人搭了条失败日志分析的流水线。每个人都在提效，但能力全部长在个人电脑里。骨干一离职，这些能力跟着人走，团队水平一夜回到解放前。这是第一个问题，能力不沉淀。

第二个问题，质量口径不统一。

同一个需求，两个人让 AI 生成的用例放在一起，颗粒度、覆盖面、异常场景的敏感度差异巨大。调研里 60% 的企业把人才缺口列为推进 AI 的第一阻力。

会用 AI 工具的人企业并不难招，难找的是能把 AI 嵌入业务流程、有能力判断 AI 输出质量的人。散装工具模式下，这种判断力更没法标准化，好坏全凭个人手感。

第三个问题，管理看不见。

AI 生成了多少用例、自动执行占比多少、失败后多少能自愈，这些领导点名要的量化指标，在散装模式下根本取不到数。资产散在个人电脑里，报表编不出来。

第四个问题最实际，企业环境进不去。

调研里有大量同学来自政企和传统行业，内网无外网、接口鉴权复杂、历史系统文档缺失。跑在公网、依赖云端大模型直接调用的散装工具，在这些环境里第一步就卡死。能私有化部署的平台，是这类企业用上 AI 的唯一通道。

所以平台化的本质，是把「少数人的 AI 能力」升级成「整个团队的基础设施」。能力沉淀在平台里，质量标准固化在流程里，指标从平台数据里长出来，部署形态适配企业环境。

还有一层 AI 时代特有的变化值得提一下。传统测试平台，禅道、TestLink 这一类，定位是管理工具，管理的是人写好的用例、人提的缺陷。

而 AI 时代的智能测试平台，AI 本身是干活的主体，生成用例、写脚本、跑执行、做诊断，人退到审核和决策的位置。干活的过程、审核的动作、沉淀的数据全部发生在平台里，数据又反过来让 AI 越用越准。平台从「管理工具」变成了「生产力本体」，这是这一轮平台建设与传统测试平台最本质的区别。

3. 平台架构设计：分层骨架，插件场景

先说架构怎么设计？ 平台架构设计不是打开画图软件直接拖框就完事了，真正花功夫的是画图之前的三件事。

行业里画架构图通用的做法：

第一，梳理需求：功能需求、非功能需求（性能、可用性、安全、能不能私有化部署）、现实约束（团队技术栈、预算、交付环境），全部列出来——后面每个架构决定，都要拿这份清单来检验。

第二，选架构风格：单体分层、微服务、事件驱动、插件化（微内核），业界常用的就这几类。

如果是中小体量选单体分层图个省心，功能模块要频繁增减的选插件化图个灵活，没有哪种风格全面胜出，只有合不合适。

第三，才是划边界：定分几层、每层管什么、依赖朝哪个方向走、接口契约长什么样。

这三步想清楚，才轮得到画图。而不管架构风格怎么变，几条铁律恒定不变：高内聚低耦合、职责单一、依赖单向。

回到我们这个AI 智能测试平台。它和一般的管理类平台相比，有三个关键性的特点：

• 测试场景差异极大，接口、UI、性能、安全、大模型评测、Agent智能体测试不同类型下场景各有各的玩法，硬塞进同一套逻辑里必然互相拖累；
• AI 技术栈迭代极快，今天的当家模型过几个月就可能换代，架构不能跟着模型重写；
• 搬进企业，必须支持私有化部署，平台得能整体搬进内网。

围绕这三个特点，再套用通用做法，本项目的设计原则大体上遵循四条：

• 总体结构采用分层原则，每层只回答一个问题，依赖只能向下——任何一层都能单独重构、单独替换；
• 不同场景做成插件挂进场景层，对扩展开放、对修改关闭——新场景来了是加插件，不是改主干；
• 变化最快的 AI 能力独立成层、经 AI 网关统一出入——模型怎么换、云端和本地怎么切，都不波及业务代码；
• 企业既有环境一律划到信任边界之外——被测系统、大模型、企业工具链只通过流水线触发、API 调用、内网路径、执行流量这几条受控通道和平台打交道。

四条原则落到图上，分别对应六层骨架、场景扩展位、AI 网关、以及最右侧那条外部环境虚线带。

按这些原则切下来，平台架构的初步形态，就是下面这张图了：

从上往下把图过一遍。

L1 用户接入层：Web 控制台、AI 对话助手、CI/CD 集成、CLI 与 OpenAPI——人、脚本、外部系统，所有入口都收在这层。

往下一层是 L2 场景服务层：测试六大场景，最右边还留了一个虚线框的「场景扩展位」，今天没有的场景，明天不动主干就能挂进来。

L3 AI 能力层：Agent 编排、提示词与规则库、RAG 检索、AI 网关，全平台的智能都从这层出。值得一提的是如今几乎所有互联网大厂都有自己的 AI 网关服务，用于统一管理和调度内部的 AI 能力。这已经是 AI 时代基础设施的标配了。

再往下是用户看不见的三层。

L4 调度执行层：任务调度、失败诊断与自愈、执行器集群，测试任务真正跑起来是在这层。

L5 数据层：业务库、缓存队列、向量库、对象存储，四类数据四种存储各就各位。

L6 基础设施层：Docker 容器池、浏览器网格、Agent 运行时、监控与日志，上面五层全落在它身上。

4. 架构分层怎么分：每层解决一类问题

架构分层到底该怎么分？为什么上面的架构图里是 6 层，而不是 5 层或 7 层？

先说结论：分层不是越多越好。

每多一层，就多一层接口、多一层调用链、多一层排障路径，一个请求进来要多穿一道关卡，出了问题日志都要多翻几屏；

分少了同样不行，两个职责不同的东西挤在同一层里，改一个动一个，牵一发动全身。

层数从来不是分层的追求，它只是职责边界切清楚之后自然掉出来的结果——边界切对了，是几层就是几层。

那按什么准则切？最根本的一条：每层只回答一类问题，且回答得完整。

套用到我们这个项目，正好是六类问题——从哪儿进、干什么活、谁在思考、谁来干活、存在哪、跑在哪。

六类问题各自成立、互不重叠，多一层嫌碎，少一层就有两个问题挤在一起，所以是 6 层，不是 5 层也不是 7 层。

「回答得完整」这半句同样要紧：比如权限校验，单独拎一层听着也单一，但它是「从哪儿进」这个问题的一部分，拆出去反而把入口切破了。

还有一条同样管用：变化节奏不同的东西，不放在同一层。

分层分的不只是职责，还有变化的速度。AI 能力是全平台变得最快的部分，模型一两个月一换代，提示词策略随时在调；而用户入口和场景服务相对稳定。把它们锁在同一层，快的每动一次，慢的就得跟着受牵连——很多层的边界，其实就落在变化快慢的分界线上。

两条准则切下来，就是上图上的这六层，每一层聚焦解决一类问题：

1、L1 用户接入层回答「从哪儿进」。

Web 控制台、AI 对话助手、CI/CD 集成、CLI 与 OpenAPI，人、脚本、外部系统，所有入口收在这一层。

对话式交互是这层的重头——AI 对话助手基于 MCP 和 Skill 构建，用自然语言指挥平台干活，是立项时呼声最高的需求；企业流水线也从这层接进来，Jenkins、GitLab 上一个 Webhook 就能触发一轮回归。

2、L2 场景服务层回答「干什么活」。

六大测试场景各自是一个服务模块，共用同一套用例资产、任务、报告模型。这层的存在感最低、但扩展性要求最高。

3、 L3 AI 能力层回答「谁在思考」。

Agent 编排、提示词与规则库、RAG 检索、AI 网关，全平台的智能都从这层出。它独立成层的意义在于：换模型、换提示词策略、换 Agent 框架，都不该波及业务层。

4、L4 调度执行层回答「谁来干活」。

任务调度把活排队分发，执行器集群真正跑测试，失败诊断与自愈负责收尾。无人值守的定时回归、夜间巡检，靠的就是这层。

5、 L5 数据层回答「存在哪」。

用例资产进业务库，队列走缓存，知识进向量库，截图报告进对象存储——四类数据四种存储，各就各位。

6、L6 基础设施层回答「跑在哪」。

Docker 容器池、浏览器网格、Agent 运行时、监控与日志，平台自身的运行底座。

层与层之间还有一条铁律：依赖只能向下，不能向上。用户接入层可以调场景层，场景层可以调 AI 能力层，反过来不行。这条规矩守住了，后面每一层都可以单独重构、单独替换，互不拖累。

5. 技术栈组合

技术选型走到这，就基本敲定了，汇总成一张总清单，项目开工后，忘记的话，随时回到这里来对照：

6. AI 网关：全平台的智能总闸

架构图里 AI 网关值得先单独拎出来讲一下，这一节解释为什么它配得上这个待遇。

先看没有网关的世界什么样。

每个场景服务都自己直连大模型：接口测试模块里写一份调用代码，UI 测试模块里再写一份，大模型评测模块里又一份。很快你会发现问题——API Key 散落在各处，权限没法收口；想统计「这个月 AI 调了多少 token、花了多少钱」，数据根本凑不齐；某天要换模型供应商，全平台代码跟着改；最致命的是内网客户来了，要求所有推理走本地模型，你发现「切到内网」这个动作没有地方可以执行。

AI 网关就是把这系列问题一次收口的组件，它对外只暴露一套 OpenAI 兼容协议。这套协议现在事实上的行业 USB-C——云端大模型、本地 vLLM、Ollama，全都讲这套协议。平台内所有组件只认网关，不认具体模型：

• 多模型智能路由：生成用例路由到便宜快速的模型，失败诊断路由到推理强的模型，按场景分配，成本和质量的平衡掌握在自己手里；
• 私有化开关：内网部署时网关整体切到本地推理，平台上层一行代码不用动，这就是架构图里那条虚线「内网路径」的含义；
• 治理与计量：重试、降级、限流在网关统一做，每次调用的用量数据落库，直接喂给管理看板——上一篇说的「AI 提效可度量」，数据源头就在这。

该项目里我们会自研一个轻量AI网关而不是直接全部套用 LiteLLM 这类现成方案，原因很直接：网关内部的路由、降级、计量逻辑本身就是这个平台最值得学的部分之一，包在别人的库里就学不到了。接口按协议标准做，生产上想换现成方案，随时可换。

7. 对企业，这个平台意味着什么

站到企业的视角，投入资源建一个测试平台，买的其实是两样东西。

一样是效率，AI 把用例编写、脚本开发、回归执行、报告输出这些人力大头接过去，人聚焦在业务理解和风险判断上。

另一样是确定性，效率提升的过程可追溯、结果可度量、能力可留存。

前者决定这件事值不值得干，后者决定这件事能不能持续干下去。这个平台对企业的意义，更多的在后者。

先说最直接的，工作提效变得可度量。

企业里所有提效动作，最终都要回答同一个问题，省了多少，快了多少，质量有没有掉。散装 AI 模式答不了这个问题，即便能答，也纯是靠个人主观讲出来的，数据散在个人电脑里，数据很难度量，报表编都编不出来。

而平台，能把测试活动的全过程留痕，AI 用例生成占比、自动化执行占比、失败自愈率、回归耗时变化，打开面板就是现成的数。管理层定目标有依据，团队汇报进展有数据，年终算投入产出有账可查，像「测试用例 80% 由 AI 自己跑」这样的目标，也只有落在平台上才可能被验证。

再往深一层，全流程 AI 化有了统一载体。

测试的活分散在需求分析、用例设计、脚本开发、执行回归、报告输出各个环节，平台把整条链路收进同一个入口，自然语言进，测试资产出，提测前自动化就绪，冒烟自动跑，报告自动出，中间不靠人肉在工具之间搬运。

同时测试平台站在企业工具链的中间位置，向上对接需求和缺陷管理，向下对接被测系统与 CI 流水线，AI 的产出直接回流到企业现有工具里，团队不需要为了用 AI 推翻已有流程。

第三件事，经验从个人资产变成组织资产。

提示词、生成规则、评审标准、诊断策略，全部在平台里版本化管理，资深工程师的判断标准写进规则，新人用平台就自动继承了这套标准。骨干流动不再带走团队的能力，质量口径不再因人而异，这一层是散装模式永远做不到的。

最后是私有化部署。

前面三层价值，政企、金融这类内网环境里的团队原本是够不着的，数据出内网就是红线。平台支持本地化私有部署，大模型可以换成本地模型或内网推理网关，无外网、接口鉴权复杂、历史系统文档缺失这些现实约束都有适配方案，AI 的能力进得去，企业的数据出不来。

这几层加起来，这个平台给企业的是一件确定的事，把测试团队从「每个人各自提效」带进「整个团队规模化提效」，并且让提效的每一分都看得见、算得清、留得住。

8. 对个人来说，它能给你带来什么

如果说企业视角看的是组织能力，个人视角看到的应该是机会。

先看一个最现实的差距。

现在投测试开发岗，简历上写「熟练使用 AI 工具辅助测试」的候选人一抓一大把，这句话的分量正在快速贬值。而「主导开发过企业级 AI 智能测试平台，覆盖接口、UI、性能、安全、RAG、Agent 全场景」是完全不同的量级。前者是用过，后者是造过。跟完这个专栏，你属于后者。

再看面试。平台开发的每个模块都直接对应测开面试的高频考点。

• 做执行调度，你要回答任务编排和资源管理怎么做；
• 做失败自愈，你要回答 flaky 用例的治理思路；
• 做平台架构，你要回答模块分层和扩展性设计。
• ...
  这些恰好是面试题系列里反复强调的区分度所在，做过平台的人答这些题，讲的是自己的真实决策和踩坑，没做过的人只能背概念，面试官一耳就能听出来。

然后是成长路径。

很多功能测试同学卡在「点点点」和「测试开发」之间，缺的从来不是一门语言课，而是一个完整的项目工程载体。

这个平台就是那个载体，你会被迫面对真实工程里的全部问题，架构怎么分层、Agent 怎么编排、大模型输出不稳定怎么兜底、内网环境怎么适配。解决这些问题的过程，就是从功能测试走向AI 全栈测试开发的过程。

最后，它是一个拿得出手的作品集。

面试时打开自己的平台，现场演示从一句自然语言需求到自动化执行、报告产出的全过程，比任何自我介绍都有说服力。

9. 写在最后

最后也想和大家说清楚：我们做这个智能测试平台项目，重点不是最后产出一个平台成品。

这个项目真正的价值，是给大家提供一个真实的训练场，它更像一个承载知识的实战载体：把工程开发能力、当下的前沿 AI 技术、我们日常真实的业务测试诉求，三者放到同一个项目里闭环落地。

我们不是简单靠着 AI 写代码 “堆出一个系统”，而是在从零搭建平台的全过程中，去学习实践怎么把工程能力和 AI 能力组合起来，直面工作里那些细碎、棘手、长期困扰我们的真实问题。

代码、平台都只是载体。真正值钱的，是这套融合解决问题的思路。等走完整个项目，你收获的不是一个仓库的源码，而是一套可迁移的、融合 AI 的质量工程化思维。

往后不管你是做自动化回归、RAG 评测、Agent 任务测评，还是性能、安全这类传统测试场景，你都能带着这套方法，自主设计、搭建、落地属于自己的解决方案。

后续我们会持续拆解平台的每一块模块，一步一步带着大家一起迭代，一起动手把它完整落地，咱们实战里见。