最近我把手头的 Agentic AI 工程笔记重新整理了一遍发现最值得优先写清楚的不是模型有多强而是 Agentic test processes智能体化测试流程和 LLM benchmarks大模型基准测试这套工程方法。从实际项目来看Agent 应用搭起来很快真正难的是证明它稳定、可回归、能上线。很多人把评估简单理解成“问几个问题看模型答得对不对”结果模型一换、提示词一动、温度一调之前的测试结论就全部失效。这篇文章从测试对象、环境准备、最小闭环、指标设计、批量回归和排查链路几个角度把常用做法拆开讲。适合做 LLM Agent、RAG、工具调用类应用的开发者和测试人员参考。1. Agentic 流程测试到底测什么先分清三个层次1.1 不要拿普通接口测试的思路来测 Agent普通接口测试的核心是“给定入参断言出参”模型任务测试也可以这么做但 Agent 不一样。Agent 是一个会自己规划步骤、调用工具、根据中间结果继续决策的程序。它在运行过程中会产生多次内部状态变化比如先调用检索工具再根据检索结果决定要不要用二次搜索最后组装回答。如果只关心最终输出很容易漏掉中间调错了工具、传错了参数、循环了好几轮才结束这类问题。尤其是 agentic RAG 这类流程检索结果是否被正确传递直接决定最终回答质量。单轮问答即便答对了也不能证明检索链路没有问题。我一般会把 Agent 测试拆成两个层面第一层是逐模块检查第二层才是端到端看最终效果。逐模块检查靠 trace 日志端到端看结果靠回归用例两者缺一不可。1.2 单步输出、工具调用、任务流程和端到端稳定性如果要把测试做得更细我建议分成四层来看。第一层是单步输出。模型在某个节点上的回答、选择的动作、生成的工具参数是否合理。这类问题可以用普通的模型评测方法比如比较关键字段是否包含、格式是否符合预期。第二层是工具调用。工具名是否正确、参数类型是否匹配、返回值有没有被正确处理。实际项目里模型写对了大段推理却在工具参数上把日期传错或者把字段名拼错这种情况非常多。第三层是任务流程。Agent 有没有在合理的步数内完成任务有没有出现死循环、提前终止、漏步骤、重复调用同一工具。框架层一般有循环控制但业务层仍需要验证。第四层是端到端稳定性。同一个任务跑多次结果是否一致是否受上下文累积影响。多轮对话场景还要看前几轮错误信息会不会带偏后续决策。1.3 为什么重点要看过程而不是只看结果这里我再强调一个观点Agent 测试的核心是过程可观测不是结果可接受。比如用户说“帮我查一下明天北京的天气如果下雨就提醒我带伞”。模型可能没有真正调用天气工具而是根据训练知识编了一个答案。如果只看最终文本它可能很像样但一看 trace发现工具调用次数是 0。这类问题在本地模型上尤其明显。因此我在设计测试时会同时记录每一步的输入和输出每次工具调用的名称、参数和返回结果模型在关键决策点的思考内容如果框架允许每一步的 token 消耗和时间戳最终是否走到终止节点拿到这些记录才能判断一次失败是模型答错还是流程设计问题还是工具返回数据有问题。2. 先搭一套能重复的测试环境再谈 Benchmark2.1 模型选择先确认走本地还是 API精度怎么选LLM benchmark 开始之前首先要确定被测模型跑在哪。业界常见做法有两种本地推理和 API 调用。本地推理的好处是隐私可控、离线可用、没有网络抖动缺点是环境依赖复杂不同卡、不同量化精度、不同推理引擎都会带来差异。API 调用相对省事但要额外关注模型版本、随机参数和服务限流。本地推理时经常遇到 FP16、FP32、BF16 这类精度问题。简单说FP32 是单精度浮点数值最稳但显存占用高FP16 是半精度速度快但部分模型在部分显卡上容易出现数值溢出BF16 也是一种半精度指数位和 FP32 相同尾数位更少在许多大模型推理场景下比 FP16 更不容易出 NaN。具体选哪种要以显卡和模型实测为准。我的建议是小规模测试如果显存够优先按模型官方推荐精度跑不确认依赖版本时不要拿 FP16 的结论直接推到生产。2.2 工具接入方式编排框架、MCP 和日志可观测性Agent 要调用外部工具接入方式会影响测试难易度。常见的有三种第一自己维护工具调用循环。代码可控但要自己处理循环、终止、容错测试时需要额外写很多状态检查。第二用成熟的 Agent 编排框架。这类框架一般内置了循环控制、工具注册、日志面板、断点调试等能力比较适合快速搭建。缺点是抽象层多出了问题要同时看框架日志和模型输出。第三通过类似 MCP 的协议连接外部工具。这种方式让工具接入标准化一个工具服务可以被多个 Agent 复用。测试时要注意连接成功后工具列表、输入 Schema、鉴权信息是否符合预期。不管用哪种方式日志必须可观测。我一般会要求测试输出目录里包含完整的一次会话记录而不是只有最终答案。没有日志的 Agent 测试基本等于白测。2.3 测试数据和运行参数的确定性控制做 benchmark 还要考虑一个很烦的问题模型输出有随机性。同一个 prompt 跑两次结果可能不一样。如果你想判断代码改动到底有没有效果就必须先把随机因素控制住。可以做的操作包括固定模型版本、推理引擎版本和依赖版本将温度降到 0 或接近 0关闭采样随机性如果框架支持使用固定的随机种子固定测试集文件版本不要边跑边改用例在记录结果时保存测试时间、模型路径、prompt 模板、参数配置这些信息应该写进一份可复用的测试配置里。我遇到过几次“这次跑得比上次好”的误判最后发现是某次测试用了不同模型分支。固定版本后结论才稳定下来。环境项测试阶段建议说明模型权重固定某个下载版本或 API 版本权重文件不一致会导致结论不可复现推理引擎固定推理引擎或官方依赖版本不同引擎对量化支持不同随机参数temperature、top_p、seed 统一记录LLM 输出有随机性需减少变量工具服务服务地址、Schema 版本固定工具返回结构变化会影响 Agent 决策测试集使用带版本号的 JSON/YAML 文件修改用例要同步修改版本号3. 从一条最小 Agent 任务开始跑通完整测试闭环3.1 最小任务怎么选很多团队第一次做 Agent 测试上来就选一个“多文档问答 工具调用 多轮对话”的复杂场景。结果失败了不知道查哪一环代码改了也没法判断效果。我更建议从最小任务开始。最小任务至少满足三个条件任务链路短通常一到两次工具调用就能完成输入输出边界清晰容易判断对错失败后能明显看到卡在哪一步比如“查询当前时间并按照指定格式输出”“查一个专有名词并返回解释”或者“根据一个配置调用一个模拟工具”。这类任务跑通后再逐步加入检索、多轮、长文本、任务编排。3.2 标准测试闭环四步定义、执行、采集、判断最小任务确定后按四步走。第一步定义任务和预期结果。不要只写“正确回复”要写清楚该调用哪个工具、传什么参数、返回什么结构。可以写成测试用例文件。下面是一个示例测试用例核心是说明结构不是完整代码{ case_id: agent_time_query_001, 任务描述: 查询当前时间并按YYYY-MM-DD HH:MM格式返回, 预期动作: [ { step: 1, tool: get_current_time, params: { format: YYYY-MM-DD HH:MM } } ], 预期结果: 返回当前时间的格式化字符串, 允许工具调用次数: 2, 不允许动作: [对用户进行反问, 输出模型自编时间] }第二步执行任务。单条任务先手动跑或者用最小脚本跑不要一次性开多个并发。重点确认模型能不能到达第一个工具调用节点。第三步采集过程信息。记录 trace、token 消耗、每次工具调用的输入输出、最终结果。这些数据后续都用于判断。第四步判断是否通过。通过不能只看答案还要看动作是否和“预期动作”一致。注意不要一上来就开最大并发先用一条样例确认输入、输出和日志都正常。否则并发跑出来一堆报错根本分不清是代码问题还是模型问题。3.3 怎么判断单条任务是否通过单条任务我一般看五个维度最终结果是否包含必要信息是否调用了预期工具工具参数格式是否正确是否在允许步数内完成是否输出过幻觉内容或编造的工具返回值任何一条不满足这条用例就不能算通过。只是最终答案对但工具调用链路不对的我一般标记为“部分通过”需要人工确认是否严重。4. Benchmark 指标设计不能只测答对答错4.1 先把“成功”定义分层到 benchmark 阶段就需要一个更正式的“成功”定义。不要一句话简单说“通过率 80%”这个 80% 太笼统。我习惯分三层结果成功最终答案满足了用户任务的基本要求。过程成功Agent 按照预期完成了工具调用和步骤切换没有明显的不规范行为。系统成功整个过程没有报错、没有超时、没有死循环资源占用在可接受范围内。三层各自成立但又相互独立。可能出现结果成功但过程失败的情况比如模型绕了很多弯路才做对也可能出现过程成功但结果失败比如工具调用都对但答案整合时出错。所以在汇报 benchmark 结果时我会把这三层分开列出。4.2 核心指标和判断方式针对三层成功对应的指标可以这样设计指标计算方式判断重点任务成功率结果成功用例数 / 总用例数总体可用性过程成功率过程成功用例数 / 总用例数Agent 流程是否合理系统成功率无报错、无超时用例数 / 总用例数工程稳定性工具调用成功率单次工具调用成功次数 / 总调用次数工具层可靠性无效调用率无效或重复调用次数 / 总调用次数模型是否乱用工具平均耗时总耗时 / 用例数同时看 p50、p95延迟感受平均 token 消耗总 token / 用例数拆 prompt 和 completion成本估算失败重试率需要重试才能完成的用例占比推理结果稳定性实际项目中我会重点盯无效调用率和 p95 延迟。很多 Agent 看起来能用但经常在工具调用上浪费时间p95 高得离谱。这时候就要考虑精简工具数量或者在提示词里增加调用约束。4.3 怎么防止 benchmark 变成过拟合benchmark 做得多了会有一个陷阱测试集慢慢变成提示词调优的“习题集”模型不是变强了而是记住了这些题怎么答。怎么避免我常用三个办法。第一随机化输入。同一个工具场景准备多种问法比如“查一下时间”“现在几点”“帮我看看当前时刻”。不要全用相同措辞。第二定期替换测试样例。测试集不能永远不变每个版本留一部分固定样例用于回归再补充一部分新样例用于观察泛化能力。第三记录人工审查结果。自动评分只能判断格式和简单规则业务正确性还需要人工看。尤其是工具参数、知识准确性、多轮一致性这些靠自动脚本容易误判。另外如果要做持续改进可以把失败样本沉淀成规则再更新到系统提示词或工具描述中。这个过程本身也要有测试闭环改一次上下文跑一遍回归看指标变化再决定是否保留。5. 批量回归和场景库怎么设计才不是拿几个 Prompt 当测试集5.1 场景库至少要有哪几类用例正规一点的测试场景库至少包含这些类型正常输入任务描述清楚工具调用链路清晰边界输入任务很简短、字段缺失、时间格式变化、数量很大很小缺信息输入用户没有提供某个必要参数看 Agent 是会主动询问还是瞎猜冲突指令用户要求互相矛盾看 Agent 是否会发现冲突无效工具入参工具需要的字段用户压根没给看模型是报错还是硬传参数长上下文输入历史消息很长看模型能不能提取关键信息会不会被中间内容带偏多轮会话输入前一轮错误会不会影响后一轮是否需要澄清每种类型不要只准备一条至少 5 到 10 条否则统计出来的通过率没有意义。5.2 批量运行管理的几个工程细节场景库有了之后就可以批量跑。这里有几个工程细节容易忽略。第一输入文件版本化。把测试集放在固定的目录用文件名带版本比如 testset_v1.json不要每次临时改文件。第二输出目录规范。每轮测试生成一个带时间戳的输出目录里面包含总报告、失败用例清单、每一条的 trace 日志、环境配置快照。这样可以跨版本对比。第三失败重试和断点续跑。批量跑 LLM 任务时偶尔会遇到服务超时、进程被杀、磁盘满。你要先确认已完成用例标记再考虑续跑避免从头再来。第四并发控制。本地推理显卡显存有限API 调用有并发限制。一开始并发设小一点比如 2 到 4跑一轮看延迟和报错率再逐步调大。不要直接拉满。第五同一用例考虑多次运行。LLM 有随机性如果任务要求严格可以同一用例跑 3 次取 3 次中至少 2 次通过作为通过标准。这样能过滤一部分随机噪声。5.3 自动评估和人工验证怎么配合自动评估适合处理格式类、流程类判断比如工具调用次数、参数类型、是否超时、是否包含关键词。人工验证适合处理语义类、业务类判断比如回答是否真正符合用户意图、检索结果是否相关、多轮对话是否保持逻辑。我建议的工作流是先用自动规则筛一遍把明显错误和明显通过的用例分开。对有疑问的中间区间人工集中过一遍。把人工发现的新问题补充进自动规则或测试集。如果全部依赖自动评分器很容易出现“分数很高但业务上没法用”的问题如果全部依赖人工效率太低跑不了大批量。6. 常见坑和排查链路Agent 卡住、乱调工具、上下文溢出6.1 现象和原因对照表先看几个高频问题现象可能原因优先排查点Agent 死循环循环终止条件不严或模型反复调用同一工具trace 中是否出现重复工具调用提前终止模型误判任务完成终止节点判断逻辑、提示词边界工具参数错误工具 Schema 描述不清或模型输出格式错最近一次工具调用的参数和返回错误上下文被撑爆单轮工具返回内容太大或历史记录无裁剪token 统计、输入超限日志结果为空最后一步模型没生成内容或结果被过滤输出后处理逻辑、生成阶段终止原因6.2 标准排查链路先 trace再输入输出、工具定义、模型配置遇到问题不要急着改提示词。我一般是按这个顺序来。第一步看 trace。找到失败的那个节点确认模型在那一轮到底做了什么、说了什么、调用了什么。如果没有 trace那第一步就是补日志。第二步看输入输出。检查这一步的输入是否完整工具返回是否为空或者格式不对。很多时候是工具服务挂了不是模型问题。第三步看工具定义。检查名称、描述、参数 Schema 是否简洁且没有歧义。工具越多越容易让模型选错可以把一些低频工具从默认 tools 里移掉按需注入。第四步看模型配置。确认温度和采样参数、模型版本、上下文窗口限制。如果是本地推理还要确认精度、量化方式、推理引擎版本。第五步最后才改提示词。提示词改动影响范围大改完必须重新跑完整回归。6.3 两个容易忽略的问题精度和依赖版本本地跑 LLM Agent 时有两个问题经常被忽略。第一个是量化精度。有的本地模型在 BF16 下工具调用正常换到 FP16 或者 INT8 之后模型输出格式开始不稳定偶尔会在 JSON 里多一个换行或者少一个引号。这不是模型业务能力变了是推理精度影响了模型输出稳定性。如果你的显卡显存有限非要用低精度建议在测试报告里单独标注精度不要混着统计。第二个是依赖版本。同样的代码框架版本不一样Agent 循环默认行为可能不同。比如某些框架在某个版本之前不会主动检查工具调用格式后一个版本加了结果代码没更新导致回归结果对不上。这类问题排查很费时间所以测试环境要和部署环境尽量保持一致并且把依赖锁文件一起放进测试配置。7. 落地建议先单条再小批量再完整回归7.1 第一步先把测试集和日志基础设施建起来不要一上来就写自动评分脚本。先建一个 50 条左右的测试集覆盖正常、边界、缺信息、多轮等主要场景。再保证每次运行都能导出完整 trace。这两件事做完后续所有调优才有依据。7.2 第二步单任务跑稳再开批量单条任务跑通后再开小批量比如 10 条验证流程确认批次输出目录、失败重试、结果汇总都正常最后才全量跑。这个顺序能帮你把“代码问题”和“模型问题”分开。如果你跳过单任务直接批量一个简单的工具参数 bug 会被放大成几十条失败样本反而更难定位。7.3 第三步把测试结论沉淀成团队资产测试过程中发现的问题比如工具描述不清晰、上下文太长、模型容易乱选工具可以整理成改进项。有些可以写进系统提示词有些可以改成校验规则有些需要补测试数据。这个过程本质上就是让 Agent 技能逐步进化每轮改进都用同一套 benchmark 验证效果。长期积累之后这些记录就是一个团队自己的 Agent 测试知识库类似维护 LLM wiki新成员进来可以直接查历史结论不用重新踩一遍坑。7.4 如果团队刚开始建议先接受人工评估最后说一句如果团队资源有限不要急着追求全自动评估。前几十条用例用人工看效率高出错少。等测试集稳定、日志齐全之后再逐步把自动规则加上。踩过几次之后你会发现很多 Agent 问题不是模型能力不够而是工具定义不清楚、上下文管理混乱、日志缺失。先把这三件事做好LLM benchmark 的结果才有意义。