在本地跑通一个 27B 规模的开源模型，然后把它接到 Agent 能力测试平台上跑完整链路，中间踩了不少坑。尤其是小模型在做工具调用、多步规划和记忆保持时，表现和大模型差距比想象中明显，但也有一套可复现的评估方法。本文会完整拆解这套“小模型 Agent 能力测试天梯”的搭建过程，包含本地部署、Agent 框架选型、测试任务设计、评分脚本和常见排错，适合正在做本地模型选型、Agent 应用落地或想要系统评估模型能力的开发者参考。
1. 背景：为什么小模型也要认真测 Agent 能力
1.1 从大模型到 Agent 的转变
过去两年，大家关注的重点主要是“模型能不能回答对”，也就是问答、摘要、翻译这类单轮任务。但到了 Agent 阶段，模型不再只是生成一段文字，而是要在一个循环里反复做决策：理解用户目标、拆解子任务、选择工具、读取结果、修正计划、再执行下一步。
这种能力差异，用传统的 benchmark（比如 MMLU、CEval）很难测出来。一个在知识问答上拿到高分的模型，可能在 Agent 场景里连“先查天气再订车”这种两步任务都跑不通。原因是 Agent 任务更看重指令遵循、结构化输出、工具调用准确性、错误恢复和长上下文的注意力分配，这些恰好是小模型最容易拉胯的地方。
所以在模型选型阶段，不能只看跑分，要专门建一套 Agent 能力测试天梯，把模型放在真实 Agent 执行链路里，用标准任务去压测。
1.2 小模型做 Agent 的挑战
这里的“小模型”没有绝对定义。本文讨论的是 27B 这个规模，它比动辄上百 B 的大模型轻量很多，普通单卡工作站就能量化运行，但又比 7B、14B 模型的综合能力强不少。
在实际测试中，27B 模型做 Agent 会面临几个典型挑战。
第一是工具调用格式不稳定。小模型在 Function Calling 时经常出现参数名写错、JSON 不合法、多余解释文本混入工具调用结果的情况。这在评测时直接表现为“工具调用失败率高”。
第二是多步规划容易断层。两步以内的问题大多能完成，但五步以上的任务经常做到第三步就开始偏离原始目标，或者重复执行同一个子任务。
第三是长上下文下的注意力衰减。Agent 执行过程中会积累工具返回结果、历史消息和中间计划，当上下文超过一定长度，模型会忽略早期约束，甚至把工具输出当成用户指令来执行，产生幻觉式行为。
第四是错误恢复能力弱。工具执行失败后，大模型通常会重新组织计划，小模型则容易陷入死循环，或者直接对用户说“我做不到”。
这些挑战都需要通过结构化的测试来量化，而不是凭感觉判断。
1.3 本文要解决的问题
这篇文章会给出一个可落地的方案，包含三层内容。
第一层是环境：讲解如何在本地用量化方式跑起 Qwen 系列的 27B 模型，并暴露成 OpenAI 兼容接口，方便后续接入 Agent 测试脚本。
第二层是概念：把 Agent 开发中容易混淆的 Tool、Skill、Harness、多 Agent 主从模式讲清楚，因为评测任务的设计必须基于这些概念。
第三层是实战：从零搭建一个 Agent 能力测试天梯，包含测试任务定义、工具注册、Agent 执行引擎、评分与报告输出，最终能对比不同模型版本的 Agent 能力差异。
2. 环境准备：在本地把 27B 模型跑起来
2.1 推理框架选型
本地跑 27B 模型，主流方案有 llama.cpp、Ollama 和 vLLM 三种。三者定位不同，我分别说明。
llama.cpp 适合纯 CPU 环境或低显存环境，通过 GGUF 量化可以把模型压得很小，但并发能力弱，适合单机调试。
Ollama 是 llama.cpp 的封装，安装简单、命令友好，适合快速验证模型是否可用，也内置了 OpenAI 兼容接口，测试脚本接起来很方便。
vLLM 适合 GPU 显存充裕、需要高并发吞吐的场景。它的 OpenAI 兼容接口更完整，Function Calling 支持也更成熟，但环境配置相对复杂，对 CUDA 版本有要求。
本文的测试天梯场景，单机单卡、顺序跑多个测试任务，Ollama 和 vLLM 都足够。如果只是验证思路，推荐先用 Ollama，等测试任务量上来再切 vLLM。
2.2 模型量化方案
27B 模型原始权重对显存要求很高，一般需要量化后再本地运行。量化主要影响显存占用和推理速度，也会影响 Agent 场景下的输出稳定性。
常见量化格式有三种。
GGUF 是 llama.cpp 系列框架的量化格式，支持 4bit 到 8bit 的多种等级，Ollama 直接支持。做 Agent 测试时，推荐优先尝试 Q4_K_M 和 Q5_K_M 这两个等级，前者省显存，后者质量更稳。
GPTQ 和 AWQ 是面向 GPU 推理的量化格式，配合 vLLM 使用。两者在批量推理时性能更好，但 Agent 场景更多是单请求多轮对话，优势不如吞吐测试明显。
这里要特别提醒，量化等级不是越高越好。Agent 任务对输出格式的敏感度远高于普通问答，4bit 低比特量化后，模型在 Function Calling 时更容易输出不合法 JSON。我建议在显存允许的前提下，尽量用 Q5_K_M 或 6bit 量化，稳定性提升明显。
2.3 通过 Ollama 启动 OpenAI 兼容服务
下面以 Ollama 为例，演示如何启动一个 OpenAI 兼容接口。先把模型下载到本地，命令如下：
# 拉取模型，实际模型名以你本地 Ollama 里的为准 ollama pull qwen2.5:27b拉取完成后，设置 Ollama 允许外部访问，并启动服务：
# Linux / macOS 上设置环境变量后启动 export OLLAMA_HOST=0.0.0.0:11434 ollama serve启动后，Ollama 默认会在http://localhost:11434/v1暴露一个 OpenAI 兼容接口。也就是说，我们可以在 Python 里用openai库直接连接它，不需要额外写 HTTP 调用。
验证接口是否正常，可以执行：
curl http://localhost:11434/v1/models如果返回 JSON 列表，说明接口可用。整个部署思路就是把本地模型包装成一个本地版的“OpenAI 服务”，所有下游 Agent 代码不感知底层是 Ollama 还是 vLLM。
如果你的场景需要更高并发，可以改用 vLLM 启动同款模型。启动命令大致如下，但具体参数需要按 vLLM 版本调整：
python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --served-model-name qwen-local启动后同样会暴露一个 OpenAI 兼容接口。需要留意的是，不同框架的 API 参数有差异，示例中写的是 vLLM 常见启动方式，实际使用时要结合当前版本文档确认。
3. Agent 核心概念拆解：评测前先厘清边界
3.1 Agent 的基本组成
在搭建测试天梯之前，必须先统一概念。Agent 应用一般由这几部分组成。
LLM 是决策核心，负责理解目标和决定下一步动作。工具是一组可被模型调用的外部能力，比如查天气、执行 SQL、访问文件系统、调用内部 API。通常每个工具对应一个函数定义，包含名称、描述、参数列表。
执行环境负责真正运行工具代码，并把结果返回给模型。记忆模块负责保存对话历史、中间状态和长期偏好，让 Agent 在多轮任务中不丢失信息。
在测试中，我们要关注模型在这几个部分之间的交互能力。模型必须能根据工具描述选择正确的工具、生成正确的调用参数、理解工具返回结果，并决定继续执行还是结束任务。
3.2 Agent 与 Tool、Skill、Harness 的区别
日常交流中，很多人把 Tool、Skill、Agent 混着说，实际它们有清晰边界。
Tool 是单个可执行函数，粒度最小。比如“获取当前时间”“计算两数之和”就是两个工具。
Skill 是一组具有语义关联的工具组合，有时还包含配套的提示词和流程。例如“数据分析技能”可能包含“读取 CSV”“数据清洗”“生成可视化”多个工具，外加一套分析流程。Skill 更像可复用的能力包，而 Tool 是能力包里的原子操作。
Agent 是运行在 LLM 之上、能自主调用 Tool/Skill 来完成目标的完整系统。它在循环中工作，感知、决策、行动、观察，然后继续感知。Agent 之间也可以协作，形成多 Agent 系统。
Harness 是承载 Agent 运行的框架或运行环境。它负责 LLM 调用的调度、工具执行、上下文管理、超时控制、日志记录。Harness 不决定“做什么”，它决定“怎么跑”。比如 LangChain 的 AgentExecutor、AutoGen 的 GroupChat，都可以看作不同形态的 Harness。
在做测试天梯时，我们测的是 Agent 能力，但实际测的是“模型 + Harness”的组合效果。同一个模型，换一个 Harness，测试结果可能差异很大。
3.3 多 Agent 主从模式
热词里提到的“最新的多 Agent 设计里，主从模式本质上是将 subagent 视作另一种 tool 进行调用”，这个观点很准确。
所谓主从模式，就是有一个主 Agent（Planner），负责接收用户任务、拆解子任务，然后把子任务分发给不同的子 Agent（Executor）。主 Agent 并不直接执行工具，它把“运行一个子 Agent”当成一次工具调用。
这种设计有几个好处。一是职责清晰，主 Agent 专注规划，子 Agent 专注执行；二是上下文隔离，子 Agent 的执行过程不会全量塞回主对话，降低上下文污染；三是便于扩展，增加新能力只需增加一个 subagent，不需要改主 Agent 的逻辑。
但也带来了测试难点。子 Agent 本身也依赖 LLM，小模型在主从模式下相当于“双层决策”，每一层都可能出错，错误会逐层放大。测试任务必须覆盖这种模式，否则无法发现模型在主从协作上的短板。
4. Agent 能力测试天梯设计
4.1 测试维度
Agent 能力的测试，不能只用一个“能不能完成任务”的二元结果。我建议从五个维度设计测试天梯。
维度一是工具选择准确性。任务给出多个工具，模型能否选中正确的一个。
维度二是参数生成规范性。模型生成的 Function Call 参数是否完整、类型是否正确、命名是否匹配。
维度三是多步规划能力。任务需要按顺序调用多个工具，模型能否自主规划并逐步执行。
维度四是错误恢复能力。设计一个工具执行失败的任务，观察模型能否根据报错信息修正计划，而不是死循环或直接放弃。
维度五是记忆与上下文保持。任务中包含临时约束，比如“每步执行前先提醒用户剩余步数”，观察模型在多轮后是否遗忘。
每个维度设计若干子任务，每个子任务对应一个可量化评分标准，最终汇总成天梯分数。
4.2 测试任务示例
下面是一个测试任务的 JSON 示例，定义了一个四步任务：
{ "task_id": "agent_test_003", "category": "planning_and_tool_use", "description": "用户想知道天气并安排一个会议提醒", "expected_steps": [ "调用 get_weather_forecast 获取城市天气", "从天气结果中提取天气状况", "调用 create_reminder 创建提醒", "输出最终总结" ], "available_tools": [ "get_weather_forecast", "get_current_time", "create_reminder", "send_email" ], "max_rounds": 8, "passing_score": 3 }每个测试用例都带上预期步骤、可用工具、最大轮数和通过分数。评测程序读取这个 JSON，把任务注入 Agent，然后根据执行过程和最终结果打分。
4.3 测试框架结构
测试天梯整体可以分为四层。
任务层维护测试用例库，覆盖不同维度和难度。运行层负责加载任务、创建 Agent 实例、注入上下文并控制执行轮数。观测层记录模型每一步的思考、工具调用、工具结果和最终输出，这是打分的依据。评分层根据预期步骤和结果计算分数，输出天梯报告。
这套结构的好处是任务和代码分离。新增测试任务时只需要在 JSON 里加配置，不需要改核心代码。
5. 实战：搭建本地小模型 Agent 测试脚本
5.1 项目结构
我在实战中使用的项目结构如下：
agent-bench/ ├── tasks/ │ └── test_001.json ├── tools/ │ └── custom_tools.py ├── engine/ │ └── agent_engine.py ├── eval/ │ └── scorer.py ├── main.py └── requirements.txttasks存放测试任务配置；tools存放 Agent 可调用的工具函数；engine是 Agent 执行循环；eval是评分模块；main.py是入口脚本。
5.2 编写模型调用客户端
由于 Ollama 暴露了 OpenAI 兼容接口，我们可以直接使用openai库。下面是客户端封装，负责调用本地模型并支持工具定义：
# 文件路径：engine/agent_engine.py 中的客户端部分 from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # 本地服务不校验 key，任意值即可 ) def chat_with_model(messages, tools=None, model="qwen2.5:27b"): kwargs = {"model": model, "messages": messages} if tools: kwargs["tools"] = tools try: response = client.chat.completions.create(**kwargs) return response.choices[0].message except Exception as e: print(f"[client error] {e}") return None这段代码把模型调用收敛到一个函数里。测试时只需要替换model名称，就能对比不同模型。
5.3 编写工具注册与 Function Calling
接下来定义工具函数。这里的工具是本地模拟的服务，用来测试模型的调用能力：
# 文件路径：tools/custom_tools.py import json import random import datetime def get_weather_forecast(city: str) -> str: """模拟天气查询，返回一个固定格式的天气信息""" weather_list = ["晴", "多云", "小雨", "阴"] weather = random.choice(weather_list) return json.dumps({"city": city, "weather": weather, "temperature": 20 + random.randint(-5, 5)}, ensure_ascii=False) def get_current_time() -> str: """获取当前时间""" return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") def create_reminder(content: str, time: str) -> str: """创建一个提醒""" return json.dumps({"status": "created", "content": content, "time": time}, ensure_ascii=False) TOOL_FUNCTIONS = { "get_weather_forecast": get_weather_forecast, "get_current_time": get_current_time, "create_reminder": create_reminder, } TOOL_SCHEMAS = [ { "type": "function", "function": { "name": "get_weather_forecast", "description": "查询指定城市的天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，例如 北京"} }, "required": ["city"] } } }, { "type": "function", "function": { "name": "get_current_time", "description": "获取当前日期和时间", "parameters": {"type": "object", "properties": {}} } }, { "type": "function", "function": { "name": "create_reminder", "description": "创建一条提醒事项", "parameters": { "type": "object", "properties": { "content": {"type": "string", "description": "提醒内容"}, "time": {"type": "string", "description": "提醒时间"} }, "required": ["content", "time"] } } } ]工具注册分成两部分：TOOL_FUNCTIONS是实际执行时调用的 Python 函数，TOOL_SCHEMAS是传给模型的函数描述。模型只能看到描述，不能看到实现。
5.4 编写 Agent 执行引擎
Agent 执行引擎实现一个简单的 ReAct 循环：把系统提示词、用户任务和工具定义传给模型，检查输出是工具调用还是最终回答。如果是工具调用，就执行对应函数，把结果作为 tool 消息追加回消息列表，然后进入下一轮。
# 文件路径：engine/agent_engine.py import json from tools.custom_tools import TOOL_FUNCTIONS, TOOL_SCHEMAS SYSTEM_PROMPT = "你是一个智能助手，请根据用户需求调用工具完成任务。工具调用必须使用标准 function call 格式。" def run_agent(task_description: str, max_rounds: int = 8): messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": task_description} ] trace = [] for step in range(max_rounds): message = chat_with_model(messages, tools=TOOL_SCHEMAS) if message is None: trace.append({"step": step, "event": "error", "detail": "model call failed"}) break tool_calls = getattr(message, "tool_calls", None) if not tool_calls: # 模型直接返回最终答案 trace.append({"step": step, "event": "final_answer", "content": message.content}) return trace for call in tool_calls: fn_name = call.function.name args_text = call.function.arguments trace.append({"step": step, "event": "tool_call", "name": fn_name, "arguments": args_text}) try: args = json.loads(args_text) if args_text else {} fn = TOOL_FUNCTIONS[fn_name] result = fn(**args) result_text = str(result) except Exception as e: result_text = f"工具执行失败: {e}" trace.append({"step": step, "event": "tool_result", "name": fn_name, "result": result_text}) messages.append({ "role": "assistant", "tool_calls": [call.dict()], }) messages.append({ "role": "tool", "tool_call_id": call.id, "content": result_text }) trace.append({"step": "timeout", "event": "max_rounds_exceeded"}) return trace这个实现是目前最简可行的一种，实际生产环境还需要增加超时控制、并发限制和重试机制。
这里有一个值得注意的细节：工具执行结果通过role: "tool"的消息送回模型，tool_call_id必须与模型返回的调用 ID 对应。如果这个 ID 对不上，模型可能无法理解调用结果。
5.5 编写评测与打分逻辑
评分模块负责把任务 JSON 里的预期步骤与实际执行轨迹做对比。我采用“关键步骤命中 + 最终结果检查”的方式打分：
# 文件路径：eval/scorer.py import json def score_task(task: dict, trace: list): expected_steps = task.get("expected_steps", []) score = 0 details = [] for idx, expected in enumerate(expected_steps): hit = False for item in trace: if item.get("event") == "tool_call" and item.get("name") in expected: hit = True break if hit: score += 1 details.append(f"步骤{idx + 1}: 通过") else: details.append(f"步骤{idx + 1}: 未完成，期望包含 {expected}") # 检查是否出现死循环或超时 if any(item.get("event") == "max_rounds_exceeded" for item in trace): details.append("提示: 达到最大轮数，可能陷入死循环") return score, details def load_tasks(tasks_dir: str): import os, glob tasks = [] for path in glob.glob(os.path.join(tasks_dir, "*.json")): with open(path, encoding="utf-8") as f: tasks.append(json.load(f)) return tasks评分设计不需要太复杂，重点是可复现。相同任务、相同模型、相同 Harness 的情况下，多次运行结果应该一致或接近一致。
5.6 运行测试与结果解读
入口脚本main.py把上面模块串起来：
# 文件路径：main.py from eval.scorer import load_tasks, score_task from engine.agent_engine import run_agent def main(): tasks = load_tasks("tasks") for task in tasks: print(f"\n===== 运行任务: {task['task_id']} =====") trace = run_agent(task["description"], max_rounds=task.get("max_rounds", 8)) score, details = score_task(task, trace) for detail in details: print(detail) print(f"任务 {task['task_id']} 得分: {score}/{len(task['expected_steps'])}") if __name__ == "__main__": main()运行命令：
python main.py预期输出会包含每一步的工具调用记录和最终得分。如果模型在某个任务上得分偏低，可以进一步查看 trace，判断是工具选择错误、参数生成错误还是执行到一半放弃。
从多次测试结果来看，27B 模型在两步工具调用类任务上通常表现不错，但在五步以上的规划任务上会出现明显的得分下滑，主要丢分点集中在“中间步骤跳过”和“参数格式不合法”两类问题上。
6. 常见问题与排查思路
6.1 “Agent execution provider did not respond in time”
这个报错在 Agent 框架中很常见，通常表示执行组件在限定时间内没有返回结果。可能有几种原因。
模型推理超时是最常见的一种。27B 模型在 CPU 或低显存环境下，单轮推理可能需要几十秒，超过了 Agent 框架的默认超时阈值。
排查思路是先确认模型推理耗时，手动调用一次模型接口，观察返回时间。如果确实慢，需要调大 Agent 框架的超时配置；如果还不行，就要考虑换更高量化精度或减少并发。
还需要检查工具执行是否卡住。比如工具内部有网络请求或死循环，会导致整个 Agent 执行流程挂起。建议给所有工具调用加超时保护，避免单点卡死影响测试结果。
6.2 显存不足与推理崩溃
本地跑 27B 模型最常见的问题是显存不够。现象是启动服务后第一次推理就报 CUDA OOM，或者推理几轮后崩溃。
遇到这种情况，先确认模型量化等级。显存紧张时优先使用 4bit GGUF 量化，同时把上下文长度调小。上下文长度对显存占用影响很大，Agent 任务默认 8192 就可能吃掉额外几个 GB。
另一个容易被忽略的是并发请求。如果测试脚本同时发多个请求，单张显卡很容易被撑爆。测试阶段应该把并发设置为 1，以串行方式跑完所有任务。
6.3 Function Calling 返回格式不稳定
小模型在 Function Calling 时偶尔会给出非法 JSON，比如参数名加上了中文引号、布尔值写成字符串、数组末尾多逗号。这类错误会导致json.loads失败，工具无法执行。
排查时先看原始返回内容，确认是模型问题还是 SDK 解析问题。如果是模型问题，可以在系统提示词里增加格式约束，或者在解析失败后把错误信息重新喂给模型，让它修正。
更稳妥的方案是加一层格式兜底，比如用正则提取 JSON 片段，或者用json.loads的strict模式逐级解析。但要注意，兜底逻辑不能过度依赖，毕竟评测目的是暴露模型真实能力。
6.4 上下文被快速占满
Agent 多轮执行会不断累积消息，尤其是工具返回结果很大的时候，可能一轮任务就占满上下文窗口。当上下文过长，模型可能忽略早期指令，导致任务失败。
建议在测试框架里加上下文压缩机制，比如超过阈值时，把旧的工具结果摘要化，只保留关键信息。但这会引入额外变量，测试时要标注清楚使用了压缩策略，否则结果对比不公平。
6.5 多 Agent 协作时子任务不收敛
主从模式下，主 Agent 把子任务发给子 Agent，如果子 Agent 执行结果不明确，主 Agent 可能反复派发同一任务，形成死循环。
排查思路是在 trace 中检查是否有重复的工具调用。如果存在反复调用相同工具且入参相同的情况，说明模型没有从工具结果中提取到有效信息。可以在工具返回结果中加入更明确的状态字段，帮助模型判断任务是否完成。
7. 最佳实践与工程建议
7.1 本地部署方面
在本地部署推理服务时，优先固定版本。Ollama、vLLM 乃至模型的版本变化，都可能影响 Agent 能力表现。测试报告里必须记录推理框架和模型版本，否则结果无法复现。
显存不足时不要盲目降低量化精度。建议先压测不同量化等级在同一批 Agent 任务上的得分，找精度和速度的平衡点。
7.2 Agent 编排方面
建议将 Agent 编排逻辑与模型实现解耦。客户端只依赖 OpenAI 兼容接口，这样模型可以从 Ollama 切换到 vLLM，甚至切换到云端 API，评测代码不需要大改。
对复杂任务，优先拆成多个子 Agent。主 Agent 负责规划和结果汇总，子 Agent 负责具体执行。这种模式对小模型更友好，因为每个 Agent 承担的上下文压力更小。
7.3 测试与评分方面
测试任务库要定期更新。Agent 评测天然存在“过拟合”问题，模型可能会记住常见任务的格式。建议维护两个任务集，一个用于开发调试，一个用于最终验收，且验收集不能出现在调试过程中。
评分要区分“过程得分”和“结果得分”。有些任务即使过程跑偏，最终结果也碰巧正确。只统计结果会掩盖模型的规划薄弱点，只统计过程又会忽略实际可用性。两者结合更合理。
7.4 安全与权限边界
Agent 测试如果涉及真实工具调用，必须明确权限边界。比如工具能读取文件、执行命令或访问数据库，测试环境一定要与生产环境隔离，使用最小权限账号。
在代码层面，所有工具调用都要加白名单校验。测试脚本只允许调用预先注册的本地模拟工具，不要直接暴露真实 API。这样可以避免模型在测试中意外触发危险操作。
日志记录也很重要。Agent 执行过程中的人工不可读日志要保留完整 trace，方便事后审计。尤其在涉及业务数据或用户信息时，trace 中可能会包含敏感内容，要注意脱敏后再存储。
8. 总结与下一步
这篇文章从本地部署开始，带大家完整搭建了一套针对 27B 小模型的 Agent 能力测试天梯。核心收获可以总结为三点。
第一，Agent 能力测试必须放在真实执行链路里做，传统基准分只能作为参考。通过工具调用、多步规划、错误恢复等维度设计任务，才能真正看出小模型在 Agent 场景下的短板。
第二，本地推理框架和量化方案会直接影响模型表现。同样的模型用不同量化等级跑，Function Calling 的稳定性差距很明显。做评测前先把环境固定下来。
第三，评测脚本要尽量模块化，任务、工具、执行引擎、评分逻辑分离，方便后续扩展。实际项目中，这套结构也可以作为 Agent 应用开发的基础框架继续演进。
接下来可以继续尝试的方向包括：把测试任务扩展到多 Agent 主从模式，验证主 Agent 对 subagent 结果的调度能力；或者在上下文压缩策略上做更多实验，观察能否改善长任务下的丢分问题。建议先把现有脚本跑通，记录一批基线数据，再逐步调整测试维度。
