架构选型说明写给关心 AI-7D-SATS 技术路线的合作伙伴、客户和技术决策者。一、我们面临的选择AI 火了之后每个做技术的人都被问过同一个问题“你们用了 AI 吗”但用 AI三个字背后其实藏着四种完全不同的做法。就像出行走路、骑单车、坐公交、开私家车都能到目的地但成本和体验天差地别。选错了轻则浪费钱重则出事故。AI-7D-SATS 是一个性能测试 Agent 应用主要能力是帮用户完成从需求理解到压测执行再到根因分析的全链路。这里有一个问题必须先回答哪些环节适合用 AI哪些环节坚决不能用 AI这篇文章讲的就是我们为什么选择了Workflow Multi-Agent这种模式。二、从 SOP 到 JD性能测试工程师思维的转变在讲具体选型之前有必要先说一线工程师思维的变化。不理解这个转变后面的四种模式看起来就是几种技术方案理解了你会发现这其实是工作方式的升级。旧模式面向过程Defining the steps在传统的性能测试工作中工程师接到一个压测任务后需要按照标准流程一步步执行。第一步读需求文档手动标记出需要压测的接口第二步打开 JMeter 或 Locust逐个配置线程组、采样器、断言第三步如果接口需要登录鉴权手写 Cookie 管理器或 Token 提取器第四步准备测试数据根据业务规则造数据或从数据库导数据第五步启动压测盯着监控大屏发现异常手动叫停第六步从 Prometheus 或 Grafana 导出监控截图粘贴到 Excel 里第七步写一份 Word 报告把响应时间、吞吐量、错误率填进固定模板每一个判断逻辑、每一次数据流转都依赖工程师的个人经验和手工操作。这在 AI-7D-SATS 早期版本中体现得尤为明显。当时我们想把这个流程自动化于是性能测试工程师开始写死每一步——第一步用正则表达式提取 PRD 中的接口列表第二步用固定模板生成 Locust 脚本第三步硬编码判断如果接口是 GET 就用这种压测策略如果是 POST 就用另一种第四步固定报表格式输出结果异常处理如果 PRD 格式变了、如果接口有鉴权、如果用户想要 JMeter 而不是 Locust——每一步都需要新增判断分支这就像一位老工程师写了一本厚厚的《性能测试操作手册》手册里写了 300 页的操作流程。但只要用户扔过来一份格式不同的需求文档或者要求测试一个非标准 REST 接口比如 WebSocket、GraphQL整本手册就卡住了——因为手册里没有写这种情况。新模式面向组织Defining the roles在 AI 时代性能测试工程师的主要工作变成了写角色说明书——几张 JD职位描述定义清楚每个数字员工的职责和边界。以 AI-7D-SATS 为例现在的性能测试工程师不再写 300 页操作手册而是定义这样几个角色需求解析专家RequirementAnalyzer职责是从 PRD / OpenAPI / HAR / 自然语言中提取测试需求能使用的工具是文档读取器、知识库查询器边界是不能直接启动压测场景设计专家ScenarioDesigner职责是生成测试场景矩阵能使用的工具是历史案例库、参数生成器边界是产出必须经人工确认脚本生成专家ScriptGenerator职责是生成 Locust / JMeter 脚本能使用的工具是代码模板库边界是产出必须经过安全审核根因分析专家RootCauseAnalyzer职责是解读监控指标、给出瓶颈假设能使用的工具是 Prometheus 查询、ChromaDB 知识库边界是置信度低于 0.7 必须上报人工写好了角色说明书然后呢Trust the Role信任角色。你不再 micromanage 他每一步做什么。以需求解析专家为例你告诉他“你是需求解析专家目标是从混乱的输入中提取清晰的测试需求。你可以查阅文档、搜索知识库、提问澄清但不能直接启动压测。我相信你能自主规划工作路径但超出边界的事情必须上报。”然后让他自己去干。他可能先通读文档再标记疑点再搜索历史案例再整理输出——这些步骤是他在自己的大脑LLM里动态规划的不是代码里写死的。为什么要这么分Multi-Agent 协作的实际好处在于你终于可以从管步骤的泥潭中解放出来去做管角色的设计。业务变化时以前新增支持 gRPC 接口压测需要改 20 处代码逻辑需求解析模块要识别 gRPC 语义、脚本生成模块要新增代码模板、参数校验模块要适配 proto 结构……。现在只需要调整脚本生成专家的工具箱给他增加 gRPC 代码模板其他角色不受影响。新需求出现时以前新增容量预测功能需要新增一整条 Workflow 分支从数据抽取到模型调用到报告格式化全部写死。现在只需要新增一个容量预测专家角色定义好他的输入历史压测数据 业务增长趋势、输出容量预测报告、工具回归模型、趋势分析器然后把他接入现有的组织即可。系统出问题时以前脚本生成异常你需要逐行 debug 代码逻辑看是哪条正则、哪个模板出了问题。现在只需要看哪个角色越界了——是脚本生成专家生成了危险代码比如包含os.system的脚本还是根因分析专家查询了不该查的生产环境指标问题定位从读代码变成了看角色行为日志。当然SOP 并没有完全消失。实际上最高效的架构是SOP JD的混合确定性环节保留 SOP用流水线确保稳定高效Workflow不确定性环节引入 JD用角色自主决策应对变化Agent所以接下来你要看到的四种模式本质上就是回答一个问题在这个环节该用 SOP还是该用 JD三、四种 AI 应用模式模式一Prompt Engineering — 直接问专家一个问题类比你有一位博学的朋友给他一个清晰的问题他一次性给你答案。适合场景问题本身很明确不需要查资料、不需要做调研答案可以直接用不需要后续加工在 AI-7D-SATS 中的例子用户在 AI 聊天框输入“请用一句话解释本次压测中 CPU 使用率 95% 可能意味着什么”平台直接调用大模型一次性返回“CPU 使用率 95% 通常意味着计算密集型瓶颈可能是业务逻辑复杂、线程竞争或垃圾回收频繁导致。”局限性如果问题需要分多步解决比如先查监控指标 → 再对比历史基线 → 再定位具体代码段Prompt 模式就搞不定了如果上下文太长比如扔给 AI 一份 10MB 的压测日志他会失忆只能处理前面几页模式二Workflow — 工厂流水线类比工厂里的流水线每一步都是预先设计好的。零件来了第一步冲压、第二步焊接、第三步质检每一步该做什么、谁来干、异常了怎么处理全写在操作手册里。适合场景流程步骤明确可以一条条列出来分支条件清晰比如如果 A 就走到 B如果 C 就走到 D对稳定性、速度、成本要求高在性能测试中的例子用户登录 → 读取项目信息 → 检查环境配置 → 校验输入参数 → 创建执行记录 → 提交任务队列 → 启动压测 → 采集监控数据 → 存储结果 → 记录审计日志这条链路的每一步都是确定的不需要 AI 来思考下一步该做什么。优势极其稳定、速度快、成本低、出了问题容易定位。局限性遇到没写在手册里的异常情况流水线就卡住了比如用户丢过来一段自然语言描述的需求流水线不知道怎么处理模式三Single Agent — 聘请一位独立Agent类比你请了一位专业Agent给他一个任务目标给他一套工具电脑、数据库权限、搜索引擎让他自己想办法完成。Agent的工作方式是思考 → 行动 → 观察结果 → 再思考 → 再行动循环往复直到任务完成。适合场景任务有一定不确定性步骤无法预先穷举需要探索、调研、判断输入可能是自然语言、非结构化数据在性能测试中的例子“用户上传了一份 PRD 文档请帮我提取出需要做性能测试的场景和指标。”Agent会打开文档、逐段阅读、提取关键信息、整理成结构化的测试场景矩阵。这个过程需要阅读 → 理解 → 归纳 → 输出步骤不是预先固定的。优势能处理不确定性和复杂性有自主决策能力。局限性如果他需要查太多资料、用太多工具脑子会过载如果他同时要写报告又要审报告容易自己骗自己如果让他处理敏感操作比如直接启动压测风险极高模式四Multi-Agent — 组建专家团类比一个复杂项目你组建了一个专家团有调研员、分析师、质检员、项目经理。每个人有明确分工互相协作最终产出一份报告。适合场景任务极其复杂一个人搞不定需要多个领域专家交叉验证质量要求高不能出错在性能测试中的潜在例子“请四位专家需求专家、脚本专家、性能专家、报告专家共同评审一份测试报告草案各自从不同角度提出修改意见。”优势专业分工、质量高、可交叉验证。局限性成本高多个人工智能体并行运行Token 消耗大速度慢协调多人需要时间系统复杂度高出问题难定位如果没有完善的管理机制审批、审计、预算控制容易失控四、性能测试这件事到底有多乱要选对架构首先要搞清楚性能测试本身属于极其有序还是高度混沌我们用一个简单指标来衡量事情的混乱程度技术上叫业务熵。混乱程度越低越适合流水线混乱程度越高越需要Agent甚至专案组。低混乱的环节适合流水线环节为什么低混乱用户登录用户名密码验证通过或不通过规则固定读取项目信息根据项目 ID 查数据库有就返回没有就报错校验输入参数并发用户数是不是数字、目标地址格式对不对规则明确启动压测按配置启动 Locust/JMeter步骤固定采集监控数据定时从 Prometheus 拉指标流程标准化记录审计日志谁、什么时候、做了什么格式固定这些环节的共同特点输入格式固定、执行路径明确。用流水线解决又快又便宜。高混乱的环节适合Agent环节为什么高混乱理解用户需求用户可能扔过来 PRD、OpenAPI 文档、HAR 文件或者一段微信语音转文字格式千差万别设计测试场景“这个接口要不要测高并发”这个数据量够不够真实需要领域知识判断诊断根因监控指标异常了是数据库慢查询还是内存泄漏还是网络抖动没有标准答案容量预测当前系统能撑多少用户需要结合历史数据、业务增长趋势、架构特点做综合判断生成报告摘要给 CEO 看的摘要和给运维看的详细报告侧重点完全不同需要理解受众这些环节的输入不可预测处理路径需要探索输出标准也偏主观。用流水线硬编码成本高且效果不好请一位Agent来处理反而更合适。五、核心原则用多大的网捞多大的鱼我们选型时遵循一条原则来自控制论中的阿什比定律“只有多样性才能对抗多样性。”通俗地说用多大的网捞多大的鱼。如果池塘里只有几种鱼且游得很规律不需要撒一张巨网一根鱼竿就够了Prompt / Workflow如果池塘里鱼种繁多、游得杂乱无章拿一根鱼竿就会漏掉很多必须撒网Agent / Multi-Agent但反过来也成立过设计池塘里明明只有几种鱼你却动用了巨网浪费钱、增加复杂度欠设计池塘里鱼群混乱你却只用一根鱼竿根本捞不上来AI-7D-SATS 的性能测试链路横跨了低混乱和高混乱两种状态执行链路登录 → 校验 → 启动 → 采集 → 存储是低混乱的用流水线分析链路理解需求 → 诊断根因 → 预测容量 → 生成报告是高混乱的用Agent所以我们的选择很明确不做纯流水线也不做纯Agent团队而是Workflow 为主骨架在关键节点引入 Multi-Agent 帮忙。这就是混合架构。六、压测执行一条绝对不能碰的红线在混合架构中有一个问题必须回答为什么压测执行启动 Locust/JMeter、连接目标服务器不能交给 AI Agent来做答案就三个字安全、审计、追责。想象一下这个场景AI Agent收到了用户的请求“帮我压测一下生产环境。”Agent自己判断“用户说生产环境我觉得没问题直接启动吧。”结果生产环境被压垮了核心业务中断 30 分钟。谁来负责AI 吗AI 没有法律责任。开发团队吗“是 AI 自己做的决定”甩锅循环开始。所以我们的红线很清楚操作类型能否交给 AI原因理解用户需求可以错了可以人工修正不直接产生破坏生成测试脚本可以生成后需要人工审核不直接执行启动压测绝对不行直接作用于生产系统一旦出错后果严重访问目标服务器绝对不行涉及网络安全和权限边界写入数据库/知识库绝对不行数据变更必须经审批和审计发布报告到外部绝对不行对外发布需经合规审核AI Agent在我们架构里的定位是建议者不是执行者。它可以生成脚本、提出根因假设、起草报告但所有高风险操作必须经过人工审批闸机DispatchGate由人来最终决定是否执行。七、评估架构的三把尺子实际做决策时我们用三把尺子来量一个需求该用什么架构第一把尺子复杂度Complexity这件事本身有多复杂维度简单AI-7D-SATS 场景复杂AI-7D-SATS 场景交互复杂度用户在聊天框问什么是 TPS一问一答搞定用户上传 50 页 PRD 文档要求提取全部性能测试场景和指标依赖复杂度只需大模型自身知识回答常识问题需要查询 ChromaDB 知识库、调用 Prometheus API 拉取指标、读取 HAR 文件分析接口过程复杂度单步生成测试脚本即可交付生成脚本 → 人工审核 → 提交队列 → 启动 Locust 压测 → 采集监控 → 根因分析 → 生成报告第二把尺子不确定度Uncertainty这件事有多说不准维度确定AI-7D-SATS 场景不确定AI-7D-SATS 场景输入不确定度用户在表单中填写固定参数并发数 1000、持续时间 300 秒、目标地址 https://api.example.com用户在微信群发了一段语音“帮我测一下这个接口能不能撑住双十一”过程不确定度执行路径固定校验参数 → 启动 Locust → 采集 Prometheus 指标 → 存储结果到数据库根因分析路径动态先看 CPU → 正常 → 转看数据库慢查询 → 正常 → 转看网络延迟 → 找到瓶颈目标不确定度压测是否通过错误率 1% 且响应时间 P99 500ms可自动判定容量预测报告质量是否达标是否覆盖了所有关键场景需要领域专家判断第三把尺子性能要求Performance这件事对速度、成本、资源有多敏感约束类型AI-7D-SATS 场景对架构的影响响应时间用户在 AI 聊天界面提问期望 2 秒内看到第一个字或压测报警后需在 5 分钟内定位根因不能用 Multi-Agent协调多个Agent太慢必须用 Single Agent 或 Workflow成本约束每天自动采集上千个监控指标并生成摘要报告高频低价值任务不能用高 Token 消耗的Agent方案降级为 Prompt 批量处理或轻量 Workflow上下文约束用户上传了 10MB 的压测日志文件要求 AI 找出所有异常模式直接塞进 Agent 会超出上下文窗口必须用文件传书 RAG 检索 分段分析三把尺子中Performance 有一票否决权。即使复杂度和不确定度都很高理论上应该用专案组但如果性能要求极其严苛比如压测根因定位必须在 5 分钟内完成我们会强制降级收缩能力边界把不确定的环节尽量固定化退回到Workflow 骨架 局部 Multi-Agent的模式。八、AI 能力建设路线图引入 AI 能力不是一蹴而就的业内有一条公认的六阶进阶路线这也是 AI-7D-SATS 的建设蓝图阶段名称通俗解释建设重点Level 0准备工具、环境、团队就位搭建开发环境、选定基座模型、组建 AI 工程小组Level 1跑通 MVP核心闭环能转起来Agent 能接收任务、调用技能、输出推理结果端到端可演示Level 2工具生态AI 能调用外部工具建立 SkillRegistry覆盖需求解析、脚本生成、监控查询等核心工具Level 3记忆与知识AI 能记住事情、查资料接入知识库建立长短期记忆机制支持上下文回溯Level 4多智能体协作多个 AI Agent能协作仅限低风险场景试点如报告评审明确角色隔离和成本上限Level 5稳定与安全有护栏、有监控、能审计Prompt 注入防护、危险脚本检测、循环调用熔断、全链路审计这条路线图的核心理念是先单点验证后生态扩展再谈协作最后上护栏。各阶段之间存在明确的依赖和先后关系Level 1 是底线如果单个 Agent 连接收任务 → 调用工具 → 输出结果的闭环都跑不通后续所有建设都是空中楼阁。必须在单 Agent 端到端可演示之后才进入下一阶段。Level 2-3 是翅膀工具生态和记忆能力决定了 Agent 能做什么、记得住什么。没有丰富的技能和知识库Agent 只能回答常识问题无法处理性能测试领域的专业任务。Level 4 是禁区门槛Multi-Agent 协作的成本、复杂度和风险都远高于单 Agent。只有在单 Agent 能力充分验证、安全护栏基本就位后才允许在低风险场景下试点。任何涉及执行、写库、发布的任务都不在此列。Level 5 是入场券没有完善的安全护栏任何 AI 能力都不允许接触生产数据或执行敏感操作。这是硬性门槛不是可选项。安全护栏全部到位后Agent等协作模式才可能从低风险试点走向生产可用。九、未来可能的变化我们并不是永远排斥 Multi-Agent。满足以下条件时可能会引入专家团模式任务性质仅限低风险的内容评审如报告评审、场景设计复核不涉及执行、写库、发布角色隔离每个 AI Agent有明确独立的职责不互相越界有评估基准单 Agent的结果 vs 专家团的结果能量化对比有成本上限试点预算、Token 消耗上限、最大运行时间已明确有回滚路径随时可关闭不影响主业务流程安全护栏到位Prompt 注入防护、循环检测、成本熔断等机制已运行稳定不是不用是时候未到。十、总结AI-7D-SATS 选择混合架构基于对业务的理解性能测试链路天然分层执行链路是有序的适合流水线分析链路是混沌的适合Agent安全红线不可逾越压测执行、权限判断、数据写入、对外发布等高风险操作必须留在确定性工程链路中由人来审批阶段性务实当前处于单Agent可用、多Agent待验证的阶段优先补齐安全护栏而非盲目增加 AI 复杂度架构选型是可复用的过程每一个新需求都经过四层漏斗 三把尺子的评估确保不过设计、不欠设计Workflow 保稳定Multi-Agent 解难题。各管各的事各用各的场。这就是我们的做法。