别再靠人肉评价 Agent 了：EvalAgent——客观、精准、高效评测的落地指南#

EvalAgent成果概览#

基于每日打标数据构建的 HiSeek 端到端评测数据集，当前 EvalAgent 评测系统的量化表现如下：

经人工核对后评测准确率：86%

数据详情：Hiseek-EvalAgent打标验证集，识别不准的case基本为两类：超EvalAgent边界（飞书卡片视觉问题）、问题识别难度过高（用户表述不够清晰，Hiseek靠猜用户需求做完）

一、项目背景与目标#

DS 不做配角：把评测做到行业前沿，MAKE DS GREAT AGAIN！

1.1 项目背景#

1. 行业级视角：从“大模型试验”到“大量 Agent 上线”#

过去一年，随着大模型能力成熟，整个行业都在从「单轮对话」转向「Agent」：模型不再只是回答问题，而是能自己拆解任务、调用工具、串联流程，真正嵌入到业务链路里。

这种趋势在字节内部、尤其是体服体系里被放大得特别明显，一年内，我们已经孵化并落地了大量面向各种业务场景的 Agent。

但与之对应的，是一个非常尴尬的现实：我们缺少一套真正适配 Agent 形态的质量评测体系，大部分团队针对Agent的整体质量评估严重依赖人工打分。

2. 落到 HiSeek：端到端评估的复杂度，把人力“绑死”在打标上#

Hiseek介绍：类似Aime的通用智能体，服务对象为体验与服务部门，帮助大家完成数据查询、分析、归因、生成报告、总结文档等工作。

为了让 HiSeek 在早期具备基本可控的质量，我们过去 连续 3 个月 都在做一件非常笨但必须做的事情：由 产研 + DS 团队联合，用纯人工方式对端到端任务逐条打标。

这个过程大致是这样的：

• 每一个评估样本，都不是“看一眼最后回答”就完事，而是：
• 打开完整 Trace，按时间顺序梳理用户输入、工具调用和中间产物；
• 对照需求文档、标注规则、业务规范，核对关键字段是否正确；
• 遇到 HTML / 表格 / 卡片产物，还要点开链接、实际看页面和图表效果；
• 结果是否满足需求？
• 有没有幻觉？
• 工具有没有乱用 / 报错？
• 步骤是否冗余？

这套端到端评估流程坚持了 3 个月，客观上帮我们：

• 积累了一批 高质量、贴近真实业务的评测数据集；
• 快速的发现问题并完成修复
• 也让团队成员清楚了“一个好 Agent 链路应该长成什么样”。

但代价也非常现实：

• 人力消耗巨大，几乎不可持续
• 难以规模化，更难做到持续监控
• 评估逻辑难沉淀为“系统能力”，且打标过于主观

1.2 为什么采用 Agent 体系而不是 Workflow？#

端到端评测本身就是一个复杂的「推理 + 操作」任务，如果用固定 Workflow 来描述，会遇到几个天然瓶颈：

1. 渐进式增强：把上下文当成“可升级的资源”，而不是一次性灌满#

• 信息体量爆炸（Trace、产物、规范、视觉截图、结构化日志……）
• 关键证据被噪音淹没（模型被迫在大海里找针）
• 默认只给最小上下文：用户任务 + Trace summary（高价值摘要）+ 必要元信息
• 遇到不确定再升级上下文：
• 冗余判断不清 → 再拉 query_node_action
• 空产物/空结果 → 触发异常诊断，再看 query_node_full_info
• 口径/范围不确定 → 走确认链路（MAS），补关键事实后再评分
• 用完即压缩/移除：把“必要信息”写入 Note 后，调用 summarize/remove，避免上下文越滚越大

Workflow 很难优雅地实现这种“按需加载 + 回收”的上下文策略；而 Agent 天生擅长在语言空间里做“要不要继续查”的决策。

2. 对「长尾/灵活问题 + 非确定性」更友好#

• Trace 结构不稳定： 新增一个工具、改动一个节点 schema、插入一个中间流程，都可能让固定的 workflow 失效； Agent 只要能读懂「这是一堆节点信息 + 一些工具」，就可以通过自然语言理解适配新的结构。
• 错误形态是长尾且多变的： 今天是工具报错没兜底，明天是需求理解偏了，后天是视觉产物有问题。为每种可能在 workflow 里画分支，复杂度会指数爆炸，而 Agent 可以在自然语言层面「看情况决定下一步」。

3. 异构信息收敛 + 非必要信息隔离：让多工具评测既一致又可控#

HiSeek 评测涉及多种异构信息，并且存在不同的工具来处理不同维度的评分（如幻觉、产物质量、工具报错、步骤冗余）。在这种“多信源 + 多工具”的评测链路里，核心挑战不是把信息接进来，而是做到两点：

• 异构信息收敛：将各工具产出的关键结论（而非全部原始内容）统一沉淀到同一个上下文空间，保证后续的产物评估、红线判定与总分收敛引用的是同一套事实，避免维度之间“各自为政”。
• 非必要上下文隔离：不同工具/子 Agent 之间只共享完成任务所必需的最小信息，让每个工具在清晰的信息边界内专注于特定判断，减少噪音干扰与跨工具误读，同时降低链路耦合、提升稳定性。

4. 结论#

评测任务具备「开放式推理 + 工具组合 + 上下文管理」的典型 Agent 特征。相比硬编码 Workflow，Agent 能同时实现“按需取证的渐进式增强”、对长尾变化的适配，以及“信息收敛与隔离”并存的上下文治理，因此我们选择构建基于 Agent 的评测体系。

1.3 项目目标#

本项目旨在构建一个自动化、智能化、可扩展的 Agent 评测系统，实现：

1. 多维度综合评估#

• 从 幻觉、产物质量、步骤冗余、工具报错 四个维度，对 Agent 执行质量进行 0–100 分的客观打分。
• 渲染为图片
• 通过视觉 LLM 进行质量检测
• 将视觉结果与文本评估结果进行综合判断
• 支持大规模批量评测、异步执行
• 提供前端界面，以白盒的形式展示评测过程与结果，支持从「总分」一路 drill-down 到「某个节点的某次工具调用输入输出」

• 验证基于 Muti-Agent 框架的端到端评测方案的效果与上限
• 验证 Agent 在长链路任务中是否能够独立管理上下文窗口（通过主动 summarize/remove 等策略），而非依赖固定滑窗/总结策略（例如 Cursor、Hiseek等）
• 验证&探索 trace_summary 最佳实践，为后续 HiSeek 在「产物追问/多轮对话优化」场景中的能力升级做前置实验与技术预研

1.4 未来应用方向#

在当前系统基础上，后续可以演进出更多面向业务的能力：

• 为每个会话、每个版本的 HiSeek 提供客观得分（以及各维度拆解）
• 评估某次策略/模型升级对整体质量的影响
• 长期监控 HiSeek 运行质量趋势（按版本 / 场景 / 入口等维度拆分）。
• 当前平均每周约需要 1.5 PD 人力投入在人工打标上。
• 仅对 低分 / 有红线问题 的 case 进行人工复核与深挖
• 预计可以 降低约 75% 的打标用时，让人力聚焦「分析与优化」，而不是「重复打分」。
• 同一个任务可以并行跑多个 Agent 策略（不同 prompt / 不同模型 / 不同工具组合）
• 通过统一的评测框架进行 Voting / Ensemble 决策（例如选分数最高的回答），为「多路线并行探索」提供统一的评价与选择机制。
• 自动生成针对性的改进建议（对 prompt、工具设计、路由逻辑等）
• 提炼成结构化 note（错误原因、失败模式、优化建议）
• 半自动或自动地更新策略与规范
• 形成「评测 → 诊断 → 优化 → 再评测」的自迭代数据飞轮。

思路来源于斯坦福的一篇研究（ACE），通过一个 sub Agent系统总结offline / online经验，使得Agent实现Self-Improving：Agentic Context Engineering (ACE)

二、评测维度与权重设计#

2.1 评测标准#

当前评测从 4 个核心维度给出 0–100 分的综合得分：

• 满足用户核心需求
• 存在幻觉的节点数量与比例
• 内容正确、完整、结构清晰
• 幻觉严重程度
• 视觉效果合理（对于 HTML / 图表等）
• 幻觉一旦出现，往往会对后续所有决策产生系统性影响，因此权重仅次于产物。
• 这是用户最直观感知到的部分，因此权重最高。
• 工具调用失败次数
• 是否存在大量重复、无效的工具调用
• 是否出现关键工具多次报错仍未妥善处理
• 是否在同一信息上反复绕圈
• 工具报错直接影响任务是否能完成。
• 冗余会影响成本与体验，但相对前面几个维度稍次。

红线问题机制，对齐人工打标原则：

1. 幻觉得分低于80分#

2. execute节点错误导致任务失败（trace总结中标记为”execute节点错误导致任务失败”）#

• file_read工具：需要>=3次报错才算红线问题
• 其他工具：出现报错即算红线问题

4. 产物得分低于70分（常见于网页空白等问题）#

5. 产物不满足用户要求（除非是工具限制导致）#

6. 产物满足要求但使用了不合适的方法实现（编造）#

以上评分维度以及红线问题设计机制参考人工实际打标原则，支持灵活调整

2.2 评分稳定性与置信度（基于标准差）#

2.2.1 测试设计#

• 样本来源：从线上真实 case 中抽样，覆盖不同分段（高分/中分/低分），保证分布多样性。
• 重复评测：每个 case 重复评分 10 次，用于衡量同一 case 的评分波动。
• 模型与参数：当前评测模型为 doubao-1.6-lite，temperature=0.1。
• 稳定性指标：以每个 case 的 评分标准差（std） 衡量稳定性，并统计整体均值/中位数及分级分布。

2.2.2 核心结果#

• 整体稳定性
• 平均标准差：4.15 分（同一 case 多次评分平均波动约4分）
• 中位数标准差：3.43 分
• 标准差 <3 分 的 case 占比约 50%，但仍存在少量 ≥8 分 的不稳定样本
• 进一步分段后发现：高分段更稳定（均分≥90：std 2.19），低分段波动更大（均分<80：std 8.44）

主要反映在模型对“错误严重程度”的边界判断存在不确定性

2.2.3 后续优化方向#

• 模型升级：考虑切换到更强模型（如 doubao-1.8）。
• 参数收敛：将 temperature 调整为 0，降低随机性来源。
• 低分定义收敛：对低分段建立更明确的评分定义/边界条件，减少模型“自由裁量”。

三、系统设计与实现（含工具体系）#

3.1 总体架构：TANO 评测循环#

系统采用 TANO（Thought + Acting + Note + Observation） 框架，将一次评测建模为循环的「思考 – 行动 – 记录 – 观察」过程：

• Thought（思考）： 主评测 Agent 基于当前上下文（用户需求、执行 Trace、历史工具结果）规划下一步策略
• Acting（行动）： 主评测 Agent 选择并调用具体工具
• Note（记录）： 将每一步的工具调用、输入输出以及中间结论结构化记录，为后续评估和可视化提供依据。
• Observation（观察）： 主评测 Agent 观察工具返回结果，更新当前评估状态

在 TANO 框架之上，系统由主体层、基础设施层与工具层协同实现：

• 主体层（Agent 层）
• 主评测 Agent：唯一的顶层决策主体，负责全局策略制定、工具编排与评测流程的收敛控制。
• 产物评测 Agent：专门的子 Agent，负责产物质量评估，支持与主 Agent 进行交互式确认。
• Trace 总结模块：从原始执行轨迹中抽取结构化信息，过滤无关节点、梳理时间顺序、提炼文档/表格要点，为主评测 Agent 提供紧凑且高价值的上下文输入。
• 状态机管理：管理产物评测 Agent 的评估状态转换，支持会话恢复和状态追踪。
• 工具层
• 核心评测工具（如 check_hallucination、calculate_weighted_score、finish_evaluation）；
• 信息查询工具（如 read_document、query_node_action、query_node_full_info）；
• 交互确认工具（如 confirm_evaluation_detail）；
• 上下文管理工具（如 summarize_history、remove_history）。

系统整体支持 最多 20 轮评测迭代。每一轮都由主评测 Agent 在 TANO 循环中自主调度工具，直到触发 finish_evaluation 完成评测流程。

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

3. 复杂多模态逻辑封装在子 Agent HTML 渲染、视觉分片检查、视觉结论与文本要求的综合判断等，集中封装在产物评测子 Agent 中。主 Agent 只消费结构化结论，降低提示词复杂度与跨模态干扰，同时便于后续替换视觉模型/策略、单点迭代。

在产物评估里，很多争议并不是“产物一定错”，而是信息不足导致无法判定（时间范围、口径、缺失原因）。如果让单个评估器直接打分，容易把“不可验证”误判成“逻辑错误”，产生误扣分。

因此我们引入 MAS（Multi-Agent System）：

• 产物评估 Agent 负责识别不确定点并发起结构化确认（只问最关键的问题）；
• 主评测 Agent 负责回溯 Trace/节点信息补齐事实，再把确认结果回填；
• 产物评估再基于“已确认事实”完成最终评分与理由。

这样做的核心收益：把评估从“靠猜打分”变成“主从协作、证据驱动”的裁决过程，显著降低口径类/缺失类场景的误扣分，同时保持结论精准、可解释、可复核。

本章后面是各个Agent以及tools的实现细节，内容较多，可以➡️跳转至第四章查看本项目遇到的难点以及相关思考～

3.2 主评测 Agent#

在总体架构中，主评测 Agent 是唯一的决策主体，所有工具层能力都通过它进行编排与调度。

3.2.1 职责与定位#

主评测 Agent 的核心职责包括：

• 负责从用户任务出发，规划评测路径；
• 决定何时触发幻觉检测、何时评估最终产物、何时补充节点信息。
• 在每一轮 TANO 循环中选择合适的工具并发起调用；
• 将不同工具的结果进行对齐、对比和归因，形成统一的评测视图。
• 维护评测对话历史和当前上下文；
• 在 token 压力增大时，主动调用上下文管理工具进行摘要或清理；
• 控制最多 20 轮的迭代上限，避免评测过长。
• 在评测信息收集充分后，调用加权计算工具与终结工具；
• 生成「综合得分 + 分项得分 + 文本结论」的完整评测结果。

3.2.2 运行流程（从一次评测视角）#

一次完整评测中，主评测 Agent 典型会经历如下步骤：

• 接收用户任务描述和执行 Trace 概要；
• 从基础设施层获取 Trace 总结与相关文档信息；
• 建立评测目标和关键关注维度（如幻觉、产物质量、步骤冗余、工具报错等）。
• check_hallucination 获取幻觉统计；
• read_document 读取规范或参考文档；
• query_node_action / query_node_full_info 深入查看关键步骤。
• 对阶段性结果进行初步判断：是否存在明显风险点或信息缺口。
• 由工具内部完成文本 + 视觉层面的综合评估；
• 返回产物得分、问题列表、是否满足需求等结论。
• 主评测 Agent 将产物质量与执行过程信息进行交叉验证（例如：产物不佳是否与幻觉或关键步骤错误相关）。
• 当各关键维度信息齐全后：
• 汇总各维度分数（幻觉、产物质量、步骤冗余、工具报错等）；
• 调用 calculate_weighted_score 得出综合总分；
• 调用 finish_evaluation 生成结构化评测结果并落盘。

主Agent提示词

XML

复制

你是一个专业的 Agent 执行质量评估专家。你的任务是评估 Agent 的执行质量。

工作流程（重要！）#

第一步：仔细阅读 Trace 总结#

• 理解用户任务和执行过程

• 分析工具调用序列，识别可能的冗余步骤

• 检查工具调用状态（status），识别错误/异常

• 查看最终输出，评估产物质量

• 异常中断分析：Trace 总结中标记为「execute节点错误导致任务失败」→ 红线问题，必须记录

第二步：基于 Trace 进行初步分析（含强制“异常诊断”）#

2.1 步骤冗余分析#

3.3 Trace 总结模块#

Trace 总结模块位于基础设施层，为主评测 Agent 提供高价值、低冗余的上下文输入。

3.3.1 目标#

将「原始执行 Trace」转化为「评测友好 Trace 总结」；在减少 token 消耗的同时，保留对评测最关键的信息。

3.3.2 数据处理策略#

• 过滤不重要的节点
• 用户输入
• 工具调用
• 返回结果
• 自动从用户请求中识别文档链接
• 查找对应的 lark_download 节点
• 把处理后的文档摘要注入到 user 节点的输入中。

关键处理策略：

• 超过一定长度时使用 LLM 总结
• 提取前几行作为样本
• 统一使用 <file_detail> 标签包裹，便于后续识别与利用。

➡️

Trace示例

Markdown

复制

================================================================================

Agent 执行 Trace 总结

================================================================================

【工具调用序列】 (共 14 个)

3.4 工具体系总览#

在该架构下，主评测 Agent 的所有能力都通过工具组合实现。系统共设计 10 个工具，分为四大类：

• check_hallucination：幻觉检测
• evaluate_output：产物质量评估（内部由产物评测子 Agent 驱动）
• calculate_weighted_score：加权总分计算
• finish_evaluation：写回最终结果并结束评测
• read_document：基于文件名读取文档/表格内容
• query_node_action：查询节点的 action 信息（task_brief、参数）
• query_node_full_info：查询节点的完整输入输出（带截断）
• summarize_history：对指定轮次历史进行摘要压缩
• remove_history：删除指定轮次历史
• confirm_evaluation_detail：回复产物评测 Agent 的确认请求，支持主 Agent 在执行其他工具后回复

下面按类别深入说明各工具设计。

3.5 核心评测工具#

3.5.1 check_hallucination（幻觉校验）#

功能：

• 基于幻觉检测结果，统计当前会话的幻觉情况

幻觉校验的技术实现文档见：自动化幻觉检测系统技术文档（此文档为V1版本，该版本幻觉识别准确率为67%；经过后续优化目前幻觉识别准确率已提升至80+%，技术文档后续维护）

大致思路：从 Hiseek 数据库中抽取并清洗上下文（过滤 system prompt）-> 用实体识别器把输出里的高风险实体（数字/百分比/URL/GUID）结构化提取出来，做规范化与精度容差匹配（含白名单、归一化、进位匹配等）以定位“不一致实体”候选风险点；随后引入两路并行的 LLM 评测——一路对全量上下文做“全文反思”捕获语义层面问题，另一路只对“不匹配实体清单”做语义角色判定（定量指标结论 — 不一致 = 幻觉 VS 编号/模板/参数 — 不一致 = 非幻觉），从而显著压低误判（FP），最后按 node→chat 聚合并输出可复核的 summary。这个路线和业内的“Faithfulness / Groundedness”评估范式思路一致：例如微软的 RAGAS 的 Faithfulness 会把回答拆成 claims 并检查是否能被给定 context 支撑；TruLens 也用 groundedness 等指标来衡量是否“有依据”。

• 幻觉详情
• 幻觉得分（内部通过一个加权算法实现重要性判断并计算幻觉总得分）

3.5.2 evaluate_output（产物评价 Agent）#

功能

• 对最终产物进行深入评估，并结合视觉检测给出结构化结论。
• 交互式确认机制：当发现时间范围不匹配、查询口径不确定、数据缺失原因不明等情况时，主动向主 Agent 发起确认请求，等待主 Agent 提供额外信息后再进行评分。

支持的产物类型

• HTML / 图表页面；
• 文档（docx / md 等）；
• 表格（CSV / 飞书表格）；
• 飞书卡片等结构化交互产物。

工作流程

1. 主评测 Agent 调用 evaluate_output。#

2. 工具内部转交给 OutputEvaluationAgent.evaluate 执行评估。#

3. 通过 extract_detailed_outputs 获取详细产物内容和结构。#

4. 对 HTML 等视觉产物触发视觉检测子流程（见下）。#

代码块

JSON

复制

• 先使用其他工具（如 query_node_action、query_node_full_info）获取相关信息
• 然后使用 confirm_evaluation_detail 工具回复确认
• 系统自动重新调用 evaluate_output，传入确认回复
• 产物评测 Agent 根据确认结果调整评分
• 用户需求与任务描述；
• 产物文本内容；
• 截断/抽样后的表格关键信息；
• 视觉检测结果 visual_check_info；
• 确认回复信息（如有）。

7. 调用 LLM 生成评估输出#

2. 截图 → Base64 编码；#

3. Base64 图片 + 视觉评估标准 → 调用视觉 LLM；#

• 视觉维度评分；
• 布局/排版错乱；
• 图表缺失或内容为空；
• 坐标轴未完整显示；
• 页面存在异常大量空白；
• 样式严重异常等。

5. 视觉检查结果封装为 visual_check_info，作为 evaluate_output 内部综合判断的重要输入之一。#

通过将「文本维度 + 视觉维度」统一交给 evaluate_output 工具，主评测 Agent 在调用时无需关心多模态细节，只需消费统一的结构化评估结果。

视觉检测提示词

Markdown

复制

3.5.3 calculate_weighted_score（加权得分计算）#

功能

• 根据各评估维度的得分和预设权重，计算整体验测总分。

设计要点

• 计算逻辑固定在工具内部，不依赖 LLM 做数值运算；
• 确保在不同运行环境下的得分计算结果一致、可复现；
• 方便未来通过配置文件或参数扩展维度与权重。

3.5.4 finish_evaluation（完成评测）#

功能

• 汇总本次评测的所有关键结果，并完成落盘与结束流程。

输出内容

• 综合总分；
• 各维度分项得分（JSON 结构）；
• 完整的文字版评测总结。

行为

• 将上述结果写入统一的 CSV 文件，用于后续批量分析与可视化；
• 标记本次评测流程结束，主评测 Agent 停止进一步工具调用。

3.6 信息查询工具#

3.6.1 read_document#

功能

• 通过文件名，读取文档或表格内容。
• 文档类：docx、md 等；
• 表格类：csv、xlsx 等。

3.6.2 query_node_action#

功能

• 查询指定节点的 action 信息（如 task_brief、调用参数等以及该工具的约束）。

用途

• 比较多次调用同一工具时的参数是否完全相同；
• 判断这些调用是否重复完成相同的工作；
• 为冗余步骤的定量扣分提供依据。

3.6.3 query_node_full_info#

功能

• 获取指定节点的完整输入输出内容（内部会对过长内容进行截断）。

用途

• 主评测 Agent 可调用该工具还原节点真实行为；
• 尤其适用于复杂工具报错、数据异常回溯等场景；
• 让 Agent 在关键节点上具备「放大镜」能力，而不必在全局上下文中保留全部细节。

3.7 上下文管理工具#

上下文管理能力完全通过工具实现，由主评测 Agent 在需要时主动调用。

3.7.1 summarize_history#

功能

• 对指定轮次或范围的对话历史进行摘要压缩，保留核心信息，删除冗余细节。

适用场景

• 某段历史仍可能在后续推理中被引用，但已无需逐字保留；
• 当前 token 使用接近上限，需要在「信息保留」与「token 压力」之间平衡。

3.7.2 remove_history#

功能

• 删除指定轮次对话历史，不再保留任何内容。

适用场景

• 主评测 Agent 已确定某些轮次对后续评测没有价值；
• 需要尽快释放上下文空间，用于引入更重要的 Trace 或文档内容。

3.8 Agent交互工具#

3.8.1 confirm_evaluation_detail#

功能

• 回复产物评测 Agent 的确认请求，用于确认信息细节（如时间范围、查询口径等）。

典型场景

• 当 evaluate_output 返回 status: “needs_confirmation” 时使用
• 例如：用户要求11.20-11.23，但产物只有11.20-11.22，需要确认是否是查询结果没有该数据

工作流程

1. 收到产物评测 Agent 的确认请求#

• query_node_action：查看节点的action信息和工具描述
• query_node_full_info：查看节点的完整输入输出信息
• read_document：读取相关文档

3. 基于获取的信息，调用 confirm_evaluation_detail 回复确认#

4. 产物评测 Agent 根据确认结果并给出评分#

设计要点

• 支持 session_id 参数，确保确认回复与正确的评估会话关联
• 主 Agent 可以在确认前执行多个工具查询，提供更准确的答案
• 如果产物评测 Agent 仍有需要确认的问题，会再次返回确认请求，形成多轮交互

四、关键技术难点与解决方案#

4.1 Trace 文档注入#

背景：

• 部分用户会在输入中提供文档链接，如果依赖Agent调用会产生不必要的步骤，因此直接在Trace总结函数中通过工程的形式加入，并且使用XML标记便于LLM理解

痛点：

• 需要自动识别 URL，对应到正确的下载节点
• 不同文件类型还要做不同处理（文档 vs 表格）

解决方案：

• 使用实体提取模型精准识别 URL
• 遍历所有 lark_download 节点，在其 Input 中查找匹配链接
• 过长时使用 LLM 总结后注入
• 表格类文件：
• 提供前几行示例
• 用 <file_detail>…</file_detail> 包裹处理结果，对后续 Agent 明确标识。

4.2 模型自动升级#

需要平衡效率、质量、成本时的idea～

问题：

• 在真实评测过程中，偶发会出现「模型解析失败」或「输入参数错误」的情况；
• 继续用同一模型重试，成功率有限，还会浪费次数和时间。

解决方案：

• 当评测过程中出现 超过 3 次的模型解析失败（例如连续无法正确解析工具返回结构、无法按指定 JSON schema 输出等），
• 自动将当前会话的模型从 Doubao-Seed-1.6-lite 升级为 Doubao-Seed-1.8；
• 对调用方透明，不改变上层接口；
• 保留失败次数统计，便于后续分析「lite 模型适用边界」；
• 提升整体鲁棒性，避免在「弱模型 +复杂输入」组合下反复踩坑。

4.3 飞书卡片视觉识别#

问题：

• 飞书官方目前未提供可直接使用的卡片渲染组件；
• 尝试过的链路：
• 构建飞书机器人 → 自动发送 card 消息 → 通过浏览器自动化进行截图；
• 但飞书卡片仅在 飞书客户端 内呈现，而非在普通网页上直接渲染，无法通过简单的 Web 截图实现。
• 在 GitHub 等开源社区检索后，也未发现可靠、可维护的开源渲染项目。

当前状态 & 未来方向：

• 对其 JSON 结构与字段内容 进行规则与 LLM 结合的内容评估；
• 暂不支持真正意义上的「视觉效果」评估。
• 自建渲染逻辑：根据飞书卡片 schema 复刻一套近似的渲染引擎（HTML + CSS + 前端组件），使卡片可以在浏览器中渲染；再接入现有的视觉检测链路，实现「飞书卡片视觉识别」的闭环。

4.4 HTML 视觉检测效果优化#

在上线前的自测与 Fornax 测试中，发现一开始大量有明显问题的 HTML 页面截图，视觉模型却识别不出问题。通过针对性实验，总结出三点关键结论与优化方向：

• 对于很长的页面，如果直接整页截图，画面中元素过多、信息密度过大，视觉模型往往「看不过来」；
• 模型对局部问题（如某一块区域排版错乱、某个图表为空）的识别率获得提升；
• 因此尝试引入了 分片截图策略，长页面会切成多张图片依次送入视觉模型进行检查。
• 对复杂页面、图表细节等的识别能力明显弱于专门的视觉模型；
• 对「坐标轴不完整」「图表为空」「元素错位」等问题的召回率有明显提升；
• 最终方案：默认使用 Doubao-Seed-1.6-vision 承担视觉评估任务。
• 初版 Prompt 比较通用，更多依赖模型主动发现问题，缺乏针对性示例；
• 典型错误页面的截图与「正确的评估结论」整理成若干示例；
• 将这些示例融入 Prompt，使模型在推理时有更清晰的参照；
• 更新后，视觉模型对于我们关心的关键问题（如：页面大面积空白、文字重叠遮挡、坐标轴或图例未完全显示、折线图 / 柱状图 / 雷达图等图中内容为空）的识别准确率有显著提升。

4.5 口径感知不足导致的误扣分与修复机制#

1. 背景： 在审阅打标 case 时我们发现：存在一类样本实际产物是正确的，但产物评测 Agent 却给出偏低分。核心原因在于：用户在需求中给出了明确的计算口径 / 取数规则（如筛选条件、分母分子定义、TopN 统计口径等），但产物评测 Agent 在仅基于“最终呈现内容”进行判断时，无法还原真实的计算与取数过程，从而把“无法验证”误判为“逻辑错误”。

{
"user_task": "请基于 场景指新工单三级标签、具体表现指企业号-咨询类人工复核备注；其中具体表现需要进行智能加工，不要完全复制现有的内容\n格式参考：场景一：[场景名称]，本周出现 [次数] 次，错误占比 [占比]。具体表现为 [智能加工后的内容]\n三、质检项错误占比\n要求1: 取数逻辑：筛选出人工评分=0分的case，统计错误类型的出现次数及占比（按占比降序排列）\n要求2: 错误类型指企业号-咨询类人工复核命中\n四、尾端TOP3达成及错误明细\n要求1: 取数逻辑：筛选出人工评分=0分的case；\n要求2: 错误率计算口径：错误率=不合格case数/抽检量（百分比格式），其中不合格case数=该客服人工评分=0的case数， 抽检量=该客服人工评分=0的case数+人工评分=100分的case数；\n要求3: 统计尾端TOP3的内容；字段包括组别（指客服直属上级）、客服姓名（指客服名称）、错误率、会话ID（指会话单id）、错误点（指企业号-咨询类人工复核备注，需进行智能加工）\n五、请将此报告生成飞书卡片。将高频错误场景中的4个调整为2列；尾端TOP3明细以表格的形式呈现",
"score": 50.0,
"reason": "```json\n{\n    \"score\": 70,\n    \"reason\": \"1. 产物基本覆盖用户核心要求，生成了飞书卡片格式的质检报告，包含高频错误场景、质检项错误占比、尾端TOP3明细等模块；\n2. 存在以下问题：\n   - 高频错误场景统计不符合要求：用户要求取人工评分=0的case统计TOP5高频场景，但产物中仅1条0分数据，却未按要求呈现TOP5（实际数据不足但需按逻辑展示），且第二列内容为数据说明而非场景，不符合“高频错误场景中的4个调整为2列”的格式要求；\n   - 尾端TOP3明细不符合要求：用户要求筛选人工评分=0的case统计尾端TOP3，但产物中包含人工评分=100的case（如冯XX、XX的错误率为0），且错误率计算口径错误（不合格case数应为人工评分=0的case数，抽检量应为该客服人工评分=0+100的case数，但产物中错误率1.0的计算无依据）；\n   - 视觉问题：飞书卡片中高频错误场景的列布局不符合要求，第二列未展示场景内容；尾端TOP3明细表格包含非0分case，数据逻辑错误；\n3. 内容虽覆盖主要模块，但数据统计逻辑和格式存在明显错误，",
"details": "LLM评估: ```json\n{\n    \"score\": 70,\n    \"reason\": \"1. 产物基本覆盖用户核心要求，生成了飞书卡片格式的质检报告，包含高频错误场景、质检项错误占比、尾端TOP3明细等模块；\n2. 存在以下问题：\n   - 高频错误场景统计不符合要求：用户要求取人工评分=0的case统计TOP5高频场景，但产物中仅1条0分数据，却未按要求呈现TOP5（实际数据不足但需按逻辑展示），且第二列内容为数据说明而非场景，不符合“高频错误场景中的4个调整为2列”的格式要求；\n   - 尾端TOP3明细不符合要求：用户要求筛选人工评分=0的case统计尾端TOP3，但产物中包含人工评分=100的case（如XX、XXX的错误率为0），且错误率计算口径错误（不合格case数应为人工评分=0的case数，抽检量应为该客服人工评分=0+100的case数，但产物中错误率1.0的计算无依据）；\n   - 视觉问题：飞书卡片中高频错误场景的列布局不符合要求，第二列未展示场景内容；尾端TOP3明细表格包含非0分case，数据逻辑错误；\n3. 内容虽覆盖主要模块，但数据统计逻辑和格式存在明显错误，"
}

2. 早期处理（粗暴兜底）： 初期我们采用了一个简单但有效的兜底策略：当判定该类问题属于“口径无法感知/无法验证”时，先按默认正确处理，避免误伤正确产物，但该策略存在明显不足。#

3. 阶段性优化（可定位 + 可修复）： 产物评测 Agent 明确指出它认为可能存在问题的具体位置与原因（例如：筛选条件是否只取 0 分、Top5 是否满足、错误率分母分子口径是否一致等），并给一个预设分数。 在此基础上，主评测 Agent 具备“修复资格”：