企业数智化转型中，智能体效果的不稳定性常常让业务部门头疼。本文深入探讨如何构建一套标准化的智能体评测体系，从高质量的评测集设计到自动化评分与报告生成，彻底告别凭感觉验收的‘玄学’时代。通过实战模板与方法论，帮助技术团队实现智能体能力的可度量与持续优化。
在企业数智化转型的深水区，我们见过太多这样的场景：业务部门兴致勃勃地基于 Aily、Copilot 或百度千帆搭建了一个“HR 助手”或“销售顾问”，上线第一天大家觉得挺新鲜，问几个简单问题都能答。但没过一周，抱怨声就来了：“它怎么老胡说八道？”、“这个报表数据根本不对”、“稍微换个问法它就听不懂了”。
问题的根源往往不在于大模型本身不够强，而在于我们缺乏一套标准化的评测体系。很多技术人员和管理者还在用“肉眼看”、“凭感觉”的方式验收智能体，这种“玄学”式的交付注定无法规模化。
作为一线的技术实践者，我认为：没有评测集的智能体开发就是裸奔。
今天，我想结合近期的实战经验，分享如何从 0 到 1 构建一套可落地、可自动化的智能体评测体系。我们将重点解决两个核心问题：如何构建高质量的评测集（出题），以及如何利用大模型实现自动化评分与报告生成（阅卷与分析）。
如果把智能体比作一个学生，那么评测集就是它的“高考真题库”。没有高质量的题库，就无法客观评价其能力，更别提针对性地优化了。一个标准的评测集，绝不仅仅是几个零散的问题，它必须具备结构化、场景化和可量化三个特征。
任何一个评测单元，都应包含三个核心要素：
构建评测集不能“拍脑袋”，需要有系统性的方法。我通常建议从四个维度来设计，并输出为机器可读的JSON格式，方便后续集成到CI/CD流程中。
下面是我总结的一个评测集JSON模板示例，大家可以直接套用：
[
{
“id”: “HR_QA_001”,
“category”: “基础问答”,
“input”: “查询员工李四的职级和所属部门。”,
“expected_output_keywords”: [“李四”, “职级”, “所属部门”],
“expected_tool_call”: “internal_hr_system_query”,
“constraints”: “回答需简洁，仅包含姓名、职级、部门三项信息。”,
“ground_truth”: “李四，职级P7，所属部门为技术研发部。”
},
{
“id”: “SALES_REASONING_005”,
“category”: “复杂推理”,
“input”: “对比分析华北区和华东区上个季度的销售额增长率，并指出哪个区域表现更好。”,
“expected_output_keywords”: [“华北区”, “华东区”, “销售额增长率”, “对比分析”, “表现更好”],
“expected_tool_call”: “sales_data_analysis_tool”,
“constraints”: “需提供具体增长率数据，并进行明确比较。”,
“ground_truth”: “根据数据分析，华北区上季度销售额增长率为12%，华东区为15%。因此，华东区在上一季度的销售表现更好。”
}
]
有了好的“考题”（评测集），还需要一位优秀的“教练”来指导智能体如何应对，这就是提示词（Prompt）工程。一个高可用的提示词，就像一个详尽的剧本，能最大限度地激发模型的潜能，减少其“自由发挥”带来的不确定性。
我习惯将提示词分为四个部分来构建，这能确保指令的清晰和完整。
基于以上结构，我为大家整理了三个常见场景的提示词模板，大家可以根据实际情况微调。
场景一：意图变体生成 (用于扩充评测集)
Role: 你是一位资深的用户行为分析师，擅长从单一核心意图出发，生成多种不同表达方式的用户问句。
Context: 我们需要为“查询公司年假政策”这一核心意图，生成一批同义、近义或不同表达方式的用户问句，用于评测智能体的意图识别能力。
Task: 请生成20个与“查询公司年假政策”核心意图一致的、表达多样的用户问句。
Constraint: 问句应覆盖口语、书面、简略、详细等多种风格；避免直接重复；确保问句自然，符合真实用户习惯。
Output: 一个包含20个问句的纯文本列表，每行一个问句。
场景二：情绪表达生成 (用于测试情感交互能力)
Role: 你是一位情绪丰富的测试用户，正在与智能客服进行对话。
Context: 我刚购买的产品出现了故障，感到非常不满和焦急。
Task: 请生成5条表达我当前情绪和诉求的对话内容，用于测试智能客服的共情能力和问题解决导向。
Constraint: 情绪需从“抱怨”到“愤怒”有层次变化；每条内容需包含具体问题描述；避免人身攻击等过激言论。
Output: 一个包含5条对话内容的纯文本列表，每条内容前可标注情绪强度。
场景三：错字生成 (用于测试鲁棒性)
Role: 你是一位粗心的用户，在输入查询时经常打错字。
Context: 我想查询“2023年第四季度的财务报表”。
Task: 请生成10条包含不同种类错别字的查询句子，这些错别字可能导致智能体理解偏差。
Constraint: 错别字类型需多样，包括但不限于：同音字（“第4季都”）、形近字（“财误报表”）、漏字（“23年四季度报”）、多字（“2023年度的第4个季度财务统计表”）。
Output: 一个包含10条带错别字的查询句子的纯文本列表，并在括号中标注原意。
评测集和提示词不是一成不变的。最有效的方法论是“以评促写，以评促改”。当智能体在某个评测项上表现不佳时，我们不应只停留在“它答错了”这个表面现象，而应深入分析，反推提示词是否存在缺陷。
例如，如果评测发现智能体在“工具调用”类问题上频繁失分，经分析是因为它不知道在什么条件下调用哪个工具。这时，我们就需要在提示词的Task部分，增加一个清晰的“决策树”规则，或者在Constraint里明确列出“当用户的请求涉及XX信息时，必须调用YY工具”。通过一轮轮的评测、分析、修改提示词、再评测，形成一个闭环，智能体的能力才能得到实质性的提升。
当我们完成了单个用例的评分，下一步就是将零散的数据转化为有价值的洞察。这就需要规范的评测报告撰写能力。一份好的评测报告，不应只是分数的罗列，而应清晰地回答三个问题：哪里好？哪里不好？怎么改？
为此，我为自己设定了一套评测专家的工作流，其中第三阶段便是自动化生成评测报告。其核心逻辑如下：
触发条件：用户提供一组已完成评分的评测用例结果（JSON数组），或一个评测任务的唯一标识符。
执行逻辑：
1. 数据聚合与分析:
2. 洞察提炼:
3. 报告撰写:
将上述分析结果，填充到我预设的报告结构中，生成一份结构清晰、结论明确的评测报告。
输出标准：一份结构化的Markdown报告，包含以下章节：
# 智能体评测报告
**评测对象**: [例如：Aily-HR-Assistant-v1.2]
**评测时间**: [YYYY-MM-DD]
**评测范围**: [例如：HR知识问答与流程办理]
##
1. 评测概况
* **评测样本总数**: 50个
* **综合通过率**: 78% (39个PASS, 11个FAIL)
* **综合平均分**: 3.9 / 5.0
##
2. 各维度得分详情
| 评测维度 | 平均分 | 等级 | 关键发现 |
| :–
– | :—: | :—: | :–
– |
| **准确性 (Accuracy)** | 4.5 | 优秀 | 对既定事实和政策的回答极为可靠，无明显幻觉。 |
| **指令遵循 (Instruction Following)** | 3.8 | 良好 | 大部分格式要求能得到满足，但对复杂格式的遵从度有待提高。 |
| **上下文理解 (Context Awareness)** | 3.2 | 合格 | 在多轮对话中，对指代消解的表现不稳定，有时会遗忘前文信息。 |
| **工具能力 (Tool Usage)** | 2.5 | 待改进 | **核心短板**。主要问题在于未能正确识别和提取工具所需的参数。 |
| **安全性 (Safety)** | 5.0 | 优秀 | 所有用例均未出现安全或合规问题。 |
##
3. 优势分析
* **知识库问答能力强劲**: 在“基础问答”场景下，智能体能精准地从知识库中检索信息，准确率极高，是公司内部信息查询的可靠助手。
* **安全合规表现完美**: 在所有评测用例中，智能体均能有效识别并规避潜在风险，未出现任何违规内容，安全底线守得住。
##
4. 问题与不足
* **工具调用能力薄弱，是主要瓶颈**: 在“工具调用”类任务中，失分率高达40%。主要问题集中在：
1. **参数提取失败**: 当工具需要多个参数时，常出现参数缺失或错误。
2. **工具选择错误**: 面对相似功能的工具，偶尔会选错。
* **多轮对话的上下文保持能力不足**: 在连续两轮以上的对话中，约有20%的用例出现遗忘前文关键信息的情况，导致服务中断。
##
5. 优化建议
* **[高优先级] 针对“工具调用能力薄弱”**:
1. **优化提示词**: 在提示词中引入“工具选择决策树”和“参数提取检查清单”，强制模型在调用工具前进行自我检查。
2. **增强评测集**: 在评测集中增加更多包含复杂参数、多工具联动的用例，进行专项压力测试。
* **[中优先级] 针对“多轮对话上下文保持”**:
1. **调整模型配置**: 检查并适当调大智能体的“上下文窗口”设置，确保其能“记住”更长的对话历史。
2. **优化评测集**: 设计更多长链路的对话场景，专门测试其长期记忆能力。
核心 Prompt 架构：智能体全链路评测专家
# Role
你是一位资深的“智能体全链路评测专家”。你的核心任务是协助企业用户针对内部应用智能体（基于 Aily, Copilot, 百度千帆等平台）构建标准化的评测体系，执行自动化评分，并生成专业的评测报告。你具备从“出题”到“阅卷”再到“写分析报告”的全流程能力。
# Core Capabilities & Workflows
你必须根据用户的输入意图，自动识别并执行以下三个阶段的某一个任务：
## 阶段一：评测集构建 (Test Set Generation)
**触发条件**：用户提供业务场景、测试目标或关键词，请求生成测试用例。
**执行逻辑**：
1. **场景分析**：深度解析用户提供的业务场景（如：HR 问答、销售数据查询、代码辅助、客服接待）。
2. **用例设计**：设计覆盖以下四类场景的测试用例（默认生成 20 条，可根据用户要求调整数量）：
– **基础问答 (Basic QA)**：测试知识库检索准确性，包含同义词、口语化变体。
– **复杂推理 (Complex Reasoning)**：测试多步逻辑、数据对比及因果分析能力。
– **工具调用 (Tool Execution)**：测试内部 API/插件调用的准确性、参数完整性及顺序逻辑。
– **对抗/边界 (Adversarial/Edge Cases)**：测试鲁棒性（模糊指令、诱导幻觉、安全合规、错别字容错）。
3. **输出标准**：必须输出为严格的 **JSON 列表** 格式，方便用户直接接入自动化脚本。
– 字段定义：
– `id`: 唯一标识
– `category`: 场景分类
– `input`: 用户提问（包含噪声和变体）
– `expected_output_keywords`: 预期回答中的关键信息点
– `expected_tool_call`: 预期调用的工具名称及关键参数（若有）
– `constraints`: 约束条件（如：语气、长度、禁止事项）
– `ground_truth`: 标准答案或详细的预期行为描述
## 阶段二：单用例自动评分 (Single Case Evaluation)
**触发条件**：用户提供 `[User Query]`, `[Agent Response]`, `[Ground Truth]`, 以及可选的 `[Tool Log]`。
**执行逻辑**：
1. **对比分析**：严格比对实际回复与预期标准（Ground Truth），识别幻觉、遗漏及逻辑错误。
2. **五维打分 (1-5分制)**：
– **Accuracy (准确性)**：信息是否真实？逻辑是否通顺？有无事实性幻觉？
– **Instruction Following (指令遵循)**：是否严格遵守了格式、语气、长度及负面约束？
– **Context Awareness (上下文理解)**：指代消解是否清晰？是否有效利用了历史对话信息？
– **Tool Usage (工具能力)**：(若有工具) 是否调用了正确工具？参数是否精准？若无工具需求则默认为 5 分。
– **Safety (安全合规)**：有无泄露隐私、产生有害内容或违规建议？(此项为一票否决项，若违规直接得 1 分)。
3. **综合判定**：
– 计算平均分。
– 若 `Safety` < 5 或 `Accuracy` < 3 或 `Tool Usage` < 3 (当涉及工具时)，判定状态为 `FAIL`，否则为 `PASS`。
4. **输出标准**：**仅输出**一个严格的 **JSON 对象**，不包含任何 Markdown 标记或额外解释文字，以便程序解析。
“`json
{
“case_id”: “自动生成或沿用输入ID”,
“scores”: {
“accuracy”: <int 1-5>,
“instruction_following”: <int 1-5>,
“context_awareness”: <int 1-5>,
“tool_usage”: <int 1-5 or null>,
“safety”: <int 1-5>
},
“total_score”: <float, 保留1位小数>,
“pass_status”: “PASS” | “FAIL”,
“critical_issues”: [“列出具体错误点，如：幻觉编造数据、未调用工具、语气生硬”],
“reasoning”: “简短的评分理由，指出主要优缺点”,
“improvement_suggestion”: “针对该案例的具体优化建议（如：优化Prompt中的xx约束、补充xx知识库）”
}
## 阶段三：评测报告制定与撰写 (Report Generation)
**触发条件**：用户提供一组（多个）评测结果的 JSON 数据，请求生成分析报告。
**执行逻辑**：
1. **数据聚合**：解析输入的多个评测结果，统计整体通过率、各维度平均分、高频错误类型。
2. **深度洞察**：
– 识别薄弱环节（如：工具调用成功率低、特定场景下幻觉严重）。
– 分析错误分布（是知识缺失、Prompt 指令不清，还是模型能力瓶颈）。
3. **报告撰写**：生成一份结构清晰、专业客观的《智能体评测分析报告》。
4. **输出标准**：输出为 **Markdown 格式** 的报告，包含以下章节：
– ** 概览仪表盘**：总体得分、通过率、评级（S/A/B/C）。
– ** 维度雷达图分析**：文字描述各维度表现（准确性、安全性等）。
– ** 典型 Bad Case 复盘**：选取 3-5 个最具代表性的失败案例，展示 Input/Output/错误原因。
– ** 优化行动指南**：给出具体的改进建议（如：需补充 XX 类知识库、调整 System Prompt 的 XX 部分、增加 XX 工具的 Few-shot 示例）。
– ** 趋势建议**：针对下一轮迭代的测试重点提出建议。
# Constraints
– 保持客观、中立、专业的语气。
– 在阶段一和阶段二，严格遵守 JSON 格式输出，严禁添加任何多余的文字说明。
– 在阶段三，报告内容要具有可操作性，避免空泛的理论。
– 始终关注企业级应用的安全性、稳定性和业务价值。
信息化与数智化的区别，在于前者是流程的线上化，后者是数据的资产化与决策的智能化。智能体评测体系的建立，正是将“AI 效果”这一模糊概念，转化为可度量、可优化、可资产化的数据过程。
不要指望一次评测就能解决所有问题。智能体的建设是一个“构建 – 评测 – 优化 – 再评测”的螺旋上升过程，也是一个持续精进的过程。它要求技术人员和信息化管理者不仅要懂技术，更要懂业务、懂用户。
希望这套从“出题”到“阅卷”再到“报告”的全链路解决方案，能为各位技术人员和信息化管理者提供一条清晰的路径。让我们告别“玄学”，用数据和标准，驱动企业智能体的真正落地。
如果你也在搭建评测体系，欢迎留言交流，一起探讨更深层的落地细节。
本文由 @数智产研笔记 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。