我先说明一下这章“规划 Planning”我打算用两条线索串起来一条是当前大模型 Agent 里最热的任务规划与拆解另一条是物理世界里机器人、网络、系统的规划算法与实践。两边看似离得远但底层思考方式高度一致。这篇我尽量把算法原理、工程选型和踩坑经验揉在一起让你既能理解“规划是什么”也知道“规划怎么做”。1. 为什么所有复杂系统最后都绕不开“规划”这一关规划这个词在不同领域里指向的东西完全不一样。在 AI Agent 里规划是任务拆解与执行路径的设计在机器人领域规划是让机械臂或小车从 A 点走到 B 点的一条无碰撞轨迹在网络领域规划是 IP 地址段、路由策略、带宽资源的分配方案在项目管理里规划是把一个模糊目标变成可执行任务列表的过程。我之前带过几个不同方向的项目后来发现一个有意思的现象无论哪个领域只要系统复杂度上来了“下一步该干什么”这个问题就一定会出现而解决这个问题的手段本质上都是规划。哪怕是最简单的扫地机器人它也得先知道自己在哪、要去哪、中间有没有障碍然后才能决定轮子怎么转。这个过程分成两块全局路径规划负责“走哪条路”局部轨迹规划负责“每一步怎么走”。两者缺一不可。所以我想借这章把“规划”这件事从多个维度拆开讲。你看那些热搜词里有 agent 核心模式、路径规划算法、机械臂轨迹规划、网络规划设计师、系统规划与管理师其实它们都指向同一个内核在约束条件下找到一条从当前状态到目标状态的可行路径。差别只在于状态空间、约束条件和评估标准不同。理解了这一点你再去看那些具体的算法和技术就不会觉得它们是孤立的知识点而会自然地形成一张知识网络。这也是我写这一章的初衷。2. Agent 的规划能力从 ReAct 到 Planning Executor 再到任务拆解的本质2.1 Agent 为什么需要规划大模型不是万能的这两年大模型 Agent 火得不行但很多人忽略了一个基础问题模型本身只是一个“下一步预测器”它擅长的是根据上下文生成一段合理的回复而不是在一长串需要多步工具调用的任务里自动保持方向感。打个比方你让模型直接写一篇一万字的行业报告它可能开头写得很好写到一半就忘了前面说过什么甚至开始重复。这不是模型笨而是它的上下文窗口和注意力机制决定了它不适合一次性完成超长任务。这个时候就需要规划——把一万字的报告拆成“收集资料、搭框架、写第一章、写第二章、复核修订”这样一个个小步骤每步单独执行再把结果拼起来。Agent 界最常见的两种模式ReAct 和 Plan-and-Execute也就是 Planning Executor。ReAct 是“边想边做”模型每一步都根据当前观察决定下一步动作好处是灵活坏处是容易跑偏。Planning Executor 则是“先想后做”先生成一份完整的计划再按计划执行每一步执行完如果没问题就不重新规划。从我实际测试的经验看简单任务用 ReAct 就够了它灵活、响应快。但一旦任务涉及多个工具、多轮数据处理ReAct 就很容易陷入循环或者遗忘原始目标。这个时候 Planning Executor 明显更稳因为计划本身就是一种“外部记忆”它把任务目标固化在列表里模型每一步只要对照计划执行就行。2.2 任务规划与拆解到底是模型的能力还是 Agent 的能力这个问题的答案有点微妙拆解任务的能力来自模型但把拆解结果稳定落地的能力来自 Agent 架构。我解释一下。你让 GPT-4 这类模型“帮我策划一场三天的杭州旅行”它天然就能给出“第一天西湖、第二天灵隐寺、第三天西溪湿地”这样的拆解。这说明模型本身具备任务分解的语义理解能力。但你直接让它执行这个计划它做不到因为它没有订票、查天气、导航的接口。所以 Agent 的价值在于第一把模型拆解出来的计划变成可执行的工具调用序列第二在执行过程中处理各种异常API 超时、数据缺失、结果不符合预期第三把每一步的结果汇总回计划决定是继续执行还是调整计划。反过来说如果一个 Agent 拆解任务总是拆得乱七八糟那问题多半出在 Prompt 里对任务目标、约束条件、输出格式的描述不够清晰而不是 Agent 框架本身不行。你需要在 Prompt 里明确告诉模型你是谁、目标是什么、有哪些资源可用、最终输出长什么样。模型在清楚上下文的情况下拆解质量会显著提升。2.3 实操手写一个最小的 Planning Executor 框架说了这么多不如直接看代码。下面是我在项目里经常用的一种极简实现去掉工程细节保留核心逻辑from typing import Callable, Any class SimplePlanner: def __init__(self, model_fn: Callable, tools: dict): self.model_fn model_fn self.tools tools def make_plan(self, task: str) - list[str]: prompt f 你是一个任务规划器。请把以下任务拆解为3-6个可执行的步骤。 每个步骤必须具体、可独立执行。只输出步骤列表不要多余解释。 任务{task} response self.model_fn(prompt) steps [s.strip() for s in response.split(\n) if s.strip()] return steps def execute_step(self, step: str) - Any: # 从步骤文本中识别需要调用的工具和参数 if 查询 in step: return self.tools[search](step) elif 计算 in step: return self.tools[calculator](step) else: return self.model_fn(step) def run(self, task: str) - list[Any]: plan self.make_plan(task) results [] for i, step in enumerate(plan): print(f[步骤 {i1}/{len(plan)}] {step}) result self.execute_step(step) results.append(result) # 可选让模型根据执行结果决定是否需要调整后续计划 return results这个框架虽然简单但它体现了一个核心思想计划生成和执行分离。生成计划是一次模型调用执行每一步是独立的工具调用。中间的results列表相当于一个“执行日志”方便你回溯哪里出了问题。我自己的经验是真正用起来之后有几个细节必须做扎实否则框架再漂亮也白搭计划要带编号和状态待执行、执行中、已完成、失败重试。没有状态跟踪Agent 一遇到错误就不知道接下来该干嘛了。步骤之间的依赖要显式声明。比如“下载文件”必须在“解析文件”之前这种依赖关系不能靠模型自觉要写清楚。执行失败的兜底策略。我一般会让模型在失败后重新规划“重试一次”还是“跳过”还是“改换方法”。这个决策本身也是一次规划。2.4 规划的粒度控制拆得太细会慢拆得太粗会废任务拆解不是越细越好。我最初做 Agent 应用时吃过亏把一个简单的“整理会议纪要”任务拆成了十几个步骤结果每一步都调用一次模型延迟高得离谱用户根本等不起。反过来拆得太粗也不行。你让 Agent“写一份产品需求文档”如果不告诉它先写背景、再写用户故事、再写验收标准它就容易东一榔头西一棒子输出结构混乱。我的经验是拆解粒度参考两条标准每个步骤的执行时间应该控制在 3-5 秒以内。如果一步要跑很久说明它内部还有可拆的空间。每个步骤完成后应该能产出一个可验证的中间结果。比如“生成文章大纲”完成后你肉眼能判断大纲质量“调用搜索 API”完成后你能看到返回内容是否为空。我管这叫“可验证的最小执行单元”。做到这一点你的 Agent 就成功了一大半。这里顺手提一句 agent 的核心模式。除了 ReAct 和 Planning Executor业界还有 Reflexion反思后重做、Toolformer自学习用工具、多 Agent 协作等模式。但不管模式怎么变底层都离不开“规划-执行-反馈-再规划”这个闭环。你把闭环打通了模式只是一个外壳。3. 从虚拟到物理机器人路径规划与轨迹规划算法实战3.1 路径规划的基础空间建模与图搜索现在我们把视野从大模型转向物理世界的机器人。路径规划要解决的问题是在已知或未知的环境中找到一条从起点到终点的可行路径并且避开障碍物。第一步是空间建模。你不能直接拿真实世界的地图跑去搜索得先把环境抽象成机器人能理解的数据结构。常见做法有三种栅格地图把环境切成一个个小格子、几何地图用多边形表示障碍物、拓扑地图把环境抽象成节点和边。栅格地图最直观也最容易实现。你把一张图切分成 N×M 的网格每个格子标记为“空闲”或“占用”然后路径规划就变成了从起点格子走到终点格子的搜索问题。A* 算法是这类问题的经典解法它用一个启发函数估计当前格子到终点的距离优先搜索“看起来最有希望”的格子效率比 Dijkstra 高很多。3.2 Hybrid A* 与泊车路径规划为什么普通的 A* 不够用普通 A* 适合在栅格地图上做路径搜索但它的输出是一条折线路径机器人只能在一系列离散格子的中心点上移动方向也是离散的通常是上下左右加四个对角。这对扫地机器人可能够用但对需要精确控制方向的车比如自动泊车来说完全不行。泊车场景里的经典方案是 Hybrid A*。它和普通 A* 的区别在于它的搜索节点不再是一个个格子而是带航向角的车辆状态 (x, y, yaw)状态转移函数也换成了真实的车辆运动学模型比如阿克曼转向模型。这样搜索出来的路径就是车辆真正能开出来的轨迹而不是理论上有直角转弯的折线。我在做自动泊车项目时第一次用普通 A* 规划出来的路径仿真里看很漂亮一放到实车上就拉胯——因为直角转弯的路径车辆根本走不出来。换成 Hybrid A* 之后路径平滑了很多但计算量也上来了。对实时性要求高的场景还需要加一步优化先粗搜索得到一条可行走廊再用数值优化比如梯度下降或者曲线插值把路径打磨平滑。3.3 RRT 系列算法高维空间与未知环境的救命稻草A* 和 Hybrid A* 都要求环境已知且建模完整但很多场景比如勘探无人机、救援机器人环境是未知或动态变化的这时候 RRT快速扩展随机树就成了首选。RRT 的基本思路很反直觉不用搜索而是“随机撒点”。算法从起点开始随机在地图上生成一个采样点然后找到树上离它最近的节点朝这个节点的方向生长一小段。不断重复这个过程直到树长到终点附近就得到了一条路径。听上去像碰运气但在高维空间里RRT 反而比穷举式搜索高效得多。比如机械臂的自由度可以是 6 到 7 个它的状态空间是六维或七维普通栅格法根本没法用因为格子数量会爆炸。RRT 不依赖显式的空间建模只需要一个“碰撞检测”函数来判断某个姿态是否碰到障碍物就能在非常高的维度里找到可行路径。RRT 的缺点也明显路径质量差拐弯多不平滑。所以工业界一般会在 RRT 之后接一个平滑算法比如三次样条插值或者直接用改进版 RRT*带重连优化的版本。3.4 强化学习路径规划从搜索到学习这几年强化学习也被广泛用到路径规划里。它的思路和传统算法完全不同传统算法是“给定环境现场算路径”强化学习是“先大量训练形成一种策略然后面对新环境时直接输出动作”。我个人的经验是强化学习路径规划适合两种情况。一是环境模式相对固定比如同一条产线上的 AGV 小车路线变化不大但障碍物出现位置有随机性二是传统算法计算速度跟不上实时性要求的时候。以 DRL 的经典方法 PPO 为例你需要定义状态传感器读数或局部地图、动作左转、右转、直行等、奖励函数到达目标给正奖励撞到障碍物给负奖励然后让机器人在仿真环境里跟环境交互数万次直到收敛出一个能避障的策略网络。但强化学习有个坑训练环境的保真度直接决定策略的可用性。你在仿真里训练的策略放到真实环境里往往会出现“sim-to-real gap”仿真到真实的差距。解决方法是 domain randomization——在训练时故意随机化传感器的噪声、障碍物的形状颜色、摩擦系数等参数让策略学会“泛化”而不是“死记硬背”。3.5 轨迹规划从路径到“带时间的路径”路径规划解决的是“怎么走”轨迹规划解决的是“走得多快”和“怎么加速减速”。一条路径上会有很多个路点轨迹规划要决定机器人经过每个路点时的速度、加速度以及两个路点之间怎么插值。最常用的规划是梯形速度曲线。简单说就是加速段、匀速段、减速段三段拼起来速度曲线像个梯形。它的优点是好算、直观缺点是加速度有突变从 0 跳到最大值那一下机械结构会有冲击。要求高的场合用 S 形速度曲线加速度本身也是连续变化的冲击更小。代价是计算复杂一些。机械臂的直线轨迹、圆弧轨迹本质上都是先确定路径几何形状再用这类速度曲线规划出每个插补周期的目标位置。我在做喷漆路径规划时遇到过一个问题喷嘴走弧线时如果线速度不稳定漆膜厚度会不均匀。解决办法是在路径规划时加约束让每个插补点的线速度保持一致这本质上就是个带速度约束的轨迹优化问题。很多初学者只关注路径几何忽略了速度规划做出来的轨迹能走但实际工件质量完全不行。4. 机械臂轨迹规划直线、圆弧与电子凸轮的具体实现4.1 关节空间规划还是笛卡尔空间规划机械臂轨迹规划有两个坐标系可以选择关节空间和笛卡尔空间。关节空间规划是在每个关节的角速度、角加速度层面做规划优点是计算简单不会出现奇异性问题缺点是末端轨迹不可控——它在两个点之间走的是曲线不是直线。适合那种对末端路径形状没要求的任务比如从一个点搬运到另一个点。笛卡尔空间规划是直接在末端位置做插值保证末端走的是一条直线或圆弧。这种规划更直观但对逆运动学计算要求高而且在某些关节角度组合下会进入奇异位形导致关节速度突然变大。我做焊接机器人时深有体会明明末端走的是直线但有一个关节的角速度突然飙到极限差点报警停机。实际项目里我的做法是先判断任务是否需要精确的末端轨迹形状。需要就做笛卡尔空间规划同时在规划前用逆解函数检查路径上有没有奇异点不需要就把两个目标点位姿算好用关节空间规划做平滑过渡。4.2 直线与圆弧轨迹的插补算法直线轨迹插补是最基础的。给定起点 P0 和终点 P1以及插补周期 T比如 10ms轨迹规划要做的是每 10ms 算出一个中间点位置让机械臂末端按顺序经过这些点。弧线轨迹稍微复杂点。给定三点 P0、P1、P2很快就能精确通过三个点你还是需要三段时间。问题在于我不小心把速度和加速度约束设得太严最后一段轨迹上出现了很大的位置跟踪误差。后来我把每个段末的允许位置误差和速度约束分别独立设置才避免了这个问题。分段协调的核心逻辑很简单用一个“目标速度”把每段联系起来——前一段末尾的速度必须在下一段开始前达到或降低到下一段的初始速度要求。为了实现平滑我在两段之间加了一个过渡圆弧圆弧半径可以设置机械臂末端走到过渡圆弧的时候既是上一段的结尾圆弧又是下一段的起始圆弧。4.3 电子凸轮与追剪控制PLC 领域的轨迹规划别以为轨迹规划只是机器人的事。工业现场最常见的追剪飞剪、剪切机控制本质上也是一种轨迹规划。追剪要求切割刀在运动过程中追上同步运行的材料并在同步过程中完成切断切断后快速返回原点准备下一次切割。在汇川 PLC 里实现追剪核心是电子凸轮CAM功能。电子凸轮相当于一个虚拟的机械凸轮你定义一条“主轴位置-从轴位置”的曲线主轴每走一个单位从轴就按照曲线的值输出对应的位置。这样就不需要真的机械凸轮去加工改工艺参数只需要改曲线数据。我第一次做追剪项目时犯了个低级错误把电子凸轮的曲线起点设成非零值结果主轴一启动从轴就猛地跳了一段把材料切歪了。后来工程师提醒我电子凸轮的曲线必须从起点闭环到终点且起点的位置和速度要和实际工况对齐否则就会有速度突变。4.4 轨迹规划的稳定性为什么插补周期这么重要机械臂轨迹规划里插补周期是个绕不开的参数。常见的有 8ms、10ms、16ms伺服驱动器的控制周期一般是 1ms 或 500us。轨迹规划器算出一个中间点然后伺服按插补周期去跟踪。如果插补周期设置得比伺服响应能力还慢末端就会“一顿一顿”的特别是走圆弧时肉眼可见的抖。相反插补周期太短计算量会飙升控制器 CPU 可能跟不上。我一般按“末端最大速度 / 插补周期 每周期位移”这个公式来估算——每周期位移最好不要超过空间分辨率的 2-3 倍分辨率的定义看你用的传感器或工艺要求。比如要求精度 0.1mm最大速度 500mm/s插补周期 10ms那每周期位移就是 5mm明显太大了。这时候要么降低速度要么缩短插补周期到 2ms。5. 网络规划与系统规划从 IPv6 到校园网与数据中心的实战视角5.1 为什么网络规划能力比配置命令更值钱如果说路径规划和轨迹规划面向的是物理空间的运动控制那网络规划面向的就是“数据流动的控制”。网络规划不只是划分 IP 网段它包含拓扑设计、VLAN 规划、路由协议设计、安全域划分、带宽规划、冗余设计等多个维度。我面试过不少网络工程师很多人对命令背诵熟练但一问他“你为什么要在这个位置做三层路由而不是二层交换”他就答不上来。这种问题没有标准答案考的就是你对网络规划的理解。好的网络规划核心就是平衡以下几个约束可扩展性现在规划的是 500 人办公网三年后可能 2000 人能不能平滑扩展可用性核心设备挂了业务能不能自动切换安全性外部流量、内部流量、运维流量能不能有效隔离可管理性出了问题能不能快速定位到具体端口和策略很多人忽略“可管理性”。我见过一些网络只是临时加了几条 ACL半年后没人知道哪些规则有用哪些是垃圾。好的规划一定要把可管理性纳入考量比如使用 IP 地址时按业务含义分配VLAN 命名按部门编号统一。5.2 校园网络规划一个典型的全局规划案例校园网是网络规划里的经典场景。我们学院之前做过一个基于 eNSP 的校园网规划毕业设计从零开始设计一个包含教学楼、图书馆、宿舍区、办公区四个区域的网络。拓扑大概是这样核心层两台交换机做双机热备汇聚层按区域划分接入层按楼栋部署。路由协议用 OSPF 做区域内互通出口用一条专线NAT 上网。IP 地址规划是重点。我们当时分配的网段是区域网段VLAN说明教学楼192.168.10.0/24VLAN 10教师机、多媒体设备图书馆192.168.20.0/24VLAN 20图书检索、电子阅览宿舍区192.168.30.0/24VLAN 30学生终端、无线覆盖办公区192.168.40.0/24VLAN 40行政办公、财务系统这个规划的好处是每个区域一个 /24IP 第三位直接对应区域编号VLAN ID 和区域编号一致运维时看到 IP 就知道大概在哪个区域排查故障非常快。有个容易忽略的坑宿舍区终端数量不一定只有 254 台。有些宿舍楼一层就有 100 多台设备一栋楼下来可能上千台。这时候单个 /24 就明显不够用你得把宿舍区设计成多个 /24 或用 /22 超网。我在指导学弟做毕设时特意要求他做终端数量评估不能拍脑袋写网段。5.3 IPv6 地址规划与 IPv4 完全不同的思路IPv6 地址空间大得离谱常见误解是“IPv6 不用规划随便分就行”。这恰恰是最大的坑。IPv6 的地址层次结构非常强前 48 位是全局路由前缀一般由运营商分配接下来 16 位是子网 ID你可以划分 65536 个子网后面 64 位是接口标识。如果不提前规划子网 ID 的分配规则后面网段多了你会发现路由表混乱、ACL 也没法按子网聚合。我做过一个 IPv6 试点项目规划策略是子网 ID 的高 8 位按地理位置分00 是总部、01 是华东、02 是华南低 8 位按业务类型分01 是办公、02 是生产、03 是视频监控。这样路由聚合时只需要写一条“2001:db8:0101::/48”就能覆盖华东办公网段。另外IPv6 的接口 ID 部分通常由 SLAAC无状态地址自动配置自动生成对你的管理来说是个黑盒子。如果要做设备追踪和安全管理建议用 DHCPv6 或者配置固定接口标识的规划。很多单位在 IPv6 改造时只注意了路由协议却忽略了地址标准化管理上线后才发现审计困难。5.4 系统规划与管理师与数据中心规划规划思维在 IT 运维层系统规划与管理师是软考高级科目里偏运维管理方向的考试。我周围备考的人不少他们最常拿来跟我讨论的题目往往是考“规划思维”的题例如业务系统扩容磁盘怎么规划备份窗口怎么设计容灾 RPO/RTO 怎么定这些问题表面上是技术题实际是决策题。你规划存储容量要综合考虑业务增长曲线、数据保留周期、备份空间冗余你规划容灾级别要算清楚 RPO最多丢多少数据和 RTO多久恢复业务分别要花多少钱。数据中心园区的供电协调规划也是同样的逻辑。最近新出的“考虑多类型资源的数据中心园区供电协调规划”说的是数据中心除了接市电还可以搭配储能电池、柴油发电机、光伏形成一个微电网系统。核心是在保障 IT 设备供电可靠性的前提下尽量降低电费成本和碳排放。牵涉到的约束包括市电容量、储能容量、负载曲线、电价时段。本质上就是一个带约束的优化问题。我觉得规划思维是这些项目里最有价值的东西它强调“在有限资源下做最优分配”你不需要把所有方案都试一遍而是建立约束模型、量化目标、再做取舍。6. 规划方法论的通用内核四步闭环与动态重规划6.1 所有规划算法共有的四个组件从 A* 到轨迹插值从 Agent 任务拆解到网络规划它们本质上都在做同一件事状态空间搜索或方案生成。我把所有规划算法的共性抽象成四个组件状态空间你当前所有可能的处境。Agent 是“当前对话和工具调用记录”机械臂是“各关节角度”网络是“所有设备和链路的连接关系”。目标你想达到的状态。Agent 是“完成用户需求”机械臂是“末端到达目标点”网络是“所有终端互通且业务等级满足要求”。约束限制你方案的因素。Agent 是“可调用工具和 Token 限制”机械臂是“关节角度限位、速度上限”网络是“带宽、设备端口、预算”。评估函数用于比较不同方案的优劣。Agent 是“用户满意度或拆解质量”机械臂是“路径长度、平滑度、时间”网络是“延迟、丢包、成本”。当你面对一个新的规划问题时先把自己的状态空间、目标、约束、评估函数写清楚再去找对应的算法这样就不会迷茫。这是我这几年做跨领域项目最受用的经验。6.2 动态环境下的重规划机制静态环境里做一次规划就够了但现实世界没有“静态”这回事Agent 调 API 可能失败、机械臂轨道上突然出现人、网络设备可能宕机。所以真正可用的系统必须支持动态重规划。重规划有两种策略完全重新规划和局部修复。完全重新规划就是环境变化后把整个问题重新求解简单粗暴但计算开销大。局部修复就更智能一点比如 A* 的 D* Lite 算法路径被障碍物挡住时只更新受影响部分的代价其他部分的路径尽量保留。Agent 里的重规划也一样。我在前面那个 SimplePlanner 里加过一段逻辑如果某一步执行失败就让模型重新生成计划而不是把整个任务推倒重来。这个“执行失败后只重排后续步骤”的设计比从零再规划快很多用户等待时间也可以接受。6.3 规划器的评估你不能只看“最终结果”我评估一个规划器好不好从来不看它会多少种算法而是看三个指标求解成功率面对随机生成的 100 个问题它能规划出方案的比例是多少规划时延从输入到输出计划平均花多少毫秒方案质量与最优解相比它的解差多少举个具体的例子同样是机械臂抓取问题用 RRT 求解成功率很高但路径长度可能比最优解长 30%用 Trajopt 这类优化算法路径质量高但求解时间可能突破 100ms 限制。实际部署时往往需要多个规划器配合先用快速规划器给一个初始解再用优化器在后台优化或者反过来。有些做规划的工程师容易陷入“算法洁癖”总想用最酷的算法。我的建议是先定场景的实时性要求和质量要求再去选算法不要本末倒置。6.4 没有反馈闭环的规划等于白做最后说一个我见过最多的错误把规划当成一次性工作做完就完事了。规划的真正价值必须通过“执行-反馈-比较-调整”的闭环来体现。拿项目管理里的规划来说你排了一个月的计划每天记录实际进度每周对比一次计划与实际的偏差如果有偏离就赶紧调整。A* 算法本身也是这个逻辑——它在搜索过程中不断用启发函数评估离目标更近的节点本质上是一个带反馈的决策过程。Agent 做任务规划更是如此。计划只是起点执行过程中的每个观察都应该反馈到计划里这一步骤完成了、信息不足、结果和预期不一致……这些反馈是规划器持续改进的养料。没有反馈的程序路径其实就是“盲飞”做得再漂亮也是花架子。根据我自己的项目经验做一个规划系统与其把精力花在把计划生成得尽善尽美上不如多花时间设计反馈回路和异常处理。计划再好也会遇到意外反馈和重规划的能力才真正决定你的系统能不能在真实环境里存活下来。