夜雨聆风架构选型说明，写给关心 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甚至专案组。
低混乱的环节（适合流水线）
这些环节的共同特点：输入格式固定、执行路径明确。用流水线解决，又快又便宜。
高混乱的环节（适合Agent）
这些环节的输入不可预测，处理路径需要探索，输出标准也偏主观。用流水线硬编码，成本高且效果不好；请一位"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 Agent在我们架构里的定位是"建议者"，不是"执行者"。它可以生成脚本、提出根因假设、起草报告，但所有高风险操作必须经过人工审批闸机（DispatchGate），由人来最终决定是否执行。
七、评估架构的"三把尺子"
实际做决策时，我们用三把尺子来量一个需求该用什么架构：
第一把尺子：复杂度（Complexity）
这件事本身有多复杂？
第二把尺子：不确定度（Uncertainty）
这件事有多"说不准"？
第三把尺子：性能要求（Performance）
这件事对速度、成本、资源有多敏感？
三把尺子中，Performance 有一票否决权。
即使复杂度和不确定度都很高（理论上应该用专家团），但如果性能要求极其严苛（比如压测根因定位必须在 5 分钟内完成），我们会强制降级，收缩能力边界，把不确定的环节尽量固定化，退回到"Workflow 骨架 + 局部 Multi-Agent"的模式。
八、AI 能力建设路线图
引入 AI 能力不是一蹴而就的，业内有一条公认的六阶进阶路线，这也是 AI-7D-SATS 的建设蓝图：
这条路线图的核心理念是：先单点验证，后生态扩展，再谈协作，最后上护栏。
各阶段之间存在明确的依赖和先后关系：
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 解难题。各管各的事，各用各的场。这就是我们的做法。
