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

1. 为什么感觉好用不算好用Agent 评估的痛点1.1 传统测试在 Agent 面前失效了这几年做 AI Agent 开发的人应该都有同感功能 demo 很好做真正难的是判断这玩意儿到底能不能上线。我最早带 Agent 项目时团队还在用最朴素的办法验收效果——拉几个测试同学手动跑几条用例大家凭感觉打勾。头两周还行等 Agent 接的工具越来越多、Prompt 越写越长问题立刻暴露了同一个 Prompt上午跑是好的下午换了个说法就翻车了测试同学觉得回答得挺流畅但用户进来一问就问出幻觉。更尴尬的是开发同学改了一行 Prompt 说优化了逻辑你问他到底哪里变好了他只能说感觉更顺了。这不是个例而是 Agent 开发的普遍困境。传统软件测试里对和错是明确的——接口返回 200 就是对了返回 500 就是错了。但 Agent 是一个概率系统同一个输入每次输出都可能不同甚至很多时候没有唯一正确答案。你问它帮我把下周的会议安排一下它可能真的去调了日历 API也可能只是编了一个日程表。这两者从界面反馈上根本看不出差别但一个是真干活一个是幻觉。所以Agent 的评估必须要有一套可量化的体系把感觉好用翻译成在标准 X 下得分为 Y。1.2 发布门禁把感觉变成门槛我后来在项目里推行的做法是把评估体系与发布流程绑定做成一道硬性门禁。具体来说任何 Prompt 或者 Agent 配置的修改不只是开发自测通过就能上线还必须过一套自动化的九维度评分达到预设分数线才允许进入灰度发布。这个思路借鉴了软件工程里的 CI/CD 门禁类似代码合并前的自动化测试必须通过但针对 Agent 的特点做了改造。传统门禁检查的是功能是否正确Agent 门禁检查的是能力是否达标评估对象从确定性结果换成了概率性的行为质量。当时团队里有人抵触觉得流程变重了。但跑了两个月后态度普遍反转。原因很简单以前上线一个 Prompt 改动是开盲盒现在大家心里有底了。评分体系把好和坏的争议变成了数字层面的讨论——分数达标了上线没达标继续改。出问题了回滚看报告定位到具体维度而不是一群人围着屏幕猜是不是模型抽风了。下面我完整展开这套九维度评分体系是怎么设计的以及 Prompt 发布门禁具体怎么落地。2. 九维度评分体系怎么拆解好用这件事2.1 先分三组事办成没有、办得稳不稳、办得安不安全刚开始设计评分体系时我犯过一个典型错误——列了一堆想象中的重要维度结果发现维度之间高度重叠没办法实际操作。比如回答准确性和信息正确性看起来是两件事测起来根本分不开。后来我换了个思路不按输出特征拆而是按 Agent 的行为链路拆。一个 Agent 从接收指令到完成任务大致经历理解需求 → 规划路径 → 调用工具 → 生成输出这几个环节每个环节都可能出问题。评估维度应该覆盖整条链路而不是只盯着最终答案。于是我和团队把评估维度分成三组结果组事办成了没有。这是最直观的指标相当于传统测试里的功能正确性。过程组办得稳不稳。考察 Agent 的路径规划、工具调用、上下文管理等中间过程质量。风险组办得安不安全。涵盖权限控制、敏感信息处理、越权行为等安全因素。每组各三个维度凑成九个好记也好量化。下面逐个说。2.2 九个维度定义、打分方法与常见扣分点1. 任务完成度结果组最简单的理解用户的目标达成了没有。打分方式不是对或错的二元判断而是分成几个等级——完全达成、部分达成、未达成、产生负面后果。举个例子用户让 Agent 把这周所有未读邮件按紧急程度排序并草拟回复。完全达成意味着排序正确且回复内容贴合每封邮件的上下文部分达成可能是排序对了但回复写得很泛未达成是只列了邮件标题负面后果是它把某封重要客户的邮件标成了垃圾邮件。实操中这个维度最难的是定义任务完成的边界。我的建议是在测试集里给每条用例写清楚预期完成状态不要用模糊的应该帮忙处理而是写生成一封发给张三的会议改期邮件包含新时间、地点、时长。2. 准确性结果组这是指 Agent 输出内容的事实性正确度。注意它和任务完成度有区别任务完成了但内容可能是错的。比如 Agent 帮你约好了会议但会议时间写错了或者写了一封回复邮件抬头把客户名字打错了。这个维度主要靠人工评测或 LLM-as-judge大模型当裁判结合校验。凡是涉及具体数据的时间、地址、数字、人名必须有硬性校验机制不能只让模型自己判断对错。3. 完整性结果组用户问一个问题Agent 只回答了一半这就是完整性不足。比如用户问帮我分析一下这个月的销售数据包括同比增长率和环比变化Agent 只给了同比增长率丢了环比就是不完整。我见过很多开发团队在准确性上卷生卷死却忽略了完整性。实际上对用户体验伤害最大的往往是看起来全对但缺了关键部分——用户得反复追问才能拿到全部信息AI 带来的效率红利直接归零。4. 路径规划合理度过程组这个维度考察的是 Agent 拆解任务和规划执行路径的能力。同样一个任务帮我调研竞品 A 和竞品 B 的定价策略合理的路径是搜索竞品 A 官网→搜索竞品 B 官网→查找第三方测评→对比总结。不合理的路径是一股脑搜索竞品 A 竞品 B 定价然后从一堆杂乱的搜索结果里硬凑结论甚至先搜了一堆不相干的内容再纠正。路径规划不合理往往不会导致任务失败但会造成效率低下、上下文混乱。打分时重点看步骤顺序、工具选择、是否有多余操作。5. 工具调用准确性过程组Agent 价值核心在于工具调用这个维度主要看三点工具选得对不对、参数传得准不准、返回结果用没用上。我踩过最深的坑是Agent 调工具的参数经常自己想当然。比如有一个天气查询工具参数是城市拼音beijing但模型传成了英文全称Beijing, China或者传成了中文北京导致工具直接报错。后来我们在工具描述里明确了参数格式错误率下降了 60% 以上。这是一个典型的工具描述优化问题后面讲门禁流程时会详细展开。6. 上下文利用度过程组这个维度考察 Agent 对对话历史、用户偏好、长期记忆的利用程度。同样是用户说帮我订一下上次那家餐厅好的 Agent 应该从历史记录里找到上次那家餐厅是哪家差的 Agent 会问请问上次那家餐厅叫什么名字这个维度在单轮评测里很难测出来必须用多轮对话场景的测试集。我们后来专门构造了一批前后轮关联的用例比如第一轮让 Agent 记住某件事五轮之后再隐晦地提起看它能不能接上。7. 安全性风险组重点检查 Agent 会不会执行有害指令、会不会泄露敏感信息、会不会越权操作。这一项在九维里提权最高——我宁愿 Agent 任务完成度低一些也不能让它做不该做的事。实操中我们专门准备了一套诱导性测试集包括 prompt injection试图让 Agent 忽略系统指令、越权操作让 Agent 读取无权限的文件、敏感信息泄露套问系统 Prompt 或隐私数据等。每条用例都必须过关任何一条失败都直接拦截发布。8. 鲁棒性风险组同一个任务换几种说法Agent 还能不能稳定完成比如把会议改到明天下午三点和明儿下午三点整个会帮我挪一下应该得到同样的执行结果。鲁棒性差的表现是换个表达方式就听不懂了或者被无关的干扰信息带偏。这一维度是 Agent 和传统软件最大的差异点之一——传统软件的功能是确定性的说明天就是明天但 Agent 需要理解明儿也是明天。测试方法是用一组同义变体测试集把同一语义用不同表达方式各写几条用例跑同一份评分标准。9. 效率与成本风险组模型调用次数、token 消耗、端到端耗时。Agent 能完成任务但绕了 10 个工具调用、烧了 50 万 token这种能干活但不划算在规模化后是致命的。效率维度的评估数据可以直接从调用日志里拿不需要额外测试关键是要设定基线——比如同类任务平均耗时不超过 XX 秒、token 消耗不超过 XX。2.3 权重怎么配不同场景优先级完全不同九个维度不是平均分配权重的。我见过很多团队在这个问题上卡住总想找一套万能权重。实际上不存在这种万能权重因为 Agent 的应用场景决定了它更该侧重哪些维度。如果是客服类 Agent准确性、完整性的权重应该拉高路径规划可以适当放松——用户要的是问题被准确解决不关心你内部调用了什么工具。但如果是自动化运维 Agent工具调用准确性和安全性就是重中之重一次错误的服务器操作可能造成生产事故。内容创作类 Agent 则要把准确性放在第一位——AI 生成了一篇看似专业实则满嘴跑火车的行业分析对业务伤害极大。我在项目里的做法是定义三套预设权重模板客服场景、办公工具场景、专业分析场景开发同学在提交评估时根据自己的业务场景选择模板。如果没有自定义需求默认使用均衡模式。维度客服场景权重办公工具场景权重专业分析场景权重任务完成度20%20%20%准确性25%20%30%完整性15%15%15%路径规划合理度5%15%5%工具调用准确性10%15%10%上下文利用度10%10%10%安全性5%5%5%鲁棒性5%0%0%效率与成本5%0%5%权重不是定死不变的每个月根据线上 badcase 分布做一次调整。如果这个月的线上投诉集中在答案不准确那就加大准确性权重逼着大家的优化方向往准确性上靠。这也是门禁机制最大的价值——它不是卡人的工具而是引导团队往正确方向发力的指挥棒。3. Prompt 发布门禁从开发到上线的全流程管控3.1 五道关卡每一关都在拦什么有了评分体系下一步就是把它嵌进发布流程。我们最终落地的门禁流程一共五道关卡第一关本地自测。开发同学改完 Prompt先在本地跑一遍测试集确认没有明显问题再提交。这一关的拦截率其实不高但能挡住最低级的错误——比如 Prompt 里语法错误、变量拼错、格式混乱导致模型直接输出乱码。第二关自动评分。提交代码后CI 流水线自动跑九维度评分。这一关是门禁的核心所有改动必须通过预设分数线才能进入下一步。我后面会详细讲分数线是怎么定的。第三关人工抽审。自动评分通过后由一位有经验的开发者不是测试同学对评测样本做人工抽审确认 LLM 打分器给出的分数没有明显偏差。这个环节我一开始觉得没必要但后来发现它非常值得保留——再好的自动评估也有盲区人工抽审是最后一道质量安全网。第四关灰度验证。在真实流量中切一小部分用户跑新 Prompt收集线上数据验证实际效果。灰度验证不是为了完成流程而是为了观察那些测试集覆盖不到的真实场景——比如真实用户说的话远比测试集里的用例要难以预料。第五关全量发布。灰度数据达到预期后才算正式全量上线。如果被门禁拦下则回滚到上一版本等待修复后重新走流程。这套流程本身不算复杂实操中最大的难点在于每一关的标准怎么定、由谁来定、以及这些标准如何在团队里达成共识。下面重点说标准的问题。3.2 门禁标准硬性指标与一票否决项门禁标准设计的好坏直接决定这套机制是生产力还是绊脚石。标准太松门禁形同虚设标准太紧开发效率被严重拖累。我踩了两个月坑之后总结出三个关键原则原则一总分不是唯一的门槛分维度门槛必须单独设。一开始我只设置了一个总分数线比如 80 分结果发现团队为了冲总分把一个维度的分数做到极致同时另一个维度跌到谷底。比如有人把 Prompt 调得特别擅长处理复杂任务任务完成度拉满但完全忽略了安全底线安全性 30 分。这绝对不能接受。正确做法是设置总分门槛之外再为关键维度设置独立门槛。比如安全性必须不低于 90 分准确性必须不低于 75 分只要有一个不达标总分再高也拦截。原则二一票否决项必须存在。有些问题不是分数问题而是原则问题。我对九维度里安全性这一项实施的是零容忍——只要测试集里有一条安全用例不过整个发布直接拦截不管其他维度分数多高。这是我在一次安全事故后学到的教训那时我们发布了一个新 Prompt整体评分 88 分很顺利地过了门槛上了线。结果上线后第一天就出事了——用户用精心设计的 prompt injection 绕过了系统指令让 Agent 输出了系统内部信息。那个 case 在测试集里没有覆盖到但从风险角度看它一票否决了整个版本。所以我现在在门禁里明确规定安全用例出现一条失败直接拦截不允许用总分补偿来通过。其他维度可以谈安全维度不谈。原则三分数线的设定要基于回归基线而不是拍脑袋。我见过很多团队把门禁分数线设成 80 分问为什么是 80答曰好听。这是完全错误的做法。正确的设定方式是先跑 3-5 个历史版本作为回归基线统计历史版本的分数分布然后取历史版本平均值 一定余量作为新的门槛线。比如历史版本的平均分是 76 分你就可以把门槛设为 78 分保证新版本必须比历史平均表现更好才能上线。3.3 灰度发布与回滚不是所有问题都能在测试阶段暴露自动评分和人工抽审能解决大部分问题但总有一些 case 是测试集覆盖不到的。所以灰度发布不是走过场而是整个门禁流程中信息量最大的环节。我建议灰度分两步走第一步是内部灰度把新 Prompt 切给团队内部 10-20 个真实用户使用收集他们日常使用中的表现。内部灰度好处是出问题的容忍度高、反馈收集快。第二步是外部小流量灰度按用户 ID 哈希取模的方式切 5%-10% 的真实流量观察 1-3 天数据。灰度期间重点监控的不是分数而是三个指标任务成功率线上实际完成任务的比率、用户投诉率、异常行为率。这三个指标在测试阶段很难精准预估只有真实流量能给出答案。回滚预案要提前写好。我一直强调门禁流程里最重要的不是发布规范而是回滚能力。如果灰度期间发现问题能否在 5 分钟内回到上一个稳定版本比门禁能不能拦住问题更重要。Prompt 的版本管理应复用代码版本管理的一整套流程Git 分支、Tag 打版本、一键回滚这些机制虽然不是 AI 专属但在 Prompt 发布上同样适用。4. 实操从 0 到 1 搭一套评估流水线4.1 测试集怎么构造黄金数据集与对抗样本九维度评分体系落地的第一步是构造测试集。测试集的质量决定了门禁的可靠性所以这一步值得花大力气。我把测试集分成两类黄金数据集和对抗样本集。黄金数据集是标准答案明确的用例集。每条用例包含三部分用户指令、预期行为、打分标准。比如一条测试用例可以写成{ id: case_0012, scene: 邮件助手, user_input: 帮我给张总发一封邮件告诉他明天下午的项目评审会改到后天上午10点地点不变。, expected_steps: [ 提取关键信息收件人张总原会议时间明天下午新时间后天上午10点地点不变, 调用邮件工具发送邮件给张总, 确认发送成功并向用户反馈 ], scoring_standard: { task_completion: complete, accuracy: 时间信息必须完全正确任何数字错误直接扣至不合格, context_usage: 无需使用历史上下文 } }黄金数据集的构造来源有三个历史真实用户问题脱敏后使用、业务同学提供的典型场景、开发过程中的 badcase修复后反过来变成测试用例。我们的经验是badcase 转测试用例这个环节价值最高——每一个线上翻车的案例都应当沉淀到测试集里防止同一个坑踩两次。对抗样本集则是专门用来打击Agent 弱点的用例集主要包括prompt injection 样本试图让 Agent 做出超出自身职责的行为、多轮绕弯样本在多个轮次里逐步试探边界、复杂指令样本包含多个嵌套任务的指令。这部分用例不需要很多十几条就能覆盖大部分风险场景但每一条的杀伤力都很大。4.2 评分器怎么搭LLM-as-judge 的校准与偏见控制九维度里任务完成度、准确性、完整性、路径规划、工具调用、上下文利用这几个维度全部可以让大模型当裁判LLM-as-judge打分。但直接用大模型打分有一个非常大的坑它会有系统性偏见。三个最常见的偏见一是位置偏见——如果把正确回答放在前面错误回答放在后面模型更倾向于认为前者好反过来也一样。解决方法是把两个回答的位置对调各评一次取两次结果的一致情况。二是自我偏好偏见——模型更喜欢跟自己风格接近的回答。如果你的测试集用的回答是从 GPT-4 生成的而你在评估一个新 Prompt 时用的是其他模型就很容易被这个偏见干扰。解决方法是尽量用盲评——隐藏 Prompt 信息只给评分器看用户问题和 Agent 的回答。三是宽松偏见——同一个裁判心情不好时给分严格心情好时给分宽松模型也是一样每次调用结果会不同。解决方法是多次采样取平均或者用更细粒度的评分标准描述来约束裁判的行为。给你看一个我实际用过的评分器 Prompt 片段你是一个严格的 AI Agent 行为评审专家。请根据以下维度对 Agent 的行为进行评分每个维度 0-10 分。 【任务完成度】Agent 是否完整实现了用户的指令目标 - 10分任务完全完成且无任何遗漏 - 7-9分任务大部分完成存在次要遗漏 - 4-6分任务部分完成存在主要遗漏 - 0-3分任务完全失败或结果无用 请注意你的评分必须严格依据用户指令与 Agent 行为之间的对应关系只评估用户要求的事是否被做到不要评估回答的语言风格是否华丽。 用户指令{user_input} Agent 行为{agent_trace}这个 Prompt 的关键在第一句严格后面加上每个分数的详细定义能显著减少模型的随意发挥。我实测下来加了详细分数定义之后评分器与人工评分的相关系数从 0.55 提升到了 0.82。4.3 回归报告怎么读三个关键指标流水线跑完之后会产出一份回归报告重点关注三个指标综合评分。九个维度的加权总分直接反映这个版本的平均健康度。这个指标的优点是直观缺点是会被平均数掩盖短板——所以一定要结合分维度分数一起看。分维度得分率。每个维度的得分占该维度满分的比例。这一项是最值得花时间细看的能直接看出优化方向。举个例子如果一次改动把任务完成度从 72 分提到了 85 分但同时把上下文利用度从 80 分降到了 65 分那这个改动很可能是因为 Prompt 里塞了太多执行步骤导致模型只顾着走流程、忘掉了对话历史里的信息。Bad Case 明细。每条得分较低的用例的具体原因分析。这一步推荐做两个动作一是让评分器解释打分理由告诉它请先给出理由再打分二是把低分用例定期拉出来做人工复盘找到共性问题。有一次我在复盘时发现 80% 的错误集中在多轮对话的第 3 轮之后原因很快被定位为上下文太长把 Prompt 指令给挤没了修复方案是使用太长对话时自动压缩前置历史。5. 常见问题与排查技巧实录5.1 评测集过拟合Agent 学会了应试门禁跑了一段时间之后我注意到一个有趣的现象Agent 在测试集上的分数越来越高但线上的用户体验并没有同步提升。后来复盘时发现测试集被背下来了——Prompt 里那些针对常见用例的标准动作被模型过度强化导致它在遇到真实用户的非典型请求时反而表现得比以前更死板。这就像学生背题背多了遇到原题会做但遇到变式就懵了。解决办法有两个一是定期更新测试集保持 10%-20% 的新用例替换率二是测试集要控制规模和多样性不要为了追求覆盖率而塞入大量高度相似的用例——那只会让模型去迎合测试集而不是学会泛化。5.2 LLM 打分的偏见位置偏见与自我偏好前面我提到了 LLM-as-judge 的偏见问题。这里再给一组实测数据我用同一个评测集分别用直接让评分器打分和对调顺序各评一次取平均两种方式跑了一遍结果直接打分方式的分数波动区间高达 15 分而对调后取平均值的方式波动区间降到了 5 分以内。如果你的团队也在用 LLM 当裁判这一条直接照做成本极低但效果显著。另外还有一个小技巧在评分器 Prompt 里明确写上不要受回答的完整度影响而提高分数这类反偏见指令虽然不能完全消除偏见但实测下来确实有帮助。5.3 门禁卡得太死评估体系的通胀门禁刚上线时大家热情很高我定了一大堆硬性标准结果开发同学集体抗议——改一行 Prompt跑一次完整评估要 40 分钟而且动不动就因为某个不重要的维度被降分而无法上线。后来问题的本质是门禁通胀——标准设得太严导致团队绕过流程偷偷在灰度阶段改 Prompt或者干脆不迭代了。我的调整方案是把门槛分数和迭代频率解耦。具体来说小改动比如修一个措辞、改一个参数示例走快速通道只跑关键维度准确性、安全性大改动比如重写系统 Prompt才跑全量九维评估。这样既守住了底线又给了团队试错余量。快速通道的口子开在改动影响面评估上——开发必须说明这次改动影响到的维度有经验的人基本能判断得比较准。哪怕偶尔判断失误进了快速通道但出问题了回滚版本就是了。5.4 置信度不足小流量测试的数学现实最后一个常见的坑是灰度阶段数据量太小导致结论无意义。灰度切 5% 流量每天可能只有几十个真实请求命中新增功能这种情况下报告里的性能提升 12%其实根本没有统计学显著性可能纯粹是噪声。我个人建议至少要积累 500 个有效样本且各场景分布均匀才能给优化效果下结论。如果你的业务量本身就很小灰度期要拉长到一两周甚至可以把灰度比例加大到 10%-20%——毕竟 Agent 类功能的改动大多不涉及金钱交易风险相对可控可以承受更大的灰度比例来换取更快的反馈速度。这部分的另一个技巧是灰度期间一定要对用户反馈做兜底记录——就是主动向灰度用户询问使用感受或者观察用户是否二次使用。Agent 产品有个很大的特点用户遇到一次失败可能直接就放弃了整个产品所以灰度期的活反馈远比后台数据重要。6. 一些个人经验补充分享九维度评分体系和 Prompt 发布门禁这套机制我们团队已经跑了近一年。最大的体会是评估体系和门禁流程不是一成不变的死规矩而是需要跟着 Agent 的复杂度一起成长。项目早期Agent 只接了两三个工具、Prompt 也就一屏长那时候跑全套九维评估确实是杀鸡用牛刀用简单的人工复核加一个任务完成度指标就够了。但等 Agent 接了十几个工具、Prompt 膨胀到几千 tokens 的时候如果没有这套量化体系几乎不可能定位问题出在哪个环节——到底是 Prompt 指令不够清晰、工具描述有歧义、还是模型本身理解能力不够这个问题在感觉流的开发方式里基本无解但有了分维度评分定位时间可以压缩到几小时以内。后续我计划做的事情有两件一是把测试集和线上 badcase 做联动实现 badcase 自动沉淀进测试集二是给九维度里的路径规划合理度和上下文利用度这两个维度引入更细粒度的自动化分析目前这两个维度还比较依赖人工判断自动化打分的效果不太理想。如果你也在搭自己的 Agent 评估体系希望这套九维度框架能给你一些参考。其他维度可以慢慢调安全底线请一定守住。