Planning Module Basics: Subgoal Decomposition and Cascading Execution in Single-Path Reasoning
We start with a cup of coffee and explore how a robot breaks “make coffee” into a chain of interlocked commands, and how it gracefully recovers when things go wrong.
Introduction: Why Does Even Making Coffee Require “Planning”?
Imagine you walk into a kitchen. Your goal is a cup of pour-over coffee. Your brain does not output the atomic action “drink coffee.” Instead, it automatically unfolds a tiny checklist: boil water -> grind beans -> bloom -> pour -> enjoy. If the kettle is empty, you know to refill it first. The process is so natural that you barely notice you are “planning.”
But for a robot, this is a disaster. It lacks your common sense and your years of muscle memory. Hand it the command make coffee, and it faces a blank action space. What now?
Do not worry. In this article we explore the most basic and elegant technical path inside the planning module: subgoal decomposition and cascading execution under single-path reasoning. It sounds like jargon, right? No problem. We will unwrap it layer by layer, like peeling a coffee filter. Our cognitive route is: see the whole waterfall first (macro), then observe the gears of the flow (meso), and finally track the trajectory of every single drop (micro).
Section 1 Macro View: What Is Single-Path Reasoning? Why Not a Lush Decision Tree?
1.1 Starting with a Counter-Intuitive Question
If we ask a robot to make coffee, our intuition might say: give it a huge search tree where every node branches into countless possibilities – French press, Moka pot, instant. More choices means smarter, does it not?
But wait. In real robotic systems, multi-path search is often a luxury. Why? Because every branch means exponential state explosion. Imagine your robot standing in a kitchen. Its sensors tremble in noise. The battery is at 20%. A human coworker is waiting for coffee. At this moment, the robot really has no leisure to compare seventeen extraction schemes.
Therefore, engineering more often adopts single-path reasoning: given a high-level goal, the system follows a predefined decomposition chain all the way down until it hits executable primitive actions. No backtracking, no branching. Like a waterfall, water flows in only one direction.
1.2 If We Drew a Picture, What Would It Look Like?
Imagine a vertical waterfall diagram. At the very top is a light-blue box with your overall goal. Three thin lines hang down from it to a method box – this method box acts like a filter paper, turning the coarse goal into three side-by-side subtasks. Further down, each subtask drops even thinner lines, eventually converging on a bottom row of orange boxes: those are the primitive actions the robot truly understands, such as heat_water, grind_beans, pour_brew.
There are no diamond decision nodes in this picture, no “OR” branches. It is a deterministic cascade. You might ask: is this not too rigid? Indeed, but the advantage of single-path is precisely predictability and verifiability – in industrial robotics and human-robot collaboration scenarios, this matters far more than “smarter but unexplainable” behavior.
1.3 Anchor to the Known: Does This Resemble an Unrolled RNN?
If you are familiar with deep learning, here is a wonderful analogy. Single-path reasoning is very much like unrolling an RNN across time steps: given an initial state, information propagates along a chain, and the output of each step becomes the input of the next. No parallel branches, no skip connections (at least not in the simplest version). Just as an RNN uses the same cell for different time steps, our planner uses the same decomposition logic for different levels of subgoals.
The only difference is that an RNN passes hidden-state vectors, while we pass a set of world states.
1.4 Toy Example: Three Lines of Code to See the Single Path
Let us feel the waterfall with the least amount of code. Below is a minimal single-path decomposer: a high-level goal maps directly to a fixed subtask sequence. No search, no branching.
# Single-path decomposition: direct mapping from Goal to Primitives
SINGLE_PATH_METHODS = {
"make_coffee": ["boil_water", "grind_beans", "brew_french_press"],
"boil_water": ["fill_kettle", "heat_water", "pour_into_pot"],
}
def decompose_single_path(goal):
"""Unroll the goal linearly into a primitive sequence, like unrolling an RNN."""
plan = []
stack = [goal]
while stack:
task = stack.pop(0) # FIFO: preserve order
if task in SINGLE_PATH_METHODS:
stack.extend(SINGLE_PATH_METHODS[task]) # cascade expansion
else:
plan.append(task) # hit bottom: primitive action
return plan
print(decompose_single_path("make_coffee"))
# ['fill_kettle', 'heat_water', 'pour_into_pot',
# 'grind_beans', 'brew_french_press']
See? make_coffee unzips downward into five primitives. This is the cascading expansion of single-path reasoning.
Section 2 Meso View: The Three-Layer Mesh of HTN – How Do Task, Method, and Operator Turn Like Gears?
2.1 From Intuition to Formalization
Now we have seen the outline of the waterfall. But why does the water automatically flow downward? What force turns the fuzzy intention “make coffee” into the precise actions “boil water” and “grind beans”?
Here we need to introduce a classic formal framework: Hierarchical Task Networks (HTN). It is one of the most solid theoretical foundations for single-path reasoning. The core idea of HTN: any complex task is compound, and a compound task must be decomposed via a method into a smaller subtask network; when the decomposition can go no further, we meet a primitive operator, which directly corresponds to a change in state.
Sounds abstract, right? Picture it as a three-layer gearbox:
- Top gear (Compound Task): large gear, turns slowly, represents a high-level intention like “make coffee.”
- Middle gear (Method): transmission gear, responsible for breaking the large gear’s rotation into medium-gear speed. Note that a machine can store multiple middle gears (multiple methods), but in single-path mode we only engage one at a time.
- Bottom gear (Primitive Operator): small gear, actually drives the robot arm or heater; every turn changes the physical state of the world.
2.2 Visualizing the Three-Layer Mesh
If this were drawn on paper, it would look like a cutaway mechanical watch. The large gear on the left (Compound Task) meshes with the middle method gear (Method), which in turn drives the subtask chain on the right (Subtask Network). The small gear at the bottom (Operator), once it turns, pushes the state pointer on the far right (World State) from Statet to Statet+1.
2.3 Anchor to the Known: Does This Resemble a Function Call Stack?
If you have ever written code, here is a perfect analogy. The HTN decomposition process is almost exactly the dynamic unwinding of a function call stack:
make_coffee()is the top-level function.- Inside it,
boil_water(),grind_beans(),brew()are called in order. - Each subfunction keeps calling lower-level APIs until it hits hardware instructions (primitive operators).
The only difference is that in HTN the “function body” is not hard-coded; it lives as a template in a method library. This lets the robot shift to different “gears” in different scenes – as long as the library holds the corresponding entry.
2.4 Code: Explicit Expression of the Three-Layer Structure
The code below makes the three-layer gears fully explicit. Note the preconditions inside the Method object: in single-path reasoning, a method itself can have preconditions, just like checking parameter validity before a function call.
from dataclasses import dataclass
from typing import List, Set
@dataclass
class Operator:
"""Bottom small gear: primitive action that directly changes the world."""
name: str
pre: Set[str] # conditions the world must satisfy before execution
eff_add: Set[str] # facts added after execution
eff_del: Set[str] # facts deleted after execution
@dataclass
class Method:
"""Middle transmission gear: breaks a compound task into a subtask sequence."""
name: str
for_task: str # which compound task this method serves
pre: Set[str] # preconditions for engaging this method
subtasks: List[str] # single-path: fixed subtask order
@dataclass
class CompoundTask:
"""Top large gear: high-level intention."""
name: str
# Method library: our "gearbox"
METHOD_LIB = {
"make_coffee": [
Method("FrenchPress", "make_coffee", {"have_beans"},
["boil_water", "grind_beans", "brew_french_press"])
]
}
# Operator library: our "bottom-level API"
OPERATOR_LIB = {
"boil_water": Operator("boil_water",
{"water", "kettle"},
{"hot_water"}, set()),
"grind_beans": Operator("grind_beans",
{"beans", "grinder"},
{"grounds"}, set()),
"brew_french_press": Operator("brew",
{"hot_water", "grounds", "french_press"},
{"coffee"},
{"hot_water", "grounds"}),
}
def decompose_htn(task: str, state: Set[str]) -> List[str]:
"""HTN single-path decomposition: recursive descent like unwinding a call stack."""
if task in OPERATOR_LIB:
return [task] # hit bottom: primitive
if task in METHOD_LIB:
for method in METHOD_LIB[task]: # single-path: pick first applicable method
if method.pre.issubset(state):
plan = []
current_state = set(state)
for sub in method.subtasks:
sub_plan = decompose_htn(sub, current_state)
plan.extend(sub_plan)
# simulate execution to update state (cascade effect)
for op_name in sub_plan:
op = OPERATOR_LIB[op_name]
current_state -= op.eff_del
current_state |= op.eff_add
return plan
raise ValueError(f"No applicable method or operator for: {task}")
# Run
s0 = {"water", "kettle", "beans", "grinder",
"french_press", "have_beans"}
plan = decompose_htn("make_coffee", s0)
print("HTN Plan:", plan)
# HTN Plan: ['boil_water', 'grind_beans', 'brew_french_press']
Aha, see that recursion? decompose_htn is like eval() on an expression: hit a compound task and expand, hit a primitive and stop. This is the essence of subgoal cascading.
Section 3 Micro View: The State Relay Race – The Cascade Mechanism of Preconditions and Effects
3.1 From Gears to Water Drops: How Does State Flow?
Now we understand the gearbox structure. But the turning of gears itself produces no meaning; the change of state does. Imagine state as water flowing in a pipe. Each primitive operator is a special pipe segment: it has an inlet valve (Precondition) that only opens when the water carries specific ingredients; it also has a chemical filter (Effect), so the molecular composition of the outflow has already changed.
In a single-path cascade, these pipes are serial. The water exiting the first segment must satisfy the inlet valve of the second. If the previous step did not produce hot_water, the brew valve stays shut and the entire cascade breaks.
3.2 Progressive Disclosure: From Atomic State to Vector Level, Then to Matrix Level
Do not rush. Let us look at the smallest case first. Suppose the world state has only 3 Boolean dimensions: hot_water, grounds, coffee. At time t, the state can be represented as a 3-dimensional binary vector st = [0, 0, 0].
- The effect of
boil_watersets dimension 0 to 1. - The effect of
grind_beanssets dimension 1 to 1. - The precondition of
brewrequires dimensions 0 and 1 to both be 1. Then its effect sets dimension 2 to 1 while clearing dimensions 0 and 1 (they are consumed).
If drawn as a diagram, this is like a state-vector relay track:
In real robotic systems, the state is not a 3-D vector but a sparse symbolic set of thousands of dimensions (objects, poses, forces…). Yet the logic is exactly the same: each operator only touches a few dimensions, like a sparse weight matrix in a fully-connected layer, except here the connections are symbolic and interpretable.
3.3 Anchor to the Known: Does This Resemble Forward Propagation in a Neural Network?
Treat the state vector s as input features and the operator as a sparse transformation layer:
- Precondition: equivalent to a mask, checking whether the input satisfies specific conditions.
- Effect: equivalent to a residual update, st+1 = st - del + add.
Cascading planning is simply stacking these sparse layers sequentially and performing forward propagation. No backpropagation, no gradients, but the direction of information flow is strikingly similar to a forward pass in deep learning. This makes engineers coming from a neural-network background feel at home – planning is not magic, it is just another kind of forward computation graph.
3.4 Code: Explicit Simulation of the State Relay
The code below makes the state flow fully explicit. Note the apply method: it is a miniature “world-state update layer.”
class WorldState:
"""Encapsulate state into a traceable vector for easy cascade observation."""
def __init__(self, facts: Set[str]):
self.facts = set(facts)
def apply(self, op: Operator) -> "WorldState":
if not op.pre.issubset(self.facts):
missing = op.pre - self.facts
raise RuntimeError(
f"Precondition failed for {op.name}: missing {missing}"
)
new_facts = set(self.facts)
new_facts -= op.eff_del
new_facts |= op.eff_add
return WorldState(new_facts)
def __repr__(self):
return f"State({sorted(self.facts)})"
def simulate_cascade(plan: List[str], initial: Set[str]):
"""Simulate single-path cascade: execute the plan step by step like forward propagation."""
state = WorldState(initial)
trace = [("init", state)]
for op_name in plan:
op = OPERATOR_LIB[op_name]
state = state.apply(op)
trace.append((op_name, state))
return trace
# Run the state relay
trace = simulate_cascade(plan, s0)
for step, st in trace:
print(f"{step:20s} -> {st}")
# init -> State(['beans', 'french_press', 'grinder',
# 'have_beans', 'kettle', 'water'])
# boil_water -> State(['beans', 'french_press', 'grinder',
# 'have_beans', 'hot_water', 'kettle'])
# grind_beans -> State(['french_press', 'grinder', 'grounds',
# 'have_beans', 'hot_water', 'kettle'])
# brew_french_press -> State(['coffee', 'french_press', 'grinder',
# 'have_beans', 'kettle'])
See that state stream? hot_water and grounds behave like two temporary variables: generated, passed along, and finally consumed inside brew to produce the ultimate coffee. This is the micro-dynamics of subgoal cascading.
Section 4 Meso-Micro Interweaving: What If Execution Breaks? – Pre-image Fallback and Execution Monitoring
4.1 Ideal Is Plump, Reality Is Bony
Up to now we have assumed a fairy-tale world: when the robot executes boil_water, the kettle never boils dry; when it executes grind_beans, beans never get stuck. But reality? Sensors have noise. Actuators drift. A human coworker might suddenly take the coffee beans away.
If one step in the cascade fails, the entire waterfall dries up. What then? Replan from scratch? That is wasteful – maybe you only need to put the beans back and continue grinding, without re-boiling the water.
This leads to a key question: execution monitoring. We need a mechanism that lets the robot ask itself after every step: “Does the current world state still allow me to continue the suffix of the original plan?”
4.2 Pre-image: Buying Insurance for the Future
The answer comes from a classic concept: Pre-image (also called pre-image backchaining in robotics, or goal regression in AI planning). Its intuition is beautiful:
Suppose you have a goal state G and a plan suffix pi = [ai, ai+1, …, an]. The pre-image answers: in what set of states can we start this suffix and guarantee arrival at G?
If drawn as a picture, it is not a forward waterfall but a reverse searchlight: starting from the final goal, the beam shines backward against the action flow, illuminating all “safe starting points.” As long as the current state falls inside the beam, the plan can continue; if it falls outside, replanning must be triggered.
If this were animated, it would look like an EKG monitor. Every time the executor beats (completes an Op), the monitor checks the pulse (checks whether the current state lies inside the pre-image). Once the pulse is abnormal (state out of bounds), first aid is activated immediately (Replan).
4.3 Anchor to the Known: Does This Resemble Gradient Checkpointing in RNNs?
If you have trained large RNNs or Transformers, you know a technique called gradient checkpointing: save an intermediate state every few steps; if the GPU OOMs later, recover from the nearest checkpoint instead of recomputing from scratch.
Pre-image execution monitoring is the “checkpoint mechanism” of planning. Each pre-image defines a logical checkpoint: as long as the state stays inside the checkpoint zone, you are safe; once outside, replan from the current state rather than from t=0. This dramatically reduces replanning cost.
4.4 Code: A Minimal Execution-Monitoring Loop
The code below shows how to embed the pre-image concept into an execution loop. For simplicity, we approximate the pre-image by the union of preconditions of all operators in the plan suffix – a common conservative estimate in engineering.
def compute_preimage(plan_suffix: List[str]) -> Set[str]:
"""
Conservative estimate: union of preconditions of all primitives in suffix.
Real BHPN systems perform recursive regression; we use a simplified version
to preserve intuition.
"""
needed = set()
for op_name in plan_suffix:
op = OPERATOR_LIB[op_name]
needed |= op.pre
return needed
def execute_with_monitor(plan: List[str], initial: Set[str]):
"""Execution loop with monitoring: like inserting assertion checks into forward propagation."""
state = WorldState(initial)
for i, op_name in enumerate(plan):
suffix = plan[i+1:]
preimage = compute_preimage(suffix)
# Pre-execution monitor: is current state still in the safe zone?
if not preimage.issubset(state.facts) and suffix:
print(f"ALERT at step {i}: state left preimage of suffix!")
print(f" Missing for future: {preimage - state.facts}")
# trigger local replan (simplified: insert a repair action)
state = handle_failure(state, preimage - state.facts)
op = OPERATOR_LIB[op_name]
state = state.apply(op)
print(f"OK {op_name:20s} -> {state}")
return state
def handle_failure(state: WorldState, missing: Set[str]) -> WorldState:
"""Local repair: like inserting a recovery subroutine."""
for fact in missing:
if fact == "hot_water":
print(" [Replan] Re-boiling water...")
state = state.apply(OPERATOR_LIB["boil_water"])
return state
# Simulate a broken scene: someone drank the hot_water before brewing
s_broken = {"water", "kettle", "beans", "grinder",
"french_press", "have_beans"}
execute_with_monitor(plan, s_broken)
# OK boil_water -> State([... 'hot_water' ...])
# OK grind_beans -> State([... 'grounds', 'hot_water' ...])
# ALERT at step 2: state left preimage of suffix!
# Missing for future: {'hot_water'}
# [Replan] Re-boiling water...
# OK brew_french_press -> State(['coffee', ...])
In this toy example, the robot discovers hot_water is gone before executing brew (someone drank it), so it triggers a local replan, re-boils the water, and then finishes the coffee. This is the embryonic form of robust cascading.
Section 5 Macro Outlook: When Symbolic Planning Meets LLM – The ChatHTN Hybrid Architecture
5.1 The Bottleneck of Old Methods
We have now walked through the complete chain of single-path HTN: decomposition -> cascade -> monitor -> repair. But one old problem always remains: where does the method library come from?
Traditional HTN requires engineers to hand-write every Method’s preconditions and subtasks. This is maintainable in closed domains such as industrial assembly or search-and-rescue robots, but in open worlds (e.g., home service robots) you cannot pre-write a method for “how to make a birthday cake for a cat.”
Sounds abstract, right? Do not worry. Recent foreign research points to a brilliant way out: let the symbolic planner marry the LLM.
5.2 ChatHTN: Symbolic Skeleton + Neural Flesh
In 2025, Munoz-Avila, Aha, and Rizzo proposed ChatHTN. Its architecture is like a twin-tower bridge:
- Left tower (Symbolic Planner Core): a traditional SHOP2-style HTN planner, guaranteeing provably sound behavior.
- Right tower (LLM Fallback): when the planner encounters a task with no method in the knowledge base, it queries ChatGPT for an approximate decomposition proposal.
- Middle suspension cable (Verifier): the decomposition returned by the LLM is not executed directly. It is wrapped into a Verifier Task, and the symbolic module checks whether its effects truly achieve the parent task’s goal.
If verification passes, the LLM-generated decomposition is admitted into the cascade; if not, the system can retry or request human intervention.
If this were drawn as an architectural cross-section, the left tower is reinforced concrete (hard logic), the right tower is a glass curtain wall (soft reasoning), and the Verifier in the middle is a seismic damper, ensuring the whole bridge does not collapse during flexible swaying.
5.3 Online Learning: From One-Shot Query to Lifelong Accumulation
A further extension is Online Learning of HTN Methods. The system does not discard the LLM’s suggestion after use; instead, it generalizes the suggestion into a reusable method template (lifting concrete constants to variables) and stores it in the method library. This is like an intern needing to ask the boss the first time they make a PowerPoint, but being able to use the template themselves the second time. Experiments show this online learning can reduce LLM query counts by up to 75% while maintaining or even improving problem coverage.
5.4 Code: LLM as a Method-Generator Interface
The code below shows the skeleton of a hybrid planner. Note that llm_decompose is a placeholder; a real system would call the GPT-4 API, but the interface design keeps the symbolic side pure.
import random
class HybridHTNPlanner:
"""ChatHTN-style hybrid planner: symbolic backbone + LLM patch."""
def __init__(self, operators, methods, llm_client=None):
self.ops = operators
self.methods = methods # dynamically extensible method library
self.llm = llm_client
self.llm_calls = 0
def llm_decompose(self, task: str, state: Set[str]) -> List[str]:
"""Simulate LLM query: return a primitive sequence proposal."""
self.llm_calls += 1
# In a real system, this would build a prompt and call GPT-4.
# We use a heuristic mock to demonstrate the concept.
if task == "make_latte":
return ["boil_water", "grind_beans",
"steam_milk", "pull_espresso", "combine"]
return ["unknown_primitive"]
def verify_decomposition(self, task: str, subtasks: List[str],
state: Set[str]) -> bool:
"""Verifier: simulate the proposed decomposition and check
whether it achieves the high-level effect."""
try:
sim_state = set(state)
for sub in subtasks:
if sub in self.ops:
op = self.ops[sub]
if not op.pre.issubset(sim_state):
return False
sim_state -= op.eff_del
sim_state |= op.eff_add
# Simplified: check whether a key effect related to task is produced
return "coffee" in sim_state or "latte" in sim_state
except Exception:
return False
def plan(self, task: str, state: Set[str]) -> List[str]:
"""Main entry: recursively decompose like ChatHTN,
falling back to LLM when necessary."""
if task in self.ops:
return [task]
# 1. Try symbolic method library
if task in self.methods:
for method in self.methods[task]:
if method.pre.issubset(state):
plan = []
cur = set(state)
for sub in method.subtasks:
sub_plan = self.plan(sub, cur)
plan.extend(sub_plan)
for op_name in sub_plan:
op = self.ops[op_name]
cur -= op.eff_del
cur |= op.eff_add
return plan
# 2. Symbolic knowledge gap: fall back to LLM (ChatHTN strategy)
if self.llm:
proposal = self.llm_decompose(task, state)
if self.verify_decomposition(task, proposal, state):
# Learn: cache as a generic method (Online Learning)
self.methods.setdefault(task, []).append(
Method(f"LLM_{task}", task, set(), proposal)
)
return proposal
raise ValueError(f"Unsolvable task: {task}")
# Demo: assume our library originally cannot make latte
METHOD_LIB_HYBRID = dict(METHOD_LIB) # copy from earlier library
planner = HybridHTNPlanner(OPERATOR_LIB, METHOD_LIB_HYBRID,
llm_client=True)
# Simulate a task known to the LLM
# Note: this is a mock; a real system would call ChatGPT
try:
latte_plan = planner.plan("make_latte", s0 | {"milk"})
print(f"Hybrid plan for latte: {latte_plan}")
print(f"Total LLM calls: {planner.llm_calls}")
except ValueError as e:
print(e)
Although this code simplifies the LLM call details, it fully preserves the three-layer philosophy of ChatHTN: symbolic first -> LLM patch -> verify and learn. This is the bridge that takes modern single-path planning from “purely manual” to “semi-automatic evolution.”
Closed-Loop Ending: What Does This Mean in Training and Deployment?
All right, we have walked together from the macro waterfall to the micro state flow, and then to the hybrid architecture. Now let us zoom out and ask ourselves: what do these principles actually change in a real project?
What It Means During Training
If you are building a planning module for a robot or agent, the greatest gift of single-path HTN cascading is an interpretable data structure. Every failure case can be precisely traced: was a method precondition unsatisfied? Was a state handoff broken? Was a primitive operator’s effect description wrong? This is far easier to debug than an end-to-end black-box policy network. You can step through the recursive unwinding of decompose_htn like debugging a program, observing the exact change of the state vector at every step.
What It Means During Deployment
At real runtime, pre-image monitoring is your first line of defense against uncertainty. It does not require retraining a model; you only need a few set operations on the state machine to give the system local self-healing capability. And if you connect an LLM (as in the ChatHTN architecture), always keep the symbolic verification layer – never feed LLM output directly to the actuator. That is using a glass curtain wall as a load-bearing wall.
Recommended Reading
If you want to dig deeper, we suggest this order:
- Primer: Georgievski & Aiello (2014), HTN survey, to build formal intuition.
- Classic: Erol et al. (1994), HTN formal semantics, to understand strict definitions of preconditions and effects.
- Execution Monitoring: MIT’s BHPN system papers (Kaelbling & Lozano-Perez), to master the robotics perspective of pre-image backchaining.
- Frontier: Munoz-Avila et al. (2025), the original ChatHTN paper, to see how symbolic and LLM interweave seamlessly.
- Application: MERL’s assembly-robot HTN papers, to observe how industry handles parallel and sequential constraints.
We started with a cup of coffee and finally arrived at the heart of AI planning. Next time you see a robot calmly brew a cup of coffee, may you smile and recognize the waterfall behind it – subgoals cascading, states relaying, the most朴素 beauty of intelligence built by engineers with symbols and code.
End of article.
477
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
