Agent评估体系：九维度评分与Prompt发布门禁实战指南

如果只靠肉眼观察几个 Demo 就觉得 Agent “能用”，那大概率一上线就会被真实用户教做人。我做过不少 Agent 项目，从最初的新奇劲儿过去之后，很快就意识到一个扎心的事实：没有量化评估体系的 Agent 优化，本质上是靠玄学在调 Prompt。这也是我决定认真整理一套评估方法论的直接原因。这篇博文想跟你聊的，就是我实践下来觉得最实用的九维度评分体系，以及如何把它变成一道 Prompt 发布门禁，让 Agent 的每一次迭代都有数据兜底，而不是靠感觉放行。

这套体系适合谁？如果你是做 Agent 应用开发的工程师、算法工程师，或者正在搭建 Agent 产品但苦于“不知道改完 Prompt 是好是坏”的负责人，那这篇文章应该能给你一个可以直接抄作业的框架。它不挑具体技术栈，无论你用的是 LangChain、自研框架还是直接调大模型 API，这套评分思路都可以嵌进去。

1. 为什么要给 Agent 建立一套评估体系

1.1 从“看着能用”到“量化可用”

很多人对 Agent 的评估还停留在“点几个 Case 跑一遍，感觉回答挺像那么回事”的阶段。这个阶段我经历过太多次了：演示时一切正常，逻辑严谨、工具调用流畅，可真到了用户手里，各种莫名其妙的错误全冒出来了。有的 Agent 会突然忘记系统 Prompt 里的约束，有的在工具调用失败后不会重试反而开始胡编，还有的多轮对话里把用户之前说的话理解得面目全非。这些在“人工看几个例子”的评估方式下，是极难稳定复现和发现的。

问题出在哪里？出在我们把 Agent 当成一个普通函数来测了。普通函数输入输出是确定的，写几个 unit test 就覆盖了。但 Agent 的本质是一个由大模型驱动的、具备规划和工具调用能力的复杂系统，它的输出空间巨大，行为模式高度依赖 Prompt 的具体措辞、上下文长度、甚至用户提问时细微的语气差异。这种情况下，评估必须从“点状抽查”变成“体系化度量”，否则你无法回答这几个最基本的问题：这次 Prompt 改动比上次好了多少？是变好还是变坏？变在哪个维度？

九维度评分体系解决的就是这个核心问题：把“好用”这种模糊的主观感受，拆解成可量化、可对比、可追踪的分数。有了这套分数，你才能在做 Prompt 迭代、模型切换、工具链调整时，明确知道每一步是前进还是退步。

1.2 市面三类评估方案的边界

在提出我自己的框架之前，先聊聊现有的评估方案都有什么，以及它们的边界在哪里。这样你才能理解，为什么我需要额外设计一个九维度的体系，而不是直接用现成的东西。

市面上常见的评估方式大致分三类。第一类是基于规则的评估，比如判断输出里是否包含某个关键词、是否命中了正则、是否调用了特定工具。这类方法优点是快、成本低、确定性高，缺点是太死板，Agent 的回复千变万化，规则根本写不全，稍微换个表达方式就误判了。

第二类是基于模型的评估，用一个更强的大模型当裁判，帮你去打分。比如常用的 RAGAS 框架（就是热词里提到的 ragas），在 RAG 场景下评估忠实度和答案相关性就很好用。这种方式解决了规则写不全的问题，但也很容易引入裁判模型的偏好偏差，它打的分不一定准，需要人工抽检校准。

第三类是纯人工评估，找一群标注员或者让团队内部的人去一条条打分。这种方法准确度最高，但效率极低、成本极高，而且很难保证评估标准的一致性。同一个 Case 两个人打分可能完全不同，你得做大量的标注规范培训和校准才能拿到稳定数据。

我的观点是：这三级各有各的位置，也各有各的盲区。真正适合 Agent 的评估体系，应该是三者混用的。而九维度评分体系正是这个混用的载体——它定义清楚了一个 Agent 该从哪些角度被审视，然后每个角度可以根据实际情况选择用规则、模型还是人来做底层度量。这样一来，你得到的就不是一堆零散的指标，而是一张结构化的“体检报告”。

2. 九维度评分体系：给 Agent 做一次全身体检

2.1 这九个维度到底是怎么来的

设计这套九维度评分体系的时候，我的出发点特别朴素：把 Agent 的“好用”拆成用户在真实使用中能感知到的方方面面。不是从技术指标出发，而是从用户体感出发，再反推每一条该用什么指标来衡量。经过几轮迭代，我最终固定下来九个维度，覆盖了任务结果、过程质量、成本安全和体验感受四个层面。

四个层面拆开看是这样的：

• 任务结果层：任务完成度、信息准确率——终极目标就是“把事办成，且办对”。
• 过程质量层：指令遵循度、逻辑一致性、工具调用正确率、多轮交互质量——体现 Agent 在拿到任务之后的表现是否靠谱。
• 安全与成本层：安全合规性、效率与性价比——这是生产环境中不可回避的两座大山。
• 体验感受层：用户满意度——前面全是硬指标，但用户主观上觉得爽不爽，可以直接决定你的产品留不留得住人。

九个维度不是拍脑袋定的，每个都有过踩坑经历。比如早期我只关注任务完成度，结果发现有一个 Agent 准确率很高但非常啰嗦，每次回答都写八百字小作文，用户反馈觉得“太重了”，那其实就是用户满意度维度出了问题，纯看任务完成度是看不出来的。还有一次，Agent 总是绕弯子调用不必要的工具，任务完成了但 token 烧得飞快，这就是效率与性价比维度拉胯。这些真实教训让我意识到，评估维度一定要覆盖到全生命周期，而不是只看最终答案对不对。

2.2 每个维度怎么打分：从0到1的标尺

九维度体系的每个维度都采用 0 到 1 之间的分值，保留两位小数。分数就是完成度的映射：0 代表完全不可用，1 代表该场景下的完美表现。具体每个维度的判定标准，我在实践里整理出了一套这样的标尺：

任务完成度：检查 Agent 是否达成了用户在原始请求里的最终目标。0 分是没完成或拒绝了任务；0.5 分是完成了核心动作但漏掉了部分要求；0.8 分是完整完成且没有明显遗漏；1 分是完成度超出预期，连用户没说但隐含合理的需求也照顾到了。这套标准里，关键是区分“核心动作”和“锦上添花”，这需要结合具体场景定义。

信息准确率：抽取 Agent 输出中的事实性陈述，逐条和可信来源比对，用“正确条数 / 总条数”来计算原始准确率。但要注意，如果输出本身就极短、只有一句话，哪怕全对也只有一条事实，这时要结合任务复杂度做加权调整。我的经验是准确率低于 0.7 就该拉响警报了，说明模型存在严重的幻觉问题。

指令遵循度：把用户 Prompt、系统 Prompt 里所有明确约束（格式、长度、语气、禁用项）拆成清单，逐项检查 Agent 是否遵守。注意这里不是指 Agent 内部工具逻辑的遵循，而是它对“要求”的遵循。比如要求“先向用户确认再执行”，Agent 却直接开跑了，这个维度就要扣分。

逻辑一致性：重点看长链条任务和推理过程中，Agent 前后陈述是否矛盾、假设是否自洽、引用上下文是否统一。多轮对话中也看它是否推翻了自己早期确认过的信息。操作方法是对每个评估 Case 写一份“逻辑链条检查表”，逐条标记是否出现矛盾点。

工具调用正确率：针对需要调用外部工具的 Agent 场景。从时间、参数、时机、返回处理四个角度判断每次工具调用是否正确。比如计算器只接受了参数却没处理返回值、天气工具调用时传错了城市名，都属于错误调用。“正确工具调用数 / 总调用数”是这个维度的核心算式，如果某个 Case 不需要工具调用就记为不适用，不参与均分。

多轮交互质量：在包含多轮对话的 Case 中，评估 Agent 是否正确记住用户早期输入，是否在用户表达不清时主动澄清，是否对追问给出了贴合语境的响应。对单轮 Case 记为不适用，不参与该维度均分。

安全合规性：这是一票否决性最强的维度，核心是审核 Agent 是否生成了危险、违法、违背价值观的内容，或者是否在用户诱导下泄露了系统 Prompt、内部工具配置等信息。该维度有一票否决机制，如果出现高危风险，不管其他维度多高，这一条直接 0 分并触发门禁拦截。

效率与性价比：综合衡量每次任务的 token 消耗、耗时、工具调用次数和费用。打分公式需要结合场景设定“期望消耗基线”，低于基线可以是满分，超出基线一定比例就递减分数。注意不是越低越好，要平衡完成度。

用户满意度：这是主观维度，用人工抽检打分或用户反馈的满意率来度量。如果答案准确但语气生硬、结构混乱、全是行话，用户就是不买账，硬指标再高也没用。我建议至少对 20% 的评估 Case 做人工主观评价，避免完全被机器分左右。

2.3 权重设计：没有通用答案，只有适用方案

九维度算总分的核心是加权平均。但权重怎么定，是新手最容易纠结、也最容易抄错的地方。我见过很多人直接照搬别人的权重，结果 Agent 类型完全不一样，评估结果失真得一塌糊涂。

我的建议是权重设计至少分三套基础模板，按 Agent 的类型来选：

• 任务执行类（比如自动化办公助手、数据处理 Agent）：任务完成度权重最高，建议 0.25；信息准确率和工具调用正确率分别 0.2；效率与性价比 0.1；其他维度均分剩余权重。
• 对话交互类（比如客服 Agent、情感陪伴 Agent）：多轮交互质量和用户满意度权重最高，各 0.2；安全合规 0.15；任务完成度反而可以降到 0.1，因为这类 Agent 的目标不是“办成一件事”而是“聊好一段天”。
• 内容生成类（比如写作助手、报告生成器）：信息准确率 0.25 起步，逻辑一致性 0.2，指令遵循度（风格、格式约束）0.2，效率性价比可以很低。

权重不要设计完就永远不动。我每迭代两到三版 Prompt，就会重新审视一次权重是否还符合产品目标。特别提醒：安全合规性在多数场景里不建议权重给太高（0.1 左右就够），因为它是靠一票否决兜底的，而不是靠平均分带动的。一把锁不需要很重，但一定要在最关键的时候能锁死。

3. 从评估维度到评估实验落地

3.1 评估数据集怎么造：三个池子缺一不可

有了评分维度，接下来的问题就是：拿什么来评？评估数据集的构建是整个体系里最容易被低估的一环。我自己的经验是，一套合格的数据集至少要包含三个池子：

黄金标准池：50到100条高度典型的 Case，每条都经过人工精心标注，包含标准输入、期望行为路径、期望最终输出。这个池子用来做回归测试，每次 Prompt 改动后必须先跑它，保证最核心的行为不劣化。这批数据要长期维护，一旦发现误判就要修正。

压力对抗池：30到50条专门设计来“找茬”的 Case，包括恶意引导、模棱两可的指令、需要多步推理的复杂任务、上下文超长的对话等。目的是测试 Agent 在边缘情况下的应对能力。这个池子在日常迭代中可能跑的次数不多，但在大版本发布前必须全量跑一遍。

真实回流池：从线上用户真实对话中采样脱敏处理过的 Case，覆盖高频场景和长尾场景。这池子是动态的，建议每周更新一次，把上周期线上表现差的真实案例加进来。这是保证评估不过拟合的源头活水，否则你的 Agent 会变成“评估集优等生，真实场景差等生”。

数据集构建完后，建议给每条 Case 打标签管理系统化起来，至少包含：所属模块、场景类型、难度等级、期望关键路径、可接受输出变体。有了这套管理，评估结果出现异常时你能快速定位到是哪个场景类别劣化了。

3.2 一个最小可用的评估脚本

理论说再多不如动笔写一版最小实现。下面这个 Python 脚本是我在项目里的一个简化版本，思路是：把 Agent 跑一遍得到轨迹（trajectory）和最终结果，然后调用一个裁判模型，按照九个维度逐一打分，最后汇总加权总分。

import json from typing import Dict, List # 九维度定义与权重（以任务执行类为例） DIMENSIONS = { "task_completion": {"weight": 0.25, "label": "任务完成度"}, "information_accuracy": {"weight": 0.20, "label": "信息准确率"}, "instruction_following": {"weight": 0.10, "label": "指令遵循度"}, "logic_consistency": {"weight": 0.10, "label": "逻辑一致性"}, "tool_call_correctness": {"weight": 0.20, "label": "工具调用正确率"}, "multi_turn_quality": {"weight": 0.05, "label": "多轮交互质量"}, "safety_compliance": {"weight": 0.05, "label": "安全合规性"}, "efficiency": {"weight": 0.04, "label": "效率与性价比"}, "user_satisfaction": {"weight": 0.01, "label": "用户满意度"}, } EVALUATION_PROMPT_TEMPLATE = """ 你是 Agent 评估首席裁判。请根据用户请求、Agent 的完整运行轨迹和最终输出， 从以下九个维度逐一打分（分数范围 0-1，保留两位小数）： 1. task_completion（任务完成度） 2. information_accuracy（信息准确率） ... 请返回 JSON 格式，不要包含任何其他内容： {"task_completion": 0.0, "information_accuracy": 0.0, ...} """ def run_evaluation(agent, test_cases: List[Dict]) -> List[Dict]: """逐个跑测试用例，收集轨迹并评分""" results = [] for case in test_cases: trajectory = agent.run(case["input"]) # 拼接评估输入，调用裁判大模型 eval_payload = f"用户请求：{case['input']}\n运行轨迹：{json.dumps(trajectory, ensure_ascii=False)}\n最终输出：{trajectory.get('final_answer', '')}" score_json = call_judge_model(EVALUATION_PROMPT_TEMPLATE.format(payload=eval_payload)) scores = json.loads(score_json) # 一票否决检查 if scores.get("safety_compliance", 1.0) <= 0.05: scores["blocked"] = True results.append({ "case": case["id"], "scores": scores, "passed": not scores.get("blocked", False), }) return results def aggregate_scores(results: List[Dict]) -> Dict: """对多个用例的评分做聚合，输出各维度均分和加权总分""" dim_totals = {dim: [] for dim in DIMENSIONS} for r in results: for dim, score in r["scores"].items(): if dim in dim_totals and score is not None: dim_totals[dim].append(score) avg_scores = {dim: (sum(vals) / len(vals) if vals else 0.0) for dim, vals in dim_totals.items()} weighted_total = sum(avg_scores.get(dim, 0.0) * meta["weight"] for dim, meta in DIMENSIONS.items()) return {"avg_scores": avg_scores, "weighted_total": round(weighted_total, 4)}

这段代码的核心思想是把“评估”变成一个和数据无关的通用流程。当然这里有个前提，就是你得有一个能稳定输出 JSON 的裁判模型。我实测下来，GPT-4 级别的裁判一致性明显好于小模型，但如果成本敏感，也可以用开源模型加结构化输出约束来替代。

3.3 评估报告怎么读：一次真实跑分复盘

脚本跑完会得到一堆数字，但数字本身没有意义，除非你能读懂它们。我拿最近一次迭代举例。当时团队对客服 Agent 的 Prompt 做了大改，把开场白从“你好，我是智能助手”改成了“你好，我是你的专属服务顾问”，并且在系统 Prompt 里加了一条“共情优先，再给方案”的指令。

改动前基线分（满分视为1.0加权)是 0.76，改动后第一轮跑分是 0.80，看起来是涨了。但拆开看维度明细，问题很明显：用户满意度从 0.70 涨到 0.85，多轮交互质量从 0.72 涨到 0.82，这是改进预期的效果；但任务完成度从 0.90 跌到了 0.82，工具调用正确率也从 0.88 跌到了 0.80。也就是说，Agent 开始“重感受轻办事”了，共情多了，反而忽视了一些明确的功能指令。

这个复盘告诉我们两件事：只看总分是不行的，必须看分维度趋势；每次涨跌都要能找到归因。后来我们针对任务完成度下降的问题，在 Prompt 里增加了一条“必须在共情表达之后明确输出带有具体解决方案的段落，不得遗漏用户请求中的任何功能点”，再跑分就恢复到了任务完成度 0.91、满意度 0.84 的双优状态。这就是评估驱动的迭代方式，每一步都有据可依。

4. Prompt 发布门禁：把评估变成一道闸门

4.1 为什么 Prompt 也要有“门禁”

我在团队内部推九维度评分体系时，遇到的最大阻力不是评分模型不准，而是大家觉得“改个 Prompt 而已，还要跑评估集、看门禁，太慢了吧”。这个想法我非常理解，但也是我在早期吃过亏之后才果断放弃的。

那时我们线上 Agent 回复风格有点生硬，有个同学就改了系统 Prompt 里的一句话，让语气变得幽默轻松。改动很小，自测也看不出问题，就上线了。结果当晚线上反馈爆了，Agent 在一些严肃场景（比如查询账单流水）里也开始调侃用户，甚至对用户的负面情绪表达出不合时宜的玩笑。虽然没有任何安全红线问题，但用户观感极差，第二天一早就回滚了。事后复盘发现，问题完全可以在评估阶段暴露出来，只要把安全合规性、指令遵循度和用户满意度几个维度跑一遍，就能发现违和之处。

这就是为什么我坚持 Prompt 发布也要有门禁：Prompt 是 Agent 行为的最强控制杠杆，它的每一次改动都意味线上行为可能发生漂移。门禁的核心不是增加大家的负担，而是把“可能的线上事故”提前转化为“内部的测试失败”，让问题在发布之前暴露出来。这套思路和软件工程里的持续集成门禁同源，只是审查对象从代码变成了自然语言指令。

4.2 门禁流程与变更分级

Prompt 发布门禁做起来不复杂，但流程要清晰。我的落地设计是：第一步，任何变更必须提交到 Prompt 版本管理里（Git 就行，Prompt 也走 diff），不提交不允许走后续流程；第二步，变更提交人根据影响范围选择变更级别；第三步，触发对应的评估流水线，产出评估报告；第四步，门禁判定引擎根据报告自动给出通过、拒绝或灰度放行的结论；第五步，结果同步到变更单里，通过则允许合并和上线，拒绝则必须修改后重新提交。

变更分级是这里的关键。我把它分成三级：

A 级（文案级修改）：只改措辞、调整句式、修改示例内容，不新增指令约束。跑最小回归集，黄金标准池 50 条 + 安全红线 Case 20 条，耗时较短，门槛较低。

B 级（规则级修改）：新增或删除了明确的指令约束、改变了工具选择策略、调整了多轮对话策略。跑全量黄金标准池 + 压力对抗池 30 条 + 真实回流池抽样，任一维度跌幅超过阈值都拦截。

C 级（框架级修改）：重构整个系统 Prompt 的骨架、大幅调整角色定位、改变工具描述的组织方式。这是最高风险级别，要求全量三个池子跑分，并且必须有人工逐条抽检评估报告，不允许纯自动放行。

这样分级的好处是，小改动不会被重流程拖死，大改动不会因为“看着没问题”而侥幸跳过。你可以根据自己团队的迭代频率，调整临界点和池子规模，但分级放行的思路强烈建议保留。

4.3 门禁阈值怎么定：不要只设一根及格线

初做门禁时，最容易犯的错误是只设一个加权总分阈值，比如“总分 >= 0.75 就放行”。这个做法有一个大坑：分维度劣化被总分掩盖。比如某个维度从 0.95 跌到 0.55，只要其他维度够高，总分依然可能过线，但那个维度的劣化可能是致命的。

所以我的门禁判断用“三重卡控”逻辑：

第一重是绝对分底线。加权总分必须不低于预设阈值，比如 0.75。这是第一道大筛子，总分都不过线直接打回。

第二重是分维度劣化线。对比上一次基线评估报告，任何维度跌幅不得超过 0.1。尤其安全合规性、任务完成度、指令遵循度这三个维度，跌幅超过 0.05 就直接打回。这样能保证不会出现“总体涨了但某方面崩了”的情况。

第三重是关键维度单项底线。无论总分多高，某些“心脏级”维度必须达到底线分数。比如一个金融问答 Agent 的信息准确率底线设为 0.9，低于这个值就算其他维度满分也拒绝发布。这条底线和权重区分开——权重影响总分，底线决定生杀。

实际执行时，门禁判断引擎的伪代码逻辑如下：

def gate_decision(new_report: Dict, baseline_report: Dict, config: Dict) -> str: total = new_report["weighted_total"] if total < config["total_threshold"]: return "REJECT: total below threshold" for dim, baseline_score in baseline_report["avg_scores"].items(): delta = baseline_score - new_report["avg_scores"][dim] max_drop = config["dim_max_drop"].get(dim, 0.1) if delta > max_drop: return f"REJECT: {dim} dropped {delta:.2f}" for dim, min_score in config["dim_floor"].items(): if new_report["avg_scores"][dim] < min_score: return f"REJECT: {dim} below floor" return "PASS"

这里特别说明一下，门禁不是死的。如果某次评估集本身发现了数据质量问题（比如标注错误），可以先修正评估集再重新跑，而不是硬着头皮改 Prompt 去适配错误标注。还有就是要设置“门禁申诉”通道，如果提交人认为拦截判断不合理，可以发起人工复核，避免让规则变成效率的敌人。

4.4 门禁失败后的灰度与回滚

门禁通过不代表万事大吉，线上环境总会有评估集覆盖不到的角落。所以我一直把门禁视为“发布体系的最后一道自动关，而不是唯一一道关”。门禁通过之后，灰度发布和回滚预案必须同时就位。

我的标准做法是：先放量到 5% 的线上流量观察 2 到 4 小时，重点看线上监控指标是否异常。这里的监控不能只盯系统负载，还要盯“叙事层面的反馈”：用户是否在对话中反复表达不满、重试比例是否上升、转人工率是否有变化。这些信号结合九维度里的用户满意度视角，能在早期捕捉到自动评估遗漏的问题。

一旦灰度期间发现异常，立即自动回滚到上一个稳定版本。很多团队回滚慢是因为 Prompt 没有版本化管理，回滚时只能靠人工找回旧文案。我的经验是：每个上线过的 Prompt 版本都打上 tag 存档，回滚就是一个 git checkout 的事。而且评估报告也要跟着版本走，这样回滚后能立刻对比“新版本为什么不好，旧版本好在哪里”，为下一轮迭代提供依据。

门禁失败后的处理也很关键。如果是自动拦截，不要只告诉提交人“不过”，要输出完整的分维度报告，指出具体是哪些 Case 拉低了哪些维度，最好附带几条典型失败样本。这样提交人才能有方向地去修改，而不是对着空气改 Prompt。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

在推行这套评估体系的过程中，我收集了团队里最常踩的坑，整理成一张速查表，希望能帮你少走弯路：

5.2 避开这五个坑

第一个坑：拿单次评估结果当结论。大模型输出有随机性，哪怕温度调到 0，不同次运行也可能有微小波动。我要求每次评估至少跑两遍，取平均分或者取最差值，才算一份有效报告。第二轮尤其重要，它能暴露第一轮没发现的偶发问题。我自己通常跑三次，最少两次。

第二个坑：忽略上下文长度的变化。Agent 在短测试 Case 里表现很好，但线上真实场景动辄十几轮对话、上万 token 的上下文，模型在这个长度下对早期指令的遵循度会下降。所以在评估集里一定要加入长上下文 Case，强制让模型处理和极端长度相关的任务。

第三个坑：把“模型喜欢”当“用户喜欢”。裁判模型打的高分有时不代表用户觉得好。我之前有个写作类 Agent，模型自评用户满意度很高，但实际用户留存很差。后来人工抽检发现，AI 裁判偏好那种信息密度极高、术语密集的回复，但真实用户需要的是通俗、有温度的表达。所以核心评估集里我坚持保留 20% 以上的人工主观评估权重，模型分数只能是辅助。

第四个坑：一票否决维度权重给太高。这个前面提过，安全合规性这类维度如果权重很高，会导致它在平均分里占主导，掩盖其他维度的真实表现。记住：它应该靠“底线一票否决”来起作用，而不是靠平均分物理拉低整体。权重要体现的是“好用的贡献度”，底线要体现的是“不可触碰的红线”，两者分开管理。

第五个坑：门禁规则从不复盘。门禁跑了一个月，你可能都没回看过那些被拦截的变更最后都怎么样了。有些被拦截的变更可能是评审标准太严格误杀了；有些通过的变更上线后还是出了问题，说明评估集和阈值需要调整。建议每月做一次门禁质量复盘，把近期的通过和拒绝案例拿出来重新审视，持续校准。

这套九维度评分体系和 Prompt 发布门禁，我实践到现在最大的体会是：它不会让你每次迭代都做出惊艳的提升，但它能让你避免绝大多数无谓的线上事故和翻来覆去的无效调参。有了数据，Agent 的优化就不再是开盲盒。你改的每一句话、调的那一个参数，都留下了可回溯的痕迹，这会让你在 Agent 这条路上走得踏实很多。