如果只靠肉眼观察几个 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_asciiFalse)}\n最终输出{trajectory.get(final_answer, )} score_json call_judge_model(EVALUATION_PROMPT_TEMPLATE.format(payloadeval_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 fREJECT: {dim} dropped {delta:.2f} for dim, min_score in config[dim_floor].items(): if new_report[avg_scores][dim] min_score: return fREJECT: {dim} below floor return PASS这里特别说明一下门禁不是死的。如果某次评估集本身发现了数据质量问题比如标注错误可以先修正评估集再重新跑而不是硬着头皮改 Prompt 去适配错误标注。还有就是要设置“门禁申诉”通道如果提交人认为拦截判断不合理可以发起人工复核避免让规则变成效率的敌人。4.4 门禁失败后的灰度与回滚门禁通过不代表万事大吉线上环境总会有评估集覆盖不到的角落。所以我一直把门禁视为“发布体系的最后一道自动关而不是唯一一道关”。门禁通过之后灰度发布和回滚预案必须同时就位。我的标准做法是先放量到 5% 的线上流量观察 2 到 4 小时重点看线上监控指标是否异常。这里的监控不能只盯系统负载还要盯“叙事层面的反馈”用户是否在对话中反复表达不满、重试比例是否上升、转人工率是否有变化。这些信号结合九维度里的用户满意度视角能在早期捕捉到自动评估遗漏的问题。一旦灰度期间发现异常立即自动回滚到上一个稳定版本。很多团队回滚慢是因为 Prompt 没有版本化管理回滚时只能靠人工找回旧文案。我的经验是每个上线过的 Prompt 版本都打上 tag 存档回滚就是一个 git checkout 的事。而且评估报告也要跟着版本走这样回滚后能立刻对比“新版本为什么不好旧版本好在哪里”为下一轮迭代提供依据。门禁失败后的处理也很关键。如果是自动拦截不要只告诉提交人“不过”要输出完整的分维度报告指出具体是哪些 Case 拉低了哪些维度最好附带几条典型失败样本。这样提交人才能有方向地去修改而不是对着空气改 Prompt。5. 常见问题与排查技巧实录5.1 高频问题速查表在推行这套评估体系的过程中我收集了团队里最常踩的坑整理成一张速查表希望能帮你少走弯路问题现象可能原因排查与解决裁判模型打出的分数波动很大评估输入里轨迹过长模型丢了关键信息截断轨迹聚焦关键步骤和最终输出Agent 在评估集上表现好线上拉胯真实回流池更新不及时评估过拟合增加线上真实 Case 抽样频率每周至少一次加了门禁后迭代速度明显变慢全部变更都跑全量评估集按 A/B/C 分级配置不同的评估池小改小测某个维度分数长期过低怎么调 Prompt 都没用问题可能不在 Prompt而在工具定义或模型能力先换工具调参或升级底座模型再回来调 Prompt工具调用正确率难以自动判定工具调用链复杂裁判模型难以判断“是否正确”人工抽检 增加工具自身的日志断言安全合规性问题漏网对抗池覆盖不足或进攻方式太单一定期更新对抗样本引用行业案例生成变体评分集中在 0.8~0.9 之间失去区分度评估 Case 难度偏低模型已经饱和了加入更多高难度 Case让区分度重新拉开5.2 避开这五个坑第一个坑拿单次评估结果当结论。大模型输出有随机性哪怕温度调到 0不同次运行也可能有微小波动。我要求每次评估至少跑两遍取平均分或者取最差值才算一份有效报告。第二轮尤其重要它能暴露第一轮没发现的偶发问题。我自己通常跑三次最少两次。第二个坑忽略上下文长度的变化。Agent 在短测试 Case 里表现很好但线上真实场景动辄十几轮对话、上万 token 的上下文模型在这个长度下对早期指令的遵循度会下降。所以在评估集里一定要加入长上下文 Case强制让模型处理和极端长度相关的任务。第三个坑把“模型喜欢”当“用户喜欢”。裁判模型打的高分有时不代表用户觉得好。我之前有个写作类 Agent模型自评用户满意度很高但实际用户留存很差。后来人工抽检发现AI 裁判偏好那种信息密度极高、术语密集的回复但真实用户需要的是通俗、有温度的表达。所以核心评估集里我坚持保留 20% 以上的人工主观评估权重模型分数只能是辅助。第四个坑一票否决维度权重给太高。这个前面提过安全合规性这类维度如果权重很高会导致它在平均分里占主导掩盖其他维度的真实表现。记住它应该靠“底线一票否决”来起作用而不是靠平均分物理拉低整体。权重要体现的是“好用的贡献度”底线要体现的是“不可触碰的红线”两者分开管理。第五个坑门禁规则从不复盘。门禁跑了一个月你可能都没回看过那些被拦截的变更最后都怎么样了。有些被拦截的变更可能是评审标准太严格误杀了有些通过的变更上线后还是出了问题说明评估集和阈值需要调整。建议每月做一次门禁质量复盘把近期的通过和拒绝案例拿出来重新审视持续校准。这套九维度评分体系和 Prompt 发布门禁我实践到现在最大的体会是它不会让你每次迭代都做出惊艳的提升但它能让你避免绝大多数无谓的线上事故和翻来覆去的无效调参。有了数据Agent 的优化就不再是开盲盒。你改的每一句话、调的那一个参数都留下了可回溯的痕迹这会让你在 Agent 这条路上走得踏实很多。
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_asciiFalse)}\n最终输出{trajectory.get(final_answer, )} score_json call_judge_model(EVALUATION_PROMPT_TEMPLATE.format(payloadeval_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 fREJECT: {dim} dropped {delta:.2f} for dim, min_score in config[dim_floor].items(): if new_report[avg_scores][dim] min_score: return fREJECT: {dim} below floor return PASS这里特别说明一下门禁不是死的。如果某次评估集本身发现了数据质量问题比如标注错误可以先修正评估集再重新跑而不是硬着头皮改 Prompt 去适配错误标注。还有就是要设置“门禁申诉”通道如果提交人认为拦截判断不合理可以发起人工复核避免让规则变成效率的敌人。4.4 门禁失败后的灰度与回滚门禁通过不代表万事大吉线上环境总会有评估集覆盖不到的角落。所以我一直把门禁视为“发布体系的最后一道自动关而不是唯一一道关”。门禁通过之后灰度发布和回滚预案必须同时就位。我的标准做法是先放量到 5% 的线上流量观察 2 到 4 小时重点看线上监控指标是否异常。这里的监控不能只盯系统负载还要盯“叙事层面的反馈”用户是否在对话中反复表达不满、重试比例是否上升、转人工率是否有变化。这些信号结合九维度里的用户满意度视角能在早期捕捉到自动评估遗漏的问题。一旦灰度期间发现异常立即自动回滚到上一个稳定版本。很多团队回滚慢是因为 Prompt 没有版本化管理回滚时只能靠人工找回旧文案。我的经验是每个上线过的 Prompt 版本都打上 tag 存档回滚就是一个 git checkout 的事。而且评估报告也要跟着版本走这样回滚后能立刻对比“新版本为什么不好旧版本好在哪里”为下一轮迭代提供依据。门禁失败后的处理也很关键。如果是自动拦截不要只告诉提交人“不过”要输出完整的分维度报告指出具体是哪些 Case 拉低了哪些维度最好附带几条典型失败样本。这样提交人才能有方向地去修改而不是对着空气改 Prompt。5. 常见问题与排查技巧实录5.1 高频问题速查表在推行这套评估体系的过程中我收集了团队里最常踩的坑整理成一张速查表希望能帮你少走弯路问题现象可能原因排查与解决裁判模型打出的分数波动很大评估输入里轨迹过长模型丢了关键信息截断轨迹聚焦关键步骤和最终输出Agent 在评估集上表现好线上拉胯真实回流池更新不及时评估过拟合增加线上真实 Case 抽样频率每周至少一次加了门禁后迭代速度明显变慢全部变更都跑全量评估集按 A/B/C 分级配置不同的评估池小改小测某个维度分数长期过低怎么调 Prompt 都没用问题可能不在 Prompt而在工具定义或模型能力先换工具调参或升级底座模型再回来调 Prompt工具调用正确率难以自动判定工具调用链复杂裁判模型难以判断“是否正确”人工抽检 增加工具自身的日志断言安全合规性问题漏网对抗池覆盖不足或进攻方式太单一定期更新对抗样本引用行业案例生成变体评分集中在 0.8~0.9 之间失去区分度评估 Case 难度偏低模型已经饱和了加入更多高难度 Case让区分度重新拉开5.2 避开这五个坑第一个坑拿单次评估结果当结论。大模型输出有随机性哪怕温度调到 0不同次运行也可能有微小波动。我要求每次评估至少跑两遍取平均分或者取最差值才算一份有效报告。第二轮尤其重要它能暴露第一轮没发现的偶发问题。我自己通常跑三次最少两次。第二个坑忽略上下文长度的变化。Agent 在短测试 Case 里表现很好但线上真实场景动辄十几轮对话、上万 token 的上下文模型在这个长度下对早期指令的遵循度会下降。所以在评估集里一定要加入长上下文 Case强制让模型处理和极端长度相关的任务。第三个坑把“模型喜欢”当“用户喜欢”。裁判模型打的高分有时不代表用户觉得好。我之前有个写作类 Agent模型自评用户满意度很高但实际用户留存很差。后来人工抽检发现AI 裁判偏好那种信息密度极高、术语密集的回复但真实用户需要的是通俗、有温度的表达。所以核心评估集里我坚持保留 20% 以上的人工主观评估权重模型分数只能是辅助。第四个坑一票否决维度权重给太高。这个前面提过安全合规性这类维度如果权重很高会导致它在平均分里占主导掩盖其他维度的真实表现。记住它应该靠“底线一票否决”来起作用而不是靠平均分物理拉低整体。权重要体现的是“好用的贡献度”底线要体现的是“不可触碰的红线”两者分开管理。第五个坑门禁规则从不复盘。门禁跑了一个月你可能都没回看过那些被拦截的变更最后都怎么样了。有些被拦截的变更可能是评审标准太严格误杀了有些通过的变更上线后还是出了问题说明评估集和阈值需要调整。建议每月做一次门禁质量复盘把近期的通过和拒绝案例拿出来重新审视持续校准。这套九维度评分体系和 Prompt 发布门禁我实践到现在最大的体会是它不会让你每次迭代都做出惊艳的提升但它能让你避免绝大多数无谓的线上事故和翻来覆去的无效调参。有了数据Agent 的优化就不再是开盲盒。你改的每一句话、调的那一个参数都留下了可回溯的痕迹这会让你在 Agent 这条路上走得踏实很多。
