上周调一个机器人导航Agent，遇到个典型问题：我给它下指令“去三楼会议室拿一份资料”，结果这家伙直接往三楼冲，到了才发现会议室门锁着，又折回来找我要钥匙。整个过程像极了刚入行的程序员——只盯着最终目标，缺了中间那层“任务拆解”的逻辑。今天咱们就聊聊Agent架构里最容易被轻视的环节：规划模块中的目标分解与任务规划。
从“一句话指令”到“可执行步骤链”
人类接到复杂任务时，大脑会自动做分层拆解。比如“筹备一场技术大会”，你会自然想到订场地、邀嘉宾、做宣传、安排设备等一系列子任务。但Agent没这本能，你得教它拆。早期我试过让LLM直接生成动作序列，结果常出现这种问题：
# 反面示例：别这样写defnaive_plan(goal):response=llm_call(f"请为'{goal}'生成步骤")returnparse_steps(response)# 这里踩过坑：LLM容易跳过关键依赖步骤某次测试“煮咖啡”任务，模型给出的步骤里居然忘了“插电源”。这种缺失关键前提的规划，在嵌入式场景里就是灾难——比如让机械臂“拧螺丝”却忘了“先移动到螺丝位置”。
任务规划的两种经典思路
自顶向下分解适合结构化强的领域。比如开发板烧录任务，可以预定义模板：
# 经验：硬件操作类任务适合模板化拆解defflash_firmware_task():steps=[("连接JTAG调试器",check_jtag_connection),("擦除Flash扇区",erase_sector,{"address":0x8000000}),("写入引导程序",write_bootloader),# 注意：这一步必须在擦除后执行("校验固件签名",verify_signature)]# 关键点：步骤间的依赖关系要显式声明add_dependency(steps[2],steps[1])动态重规划则应对变化环境。我做过一个仓储巡检Agent，遇到货架临时调整时，它会用树搜索重新规划路径：
defdynamic_replan(current_state,goal):# 用BFS在状态空间里找可行路径queue=deque([(current_state,[])])whilequeue:state,path=queue.popleft()ifsatisfy_goal(state,goal):returnpathforactioninvalid_actions(state):new_state=simulate_action(state,action)# 剪枝：避免重复状态（这里省过50%内存）ifnotvisited(new_state):queue.append((new_state,path+[action]))状态表示是隐形的基石
规划质量八成取决于状态表示。早期项目我用过纯文本描述状态，结果Agent分不清“门关着”和“门锁着”的区别。后来改成结构化表示：
classEnvironmentState:def__init__(self):self.objects={}# 对象属性字典self.relations=[]# 空间/逻辑关系self.constraints=[]# 物理约束defto_llm_prompt(self):# 技巧：把结构化状态转成自然语言时，保留关键数值returnf"当前位置:{self.objects['robot']['coord']}, 电量:{self.objects['robot']['battery']}%"特别提醒做硬件的朋友：一定要把物理约束显式写进状态。我曾调试过一个机械臂撞限位的问题，就是因为状态里没包含“关节角度范围”这个约束。
规划中的常见坑与绕坑指南
坑1：无限递归分解。某个任务拆解函数忘了设深度限制，把“写文档”拆成了“移动手指到键盘位置”→“收缩肌肉”→“触发神经信号”……现在我的代码里一定会加这个：
MAX_DEPTH=5# 经验值：超过5层的分解通常该换方法了defdecompose(task,depth=0):ifdepth>MAX_DEPTH:return[task]# 触底反弹，直接执行坑2：忽略执行反馈。规划不是一锤子买卖，得闭环。我的做法是在每个步骤后插入状态检查：
defexecute_with_monitoring(plan):forstepinplan:result=execute(step)ifnotresult.success:# 不是简单重试，而是根据失败类型调整ifresult.error=="PRECONDITION_NOT_MET":returnreplan_from_current()# 重新规划坑3：资源竞争没建模。多Agent协作时，两个任务同时申请串口，死锁了。后来在规划器里加了资源预约表：
resource_calendar={"uart1":[(9.5,10.0,"agent1")],# (开始时间, 结束时间, 使用者)"i2c_bus":[(9.7,9.9,"agent2")]}给动手实践者的几点建议
从简单领域开始练手。别一上来就搞自动驾驶的规划，先试试“让Agent整理文件夹”这种可控场景。我第一个规划模块就是做文档分类，状态空间小，容易验证逻辑。
可视化中间过程。一定要把规划器的决策树打日志存下来，用文本图表都行。上周我就是靠日志发现，Agent总在“先充电还是先执行”之间反复横跳，才定位到奖励函数设计问题。
混合方法往往更稳。纯学习的方法容易出奇葩规划，纯规则的方法又太死板。我现在常用规则生成初步规划，再用LLM做合理性校验，反过来也行。
留个“手动模式”接口。遇到规划器死活解不出的情况，要能人工注入步骤。生产环境里，这个逃生通道救过我三次。
规划模块像写代码时的架构设计，前期多花一天想清楚状态表示和依赖关系，后期能省掉一个月调试时间。下次咱们接着聊规划模块的进阶话题：如何让Agent在不确定环境中做概率规划。
下期预告：遇到“传感器读数不准”“动作执行失败”这些现实干扰时，规划模块该怎么应对？我们聊聊概率规划与重规划机制。
