dataset: 跟随 d172b62 重生成，统一工具错误协议落到数据里

[chenweihang0160-alt]

这次带来什么

跟随上游 d172b62 重生成，并把 d29d3e4 的统一工具错误协议全面落到数据里。

schema_version 仍是 711faf60（工具面没变，学习空间 22 个），
样本 1407 → 1414（+7，正是你们新加的 structured_runtime），tool_error 49 → 56。

收下了你们两笔的全部改动

commit	我们做了什么
7b5b7eb	system prompt 的 alias / teaching trigger → 重抓提示词缓存
d29d3e4	structured_runtime 7 条种子 + gen_structured_runtime + validate 认 message 键 + capture_system_prompts --keys 可重复，四处全收，validate.py / seeds/tool_errors.yaml 做了三方合并

structured_runtime 那 7 条我们逐条对着 backend/agent/tools/execution_errors.py 核过，
message 和 retryable 全部逐字一致，并且把这个对账做成了常设闸门（见下）。

🔴 三处我们改了你们的产出（都带证据）

① capture_* 抓的层：ToolExecutionResult 有三个投影

d29d3e4 之后工具返回从 dict 变成 ToolExecutionResult，我们两个 capture 脚本
当场 TypeError: Object of type ToolExecutionResult is not JSON serializable。

链路我们逐层追过才动手：

ToolExecutionResult.model_content
  → loop_runtime.tool_result_channels()      拆三投影
  → loop_runtime.serialize_tool_result()     json.dumps(..., default=str)
  → ToolObservation.model_text
  → agent.py:361  {"role": "tool", "content": observation.model_text}

模型看见的是 model_content，display_content 走界面、audit_metadata 是独立字段。
两个 capture 已改成取 model_content，esa/fixtures.py 的三个错误构造函数
也改成统一协议 {ok, error_code, error, retryable, tool, attempt, message} ——
test_fixture_contract 当时红了 5 条（「线上有我们没有：['attempt','error_code','message','retryable']」），
现在 72 通过 / 0 失败。

② data/ir/tool_errors.jsonl 里两种格式并存

你们那份里：

① [Error]: 字符串      7        ④ 旧的 ok/error/detail   6      ← 和 ⑥ 并存
② 带 error 键          12       ⑥ 统一结构化协议         7
③ 阻断 / 空结果        7

gen_structured_runtime 产出的是新协议，但 gen_denied / gen_exec_error
走的还是 fixtures 里旧的 {ok, error, detail} —— 同一个文件里两种格式，
而线上只有一种。本 PR 里那 6 条已经归到 ⑥（13 = 7 + 6）。

顺带：gen_external / gen_tool_errors 有三处 result["detail"]，
在新协议下是 KeyError。已改成调 validate._failure_text() ——
模型看见的那句、和 validate 认不认得那句，必须由同一个函数说了算，
两处各写一份迟早分叉。

③ seeds/tool_errors.yaml 的 wrapped 段少了 5 条

你们那份 7 条，我们这份 12 条 —— 少的是 unified_public_unconfigured_00..04
（[Error]: public knowledge service is not configured）。三方合并已经把两边的新增都保住了，
本 PR 是并集。

新增一道闸门

tests/test_runtime_error_contract.py —— 拿 execution_errors.py 的
ERROR_MESSAGES / RETRYABLE_ERROR_CODES 逐条核种子，改一个字就红（反向验证过）。
它还报覆盖率：后端 16 个 error_code，structured_runtime 只覆盖 7 个，
未覆盖的 9 个是 attachment_not_authorized / invalid_tool_arguments /
memory_policy_denied / non_idempotent_action_rejected / resource_capability_required /
temporary_tool_error / tool_not_available / upstream_unavailable / wall_time_exhausted。
要不要补齐，我们听你们的意见。

同时把这 16 句文案连真实行号登记进了 seeds/tool_errors.yaml 的 registry 段
—— 否则 validate 的 error_text 闸门会拦下整批数据（这次就拦了 11 条）。

📌 一个你们已经修掉的阻塞

docs/后端问题反馈.md 的 P0-4（删除不存在的记忆会让整轮 run 崩掉）——
d29d3e4 之后 delete_core_memory 返回
{"ok": false, "error_code": "tool_internal_error", ...}，不再抛异常。
那批「删不存在的记忆之后怎么恢复」的样本可以补了，下一轮会做。

怎么验（都是跑出来的）

在本 PR 分支的树上、后端仓库布局下实测：

PYTHONPATH=backend/scripts/dataset python3 -m esa.validate \
    backend/scripts/dataset/data/ir/*.jsonl      → 0 错误 / 1414 条 / 711faf60

七个自测全过：test_validator 58 · test_fixture_contract 72 ·
test_eval_scoring 111 · test_esa_tool_format · test_llamafactory_ingest ·
test_review_ledger 17 · test_runtime_error_contract。
在该树上重跑 esa.evalset，考卷指纹 2f4db3af27963d1e 与我们本机一字不差。

评测集 440 道 / 补充集 55 道 / 训练池 1087 条 → split 985 / 55 / 47。
零泄露：考卷 94 个模板与训练池 387 个模板交集为 0。

[chenweihang0160-alt]

补充两条 09-02 下午查出来的，都影响这个 PR 的数据，说明一下当前状态。

① 已修：11 条恢复话术在教模型编造技术原因

d29d3e4 之后每个工具返回都过 normalize_tool_error_result（capability_runtime.py:101，在 try 之外的正常返回路径上），错误原文进 audit_metadata.legacy_detail —— 模型看不见。而我们的话术逐字引用了它：

我们教的回答：「arXiv 那边没响应（[Error]: arXiv API 请求超时（已重试 5 次）），这次检索没拿到结果。」
模型实际看到：{"ok":false,"error_code":"temporary_tool_error","message":"工具暂时无法完成请求","retryable":true,"retry_after_ms":1000}

这是在教模型：看到一句笼统的失败文案，就编出一个具体原因。已全部改掉，话术只保留模型真看得见的东西（自己发的 tool_call 参数、message/retryable、schema 先验）。

顺带修正了 error_code 的取值：Agent 走 BoundToolExecutor，异常经 classify_tool_exception 分类，所以 arxiv 的 503/429/timeout（源码三处都是 raise RuntimeError）在模型侧是 temporary_tool_error（可重试），不是 tool_internal_error。载荷现在与线上 structured_tool_error 的输出逐字节相同。

新增闸门 tests/test_error_payload_visible.py：话术不许引用被协议改写时丢掉的内容。

② 未修，等你们定口径：业务错误文案被当成 error_code

normalize_tool_error_result 的 source.get("error_code") or source.get("error") 会把三个计算器的业务错误文案当成 error_code：

calculator 返回 {"expression":"1024/(10-10)", "result":null, "error":"除零错误"}
模型看到     {"ok":false, "error_code":"除零错误", "message":"工具暂时无法完成请求，请稍后重试"}

扫下来 13 种枚举外的 error_code，最长的是整句「函数 'popcount' 调用错误: popcount 仅支持非负整数…」。而且 expression/result 全丢、没进 audit（不在 legacy_* 白名单）—— 模型既不知道算的是哪个式子，也不知道是除零。

这一族我们没改，保持存工具的真实返回 —— 照抄现状等于把 bug 固化成训练目标。等你们定了口径我们跟。详细说明和建议修法另发。

[chenweihang0160-alt]

再补一条，和数据无关，但它挡着 CI —— 而 CI 红会挡住这个 PR。

POST /student/classes/join 建路由时就炸，一行能修

2026-09-05 对着 8f25ce8 复核过，仍然存在。

# backend/core/web/routers/student_teaching.py:15   ← 少了 JoinClassRequest
from backend.core.web.teaching_schemas import InvitationResponseRequest, SubmissionCreateRequest

# backend/core/web/routers/student_teaching.py:93-94
@router.post("/classes/join")
def join_class(body: JoinClassRequest, request: Request, session: CurrentSession) -> dict:

JoinClassRequest 本身是好的，定义在 backend/core/web/teaching_schemas.py:31。

为什么 import 这个模块不报错：文件第 5 行有 from __future__ import annotations，
注解全成了字符串，模块导入阶段不解析。FastAPI 建路由时才去解析，那一刻才炸。
所以它不是「某个请求失败」，是应用起不来。

复现（不用装 fastapi，get_type_hints 就是 FastAPI 建路由时调的那个）：

from __future__ import annotations
import typing

def join_class(body: JoinClassRequest) -> dict:   # 复刻 :94 的签名
    return {}

typing.get_type_hints(join_class)
# NameError: name 'JoinClassRequest' is not defined

⚠️ 说清楚界限：上面验的是机制，我们这边没装 fastapi，没跑起真实的 FastAPI 应用。
你们那边起一次服务就能坐实。

修法：:15 的 import 补上 JoinClassRequest。一行。

---

顺带同步一下这个 PR 的状态：dataset/steer/ 那个推理期工具调用闸门已经做完端到端实测了
（不是估算，是真挂上去重跑再整份判分）：误触发率 30.5% → 8.5%，代价是工具选择 −1.2、
漏调 +2.4，忠实度/响应率/格式/恢复率/参数匹配一个点没掉。⚠️ 8.5% 仍然没跨过 ≤5 那条线，
它是把大问题变成小问题，不是解决它。

唯一的接入成本是要拿到隐状态（第 48 层最后一个 token），走 OpenAI 兼容 API 那层拿不到，
得在能访问 output_hidden_states 的地方接。这件事需要你们配合才能落地，
细节和参考实现都在 dataset/steer/README.md，用不用你们定。

[chenweihang0160-alt]

更正上一条：/classes/join 那个 bug 你们已经修了，是我搞错了。

8696eee 里 student_teaching.py:15 的 import 已经补上 JoinClassRequest。
时间线是我的评论（08:28:57Z）比你们的修复（08:27:13Z）晚了一分四十四秒。

原因不是巧合，是我核实的方式不可靠：我用 gh api .../contents/... 拉的文件，
那个接口有缓存，返回的是旧内容——连它告诉我的「最新 commit 是 8f25ce8」也是旧的。
所以我写的「对着 8f25ce8 复核过，仍然存在」，复核的其实是一份过期快照。
以后我改用 raw.githubusercontent.com/<repo>/<commit>/... 指定 commit 拉，不再信那个接口的 HEAD。

抱歉浪费你们的注意力。上一条里闸门那部分（FPR 30.5% → 8.5%、需要拿隐状态才能接入）不受影响，仍然有效。

---

顺带两条关于 8696eee 的反馈，都和数据集这个 PR 直接相关：

① 谢谢把数据集的闸门接进了 CI。 不过 test_llamafactory_ingest.py 那个跳过分支在 CI 上会永远触发——它判的是 $HOME/Downloads/llamafactory-0.9.4 存不存在，CI runner 上不会有这个目录，所以这道闸门在 CI 里一次都不会真跑。而且 0.9.4 也不是我们集群实际用的版本（0.9.5.dev0）。它守的是「LLaMA-Factory 静默吃掉训练样本」，是条要紧的闸门，我在这个 PR 里改成从环境变量取路径、并且找不到就明确失败而不是跳过。

② 另外五个测试也建议一起接进去：test_error_payload_visible.py、test_esa_tool_format.py、test_runtime_error_contract.py、test_tool_coverage.py、test_verbosity_tools.py。第一个和你们这次做的事是同一个方向——它查的是「我们教给模型的话术，不许引用模型实际看不见的内容」。

③ 关于 problem_solving_expert v1 → v2：我们原本打算保留 v1 的 description，查证之后放弃了。v1 正文第 242 行写着「批改 → `homework_review` + `error_diagnosis`」，而运行时一轮只能加载一个主 Skill——那是个兑现不了的承诺。v2 删得对，我们跟随 v2 重新生成了数据。