运行：让业务任务有人负责到底

上线后最容易遗漏的问题是：接口都正常，用户的工作却没有完成，此时谁接手？模型服务可用、工单已受理、补卡请求已创建，是不同的状态。运行设计要让团队识别这些差别，并能继续处理尚未结束的任务。

以任务为单位安排责任

以“卡未收到”为例，物流查询成功可能已经满足客户；需要补卡时，请求被创建不代表新卡送达；查询结果矛盾时，人工调查可能是正确下一步。Nubank公开材料把例程、工具和评测分别维护，并观察交接、错误、自助率与满意度。它支持这种分层运行思路，但没有公开完整值班表、事故台账或固定恢复时限。以下是可迁移的参考设计。

对一个任务至少分清三个责任：业务责任人定义什么算解决，系统维护者恢复可执行能力，知识或规则维护者修正依据。规模小的团队可由同一人承担多项责任，仍需写清发生哪种问题时做什么。设立一个笼统的“AI负责人”会让所有错误涌向一个人，却没有改变系统。

从同批任务追到跨日接续

接续第16章商品建档试点，用OPS-SYN-12台账安排十二笔合成任务。商品运营A负责业务完成与回告，供方联络B补资料，工程C核对动作，类目负责人D维护规则；它们是角色占位。保存回查、草稿合格、需求方收到结果分别核对，不能只看工具是否返回成功。

第一天8笔有保存回查，O04却有颜色误读；O09/O10回执未知，O11待单位，O12超出类目范围。A下班前交出的不是“4笔失败”，而是每笔的最后确认状态、稳定动作键、已核实事实、接收人及下次检查时间。C查询O09的原键，第二天查到已保存草稿；O10查询服务也不可用，先保留unknown与接续任务，查证原请求未执行后，才由授权原流程完成。接口恢复本身不产生这些业务结论，更不能换键重提。

第二天按原12笔到达队列结算：11笔完成合法业务接续，O11仍待资料；O01–O10最终有正确草稿，其中O10来自原流程，O12也由原流程完成。因此11/12不是工具自动完成率，第一天8/12也不是合格率。O04修订不能抹去曾经漏错；O09/O10不在第二天新增任务中再计一次成功。下一班先对未结清单，再看新增流量；需增加 accepted_at、next_check_at、settled_at 等时间，区分已派出与已接收。

运行记录保存事件、版本与必要引用，不必向每个日志系统复制完整客户资料。真实后端需验证持久查询、权限与恢复语义；现有会话Map演示只支持局部机制检查。

轻量与较重的运行安排

低风险、仅草稿且量小的团队，可以工作时段由A每日两次接收待办，C在约定窗口处理接口问题，B/D按问题类型接续；UI明确下次检查时间，未接收前显示“等待接收”。A请假时由指定备岗接收，不能把无人看的邮箱当接续能力。

涉及频繁写动作、跨日unknown或大批量业务时，需按任务队列连续管理：值班者接收告警、工程可暂停写工具、业务owner可切回原流程；换班核对未决任务和已执行动作。规定升级条件及替代路径，不必因此自建AI平台。严重权限事件立即停相应能力；普通积压按事先容量边界限流。两种安排都要实地演练接收人是否真的能取得材料，文档列出名字不等于接收。

**合成容量算例（CAP-SYN，独立于OPS-SYN-12）：**每天60笔到达，20%需要人工接续，即12笔；每笔接续15分钟，需求180分钟。可用净处理时间240分钟时，负荷75%，余60分钟。故障时接续比例升到40%，24笔需要360分钟，超过能力120分钟；即使接口恢复，积压也不会自动消失。临时加120分钟只到100%负荷，没有波动余量；若保留25%余量，需480分钟总净能力，或限制到达、缩小能力并安排原流程。这里不假设各任务耗时独立，也不以此算排队等待；真实排队需测到达峰值、服务时长分布、优先级与人员技能。

在途任务跨版时仍先核对原动作；发布组合与回退见第15章，退出接收与权限回收见第20章。

收到新事件时，继续哪一笔工作

设想合成维护任务：设备SYN-PUMP-07告警触发调查，五分钟后同设备出现温度升级，同时另一设备SYN-PUMP-08发来外观相似告警。给每条消息启动一个独立Agent，会让第一台设备被重复调查；仅按文字相似度合并，又可能把两台设备混成一笔故障。这里先决定的是事件属于哪项工作，而不是选择哪个模型。

SAP作者的事件编排研究将任务管理与执行分开：模型建议新建、合并或忽略，并判断优先级；确定性队列只接受通过Schema与配置检查的决定。待办保存任务、待吸收事件、优先级和恢复状态，在明确停止点吸收新上下文或切换工作。这是源于业务情境构造、使用模拟专业Agent的研究实验，不是SAP生产系统的端到端性能证明。论文v1 §2.3–4

对应本例，第二条消息可作为同一设备调查的补充，第三条保持独立；无法确定实体时进入核对，不能为缩短队列强行合并。事件判“不需新建任务”也要保存理由，防止告警消失。优先级提高只在明确停止点切换，不中断不可拆分操作；真实安全动作须有独立控制和人工响应，不能等待通用调度器。

普通日终报告用串行队列即可；持续事件、紧急度差异和更新中的任务才值得合并/抢占。主线验收：事件属于谁、已完成什么、新事实影响什么、恢复前重验什么。长任务专题统一维护四种状态合同与恢复反例；论文mock实体识别不提供企业授权。

持久消息不是业务幂等

LinkedIn平台披露消息历史、FIFO交付与持久重试，同时保留同步快速调用：同步路径旁路创建消息，因此记录与响应存在最终一致窗口。它提示不能用“消息队列已有重试”代替业务恢复合同，也不能因没有立刻看到聊天记录就重发业务动作。平台工程

假设招聘外联提交超时：任务进入result_unknown，后台按稳定动作键查询是否已发；已发则补登记结果，未发才恢复发送，仍不可确认则交人工。该协议是教学设计，公开材料未披露LinkedIn完整外联去重机制。FIFO只说明某一交付范围内的顺序，不自动给跨工具调用全局顺序或恰好一次业务结果。运行团队需要同时记录接收事件、业务状态、回执和界面可见版本，才能回答“消息到了但工作有没有完成”。

报警与人工接续

平均错误率容易掩盖同一种高损失问题。建议分别看接口不可用、结果未知、越权请求、关键任务错误和人工队列积压。每项报警应指向一个可以采取的动作：暂停某个动作工具、恢复上一配置、切换只读模式或将任务交人工。仅提高告警数量会增加噪声。

人工接手需要看到请求目的、已核实事实、做过的动作、未确定的结果及引用版本。不能让客服再问一遍已经提供的全部信息，也不能把模型猜测写成核实事实。对内部知识助手，Cisco研究的例子提醒我们：“工单已受理”与“访问已恢复”应分别验收；安全入口与员工真实任务也不是同一件事。

检查是否真的能运行

选取正常结束、接口超时、提交结果未知、规则失效和人工接续五条合成任务，按现有设计走完。检查任务有没有丢失、是否产生重复动作、接手者能否复原状态、客户是否得到准确解释。再观察一次真实运行周期，确认谁实际收到报警、处理耗时与队列情况；合成演练只能证明设计路径可走，不能证明生产可靠性。

运行复盘不必每次开大会议。先用运行复盘模板记录影响决策的事实，再进入反馈分层决定改哪里。无法找到责任人或恢复路径的问题，应在继续扩大前解决。

参考资料

• Nubank v2 §4.4–4.5、§6.3：例程、工具、评测与交接观察。
• Cisco内部助手：Operating model与Lessons learned；Intuit工程演讲：开发、注册与运行分工。
• SAP v1 §2.3–4、LinkedIn平台工程：模拟事件编排与生产消息平台披露，属于不同证据范围。
• The AI Product Playbook 第10章：运行生命周期，章节提炼笔记作为辅助参考。
• 设备事件、状态、值班责任与恢复协议为合成教学设计；未运行生产系统或复现编排实验。

继续使用

上一章：试点与采用 · 下一章：反馈与改进 · 五篇阅读目录。相关工具：结果核对与运行责任。

案例延伸：IBM维护：区分建议交付、维修执行与运行责任。