智能体评估方法

在智能体开发的早期，最常见的做法是“开发-预览-发布”模式：开发者编写好提示词（Prompt），挂载了知识库和各类工具，在预览聊天框中手动输入5~10个典型问题。如果AI回答得不错，便认为开发完成，直接发布上下。

然而面对真实的业务场景，需要长期稳定运行的智能体而言，这种“抽样聊天”的人工测试存在致命的局限性，往往很快就会遇到这些崩溃时刻：

昨天还好好的，今天怎么突然变笨了？
“只是为了优化一句语气词微调了Prompt，结果智能体怎么突然忘记怎么调用知识库了，难道每次改几个字，都要手动重新测试几百个问题吗？”智能体的开发是一个高度敏捷、持续迭代的过程。假设您为了修复“场景A”中的问题，微调了系统提示词。如何确保这一修改没有破坏原本运行完美的“场景B”？如果依靠人工，每次修改一句话，都要把历史的几百个测试用例重新手打一遍，这在人力和时间上是完全不现实的，最终必然导致越改越乱。
它竟然当着客户的面瞎编政策！
“遇到知识库没写的问题，不但不拒绝回答，反而自己编造了一个新的答案，到底那条数据触发了它的幻觉？”人工测试通常只覆盖了“理想状态”。当真实用户输入知识库中不存在的偏门问题，或者使用模糊、甚至对抗性的语言提问时，智能体会如何反应？它是否会为了迎合用户而“一本正经地胡说八道”？人工抽测的极低覆盖率，根本无法探测到智能体的能力边界和安全底线。
工具看似调用成功了，但是参数对吗？
“让它去查机票，结果转了半天返回无票。是选错了查询工具？还是把明天的日期提取成了今天？完全是个黑盒……”智能体往往包含复杂的执行过程。它可能需要先检索知识库，再调用外部工具查询数据，最后综合输出。单纯看最终输出的文本，您无法知道：它是真的理解了业务逻辑，还是歪打正着；它在调用插件、MCP工具时，是否提取了错误的参数，导致中间步骤失败？

靠人工聊天测试，永远无法科学量化AI的真实能力。我们需要从“手工坊”走向“工业化流水线”，为了打破这种“黑盒”状态，AgentArts全新上线了智能体评估功能。

传统手工测试 VS 自动化评估

为了直观理解AgentArts评估功能带来的效能飞跃，可以通过以下矩阵对比两者的差异：

表1 传统手工测试 VS 自动化评估
维度	传统人工抽样测试	AgentArts自动化评估
测试规模	每次5~10条，人工输入问题观察结果。	每次数百条，自动化执行评测任务。
评判标准	开发者主观感受（看着还行）。	提供标准化的评估器，使用大模型作为裁判，提供量化打分（0~1分）将主观感受转化为客观的数据。
评估维度	仅关注答的对不对。	内置30+细分维度（幻觉、AI味、工具参数正确性、格式检查等）的评估器，全方位对智能体进行评估检查。
迭代保障	无法回归，越改越怕。	通过评估建立数据基线，分数对比一目了然，提示词调整、智能体优化有据可依。

智能体评估要素

让智能体由黑盒变得透明非常简单。在AgentArts中可以将“智能体评估”的过程，形象地类比为AI举办的一场“模拟考试”。在这场自动化模考中，包含三大核心要素（分别对应AgentArts平台上的三大核心功能）：

要素一：评测集，定义考卷与标准答案
您想考察智能体的哪些能力，评测集就是包含了上百条测试用例的结构化数据表。一张优秀的考卷，绝不能只有“送分题”（常见问题），它必包括：
- 正向用例：测试基础业务能力。
- 边界用例：测试模糊提问，上下文衔接能力。
- 对抗用例（陷阱题）：如故意询问知识库外的信息，测试其拒答能力。
在平台中，需要给评测集设计数据字段，包含基础的input（输入问题）和reference_output（预期答案），并可基于实际测试要求增加额外的字段。
要素二：评估器，挑选阅卷者和评分标准
考卷做完了，用什么标准来打分？AgentArts预置了30+不同专业领域的“阅卷官”，针对同一份回答，它们有不同的审视视角。
- 正确性评估器：只核对核心事实和关键数据是否与参考答案一致。
- 幻觉现象评估器：拿着参考资料（Context）逐句排查，只要AI输出了不相干的内容，直接判定为0分。
- 工具参数正确性评估器：不看文本，专盯Trace轨迹，检查AI调用的API参数字段类型和数值是否全部正确。
评估器不是越多越好，创建评估任务时，您需要根据业务痛点，合理地选择评估器，组合使用。
要素三：评估任务，组织自动化模考并发放成绩单
评估任务本质是将评测集发给智能体，并由评估器打分的过程。在配置好评测集、评估器后，只需创建评估任务，系统将在后台高并发地运行所有题目，追踪每一次智能体的调用数据，并最终汇总生成多维度的评估报告。

量化评估到针对性调优

许多新手开发者最大的误区是“拿到高分评估报告，就认为工作结束了”。事实上“为了找到缺陷并证明优化有效”才是评估的最终价值。在AgentArts评估智能体工程中，强烈建议将以下评估方法论融入到评估动作中。

阶段一：基线摸底
智能体初版完成后，立即使用包含30~50条黄金数据的评测集跑一次“基线测试”。并通过评估报告查看“能力洼地”。例如，某企业IT助手的总分有85分，但“幻觉现象”这一项得分极低，仅有40分。这明确了第一阶段的优化目标是“防止编造”。
阶段二：抓取BadCase、人工标注校准数据
- 下钻寻根：在报告的数据明细列表中，按得分进行升序排列，过滤出那些被打0分或低分的“不及格”测试用例。对比“用户原始问题”、“智能体实际输出”与“标准参考答案”的差异。查看中间流转节点的输出：是知识库检索为空导致它开始瞎编？还是插件工具的API返回了复杂JSON它没能正确解析？
- 人工改分（建立真值）：大模型“阅卷官”虽然高效但并非100%完美。如果您在复核时发现评估器打分过于严苛或存在误判，可以直接修改该条测试的得分。修改后的分数将作为权威的“真值”保存，让统计更加精准。
- 打标签（错题归类）：为正例打上标签，也可以为查明病因的BadCase打上标签（例如：Prompt约束弱、知识库缺失、API提参问题）。这个动作将冷冰冰的报告变成了一本结构化的“错题本”，为下一步的批量调优指明方向。
阶段三：精准微调
带着明确的“病因”返回智能体编辑界面，进行针对性干预。常见的干预手段包括：
- 修改Prompt：如果病因是发生幻觉，在系统提示词中追加强约束，例如：“【重要指令】当知识库检索结果为空时，必须明确回复‘抱歉，内部知识库暂无相关指南’，严禁根据模型自有知识进行解答。”
- 修改插件/MCP描述：如果病因是参数提取错误，去修改对应工具的描述字段，把原本模糊的“date”描述修改为“请提取用户提问中的时间，并必须转换为YYYY-MM-DD格式”。
- 补充知识库：如果病因确实是源文件中缺少这部分知识，则去维护底层的知识库内容。
阶段四：回归验证
智能体调整完成后，使用同一份评测集执行一次评估，观察评分是否得到改善。如果“幻觉现象”的分数从0分跃升到了1分，并且其他维度的分数没有下降（没有发生回归灾难），那么恭喜您，您的优化动作被数据科学地证明是成功的！