企业官网建设流程全解析

UFO 评估日志（evaluation.log）完全解析：结构、字段与实战读取指南

【免费下载链接】UFOUFO³: Weaving the Digital Agent Galaxy项目地址: https://gitcode.com/GitHub_Trending/uf/UFO

evaluation.log是 UFO 项目中由EvaluationAgent在任务执行完成后生成的任务完成度评估记录，以 JSON 格式保存于logs/{task_name}/evaluation.log，一条记录即对应整个会话（session）的一次完整评估。本文以 UFO 官方文档《Evaluation Logs》为骨架，结合仓库内EvaluationAgent、会话模块与轨迹解析器的源码实现，系统讲解该日志的字段语义、子评分结构、生成链路、配置开关与程序化读取方法，帮助你在排查任务失败、分析 Agent 表现、构建评估流水线时准确理解并复用这一数据源。

日志的定位：它是评估结果唯一的落盘形态

在 UFO 的架构中，评估动作由 EvaluationAgent 承担。它会结合用户原始请求、执行轨迹（trajectory）与屏幕截图，使用 Chain-of-Thought（CoT）机制给出任务是否完成的判断。这个判断结果最终被会话对象序列化为 JSON 并写入日志文件，该文件即evaluation.log。

从源码可以确认这一点：在 ufo/module/basic.py 的evaluation()方法中，会话依次完成"调用EvaluationAgent.evaluate()获取结果 → 补充元信息 → 追加写入evaluation.log"的完整流程。日志的物理位置与目录约定见 Logs Overview：

其中{task_name}由系统基于时间戳自动生成，因此每次会话都会在独立目录下留下各自的evaluation.log。需要注意的是，该文件在会话初始化时即以追加模式（mode="a"）创建（见 ufo/module/basic.py），最终写入的内容是评估整个会话的一条 JSON 记录。

日志结构：六个核心字段

官方文档定义了evaluation.log的六个顶层字段，以下表格完整继承原文并补充取值说明：

其中level、request、type三个字段并非由 LLM 直接产出，而是会话模块在拿到评估结果后程序化追加的元信息。对应源码见 ufo/module/basic.py：

additional_info = { "level": "session", "request": requests, "type": "evaluation_result", } result.update(additional_info)

这意味着：无论底层 LLM 如何组织输出，level恒为session、type恒为evaluation_result、request恒为用户原始请求，这三个字段为下游程序按固定契约解析日志提供了稳定入口。

子评分结构：sub_scores的内部约定

sub_scores列表中的每一项都是一个字典，包含两个字段：

这一结构与EvaluationAgent的 CoT 评估流程一一对应：Agent 首先根据用户请求将任务分解为若干子目标，再对每个子目标独立打分（yes/no/unsure），最后聚合子评分得到整体complete状态。完整的评估流程（输入、分解、聚合、结论）可参考 EvaluationAgent 文档 中的 mermaid 流程图。

在 ufo/prompter/eva_prompter.py 的get_step_trajectory()中可以看到评估输入中每个步骤轨迹的字段构成：Subtask、Step、Observation、Thought、Plan、Comment、Action、Application。这意味着子目标的命名往往与轨迹中的子任务/步骤内容直接对应，读日志时可将sub_scores[].name与轨迹中的步骤描述互相印证。

完整示例：一份真实的 evaluation.log

官方文档给出的示例 JSON 如下（完整继承，未作删减）：

{ "complete": "yes", "sub_scores": [ { "name": "Open application", "evaluation": "yes" }, { "name": "Complete data entry", "evaluation": "yes" } ], "reason": "All sub-tasks completed successfully. Screenshots show the application was opened and data was correctly entered.", "level": "session", "request": "Open the application and enter data", "type": "evaluation_result" }

从这个示例可以看出该日志的阅读方法：先看complete快速判断任务成败，再看sub_scores定位具体哪个子目标失败，最后读reason获取失败/成功的定性分析。在 EvaluationAgent 文档 中还给出了一个更复杂的真实场景示例：评估"向 Microsoft Teams 中的 Zac 发送 hello 消息"任务时，reason会结合初始截图、操作序列与最终截图逐步叙述判断依据，sub_scores则拆分为correct application focus、correct message input、message sent successfully等细粒度子目标——这展示了日志在"定位失败环节"上的实用价值。

日志生成链路：从评估到落盘的源码级剖析

理解evaluation.log的生成过程有助于解读其中的内容，整个链路可概括为四步：

1. 会话触发评估：会话对象调用 ufo/module/basic.py 的evaluation()方法，该方法首先读取配置EVA_SESSION（默认True，见 config/ufo/system.yaml）决定是否执行整体会话评估；EVA_ROUND（默认False）则控制是否按轮次单独评估。
2. 构造评估输入：EvaluationAgent的message_constructor()通过 eva_prompter.py 组装系统提示与用户内容。当EVA_ALL_SCREENSHOTS为True时使用user_content_construction_all()传入全部截图（受MAX_EVAL_IMAGES = 40上限约束，超出部分自动裁剪，见 eva_prompter.py）；为False时使用user_content_construction_head_tail()仅传首尾两张截图（对应系统提示中的screenshots_all/screenshots_head_tail模板键，见 eva_prompter.py）。
3. LLM 生成结果：EvaluationAgent.evaluate()调用 LLM 并解析 JSON 返回(result, cost)（见 evaluation_agent.py）。值得注意的容错设计：若携带全部截图的评估请求异常，evaluation()会捕获异常并以eva_all_screenshots=False重试一次，即自动降级为首尾截图模式（见 ufo/module/basic.py）。
4. 写入并展示：会话把level/request/type三个元字段合并进结果后，通过evaluation_logger.write(json.dumps(result))追加写入logs/{task_name}/evaluation.log，同时调用evaluator.print_response(result)以 Rich 富文本形式在终端展示（见 evaluation_agent.py）。

此外，EvaluationAgent还接收工具（API）描述作为输入之一，由context_provision()从上下文中的TOOL_INFO加载并注入提示模板（见 evaluation_agent.py），因此日志中的判断依据实际上也隐含了对可用工具的感知。

配置开关：三个控制评估行为的参数

评估行为由config/ufo/system.yaml中的三个开关控制，完整继承 EvaluationAgent 文档 的配置表如下：

当前仓库 config/ufo/system.yaml 中的实际默认配置为：

EVA_SESSION: True # Whether to include the session in the evaluation EVA_ROUND: False EVA_ALL_SCREENSHOTS: True # Whether to include all the screenshots in the evaluation

各参数对日志的影响：EVA_SESSION控制evaluation.log中是否产生level: "session"的记录；EVA_ALL_SCREENSHOTS直接影响评估所依据的截图数量，进而影响reason的详细程度与 API 调用成本（截图越多，token 开销越大）；EVA_ROUND开启后，按轮次的评估结果同样会进入evaluation.log，使文件中可能出现多条记录。

程序化读取：如何在代码中解析 evaluation.log

evaluation.log是 UFO 为下游消费者提供的规范化接口，仓库内的轨迹解析器给出了官方的读取范式。在 ufo/trajectory/parser.py 的_load_evaluation_data()中，解析逻辑如下：

evaluation_log_path = os.path.join(self.file_path, self._evaluation_file) if os.path.exists(evaluation_log_path): with open(evaluation_log_path, "r", encoding="utf-8") as file: try: evaluation_data = json.load(file) except: evaluation_data = {} else: logger.warning(f"Evaluation log not found at {evaluation_log_path}.") evaluation_data = {}

这段代码的关键设计点：

• 文件缺失不致命：当某次会话没有生成评估日志时（例如EVA_SESSION关闭或评估流程未触发），解析器不会抛出异常，而是记录 warning 并返回空字典，保证轨迹解析流程可继续；
• JSON 解析容错：若文件内容不是合法 JSON（如被中断写入），同样降级为空字典；
• 统一入口：Trajectory对象通过evaluation_log属性暴露该数据（见 parser.py），并在输出 Markdown 报告时将评估结果一并导出（见 parser.py），因此你完全可以直接复用Trajectory类来读取评估日志，而无需自行编写文件解析代码。

实践建议：把评估日志用起来

结合官方文档与源码实现，针对evaluation.log的使用给出以下实操建议：

1. 快速定位失败：批量扫描logs/*/evaluation.log，筛选complete为no的记录，再依据sub_scores中evaluation为no的子目标定位失败环节；
2. 区分"确定性失败"与"不确定结果"：unsure状态通常表示 LLM 无法仅凭截图与轨迹给出明确结论，这类样本应人工复核，而非直接计入失败率——这与官方文档"LLM 评估结果应作为参考而非绝对事实"的定位一致；
3. 对照轨迹阅读：将reason中的描述与logs/{task_name}下的截图（如action_step1.png、action_step_final.png）、response.log对照查看，可确认评估结论是否与实际执行一致；
4. 关注成本：EVA_ALL_SCREENSHOTS为True时单次评估可能携带数十张截图，若对成本敏感或截图缺失场景频发，可评估将其关闭以换取更经济的评估；评估本身的 LLM 调用成本会计入会话总成本（见 ufo/module/basic.py）。

延伸阅读

• EvaluationAgent 详解：评估 Agent 的配置项、CoT 流程与输入输出契约
• 日志总览：UFO 全部日志类型与目录约定
• 系统配置指南：EVA_*系列配置项在系统配置中的完整说明
• Benchmark 概览：如何基于评估结果进行基准测试

【免费下载链接】UFOUFO³: Weaving the Digital Agent Galaxy项目地址: https://gitcode.com/GitHub_Trending/uf/UFO