任务接续系统改造：从“做一半就断线”到“可恢复推进”

type

Post

status

Published

date

slug

summary

一次围绕状态持久化、标准化 handoff、失败恢复与可验证收口的任务接续系统改造复盘。

一、我们真正缺的，不是更多执行器，而是“不断线”的能力

旧链路有个很典型的问题：看起来很忙，实际上很脆。

任务一发出去，receipt 有了；状态一更新，板面前滚了；有时连 `next_role` 都写好了。表面上像是在推进，实际上却常常卡在最关键的地方：没有真实执行证据，没有统一交接格式，也没有明确恢复点。结果就是——

任务暂停几小时后，回来只能从聊天记录里捞上下文；

任务转给下一个角色后，接棒的人不知道该从哪一步继续；

子任务失败了，系统不会自动回退到可恢复状态，只会把“处理中”挂在那里；

最后明明每个人都觉得自己动过了，整条线却没有真正收口。

这类问题本质上都不是“某一步没写好”，而是系统缺了任务连续性。

换句话说，旧系统会做事，但不会续做。

二、什么叫“任务接续”

如果把这个概念说得硬一点，我会这样定义：

> **任务接续 = 任务在跨时间、跨角色、跨执行器、跨失败场景下，仍能基于明确状态和标准回执继续推进的能力。**

这句话里有四个关键点。

1）状态要持久化

任务不能只活在聊天里，也不能只活在某个执行器的上下文窗口里。

它必须有一个外部可读、可回写、可追踪的状态层，让系统知道当前是在 `received / routed / executing / verifying / done / blocked` 的哪一段，而不是靠“刚才好像有人说在做”。

2）交接要标准化

handoff 不是一句“你接一下”，而是一次结构化移交。

谁来接、接什么、当前做到哪、上一棒留下了什么证据、下一棒的完成条件是什么，这些都得带着走。否则每次换人都等于重读上下文、重建意图、重猜目标。

3）恢复点要明确

真正的系统不是永远不出错，而是出错后还能接着跑。

所以每一条任务线都应该知道：

失败后往哪退；

哪个节点可以重试；

什么情况下转人工；

什么情况下明确标 `blocked`，而不是继续假装“执行中”。

4）收口要可验证

任务完成不能只靠口头说“搞定了”。

需要有能核验的产物、结论或回单字段。没有这些，系统就只能得到一种很危险的假象：看起来一切都有人管，实际上没有一条线真正闭环。

三、旧系统的问题，不是功能少，而是连续性差

回头看改造前的链路，问题主要集中在四件事上。

状态散落

消息里一点、记忆里一点、临时文档里一点、执行器上下文里再藏一点。任务的真实状态没有单一可信视图。

handoff 靠猜

很多交接动作都停留在“谁来接”这一层，没有把“接什么、做到哪、为什么停、下一步最小动作是什么”说清楚。

中断不可恢复

旧流程里，一旦失败、超时、环境变动，系统不会自然回到某个稳定恢复点。最常见的结果不是自动续上，而是悬空。

收口不可核对

不同任务线回来的回单格式不统一，有的写结论，有的贴日志，有的只说“已完成”。这让自动汇总、自动校验、甚至人工审核都变得很痛苦。

这些问题加在一起，造成的不是偶发故障，而是一种结构性脆弱：任务只适合一口气做完，不适合真实世界那种会暂停、会中断、会换人、会返工的推进方式。

四、这次改造，核心是把“会做事”改成“能续做”

我们这次没有继续往旧流程上补胶布，而是直接把任务接续拆成四个基础能力。

1）统一状态模型

先把状态讲清楚。

任务不再只分“在做 / 做完 / 卡住”这种模糊口径，而是统一按轻量状态机理解和汇报：

`received`：收到请求，尚未路由

`routed`：已明确交给谁处理

`executing`：执行中

`verifying`：进入验证/审核

`done`：已完成并收口

`blocked`：当前明确受阻，等待条件解除

这件事看起来简单，实际特别关键。因为一旦状态语言统一，系统才能知道什么时候该继续派、什么时候该等、什么时候该转验证、什么时候必须显式告警。

2）补上 handoff 协议

交接不再靠一句话。

每次续派，都要尽量带上最小必需字段，比如：

这条线当前目标是什么；

已完成到哪一步；

留下了哪些证据；

为什么需要续派；

下一棒的完成标准是什么；

若失败，优先回退到哪里。

这么做的直接效果是：下一棒拿到的不是“一个任务”，而是“一个带状态、带意图、带边界的任务节点”。

3）把失败后处理纳入日常路径

以前很多系统最大的问题，是把失败当成异常分支，结果异常一多，主流程就形同虚设。

这次改造后，我们默认任务推进里就应该包含：

短重试；

回退执行；

必要时回中书重拆；

最终明确 `blocked`。

也就是说，失败不是“流程外事件”，而是流程本身必须消化的一部分。

4）复杂任务默认带验证席

这是很重要的一刀。

以前很多线做到最后，用户看到的是一个“像完成了”的成品，但系统内部其实没经过稳定验收。现在复杂任务默认把验证环节编进流程，不再等做到最后才临时想“要不要验一下”。

这样做的好处是，收口不再只取决于执行者的自述，而是有更稳定的审核闭环。

五、真正让系统稳下来的，不只是状态机，而是“接续视角”

如果只把这次改造理解成“加了几个状态、补了几个字段”，其实还差一层。

真正变化的是系统看待任务的方式。

以前的默认视角更像“单轮执行”：

来一个任务；

派出去；

做完就结束。

这个模型在简单任务上没问题，但一旦任务跨天、跨角色、跨工具，它就会开始失真。因为现实里的任务不是直线，而是会停、会转、会失败、会恢复、会再往前滚。

所以这次改造真正立住的一件事，是把“任务”从一次性动作，改成一条可以被持续维护的线。

这个视角变了以后，很多动作的意义也跟着变了：

派工不是发出去就算完成，而是要考虑能不能被接住；

中断不是“先放着”，而是要明确恢复条件；

回单不是留痕，而是要服务下一次接续；

完成不是一句话，而是系统真正能验明这条线已经闭环。

六、一个典型变化：系统开始知道“断了以后怎么继续”

改造前，常见情况是这样的：

任务做了一半，执行器超时了。外面只看到一段聊天、一条回执，甚至任务板还停留在“执行中”。等人回来想接这条线时，往往只能重新翻记录、重新判断现状、重新决定下一步，成本高，而且容易接错。

改造后，同样的情况会被拆开处理：

先确认当前节点真实停在什么状态；

看是否已有足够证据进入验证；

如果没有，判断是短重试、回退执行，还是直接 `blocked`；

续派时带着上一轮上下文摘要、证据位置和下一步目标；

下一棒接到手后，不需要“再理解一遍任务是什么”，而是直接从当前恢复点继续。

这不是把问题变少了，而是把问题从“靠人补”变成“系统可处理”。

七、这类改造真正带来的收益，不只是效率

很多人一听到工作流、状态机、handoff，会先想到效率。

效率当然重要，但这次改造更大的价值其实是三件事。

1）可恢复性

系统不再要求每条任务都一口气跑完。中断之后还能有秩序地接回去，这一点比单次速度更重要。

2）可协作性

任务跨角色推进时，不再过度依赖某个人的脑内上下文。交接质量上来以后，多人协作才真正开始成立。

3）可治理性

一旦状态和回单结构统一，后面无论是做统计、做巡检、做自动提醒，还是做问题复盘，都会顺很多。因为系统终于开始沉淀“可计算”的过程信息，而不是只有聊天痕迹。

八、任务系统最重要的，不是自动化，而是不断线

回头看这次改造，最容易说错的一句话是：我们做了一个更强的 agent 系统。

其实不止是这个。

我们真正补上的，是一套让任务在真实世界里活得更久的能力：它可以暂停，可以转交，可以失败，可以恢复，也可以被验证和收口。

一个真正能落地的任务系统，不是每一步都自动，而是在任何一步出问题时，都知道如何继续。

这才是“任务接续系统改造”真正想解决的事。