开篇词｜Agent 的性能好不好，要拿证据说话

高楼

讲述：高楼AI版大小：13.72M时长：12:00
你好，我是高楼。
2019 到 2021 年间，我在极客时间上写了三个专栏，分别是《性能测试实战 30 讲》、《高楼的性能工程实战课》、《全链路压测实战 30 讲》，自以为把性能项目从头到尾该怎么做都讲完了。而这几年随着 AI 应用的崛起，在我做咨询、培训、项目的时候，聊的话题慢慢变了，几乎所有的话题都会跟 AI 相关，性能也不例外。
在性能领域中应该如何利用 AI 能力提升效率呢？把需要分析的数据扔给 AI，它就会给你一个精确的解决方案吗？当然不是，如果你做过这样的尝试，就会知道，所有的 AI 大模型都不可能对你所有的性能瓶颈分析生效，这和 AI 大模型的底层逻辑有关。
那如何通过 AI 工具的应用在性能项目中提高效果呢？又如何把 AI 落地到具体项目中呢？
做性能这些年，我有个宗旨，合作过的人都知道：上线不死，死了不收钱。这句玩笑放到 AI Agent 项目里依然算数，只是要把“不死”证明出来，需要的证据链跟以前不一样了。不是系统变娇气了，是我们手里的老办法，管不住这个新物种。
为了写这个专栏，我专门设计了一个完整的 AI Agent 业务流程，分为三个阶段：Single-Agent（阶段一）/ Multi-Agent（阶段二）/ Workflow + RAG（阶段三），同时也设计了一套完整的性能测试实验台，以支撑专栏所需要的基础数据。示意图如下：
后续课程中，你将看到每一个步骤对应的实验数据，我也把这些数据放在了公共仓库中，并加了链接，以便你在阅读专栏时可以找到对应的内容。
请注意，课程配套仓库在这里：https://github.com/xncssj/agent-perf-testing-30-lectures.git，内容会随课程讲解更新。
你可能要问，为什么要如此大费周章，实现一个完整的 AI Agent 业务流程来做性能场景呢？
因为在 AI Agent 性能领域中，掌握某个单独的 AI 工具远远不够，而是要把一个 AI Agent 系统从开发到上线完整地运行起来，并且要知道如何评估这个系统运行得正常不正常，所以这个大费周章是必须的。专栏对应的 AI  Agent 示例系统整体部署架构图如下：
课程项目技术架构示意图
相对于传统的性能项目，有些内容已经发生了变化，这也是为什么要写这个专栏。至于有哪些变化，我们接着往下看。
报告说通过，业务说没有课程第 01 讲里有个场景：用户提交工单问“我的包裹到哪儿了”，网关统计接口成功率 100%，响应时间达标，报告结论“测试通过”。业务方一抽查，一批标记成功的业务里，Agent 只回了句“请耐心等待”。包裹查了吗？没查。业务做完了吗？没有。那 100% 是什么的 100%？是 HTTP 请求的 100%，跟用户没关系。
这事儿怪 Agent 吗？也不能全怪它。要怪，先怪我们手里那套老办法，它至少在三处失灵了。
第一，你压测的不是用户等的东西。传统接口一笔业务基本对应一次请求，压测接口约等于压测业务。Agent 是多步执行：模型想一轮，查一次订单，再想一轮，中间可能还有重试。你在接口上压得起劲，用户在那头盯着转圈，两层之间还对不上数。
第二，状态码管不着结果。接口返回 200 只说明请求成功。业务完成没有？结果合格没有？它一概不知。模型又是概率性的，同一个问题这次答对、下次可能跑偏。第 01 讲会给你一张四级判定表：请求成功、流程完成、业务完成、结果合格，一级比一级难，也一级比一级接近用户的真实感受。
第三，最慢的未必是病根。传统系统慢了，顺着调用链往下钻，通常能揪出拖后腿的服务。Agent 链路里混着模型、工具、编排和队列，执行路径每次还可能不一样。第 19 讲的标题就是个提醒：最慢的组件，不一定是瓶颈。这个学费我交过。第 06 讲我会分享这个踩坑经验：并发还没到设计峰值，合格率先从 100% 掉到 90%，错误率却是零，追到最后，病根在我自己的压测脚本上。对，忙活半天，病在我身上。没有一条可靠的证据链，这类问题连门都摸不着。
方法没过时，对象升级了先说我的判断：性能工程的骨架没有过时。需求分析、场景设计、压测执行、容量评估、分析优化、回归验证。这一套对 Agent 照样成立，不用推倒重来，要换的是三样东西：
测试对象从接口换成业务；
指标体系从 TPS 和响应时间，换成 TTFT、TPOT、端到端业务时延、Goodput 和成功业务成本（详细说明导学和后续课程里再展开）；
分析方法从调用链定位，换成完整的业务证据链：Trace 还原轨迹，Eval 核对结果。
顺便说一下，RESAR 是我从《性能测试实战 30 讲》起沿用的方法论，按需求、环境、场景、分析、报告组织整个性能项目。
这门课把其中的分析环节展开成七步：从读懂压力曲线开始，到拆解业务时延、缩小可疑范围、定向验证假设、判定瓶颈，最后完成优化和配对复测（用同样的业务、负载和环境再测一遍，证明优化真的有效）。每一步有交付物，每个结论都会对应着证据。没有证据的结论，在我这里不算结论，算许愿。
这门课带你完整做完一个项目这几年我带团队做企业 AI Agent 应用的性能测试、分析和优化。一开始大家都觉得，大模型性能会是最大瓶颈点。但真放到实际业务里才发现，不只是大模型本身 ，Agent 应用层的设计也会出现很多性能瓶颈，不过优化方案的选择会比前者更多。
所以说，企业级 AI Agent 一定要做性能评估。未来 Agent 应用会越来越普遍，掌握 Agent 性能分析能力，对职业发展肯定有好处。同时，这块要懂的东西很广，也是锻炼和提升个人能力的好机会。
这门课不是知识点的拼盘，而是按项目串起来的实战方法。我深知掌握孤立知识点并不等于能在项目中能落地。而一个完整项目，让你看到一个 AI Agent 的性能需求分析、场景设计、压测执行、容量评估、性能分析、优化与验收之间的衔接，把每一步的技术细节都落地。
主项目是一个客服工单 Agent，业务很好理解：用户问订单的配送进度，Agent 查询后给出答复。
那怎么验收这个 Agent 的性能呢？业务负责人就给了四个字：“快、稳、准、省。”四个字念起来提气，验收起来要命。多快算快？怎么个稳法？谁也答不上来。
这门课将从把这四个字拆成能打钩的硬指标开始，然后画测试范围、定场景、写脚本、执行压测，用七步分析定位瓶颈、完成优化和回归，最后做出上线验收结论。
一个系统做完，还有两次架构升级：先升级为 Multi-Agent（多智能体协作架构），验证一个请求派生多路并行调用的场景，还有排队和级联故障；再升级为 Workflow/Flow（工作流）加 RAG（检索增强生成），验证分支、关键路径和持续评估门禁（每次变更自动跑一遍达标检查，达标才放行）。同一个业务，架构换了，测试方案哪些要重做、哪些能复用，我们都要亲手过一遍。
代码、数据和报告都是实打实交付的：245 条版本化的工单样本和配套的订单、物流快照，可运行的压测脚本，以及实测的实验记录、压测报告和验收模板。引用的实测数字都注明了来源和统计方式，你可以自己跑一遍对照。
丑话也写在前面：课程里也有我的翻车记录。第 15 讲开头就写着，我们曾经拿着一张错的路径图，做完了一整轮分析。错在哪儿、怎么发现的、后来怎么改，正文里都有。我想让你看到的，是一条走得通、也摔过跟头的路。
这门课长什么样接下来预告一下课程内容安排。
第 01—07 讲，备料。 把 Agent 性能测试的地基打好：业务怎么算成功（第 01 讲那张四级判定表）、五种架构形态的风险差在哪、测试对象画到哪一层、TTFT 和 Goodput 这些指标怎么选、概率性输出下怎么立可信基线、并发怎么数、悄悄失稳怎么抓。这七讲涉及的性能测试基础知识，后面项目实操每一讲都要反复使用。
第 08—13 讲，开工。 主项目正式动工：把“快、稳、准、省”变成可验收的需求，画测试范围，定方案、备数据、搭环境，设计基准、容量、稳定性、异常四类场景，写流式压测脚本，最后执行压测并留下经得住质疑的记录。到第 13 讲收工，你手里会有一整套压测场景下的原始数据。
第 14—20 讲，找病根。 RESAR 七步分析，每一讲对应一步：读压力曲线、标高风险路径、拆业务时延、用全局观测缩小范围、定向 Trace 与 Eval 验证假设、判瓶颈，最后优化加配对复测。第 11—13 讲产出的同一批数据从头用到尾，七步连成一套完整分析链路。
第 21—24 讲，搬家。 同一个客服工单系统先升级多智能体（Multi-Agent），再升级 Workflow/Flow 加 RAG，你会亲手验证：架构换了，测试方案哪些必须重做、哪些能复用；这一章的收尾，是把测试变成每次变更自动达标的持续评估门禁。
第 25—26 讲，配装备。工具不能盲目选择，要从项目问题反推出最小组合；压测、Trace、Eval 的数据怎么串成证据链，什么时候才值得建平台。
第 27—30 讲，过日子。聊清楚开工前的十大坑、两周怎么做出第一版 MVP（最小可行版本）、上线验收怎么做结论、运行三个月后体系怎么演进。
第 01—13 讲是入门主线，后面开始逐步进阶。每讲的内容会有相互的关联关系，我也会告诉你某段具体的内容依赖谁、又供谁用，有经验的可以按章跳读，不必从头看到尾。
你能带走什么一套指标字典，知道 Agent 性能该看哪些数；一张 SLO 卡片（服务级别目标，预先约定的达标要求），把“快、稳、准、省”变成可验收的条款；一组流式输出（边生成边返回）场景的压测脚本，能采到首 Token 时延和完整的业务轨迹；一条七步分析的证据链方法，让瓶颈结论经得住质疑；还有上线验收和持续门禁的做法，把一次测试沉淀成团队机制。
说到底就一句话：下次有人问“这个 Agent 性能行不行”，你拿出的是数据和证据链，结论能打钩，而不是一句“我觉得应该没问题”。“我觉得”这三个字，在性能这行从来不作为验收依据——当聊天开场白倒是可以。
开课寄语多年前我抛过一个说法：让性能变得有价值。到了 Agent 时代，这句话可以更直白一点：别拿接口指标糊弄业务，别拿“我觉得”糊弄自己。模型和框架年年换，用证据说话的工程能力不会过时。
下一讲是导学，我先把案例资产和阅读路线讲清楚，咱们导学里见。