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 面对的"原因分类"依然是残缺的，建议这两条修复优先。