当前位置：首页 > news >正文

006、规划模块（三）：分层任务网络与自动化规划器

news 2026/4/16 3:44:06

昨天深夜调一个机器人抓取流程，代码逻辑堆了三百多行if-else。当需求变成“先检查电池再决定是否取货”时，整个模块几乎重写。那一刻我盯着屏幕想：这堆面条代码，不就是缺个正经规划器吗？

从if-else地狱说起

很多项目起步时都这样：任务简单，直接硬编码。传感器触发A？执行动作X。条件B成立？跳转到Y。三个月后需求变更，代码变成迷宫，添加新功能像在雷区排雷。

上周看到同事的仓储机器人代码，判断逻辑里嵌套了五层条件。我问他：“如果中途需要充电怎么办？”他沉默了一会儿：“得加个标志位，再重写状态判断。”这就是典型的手动规划困境——人类大脑在代码里模拟状态机，迟早会溢出。

分层任务网络（HTN）是什么味道

HTN不像传统规划器那样搜索“动作序列”，它思考的是“任务分解”。想象你指挥一个机器人泡茶：

传统规划可能是：走到厨房->烧水->拿茶叶…
HTN的思维是：“完成泡茶任务”，这个高层任务可以分解为“准备热水”和“准备茶杯”两个子任务。“准备热水”又能分解为“接水”和“加热”。

实际代码里，HTN的吸引力在于它匹配人类思维。我们不会从头规划每个肌肉动作，而是自然分层思考。

# 一个简化的HTN结构示例classHTNMethod:def__init__(self,task,subtasks):self.task=task# 要分解的高层任务self.subtasks=subtasks# 分解后的子任务列表# 定义“递送包裹”的分解方法deliver_methods=[HTNMethod('递送包裹',['取包裹','规划路径','移动','交付']),HTNMethod('规划路径',['检测障碍','计算轨迹']),# 这里踩过坑：子任务顺序很重要，但别写死依赖，用前置条件更灵活]

真正的HTN规划器会维护任务栈，不断展开高层任务，直到所有任务都变成可执行的原语操作。这个展开过程可以很智能——同一个高层任务可能有多种分解方式，规划器根据当前世界状态选择最合适的。

自动化规划器怎么落地

实验室里的规划算法论文都很美，但产线环境是另一回事。去年给AGV部署规划模块时，发现学术界的标准HTN实现太“重”，每次重新规划要几百毫秒，机器人早撞墙了。

我们最后做了个混合架构：

高层用HTN做任务分解（秒级）
底层用行为树做实时执行（毫秒级）
中间加了个状态缓存层，避免重复规划

classProductionPlanner:def__init__(self):self.htn_solver=HTNSolver()# 处理“做什么”self.bt_executor=BehaviorTree()# 处理“怎么做”self.world_state={}# 别用全局变量，这里吃过亏defreplan_if_needed(self,state_change):# 只有关键状态变化才触发重新规划ifself._is_significant_change(state_change):# 从当前失败的任务层级开始重新分解，不是从头开始partial_plan=self.htn_solver.replan_from_failure(self.current_task_stack,self.world_state)# 保留还能用的部分规划，节省计算量self._merge_partial_plan(partial_plan)

这个架构的妙处在于：当传感器发现新障碍时，底层行为树立即避障（反射式），同时标记“路径受阻”状态；规划器在后台计算新路线，算好了无缝切换过去。用户只觉得机器人绕了一下，不知道内部已经重构了整个任务树。

调试HTN的实战技巧

HTN调试最头疼的是“规划结果看起来合理，执行起来出问题”。分享几个血泪教训：

给任务分解加日志钩子
每个方法分解时打印完整上下文，包括被拒绝的其他分解选项。很多时候问题不是选了错的分解，而是漏了正确的分解方法。
可视化任务栈
我们写了个简单的ASCII图形化工具，实时显示任务栈展开过程。看到某个任务反复分解又失败，基本能定位到前置条件没写对。
世界状态要版本化
规划器基于的世界状态必须是快照，不能是实时变化的。有次遇到规划时电池电量是30%，执行时变成29%，导致前置条件不满足。后来给状态加了时间戳，规划时用“规划时刻的状态”，执行时再检查状态是否依然有效。
设置规划超时
复杂任务可能有无穷的分解方式，必须设置超时和深度限制。超时后可以回退到“降级模式”——用更粗糙但确定的分解方法。