1. 为什么 Agent 性能测量总是“测了个寂寞”如果你正在做 AI Agent 的工具链评估大概率遇到过这种场景本地跑一个 Agent 任务感觉挺快上线后用户却抱怨“转圈半天”离线评测准确率 92%真实流量里却频繁答非所问压测报告写着 QPS 30生产环境并发一上来就雪崩。问题不在于你不会测而在于响应时间、准确率、吞吐量这三个指标被混在一起测且没有统一的采集口径。AI Agent Harness Engineering 的核心工作之一就是把 Agent 的“感知—推理—工具调用—响应”整条链路用一套可复现的测量骨架管起来。它适合三类人正在给 Agent 工具链做性能基线的工程团队、需要向业务方交付 SLA 的架构负责人、以及想搞清楚“我的 Agent 到底慢在哪”的独立开发者。这篇内容不讲空泛的方法论直接给你可复制的settings.json/config.toml采集配置骨架配合分步验证动作让你能自己跑出一份可对比的三指标报告。需要先明确一个前提Agent 的响应时间不是单一数字它至少包含网络往返、排队等待、模型推理、工具调用、结果组装五段准确率也不是一个百分比而是任务完成率、字段正确率、格式合规率的加权吞吐量更不是“每秒请求数”这么简单它和并发数、超时设置、重试策略强耦合。下面按“先搭采集环境再分项测量最后交叉核对”的顺序展开。2. 用 TaoToken 做统一接入层的前置准备在开始写采集脚本之前建议先把模型调用收敛到一个统一入口否则你会在每个 Agent 节点里重复处理鉴权、超时、重试和用量统计测量结果根本没法横向对比。我自己的做法是用 TaoToken 作为模型接入层它提供 OpenAI 兼容的接口形态Agent 侧只需要改base_url和api_key两个字段就能把不同模型的调用统一到一套日志和计时口径下。具体操作路径先到 TaoToken 控制台 创建一个项目然后在 API Keys 页面 生成一个 key。这个 key 后面会写进你的采集配置里用于 Agent 的模型调用。接口地址统一用https://taotoken.net/api注意这个地址不带任何查询参数避免被误当成带追踪的链接。如果你只是想先验证模型是否通、响应时间大概什么量级可以直接用 模型对话 页面手动发几条请求观察首 token 延迟和完整响应时间心里有个底。但要做系统性测量还是得落到代码和配置文件上。对于需要长期跑 Agent 编码任务、做多轮工具调用的团队可以了解 Coding Plan它更适合把测量流程固化到日常开发循环里。注意所有采集脚本里的 key 都不要硬编码进仓库用环境变量注入否则你的性能报告还没发出去key 先泄露了。3. 可复制的指标采集配置骨架这一节是全文的核心。我给你两套配置一套是 Agent 运行时的settings.json控制超时、重试、并发和日志字段另一套是测量任务的config.toml定义三指标的采集参数和输出路径。两套配置配合使用才能保证“同一份输入跑出可对比的输出”。3.1 settings.jsonAgent 运行时采集配置{ agent: { name: harness-bench, endpoint: https://taotoken.net/api/v1/chat/completions, api_key_env: TAOTOKEN_API_KEY, model: gpt-4o-mini, timeout_ms: 30000, max_retries: 2, retry_backoff_ms: 500, concurrency: 8 }, instrumentation: { enable_stage_timing: true, stages: [queue, network, inference, tool_call, assemble], record_token_usage: true, record_tool_trace: true, log_format: jsonl, log_path: ./logs/agent_trace.jsonl }, accuracy: { eval_mode: weighted, criteria: [ { field: task_completed, weight: 0.4, type: boolean }, { field: answer_exact, weight: 0.4, type: exact_match }, { field: format_valid, weight: 0.2, type: regex, pattern: ^\\{.*\\}$ } ] } }这份配置的关键点有三个。第一enable_stage_timing打开后Agent 每处理一个请求都会在agent_trace.jsonl里写一条包含五个阶段耗时的记录这是后面算 P50/P95/P99 的原始数据。第二concurrency先设成 8不要一上来就拉满否则你分不清是系统瓶颈还是测量工具本身在抢资源。第三accuracy.criteria用加权方式定义“正确”避免单一 exact match 把语义正确但措辞不同的回答判错。3.2 config.toml测量任务配置[measurement] name harness-perf-baseline warmup_requests 20 sample_requests 200 output_dir ./reports [latency] percentiles [50, 90, 95, 99] stage_breakdown true cold_start_separate true [accuracy] dataset_path ./datasets/agent_eval.jsonl sample_size 100 human_review_ratio 0.1 [throughput] mode staircase start_concurrency 1 end_concurrency 64 step 8 step_duration_sec 30 monitor_interval_sec 1warmup_requests 20是为了避开冷启动对响应时间分布的污染cold_start_separate true会把前 20 个请求单独统计。吞吐量用阶梯模式从并发 1 逐步加到 64每档跑 30 秒这样你能看到 QPS 随并发上升的曲线以及在哪一档开始出现响应时间陡增——那个拐点就是系统的实际容量边界。3.3 采集脚本的调用方式把上面两份配置放到项目根目录后用一段 Python 驱动脚本读取它们并执行测量。核心逻辑是先按settings.json初始化 Agent 客户端再按config.toml的节奏发请求每条请求的耗时和结果都追加写入 jsonl。这里不展开完整脚本重点是你需要确保每次测量前清空logs/agent_trace.jsonl否则新旧数据混在一起百分位数会失真。4. 分步验证三项指标是否测准配置搭好只是第一步真正容易翻车的是“测出来的数不对”。下面按响应时间、准确率、吞吐量分别给验证动作。4.1 响应时间先看阶段分解再看百分位跑完一轮 200 个样本后先别急着看平均值。打开agent_trace.jsonl随便挑 5 条记录检查stages字段里的五段耗时之和是否等于total_ms。如果对不上说明你的计时埋点有重叠或遗漏。确认无误后用下面的命令快速算百分位python -c import json, statistics rows [json.loads(l) for l in open(./logs/agent_trace.jsonl)] totals sorted(r[total_ms] for r in rows if r.get(total_ms)) for p in [50, 90, 95, 99]: idx int(len(totals) * p / 100) print(fP{p}: {totals[min(idx, len(totals)-1)]} ms) print(mean:, statistics.mean(totals)) 如果 P50 和 mean 差距超过 30%说明响应时间分布严重右偏大概率是少数请求触发了重试或工具调用超时。这时候要回到agent_trace.jsonl里筛出total_ms最大的 10 条看它们的stages.tool_call是不是异常高。4.2 准确率加权分数要能解释准确率验证的关键是“可解释”。跑完 100 个评测样本后你的报告里应该同时有总分和分项分。比如总分 0.78其中task_completed0.9、answer_exact0.7、format_valid0.8这样你才知道是“任务基本能完成但答案措辞不稳定”。如果只报一个 78%业务方问“哪里不行”你就答不上来。另外human_review_ratio 0.1意味着抽 10 条人工复核。如果人工复核结果和自动评分差异超过 15%说明你的评估标准定义有问题需要回去改settings.json里的criteria。4.3 吞吐量找拐点而不是找最大值阶梯压测跑完后你会得到一张表并发数、QPS、P95 响应时间。判断系统容量的标准不是 QPS 最高点而是P95 响应时间开始超过你 SLA 阈值的那一档。比如并发 32 时 QPS 45、P95 800ms并发 40 时 QPS 48、P95 2100ms那你的安全容量就是 32 并发不是 40。多出来的 3 个 QPS 是用 2.6 倍的尾延迟换来的不划算。5. 本篇常见错排查报错一401 Unauthorized或invalid api key。检查TAOTOKEN_API_KEY环境变量是否真的注入到了运行进程里而不是只写在了.env文件里没 source。另外确认 key 没有多余空格复制时容易带上换行。报错二timeout_ms设了 30000 但请求 5 秒就断了。这通常是 Agent 框架自己的默认超时覆盖了你的配置。检查框架层是否有独立的request_timeout参数两处都要改。报错三准确率跑出来 0.0 或 1.0 这种极端值。大概率是evaluation_criteria里的字段名和实际输出对不上导致所有样本都走了默认分支。打印一条actual_output和expected_output对比字段结构。报错四吞吐量阶梯测试中 QPS 不升反降。检查是不是触发了服务端的限流或者你的测量机本身 CPU 打满了。用top看一下测量进程的资源占用如果测量机先扛不住那测的就不是 Agent 的吞吐量。报错五agent_trace.jsonl里stages字段缺失。确认enable_stage_timing为 true并且你的 Agent 代码在关键节点调用了计时打点函数。有些框架需要手动注册 hook 才会输出阶段数据。6. 把测量流程固化下来三指标测量最容易犯的错是每次换个人、换个时间跑结果都对不上。解决办法是把settings.json、config.toml和驱动脚本一起提交到仓库每次测量前用git rev-parse HEAD记录代码版本报告里带上版本号。这样当准确率从 0.82 掉到 0.75 时你能快速定位是哪次提交引入的回归。如果你需要把这套流程接到 CI 里让每次 Agent 代码合并前自动跑一轮基线测量可以参考 接入文档 里的批量调用说明把测量任务包装成一个可重复执行的 job。对于已经在用 Claude Code 做 Agent 开发的团队ClaudeCodeAnthropic 这条路径也能帮你把测量脚本和日常编码工作流串起来减少手动切换成本。最后留一个实操建议第一次跑不要追求样本量大先用 20 个 warmup 50 个样本把流程跑通确认三份输出响应时间分布、准确率分项、吞吐量拐点都能正常生成再逐步加到 200 样本和 64 并发。测量工具本身也需要预热急不得。
