← 返回概念解读

Concept Fable精修版

规划器

Planner · Agent architecture

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

修渠前夜,那张没有铲子的地图

南坡村靠一条老渠灌田。过去渠短,村长只要喊一声,谁去挖土,谁去搬石,谁去开闸,大家自然知道。那时一场小雨就能把田浇透,没人觉得需要复杂安排。

后来村子扩到三片坡地。上坡缺水,下坡怕涝,中间有一段渠壁松了,粮仓还要求三天内不能断运。旧办法仍是开工后现场喊人,哪里吵得最凶,就先补哪里。

第一轮修渠很热闹。十几把铲子同时下地,结果上游刚挖深,下游就被泥堵住;粮车走到半路,发现临时堆土挡住了路;开闸人听到两边喊声,不知道该放水还是关水。

村长想了个简单补丁:把所有任务按紧急程度排成一列。可每个人都说自己的事急,松渠壁的人说不修会塌,粮仓说不让路会误粮,下坡农户说再放水就淹苗。那张排序表很快变成争吵清单。

一位老测量师没有立刻发铲子。他先沿渠走了一整天,把水位、路口、田块、工人、工具和不能碰的边界画在地图上。晚上,他把大目标拆成几段:先保粮路,再固渠壁,再分批开闸,最后补下坡排水口。

他还在每段旁边写了条件:如果夜里下雨,暂停开闸;如果石料没到,先做临时支护;如果下坡水位超过红线,马上改走旁渠。每个步骤都有输入、前置条件和失败后的备用路径。

第二天,村民发现这张地图没有替他们挖一铲土,却让每一铲土有了位置。工人知道自己为什么等,也知道什么时候该换任务;开闸人不再听谁喊得响,而是看水位和前一步结果。

三天后,老渠修通。村长才承认,真正救场的不是那位测量师比所有人都强,而是他在行动前把目标、顺序、约束和可变条件摊开了。从那以后,村里再遇到大工程,先不急着动手。他们先画出能被执行、能被修改、也能被追责的路线,再把铲子交给合适的人。后来老测量师离开,村里仍照着方法做事。新工程先写目标,再列资源、顺序、约束、触发条件和备用路;做完还要复盘哪些判断错了。村民发现,计划不是把未来钉死,而是让大家在变化出现时知道该改哪一步。没有这张可修改的路线,勤快的人越多,现场越乱。

揭示

这个故事讲的是:规划器

规划器负责把用户目标拆成可执行步骤、子目标、约束和依赖关系,并在新信息出现时调整计划。企业 Agent 中,规划器不能只写漂亮任务清单,还要明确哪些步骤可并行、哪些需要审批、哪些依赖外部系统、失败后怎么重试或改道。它的价值是降低执行阶段的混乱,让执行器、工具、人类审批和状态管理围绕同一张计划推进。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 老渠工程:一个跨系统、跨角色的企业任务
  • 现场喊人:没有规划器时的临时决策和局部优化
  • 紧急程度排序表:只按表面优先级排队的天真修补
  • 老测量师:Planner,先理解目标、资源、约束和风险
  • 地图上的分段:任务分解、步骤顺序和依赖关系
  • 下雨、石料没到、水位红线:动态条件、外部依赖和异常分支
  • 铲子交给合适的人:规划器输出计划,执行器和工具负责落地
  • 能修改、能追责的路线:企业 Agent 计划需要可审计、可恢复、可调整

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

executororchestrationworkflowstask decompositionplan-and-execute agents

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。