UFO Step Logs 全解析读懂 response.log 中每一行 Agent 决策轨迹【免费下载链接】UFOUFO³: Weaving the Digital Agent Galaxy项目地址: https://gitcode.com/GitHub_Trending/uf/UFOUFO 在每次会话中都会把 HostAgent 与 AppAgent 每一步的 LLM 响应、执行结果与截图信息以 JSON Lines每行一条 JSON的形式写入logs/{task_name}/response.log这份 step log 是 UFO 调试、评估与轨迹分析的核心数据源。本文以 step_logs.md 为基础结合仓库源码深入讲解 step log 的字段语义、生成机制与读取方法读完后你将能够独立解析、检索并可视化任何一次 UFO 会话的完整决策轨迹。Step Log 是什么一次会话的逐帧黑匣子Step log 是一条按时间顺序追加写入的 JSONLJSON Lines文件文件中的每一行对应 Agent 的一次动作。它不只记录最终结果还完整保留了每步的observation环境观察、thought推理过程、status状态转移、costLLM 调用开销以及截图路径相当于把一次 GUI 自动化任务还原成可逐帧回放的状态机快照。所有 step log 统一存放在日志目录中目录名{task_name}依据会话创建时间自动生成logs/{task_name}/response.log围绕该目录UFO 还会生成配套日志文件共同构成完整会话证据链见 overview.md日志类型内容位置Request Log每一步发送给 LLM 的 prompt 请求logs/{task_name}/request.logStep LogAgent 响应与执行细节本文主题logs/{task_name}/response.logEvaluation Log任务评估结果logs/{task_name}/evaluation.logScreenshotsUI 截图与视觉采集logs/{task_name}/UI Tree应用 UI 结构数据logs/{task_name}/ui_tree/字段全表HostAgent 的 LLM 响应HostAgent 负责接收用户请求、拆解任务、分配子任务并调度 AppAgent。它的每条响应包含以下 LLM 输出字段FieldDescriptionTypeobservation桌面截图分析与当前状态Stringthought任务拆解的推理过程Stringcurrent_subtask待 AppAgent 执行的子任务Stringmessage给 AppAgent 的指令与上下文List of Stringscontrol_label所选应用的索引Stringcontrol_text所选应用的名称Stringplan当前子任务之后的后续计划List of StringsstatusAgent 状态FINISH、CONTINUE、PENDING或ASSIGNStringcomment面向用户的摘要或进度更新Stringquestions需要用户澄清的问题List of Stringsfunction要执行的系统命令可选String此外每条 HostAgent 记录还附带会话级元数据FieldDescriptionTypestep会话内的全局步号Integerround_step当前 round 内的步号Integeragent_step该 Agent 实例自己的步号Integerround_num当前 round 编号Integerrequest原始用户请求Stringagent_type固定为HostAgentStringagent_nameAgent 实例名Stringapplication应用进程名Stringcost本步 LLM 成本Floatresult执行结果Stringscreenshot_clean干净桌面截图路径Stringscreenshot_annotated标注版截图路径Stringscreenshot_concat拼接版截图路径Stringscreenshot_selected_control选中控件截图路径Stringtime_cost各处理阶段耗时Dictionary字段全表AppAgent 的 LLM 响应AppAgent 在具体应用如 Word、Excel、PowerPoint、浏览器内执行 UI 操作。它的 LLM 响应字段如下FieldDescriptionTypeobservation应用 UI 分析与状态Stringthought下一步动作的推理Stringcontrol_label选中控件元素索引Stringcontrol_text选中控件元素名称Stringaction动作详情含函数名与参数Dictionary or ListstatusAgent 状态CONTINUE、FINISH 等Stringplan当前动作之后的计划步骤List of Stringscomment进度摘要或完成说明Stringsave_screenshot截图保存配置Dictionary配套的元数据字段FieldDescriptionTypestep会话内全局步号Integerround_step当前 round 内步号Integeragent_step该 Agent 实例自己的步号Integerround_num当前 round 编号IntegersubtaskHostAgent 分配的子任务Stringsubtask_index子任务在当前 round 中的索引Integeraction_type执行的动作类型Stringrequest原始用户请求Stringagent_type固定为AppAgentStringagent_nameAgent 实例名Stringapplication应用进程名Stringcost本步 LLM 成本Floatresult执行结果Stringscreenshot_clean干净应用截图路径Stringscreenshot_annotated标注版截图路径Stringscreenshot_concat拼接版截图路径Stringtime_cost各处理阶段耗时Dictionary关键字段的源码佐证save_screenshotAppAgent 响应模式在 response_schema.py 中定义为Optional[Dict[str, Any]]处理上下文 app_agent_processing_context.py 中其结构包含save与reason字段。应用策略 app_agent_processing_strategy.py 会据此决定是否把当前截图写入 Blackboard 供后续 Agent 复用。screenshot_selected_control截图路径按action_step{session_step}_selected_controls.png的规则生成见 app_agent_processing_strategy.py与文档中的字段名一一对应。status状态值HostAgent 的FINISH/CONTINUE/PENDING/ASSIGN对应其「完成任务 / 继续推进 / 等待用户输入 / 分派子任务」四种行为也是 UFO 状态机驱动多轮会话流转的核心信号。如何读取 Step Logs由于 response.log 是 JSONL 格式解析非常简单。原文档给出了逐行解析的示例import json with open(logs/{task_name}/response.log, r) as f: for line in f: log json.loads(line) print(fStep {log[step]} - Agent: {log[agent_type]}) print(fThought: {log[thought]})在此基础上仓库还提供了更高层的解析封装Trajectory类ufo/trajectory/parser.py直接面向日志目录初始化并自动按agent_type拆分两类 Agent 的轨迹from ufo.trajectory.parser import Trajectory traj Trajectory(logs/{task_name}) # 分别取出 HostAgent 与 AppAgent 的逐步记录 for step in traj.host_agent_log: print(step[step], step[thought], step[status]) for step in traj.app_agent_log: print(step[step], step[action])Trajectory类会完成三件原文档未展开的附加工作容错解析逐行json.loads并跳过损坏行_load_response_data见 parser.py截图回填依据clean_screenshot_path、annotated_screenshot_path、concat_screenshot_path、selected_control_screenshot_path四个键加载图片对象注入ScreenshotImages字段见 parser.py按步号聚合step_number、round_number等属性从 step log 中推导出会话总步数与总轮数见 parser.py。Trajectory还提供to_markdown()方法见 parser.py可把整条轨迹导出为包含摘要、评估结果与内嵌截图的 Markdown 报告——这正是 Markdown Log Viewer 的实现基础。Step Log 的写入机制从会话上下文到文件Step log 并非由某个 Agent 直接写盘而是通过会话上下文中注册的文件写入器完成。在 ufo/module/basic.py 的_init_context中会话初始化时会创建三个绕过全局日志开关的FileWriterresponse_writer FileWriter( os.path.join(self.log_path, response.log), modea ) request_writer FileWriter( os.path.join(self.log_path, request.log), modea ) eval_writer FileWriter( os.path.join(self.log_path, evaluation.log), modea )随后分别注册到ContextNames.LOGGER、REQUEST_LOGGER与EVALUATION_LOGGER。从源码可以推断三个 writer 均以modea追加打开因此 response.log 天然是按时间顺序累积的 JSONL执行中间件 processing_middleware.py 会在每一步处理流程中把 Agent 响应写入ContextNames.LOGGER即每次动作对应文件中的一行step/round_step/agent_step/round_num等元数据由会话上下文中的步号与轮号计数器维护保证跨 Agent 的全局步号唯一且可对齐。进阶结合 Markdown Log Viewer 与评估日志使用对于人工排查场景无需直接解析 JSON。在config_dev.yaml中开启如下配置后会话结束时自动生成人类可读的 Markdown 日志详见 markdown_log_viewer.mdLOG_TO_MARKDOWN: true输出文件为logs/{task_name}/output.md其中包含会话概览与元数据请求、总步数、总轮数、Host/App Agent 步数统计逐步执行时间线thought、status、action 与执行结果内嵌标注版与选中控件截图评估结果摘要。该功能由BaseSession.save_log_to_markdown()见 ufo/module/basic.py在会话结束时调用Trajectory.to_markdown()生成。若需要结合自动评估指标解读 step log可配合logs/{task_name}/evaluation.log由evaluation_agent.md所描述的评估流程写入以及 evaluation_agent.md 中定义的评估机制一起分析。常见问题与排查建议response.log 为空Trajectory初始化会直接抛ValueError见 parser.py。通常是会话被中断或尚未执行任何动作to_markdown()也会输出「No trajectory data found」的空模板。step 号不连续属正常现象。step是跨 Agent 的全局会话步号HostAgent 与 AppAgent 交替记录时会交叉递增建议按agent_type过滤后再看各自的agent_step。截图字段为空字符串_load_single_screenshot会跳过空值与空字符串避免因os.path.join误指向目录本身而报错见 parser.py解析时无需自行防御。总结logs/{task_name}/response.log以 JSONL 格式完整记录了 UFO 会话中 HostAgent 与 AppAgent 每一步的 LLM 响应、执行结果、成本与截图信息是 UFO 调试、评估与轨迹分析的第一手数据源。本文从字段全表、读取方法、写入机制到 Markdown 导出完整梳理了 step log 的解析与使用路径实际项目中建议直接复用仓库自带的 ufo/trajectory/parser.py 中的Trajectory类进行结构化加载以最低成本获得可靠、可复现的轨迹数据。【免费下载链接】UFOUFO³: Weaving the Digital Agent Galaxy项目地址: https://gitcode.com/GitHub_Trending/uf/UFO创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考