企业官网建设流程全解析

先说个我自己踩过的场景：Agent的Demo演示给老板、客户看，效果惊艳，能规划、能查资料、能调用工具，现场掌声一片。结果一进生产环境，用户问法稍微绕一点，它就答非所问；工具调用链一长，中间一步失效就全盘崩溃；上下文稍微长一点，它反而开始丢关键信息。这个时候你才会明白，Agent从“能在演示环境里跑通”到“能在生产环境里扛住”，中间差的不是一两个prompt调试，而是一整套评估体系。

这个评估体系不是简单拿几个测试用例跑一遍看看对不对，而是要把Agent的行为、链路、产出、成本全部量化，用数据说话。只有把它做扎实了，Agent迭代才不是靠感觉，上线才不是靠赌。这篇文章就从我实际搭建评估体系的经历出发，聊聊从Demo到生产这段“最后一公里”里，评估体系到底该怎么设计、怎么落地、怎么避坑。

1. Agent评估体系的核心思路拆解

1.1 Demo与生产之间的“失真”到底发生在哪

做过Agent的朋友应该都有感触：Demo环境里，Agent的表现基本是“可控的乐观”。因为这个阶段你喂给它的都是精心设计的用例，意图明确，资料充分，工具链路也相对短。而生产环境里，用户输入是无限多样的，可能有歧义、有口语化表达、有错别字，甚至故意刁难；工具服务不稳定，第三方接口随时可能超时或返回脏数据；业务数据分布也在变化，上周还好用的检索策略，下周可能就失灵了。

我后来反思了一下，Demo环境最大的问题不是“技术验证不够”，而是缺少了一个负反馈闭环。在Demo里，只要跑通就是成功；在生产里，跑通了但用户不满意，也是失败。Demo阶段关注的是“能不能调用工具、能不能完成任务”，而生产阶段关注的是“在大量不确定因素下，能不能稳定、准确、低成本地完成任务”。这两者的评估标准完全不同。

所以做评估体系的第一步不是去选工具，而是先接受一个现实：Agent的质量不是一个静态指标，而是多维度的复合结果，包括任务完成度、路径合理性、回复准确性、工具调用可靠性、时间消耗和成本开销。缺了任何一个维度，评估都是不完整的。

1.2 评估体系不是“测试”，而是“质量闭环”

一开始我犯过一个认知错误，把Agent评估当成了传统软件测试——写一批test cases，跑一遍，看通过率。这个做法对传统函数是有效的，但对Agent来说远远不够。原因有两点。

第一，Agent的输入输出不是纯函数式的。同一个用户问题，今天回答A，明天可能回答B，原因可能是模型版本变了、上下文窗口轮转不同、检索到的文档片段排序变了。用固定期望输出比对的方式，根本写不出断言。

第二，Agent的行为链路太长。一个任务可能要经历“理解意图-拆解步骤-调用工具-检索信息-生成回复”多个环节，任何一个环节出错，最终输出都会受影响。你是该在最终结果上评估，还是在每个环节上评估？答案是都要，而且要分层。

所以我的思路是：评估体系本质上是一个质量闭环，它应该包含三层能力——度量（Measure）、诊断（Diagnose）、回归（Guard）。度量阶段，定义指标、采集数据；诊断阶段，定位问题出在哪个环节、哪类场景；回归阶段，在每次迭代后跑一遍评估，防止新改动引入旧问题。数据回流到测试集和prompt里，再继续下一轮迭代。

2. Agent评估体系的四层设计

2.1 第一层：路径级评估——把Agent的每一步“行踪”摸清楚

做Agent评估，最容易忽略的就是过程。只盯着最终输出，你会发现很多问题被“糊”过去了。比如Agent明明调错了一个工具，但最后还是拼凑出了一个看起来还行的答案；或者它绕了一大圈，中间浪费了十来次模型调用，最后才找到正确结果。这些情况，只看最终答案根本发现不了。

路径级评估要关注的就是Agent每一步的行为轨迹。具体来说，我要看三件事。

一是工具调用的准确率。它决定该调“天气API”的时候是不是真的调了天气API，而不是调成了“日历API”；参数有没有传对，比如查询天气的城市、日期是否正确。

二是步骤拆解的顺序合理性。一个“帮我安排周三下午三点的产品评审会议，预订会议室并通知参会人”的任务，正常的路径应该是先查参会人忙闲、再订会议室、然后创建会议邀请、最后通知参会人。如果Agent先去通知参会人、再找会议室，顺序倒置，就算它最后也完成了任务，也会给用户带来困扰。

三是无效循环与死胡同的检测。这个在生产环境特别常见，Agent会陷入同一个错误里反复重试，比如调一个接口报了401，它不检查token是不是过期了，换个prompt再试一次，还是401，又试一次。这种情况在Demo里几乎不会出现，因为Demo的接口全是mock好的。

我在落地路径级评估时，用的是两步走方案：第一步，在Agent框架里加一个统一的trace埋点，把每次模型调用、工具调用、中间结果、耗时全部结构化记录下来；第二步，写一个路径校验器，用规则解析trace里的关键节点，用“合理路径模板”去比对实际路径。模板不用写很多，常见场景每个场景准备三五条最佳路径、一两条可接受的容错路径就够了。

这里补充一个实操细节：路径校验器不要全用规则去匹配，建议“规则为主，模型为辅”。规则负责检查硬性条件（工具名、参数类型、必填字段），模型负责判断顺序和语义合理性（比如“先查日程再订会议室”和“同时进行”是否可接受），这样既稳定又灵活。

2.2 第二层：状态级评估——用工具输出反推Agent的“理解程度”

路径级评估能告诉你Agent“做了哪些事”，但还不能告诉你它“做得对不对”。比如Agent调了一个“获取订单状态”的工具，工具返回了“订单已发货”，这是正确的调用，但如果用户问的是“我的订单什么时候到”，Agent只回复“已发货”就结束了，没给出预计送达时间，那么这个调用本身虽成功，但任务并没有真正完成。

状态级评估的做法，是把工具返回的结构化数据作为“中间状态”，再结合用户原始问题去判断“这个状态是否真正解答了用户的问题”。这个环节我完全交给LLM来判断，但给LLM设计了严格的评估模板，不是为了让它自由发挥，而是让它按照“证据→结论”的链条来打分。

具体评估模板，我会让裁判模型先输出三个字段：用户核心诉求、工具返回的关键证据、证据能否完全支撑诉求。如果证据不足，再输出缺少哪一类信息。最后再给一个0到5分的过程得分。这套模板跑下来，能非常有效地发现“工具调对了但任务没有完成到底”的情况。

状态级评估还有一个隐藏好处：它可以把“Agent的理解能力”和“Agent的执行能力”分开度量。理解能力看它是否选了正确的工具和参数，执行能力看它是否把工具返回的信息真正用到了最终答案里。这两个能力在后续调优时的优化手段完全不同，分开度量后，能少走很多弯路。

2.3 第三层：结果级评估——LLM-as-a-Judge的选型与部署

结果级评估是大家最熟悉的一层，就是直接对Agent的最终回答进行质量打分。早期我做这种评估，试过Rouge、BLEU、BERTScore这一套文本相似度指标，用下来总体感受是：文本相似度指标与用户体验的相关性非常弱。

原因其实不难理解。用户问“帮我查一下上海明天天气”，Agent回答“明天上海晴，23到28度，东南风3级”，和参考回答“上海明天最高28度最低23度，晴好天气，东南风3级”在字面上差别不小，但意思完全一样，语义等价。Rouge得分可能只有0.5，但用户满意度是100%。反过来，两个回答字面上高度相似，但一个多了一句话“建议带伞”，这个才真正影响体验。所以传统文本匹配指标，在开放式生成任务上基本失效。

最终我选了LLM-as-a-Judge（用大模型当裁判）作为结果级评估的主力方案。具体做法是：准备一个独立部署的裁判模型（可以是GPT-4级别的闭源模型，也可以是开源的Qwen2.5-72B这类模型），把用户问题、Agent回答、参考回答（如果有）一起喂给它，让它按照预设的评分卡输出维度得分、总分和判定理由。

需要特别注意的一点是，裁判模型最好和Agent模型不是同一个。如果Agent和Judge共享同一个模型，Judge很容易对Agent的“风格偏好”产生纵容，从而给出虚高的分数。我之前做过一次对比实验，用同一个模型又当选手又当裁判，平均分比用独立裁判模型要高出0.7分左右。所以哪怕成本高一点，也建议用独立模型。

评分维度我也调整了好几版，最终稳定在这五个维度：正确性（信息是否准确、有无幻觉）、完整性（是否覆盖用户所有诉求）、可操作性（用户能否直接照做）、语气与安全（是否专业、合规、无歧视性内容）、冗余度（有没有车轱辘话）。每个维度按5分制打分，再加上总分和一句总结性理由。

2.4 第四层：非功能性评估——成本、时延、稳定性

这一层是Demo阶段最容易忽略、生产环境最致命的。我见过太多Agent项目，在Demo里跑得好好的，上了生产发现每次问答要花5到8秒，用户早就走了；或者一次调用的token费用是预算的10倍，老板看完账单直接让项目下马。

非功能性评估我重点看四个指标。一是单轮时延，从用户发起请求到收到完整回复的总时间，P50、P90、P99三个分位都要记录，因为P50再好看，P99如果超过15秒，长尾用户照样会流失。二是调用成本，把模型token费用、工具调用费用分摊到每个任务上，按天和按版本分别统计。三是稳定性，连续跑N轮测试，统计超时、报错、解析失败的比例。四是上下文损耗，长对话场景下，Agent在多少轮之后开始出现“失忆”或关键信息遗漏。

这四项指标里，调用成本是最容易被低估的。Agent不是一个单次问答，而是一个有多次模型调用和工具调用的复合流程。如果Agent在一个任务里平均调用模型8次，即使单次价格很低，整体成本也会被放大很多倍。所以定量策略很重要：给每个Agent项目设定一个“单任务成本阈值”，超过阈值，要么优化prompt减少不必要的调用，要么换一个更小、更便宜的模型处理子步骤。我在实际项目里，通过给简单子任务换用小型模型，将单任务整体成本压低了约40%，效果非常明显。

3. LLM-as-a-Judge的工程化实践与调优

3.1 评分卡与评估Prompt的设计细节

Judge模型的Prompt设计，是整个评估体系里技术含量最高的一个环节。Prompt写得好不好，直接决定评估结果可不可信。我见过一些团队把评估Prompt写得很随意，两行字就让模型打分，打分结果在0到10之间波动剧烈，今天同一份测试集跑出7分，明天跑出4分，根本没法用。

经过多次迭代，我的评估Prompt固定成四段式结构。第一段，身份与任务的声明：“你是一名专业的Agent质量评测专家，请根据以下评分卡对Agent的回答进行客观打分”。第二段，评分维度的明细：每个维度单独一行，附上该维度的定义和打分锚点。例如“正确性：1分表示核心信息错误，3分表示部分信息准确但存在遗漏或错误，5分表示信息完全准确且无关键遗漏”。第三段，输入信息的分隔与标注：用XML格式清晰的标记用户问题、Agent回答、工具调用记录，避免信息粘连。第四段，输出格式要求：必须严格输出JSON对象，包含每个字段的得分和reason字段。

这里有个很细微但也非常重要的点：评分锚点必须描述到“行为”层面，而不是“感受”层面。不能写“5分：回答质量高”，要写“5分：回答中所有关键信息都有准确出处，且无任何与用户问题无关的扩展”。同样，3分的描述里要写明“有多少比例的信息是准确的”。把每个档位的行为描述清楚，能明显降低不同批次评测之间的浮动幅度。

3.2 四个Judge模型的典型坑与对策

Judge模型在实际运行中，我踩过并验证过的，有四个典型问题值得单独列出来。

第一个是序列位置偏见。Judge会对位置靠后的内容给出更高权重，尤其是当内容较长时。我的对策是，在多个测试用例中进行“AB交换”随机化处理：同一组对比，把Agent回答A和B的顺序互换着评估，取两次结果的平均值作为最终结论。如果没有条件做双向评估，至少要在结果字段里特别提示Judge“不要因为内容位置不同就改变打分”。

第二个是自增强偏差。Judge和Agent如果是同一个模型，或者同一个模型系列，Judge会倾向于给“与自己风格更接近”的回答更高分。这个我在前面提到过，解决方法是使用完全不同的模型家族，或者至少在评估结果中做人工抽检校准。

第三个是得分趋中。很多模型在不确定给多少分时，会倾向于给一个中间分比如3分，导致评估结果区分度很差。解决办法是把一些典型答案作为“锚点样本”放进Prompt中作为few-shot示例，例如“当回答完全跑题时，应给出1分，例如：……”，或者要求Judge先给出各维度证据再输出最终分，证据先行能显著减少趋中倾向。

第四个是指令过宽导致的幻觉评分。Judge在没有足够上下文时，容易脑补Agent没有说过的话。尤其当Agent的回答有引用了文档内容但省略了原文时，Judge会默认Agent说得对。对策是在评估Prompt中增加一个声明：“当某个信息没有被Agent明确提供时，该信息视为答错，不得自行补全”。这一条对幻觉检测尤其有效。

3.3 评估结果的可信度验证与校准

再好的Prompt，也不能保证Judge模型100%可靠。所以我会在评估流程里加一道“可信度验证”的工序。具体操作是定期从测试集里抽20到30条样本，请真实业务人员或领域专家自己对Agent回答打一次分，然后对比Judge的评分，计算相关系数（我一般用Spearman相关系数）和一致率。相关系数低于0.7，说明Judge的评估结果不能直接用，需要回头检查Prompt或更换Judge模型。

另外，我还会给每条评测记录加上一个“置信度”字段。这个置信度由Judge自己给出，是一个0到1的值，用来表达它对自己所打分数的确信程度。置信度低于0.4的样本，系统会自动标记为“待人工复核”，不会进入后续的分数汇总。这样做还有一个好处：它能很自然地识别出那些边界模糊、模型自己都拿不准的测试用例，而这些用例往往恰恰是最有价值的迭代素材。

4. 从评估集构建到上线回归的完整链路

4.1 评测集从哪里来：历史沉淀、分类归因、难例挖掘

构建评测集，是评估体系里看似简单但实际最花时间的部分。我一开始以为写个三五十条测试用例就够了，后来发现远远不够。Agent的应用场景往往很宽泛，市面上真实用户的问法又千奇百怪，评测集覆盖面不足，评估结果就容易“自我感觉良好”。

我的评测集构建来源有三个。第一个来源是历史对话沉淀，把线上日志里真实用户的query全部捞出来，做主题聚类和去重，挑出高频、高价值、高失败率的样本进入评测集。第二个来源是人为构造的“难例”，根据当前Agent的薄弱点，故意构造刁钻的输入，比如带错别字的query、语义歧义的query、多步骤嵌套指令、需要常识推理才能回答的问题等。第三个来源是回归补漏，每次生产中出现的bad case，修复之后立即加入评测集，确保同类问题不会复发。

在评测集的管理上，我做了拆分：按域划分（比如“订单查询域”“售后处理域”“产品推荐域”），每个域单独维护；并且把评测集拆成“核心回归集”和“候选扩展集”两部分。核心回归集每次版本迭代必跑，候选扩展集用来探索新的边界。核心回归集不建议频繁扩充，数量控制在每域30到50条，否则每次跑评测的成本和时间会吃不消；候选扩展集则可以随线上反馈不断累积，积累到一定量级后经过筛选并入核心回归集。

4.2 评估流水线如何接入CI/CD

评估体系要发挥作用，不能只靠开发人员手动在本地跑，它必须成为开发流程的一部分，在每次代码或配置变更时自动触发。我把这套流程接入了项目的CI流水线，一共有三个关键环节。

第一个环节是离线评估阶段。每次MR（合并请求）创建时，会在一个独立的环境中拉起一个新的Agent实例，跑一遍核心回归集，生成一份评估报告。报告里会显示各项指标与上一次基准（baseline）的对比，分数下降超过阈值（比如正确性下降超过0.3分）就视为“回归失败”，直接阻断合并。

第二个环节是线上小流量验证阶段。离线评估通过后，新版本会先部署到小流量环境，把真实流量的5%切给新版Agent，同时把线上日志的评估结果收集好后，与旧版Agent进行在线对比。这个环节有一件很重要的事：要有独立的“暗标”比较，就是同一个用户问题，同时让新旧两个Agent回答（但不是都发给用户），只拿旧版给用户，新版留作对比。这样才能拿到同分布数据下的性能对比，不会因为流量偏差导致误判。

第三个环节是发布后的持续监控阶段。发布完成后，不代表评估结束了。线上Agent每处理一条请求，都会自动采集结果进入评估队列，以天为粒度生成质量报表。一旦某个域的单日平均分低于阈值，会立刻触发告警，提醒开发人员去查看是数据分布变化了，还是模型本身出了问题。

4.3 一次真实的Agent上线复盘

说了这么多理论，放一个我最近一次上线的实际案例，给大家一个直观的概念。

这次上线的是一个面向内部员工的知识库问答Agent，核心能力是检索公司政策文档并回答员工问题。Demo阶段，我们发现Agent在公司网络环境下跑得很流畅，demo演示的30个用例正确率做到了90%以上，老板当时就拍板要往生产推。

推上生产后第一周，问题就暴露了。首先是真实员工的提问方式和我们Demo里的query差异太大，员工喜欢用很碎的口语，比如“年假能休几天来着”、“报销发票怎么搞”，Agent经常识别不了意图；其次是知识库里的文档格式五花八门，有PDF、有Word、有网页抓取来的文本，Agent在检索阶段经常抽到不相关的片段，导致回答质量大幅下降。

我们把线上第一周的数据全部捞回来做了二次标注，扒出了117个bad cases，进行归类后发现主要问题集中在三个域：语义匹配错误（31%）、信息遗漏（27%）、检索结果不相关（22%）。针对这三个问题，我们对检索策略做了优化，引入了向量检索与关键词检索的双通道融合，并给Agent增加了“当检索置信度不足时主动承认并反问用户”的行为。同时把这些问题样本全部补进评测集里。

第二次评估时，正确率从生产初期的68%提升到81%，但更让我满意的不是分数本身，而是每个分数背后都有明确的归因：我们知道提升来自哪一部分改动、哪些bad case被修复了、哪些还没覆盖。这种透明度，才是评估体系真正带来的价值。

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

5.1 评估体系落地中的高频问题速查

把我在不同Agent项目里踩过、以及被同事问过的高频问题整理成一个速查表，方便大家对照排查。

5.2 几个避免评估“自我感觉良好”的再补充

最后补充三个我后来才意识到的小技巧，专门用来防止评估体系本身变成一个“自我感觉良好”的摆设。

第一个是定期“金丝雀式”人工复核。就算Judge和置信度机制再完善，也要定期拿一批样本给真人看。我现在的节奏是每两周做一次人工抽样复核，每次抽20条，不只看分数对不对，还要看“评测标准本身还合不合适”。因为业务在变，用户的期望也在变，半年前觉得“能查到即可”的答案，现在可能觉得“还要给出建议才满意”。标准不跟着变，评估体系就会从“质检员”变成“段子手”。

第二个是刻意让评测集“过拟合”Detect出来。如果持续用同一批评测集迭代，模型和prompt很快会对评测集产生“越调越好但对真实场景变化无效”的过拟合。比如评测集里某个问题连续三次迭代都是满分，那它就不再提供信息量了。我会定期统计每个测试用例的历史得分，把连续多轮满分、且没有争议的样本“退居二线”，换成更有挑战性的难例。这样能让评测集永远处于“有压力”的状态。

第三个是双通道盲测。当你要在两个Agent版本之间做决策时，不要只看各自分数，要把新旧两个版本的输出随机打乱，让标注员（或Judge）进行AB对比，并记录“偏好”而非“绝对分”。偏好类问题的标注一致性通常会比打分高很多，而且能告诉你的不是“这两个版本大概谁强”，而是“强在哪个场景、哪个维度”，决策价值直接高一个量级。

6. 把评估体系变成Agent迭代的“指南针”

评估体系这东西，做着做着你会发现，它的价值不在于“打分”本身，而在于它逼着你想清楚：你做的这个Agent到底好在哪、坏在哪、下一步应该优化哪里。没有评估体系的Agent迭代，就像蒙着眼睛开车，开到沟里才知道方向错了；有了评估体系，每次改动都能看到指标在趋势上的变化，它会告诉你哪条路更值得继续走。

从我的实际经验看，一个评估体系的建立，真正难的不是技术选型，而是坚持把每一环做细：评测集是不是够贴近真实、Judge的评分准不准、回归的闸门该设多紧、线上数据有没有回流。这些琐碎的事情叠加在一起，才构成了从Demo到生产这段“最后一公里”里最扎实的那段路。

最后分享一个小技巧：如果你的Agent项目还没建立评估体系，别想着一步到位做很复杂的。先从“20条核心用例 + 一个粗略的LLM打分器”这种最小闭环开始，跑起来，再逐步加维度、加评测集、加流程。我见过太多团队因为一开始把评估体系设计得太重，最后维护不下去全盘放弃。小而精的闭环，比大而全的依赖表可靠得多。