企业官网建设流程全解析

最近在业务里折腾 Agent 应用评测和 LLM 基准对比，和几个团队交流后发现一个普遍现象：大家花大量时间调 Prompt、配工具、接知识库，但测试和评估环节却非常薄弱。很多人还在用“人工跑几条用例，肉眼看效果”的方式判断 Agent 好不好用。这种模式在单轮 Chat 场景勉强能凑合，一旦进入 Agentic 场景——多轮推理、工具调用、长上下文、自主规划——就完全不够用了。

本文将围绕 Agentic 测试流程（Agentic Test Processes）和 LLM 基准评估（LLM Benchmarks）展开。我会先讲清楚这两个概念到底是什么、解决什么问题；然后给出一套可复用的 Agent 测试脚本和一个轻量基准评估思路；最后分享我在工程实践中踩过的坑，以及沉淀下来的最佳实践。

适合读者：正在做 LLM 应用、Agent 产品、RAG 系统评测的开发者；想系统了解模型评估体系的算法工程师；以及想给团队搭建自动化评测流程的技术负责人。读完你至少能回答三个问题：Agent 应该测什么、怎么测；基准评估的分数是怎么来的；以及如何把评估流程落地到日常开发中。

1. 背景：为什么 Agent 测试和 LLM 基准评估值得认真做

1.1 从 Chat 到 Agent，测试对象变了

传统 LLM 应用是一个“单轮问答”形态：用户提问，模型回答。测试时只需要准备一批问题和标准答案，对比输出相似度即可。

但 Agent 应用完全不同。Agent 的核心是“循环”：模型先理解任务，再决定调用哪个工具，拿到工具结果后继续推理，直到完成任务。这个过程中，每一步都可能出错：

• 第一步就把任务理解偏了；
• 工具名称选错，或者参数格式不对；
• 拿到工具结果后没有正确利用，而是自顾自编答案；
• 陷入死循环，反复调用同一个工具；
• 被用户输入或工具返回内容诱导，执行了计划外的行为。

这些问题在单轮评测中几乎测不出来。所以 Agentic 测试流程的核心思路是：把“多轮交互整条链路”作为测试对象，而不是只测“模型生成了什么文本”。

1.2 什么是 Agentic 测试流程

通俗地说，Agentic 测试流程就是围绕“Agent 的自主行为”设计的一套测试方法。它不只看最终答案对不对，还要看过程是否合理、工具调用是否规范、失败时是否能正确恢复。

一个完整的 Agentic 测试流程通常包含：

• 场景设计：把真实业务拆成具体的任务场景；
• 用例编排：每个场景包含用户输入、期望行为、可接受的边界；
• 执行引擎：自动跑 Agent，记录完整轨迹；
• 结果判定：通过规则、断言或模型评判，判断用例通过还是失败；
• 回归机制：模型升级、Prompt 调整、工具变更后，自动重跑。

这套流程解决的核心问题是：Agent 的行为具有高不确定性，同一个输入在不同时间可能得到不同结果。如果不把测试流程自动化、标准化，你永远分不清一次失败是“偶发问题”还是“系统缺陷”。

1.3 LLM 基准评估是什么

LLM 基准评估（Benchmark）是另一件事：用一套固定的、公开的测试集，去衡量模型在不同能力维度上的表现。

常见的评估维度包括：

• 综合知识：考察模型的知识广度和多选推理能力，典型如 MMLU、C-Eval；
• 代码生成：考察模型能否根据函数注释生成正确代码，典型如 HumanEval；
• 数学推理：考察多步计算与逻辑推理，典型如 GSM8K；
• 通用 Agent 行为：考察模型在复杂环境中的规划与工具使用能力，典型如 AgentBench、SWE-bench。

注意，这里我没有写具体版本号，因为这些数据集和榜单更新非常快，你动手实践时一定要以对应项目仓库的最新说明为准。

1.4 容易混淆的三个概念

很多刚接触的同学会把下面三个词混在一起：

• Eval（评估）：一个统称，指任何对模型或应用效果的衡量过程；
• Benchmark（基准）：一套标准化的测试集，用于横向对比不同模型，比如公开榜单；
• Test（测试）：针对你具体业务场景设计的验证用例，目的是保证产品质量。

打个比方：Benchmark 像“全国统一高考”，用来横向比较所有考生；Eval 像是“学校组织的常规考试”，范围可以自己定；Test 像是“岗位入职考核”，题目完全贴合你的业务。企业落地时，三者都需要，但优先级通常是 Test > Eval > Benchmark。

2. 环境准备与工具选型

2.1 环境清单

在动手写测试代码之前，先把环境理清楚。以下是一份基础清单：

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示测试流程的设计思路。

2.2 被测对象：最小 Agent

为了不让示例被某个具体框架绑死，我会写一个极简 Agent：它维护一个消息列表，循环调用 LLM，LLM 返回“工具调用指令”或“最终答案”，Agent 根据指令执行工具并把结果追加回上下文。

真实项目中，你完全可以用 LangChain 的 AgentExecutor、LlamaIndex 的 AgentRunner，或者自研框架替换。测试流程本身与框架无关，重要的是“可记录的输入输出轨迹”。

2.3 评测框架怎么选

市面上的 LLM 评测框架很多，比如 DeepEval、promptfoo，以及各云厂商自带的评测服务。选型时建议关注四点：

• 是否支持自定义测试集和评判规则；
• 是否能记录和回放完整轨迹；
• 是否方便接入现有 CI 流程；
• 是否支持 LLM-as-Judge（用模型辅助评判主观答案）。

如果团队刚起步，我建议先不要引入重框架。用一个几百行的 Python 脚本把流程跑通，理解清楚之后再迁移到成熟框架，成本更低，也不容易被框架的抽象带偏。

3. 核心原理：测试与评估要拆到哪一层

3.1 Agent 测试的三层拆解

我习惯把 Agent 测试拆成三层，每一层的目的和手段都不同：

• 单元层：测试单个 Prompt 模板、单个工具函数、单次 LLM 调用的输入输出。比如“工具参数解析是否正常”“Prompt 在边界输入下是否崩溃”。这一层可以用最朴素的单元测试覆盖，速度快、成本低。
• 流程层：测试 Agent 的完整循环。给定一个用户输入，让它最多跑 N 步，断言每一步的工具调用是否符合预期、最终是否完成任务。这是 Agentic 测试的核心。
• 场景层：模拟真实用户的完整操作路径。比如 agentic RAG 场景下，用户先问“帮我找上季度的销售数据”，Agent 要完成“检索→筛选→汇总→回答”一系列动作。这一层要结合业务数据，做端到端验证。

三层各司其职：单元层解决“零件是否合格”，流程层解决“装配是否顺畅”，场景层解决“整车能不能上路”。

3.2 基准评估的四个构成要素

任何基准评估，无论简单还是复杂，都有四个构成要素：

• 数据集：一批带标准答案的题目，必须有明确的答案判定规则；
• 模型接口：统一的模型调用方式，保证对比公平；
• 采样策略：固定随机种子、控制 temperature 等参数，避免因为采样波动导致分数失真；
• 评分函数：把模型输出映射成可比较的分数，可能是精确匹配、模糊匹配，也可能是代码测试用例通过率。

理解这四个要素之后，你会发现“刷榜”有很多操作空间：比如测试集泄漏进训练数据、答案判定宽松、采样次数取最大值等。所以看到 benchmark 分数时，先别急着膜拜，看看它的数据是否隔离、判定是否严格。

3.3 为什么 Agent 效果不能只靠分数

这里想特别提醒一点：LLM benchmark 分数高，不代表你的 Agent 产品好用。

原因很简单。Benchmark 考的是模型的“单点能力”，比如一道数学题、一段代码；但 Agent 产品是“系统能力”，它涉及检索质量、工具设计、上下文管理、异常恢复等大量非模型因素。

举个我遇到的例子：某个模型在通用推理 benchmark 上表现很好，但在我们的 agentic RAG 场景里，它频繁地“跳过检索步骤直接编答案”，因为它的能力分布和业务场景不匹配。反过来，一个小参数模型在 benchmark 上排名不高，但因为工具调用格式稳定、响应快，反而更适合我们当时的业务。

所以，benchmark 适合“选模型”和“看趋势”，业务测试才适合“保交付”。两者是互补关系，不是替代关系。

4. 实战一：搭建一套可复用的 Agent 测试流程

下面我们动手写一套最小但完整的 Agent 测试流程。为了让示例可以直接运行，我会用一个 Mock LLM 模拟真实模型的工具调用行为，方便你理解测试框架本身。接入真实模型时，只需替换 LLM 实现即可。

4.1 项目结构

agent_test_demo/ ├── agent_core.py # 极简 Agent 与工具定义 ├── mock_llm.py # Mock LLM，用于离线测试 ├── test_agent.py # 测试用例与执行脚本 └── README.md

4.2 被测 Agent 核心代码

先定义工具和一个极简 Agent 循环。

# agent_core.py """ 极简 Agent 实现，便于演示测试流程。 实际项目中可替换为 LangChain / LlamaIndex / 自研框架。 """ from typing import Callable, Dict, List class Tool: def __init__(self, name: str, description: str, func: Callable): self.name = name self.description = description self.func = func def calculator(expression: str) -> str: """演示工具：计算数学表达式。生产环境请使用安全表达式解析库。""" try: result = eval(expression) return f"计算结果: {result}" except Exception as e: return f"表达式错误: {e}" def get_weather(city: str) -> str: """演示工具：查询城市天气（伪实现）。真实项目中替换为天气 API。""" return f"{city} 天气: 多云, 24℃" TOOLS: List[Tool] = [ Tool(name="calculator", description="计算数学表达式", func=calculator), Tool(name="get_weather", description="查询城市天气", func=get_weather), ] class Agent: """极简 Agent：循环调用 LLM，直到得到最终答案或达到最大步数。""" def __init__(self, llm, tools: List[Tool], max_steps: int = 5): self.llm = llm self.tool_map = {t.name: t for t in tools} self.max_steps = max_steps def run(self, query: str) -> Dict: messages = [{"role": "user", "content": query}] trace = [] for _ in range(self.max_steps): response = self.llm.complete(messages, self.tool_map) trace.append(response) if response.get("finish"): return {"answer": response.get("answer", ""), "trace": trace} tool_name = response.get("tool_name", "") tool_args = response.get("tool_args", {}) if tool_name in self.tool_map: result = self.tool_map[tool_name].func(**tool_args) messages.append({ "role": "tool", "name": tool_name, "content": result, }) else: messages.append({ "role": "assistant", "content": "工具不存在，请检查工具名称。", }) return {"answer": "达到最大步数未完成", "trace": trace}

这个 Agent 的核心逻辑很简单：每次循环让 LLM 返回一个动作，动作要么是“调用某个工具”，要么是“结束并给出答案”。trace记录每一步的决策，方便测试后定位问题。

需要说明的是，真实接入 OpenAI 兼容接口时，LLM 返回的内容通常是函数调用（function call）结构，需要你按对应 SDK 解析。上面代码把“解析结果”抽象成了一个接口，这正是为了测试方便。

4.3 Mock LLM 与测试脚本

为了让测试在离线环境也能跑，我写一个 MockLLM，它按预设剧本一步步返回动作。

# mock_llm.py class MockLLM: """测试用固定行为 LLM：按预设脚本返回动作，用于离线复现。""" def __init__(self, script): self.script = script self.cursor = 0 def complete(self, messages, tools): if self.cursor < len(self.script): step = self.script[self.cursor] self.cursor += 1 return step return {"finish": True, "answer": "无更多脚本步骤"}

接着编写测试用例和执行脚本。

# test_agent.py from agent_core import Agent, TOOLS from mock_llm import MockLLM def run_case(case): """执行单个测试用例，返回是否通过。""" llm = MockLLM(case["script"]) agent = Agent(llm=llm, tools=TOOLS, max_steps=5) result = agent.run(case["query"]) passed = result["answer"] == case["expected_answer"] print(f"[{'PASS' if passed else 'FAIL'}] {case['name']}") if not passed: print(f" query: {case['query']}") print(f" expected: {case['expected_answer']}") print(f" actual: {result['answer']}") for i, step in enumerate(result["trace"]): print(f" step {i}: {step}") return passed # 用例 1：正确调用计算器并返回结果 case_calculator_ok = { "name": "calculator_success", "query": "1 + 2 * 3 等于多少？", "script": [ {"tool_name": "calculator", "tool_args": {"expression": "1 + 2 * 3"}}, {"finish": True, "answer": "7"}, ], "expected_answer": "7", } # 用例 2：模型应对天气查询调用天气工具 case_weather_ok = { "name": "weather_success", "query": "北京今天天气怎么样？", "script": [ {"tool_name": "get_weather", "tool_args": {"city": "北京"}}, {"finish": True, "answer": "北京 天气: 多云, 24℃"}, ], "expected_answer": "北京 天气: 多云, 24℃", } # 用例 3：模型连续调用两次工具才得到答案 case_multi_step = { "name": "multi_step_success", "query": "先算 3 * 7，再算结果加 1", "script": [ {"tool_name": "calculator", "tool_args": {"expression": "3 * 7"}}, {"tool_name": "calculator", "tool_args": {"expression": "21 + 1"}}, {"finish": True, "answer": "22"}, ], "expected_answer": "22", } # 用例 4：模型调用不存在的工具，应被 Agent 拦截 case_unknown_tool = { "name": "unknown_tool_rejected", "query": "帮我执行一个未知操作", "script": [ {"tool_name": "not_exist_tool", "tool_args": {}}, {"finish": True, "answer": "工具不存在，请检查工具名称。"}, ], "expected_answer": "工具不存在，请检查工具名称。", } def main(): cases = [ case_calculator_ok, case_weather_ok, case_multi_step, case_unknown_tool, ] passed_count = sum(1 for c in cases if run_case(c)) print(f"\n总计: {passed_count}/{len(cases)} 通过") if __name__ == "__main__": main()

4.4 运行与结果解读

在项目目录下执行：

python test_agent.py

预期输出类似：

[PASS] calculator_success [PASS] weather_success [PASS] multi_step_success [PASS] unknown_tool_rejected 总计: 4/4 通过

这里每个“脚本”其实就是模型在当前场景下的一种行为路径。你可以把它理解为：我们希望模型在给定情况下走某条路。如果真实模型走了别的路，用例就会失败，trace会清楚地展示它每一步做了什么。

接入真实模型时，只需要把MockLLM替换为真实模型客户端：

# real_llm.py（伪代码，需按实际 SDK 调整） class RealLLM: def __init__(self, client, model): self.client = client self.model = model def complete(self, messages, tools): # 把 messages 和 tools 序列化为模型需要的格式 # 调用 self.client.chat.completions.create(...) # 解析返回的 function_call，转换成统一的 response 字典 pass

统一的response字典结构如下：

{ "finish": False, # 是否结束 "answer": "", # finish=True 时的最终回答 "tool_name": "calculator", # finish=False 时的工具名 "tool_args": {"expression": "1+2"} # 工具参数 }

只要保证这个协议不变，你的测试用例就和具体模型、具体框架解耦了。

5. 实战二：轻量 LLM 基准评估脚本

Agent 测试解决了“业务链路对不对”的问题。但遇到“该选哪个模型”“升级模型后效果是升是降”这类问题，就需要 benchmark 了。

5.1 挑选合适的基准

市面上公开基准很多，先按能力维度分类，再结合你的业务场景挑选：

需要注意，Agent 类 benchmark 运行成本高、环境复杂，不适合频繁跑。日常开发中更实用的是：从公开数据集中抽取一个小样本，组成自己的“回归集”，每次模型变更时快速验证。

5.2 编写评测脚本

下面是一个轻量评测脚本，结构清晰，你可以直接改造。

# benchmark_runner.py """ 轻量基准评估脚本（示例结构） 用同一批题目评估一个或多个模型，输出准确率。 实际使用时，请把 DEMO_SET 替换为公开 benchmark 数据集的子集。 """ import random import re DEMO_SET = [ {"question": "一个笼子里有鸡和兔子共 35 个头，94 只脚，兔子有多少只？", "answer": "12"}, {"question": "将字符串 'hello' 反转输出。", "answer": "olleh"}, {"question": "3 的 4 次方是多少？", "answer": "81"}, ] def normalize(text: str) -> str: """简单归一化：转小写、去首尾空格、去标点。""" return re.sub(r"[^\w\u4e00-\u9fff]", "", text.strip().lower()) def evaluate_model(model_id: str, generate_fn, dataset: list, sample_size=None, seed=42): """对同一批题目跑一个模型，返回准确率统计。""" random.seed(seed) if sample_size is None: sample = dataset else: sample = random.sample(dataset, min(sample_size, len(dataset))) hit = 0 total = 0 for item in sample: output = generate_fn(item["question"]) total += 1 if normalize(output) == normalize(item["answer"]): hit += 1 else: print(f"[MISS] Q: {item['question']}") print(f" expected: {item['answer']}") print(f" actual : {output}") accuracy = hit / total if total > 0 else 0.0 return {"model": model_id, "accuracy": accuracy, "hit": hit, "total": total}

然后写一个简单的generate_fn接入真实模型：

# main.py（伪代码，按实际 SDK 调整） def build_generate_fn(client, model, temperature=0.0): def generate_fn(question): # 调用模型 # resp = client.chat.completions.create( # model=model, # messages=[{"role": "user", "content": question}], # temperature=temperature, # ) # return resp.choices[0].message.content # 伪代码返回固定值，仅演示结构 return "12" return generate_fn if __name__ == "__main__": from benchmark_runner import evaluate_model, DEMO_SET # 伪代码：这里需要替换为你的真实 client client = None gen_a = build_generate_fn(client, "model-a") gen_b = build_generate_fn(client, "model-b") for gen in [gen_a, gen_b]: result = evaluate_model("demo-model", gen, DEMO_SET, sample_size=3) print(result)

5.3 对比结果怎么解读

跑完脚本后，你会得到类似下面的结果：

{"model": "model-a", "accuracy": 0.667, "hit": 2, "total": 3} {"model": "model-b", "accuracy": 1.0, "hit": 3, "total": 3}

解读时注意三点：

• 样本量小，分数波动大。不要因为一次 0.667 和 1.0 的差异就下结论，建议多次采样取均值，并记录每次的 seed。
• 温度参数必须固定。评测时统一使用 temperature=0，否则同一个模型跑两次分数都不一样，无法对比。
• 数据集不能换。模型 A 用了一组题，模型 B 用了另一组题，分数就没有可比性。

如果条件允许，建议把评测脚本接入 CI，每次更新模型版本、Prompt 或工具定义后自动跑一遍回归集，把分数变化记录到 Git 提交信息里。

6. 常见问题与排查思路

6.1 高频问题速查表

6.2 排查清单

当你遇到 Agent 相关的问题，可以按下面顺序排查：

1. 先复现：用固定 seed、固定 temperature、完整 trace 复现一次；
2. 看 trace：工具调用是否合理、哪一步开始偏离；
3. 看输入上下文：是不是历史工具结果污染了后续判断；
4. 缩小范围：把问题定位到“Prompt 问题”“工具设计问题”还是“模型能力问题”；
5. 修改后回归：改一处，跑一次回归集，对比通过率变化。

这套清单听起来朴素，但非常有效。大部分 Agent 问题都不是玄学，而是“上下文没管好”或者“工具设计不清晰”。

7. 最佳实践与工程建议

7.1 测试分层与回归策略

在生产项目中，我会把测试分成三级，对应不同的触发时机：

• 提交级：每次代码提交时跑单元层测试，几分钟内完成，拦截低级错误；
• 流水线级：合并代码或发布前跑流程层测试，覆盖主要 Agent 场景；
• 周期性级：每周或每轮模型升级后跑场景层测试和 benchmark 回归，输出趋势报告。

分级的好处是成本可控。如果你所有用例都放在提交级，一次改动可能触发几百次 LLM 调用，既慢又贵。

7.2 用例数据管理

测试用例是团队资产，建议像代码一样管理：

• 所有用例放入 Git，评审变更；
• 每个用例包含：场景描述、输入、预期结果、判定方式；
• 定期清理失效用例，避免用例集膨胀导致回归成本失控；
• 敏感业务数据脱敏后再入用例库。

另外，用例数量要克制。我的经验是：初始 30～50 个高质量业务用例，比 200 个重复用例更有效。先用少量用例跑通流程，再逐步补充边界场景。

7.3 安全与权限边界

Agent 测试涉及工具调用执行，安全边界一定要提前设计：

• 工具函数放在沙箱环境执行，禁止访问生产系统；
• 遵循最小权限原则：Agent 只能调用它完成当前任务所必需的工具；
• 涉及数据库、文件删除、支付等敏感操作时，必须加人工确认或权限校验；
• 对用户输入和工具返回内容保持警惕，防止提示注入导致工具被恶意调用。

这些不只是测试阶段的建议，Agent 上生产前必须完整检查一遍。

7.4 成本与性能控制

LLM 评测的成本很容易被忽视。一个用例集从 50 条涨到 500 条，调用量增长 10 倍；如果每条用例跑 3 次取均值，成本再乘 3。

控制成本的思路：

• 相同输入结果缓存，减少重复调用；
• 先用小模型过滤明显不合格的用例，再让大模型复核；
• 设置并发上限和超时时间，避免异常调用拖垮服务；
• 记录每次评测的 token 消耗，建立成本看板。

7.5 可观测性建设

最后一点，也是我认为最重要的一点：可观测性。没有完整轨迹的测试就是碰运气。

每个测试用例执行时，至少要记录：

• 完整的消息列表（含工具返回结果）；
• 模型 raw response（不要只存解析后的字段）；
• 每一步的耗时和 token 数；
• 最终判定结果和失败原因。

这些数据最好落成 JSON 日志或 trace 文件，方便后续重放和定位。网上一些团队在探索“meta context engineering via agentic skill evolution”这类方向——通过让 Agent 在不断评估中优化自身上下文构建策略。这类玩法虽然还在早期，但前提都是：你得有高质量、可回放的评测数据。没有可观测性，再高级的优化方法都无从谈起。

8. 总结与下一步学习方向

本文系统梳理了 Agentic 测试流程和 LLM 基准评估的完整知识体系。核心要点可以概括成几句话：

• Agentic 测试测的是“多轮自主行为”，不是单次文本生成；
• 测试要分层：单元层、流程层、场景层，各有各的目的；
• Benchmark 适合选模型和看趋势，业务测试才适合保交付；
• 评估体系要保证可复现：固定 seed、固定 temperature、统一数据集；
• 安全、成本、可观测性，是评测系统能持续运转的三个底座。

接下来你可以按这个路径继续深入：先把手头的 Agent 项目跑通本文的测试脚本，积累第一版业务用例集；然后搭建一个最简单的 benchmark 回归脚本，把每次模型变更的分数记录下来；最后考虑引入成熟的评测框架，把流程接入 CI。

如果你正准备给一个真实业务做 Agent 评测，建议从 20 个左右的高质量场景用例开始，先跑一周看看效果。如果本文对你有帮助，可以收藏备用；遇到具体报错或设计问题，欢迎在评论区带上你的 trace 片段一起讨论。