/goal 的两个洞：状态太死、只判结果

github.com/loopx-project/… 给 agent 派长活的 /goal，被拆出两个洞。 洞一在状态。目标只有一句终局描述，中途该到哪、偏没偏，机器看不见。任务一长、目标一随进度变形，那句死话就对不上了。洞二在引导。跑完只判结果，不看过程，于是要么跑偏到底才发现，要么在原地绕圈。解法指向 loopx，思路是外置一套稠密的语义状态，再补上过程监督，据说 7 月爆火前就把这两个洞填了。 引帖里还有个更狠的说法：/goal 这东西可能压根不必依赖。Prompt 写得好，目标线程和生命周期自己管得住；Claude Code 早期的 Ralph Loop 加 stop hook，搁我看就是 /goal 的前身。这位面试官爱问"how is /goal implemented"，在实践派看来，命令的甜头更多来自名字好听。 两派摆一起，我看是各说各的层次。引帖讲的是"模型够强就不需要"，这篇讲的是"给定这个工具，它哪里有毛病"。前者说的是未来，后者修的是现在，不冲突。这跟前面 vibe coding 退休那篇对上了，工具会被内化，可内化之前，谁用谁知道坑在哪。 保留的疑问很具体：外置状态到底存在哪、多细才够。稠密到每个动作都记，token 先受不了；太粗又回到原来那个洞。 想动手的先看仓库，loopx 的状态模型和 /goal 的差别，对照一遍就明白自己缺哪半边。