长程规划能不能做好，往往不取决于单步执行得多利索，而取决于大目标有没有被拆对的小目标。可「拆得对不对」这件事，过去长期没有统一标尺——大家默认只要最终答对了，中间怎么拆都行。近期出现的子目标分解基准，把「会不会拆」单独拎出来打分。
它到底在测什么
给定一段长程任务，基准要求智能体先产出一串子目标，再由独立的校验逻辑判断三件事：分解本身是否正确，子目标之间的依赖关系有没有被保真，以及某个子目标失败后，系统是否还存在可行的回退路径。任务跨度从五步、十步一路拉到百步，目的就是看规划能力随长度如何退化。依赖保真这条尤其关键——拆出来的子目标如果破坏了原来的先后约束，执行时就会自相矛盾。
规律相当一致：短程还行，五步规模正确率约八成六；越往长走越塌，跨到百步后正确率近乎腰斩，落到约两成七。这说明长程规划的薄弱点常常在「拆」而不在「做单步」——模型能执行好一个清楚的子目标，却可能在把大目标翻译成子目标时就埋下连锁错误。换句话说，错误不在手上，而在蓝图里。
它点破了什么
过去不少评测盯着单步工具调用的成功率，那个数字往往漂亮，却掩盖了规划层的塌方。把分解单独成档打分，等于给规划能力装了一把尺。它也给工程提了个醒：与其无脑给模型堆更长的上下文去硬扛长任务，不如先让模型学会把目标拆稳——拆对了，后面执行才不会顺着错误的前提一路狂奔。对写智能体工作流的人而言，这条结论很实用：在加更多工具、更长记忆之前，先检查子目标分解是否站得住。
但别把数字当及格线
需要冷静的是，基准里的「分解正确」由评测脚本定义，和真实业务里「拆得有用」未必是一回事；跨百步的标注与回放本身成本高、噪音大，排序价值大于绝对值。它更像一个研究抓手与相对排行榜，告诉我们该往哪使劲，而不是一张投产用的及格卷。把它和具体的业务复盘结合，才不会被一个百分比带偏。真正落地时，企业更该关心的是：在自己的任务分布上，智能体拆出来的子目标，人审一遍能不能放心交给下游去执行。
对做智能体产品的团队，这条结论有个很落地的用法：在动辄给模型加更长上下文、更复杂工具之前，先拿自己的任务抽样做一次分解体检。如果子目标经常在十步开外就失稳，那瓶颈几乎一定在规划，而不在单步执行——这时候堆算力是扬汤止沸，先教会模型拆目标才是釜底抽薪。把评测当放大镜，而不是当成绩单。
有个容易低估的细节：分解质量高度依赖模型对被拆领域的结构理解。让一个对业务流程毫无概念的模型去拆跨月对账，拆解再漂亮也经不起业务校验。所以基准的数字之外，真正的杠杆往往在于给模型足够的领域结构与约束，而不是单纯指望它「想清楚」。规划能力的上限，常常由领域建模的质量决定，而非模型本身的聪明程度。