把 Agent 送进千问平台前，先过这 17 道性能关卡：一次 A2A 压测实录
质量工程实战 · 2026-07 · betae 环境
一、背景：Agent 要"上架"第三方平台，对方先甩来一份验收模板
我们的 Agent 服务要接入千问开放平台。对方给了一份性能验收模板，列了 17 项指标，分五大类：OAuth 授权、SSE 流式输出、对话性能、H5 页面、事件回调。不达标不接。
这份模板最大的价值不是"考试"，而是它把"一个 Agent 在第三方平台上会被用户怎么用、哪些环节会卡"拆成了可测的原子指标——这正是我们平时容易漏测的地方：多数团队自测 Agent 只测"回答正不正确、快不快"，但平台的视角是每一次网络往返、每一个流式帧、每一张卡片。
二、模板在验什么：17 项指标背后的用户感知
先看懂模板每一类在防什么用户体感问题：
| 大类 | 指标 | 它在防什么 |
|---|---|---|
| OAuth 授权 | 授权时间 P50/P99 | 用户点"去授权"后授权流程卡顿、无响应 |
| SSE 流式 | 首帧延迟 TTFT | 发完 query 半天看不到一个字 →"卡顿/无响应" |
| SSE 流式 | 完整响应时间 | 等待完整回答过久，尤其要出卡片的场景 |
| SSE 流式 | 帧率 / 帧均字符数 | 文字"一跳一跳"或"一坨一坨蹦出来"，打字机不连贯 |
| SSE 流式 | 帧间隔 P50 | 打字机整体偏慢、（P50≤100ms=典型帧率≥10帧/s） |
| SSE 流式 | 连接稳定性 | 对话输出到一半突然中断、内容不完整 |
| 对话性能 | 卡片渲染 / 首字耗时 | 卡片场景或纯文本首屏等待超时 |
| H5 页面 | 授权页/业务页加载、H5 内 API | 点击后白屏、页面加载中、操作卡顿 |
| 事件回调 | 回调响应时间/成功率 | 回调中同步耗时操作拖垮平台侧流程 |
有几个指标特别值得展开——它们是这份模板的"含金量"：
TTFT（首帧延迟）要按 kind=task 帧卡点，不是"第一个文字"：发请求 → 收到第一个 task 帧。这衡量的是平台编排链路首包响应，不含生成。
帧间隔 P50 替代"平均帧率"：模板明确写了"此指标替代原流式输出帧率的平均值概念"。因为流式输出时快时慢（思考间歇、首尾帧分布不均），平均值会被少数密集帧拉高，中位数才能反映典型打字机水平。
帧均字符数防"块状输出"：单帧字符太多 → 视觉上"一坨一坨蹦出来"；太少（我们实测约 1.7 字符/帧）→ 打字机过细、开销大。帧间隔 + 帧均字符数配合，才完整定义"流畅打字机"。
三、实测方法：A2A 协议下的阶梯压测
- 协议：A2A（Agent 对 Agent），入口
POST /api/v1/qianwen/a2a - 阶梯：5 / 10 / 15 / 20 并发 × 5 loops = 250 次请求，每请求新
contextId（新会话）+ 独立X-Ebao-User-Id（模拟不同用户） - 判定口径：HTTP 200 + SSE
final=true+state=completed+ 至少一段文本 = 成功；空答 / 流失败 / 断连分别计数 - SSE 帧语义：
task→artifact-update*→status-update final - 入口边界：Gateway 公网 + Sandbox Bearer 仍 401，最终走 orchestrator 内网；计时为客户端往返近似
四、实测结果：250/250 全成功，但"贴线"和"超标"各有一堆
主链路：A2A 阶梯（2026-07-22）
| 并发 | N | 成功率 | 断连率 | 完整 P50 | 完整 P99 | TTFT P50 | TTFT P99 | 帧间隔 P50 | 吞吐 rps |
|---|---|---|---|---|---|---|---|---|---|
| 5 | 25 | 100% | 0% | 14.2s | 18.9s | 1.03s | 1.63s | 1.5ms | 0.338 |
| 10 | 50 | 100% | 0% | 16.4s | 25.8s | 1.37s | 3.13s | 5.5ms | 0.539 |
| 15 | 75 | 100% | 0% | 20.9s | 34.7s | 1.73s | 6.77s | 7.9ms | 0.653 |
| 20 | 100 | 100% | 0% | 22.6s | 44.5s | 1.88s | 4.73s | 8.7ms | 0.760 |
稳定性满分：250/250 classify=success，0 断连 / 0 空答 / 0 流失败。
对照模板门槛：三类结论
| 模板指标 | 要求 | 实测 | 结论 |
|---|---|---|---|
| 成功率 | ≥99% | 100% | ✅ 达标 |
| 帧间隔 P50 | ≤100ms | 1.5~8.7ms | ✅ 达标 |
| 连接稳定性 | 断连<1% | 0% | ✅ 达标 |
| TTFT | P50≤1s / P99≤3s | 5 并发 P50=1.03s 贴线；≥10 并发 P50 1.37~1.88s 超；10/15/20 P99 3.13~6.77s 部分超 | ⚠️ 高并发未达字面门槛 |
| 完整响应时间 | P50≤5s / P99≤15s | P50 14~23s，P99 19~45s | ❌ 远未达字面门槛 |
| 并发承载 | 时延退化≤10% | 5→20 完整 P50 +59%（14.2→22.6s）；错误率不降 | ⚠️ 延迟抬升明显 |
五、三个真正的"考点"（方法论部分）
1. 完整响应时间超门槛≠服务有问题，是SLA 口径问题
模板的"完整响应 P50≤5s / P99≤15s"显然是给普通对话接口定的。Agent + LLM 长链路（检索 → 规划 → 多轮工具调用 → 生成）天然是 10~20s 量级——我们 5 并发 P50 也要 14.2s。直接把算法类模板门槛套在 Agent 上会得出"不合格"的假结论。正确动作是把 Agent 类 SLA 单独与平台协商，而不是硬压性能。
2. TTFT 高并发排队是"容量承诺"的信号
5 并发 TTFT 贴线（1.03s），15 并发 P99 飙到 6.77s——首帧排队在更高并发下被放大。这直接决定对外承诺：代表值交 5 并发，对外并发承诺 ≤10，别在 20 并发档打广告。
3. 交表也要讲策略：七项可交、三项要谈
- 可交：成功率、断连率、帧间隔 P50、阶梯全表 + Excel、帧率/帧均字符数（观察项）
- 需协商：完整响应 5s/15s、高并发 TTFT P50≤1s / P99≤3s
- 未测项如实标注：卡片渲染（功能未调试）、回调 P99（未压 POST 回调）、月度可用性（需线上周期统计，短时压测不能代替）
六、数据之外的待办（这次暴露的工程债）
- Sandbox→Gateway 401 未解：压测只能走 orchestrator 内网，公网入口版本待鉴权打通后复测
- 服务端三时刻 Header 缺失：目前 TTFT/完整时延全是客户端往返近似，服务端埋点（收到请求/首帧写出/final 写出）落位后口径才能对齐
- 回调是 fail-soft 的坑：鉴权失败时 gateway 仍返回 code=0，成功率不能只看接口返回，要捞日志
七、方法边界（写清楚，别让数据背锅）
- 客户端计时（含网络传输），非服务端 recv/写出埋点
- 每请求新会话 + 独立用户 ID；未含 OAuth 授权耗时、回调 P99、H5 渲染
- 短时压测窗口（minutes 级）≠ 月度可用性（需监控周期统计）
原始数据：A2A scripts/jmeter/results/qwen_a2a_20260722_192703.json；OAuth qwen_oauth_20260720_192603.json；阶梯 5/10/15/20 × 250 次。