Agentic LLM系统测试与评测：从行为链验证到LLM Benchmarks落地实践

在 Agentic LLM 系统进入日常开发后，团队真正缺的往往不是一条更高级的提示词，而是一套能回答“这次改动到底是变好还是变坏”的测试流程。围绕 Agentic test processes 和 LLM benchmarks 建立评测体系，正在成为 LLM 应用工程化的关键环节。传统单元测试验证的是确定函数，而 Agentic 系统会在多次工具调用、多轮上下文和不同模型版本之间产生不可预期的行为，于是测试必须从“断言输出”扩展为“验证行为链、记录轨迹、评估资源消耗”。

这篇笔记从实践角度整理 Agentic 系统测试与评测的落地思路，会包含环境搭建、测试用例组织、基准测试指标、失败排查和最佳实践。内容面向正在做 LLM 应用、Agentic RAG、工具调用类项目的开发者和测试工程师，也适合刚接触 LLM 评测、想建立可复现回归流程的团队。下面不会堆叠某个框架的官方文档，而是从“如何把评测跑起来、如何解释结果、如何让结果可复现”这条主线展开。

1. 为什么传统测试流程在 Agentic 系统里失效

1.1 传统测试的核心假设：输入确定、输出确定

传统软件测试在大多数场景下依赖确定性假设。给一个函数传入参数，它返回固定结果；一个接口在相同请求体下产生相同响应。单元测试、集成测试、E2E 测试都建立在“给定输入，应有预期输出”的模型上。测试框架可以维护断言，CI 可以自动执行，只要用例稳定，结果就稳定。

这套思路在处理普通业务系统时依然有效，但放到 Agentic LLM 系统中会出现明显的边界问题。当系统需要根据用户意图自主规划步骤、决定调用哪个工具、从多页上下文中选取信息时，同一个提问可能产生不同的执行路径。测试如果仍然只比较最终输出文本，就很容易把一次偶发性的工具调用失败误判成功能缺陷，也会漏掉“最终答案正确但过程引用了错误来源”的隐蔽问题。

1.2 Agentic 系统的不确定性来自哪里

需要先明确 Agentic 系统的不确定性是分层出现的，只有分清层次，测试用例才能设计得有意义。

第一层是模型采样层。即使提示词完全相同，temperature、top_p 和模型版本差异都会导致生成文本不同。第二层是任务规划层。Agent 可能先检索、再总结，也可能先拆问题、再并行查询，规划不同，结果就不同。第三层是工具调用层。工具参数是否正确、返回内容是否被截断、超时是否被处理，都会影响后续步骤。第四层是外部依赖层。知识库是否更新、数据库连通性、上游 API 限流，都可能让同一个用例在不同时间得到不同结果。

这些不确定性并不是 Agentic 系统的缺陷，而是它作为“有自主行为能力的程序”的固有属性。测试设计不能试图消除不确定性，而是要把不确定性变成可以观察、记录、评估的数据。

1.3 测试对象从“输出”变成“行为链”

传统测试断言的是结果，Agentic 系统测试要同时关注过程。以 Agentic RAG 为例，一个知识库问答 Agent 的完整行为链可能是：

1. 接收用户问题。
2. 判断问题是否需要多路召回。
3. 改写查询词，分别检索多个数据源。
4. 把检索结果拼入上下文。
5. 让模型生成答案并给出引用来源。

如果只检查最后答案是否包含“华东区销售额增长 12%”，无法发现系统是不是因为某一次工具返回了错误数据才得到这个答案。只有把每一步工具名称、入参、出参、上下文长度、模型输出都记录下来，才能定位是检索不准、上下文截断、提示词指令不清，还是模型本身生成错误。

这里引出一个很实用的判断标准：Agentic 测试用例不能只写“预期输出文本”，而是要写“预期行为链”。

1.4 Agentic 测试与传统测试关注点对比

表格里的差别说明了一个核心结论：Agentic 系统的测试流程必须引入新的观测和评估机制。下一节先从环境准备开始，因为评测环境不稳定，后面所有流程都会失真。

2. 搭建可复现的评测环境：版本、上下文和依赖都要锁住

2.1 评测环境为什么要和业务环境分离

很多团队在测试 Agentic 系统时，直接连开发环境的模型服务、向量库和 API 网关。这样做能快速看到效果，但也很容易让评测结果不可信。

开发环境的知识库数据随时可能被更新，模型服务可能由用户自行切换版本，工具的 mock 开关可能被某个调试任务打开。评测一旦依赖这些不稳定因素，今天跑出的指标和明天跑出的指标之间就没有可比性。正确做法是维护一个独立的评测环境，里面至少包含固定的测试知识库、固定的模型端点、固定的工具 Mock 服务和固定的网络配置。

评测环境不一定要和生产完全隔离。它可以使用生产模型，但必须通过版本号锁定 API 请求；可以使用生产知识库，但需要导出固定快照；可以使用真实第三方工具，但更推荐用 Mock 服务来测试异常分支。

2.2 锁住模型、提示词、工具和知识库版本

为了让 Agentic 评测可复现，需要维护一组版本信息。下面是一个常见的“版本锁定”清单：

• 模型：供应商、模型名称、模型版本、temperature、top_p、max_tokens。
• 提示词：模板文件版本、few-shot 样本版本、系统提示词哈希。
• 工具：工具数量、工具描述、入参 schema、Mock 响应文件版本。
• 知识库：数据快照版本、切分策略、索引配置、向量库版本。
• 代码：Agent 框架版本、业务逻辑代码 commit ID。

这些信息不一定要靠人手工记录，可以通过环境变量和启动脚本固化。以 Docker Compose 为例，可以让评测环境里的模型服务、向量库和评测脚本各自使用独立服务。