企业官网建设流程全解析

一、核心观点

Agent 产品和传统软件不同，它不仅生成结果存在不确定性，执行过程也存在不确定性。

这种不确定性可能来自：

• 模型推理的不稳定
• 用户输入的不完整
• 多轮上下文的漂移
• 工具调用的失败
• 外部 API 状态变化
• 检索结果的波动
• 业务规则和用户约束的复杂性

因此，评估一个 Agent 产品，不能只看单一的“准确率”，也不能只看最终回答是否看起来合理。

Agent 本质上是一个包含：

• 感知和理解
• 任务规划
• 记忆管理
• 工具调用
• 执行反馈
• 状态管理
• 安全控制

在内的复合系统。

所以，评估 Agent 时，既要看它有没有把事办成，也要看它是怎么把事办成的，还要看整个系统是否稳定、可信、可控、可用。

可以从三个层面搭建完整评估体系：

1. 业务结果层
2. 过程质量层
3. 系统底盘层

二、评估体系：三个层面

1. 业务结果层：先看“有没有把事办成”

这是最直观的一层，核心问题是：

Agent 有没有真正完成用户任务。

这里不能只看流程是否结束，还要看最终结果是否满足用户的真实目标、约束条件和偏好。

比如一个订票 Agent，不能只看它有没有完成下单，还要看它是否订对了时间、地点、价格区间、舱位偏好和乘客信息。

1）任务完成率

任务完成率是最核心的业务指标。

• 它衡量的是：用户提出一个任务后，Agent 最终是否成功完成。

  例如：

  • 订票 Agent 是否完成下单
  • 客服 Agent 是否解决用户问题
  • 数据分析 Agent 是否产出正确报表
  • 代码 Agent 是否完成可运行的代码修改
  • 办公 Agent 是否成功生成并发送文档

  但这里要注意，任务完成率不是简单地看 Agent 有没有“给出结果”，而是看结果是否真正满足任务目标。

  比如：

  • 用户要订明天上午的票，Agent 订成了下午，不能算成功
  • 用户要查询 A 项目的数据，Agent 查成了 B 项目，不能算成功
  • 用户要生成一份可提交的报告，Agent 只给了一个大纲，也不能算完全成功

  所以，任务完成率需要结合具体业务定义清楚“成功”的标准。

2）任务完成效率

• 不仅要看是否完成，还要看完成得是否高效。

  常见指标包括：

  • 平均对话轮次
  • 平均任务时长
  • 首次成功率
  • 平均返工次数
  • 平均确认次数
  • 平均工具调用次数

  如果一个 Agent 需要反复确认七八轮才能理解用户意图，即使最终完成任务，用户体验也会很差。

  更理想的情况是：

  • 简单任务快速完成
  • 复杂任务合理追问
  • 不该追问时不反复打扰用户
  • 信息不足时能够精准补问
  • 执行失败时能够快速恢复

  所以，任务完成效率本质上是在评估 Agent 的交互成本和执行效率。

3）用户满意度

任务完成不等于用户满意。

• 有些 Agent 从系统视角看完成了任务，但用户仍然不满意。

  例如：

  • 结果是对的，但解释不清楚
  • 任务完成了，但过程太慢
  • 方案可行，但没有考虑用户偏好
  • 回答很完整，但用户只想要一个简短结论
  • Agent 频繁追问，打断用户体验

  因此，除了任务完成率，还需要看用户侧反馈。

  常见指标包括：

  • 点赞率
  • 点踩率
  • 用户评分
  • 投诉率
  • 复用率
  • 留存率
  • 人工接管率

  其中，人工接管率非常重要。

  如果大量任务最后都需要人工介入，说明 Agent 还没有真正承担核心工作，只是在前面做了一层交互包装。

4）投入产出比 ROI

• 从商业价值视角，还需要评估 Agent 是否真的值得投入。

  常见成本包括：

  • 模型调用成本
  • token 消耗成本
  • 工具调用成本
  • 服务器资源成本
  • 人工兜底成本
  • 标注和评估成本
  • 运营和维护成本

  常见收益包括：

  • 节省人工处理时间
  • 降低客服或运营成本
  • 提高任务处理效率
  • 提升用户转化率
  • 提升用户留存
  • 提高业务自动化率

  因此，ROI 不能只看 Agent “能不能做”，还要看它“值不值得做”。

  一个 Agent 如果效果不错，但单次任务成本过高、延迟过长、维护成本很大，也未必具备规模化落地价值。

2. 过程质量层：看 Agent 是“怎么把事做成的”

业务结果层看的是最终结果，过程质量层看的是中间决策。

这一层关注的是 Agent 的决策过程质量，也就是它在理解需求、拆解任务、选择工具、处理异常和修正路径时是否合理。

对于简单问答类产品，可能只看最终答案就够了。

但对于 Agent 产品，尤其是涉及工具调用、数据库查询、代码执行、订单处理、工作流自动化的场景，只看最终结果是不够的。

因为同样完成任务，路径可能完全不同。

一个好的 Agent 应该不仅能完成任务，还应该以合理、稳定、可控的方式完成任务。

1）需求理解质量

需求理解质量关注的是：

Agent 是否真正理解了用户想做什么。

• 它不只是传统意义上的“意图识别准确率”，还包括对用户目标、约束条件、偏好信息、上下文依赖和缺失信息的理解。

  • 实现方法：

    https://blog.csdn.net/qq_65800683/article/details/160548814

  例如，用户说：

  帮我订一张明天去上海的票，别太晚，价格别太贵。

  Agent 需要理解的不只是“订票”这个意图，还包括：

  • 出发地可能需要确认
  • “明天”需要转成具体日期
  • “别太晚”需要理解为时间偏好
  • “价格别太贵”需要转成预算约束
  • 如果缺少身份证、乘客、车次等信息，需要合理追问

  好的 Agent 不应该机械执行，也不应该过度追问，而是要判断哪些信息可以从上下文继承，哪些信息必须向用户确认。

  常见评估点包括：

  • 是否正确识别用户目标
  • 是否正确识别约束条件
  • 是否正确利用上下文
  • 是否发现关键信息缺失
  • 是否在必要时主动追问
  • 是否避免无意义追问

2）任务规划质量

任务规划质量关注的是：

Agent 是否能把复杂任务拆成合理步骤。

• 对于长链路任务，不能只看最终结果，还要看中间路径是否合理。

  例如，用户说：

  帮我分析这个月销售下降的原因，并整理成一页汇报。

  一个合理的 Agent 可能需要：

  1. 明确分析对象和时间范围
  2. 获取销售数据
  3. 对比历史数据
  4. 按地区、渠道、产品拆解变化
  5. 找出主要下降因素
  6. 生成结论
  7. 整理成汇报格式

  评估规划质量时，可以看：

  • 是否能把复杂任务拆成清晰步骤
  • 步骤顺序是否合理
  • 是否存在明显遗漏
  • 是否走了不必要的弯路
  • 是否重复执行同类步骤
  • 信息不足时是否会补问
  • 执行失败时是否能调整路径
  • 规划是否可执行、可验证、可恢复

  这里通常会建立一套黄金测试集，覆盖简单任务、复杂任务、异常任务、多轮任务和边界 case，专门观察 Agent 在不同场景下的规划能力。

3）工具调用质量

工具调用质量关注的是：

Agent 是否在正确的时机，用正确的参数，调用正确的工具。

• Agent 和普通 Chatbot 的一个重要区别，就是它不只是回答问题，还会调用外部能力完成任务。

  这些外部能力可能包括：

  • 数据库查询
  • 搜索引擎
  • 企业知识库
  • 订单系统
  • 支付系统
  • 代码执行环境
  • 第三方 API
  • 内部业务系统

  因此，工具调用是 Agent 评估中非常关键的一环。

  常见问题包括：

  • 调错工具
  • 漏调工具
  • 不该调用时乱调用
  • 参数传错
  • 调用顺序错误
  • 没有正确解析工具返回结果
  • 工具失败后没有重试或降级
  • 工具返回异常时继续编造结果

  工具调用质量可以拆成几个指标：

  • 工具选择准确率
  • 参数填充准确率
  • 调用时机合理性
  • 调用顺序合理性
  • 工具结果解析准确率
  • 工具失败恢复率
  • 越权调用拦截率

  如果这部分经常出问题，可能是 Prompt 设计、工具描述、参数 schema、模型理解能力、编排策略或工具本身的稳定性存在问题。

4）结果校验质量

• 很多 Agent 不是一次生成答案就结束，而是需要对结果进行校验。

  例如：

  • 数据分析结果是否和原始数据一致
  • 代码是否能运行
  • SQL 是否能执行
  • 订单金额是否正确
  • 报告内容是否符合用户要求
  • 工具返回结果是否被正确引用

  如果没有结果校验，Agent 很容易出现“看起来完成了，实际上错了”的情况。

  评估结果校验质量时，可以看：

  • 是否检查关键结果
  • 是否验证工具返回
  • 是否发现明显冲突
  • 是否能识别不确定性
  • 是否会在必要时向用户说明限制
  • 是否避免把未验证内容包装成确定结论

  对于高风险任务，结果校验尤其重要。

  比如金融、医疗、法律、合同、权限操作、支付、订单变更等场景，不能只依赖模型自信地生成结论，而要有规则、工具或人工审核机制兜底。

3. 系统底盘层：看 Agent 是否稳定、可信、可控、可用

这一层关注的是 Agent 系统的底层能力。

它不仅取决于模型本身，也取决于：

• Prompt 设计
• 上下文策略
• 记忆系统
• RAG 检索质量
• 工具稳定性
• 后端编排
• 权限系统
• 安全策略
• 监控和降级机制

所以，这一层不应该简单理解为“LLM 基础能力”，而应该理解为“Agent 系统底盘能力”。

1）事实正确性与幻觉率

• 幻觉率指的是 Agent 是否会输出错误但听起来很专业的内容。

  这在以下场景中特别重要：

  • 知识问答
  • 客服支持
  • 数据分析
  • 决策辅助
  • 法律合同
  • 医疗健康
  • 金融建议
  • 技术排障

  评估时需要关注：

  • 是否编造事实
  • 是否编造引用来源
  • 是否错误解释工具结果
  • 是否把不确定内容说成确定结论
  • 是否在不知道时承认不知道
  • 是否能够基于知识库或工具结果回答

  更准确地说，不能只看“幻觉率”，还要看“事实正确率”和“可溯源性”。

  如果一个 Agent 能给出答案，但无法说明来源，或者来源和结论对不上，在严肃业务场景中也很难被信任。

2）安全性

• 安全性关注的是 Agent 是否能在风险场景中保持边界。

  包括：

  • 是否会输出违规内容
  • 是否会泄露敏感信息
  • 是否会执行越权操作
  • 是否会被 Prompt Injection 诱导
  • 是否会绕过权限系统
  • 是否会在高风险场景中给出不当建议
  • 是否会错误处理用户隐私数据

  对于具备工具调用能力的 Agent，安全性比普通问答产品更重要。

  因为普通 Chatbot 的风险主要是“说错”，而 Agent 的风险可能是“做错”。

  例如：

  • 错误删除数据
  • 错误发送邮件
  • 错误修改订单
  • 错误调用支付接口
  • 泄露内部文档
  • 把用户隐私传给不该调用的工具

  所以，安全评估不能只看内容安全，还要看权限控制、操作边界、工具调用白名单、敏感操作确认机制和审计日志。

3）鲁棒性

• 鲁棒性关注的是 Agent 在异常输入、模糊表达、边界场景下是否还能保持稳定。

  典型场景包括：

  • 用户表达不完整
  • 用户需求前后矛盾
  • 用户中途改变目标
  • 上下文很长
  • 工具返回异常
  • API 超时
  • 检索结果为空
  • 输入中包含噪声或误导信息
  • 多轮对话中出现上下文冲突

  好的 Agent 不应该在这些情况下直接崩溃、胡编或者无限循环。

  它应该能够：

  • 主动澄清
  • 给出合理假设
  • 说明不确定性
  • 进行降级处理
  • 重新规划路径
  • 请求用户补充信息
  • 在无法完成时明确说明原因

  常见指标包括：

  • 异常任务成功率
  • 工具失败恢复率
  • 长上下文一致性
  • 多轮对话一致性
  • 边界 case 通过率
  • 失败后可恢复率

4）响应延迟与系统性能

• Agent 通常涉及多轮推理和多次工具调用，因此响应延迟非常关键。

  重点指标包括：

  • 首次响应时间
  • 总任务耗时
  • P95 / P99 延迟
  • 工具调用链路耗时
  • 模型推理耗时
  • 队列等待时间
  • 超时率
  • 失败率

  如果响应太慢，用户往往不会持续使用。

  但延迟也不能单独看。

  有些复杂任务天然需要更长时间，比如：

  • 生成长报告
  • 分析大量数据
  • 执行多步骤工作流
  • 调用多个外部系统

  所以，关键不是所有任务都追求极低延迟，而是要区分任务类型：

  • 简单任务要快
  • 复杂任务要透明
  • 长任务要有进度反馈
  • 失败任务要能及时中止或恢复

5）成本控制

• Agent 系统的成本通常比普通 Chatbot 更复杂。

  成本来源包括：

  • 模型调用成本
  • token 消耗
  • 多轮推理成本
  • 工具调用成本
  • 向量检索成本
  • 存储成本
  • 人工审核成本
  • 失败重试成本
  • 日志和监控成本

  评估时需要关注：

  • 单次任务平均成本
  • 单用户平均成本
  • 单成功任务成本
  • 不同模型路由下的成本差异
  • 小模型和大模型的使用比例
  • 缓存命中率
  • 重复调用率

  一个 Agent 是否能规模化，很多时候不是看 demo 效果，而是看真实流量下的成本结构是否健康。

6）可观测性

Agent 评估还有一个很容易被忽略的点：可观测性。

• 如果系统只记录最终回答，而不记录中间过程，就很难定位问题。

  一个可评估、可优化的 Agent 系统，应该记录：

  • 用户原始输入
  • 模型中间推理或规划结果
  • 工具调用记录
  • 工具入参和出参
  • 检索命中文档
  • 上下文拼接内容
  • 失败原因
  • 重试记录
  • 权限校验结果
  • 最终输出
  • 用户反馈

  这样当任务失败时，才能判断问题到底出在：

  • 模型理解
  • Prompt
  • 规划链路
  • 工具调用
  • 知识库
  • 上下文策略
  • 权限系统
  • 外部接口
  • 产品交互

  没有可观测性，就很难形成真正的评估闭环。

三、具体评估方法：离线评估 + 在线评估结合

Agent 评估不能只依赖单一方法。

更合理的做法是：

• 离线评估看版本质量
• 在线评估看真实表现
• 自动化评估提高效率
• 人工抽检保证可信度
• 用户反馈提供真实信号

1. 离线评估

• 离线评估通常发生在上线前、版本迭代前或模型 / Prompt / 工具链变更后。

  常见方式包括：

  • 黄金测试集
  • 回归测试集
  • 对抗测试集
  • 多轮对话测试集
  • 工具调用测试集
  • 异常场景测试集
  • 仿真用户任务

  黄金测试集用于评估核心能力。

  回归测试集用于确保新版本没有把旧能力改坏。

  对抗测试集用于测试边界情况、安全风险和 Prompt Injection。

  工具调用测试集用于验证 Agent 是否能正确选择工具、填写参数、处理结果和恢复异常。

  离线评估的优势是可控、可重复、适合版本对比。

  但它的问题是：测试集再完整，也很难完全覆盖真实用户的复杂表达和真实业务环境。

2. 在线评估

• 在线评估关注 Agent 在真实用户环境中的表现。

  常见指标包括：

  • 真实任务完成率
  • 用户满意度
  • 点赞 / 点踩率
  • 投诉率
  • 留存率
  • 复用率
  • 人工接管率
  • 任务中断率
  • 平均任务时长
  • 平均成本
  • 线上错误率

  在线评估更接近真实业务价值，但也更复杂。

  因为线上数据会受到很多因素影响，比如：

  • 用户表达方式不同
  • 任务难度不同
  • 流量来源不同
  • 用户预期不同
  • 外部系统状态不同
  • 业务规则变化

  因此，在线评估通常要结合分层分析和 A/B 测试，不能只看整体平均值。

  例如，要分别看：

  • 新用户和老用户
  • 简单任务和复杂任务
  • 高价值用户和普通用户
  • 不同入口来源
  • 不同业务场景
  • 不同模型版本

  这样才能判断问题到底来自 Agent 本身，还是来自用户群体、任务类型或业务环境变化。

3. LLM as a Judge

在实际工作中，不可能完全依赖人工逐条评估，因为成本太高、效率太低。

所以更常见的做法是使用LLM as a Judge，也就是用一个能力更强或更稳定的模型，对 Agent 输出进行自动化评分。

通常会先定义一套明确的评分标准，例如：

• 是否完成任务
• 是否理解用户意图
• 是否遵守用户约束
• 是否调用正确工具
• 参数是否正确
• 是否存在幻觉
• 是否有安全风险
• 回答是否清晰、自然、可执行
• 是否需要人工接管

然后让评估模型根据标准打分，并给出原因。

这种方式适合：

• 大规模回归测试
• 多版本对比
• Prompt 迭代评估
• 模型选型评估
• 失败样本初筛
• 线上日志抽样分析

但 LLM as a Judge 不能完全替代人工评估。

它也会存在问题，例如：

• 评分不稳定
• 容易受表达风格影响
• 对事实正确性判断不一定可靠
• 对复杂业务规则不一定敏感
• 对长链路任务可能漏看关键细节
• 可能偏好更长、更像样的回答

所以，LLM as a Judge 更适合做大规模初筛和趋势对比，而不是作为唯一评估标准。

在高风险、强规则、强事实校验的场景中，仍然需要结合人工评估、规则校验和真实工具验证。

4. 人工抽检校准

为了防止自动评估出现偏差，不能只依赖模型打分。

常见做法是：

• 每周人工抽检一部分样本
• 重点抽检差评样本和高风险样本
• 对比人工评分和模型评分
• 做一致性校验
• 分析评分偏差
• 持续修正规则和评分标准

人工抽检的目的不是替代自动化评估，而是校准自动化评估。

如果发现评估模型经常误判，就要调整：

• 评分 rubric
• 评估 prompt
• 样本分层方式
• 自动化指标权重
• 人工标注规范

这样才能让自动评估体系持续稳定可信。

四、闭环优化：评估不是一次性动作，而是持续迭代过程

Agent 的评估不是做完一套指标就结束，而应该是一个持续动态优化过程。

完整闭环通常包括：

1. 收集数据
2. 识别问题
3. 分析原因
4. 反哺优化
5. 回归验证
6. 上线观察

1）收集用户反馈

在产品中提供明确的反馈入口，例如：

• 点赞
• 点踩
• 文字反馈
• 人工接管
• 问题举报
• 满意度评分

用户反馈是非常重要的真实信号。

但也要注意，用户反馈通常是不完整的。

很多用户不满意时不会点踩，而是直接流失。

所以，除了显式反馈，也要看隐式反馈。

例如：

• 用户是否重复追问
• 用户是否中途退出
• 用户是否撤销操作
• 用户是否改用人工
• 用户是否再次使用
• 用户是否完成后续转化

2）对失败样本做 Case Study

所有负反馈样本、高风险样本和任务失败样本，都应该被拉出来做专项分析。

分析时要判断问题到底出在哪一层：

• 是需求理解错误
• 是任务规划错误
• 是工具选择错误
• 是参数填写错误
• 是工具接口失败
• 是知识库召回错误
• 是上下文管理问题
• 是权限校验问题
• 是 Prompt 设计问题
• 是模型能力问题
• 是产品交互问题
• 是用户输入本身不完整

这一步非常关键。

因为 Agent 系统是复合系统，同一个失败结果背后可能有完全不同的原因。

例如，用户说“帮我查一下上个月销售情况”，Agent 给错了数据。

原因可能是：

• 模型理解错了“上个月”的时间范围
• 工具参数传错了
• 数据库接口返回异常
• 权限限制导致只查到部分数据
• 知识库数据过期
• 最终总结时模型编造了结论

只有定位清楚原因，才能做有效优化。

3）反哺优化

失败样本不能只做记录，而要沉淀进评估和优化体系。

常见反哺方向包括：

• 黄金测试集
• 回归测试集
• 对抗测试集
• Prompt 优化
• 工具描述优化
• 参数 schema 优化
• 工具调用规则
• RAG 检索策略
• 上下文压缩策略
• 模型微调数据
• 权限和安全策略
• 产品交互设计
• 后端降级策略

例如：

• 如果频繁出现参数传错，就优化工具 schema 和参数校验。
• 如果频繁出现无意义追问，就优化上下文继承和追问策略。
• 如果频繁出现知识库答错，就优化知识库质量、召回和重排。
• 如果频繁出现工具失败后胡编，就加强异常处理和结果校验。
• 如果频繁出现越权风险，就加强权限系统和敏感操作确认机制。

4）回归验证

每次优化后，都需要重新跑回归测试。

否则很容易出现一个问题被修好，另一个能力被破坏的情况。

回归验证要看：

• 原来的失败样本是否修复
• 核心任务成功率是否提升
• 安全指标是否下降
• 延迟和成本是否恶化
• 旧能力是否被破坏
• 新策略是否引入新问题

对于 Agent 产品来说，回归测试尤其重要。

因为 Prompt、工具描述、模型版本、上下文策略、RAG 策略的任何一个变化，都可能影响整体行为。