上周调一个机器人导航Agent遇到个典型问题我给它下指令“去三楼会议室拿一份资料”结果这家伙直接往三楼冲到了才发现会议室门锁着又折回来找我要钥匙。整个过程像极了刚入行的程序员——只盯着最终目标缺了中间那层“任务拆解”的逻辑。今天咱们就聊聊Agent架构里最容易被轻视的环节规划模块中的目标分解与任务规划。从“一句话指令”到“可执行步骤链”人类接到复杂任务时大脑会自动做分层拆解。比如“筹备一场技术大会”你会自然想到订场地、邀嘉宾、做宣传、安排设备等一系列子任务。但Agent没这本能你得教它拆。早期我试过让LLM直接生成动作序列结果常出现这种问题# 反面示例别这样写defnaive_plan(goal):responsellm_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在状态空间里找可行路径queuedeque([(current_state,[])])whilequeue:state,pathqueue.popleft()ifsatisfy_goal(state,goal):returnpathforactioninvalid_actions(state):new_statesimulate_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_DEPTH5# 经验值超过5层的分解通常该换方法了defdecompose(task,depth0):ifdepthMAX_DEPTH:return[task]# 触底反弹直接执行坑2忽略执行反馈。规划不是一锤子买卖得闭环。我的做法是在每个步骤后插入状态检查defexecute_with_monitoring(plan):forstepinplan:resultexecute(step)ifnotresult.success:# 不是简单重试而是根据失败类型调整ifresult.errorPRECONDITION_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在不确定环境中做概率规划。下期预告遇到“传感器读数不准”“动作执行失败”这些现实干扰时规划模块该怎么应对我们聊聊概率规划与重规划机制。