HTN 和 LLM 规划怎么配合？有没有冲突？
理解这个问题需要先回答一个更深层的问题：如果已经有了 LLM，为什么还需要 HTN？
LLM 擅长什么，缺少什么
LLM 擅长语义理解——把”帮我换一下 3 号防振锤，注意线路带电”这样的自然语言工单转化为结构化的任务描述，处理模糊意图，理解场景上下文。
但 LLM 的输出是文本，是概率性的，是无法形式化验证的。当它生成一个动作序列时，你无法用数学方式证明这个序列不包含危险的子任务组合，也无法自动检查它是否满足时序约束（“必须先断开接地线，再接触导线”）。对于高安全任务，这不是可以接受的。
HTN 擅长什么，缺少什么
HTN（分层任务网络）做的事情恰好相反：它的输入是结构化的任务描述（不是自然语言），输出是可以被形式化验证的行动计划——每个算子的前置条件和效果都有精确的逻辑定义，分解过程是可追溯的，合法性是可机械检验的。
但 HTN 不能处理自然语言，不能理解上下文意图，不能处理训练数据之外的语义模糊。知识库里没有定义的任务类型，HTN 规划器无法处理。
两者的配合：串行流水线
配合方式是串行流水线，职责不重叠：
自然语言工单
↓
[LLM] 语义解析 → 结构化任务描述 (Proposal P)
↓
[HTN] 形式化分解 → 行动计划 (ActionPlan A)
↓
接口 A → Spine 层执行
LLM 负责语义层的理解，HTN 负责任务层的形式化分解。职责界限由接口协议强制划定——LLM 不直接生成电机指令，HTN 不处理自然语言——因此不存在功能重叠，也不存在谁覆盖谁的冲突。
已知的失效模式
若 LLM 输出的任务描述包含 HTN 知识库中未预定义的任务类型，规划器找不到合法的分解路径，任务失败，系统触发 FAILSAFE Jump，请求人工接管。
这是符号 AI 规划方法的普遍局限——知识库的覆盖边界就是系统自主能力的边界。EICPS 不假装这个局限不存在，而是设计了清晰的失效上报路径：规划失败 → FAILSAFE 模态 → 人工接管请求。在高安全场景中，“我不知道怎么做”比”随意尝试”更安全。