我是怎么设计企业办公智能体性能测试场景的

最近在做企业办公智能体的性能测试时，我遇到一个很现实的问题：到底应该怎么设计性能测试场景？

如果测试的是传统业务系统，这个问题其实没有那么难。

登录、查询、保存、提交、审批，每个交易基本都有相对明确的入口、请求和响应。我们可以从生产交易量、峰值 TPS、在线用户数出发，再设计并发模型。

但办公智能体不太一样。

一个用户打开办公智能体，可能让它写一篇材料，也可能上传一个几十页的文档进行问答；可能生成 PPT，也可能让它分析 Excel；有的人问一句就走，有的人会围绕一个问题连续聊十几轮。

表面上看，这些请求最终可能都是：调用一次大模型。但对后端算力来说，它们完全不是一回事。

所以我现在越来越觉得：企业办公智能体的性能测试，首先不是设计「多少并发」，而是设计「这些并发用户到底在干什么」。

这也是我最近在性能测试方案里重点补的一块——用户行为模型。

一、为什么不能直接设计一个「50 并发大模型调用」场景？

最开始做大模型性能测试，很容易采用传统接口测试的思路：10 并发、20 并发、30 并发、40 并发、50 并发；然后记录 TTFT、Token/s、请求耗时、成功率。

这样做当然有价值。它非常适合回答一个基础问题：当前这套模型和算力，在不同并发压力下，能力边界在哪里？

但它回答不了另一个更重要的问题：这套资源到底能支撑多少真实办公用户？

因为「40 个并发请求」与「40 个人使用办公智能体」，不是一个概念。

比如同样是 40 个用户：

• 有人正在阅读模型刚刚生成的材料，可能两三分钟都不会再发送请求；
• 有人正在连续追问；
• 有人上传了一份长文档，单次请求就带入大量上下文；
• 有人调用的是简单知识问答；
• 还有人正在生成几十页 PPT，背后甚至不只是一次模型调用，而是一串 Agent 工作流。

所以办公智能体真正应该建立的是：用户 → 任务 → 会话 → 模型调用 → Token → 算力，这样一条完整的负载链路。

图 1 · 办公智能体性能负载是怎么形成的：用户数 ≠ 并发请求数 ≠ 模型并发数

二、第一步：先把办公智能体拆成六类任务

我目前更倾向于把企业办公智能体的典型使用场景拆成六类：写文档、知识问答、数据分析、PPT 生成、代码任务、多轮对话。

为什么这么拆？因为这六类任务在几个关键维度上的差异非常明显：

• 输入长度不同
• 输出长度不同
• 是否依赖附件不同
• 是否依赖 RAG 不同
• 是否调用工具不同
• 用户等待和思考时间不同
• 多轮上下文增长速度不同

也就是说，它们产生的算力负载完全不同。

1. 写文档

这是企业办公智能体里非常典型的一类场景。比如：「帮我根据下面这些材料写一份汇报」，或者「根据这份制度和会议纪要，整理一篇 2000 字的总结」。

这类任务的特点是：输入不一定短，输出通常比较长。

特别是企业内部办公场景，经常不是一句 Prompt 直接生成，而是：用户指令 + 模板 + 历史材料 + 附件解析结果 + 系统 Prompt。最后真正进入模型的输入 Token 可能远高于用户看到的那几句话。

因此写文档类场景，我会重点关注：输入 Token、输出 Token、TTFT、TPOT、完整生成耗时。

其中 TPOT 非常重要。因为对于长文本生成来说，即使首 Token 出来很快，如果后面每个 Token 生成速度比较慢，最终用户还是要等很长时间。

2. 知识问答

知识问答表面上通常是最轻的一类任务。比如「差旅费报销标准是多少？」或者「某项制度具体是怎么规定的？」。用户输入可能只有几十个 Token。

但问题在于：真正发给模型的输入，不一定只有这几十个 Token。

如果使用 RAG，实际输入会变成：用户问题 + 系统 Prompt + 检索结果 + 知识库片段 + 历史对话，最后可能变成几千甚至上万 Token。

所以测试知识问答的时候，我一般不会只设计「一个 100 Token 的问题」，而会进一步区分：

• 轻量知识问答
• 普通知识问答
• 多文档知识问答
• 长上下文知识问答

否则很容易低估实际负载。

3. 数据分析

数据分析是另外一种比较特殊的负载。比如：「帮我分析这份 Excel，找出异常数据并总结趋势。」

这时候模型可能不是直接回答。背后可能出现：文件上传 → 文件解析 → 数据读取 → 代码生成 → Python 执行 → 结果返回 → 模型总结。

也就是说：一次用户请求，背后可能对应多次模型调用和工具调用。

这种情况下，如果只统计大模型接口本身的耗时，很容易得到一个「看起来不错」的结果。但用户真正关心的是：从一个点击发送，到最终分析结果展示出来，一共等多久？

所以数据分析场景，我会同时保留两类指标：模型层指标和端到端任务指标。

4. PPT 生成

PPT 其实是我认为办公智能体里比较值得单独拿出来测试的一类场景。

因为一个「帮我生成 PPT」的请求，背后可能经历：理解任务 → 生成大纲 → 生成每页内容 → 搜索/生成素材 → 生成图表 → 生成页面布局 → 文件生成。它可能对应的是一条比较长的 Agent 调用链。

因此 PPT 场景很容易出现一个问题：前端只有一个用户请求，后端却产生了很多模型请求。

假设一个用户生成一次 PPT，后台平均调用模型 8 次。那么 20 个用户同时生成 PPT，理论上并不等于 20 个模型请求。在某个阶段，它可能形成远高于 20 的模型瞬时压力。

我一般把这个现象叫作：Agent 调用放大。

图 2 · 为什么 1 个用户请求会变成 N 次模型调用：用户并发 × Agent 调用放大 ≠ 模型并发

5. 代码任务

代码场景和普通问答也不太一样。比如「帮我写一个 Python 脚本」，可能只需要几千 Token。但是「分析这个项目里的代码，找到问题并修改」，就可能快速演变成长上下文任务。

特别是企业内部逐渐引入 Coding Agent 之后，可能出现：读取多个文件、分析代码、修改代码、执行程序、读取报错、再修改、再执行。

所以 Coding Agent 本质上也更接近 Agent 工作流，而不是单次对话。

三、真正影响负载的，其实是两个数字

如果把上面的场景继续往下拆，我认为办公智能体性能测试里最核心的两个变量还是：输入 Token和输出 Token。可以很粗略地把不同任务放到一个二维空间里。

图 3 · 六类办公任务的 Token 特征矩阵：输入长度和输出长度，决定了任务负载的形态

这张图很重要。因为它能说明一个问题：「一次请求」不是一个统一的性能单位。

一个 500 Token 输入 + 300 Token 输出，和一个 30000 Token 输入 + 4000 Token 输出，虽然都是一次请求，但消耗的资源显然完全不同。

四、我现在不会再给每个场景只配一个 Token 长度

以前设计测试数据时，很容易这样写：输入长度 4K、输出长度 1K。后来我觉得这种设计太理想化了。真实用户不会严格按照 4K 上下文使用。

所以现在我更倾向于采用：Token 长度分布。

例如知识问答可以设计成：

• 轻量问答 —— 输入 1K 左右，占 40%
• 普通 RAG 问答 —— 输入 4K 左右，占 40%
• 复杂知识问答 —— 输入 8K～16K，占 15%
• 长文档问答 —— 输入 32K 以上，占 5%

这里的数字不是说所有办公智能体都必须这样设计。它更重要的意义在于：性能测试数据应该是一个分布，而不是一个固定值。

同样，写文档也可以拆：2K 输入 / 1K 输出；8K 输入 / 2K 输出；16K 输入 / 4K 输出；32K 输入 / 4K 输出。通过比例组合形成真实负载。这样得到的结果，才更接近生产。

五、128K 上下文，不代表每个请求都应该压 128K

这个问题在办公智能体性能测试中特别容易混淆。比如系统要求「支持 128K 上下文」，那么性能测试是不是应该让所有请求都带 128K？

我的理解是：不是。

128K 首先代表的是系统能力边界。它说明系统应该能够处理达到这个长度的上下文。但真实办公场景中，大多数请求很可能远远达不到 128K。

因此我现在会把测试拆成两类。

第一类：容量边界测试。例如 32K、64K、96K、128K。验证随着上下文不断增加：TTFT 如何变化、显存/内存如何变化、最大并发如何变化、吞吐如何变化。这是能力边界测试。

第二类：业务负载测试。根据真实办公任务设计一个 Token 长度分布，例如：短请求最多、普通请求次之、长请求较少、超长请求极少。这才是用来回答「系统能支撑多少办公用户」的测试。

两类测试解决的是完全不同的问题。

图 4 · 上下文越长，并发能力通常越低：容量边界测试和业务负载测试要分开看

六、输出 Token 也不能随便设

输出长度同样很容易影响测试结果。

比如知识问答，300～800 Token 可能就够了。但生成汇报材料，2000～4000 Token 并不少见。

如果测试的时候所有请求都设成 max_tokens = 512，那么最终测出来的 GPU 吞吐和真实办公负载之间，很可能存在明显偏差。

所以我现在会根据任务分别设计输出长度。一套比较适合作为初始测试建模基线的参数，可以这样设计：

• 知识问答 —— 输入 2K～8K，输出 300～800
• 写文档 —— 输入 4K～32K，输出 1K～4K
• 数据分析 —— 输入 4K～16K，输出 500～2K
• PPT 生成 —— 输入 4K～16K，输出 1K～3K
• 代码任务 —— 输入 4K～32K，输出 500～4K
• 多轮对话 —— 随轮次增长，输出 300～1K / 轮

其中 PPT 需要注意：如果 PPT 通过多 Agent、多阶段生成，单次模型输出长度意义会下降，需要统计整条调用链。

这里我要特别强调：这张表不是生产容量结论。它只是我在没有完整生产日志之前，用来构造第一版办公负载模型的起点。真正上线以后，还是应该根据真实日志重新校准。

七、然后才是 Think Time

这是我认为办公智能体性能测试特别容易被忽略的一项参数。

传统接口压测经常采用「请求、请求、请求、请求」的方式，也就是一个虚拟用户完成请求以后，马上发送下一次请求。

如果拿这种方式直接测试办公智能体，很容易把负载放大很多。

因为真实办公用户通常是这样的：发送问题 → 等待 AI → 阅读结果 → 思考 → 修改内容 → 再次提问。这里存在大量 Think Time。

例如 AI 生成了一篇 2000 字材料。用户不太可能结果刚出来 0.1 秒，马上继续发送下一个请求。他可能会看几十秒甚至几分钟。

所以办公智能体里的并发模型，不能简单理解成「N 个用户不停请求」，而应该是：N 个在线用户，其中只有一部分用户在某一时刻真正向模型发起请求。

八、六类任务的 Think Time 其实差别很大

比如可以先建立这样一个初始模型：

• 知识问答 —— 10～30 秒
• 写文档 —— 30～120 秒
• 数据分析 —— 30～120 秒
• PPT —— 60～180 秒
• 代码 —— 20～90 秒
• 多轮问答 —— 5～30 秒

这里同样不建议全部写死。更适合的方式是使用区间随机，例如 wait_time = between(10, 30)，甚至进一步使用带权分布。因为真实用户行为本身就是随机的。

九、这样才能理解「3000 用户」到底是什么意思

假设一个办公智能体规划给 3000 人使用。如果直接问「3000 人需要多少服务器？」，其实信息还不够。

因为 3000 人可能意味着完全不同的负载。例如：

• 情况 A：3000 个注册用户，每天只有 500 人真正使用。
• 情况 B：3000 个日活用户，高峰同时在线 800 人。
• 情况 C：800 个在线用户中，同时真正等待 AI 结果的只有 120 人。
• 情况 D：120 个活跃会话，平均每个会话由于 Agent 编排产生 1.8 个并行或连续模型调用。

那么最终模型侧看到的负载，才是我们真正需要关注的东西。

因此我更倾向于建立这样一个折算模型：总用户数 → 日活用户 → 高峰在线用户 → 活跃会话用户 → 模型请求并发 → Agent 调用放大 → 真实模型负载。

图 5 · 从 3000 用户到真实模型负载的折算漏斗（图中数字为示意，不能直接当作容量结论）

十、多轮会话必须单独设计

办公智能体和传统搜索最大的区别之一，就是多轮。

比如用户第一轮说「帮我写一个测试工作总结」；第二轮「性能测试部分再展开一点」；第三轮「不要太技术化，领导要能看懂」；第四轮「把这段再压缩一半」；第五轮「最后帮我形成正式材料」。

看起来每一轮用户输入都很短。但模型收到的上下文可能是：系统 Prompt + 第一轮问题 + 第一轮回答 + 第二轮问题 + 第二轮回答 + …… + 第五轮问题。

所以会话越往后，输入 Token 可能越来越大。

这也是为什么我现在测试办公智能体时，会专门设计：1 轮会话、3 轮会话、5 轮会话、10 轮会话、长会话。

重点观察：上下文增长、TTFT 变化、显存变化、吞吐变化、上下文压缩机制、会话截断机制。

图 6 · 多轮会话为什么会越聊越贵：第 10 轮的上下文成本通常高于第 1 轮

十一、最终我会把六类场景混合起来

单场景测试当然还是需要。因为它能回答：某一种任务的能力边界在哪里？比如纯问答最大并发、长文本最大并发、128K 最大并发、PPT 任务最大并发。

但是如果要评估企业真实使用能力，最终还是应该设计混合场景。例如第一版可以先设：

• 知识问答 —— 35%
• 写文档 —— 20%
• 多轮对话 —— 20%
• 数据分析 —— 10%
• PPT —— 8%
• 代码 —— 7%

这里的比例也只是初始化参数。真正上线以后，最好通过网关日志、Agent 日志、模型调用日志、用户行为日志重新统计，最后形成真正属于自己企业的：AI 办公用户画像。

十二、我现在的 Locust 脚本更希望长成这样

而不是一个虚拟用户只会在 @task 里调用 request() 的写法。

更接近的结构应该是：一个 OfficeUser，下面挂六类任务并按比例分配权重——知识问答 35%、写文档 20%、多轮对话 20%、数据分析 10%、PPT 生成 8%、代码 7%。

然后每一个 Task 内部再随机：输入长度、输出长度、Think Time、会话轮次、附件数量、RAG 片段数量、Agent 调用路径。

也就是说：一个虚拟用户不再只是一个 HTTP 请求发生器，而是尽可能模拟一个真正使用办公智能体的人。

图 7 · 办公智能体的 Locust 用户模型：虚拟用户不是请求发生器，而是办公行为模拟器

十三、最后，我会把测试拆成四层

经过这段时间的实际测试，我现在更倾向于把办公智能体性能测试拆成四层。

第一层：模型基准测试。回答「模型本身跑得怎么样？」主要看 TTFT、TPOT、Token/s、最大并发、输入输出 Token。

第二层：任务场景测试。回答「写材料、问答、PPT 这些任务跑得怎么样？」主要看端到端响应时间、成功率、任务完成时间、Agent 调用次数、工具调用耗时。

第三层：混合用户负载测试。回答「多种办公任务一起跑的时候，系统能支撑多少用户？」这里才真正引入六类任务比例、Token 分布、Think Time、多轮会话、用户行为模型。

第四层：容量规划。最终回答领导最关心的问题：这些服务器，到底够多少人用？

这里就不能只看 Token/s 了。而需要建立：业务用户规模 × 高峰使用率 × 活跃率 × 请求频率 × Token 消耗 × Agent 调用放大，最终转换成算力资源需求。

图 8 · 四层模型：不是能压多少并发，而是到底够多少人用

十四、真正难的不是压出一个并发数字

做到最后，我现在越来越觉得：企业办公智能体性能测试最难的一步，其实不是把并发从 10 压到 20、再压到 40。

真正困难的是：建立一个合理的真实用户模型。

因为只有知道：用户在干什么、一次任务输入多少 Token、输出多少 Token、一天会发多少次请求、每次请求之间隔多久、一个会话有多少轮、一次 Agent 任务会放大成多少次模型调用——才能真正回答：这套算力到底够不够。

否则我们很容易得到一个非常漂亮的结论：「当前支持 40 并发。」

但领导真正问你的时候可能只有一句：那到底够多少人用？

这两个问题之间，其实还隔着一整套用户行为模型。

所以如果现在让我重新设计一套企业办公智能体性能测试，我大概会遵循这样的顺序：

先设计人。再设计任务。再设计 Token。再设计 Think Time。再设计会话。最后，才是并发。

因为服务器最终承载的从来不是一个抽象的「并发数」，而是：一个个正在写材料、查知识、做分析、改 PPT、写代码、和 AI 连续交流的人。

这可能才是企业办公智能体性能测试真正应该模拟的东西。