# 2026-08-13 复盘：5 个自举任务反复卡在 blocked_pending_human

**日期**: 2026-08-13
**性质**: 复盘文档 + 修复/执行顺序 todo，不是需求文档——真正的需求已经拆成三份独立文档（见 §2），
这份文档负责把"今天到底发生了什么、为什么会看起来像是全线报错、接下来按什么顺序处理"讲清楚。

## 1. 表面现象 vs 真实情况

用户观察："现在所有任务都报错了" —— 表面上确实如此：5 个目标任务（`2084590a`/`911861fe`/
`b243dfe8`/`bfd3ee82`/`71868db6`）加上新提交的 `6b823b35`，全部落在 `blocked_pending_human`，
`blocked_reason` 也全部显示同一个词 `execution_error`。

**但这不是一个共同根因导致的连锁故障**——逐个查真实 `execution_event` 记录后，是 **6 个互相独立
的真实原因**，只是都被同一个粗粒度的兜底桶盖住了，表面上看起来像"全线崩溃"：

| 任务 | 真实原因 | 类别 |
|---|---|---|
| `b243dfe8` | 孤儿 `work_graph_run`（有 manifest 无 artifact）撞 `ux_work_graph_run_active` 唯一索引 | 基础设施 bug，**已修复**（`_existing_active_run_id`） |
| `71868db6` | `max_concurrent_goals` 并发上限——本来就不是错误 | 机制设计缺陷，**已修复**（并发上限不再阻塞） |
| `911861fe` | Coder 和 Validator 的建议节点目录都收敛到 `node_type=test_script`，共享 run 里 `node_id` 撞名 | 基础设施 bug，**未修复**（`docs/todo/append-run-node-id-collision-across-org-nodes-requirements.md`） |
| `bfd3ee82` | 大 prompt 的 Validator 规划调用跑满固定 300 秒超时 | 基础设施 bug，**未修复**（`docs/todo/agent-call-liveness-not-fixed-duration-timeout-requirements.md`） |
| `2084590a` | Planner 自规划的 `graph_manifest` 里 `on_fail.action='loop_back'` 但缺对应 `on_failure` 边 | 内容/自规划质量问题，不是代码 bug——校验本身是对的，只是这次规划产出有缺陷 |
| `6b823b35` | Planner 的响应是叙述性文字，没能提取出结构化 `content` 字段 | 内容质量问题，跟 `docs/done/validator-test-script-narrative-output-issue.md` 记录过的同一类问题 |

## 2. 这次复盘真正的结论

这不是"系统今天特别不稳定"，是**一个一直存在、只是今天才被真正看清楚的设计缺陷**：`task_execution.py::_mark_blocked` 的兜底逻辑——任何不在一个很小的白名单（`_ROUTABLE_EXCEPTIONS`）里的异常，
不管性质是什么，一律扣上同一个 `execution_error` 帽子、状态打成 `blocked_pending_human`。这把
"系统自己造成的正常排队"（并发上限）、"真实但可自动恢复的 bug"（run_id/node_id 撞名）、"需要更长
等待时间的正常调用"（超时）、"这次规划质量不够好，换一次也许就好了"（内容问题）**全部混成了一种
表象**："报错，需要人工点 Resume"。

三份独立的需求文档（不在这份文档里重复内容，只列出关系）：

1. `docs/todo/boss-agent-autonomous-blocked-task-arbiter-requirements.md`——**长期**方案：一个
   自主监控 `blocked_pending_human`、做真实诊断、有权限边界地自主处理的角色。
2. `docs/todo/agent-call-liveness-not-fixed-duration-timeout-requirements.md`——**根因之一**：
   agent 调用不该用固定时长判断超时，只能用"是否还活着"。已作为 Goal 提交（`6b823b35`，但这个
   Goal 自己又撞上了另一个独立的内容质量问题，见上表——这本身也是个真实的、略带讽刺的例子，说明
   "内容质量问题"和"基础设施 bug"是两条完全独立的故障轴）。
3. `docs/todo/append-run-node-id-collision-across-org-nodes-requirements.md`——**根因之一**：
   共享 `work_graph_run` 下跨 org_node 的节点命名撞名问题。

今天已经**直接**修复（不经过 graphlemon 自己的 Coder，原因见下方"实施方式"说明）：
- `_existing_active_run_id()`（`src/e2e_pipeline.py`，commit 已提交）——修复孤儿 run 撞名。
- `_mark_blocked` 对 `ConcurrencyLimitReachedError` 的特判（`src/task_execution.py`，commit
  已提交）——并发上限不再报错阻塞，只是正常留在 `queued` 等下一轮调度。
- `task.execution_priority` 列 + `v_task_board` 新增"执行顺序"列（commit 已提交）——见 §3。

**实施方式说明**：以上三处修复都是本次会话直接改代码 + 写真实回归测试 + 跑全量测试套件验证后
提交，不是走 graphlemon 自己的 Planner→Coder→Validator 闭环——因为这些是阻塞 graphlemon 自身
基础设施的 bug（同类前例见 `docs/implementation-gap-analysis.md` 里"人工直接改代码修的，不是走
自举流程验证的"那几条），跟"喂给 graphlemon 自己实现"的三份需求文档（更大范围的设计工作）性质
不同，不要混为一谈。

## 3. 6 个任务的执行顺序

新增的 `task.execution_priority` 列已经把下面这个顺序写入了每个任务（串行用整数、并行用同一个
整数部分的小数——比如 `2.1`/`2.2`/`2.3` 表示这三个可以同时跑，都在"第 2 步"）：

| 顺序 | task_id | 为什么是这个顺序 |
|---|---|---|
| **1** | `b243dfe8` | 阻塞它的 bug 已修复（`_existing_active_run_id`），且这是验证今天这个修复本身是否真的生效的第一手真实信号——先单独跑，确认不再复现同一个 `IntegrityError`，再放心批量恢复其余任务。 |
| **2.1** | `71868db6` | 阻塞它的并发上限 bug 已修复，且这个修复本身不需要等任何东西——它甚至不需要手动 resume，下一轮 `new_goal_dispatch` 循环（45 秒）会自动重新拾取。 |
| **2.2** | `2084590a` | 阻塞它的是内容质量问题（自规划图结构有缺陷），不依赖任何未完成的基础设施修复——直接重试，让 Planner 有机会规划出结构正确的图。 |
| **2.3** | `6b823b35` | 同上，叙述性输出问题，不依赖未完成的修复——直接重试。 |
| **3.1** | `911861fe` | **暂不恢复**——阻塞它的 node_id 撞名 bug 还没修（`docs/todo/append-run-node-id-collision-across-org-nodes-requirements.md`），现在重试大概率原样复现同一个撞名。 |
| **3.2** | `bfd3ee82` | **暂不恢复**——阻塞它的固定时长超时问题还没修（`docs/todo/agent-call-liveness-not-fixed-duration-timeout-requirements.md`），现在重试大概率再次跑满 300 秒被杀。这条**不接受**"先把 300 秒改成一个更大的数字"这种临时缓解——用户已经明确过这个决定：判断逻辑本身错了（固定时长 vs 是否还活着），不是数字选小了，改数字治标不治本，还是要等真正的心跳判断机制落地。 |

3.1 和 3.2 之间没有依赖关系（各自阻塞在不同的、互相独立的基础设施 bug 上），标成并列的
"第 3 步"两条分支，不是先后关系——哪个对应的修复先做完，哪个就先重试，不用等另一个。

## 4. 下一步 todo

- [ ] 按上表恢复 `b243dfe8`（第 1 步），验证不再复现 `IntegrityError`。
- [ ] 确认 `71868db6` 被下一轮 `new_goal_dispatch` 自动拾取（第 2.1 步，预期不需要手动操作）。
- [ ] 恢复 `2084590a`/`6b823b35`（第 2.2/2.3 步）。
- [ ] 设计并实现 node_id 撞名修复（`docs/todo/append-run-node-id-collision-across-org-nodes-requirements.md`），完成后恢复 `911861fe`（第 3.1 步）。
- [ ] 设计并实现 agent 调用心跳超时判断（`docs/todo/agent-call-liveness-not-fixed-duration-timeout-requirements.md`），完成后恢复 `bfd3ee82`（第 3.2 步）。
- [ ] 上述两条修复都落地后，重新评估 Boss Agent（`docs/todo/boss-agent-autonomous-blocked-task-arbiter-requirements.md`）该由谁实现——它本身也是喂给 graphlemon 自己的 Goal，但两条基础设施修复没做完之前，Boss Agent 面对的"原因分类"依然是残缺的，建议这两条修复优先。