现场服务与派工智能体

不要让模型排程。

路径与派工是一个带时间窗的车辆路径问题，这个领域在上面耗了四十年。求解器能同时处理技能匹配、行车时间、班次边界和加班规则，并给你一个能解释的最优解。同一个问题交给模型，它会产出一张看着挺像样、却在第九行违反了某项资质要求的看板。

• 求解器负责派工，智能体负责输入与例外。这个分工不是折中——求解器的答案只可能和你交给它的工时、技能代码与零件清单一样好，而这些都来自非结构化的人类文字。
• 约束被违反时，模型是无声的，求解器是响亮的。求解器要么返回不可行，要么点名那条起约束作用的条件。派工员正是靠这条解释去做覆盖决策的，而在模型接手派工的那一刻，你就失去了它。
• 模型真正能帮上求解器的地方：从描述与历史估计工时、推断技能代码、判断一个工单是真的紧急还是遇上了一位"什么都紧急"的客户。每一项都是喂给求解器某个输入的有界预测，也都可以单独测试。
• 这就定下了架构：智能体 → 结构化工单记录 → 求解器 → 看板，智能体永不直接写入派工结果。DevOps 与 SRE 智能体里的"只读优先"是同一条论证，只是爆炸半径不同。

一天的成败在受理环节就定了，因为车在有人开出去之前就已经装好。

现场服务里最大的一笔成本是第二次上门。一位技师带着不对的零件抵达，就烧掉了一个时段、一趟车程和客户的一上午；而原因几乎总在上游：一句"暖气有响声"被变成了一张没人能据以备货的工单。

• 把受理建模成一次诊断收窄，而不是一次填表。真正有用的输出，是最小的一组可能故障，加上每一种所对应的零件——其中也包括诚实的那句"远程无法收窄"，它会正确地触发一次诊断上门，而不是一次注定失败的维修上门。
• 照片和铭牌是你能索取的最高价值输入。从照片上读出的序列号能定位到具体机型、它的版本以及兼容零件，把一次猜测变成一次针对你自家目录的查表。
• 去挖你已经有的历史。这个地址此前的上门记录、这台资产的故障档案、以及最近三位见过同样症状的技师实际换掉了什么——在你自家服务记录上做检索，胜过模型关于这类设备的任何通用知识。
• 让"弃答"的得分高于"自信错答"。错误的零件清单比没有清单更糟，因为它在排程系统和技师心里制造了虚假的确定性。这与数据与分析智能体对待"自信的错误数字"是同一套评测立场。

一个上门时段是一句承诺。每一次写入都要两阶段。

智能体的工具调用订下一个时段；客户收到的是"周四 8 点到 12 点之间"，并围着它重排自己的生活。这就使得写入看板成为一次另一端站着真人的、不可撤销的对外动作，而通常那套重试语义对它是有实质危险的。

• 先预留，再确认。先下一个短期过期的占位，等客户同意、且零件可得性被核实之后再显式确认。一次既分配时段又通知客户的单步写入，没有任何安全的失败模式。
• 每一次预约调用都带幂等键。预留超时绝不能被重试成同一工单占两个时段——这是幂等性与重试里的标准处置，而现场服务是它咬得最狠的地方，因为重复是客户看得见的。
• 取消不是撤销。释放时段恢复了看板，却对已经发出去的那条消息毫无作用。把补偿动作设计成一套真实的致歉并改约流程，而不是一次回滚——这正是撤销与可逆性坚持的区分。
• 把限制写进工具签名。预约工具不应接受技师班次之外的时段、超出 SLA 窗口的时段，或者零件尚未确认的工单。写在 schema 里的约束是被强制执行的，写在提示词里的只是建议——见工具设计原则。

看板是和人共享的，而"最后写入者获胜"是输。

几乎每一个现场服务试点，都是照着"智能体是唯一写入者"来设计的。它不是。派工员正在实时地把工单拖来拖去，技师正在车里把一单标记完成，客户正通过门户改约——全都发生在智能体四十秒前读到的那份状态之上。

• 乐观并发，而不是发完不管。每次写入都带上智能体读到的版本号；冲突时返回当前状态，由智能体重新决策。悄悄覆盖掉派工员的手动调整，是智能体永久失去派工团队的方式，而这种机会你只有一次。
• 派工员的每一次覆盖都是打好标签的训练数据。每一次把工单从智能体的提议上挪开，都对应着一条存在于某人脑子里、而不在你系统里的约束——某位技师不能被派往那个站点、某位客户要求两人一组、某辆车上没有梯架。把覆盖连同原因一起记录下来，你就是在开采自己没能建模的那套约束集。
• 用构造保证人的优先级。派工员的调整绝不该被智能体的一次优化回合改回去，哪怕那次优化更优。把手动挪过的工单钉住，让求解器绕着它们工作。
• 提防"全局最优"的大挪移。一次把总行车时间改善 6%、却动了十一位技师下午安排的再平衡，是净亏损：它摧毁了他们每个人早上七点建立起来的心理模型。给单次智能体动作能挪动的看板范围设上限——这与供应链与物流智能体里的多写入者纪律是一致的。

改约对话，是回报最清晰的那项任务。

上午十点，计划已经不对了：一单超时、一辆车抛锚、一位客户不在家。现在必须有人按正确的顺序打八个电话去重新谈。这是高频、低判断、时间紧迫的活，人在压力下做得很糟——而且与排程本身不同，它确实是一件语言任务。

• 按后果排电话顺序，而不是按名单顺序。为此请了一天假的客户，和一个受 SLA 约束的商业站点，不是同一个电话；把顺序排对就是这件事里的大半价值。
• 只提供真实存在的时段。智能体必须先把替代时段占住再提出来，否则它会兴高采烈地承诺一个求解器早已派给别人的窗口——这是第 3 步里的预留纪律，只是现在还带着时间压力。
• 外呼是一种受监管的行为。给客户打电话和发短信附带同意、告知与免打扰时段义务，而一个会拨号的智能体同样背着这些义务——外呼面见外呼语音智能体，"说清是谁在打"见信息披露与内容溯源。
• 按情绪上报，而不只是按意图。一位在第三次爽约上发火的客户，是一次留存事件，不是一次排程事件。转人工规则应当在重复失败与检测到的沮丧上触发，并且移交的是上下文而不是一份逐字记录——见中断与交接。

衡量一次修复率与承诺兑现率，永远不要衡量自动化率。

自动化率是让这类项目被砍掉的那个指标。智能体订得越多它越高，而它订得越糟它涨得越快，因为一个错误的预约仍然是一个预约。

• 一次修复率是业务指标，也是诚实的那个。它把受理质量、零件预测与工时估计压进了一个财务本来就认的数字里。
• 承诺兑现率——在约定窗口内如期上门的比例——是客户对你这个智能体的实际体验，也是当求解器被喂进乐观工时时最先劣化的那个数。
• 二次上门率与每个已解决工单的出车次数把失败定位到具体环节。受理量持平而二次上门率上升，意味着零件预测过于自信，应当往弃答方向调。
• 派工员覆盖率，看趋势。下降说明智能体正在学会那些未建模的约束；居高不下说明它在提议一些人类会否决的工作，而你在为返工付 token。
• 每个已解决工单的成本，而不是每次交互的成本。这里的单位经济学毫不留情：一次本可避免的出车，成本高于整条受理流水线一个月的推理开销——这也正是受理那部分工作在这份清单上高于其余一切的原因。

相关：客服智能体——受理渠道；出行与预订智能体——面向第三方库存的同一个"先预留后确认"问题；以及IT 服务台智能体——派工回路的室内版本。