[BUG] 孤立字符 bug

[SherryWang2005]

Task 28 的主运行和定向补跑中，Agent 都已经进入腾讯视频《繁花》第 01 集页面并调用 done 产出最终答案；随后 API 日志与 result.json 在写入 UTF-8 文件时遇到孤立高位 surrogate \ud83d，两次均抛出 UnicodeEncodeError。异常处理又用一个空的错误结果覆盖了原本有意义的 Agent 结果

[SherryWang2005]

Task 28 UTF-8 surrogate 失败说明

一句话结论

这是一个高置信的 harness 结果序列化缺陷，不是 Browser-use 或 GPT-5.5 Medium 没有完成浏览任务。

Task 28 的主运行和定向补跑中，Agent 都已经进入腾讯视频《繁花》第 01 集页面并调用 done 产出最终答案；随后 API 日志与 result.json 在写入 UTF-8 文件时遇到孤立高位 surrogate \ud83d，两次均抛出 UnicodeEncodeError。异常处理又用一个空的错误结果覆盖了原本有意义的 Agent 结果。

建议 taxonomy 主标签为 H1 Harness / Execution Defect；网站高层分类可记为 Tool / harness failure。

案例信息

字段	值
Benchmark	LexBench-Browser / All
Task ID	28
任务	在腾讯视频搜索《繁花》，进入第一集并记录导演、主演、播放量和豆瓣评分
Agent	Browser-use 0.13.4
模型	GPT-5.5 Medium，Responses API，reasoning_effort=medium
Vision	On
Browser backend	Lexmount .com
Timeout / max steps	900 秒 / 40 步
主运行并发	3
运行目录	browser-use/gpt-5.5/20260714_210121
运行代码 commit	a20a3568021e93761a906101fa19d42f42e44d11
Python / OS	Python 3.11.15 / macOS 26.1 arm64

配置文件使用环境变量占位符；包内的 config snapshot 已脱敏，不包含 API key、project id、CDP session URL 或本机身份指纹。

两次失败时间线

第一次：全量主运行

1. Agent 成功搜索《繁花》，识别 2023 年 30 集正剧，并进入第 01 集播放页。

2. Agent 在第 11 步调用 done(success=True)，输出导演王家卫、主演胡歌/马伊琍/唐嫣/辛芷蕾，并对页面上的 9679 和 9.2 做了保守的不确定性说明。

3. Browser-use 日志明确记录 Task completed successfully。

4. 任务结束后的 API 日志生成失败：

   Failed to generate API logs for task 28:
   'utf-8' codec can't encode character '\ud83d' in position 28704:
   surrogates not allowed
   

5. Runner 随后写 result.json 再次失败：

   UnicodeEncodeError: 'utf-8' codec can't encode character '\ud83d'
   in position 13081: surrogates not allowed
   

6. Wall time 为 217.0 秒，进程最终 exit code 1。

完整上下文见 evidence/run_log_original_attempt_excerpt.txt。

第二次：定向补跑

1. Agent 再次完成搜索和第一集页面核验，在第 12 步调用 done(success=True)。
2. 第二次最终答案同样保守：确认导演、主演；明确说明页面只显示 10005 和站内评分 9.2，无法证明它们分别是播放量和豆瓣评分。
3. Browser-use 再次记录 Task completed successfully。
4. API 日志生成再次因同一个 \ud83d 失败，位置变为 30882。
5. result.json 再次因同一个 \ud83d 失败，位置变为 12698。
6. Wall time 为 238.1 秒，进程最终 exit code 1。

完整上下文见 evidence/run_log_rerun_attempt_excerpt.txt。

两次独立会话都在 Agent 完成之后、同一持久化阶段、以同一 surrogate 字符失败，因此这不是一次偶发模型输出错误。

证据链

1. Agent 实际已经完成

两次 run.log 都同时出现：

[Agent] done ... success: True
[Agent] Final Result: ...
[Agent] Task completed successfully

这排除了“Agent 未调用 done”“模型超时”或“模型完全不会执行任务”作为本次 runner 失败的直接原因。

2. 失败发生在结果落盘

Traceback 固定指向：

browseruse_bench/runner/agent_runner.py::_save_result
json.dump(result_data, ..., ensure_ascii=False)
fp.write(chunk)
UnicodeEncodeError ... '\ud83d' ... surrogates not allowed

包内 code/failing_version/agent_runner.py 是失败时版本。其 _save_result 直接把整个 result_data 以 ensure_ascii=False 写入 UTF-8，没有 Unicode sanitation。

3. API 日志先暴露了同一问题

失败时 APICallLogger 会把浏览器 state message、模型输出和 action result 直接做：

json.dumps(step_data, ensure_ascii=False, indent=2)

它只捕获 OSError 和 TypeError；UnicodeEncodeError 属于 UnicodeError -> ValueError，因此 step 写入失败后异常向外传播。当前任务目录只留下 step 1-4，step_005.json 为 0 字节，和日志中的失败点一致。

4. 错误结果覆盖了有效结果

Runner 的外层异常处理捕获 ValueError 后构造新的错误结果并再次调用 _save_result。这个 fallback 不含原动作历史，所以最终 result.json 显示：

• env_status=failed
• agent_done=error
• answer=""
• steps=0
• action_history=[]
• screenshots=[]
• usage=null

但同一目录实际保留了 12 张截图，日志也保留了第 12 步的最终答案。这说明最终 JSON 是异常后的覆盖结果，不是 Agent 的真实执行轨迹。

5. Judge Pass 不能当作运行成功

现存 gpt-4.1 stepwise eval 给了 100 分 / Pass，因为 evaluator 仍看到了 12 张截图和 4 个 API step preview；与此同时它记录 has_agent_answer=false、steps=0、usage=null。

该 Judge 回答还声称“播放量 20.2 亿、豆瓣评分 8.5”，但 retained screenshots 和两次 Agent 最终答案对应的是页面数值 9679/10005 与站内评分 9.2，并没有支撑 20.2 亿或 8.5。这个 Pass 属于截图残留条件下的 Judge 误判，不能消除 runner 硬失败。报告的 rerun audit 因此仍将 Task 28 标为 definite hard failure。

技术根因

\ud83d 是 UTF-16 的高位 surrogate，单独存在时不是合法 Unicode scalar，标准 UTF-8 编码器必须拒绝它。

Python 3 中合法 emoji 通常是完整 code point，可以正常写 UTF-8；只有字符串里出现未配对的 U+D800..U+DFFF 时才会触发本错误。因此至少有一个 browser state、action result、模型/history 字段或桥接层字符串含孤立 \ud83d。

最早可观察失败位于 API log step 5。该步骤刚进入腾讯视频播放详情页；截图中 10005 前有火焰/热度图标，而火焰 emoji 🔥 的 UTF-16 表示以 D83D 开头。这是一个有解释力的候选来源，但不是定论：崩溃阻止了原始 step 5 state object 落盘，因此现有证据无法唯一判断 surrogate 是腾讯页面原始文本、Lexmount/CDP bridge、browser-use DOM 序列化还是其他中间层引入的。

可以确定的是：不论非法 surrogate 来自哪一层，日志和结果持久化都不应因此让整个已完成任务失败。

建议修复

1. 在所有 JSON/文本落盘入口前递归清洗未配对 surrogate，替换为 U+FFFD，并记录清洗数量和字段路径。
2. 至少覆盖 agent_runner._save_result、API step JSON、unmatched LLM failures、system prompt 和 API summary。
3. 使用临时文件加原子 rename，避免本例 step_005.json 这种 0 字节半成品。
4. API 日志属于观测产物；日志序列化失败不应改变 Agent 的业务结果或 exit code。
5. 保存 AgentResult 失败时，不要用空 fallback 覆盖原结果；应保留可恢复的 ensure_ascii=True 备份或 sanitized backup。
6. 增加包含 answer="completed \\ud83d"、嵌套 action history、dict key、API state message 的单元测试。
7. 修复后重新跑 Task 28，并让 Judge 只基于实际保存的最终答案和完整轨迹评分。

code/fixed_reference/ 收录了本机另一工作树中现有的 sanitizer 实现与测试，核心是 replace_unpaired_surrogates()。这些文件来自 commit ec84f545... 上的未提交改动，仅作为修复参考，不代表已合并到 Task 28 的运行分支，也不应整文件覆盖，因为其中还混有其他工作树差异。

最小复现

运行：

python reproduction/reproduce_unpaired_surrogate.py

预期先复现 UnicodeEncodeError，再展示递归 sanitizer 后可以成功写入，并把非法 surrogate 替换为 �。

包内目录

README_CN.md
evidence/
  task_definition.json
  run_config_env_placeholders.yaml
  config_snapshot_sanitized.json
  run_log_original_attempt_excerpt.txt
  run_log_rerun_attempt_excerpt.txt
  run_log_all_task28_lines.txt
  judge_eval_task_28.json
  report_rerun_audit_task_28.json
  task_28_runtime_artifacts/
    result.json
    api_logs/
    trajectory/
code/
  failing_version/
  fixed_reference/
reproduction/
  reproduce_unpaired_surrogate.py
MANIFEST.sha256