一支维护城市骑行地图的小组每周要处理一批道路变更。施工公告提供封闭时段，地图仓库记录现有路线，编辑需要给骑行者写绕行说明。过去一条长提示词同时要求查公告、判断影响、改地图和发布，出错后很难知道是哪一步用了过期数据。可以从一条虚构的桥梁维修通知开始，把路由、工具、可复用步骤和审批拆开，先产出可审查的变更包。
定义各层职责和输入
主 Agent 接收请求后只负责分类、选择路径和解释无法处理的例外。用三个明确意图区分查询现状、提出变更和申请发布。只有收到路线编号与有效日期才进入变更流程。输入缺失时请求补充，路线名有多个匹配时列出候选供编辑选择。将路由结果和理由写入运行记录，便于发现同一类输入为何进入了不同分支。
Skill 保存某项可复用做法，例如如何从公告提取方向、起止时间和适用路段。外部数据通过对应工具读取。若使用 MCP 接入公告数据库，先在测试环境验证连接身份、查询字段与权限范围。工作流负责安排步骤和记录状态，例如先确定受影响路段，再生成草稿，批准后才进入发布动作。将这些边界写入输入输出约定，别依赖主 Agent 在每轮对话里记住全部细节。
将一项更新拆给可独立检查的执行者
先给请求分配运行编号，保存公告原文编号、版本及地图基线。公告核对员从输入提取封闭日期、方向、公告记录号和不确定字段。路线核对员可独立读取当前地图，列出可能受影响的路段编号和备选道路。两者都把结果写到自己的文件，由汇总节点读取。需要公告的正式范围才能决定绕行路线，因此路线核对的候选结果可以提前生成，最终推荐要等公告核对结束。
分派时只给执行者任务相关的数据和权限。公告核对员可以读公告，地图核对员可以读地图。两者都不需要正式地图的写权限。任务说明列出预期产物和失败信号。比如公告缺少结束时间，输出应注明未知，并附上待核问题。出现未知状态后，主控可以继续准备其他材料，但不能把该条变更标为可发布。
在归并时验证版本和冲突
假设公告写的是桥面西向车道周二早上封闭，地图组初步报告却按双向封闭评估。汇总先检查地图组所用的路线版本，再将方向差异列为阻断项。请执行者在同一地图版本上重做受影响判断，同时保留原报告和复核理由。审核者应看到最终受影响路段来自哪条公告、哪一版地图和哪次判断。对于公告未明确覆盖的支路，写入待确认清单，避免把推测画成确定路线。
记录每个任务的状态、输入版本、产物位置、开始时间、超时原因和重试次数。并行分派时，主控等齐必需产物再归并。某个任务超时可按上限重跑该任务。等待状态应区分未开始、仍在运行和需要人工处理。新公告替换旧版本时，标记依赖旧公告的报告失效；未受影响的地图基线可继续使用。这样既能恢复运行，也能说明为什么某份早期结果被舍弃。
让分析方案成为执行前的约束
设计阶段交付变更计划，列出受影响的路线、拟调整字段、证据和仍待确认的问题。编辑批准具体版本后，执行阶段只在预览地图上应用该计划。对比前后路线坐标、封闭时段与提示文字，查看是否误改了同名桥梁。发现需额外修改的道路时，先退回计划阶段说明范围变化。测试可以注入一次草稿批准后公告改期，确认执行节点会停下并要求重新核对。
公开动作由独立步骤执行，使用绑定计划版本的审批记录和可追踪的请求编号。写入超时后按请求号核对结果，避免重复生成公告。若无法判断写入是否成功，将运行交给编辑处理并保存变更前后记录。试跑完成后交付路由记录、分析计划、变更包、验收截图和审批日志。维护者可按运行编号复现整条路径。
用预览验证路由和交付
使用关联的 Webapp Testing 技能检查可操作的预览页面。给它一组模拟路线、两类意图和待批准变更，验证查询请求不会显示发布入口、错误方向会触发阻断、审批过期时无法继续。保存页面反馈和操作证据。后端还要核对相同请求是否只产生一条写入，以及日志中能否找到对应任务。技能提供浏览器验收步骤，地图数据的准确性由团队根据公告与仓库记录复核。
常见问题
每个步骤都需要一个 Agent 吗？先区分固定判断与需要解释的判断。按日期筛选、检查版本和校验字段通常可以由确定性的步骤完成。公告写法模糊时，再请模型提取候选范围供编辑核对。单次工作量小而且没有独立分支时，用一个执行者更容易追踪。
增加新 Skill 是否需要改整个工作流？如果输入和输出约定兼容，可以先替换对应步骤，沿用现有的验收样本。新增写入权限或修改返回结构时，复核依赖和批准路径，再决定是否扩大试点。
并行结果经常互相覆盖怎么办？检查执行者是否共用一个输出路径。为每个运行和任务指定独立位置，让归并节点成为最终变更包的唯一写入者。重跑后核对文件是否属于当前版本。
怎么排查请求被路由错？找出触发分类的字段与缺失值，再用相近但不同意图的样本重放，例如“看看桥上能不能骑”和“把桥标记为关闭”。确认分类差异能从输入与规则解释，并给无法判定的请求留一个澄清出口。