lhk229
98abcf4f0d
澄清任务的身份豁免按任务判而不是按工具判
上一笔把豁免收窄成「工具必须是 user.input_request」，只覆盖了转述动作本身。
实际上用户答完后 pending_execution 调的是
run_recovered_game_creator_context_on_fresh_task(root, agent_id,
pending.task.clone(), ...)：整条 run 从此改跑在转述任务上，同一 run 后续的
agent.run_status、agent.delegate 全都带着它，而 runtime.current_task 仍是用户
原始请求。
于是 run 15 过了转述那一关，却在续跑第一步就挂：Supervisor 按 supervisorRepair
的要求调 agent.run_status 重读权威合同，动作在等到项目锁之后被
validate_agent_runtime_pending_context 判成「pending action 身份已变化」，仍是
needs-reconciliation。
pending.tool = agent.run_status
pending.task = 子 Agent 需要用户澄清后才能继续。delegationId=delegation-4216f572…
runtime.currentTask = 做个横版像素解谜小游戏，主角是个能操控自己影子的小机器人。
判据改成只看 task 是不是 Runtime 生成的转述指令。同一个 || 链里的
validate_agent_runtime_pending_action_after_lock 不比较 task，所以豁免面仍然只
有这一条文本相等；agent/task_id/session/run/source 与轮次检查照旧全走。
回归测试补上 run 15 实测的那个形状：同一 run、同一转述任务、工具是
agent.run_status 的续跑动作必须通过，而 task 被改写的同形状动作必须照旧被拒。
三向变异验证：恢复严格比较、整条删掉、把判据换成恒真替身，都会红。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 05:33:48 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-21 05:33:48 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:42:29 +08:00