HTN领域设计出来能跑是一回事调通是另一回事。所以这篇文章聊聊在HTN调试时踩过的坑以及怎么绕过去。坎儿1无限递归无限递归大概是HTN领域最常遇到的错误。你写了个方法分解后得到它自己然后它再分解再得到自己……规划器直接卡死或者爆栈。怎么发现看规划器输出如果显示展开深度超过XXX或者直接报infinite recursion suspected大概率就是这个问题。怎么修两种思路第一种加前提条件——让递归有出口。比如(:method eat_food :precondition (and (hungry) (not (just_ate))) :tasks (cook) (eat)关键是(not (just_ate))这个条件确保吃完了就不会立刻再吃。第二种重新设计分解结构——如果某个任务本质上会递归试试把它拆成两个不同名字的方法然后用更高层的逻辑来选择。坎儿2循环检测方法A调用方法B方法B调用方法C方法C又调用回方法A——这就是循环依赖。静态分析 vs 运行时检测静态分析是最理想的情况——在运行之前就能发现循环。PANDA系统就是这么做的它会预先构建一个方法调用图然后检查有没有环。# 简化版循环检测思路defdetect_cycles(method_graph):visitedset()recursion_stackset()fornodeinmethod_graph:ifhas_cycle_from(node,visited,recursion_stack):returnTrue# 发现循环returnFalsedefhas_cycle_from(node,visited,stack):ifnodeinstack:returnTrue# 找到循环ifnodeinvisited:returnFalse# 已检查过不是循环源stack.add(node)forchildinmethod_graph[node]:ifhas_cycle_from(child,visited,stack):returnTruestack.remove(node)visited.add(node)returnFalse运行时检测则是规划过程中监控展开深度——如果深度超过某个阈值就强制终止。这种方法简单但没法给出明确的错误位置。坎儿3约束冲突方法A要求任务在状态X执行方法B要求同一时间任务在状态Y执行——这就是约束冲突。这种情况最讨厌因为单独看每个方法都没问题放在一起就打架了。怎么排查画状态转移图——把任务间的状态依赖画出来冲突一目了然检查前提条件的冲突——两个方法能不能同时满足看规划器报错信息——大多数规划器会告诉你no valid method sequence常见陷阱隐式约束方法A没写但逻辑上依赖某个状态时序约束没写清楚本来应该先做X再做Y但方法里没体现数值约束写错比如速度要求 10写成了 10漏掉边界情况领域正确性验证怎么跑通光调试还不够还得验证你的领域设计是对的。单元测试思路# 测试某个方法能否正确分解deftest_cook_method():stateinitial_state()tasks[cook]# 顶级任务planplanner.plan(tasks,state)assertplanisnotNone# 能找到解assertcontains_actions(plan,[buy,chop,fry])# 分解出正确的动作序列边界测试前提条件刚好满足时能不能解前提条件不满足时规划器是否正确失败最大递归深度是多少写在最后HTN调试没有银弹唯一的方法就是多跑、多看日志、多分析错误信息。我的经验是80%的问题出在前提条件没写对或者状态转移没设计好。所以写完一个方法先问自己——这个方法的前提条件真的对吗分解出来的子任务能不能真的达到目标状态下篇打算写HDDL——HTN领域的标准化建模语言感兴趣可以关注一下。