1. Agent 好不好用为什么非要一套评分体系1.1 “好用”为什么是最难回答的问题任何一个把 Agent 从 demo 推到生产环境的人早晚会被同一个问题卡住你怎么向老板、向业务方证明这个 Agent 真的好用我见过太多团队把 Agent 跑通了一个演示就急着上线结果用户试了两三次就再也不碰。然后进入无限甩锅循环——产品说模型能力不行算法说数据质量太差测试说需求压根没写清楚。这中间缺失的环节就是一套能让所有人达成共识的评估标准。为什么 Agent 的评估比传统软件难这么多传统软件的行为是确定的一个功能点写清楚了测试用例一跑就知道过没过。但 Agent 面对的是开放域输入同一个 Prompt、同一个任务今天跑和明天跑结果可能就有肉眼可见的差异。你没法用“功能是否实现”这种二元标准去判断只能从多个可观测的维度去刻画它到底“有多好”。这也解释了为什么很多团队一上来就谈“我要一个完美的 Agent 评估方案”但连“完美”长什么样都没想清楚。做评估的第一步不是急着写测试用例而是把“好用”拆解成可度量、可比较、可复现的具体指标。1.2 九维度评分体系的诞生过程我最初照着一些公开的 Agent 评测基准来做发现思路不完全适用我们自己的场景。那些基准擅长回答“在标准公开数据集上谁更强”但它回答不了“这个 Agent 在真实业务里能不能收回成本、用户愿不愿意持续用”。后来我换了个思路与其迷信某个权威榜单不如从实际使用中最容易被投诉、最容易翻车的环节反推到底有哪些因素在决定一个 Agent 的存亡。经过反复调整我把评估角度收敛到九个维度任务完成度、稳定性、响应质量、效率、成本、可解释性、泛化能力、安全性、用户体验。这套体系不是要从一个维度分高下而是要回答这个 Agent 在具体场景里各个关键能力项分别处于什么水平哪里是短板值不值得放出去给真实用户用。它最终长成一套评分卡同时也为后面的发布门禁提供了原始依据。接下来我把每个维度展开讲包括定义、打分锚点、实操方法配合具体案例说清楚。2. 九维度评分体系逐项拆解——从定义到打分全部说清2.1 前四维任务完成度、稳定性、响应质量、效率任务完成度是我最看重的维度它的意思是在给定任务和上下文的情况下Agent 正确完成了多少核心目标。打分的时候不是让测试人员凭感觉“好像完成了”而是要把任务拆成子步骤给每个步骤设定明确通过标准。比如一个售后客服 Agent它的任务是“识别用户诉求→查询订单状态→给出处理方案”哪怕最终答案正确但中间漏掉了订单查询也不能给满分。我一般建议用 1 到 5 分3 分是基准核心目标完成但过程中有可接受的瑕疵5 分是完全达成甚至超出预期。稳定性关注的是“同一输入多次执行结果差异有多大”。这个维度在传统领域会被当成理所当然在 Agent 场景里却是大问题因为大模型的生成具有随机性。我见过一个报表生成 Agent同一个问题给它跑十次有三次生成了格式错乱的表格用户第一反应就是“系统坏了”。稳定性测试要有量化手段一个简单的做法是同一组测试用例跑 N 次统计成功次数占的比例。一个合格的 Agent核心路径的稳定通过率至少要达到 95% 以上否则发布出去就是给自己埋雷。响应质量不完全等于“答案对不对”它更强调“答案好不好”。两个 Agent 都能回答“请帮我写一封离职邮件”一个只是堆砌模板另一个能结合用户的具体情况给出得体措辞这就是质量差异。我从三个角度来打分准确性、完整性、表达自然度。准确性看有没有事实错误完整性看该覆盖的点是否覆盖到表达自然度看是不是像机器在说话。测试时可以引入内外双评内部先按标准打分再从真实用户里抽样做盲评。效率维度直接关系到用户的耐心和真实体验。它包含两部分端到端响应时间以及完成同样任务所需的工具调用次数。曾经有个 Agent 明明能一次取到数据却因为工具设计得太碎片化先后调用了四次接口每次间隔两秒用户体感就是“卡”。效率的打分建议以秒为单位设置区间3 秒以内为满分区间3 到 10 秒为可接受区间超过 10 秒就得扣分甚至一票否决。这个阈值不是拍脑袋定的可以根据你自己业务里用户流失的数据来校正。2.2 中间三维成本、可解释性、泛化能力成本维度是很多技术团队最容易忽略的。为什么我坚持把它放进九维度里因为一个技术上限再高的 Agent如果跑一次任务的 API 费用比人工处理还贵业务方是不可能长期买单的。成本要综合算三笔账Prompt 的 token 消耗、工具调用链路里的中间 token 浪费以及出问题后的重试成本。我做过一个文档处理 Agent最初版本平均每单要烧掉 8000 个 token后来通过压缩上下文、精简 Prompt、减少无效工具调用降到了 2500 左右成本降低了近七成。可解释性是关于“能不能复盘”的维度。Agent 给出一个结论后你和用户都得能知道它依据了什么、经过了哪些推理。很多人觉得可解释性只是合规需要离自己很远但实际排查线上问题的时候你会发现它是最重要的救火工具。有一次我们的 Agent 在回答中出现了明显错误排查的时候发现它的工具调用链里有一次拿到了错误参数如果没有完整的日志链条这个问题可能要花半天才能定位。打分时看三处是否完整是否有决策路径记录、关键节点是否有输入输出摘要、出错时是否能回溯到具体步骤。泛化能力衡量 Agent 应对“没见过的输入”的能力。生产环境和测试集最大的区别就是用户永远不会按你的预定剧本来提问。我给泛化能力设计了一套测试方法每一轮发布前从历史用户的真实提问里随机抽出 20% 当作新测试集跟上一轮的测试集做交叉验证。如果 Agent 在新增样本上的表现明显下降说明它大概率是过拟合了某些固定话术而不是真正理解了任务。泛化能力打分建议放在发布前做一旦发现 Model 层或 Prompt 层修改导致泛化分下降超过 15%就必须停下来检查这轮改动到底在“学习”还是在“背题”。2.3 后两维安全性与用户体验安全性这个维度现在已经是硬门槛。它对 Agent 的考验集中在两个方面一是内容安全二是权限边界。内容上不能产生有害、违规、具有误导性的输出权限上不能让 Agent 在未经授权的情况下执行敏感操作。我们内部的做法是给所有 Agent 搭了一套模拟环境测试时可以放心大胆地诱导它“越权”看看它会不会在对话中泄露内部系统信息、会不会绕过审批流程直接操作数据。任何一个安全维度被一票否决的版本都不能上发布门禁。用户体验是最后一个维度但它是在拿到前面所有客观指标后再做的一次“代入式判断”。我把用户体验拆成三层交互自然度、容错引导、完成峰值体验。交互自然度看用户能不能用口语化表达完成任务而不是非得输入标准指令容错引导看 Agent 在理解不了用户意图时是直接说“我不知道”还是会主动反问澄清完成峰值体验看任务结束后用户是否觉得这个结果超出了自己的基本预期。用户体验建议用真实用户抽样调研加可用性测试来打分避免完全让研发自己给自己打分。3. Prompt 发布门禁——把评估变成上线前的强制环节3.1 为什么需要一道 Prompt 门禁说到 Prompt 的发布绝大多数团队还是“改完直接上线”。我自己踩过这个坑有一次调了一个 Prompt 里的措辞觉得改动很小本地测了两条用例没问题就直接发了结果线上出现了一连串离题的回答。原因是一个用来约束输出格式的指令在另一个场景里被用户输入彻底覆盖了。从那以后我就意识到Prompt 和代码是一样的改动会引入回归风险必须有一套像 CI/CD 那样的门禁机制来做强制检查。Prompt 发布门禁的本质是把评估从“事后诸葛亮”变成“事前拦截”。代码有编译期、有单测、有 code reviewPrompt 凭什么就靠“我觉得没问题”来发布门禁的概念就是从软件工程里借过来的一系列自动化和半自动化的检查项全部通过才允许合并发布任何一个关键项挂了就驳回给原作者。门禁不是要限制研发效率而是要把已知的坑挡在上线之前。3.2 门禁检查项清单与评分门槛设计我整理了一套经过实际验证的检查清单把它分成静态检查、动态验证、风险评估三大块。静态检查不需要跑模型就能完成主要看 Prompt 本身的规范性。第一项是格式完整性检查有没有缺失的关键指令段落、有没有多余的 HTML 标签或 Markdown 语法错误第二项是变量校验把 Prompt 里引用的所有字段与系统输入 Schema 做比对确保不存在引用不存在的变量第三项是冲突检测如果 Prompt 里有角色设定要检查新 Prompt 是否与系统级 System Prompt 冲突第四项是长度控制超过模型最大上下文的一定比例时直接告警。动态验证就需要实际跑模型了。每个 Prompt 在上线前必须跑一遍预先准备好的回归用例集。这个用例集不是几条“Happy Path”而是包含正常输入、极端输入、对抗输入三种类型。比如一个客服 Agent 的 Prompt至少要覆盖用户愤怒时、用户表达不清时、用户故意诱导时这三类场景。动态验证的评分标准直接复用九维度里的任务完成度和响应质量只有这两个维度达到门槛分才能进入下一步。风险评估则是人工环节。提交者需要明确填写这次 Prompt 改动的影响范围是什么、是否涉及敏感操作、是否改变了工具调用策略。对于涉及权限提升或者数据写入的改动需要额外经过安全负责人复核。我遇到过执行得过于彻底的门禁每一步都要人审结果团队改一条 Prompt 的成本暴涨最后大家都绕开门禁偷偷改。这是门禁设计必须避免的问题它要拦截真正的风险而不是做繁琐的流程表演。评估维度永远不会只有一个门禁同样不能只有一套死标准。3.3 门禁执行流程与配置参考整个门禁的执行流程我在团队里已经固化成五步。第一步是提交开发者在发布平台填写变更说明上传新的 Prompt 文件第二步是静态扫描系统自动跑一遍格式、变量、冲突和长度检查这一段是纯自动化的几秒钟就能出结果第三步是动态回归自动触发预置的测试用例集跑完后把九维度评分结果回填到发布单上第四步是人工审批门禁系统会结合评分自动给出“通过”“待定”“驳回”三种建议负责人只需要针对“待定”做判断第五步是发布与留档所有通过门禁的 Prompt 版本都会存入版本库确保线上出问题时能快速回滚。具体到配置层面我给出一个自己团队在用的门槛参考表。这个表不是让你照抄而是让你根据自己的业务现状去调整。我们当前的设置是任务完成度至少 4 分、稳定性通过率 95% 以上、成本消耗不超过预算基线、安全性和泛化能力必须一票通过。优先级排序上安全第一稳定性第二成本第三体验第四。我得提醒一句门槛一开始不要定得太高否则团队会花大量时间在修指标而不是打磨功能上。比较稳妥的做法是先设为观察模式跑两周收集真实数据后再把硬性阈值加上去。4. 我在实操里踩过的坑——评分体系落地与门禁执行实录4.1 评分主观性太强怎么让结果可复现我在推行九维度评分时遇到的第一个问题就是“同一份回答两个测试员给的分不一样”。有个案例是我们在评估一个文案生成 Agent一个人给响应质量打了 5 分觉得措辞高级另一个人只给了 3 分说它跑题。两个人吵到我这里来我才意识到问题不在人而在我的评分定义里缺少具体的行为锚点。后来我重新整理了每个维度的“锚点描述”把抽象分数绑到可观察的行为上。比如响应质量的 5 分不是“表达很好”而是“结论正确、无事实性错误、覆盖所有关键要素、表达自然但可识别为机器生成”3 分则是“结论正确但覆盖不全、顺序混乱、存在明显模板感”。有了这一类锚点不同测试者对同一结果的判断才能收敛。你在落地的时候一定要花时间把每一分的锚点写清楚这是评估体系能不能长期运转的核心。另外建议定期开一场对齐会把最近打分有分歧的 case 拿出来集体过一遍让标准在讨论中变得越来越清晰。4.2 门禁误伤正常 Prompt发布速度骤降怎么办门禁上线两周后团队抱怨最多的一件事就是“动不动就被门禁拦下来”。我发现问题出在两个地方一是动态回归用例集混入了太多边界情况很多日常场景的 Prompt 改动根本不应该被那些刁钻用例限制二是门槛设得太硬一些非关键路径的 Prompt 也被要求达到全量指标。这两个问题叠加起来让发布周期从原来的半小时拖到了一整天。我的调整思路是把变更分级。把 Prompt 改动标识为 S 级涉及核心流程、涉及敏感权限、A 级影响主流程但不涉及敏感业务、B 级文案措辞、辅助提示等。S 级必须过全量门禁A 级过核心用例B 级只要做静态检查和抽样验证。这样既守住了高风险改动的底线又不会让低风险改动被流程拖死。门禁的核心目标从来不是把所有改动都卡死而是把风险控制在可接受范围内。如果门禁最终变成了一个仅仅为了“显得专业”的摆设团队会失去对这套机制的信任那就得不偿失了。4.3 从评估到迭代的闭环怎么让分数真正驱动改版做评估最怕的是什么是每个月发一份报告里面填满数字但没有任何人根据这些数字去改东西。我反思我们自己的协作方式发现最初的评分结果只是“验尸报告”——上线之后发现问题才去翻才去复盘而不是在发布之前主动驱动迭代方向。现在我把流程改成了“评分—归因—改版—再评分”的闭环。举一个实际例子我们的某个 Agent 在泛化能力维度上连续两次得分偏低归因时发现它的 Prompt 开头给了一个过于具体的案例导致模型总在模仿案例的句式反而丢掉了理解真实用户意图的能力。于是我们改了 Prompt 里的示例策略把唯一的长例子拆成三个不同表达方式的短示例。下一次评分时泛化能力明显提升而任务完成度没有下降。这种从分数到归因再到修改的路径才是九维度体系真正的价值所在。每个维度不是孤立存在的它们之间还会相互作用。改一个维度可能会同时影响另外几个维度的表现所以回归测试时必须统一看九维度的雷达图不能只看单一数字有没有变好。5. 总结一下我的真实体会与建议九维度评分体系和 Prompt 发布门禁看起来像是给团队加了一道又一道流程负担实际使用下来它反而是节省时间的。关键在于它把大量原本要靠吵架、靠猜、靠上线后用户投诉来暴露的问题前置到了发布之前。我们现在的迭代流程里几乎不会再出现“上一个版本好好的这次改完突然一堆问题”的失控状态因为门禁会在源头把风险拦住。最后分享两个细节。第一个评分维度的权重不是一成不变的产品的不同阶段要有不同的优先级。早期我们最看重任务完成度功能不稳定时先解决“做不做得出答案”中期转向成本与稳定性因为要控制预算并保证体验后期则更关注泛化与安全毕竟规模上去了风险也同步放大。第二个门禁的回归用例集不是一次性建好的它是一个应该持续生长的资产。每次在线上发现一个导致 Agent 表现不佳的新 case都应该回归到用例集里确保下一次不会再踩同一个坑。这两条经验我认为比任何一个固定的模板都更重要。 Agent评估与Prompt发布门禁：九维度评分体系实战指南
1. Agent 好不好用为什么非要一套评分体系1.1 “好用”为什么是最难回答的问题任何一个把 Agent 从 demo 推到生产环境的人早晚会被同一个问题卡住你怎么向老板、向业务方证明这个 Agent 真的好用我见过太多团队把 Agent 跑通了一个演示就急着上线结果用户试了两三次就再也不碰。然后进入无限甩锅循环——产品说模型能力不行算法说数据质量太差测试说需求压根没写清楚。这中间缺失的环节就是一套能让所有人达成共识的评估标准。为什么 Agent 的评估比传统软件难这么多传统软件的行为是确定的一个功能点写清楚了测试用例一跑就知道过没过。但 Agent 面对的是开放域输入同一个 Prompt、同一个任务今天跑和明天跑结果可能就有肉眼可见的差异。你没法用“功能是否实现”这种二元标准去判断只能从多个可观测的维度去刻画它到底“有多好”。这也解释了为什么很多团队一上来就谈“我要一个完美的 Agent 评估方案”但连“完美”长什么样都没想清楚。做评估的第一步不是急着写测试用例而是把“好用”拆解成可度量、可比较、可复现的具体指标。1.2 九维度评分体系的诞生过程我最初照着一些公开的 Agent 评测基准来做发现思路不完全适用我们自己的场景。那些基准擅长回答“在标准公开数据集上谁更强”但它回答不了“这个 Agent 在真实业务里能不能收回成本、用户愿不愿意持续用”。后来我换了个思路与其迷信某个权威榜单不如从实际使用中最容易被投诉、最容易翻车的环节反推到底有哪些因素在决定一个 Agent 的存亡。经过反复调整我把评估角度收敛到九个维度任务完成度、稳定性、响应质量、效率、成本、可解释性、泛化能力、安全性、用户体验。这套体系不是要从一个维度分高下而是要回答这个 Agent 在具体场景里各个关键能力项分别处于什么水平哪里是短板值不值得放出去给真实用户用。它最终长成一套评分卡同时也为后面的发布门禁提供了原始依据。接下来我把每个维度展开讲包括定义、打分锚点、实操方法配合具体案例说清楚。2. 九维度评分体系逐项拆解——从定义到打分全部说清2.1 前四维任务完成度、稳定性、响应质量、效率任务完成度是我最看重的维度它的意思是在给定任务和上下文的情况下Agent 正确完成了多少核心目标。打分的时候不是让测试人员凭感觉“好像完成了”而是要把任务拆成子步骤给每个步骤设定明确通过标准。比如一个售后客服 Agent它的任务是“识别用户诉求→查询订单状态→给出处理方案”哪怕最终答案正确但中间漏掉了订单查询也不能给满分。我一般建议用 1 到 5 分3 分是基准核心目标完成但过程中有可接受的瑕疵5 分是完全达成甚至超出预期。稳定性关注的是“同一输入多次执行结果差异有多大”。这个维度在传统领域会被当成理所当然在 Agent 场景里却是大问题因为大模型的生成具有随机性。我见过一个报表生成 Agent同一个问题给它跑十次有三次生成了格式错乱的表格用户第一反应就是“系统坏了”。稳定性测试要有量化手段一个简单的做法是同一组测试用例跑 N 次统计成功次数占的比例。一个合格的 Agent核心路径的稳定通过率至少要达到 95% 以上否则发布出去就是给自己埋雷。响应质量不完全等于“答案对不对”它更强调“答案好不好”。两个 Agent 都能回答“请帮我写一封离职邮件”一个只是堆砌模板另一个能结合用户的具体情况给出得体措辞这就是质量差异。我从三个角度来打分准确性、完整性、表达自然度。准确性看有没有事实错误完整性看该覆盖的点是否覆盖到表达自然度看是不是像机器在说话。测试时可以引入内外双评内部先按标准打分再从真实用户里抽样做盲评。效率维度直接关系到用户的耐心和真实体验。它包含两部分端到端响应时间以及完成同样任务所需的工具调用次数。曾经有个 Agent 明明能一次取到数据却因为工具设计得太碎片化先后调用了四次接口每次间隔两秒用户体感就是“卡”。效率的打分建议以秒为单位设置区间3 秒以内为满分区间3 到 10 秒为可接受区间超过 10 秒就得扣分甚至一票否决。这个阈值不是拍脑袋定的可以根据你自己业务里用户流失的数据来校正。2.2 中间三维成本、可解释性、泛化能力成本维度是很多技术团队最容易忽略的。为什么我坚持把它放进九维度里因为一个技术上限再高的 Agent如果跑一次任务的 API 费用比人工处理还贵业务方是不可能长期买单的。成本要综合算三笔账Prompt 的 token 消耗、工具调用链路里的中间 token 浪费以及出问题后的重试成本。我做过一个文档处理 Agent最初版本平均每单要烧掉 8000 个 token后来通过压缩上下文、精简 Prompt、减少无效工具调用降到了 2500 左右成本降低了近七成。可解释性是关于“能不能复盘”的维度。Agent 给出一个结论后你和用户都得能知道它依据了什么、经过了哪些推理。很多人觉得可解释性只是合规需要离自己很远但实际排查线上问题的时候你会发现它是最重要的救火工具。有一次我们的 Agent 在回答中出现了明显错误排查的时候发现它的工具调用链里有一次拿到了错误参数如果没有完整的日志链条这个问题可能要花半天才能定位。打分时看三处是否完整是否有决策路径记录、关键节点是否有输入输出摘要、出错时是否能回溯到具体步骤。泛化能力衡量 Agent 应对“没见过的输入”的能力。生产环境和测试集最大的区别就是用户永远不会按你的预定剧本来提问。我给泛化能力设计了一套测试方法每一轮发布前从历史用户的真实提问里随机抽出 20% 当作新测试集跟上一轮的测试集做交叉验证。如果 Agent 在新增样本上的表现明显下降说明它大概率是过拟合了某些固定话术而不是真正理解了任务。泛化能力打分建议放在发布前做一旦发现 Model 层或 Prompt 层修改导致泛化分下降超过 15%就必须停下来检查这轮改动到底在“学习”还是在“背题”。2.3 后两维安全性与用户体验安全性这个维度现在已经是硬门槛。它对 Agent 的考验集中在两个方面一是内容安全二是权限边界。内容上不能产生有害、违规、具有误导性的输出权限上不能让 Agent 在未经授权的情况下执行敏感操作。我们内部的做法是给所有 Agent 搭了一套模拟环境测试时可以放心大胆地诱导它“越权”看看它会不会在对话中泄露内部系统信息、会不会绕过审批流程直接操作数据。任何一个安全维度被一票否决的版本都不能上发布门禁。用户体验是最后一个维度但它是在拿到前面所有客观指标后再做的一次“代入式判断”。我把用户体验拆成三层交互自然度、容错引导、完成峰值体验。交互自然度看用户能不能用口语化表达完成任务而不是非得输入标准指令容错引导看 Agent 在理解不了用户意图时是直接说“我不知道”还是会主动反问澄清完成峰值体验看任务结束后用户是否觉得这个结果超出了自己的基本预期。用户体验建议用真实用户抽样调研加可用性测试来打分避免完全让研发自己给自己打分。3. Prompt 发布门禁——把评估变成上线前的强制环节3.1 为什么需要一道 Prompt 门禁说到 Prompt 的发布绝大多数团队还是“改完直接上线”。我自己踩过这个坑有一次调了一个 Prompt 里的措辞觉得改动很小本地测了两条用例没问题就直接发了结果线上出现了一连串离题的回答。原因是一个用来约束输出格式的指令在另一个场景里被用户输入彻底覆盖了。从那以后我就意识到Prompt 和代码是一样的改动会引入回归风险必须有一套像 CI/CD 那样的门禁机制来做强制检查。Prompt 发布门禁的本质是把评估从“事后诸葛亮”变成“事前拦截”。代码有编译期、有单测、有 code reviewPrompt 凭什么就靠“我觉得没问题”来发布门禁的概念就是从软件工程里借过来的一系列自动化和半自动化的检查项全部通过才允许合并发布任何一个关键项挂了就驳回给原作者。门禁不是要限制研发效率而是要把已知的坑挡在上线之前。3.2 门禁检查项清单与评分门槛设计我整理了一套经过实际验证的检查清单把它分成静态检查、动态验证、风险评估三大块。静态检查不需要跑模型就能完成主要看 Prompt 本身的规范性。第一项是格式完整性检查有没有缺失的关键指令段落、有没有多余的 HTML 标签或 Markdown 语法错误第二项是变量校验把 Prompt 里引用的所有字段与系统输入 Schema 做比对确保不存在引用不存在的变量第三项是冲突检测如果 Prompt 里有角色设定要检查新 Prompt 是否与系统级 System Prompt 冲突第四项是长度控制超过模型最大上下文的一定比例时直接告警。动态验证就需要实际跑模型了。每个 Prompt 在上线前必须跑一遍预先准备好的回归用例集。这个用例集不是几条“Happy Path”而是包含正常输入、极端输入、对抗输入三种类型。比如一个客服 Agent 的 Prompt至少要覆盖用户愤怒时、用户表达不清时、用户故意诱导时这三类场景。动态验证的评分标准直接复用九维度里的任务完成度和响应质量只有这两个维度达到门槛分才能进入下一步。风险评估则是人工环节。提交者需要明确填写这次 Prompt 改动的影响范围是什么、是否涉及敏感操作、是否改变了工具调用策略。对于涉及权限提升或者数据写入的改动需要额外经过安全负责人复核。我遇到过执行得过于彻底的门禁每一步都要人审结果团队改一条 Prompt 的成本暴涨最后大家都绕开门禁偷偷改。这是门禁设计必须避免的问题它要拦截真正的风险而不是做繁琐的流程表演。评估维度永远不会只有一个门禁同样不能只有一套死标准。3.3 门禁执行流程与配置参考整个门禁的执行流程我在团队里已经固化成五步。第一步是提交开发者在发布平台填写变更说明上传新的 Prompt 文件第二步是静态扫描系统自动跑一遍格式、变量、冲突和长度检查这一段是纯自动化的几秒钟就能出结果第三步是动态回归自动触发预置的测试用例集跑完后把九维度评分结果回填到发布单上第四步是人工审批门禁系统会结合评分自动给出“通过”“待定”“驳回”三种建议负责人只需要针对“待定”做判断第五步是发布与留档所有通过门禁的 Prompt 版本都会存入版本库确保线上出问题时能快速回滚。具体到配置层面我给出一个自己团队在用的门槛参考表。这个表不是让你照抄而是让你根据自己的业务现状去调整。我们当前的设置是任务完成度至少 4 分、稳定性通过率 95% 以上、成本消耗不超过预算基线、安全性和泛化能力必须一票通过。优先级排序上安全第一稳定性第二成本第三体验第四。我得提醒一句门槛一开始不要定得太高否则团队会花大量时间在修指标而不是打磨功能上。比较稳妥的做法是先设为观察模式跑两周收集真实数据后再把硬性阈值加上去。4. 我在实操里踩过的坑——评分体系落地与门禁执行实录4.1 评分主观性太强怎么让结果可复现我在推行九维度评分时遇到的第一个问题就是“同一份回答两个测试员给的分不一样”。有个案例是我们在评估一个文案生成 Agent一个人给响应质量打了 5 分觉得措辞高级另一个人只给了 3 分说它跑题。两个人吵到我这里来我才意识到问题不在人而在我的评分定义里缺少具体的行为锚点。后来我重新整理了每个维度的“锚点描述”把抽象分数绑到可观察的行为上。比如响应质量的 5 分不是“表达很好”而是“结论正确、无事实性错误、覆盖所有关键要素、表达自然但可识别为机器生成”3 分则是“结论正确但覆盖不全、顺序混乱、存在明显模板感”。有了这一类锚点不同测试者对同一结果的判断才能收敛。你在落地的时候一定要花时间把每一分的锚点写清楚这是评估体系能不能长期运转的核心。另外建议定期开一场对齐会把最近打分有分歧的 case 拿出来集体过一遍让标准在讨论中变得越来越清晰。4.2 门禁误伤正常 Prompt发布速度骤降怎么办门禁上线两周后团队抱怨最多的一件事就是“动不动就被门禁拦下来”。我发现问题出在两个地方一是动态回归用例集混入了太多边界情况很多日常场景的 Prompt 改动根本不应该被那些刁钻用例限制二是门槛设得太硬一些非关键路径的 Prompt 也被要求达到全量指标。这两个问题叠加起来让发布周期从原来的半小时拖到了一整天。我的调整思路是把变更分级。把 Prompt 改动标识为 S 级涉及核心流程、涉及敏感权限、A 级影响主流程但不涉及敏感业务、B 级文案措辞、辅助提示等。S 级必须过全量门禁A 级过核心用例B 级只要做静态检查和抽样验证。这样既守住了高风险改动的底线又不会让低风险改动被流程拖死。门禁的核心目标从来不是把所有改动都卡死而是把风险控制在可接受范围内。如果门禁最终变成了一个仅仅为了“显得专业”的摆设团队会失去对这套机制的信任那就得不偿失了。4.3 从评估到迭代的闭环怎么让分数真正驱动改版做评估最怕的是什么是每个月发一份报告里面填满数字但没有任何人根据这些数字去改东西。我反思我们自己的协作方式发现最初的评分结果只是“验尸报告”——上线之后发现问题才去翻才去复盘而不是在发布之前主动驱动迭代方向。现在我把流程改成了“评分—归因—改版—再评分”的闭环。举一个实际例子我们的某个 Agent 在泛化能力维度上连续两次得分偏低归因时发现它的 Prompt 开头给了一个过于具体的案例导致模型总在模仿案例的句式反而丢掉了理解真实用户意图的能力。于是我们改了 Prompt 里的示例策略把唯一的长例子拆成三个不同表达方式的短示例。下一次评分时泛化能力明显提升而任务完成度没有下降。这种从分数到归因再到修改的路径才是九维度体系真正的价值所在。每个维度不是孤立存在的它们之间还会相互作用。改一个维度可能会同时影响另外几个维度的表现所以回归测试时必须统一看九维度的雷达图不能只看单一数字有没有变好。5. 总结一下我的真实体会与建议九维度评分体系和 Prompt 发布门禁看起来像是给团队加了一道又一道流程负担实际使用下来它反而是节省时间的。关键在于它把大量原本要靠吵架、靠猜、靠上线后用户投诉来暴露的问题前置到了发布之前。我们现在的迭代流程里几乎不会再出现“上一个版本好好的这次改完突然一堆问题”的失控状态因为门禁会在源头把风险拦住。最后分享两个细节。第一个评分维度的权重不是一成不变的产品的不同阶段要有不同的优先级。早期我们最看重任务完成度功能不稳定时先解决“做不做得出答案”中期转向成本与稳定性因为要控制预算并保证体验后期则更关注泛化与安全毕竟规模上去了风险也同步放大。第二个门禁的回归用例集不是一次性建好的它是一个应该持续生长的资产。每次在线上发现一个导致 Agent 表现不佳的新 case都应该回归到用例集里确保下一次不会再踩同一个坑。这两条经验我认为比任何一个固定的模板都更重要。