企业官网建设流程全解析

1. 为什么说AI系统测起来和传统软件根本不是一回事

团队最近在测一个基于大语言模型的客服Agent项目，功能不复杂：用户进来咨询订单、退换货、物流进度，Agent自己调用订单系统、库存系统的工具接口去查数据、给结论。听起来就是个带工具调用的对话机器人，对吧？但真到了测试阶段，你会发现以前那套“写用例、点页面、对断言”的打法，一大半都失效了。

传统软件测试的核心假设是：同样的输入，必然得到同样的输出。你点十次“登录”按钮，只要代码没改，结果就一样。但大模型Agent不是这样：同一个用户问题，温度参数稍微一抖，返回措辞不同；同样的数据库状态，多轮对话的顺序变一下，Agent可能就选了另一条工具调用路径。甚至模型版本不升级、代码一行没动，仅仅因为上游API的延迟抖动，Agent给我返回了一个完全错误的结论。

这意味着测试对象已经从“逻辑确定的程序”变成了“概率不确定的系统”。你没法用“预期结果=实际结果”这种二元判断去度量它。我们当时试过直接套用传统接口测试框架，把每个对话场景写成固定用例，断言某句话必须出现——结果一到回归阶段，凌晨发版前用例挂了一片，不是功能坏，是模型换了种说法，语义还对，但字符串比对不过。

所以做AI系统测试，第一件事不是选工具、写用例，而是先承认一件事：你的测试策略必须重新设计。传统测试测的是“实现是否正确”，AI测试首要关注的是“行为是否可靠、结果是否可接受”。前者的核心方法是确定性断言，后者的核心方法是分层验证加概率评估。

这就是我要分享的这套六层测试框架的由来。它是我们在一系列Agent类项目里迭代出来的，专门用来回答三个问题：模型本身行不行、Agent行为稳不稳、整个系统上线后能不能扛住。下面从框架的总体逻辑开始讲，然后用一个实际的客服Agent项目贯穿每一步，给你一套可以直接拿去用的测试方案。

2. 打地基：理解Agent系统的“三层不确定性”

讲框架之前，得先把Agent系统和其他软件的关键差异点说透。不搞清楚这个，后面每层测试的设计逻辑你都会觉得“有点过度设计”。

Agent系统的不确定性来自三个层面：

第一层，模型输出的概率性。大模型的解码过程本质是采样，同样的输入，输出不是唯一的。哪怕把温度调到0，由于浮点计算和批处理差异，极端情况下输出也会有微小差别。这个不确定性会让所有依赖精确匹配的断言失效。

第二层，行为路径的组合爆炸。一个Agent至少包含：模型本身、系统提示词、工具集合、记忆模块、外部API。模型决定下一步调什么工具、传什么参数、怎么解读返回结果，这本质上是一个状态机，但状态转移条件不是代码写的，而是模型“临场发挥”的。N个工具、M轮对话，路径数量是指数级的。你没法用穷举的方式验证所有路径。

第三层，环境依赖的动态性。工具调用结果可能是实时数据，上游API会挂、会慢、会返回格式异常。数据库里的订单状态随时在变。这意味着测试时的输入条件本身就不是稳定的，传统测试里“造一份固定测试数据”的方法，在Agent测试里经常行不通。

这三层不确定性叠加，导致一个问题：你根本测不出“这个系统是否正确”，只能测“这个系统在多大比例的情况下表现可接受”。所以六层框架的核心思路，是把“测不确定的系统”这件事，拆成多个确定性逐渐增强的层次，每层用不同的方法、不同的标准去收敛风险。

我个人的体会是：很多人第一次接触AI测试，上来就跑到“评测大模型”那一层——写一堆提示词、看输出质量分数。但实际项目中，真正让系统崩溃的往往不是模型能力不行，而是工具返回异常时Agent不会处理，或者多轮对话中记忆被污染导致决策跑偏。所以框架的顺序不是从模型往上层测，而是反过来的：先从底层的确定性组件开始，把能确定的先确定掉，越往上才是越“玄学”的部分。

3. 六层测试框架的全貌：从零件到整车的测试逻辑

把这套框架比作造车，你可能更好理解。

你造一辆车，不可能只做一次“整车测试”就完事。你得先测螺丝和轴承（零件层），再测发动机启动是否正常（组件层），然后测仪表盘和油门刹车是否协调（功能层），接着模拟不同路况开几圈（场景层），再让不同驾驶风格的人都开一遍看看满意度（体验层），最后车卖出去了，还得监控每辆车的实时故障（运维层）。

AI系统的六层测试框架，逻辑一模一样。

这里有个容易混淆的点：前三层可以理解成“单元测试+集成测试”，但它们的写法跟传统测试完全不同。后三层可以理解成“系统测试+验收测试+运维监控”，但里面的核心不再是功能断言，而是质量评估。

为什么分六层而不是三层？因为我们踩过坑：如果把工具测试和Agent行为测试混在一起，出问题的时候根本分不清是工具返回错了，还是模型决策错了。比如Agent调库存接口拿到一个空数组，然后告诉用户“缺货”，你很难判断是接口真的返回空、还是Agent传错了参数。分层测，每一层只负责验证一个固定的不确定性来源，问题一出现就能快速定位。

下面每一层我都结合那个客服Agent项目讲具体的测试方法。先提一句，这个项目我们用了一个标准的工具集：pytest作为基础测试框架，加上一些LLM专用的评测库（比如promptfoo这类），以及自研的对话追踪工具。你不需要完全照搬工具选择，核心是理解每一层在测什么、怎么设计断言。

4. 第一层到第三层：先把一切确定的组件测到无懈可击

4.1 第一层：数据与提示词测试——输入不干净，后面全白测

Agent系统的“源代码”不只是模型权重，还包括系统提示词、工具描述、示例数据。这些是你可以完全控制的确定性输入，但它们经常出问题。

我们在项目初期遇到过一件很离谱的事：工具描述里写了“时间格式为YYYY-MM-DD”，但订单系统实际返回的时间戳是毫秒级的数字。Agent拿到之后一顿操作，告诉用户“您的包裹已于2026年4月1日送达”——完全错误。测试如果有做第一层校验，这种问题在写代码阶段就能拦住。

第一层测试具体做三件事：

一是数据结构校验。把系统涉及的所有工具入参、出参、工具描述、环境变量写成JSON Schema，每次构建时用脚本校验。这个不需要引入什么复杂工具，把Schema定义好，用pytest参数化跑一遍校验逻辑就行。提醒一下：一定要把“模型能看到的内容”和“真实系统返回的内容”分开校验。模型看到的工具描述是人写的，真实返回是系统生成的，两边都有可能出错。

二是提示词静态检查。系统提示词里有没有变量没格式化就上屏？有没有示例数据本身格式就是错的？有没有Prompt注入风险——比如用户输入里带“忽略之前的指令”，而系统没有加任何防护层。这些用静态扫描加人工review就能做，不需要跑模型。我们在实际项目里专门加了一个测试用例，用户用各种方式尝试注入系统提示词，验证Agent有没有飞出去。这个测试案例评估下来发现，很多看起来“智能”的Agent，防注入能力弱得一塌糊涂。

三是黄金数据集的版本管理。把每个版本的测试数据、预期行为、模型版本、提示词版本全部打标签存起来。后面每一层测试都要引用这个标签，不然模型升了个版本，你的用例还在拿旧数据跑，得出的结论毫无意义。

4.2 第二层：工具与函数测试——每个零件必须单独验收

第二层的测试对象是Agent会调用的所有工具函数，包括内部检索模块、外部API封装、数据库查询逻辑。传统单元测试的经验在这里完全可以复用，但要额外关注LLM特有的边界情况。

对客服Agent项目来说，我们测试了几个典型工具：“查订单接口”“提交退货申请接口”“计算运费接口”。每个接口的用例设计都覆盖四类情况：

正常输入：合法订单号、合法用户ID。 异常输入：空字符串、超长字符串、特殊字符（比如引号、反斜杠）、不存在的数据。 超时与错误：Mock掉上游API，分别测试超时、返回500、返回非JSON格式、返回字段缺失。 兼容性：同一接口在不同环境下返回格式是否一致。

这里重点强调一种容易漏测的异常——工具返回了“语义正确但内容不完整”的数据。比如查订单接口返回了200，但orders字段是null，不是空数组。传统测试只会断言“返回200就算通过”，但LLM看到null之后会怎么解读？它可能说“您没有订单”，也可能说“系统出错了”。这两种回答天差地别。我们在工具层测试里增加了一条约定：任何返回值要么符合Schema，要么必须携带一个机器可读的错误标记，不允许出现“怪异的中间状态”。这条约定后来帮我们挡掉了很多莫名其妙的生产事故。

工具层测试还有一个独家经验：一定要做并发测试和限流测试。Agent在并发场景下对工具调用的频率和传统用户操作完全不同——一个Agent可能在一分钟内调用同一个接口20次。如果工具层没有做好限流与缓存，接口响应会越来越慢，然后Agent会频繁失败重试，形成恶性循环。

4.3 第三层：单轮行为测试——从“对不对”变成“像不像预期”

到了这一层，才开始真正测试“Agent作为一个决策系统”的行为。单轮行为测试的定义是：给定一个用户输入和初始状态，验证Agent做出的第一个决策是否正确。

这个“决策”包括三类：

• 调用了哪个工具，参数传得对不对。
• 有没有调用工具就回答，答案内容是否正确。
• 该拒绝回答的时候有没有拒绝（比如用户问无关话题、要求越权操作）。

单轮测试的核心难点从“预期结果”变成了“预期行为”。我们不再断言Agent输出某句话，而是断言Agent的行为轨迹是否在可接受集合内。

我们的做法是设计一个“行为断言三元组”：输入场景，定义期望的工具调用序列和关键输出语义；主路径，定义正常的工具选择与参数；可选路径，定义若干可接受的行为分支。

举一个实际用例：用户问“帮我查一下订单12345的物流状态”。 期望行为：Agent调用query_logistics接口，参数order_id等于12345，然后回答中应包含物流状态描述。允许的行为分支：如果物流接口返回“配送中”，回答要提到当前位置；如果返回异常，Agent应该明确告知用户暂时查不到并建议稍后重试，而不是瞎编一个状态。

单轮测试的执行方式是构造几百个这样的场景，批量发给Agent，然后对输出做自动语义断言。语义断言用LLM来评判——让一个评分模型判断输出是否包含关键信息、是否偏离了用户意图。注意这里有个坑：评分模型本身也可能误判。我们的经验是，关键场景全部人工复核，一般场景用评分模型，分数低于阈值再拉出人工看。

写到这里，我要强调一个单轮测试的设计原则：不要只设计“正确场景”，一定要大量覆盖“恶劣场景”。比如用户输入的订单号不存在、用户问的订单不属于当前用户、工具返回超时但Agent还有一次重试机会、多个工具返回互相矛盾的数据等等。Agent和生产系统的差距，往往不是在主路径上拉开的，而是在这些没人预设的分支路径上暴露的。

5. 第四层到第六层：应对不确定性的进阶玩法

5.1 第四层：多轮会话测试——状态机不崩，才是真本事

单轮测试通过后，进入多轮测试。为什么单轮通过不代表多轮能过？因为Agent有记忆。记忆模块会记住前面轮次的信息——用户名字、订单号、之前聊到的话题。多轮测试的重点，就是验证这个记忆和状态管理在长时间对话中不会把决策带偏。

我们最初用“先聊几轮正常问题，再看最后一轮回答是否正确”这种粗暴方式测，很快发现覆盖不了问题。后来改成更系统的状态机校验法。

多轮测试的状态机抽象是这样的：每一轮，Agent接收用户输入和当前会话状态，输出行为决策和新状态。

需要跟踪的状态维度包括：

• 重要实体是否被记忆（比如用户报过订单号，下一轮直接说“那单现在什么状态”，Agent要能关联上）。
• 上下文窗口内的信息是否被正确引用，还是出现了幻觉性补充。
• 用户改变意图时，Agent是能切换话题，还是死磕旧话题。
• 当记忆被填满、需要截断时，重要信息会不会丢失。

我们的做法是构造几类多轮场景：连续追问型（每轮补充一个条件，Agent的信息聚合要越来越准）、话题切换型（中途换一个完全不相关的问题，Agent要能重新聚焦）、信息修正型（用户先报错订单号，后来又更正，Agent不能继续沿用旧值）。

每一类场景都要执行至少20轮以上的长对话，因为记忆污染往往在5轮之后才出现。跑完一轮长对话，除了验证最终回答质量，还要做中间状态检查：把每一轮的记忆状态快照导出来，对照“该记的事是否记了、不该记的噪音是否没记、被修正的信息是否已经替换”。这个检查做下来，一个隐藏很深的bug被我们逮到了：用户先查了A订单，然后切换话题聊了半天退货政策，最后回来问“那A订单呢”，Agent已经完全忘了A订单是什么，直接按照知识库瞎答退货政策。原因是记忆模块的“话题隔离”做得很差，切换话题时把旧记忆覆盖消灭了。这类问题，单轮测试绝对发现不了。

多轮测试的执行成本比较高，每轮都要真实调用模型和工具，跑一组几十个场景可能就要几十分钟。经验是一定要提前做好任务的并行化和幂等设计，否则测试环境会被跑爆。另外，多轮测试用例的编写门槛也不低，建议由了解业务又懂Agent实现的资深人员来写，光靠测试工程师闭门造车，很难覆盖实际使用中的复杂状态迁移。

5.2 第五层：质量评测——光“跑通”不够，还得“答得好”

第四层测的是“链路通不通”，第五层测的是“结果好不好”。一个Agent完全可以每一轮都调用对了工具、说出来的话也找不出明显错误，但用户实际体验下来就是觉得“不对劲”——回答太啰嗦、语气冷冰冰、该追问的没追问、给了结论但没解释依据。

这一层需要定义多维评测体系。我们团队用了一个五维评分卡：

第五层的核心方法是评测集的建设与维护。我们在项目里维护了一个约500条样本的评测集，每条样本包含：用户旅程描述、初始环境状态、预期行为要点、关键禁止点，以及一个综合分值的参考答案。

重点说一个关于评测集的教训：评测样本一定不能从线上真实对话里直接抽，哪怕脱敏之后也不行。真实对话里充斥着各种不规范的、试错的、上下文缺失的语句，拿来做评测集会导致分数和真实体验严重脱节。我们的做法是“仿真生成+人工改写”——先模拟真实用户场景写出种子对话，再由业务专家改写润色，确保样本覆盖业务核心链路，同时保持语言多样性和难度梯度。

第五层另一个重要用法是对比评测。每次模型版本升级或提示词改动，都在同一份评测集上跑新旧版本，用五维评分卡打分对比。这比跑一堆pytest用例更接近“这个改动到底好不好”的答案。注意，对比评测要控制变量——如果同时改了模型版本和工具描述，得分变化就无法归因。我们曾经一次升级同时改了提示词和底层模型，结果分数大涨，后来分析发现其实是提示词的作用，模型升级反而拖了后腿，差点把这个改动推到线上。

5.3 第六层：线上监控与漂移检测——上线不是终点，监控才是护城河

最容易被测试团队忽视的一层，也是最关键的一层。Agent系统上线之后，线上输入分布的漂移、模型API的更新、上游服务的波动，都会让一个“测试全绿”的系统突然变烂。

第六层的核心是建立在线监控体系，至少包含三类数据：

一是质量监控。给线上每一条用户请求打一个质量分。我们用的方法是旁路一个评分模型，把用户输入和Agent输出丢给它，实时打分，低于阈值自动告警。注意，评分模型也必须做离线校准，否则它自己飘了都不知道。

二是行为监控。统计Agent的决策分布，比如工具调用成功率、单均调用次数、拒答率、平均响应时延。任何一个指标突变，都值得拉报警。举一个真实例子：某天我们发现工具调用成功率从98%掉到85%，告警拉起来一查，是上游库存接口新加了一个鉴权字段，Agent拿旧参数调了大半天。如果没有线上监控，这个问题可能被人反馈好几次才能被发现。

三是漂移检测。输入分布漂移和输出分布漂移都要盯。方法是记录每天的输入文本和输出文本，用向量化手段算相似度分布，跟基线对比，漂移超阈值就告警，然后触发一次全量回归。

很多时候模型漂移不是突然发生的，而是渐进劣化的。比如用户的提问方式在三个月内逐渐偏向某一类新话题，Agent的知识库和工具能力不知道这个新话题，回答质量慢慢下滑。这类问题只有长期监控漂移才能发现，靠测试阶段的人工样例基本无能为力。

线上监控的痛点，是它很容易被当成“运维的活”而不是“测试的活”。我的观点是：Agent系统的测试负责人必须拥有线上指标的解读权。不然你测了六层，上了线，出了事故，你连第一手数据都拿不到，那前五层的意义就大打折扣。

6. 完整案例实测：客服Agent从零到可上线的全流程验证

前面六层原理讲了半天，现在用一个完整的案例全流程串一遍。假设我们要上线一个客服Agent，功能覆盖订单查询、退货申请、运费说明、物流跟踪。下面是我们当时执行的测试计划，每一步都可以直接抄。

整体计划概览：

6.1 工具层实测记录

我们对“提交退货申请”工具写了12个用例，重点包括：

• 用户名合法、订单属于该用户、订单状态为已签收 → 应该成功提交。
• 用户名合法、订单不属于该用户 → 应该被拒绝，返回明确错误码。
• 订单状态为“退款中”→ 应该被拒绝并给出状态说明。
• 传参时故意把order_id写成字符串数组 → 工具层应该做类型校验直接报错，而不是把错误抛给LLM去自由发挥。

其中一个设计细节值得展开：为什么要把“工具参数类型校验失败”设计成工具层直接报错？因为它不是LLM能修复的问题，LLM只会想办法“表达”错误，可能编出一个无辜的失败原因。这会导致用户收到“系统繁忙”的废话。工具层能拦截的错误，绝不让LLM背锅。

6.2 单轮行为层实测记录

我们测了一条非常典型的黄金路径：“帮我查订单999的物流”。Agent的正确行为是：调用query_logistics(order_id=999)，拿到返回结果后，回应用户包含物流状态和预计送达时间。但我们在评测集里故意加入了变体：

• “帮我查一下999物流”——没有动词。
• “999到哪了”——极简表达。
• “我的包裹什么时候能到”——没有订单号，需要追问。

变体用例的判定标准是：要么正确追问获取订单号，要么在上下文中已存在订单号时正确使用，绝不允许瞎猜一个订单号去查然后给出错误结果。测试过程中我们发现，早期版本在“没有订单号”时会默认调用一个空参工具，返回结果为空后竟然回答“您的订单正在等待揽收”。这是完全错误的，系统提示词里根本没有预设这种兜底行为。这类问题靠的就是覆盖变体和语义判定的单轮测试集。

6.3 多轮会话实测记录

有一组测试场景至今记忆深刻。用户： 第1轮：“我想退掉刚收到的鞋子。” 第2轮：“顺便问一下，你们退货运费谁出？” 第3轮：“对了我订单号是888。” 第4轮：“那你帮我把这单退了吧。”

正确行为是，到第4轮时，Agent应该把“888”这个订单号从第3轮的记忆中取出，结合第1轮的退货意图，发起退货申请流程。我们测试时发现，Agent确实记住了订单号888，但把“退货运费谁出”这个问题和第1轮的退货意图混在一起，导致它在提交退货申请时额外问了一句“请问是谁原因造成的退货呢？”，打断了用户已经明确表达的退货需求。这个不算硬性错误，但无形中增加了用户的操作成本。这类体验问题，就是第五层的完整性和效率性维度拉低的分数，最后我们又微调了提示词对状态迁移的颗粒度要求，才把分数拉回来。

6.4 评测集与线上监控实测记录

项目上线前，我们还做了一次“模拟生产流量”的压测：用线上会话日志的前5000条脱敏改造样本回放，观察Agent在高并发下的表现。结果发现第四层完全没覆盖到的现象——大量会话同时并发时，Agent对同用户不同窗口的状态同步出现了错乱，导致一个窗口查了订单，另一个窗口重复问订单号。这又是个多轮状态管理问题，但是只有压测才能暴露。

线上监控部分，我们当时的配置是：旁路评分模型每10分钟聚合一次质量分，低于85分触发告警。工具调用成功率低于90%触发告警。平均单轮时延超过15秒触发告警。上线首周内，还真触发了一次工具调用成功率告警，原因是某个工具把成功响应时间从100ms降到了3秒，Agent默认认为失败反复重试，把成功率打到75%。如果没有监控，这个问题要到用户连环投诉才会暴露。

7. 测试过程踩过的坑与排查技巧总结

这套框架不是一次就搭成型的，中间踩了不少坑，挑几个最典型的分享出来，给正要搭AI测试体系的团队避避雷。

7.1 常见问题速查表

7.2 排查技巧：用“最小复现”替代“随机重试”

Agent测试最大的痛点是问题不好复现。同样的话问两次，一次对一次错。我们的排查原则是：一旦发现可疑行为，立刻锁定当时的完整上下文——系统提示词版本、模型版本、工具返回快照、完整对话历史。然后手动组一个最小复现，把对话历史作为固定上下文输入，而不是重跑整个会话流。因为模型本身有随机性，重跑引擎里的“完整对话流”很可能复现不出来，但如果你把全部历史上下文原样重放给它，大概率能复现决策倾向。这个“把历史喂回去”的技巧，帮我们定位了至少三分之二的疑难杂症。

另外，排查Agent问题时，不要一上来就怀疑模型能力。先查工具返回，再查提示词，再查记忆状态，最后才是模型本身。我们团队甚至立了条规矩：没有导出的工具返回快照和上下文token记录，不允许提“模型有问题”这个结论。这条规矩让我们的问题定位效率提升了非常多。

7.3 独家教训：评测集要当代码来维护

评测集是这个体系里最难维护的部分。它有版本、有评审、有变更记录。任何提示词改动，都必须说明“为什么评测集不需要改或者需要怎么改”。评测集一旦被某个团队私下改掉用来“刷分”，这套体系就报废了。我们的做法是每次版本发布，评测集固定打包一个hash存进制品库，任何改动都走变更评审。后来因为好看的数字诱人，有人动了改评测集的念头，但这个hash机制成功拦住了。

8. 写在最后：从测试框架到质量文化

从我们做第一个真实Agent项目到现在，最大的体会是：AI系统测试最难的不是某个技术环节，而是整个团队对“质量”二字的理解还停留在旧世界。旧世界说，功能左就是在右不在，抓到一个bug是一个bug。新世界说，你要花大量精力设计评测集、维护监控指标、分析概率分布下的行为，这比抓bug更累，更容易被质疑“你一天到晚在干嘛”。

我的建议很直接：如果你负责的团队要重仓Agent方向，一定要从项目第一天就按这套六层框架搭质量体系，不要把“测试”定义成最后上线前的验收环节。第一层数据测试在写工具函数的时候就可以做，第二层工具单测不依赖模型也能做，第五层评测集可以随着需求细化逐步积累。真正到上线前才开始做，你只会获得一个脆弱的、靠人工盲测得出的“看起来能行”。

最后分享一个小经验：六层框架的执行优先级也不是平均用力。对多数业务Agent来说，第二层（工具测试）和第四层（多轮会话测试）是性价比最高的两处投入，一个是确定性风险的源头，一个是体验崩坏的放大器。如果你只有三天时间给一个Agent项目做个快速测试评估，我强烈建议你把精力集中在工具异常处理和长对话状态管理这两件事上，绝对比写一百个单轮用例来得好。