SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

规划器和执行器:一个画路线图,一个踩油门

Agent 架构里最经典的搭档也是最容易被压成一个模块的两个角色。规划器负责把用户意图拆成子任务序列,决定先做什么后做什么、选择哪些工具、估算资源;执行器负责真正调用 API、读写文件、处理返回结果。把规划逻辑嵌在执行代码里,调试时会发现既找不到规划错误也修不好执行 bug。

寓言

建筑工地上两个位置不该合并的工位

城南一座高层建筑的施工队里,有两个角色一直由同一个人兼着。施工员每天到工地后先对着图纸把今天的工序排一遍——先拆哪面模板、钢筋几点到场、混凝土在哪层开始浇。排完之后他再拿对讲机叫各班组进场干活。一个人既排工序又调度班组,干了两年没人觉得有问题。

第三年接了一座弧形幕墙写字楼。工序依赖比之前的方盒子复杂得多——幕墙的每块玻璃尺寸都不一样,安装顺序错了就要拆掉重来。施工员还是自己排工序自己调度,结果第四层幕墙装到一半发现第三层的定位支架没拆,整个进度卡住了。

事后翻施工日志才发现问题。施工员当天早上排工序时漏了“拆除第三层临时支架”这个前置步骤,但他在调度班组时直接跳到了“幕墙第四层安装”。因为他自己排自己执行,没有第二双眼睛看工序清单,错误从规划直接进入了现场。

总工把工序排布和现场调度拆成了两个人。新设了一个岗位叫工序计划员,专门对照整体工期和楼面图纸排出每天的前置条件清单。施工员只负责拿到清单后调度班组、检查完成情况、报告异常。两个人坐同一间办公室,但签字用的是两张表。

拆开之后第一周生产效率反而下降了。施工员经常因为清单上某个前置条件没满足而闲置,班组等着干活。但第二周开始,意外停工的次数骤降——以前拆模拆早了导致返工,现在计划员提前标了养护最短时间,施工员照表执行。

进度会上总工画了一张分工图:计划员管的是“做哪些事、按什么顺序、哪些前置条件必须满足”——这是规划和推理。施工员管的是“叫谁来做、做没做完、做完有没有问题”——这是执行和反馈。两个角色之间用一张工序清单传递信息。

大楼封顶时,总工期比计划提前了十一天。最关键的改进不在速度上,而在于任何一次延误都能一眼定位:是计划排漏了,还是现场没照计划执行。以前混在一起时,这两类错误互相掩盖,追责会议开成了猜谜大会。

规划器

Agent 系统中负责将用户意图分解为子任务序列、选择工具和策略、排定执行顺序的模块。

执行器

Agent 系统中负责实际调用工具、执行子任务、处理返回结果并报告状态的模块。

故事对应

  • 工序计划员排前置条件清单:规划器,拆分任务、排定顺序、检查依赖
  • 施工员调度班组和检查完成情况:执行器,调用工具、执行子任务、报告结果
  • 一个人兼两职导致遗漏前置步骤:规划逻辑和执行逻辑混在一起,错误无隔离
  • 两张签字表互传信息:规划器输出子任务序列,执行器按序执行并反馈状态

落到 Agent 项目里

设计 Agent 架构时,别把规划逻辑写成执行代码里的 if-else。规划器模块独立输出子任务计划,执行器模块按计划执行并返回每步结果。两类模块各自有日志、有评测、有独立的错误处理。规划出问题能回溯计划是否合理,执行出问题能看单步调用的参数和返回值。拆开的第一周可能更麻烦,但之后的调试成本会断崖式下降。