[Idea] 从 last_error 到 failure taxonomy：结构化失败原因能否改进 HALF 的 Agent 重派发？

[leonadoor]

[Idea] 从 last_error 到 failure taxonomy：结构化失败原因能否改进 HALF 的 Agent 重派发？

背景

HALF 当前已经有基础的任务异常处理机制：

• 任务可以进入 needs_attention
• 后端会记录 last_error
• TaskEvent 中会记录 error、timeout、redispatched 等事件
• 用户可以对异常任务执行 redispatch

这说明 HALF 已经能记录“任务失败了”和“上一次错误是什么”。

但目前这些信息主要还是状态和自由文本错误。比如 result.json 不合法、任务超时、Git 同步失败等，通常被记录为一段 last_error。这些错误信息可以帮助人类排查问题，但还没有被进一步组织成可统计、可复用的结构化失败原因。

因此这里想讨论一个问题：

HALF 是否应该把 needs_attention + last_error + redispatch 进一步演进为结构化的 failure taxonomy？

核心问题

在 human-in-the-loop 的多 Agent coding 工作流中，对失败任务进行结构化失败原因标注，是否能提升后续 Agent 的重试质量，并减少无效重派发？

更具体地说：

1. Coding Agent 任务失败可以分成哪些常见类型？
2. 不同失败类型是否需要不同的 retry prompt？
3. 失败原因应该由人工标注、Agent 自评，还是由系统根据 verifier / last_error 自动推断？
4. 结构化失败标签是否能减少后续 Agent 的重复探索和同类错误？
5. 长期积累的失败标签能否形成 HALF 的 failure playbook？

论文依据：EvoMAC 中的失败反馈驱动改进

此问题的启发来自仓库里已有一篇对 EvoMAC 的讨论：#123。此处不再过多赘述论文本身的内容。简单来说，EvoMAC 的核心思路不是让多个 Agent 简单分工后各自完成任务，而是引入一个“执行 - 测试 - 更新”的闭环：

1. Coding Team 负责根据需求生成代码。
2. Testing Team 自动生成测试，并用测试结果作为反馈信号。
3. Updating Team 根据测试报告和执行日志，对 Agent 的提示和协作流程进行更新。

这里最值得借鉴的一点是：EvoMAC 没有把失败仅仅看作一次任务结束后的日志，而是把失败反馈转化为下一轮协作改进的输入。

这对 HALF 有一个比较直接的启发：

HALF 当前已经会把失败任务标记为 needs_attention，并记录 last_error。但这些失败信息更多是给人看的，还没有被进一步结构化，也没有系统性地影响下一次 redispatch。

因此，可以考虑一个更小的、适合 HALF 当前阶段的问题：

能否先把失败原因结构化，再用这些失败类型指导后续重派发？

也就是说，不一定马上实现 EvoMAC 那种完整的自进化多 Agent 网络，而是先把失败反馈从自由文本变成可分类、可统计、可复用的对象。

与 HALF 当前机制的关系

当前 HALF 已经具备：

• Task.status = needs_attention
• Task.last_error
• TaskEvent(error / timeout / redispatched)
• redispatch

但这些机制更偏向“记录和恢复状态”，并未明显形成：

• 失败原因分类
• 失败类型统计
• 按失败类型生成重试提示
• 基于历史失败的经验沉淀

所以这个问题不是要替代现有机制，而是想讨论现有机制是否可以进一步结构化。

一个可能的分类方向

初步来看，失败原因可以分成两类。

系统可直接识别的失败

例如：

• timeout_no_result
• invalid_result_json
• task_code_mismatch
• artifact_path_invalid
• dependency_blocked
• git_sync_failed

需要人工或 Agent 辅助判断的失败

例如：

• context_missing
• requirement_misunderstood
• incomplete_patch
• wrong_file_modified
• test_failed
• task_too_large
• over_editing

这些更接近 Agent 行为层面的失败，可能需要人工 review 或额外判断。

可能的研究价值

这个问题的价值在于，它处在一个相对小但很关键的位置：

• 比完整 runtime supervisor 更容易落地。
• 比单纯展示 last_error 更有研究价值。
• 和 HALF 当前的 needs_attention / redispatch 机制直接相关。
• 可以把失败任务从“人工处理对象”变成“可分析、可比较、可复用的经验来源”。

如果 failure taxonomy 有效，HALF 未来也许可以回答这些问题：

• 哪类失败最常见？
• 哪类失败最适合自动重试？
• 哪类失败应该直接交给人工？
• 哪类 Agent 更容易产生某类失败？
• 哪种 retry prompt 对某类失败最有效？

想讨论的问题

1. HALF 是否需要引入结构化 failure taxonomy？
2. failure taxonomy 应该只覆盖系统错误，还是也覆盖 Agent 行为错误？
3. last_error 是否应该继续作为自由文本保留，同时增加结构化标签？
4. 哪些失败类型最值得 HALF 优先识别？

[black-pwq]

HALF 主分支目前只有两种故障会标记为 needs_attention:

1. result.json 校验失败
2. 超时仍未检测到 result.json

第一种错误可以认为是 agent 行为错误导致的，第二种错误更像是系统性错误。从这个角度来看，可以把故障原因归类，把第一种错误的原因在重派发时作为提示发送给 agent。