腾讯 ADP 把 Agent 的断点续跑做成了产品：暂停之后，第 15 步不会重来

一句话定位：这不是"平台稳不稳"，而是"暂停—检查—续跑之后，Agent 知不知道哪些步骤已经真的完成"——被测对象是执行轨迹与外部副作用的一致性，不是进度的百分比。同样的断言可迁移到审批流中途撤回、批量任务断点续传、订单履约分仓卡单、发布窗口到期强制中止。

摘要

腾讯云 2026 年 11 月 4 日的官方博客把三件事写进了产品说明：需要长时间跑的 Agent 任务可以按需启停、可以从断点续跑、可以查看每一步的运行记录。这三项能力解决了一个真实痛点，也引入了一个新的测试对象——续跑点。这篇不谈模型评测，只讲一件事：当 Agent 可以被"暂停再继续"，测试要补的三类断言是什么（续跑不重复、不丢中间态、轨迹可对账），以及为什么"云端常驻"这个便利会顺手拿掉"重启就好"这个兜底。文中给出三条可以直接写进用例的判定规则和一个会踩的坑。

一条工单在企业内部要走十几步：收到客户报障、查订单、判断是否在保、生成维修单、等网点接单、等配件、回访、关单。

把这串动作交给 Agent 之后，最麻烦的不是哪一步会错，而是它跑到一半，得停下来等人。

等人确认是否免单，等人补充配件型号，等人决定这个客户要不要升级处理。停下来的时间可能是十分钟，也可能是隔天上午。若 Agent 只活在某台开着的电脑上，这段等待就是它最脆弱的部分。

腾讯云 11 月 4 日的官方博客里，这块能力有个具体名字：Agent Harness。官方原话是"需要在云端持续执行的任务，可通过 Agent Harness 按需启停、断点续跑，并查看运行记录"。腾讯云开发者社区同日发布的署名文章把它展开成三点：断点续跑（中断后从断点恢复，不丢失已完成步骤）、按需启停（可以暂停 Agent、检查中间状态、再继续）、全链路可观测（trace 回放，每一步的输入输出可查）。

我对这三条的第一个反应不是"真好用"，而是：那"已完成步骤"是怎么定义的？

这不是找茬。一个可以被暂停和恢复的系统，它的正确性不再取决于"从头跑到尾"，而取决于"从中间某一点接着跑"是否等价于"从头跑到尾"。这两者在测试上是两件事，而多数团队的用例只覆盖了前者。

暂停、检查、继续——多出来的那一段才是风险

先看这三项能力叠加之后，实际发生了什么变化。

原来 Agent 是一条单向的时间线：输入、循环、输出。人能做的只有开始和（杀进程）结束。

加上"按需启停 + 检查中间状态 + 继续"之后，时间线上多了若干个人为的插入点。每个插入点上，系统的状态必须是一致的：已经完成的动作真的完成了，还没开始的真的没开始，正在进行的那个不会在你按下继续之后变成两个。

社区那篇文章用一个很形象的假设开场：跑到第 15 步断了一切重来。（本文沿用这个示例步数，它不代表任何真实任务的实测步数。）断点续跑解决的是"重来"这件事。但它同时把另一个问题摆到台面上——如果恢复点选得不对，你不是重来，你是做了两遍。

下面这张图把一段长任务被暂停时，状态可能落在的三种位置画出来。它要说明的只有一件事：续跑的正确性取决于暂停点落在哪里。

三条断言，覆盖续跑最常出错的三个地方

我在自己的项目里用三条规则检查任何"可续跑"的流程。它们都不需要读平台源码，只需要在流程外部观察。

第一条，续跑不重复。 暂停前完成的那些写操作，续跑后数量不能变。这条最容易被漏，因为重复往往发生在"提交了但没收到回执"的那一步——从系统外部看，它既可能成功也可能失败。判定方法很土：在执行前后各数一遍关键表的行数，并记下每行的主键；续跑之后再数一遍，主键集合只能增不能重复。

第二条，不丢中间态。 暂停期间人做的修改（比如人工补了配件型号），续跑后必须被 Agent 读到，不能被它用自己缓存的旧值覆盖。这条的失败表现特别隐蔽：流程跑完了，工单也关了，但配件型号是 Agent 暂停前记的那个错的。判定方法是把人工修改写成一条必须出现在最终记录里的断言，而不是让它停留在"人工已经改过了"的认知里。

第三条，轨迹可对账。 既然能"查看运行记录"，那就把记录本身当成被测对象：每次续跑，轨迹里必须有一条明确的"从这里继续"标记，且前一段的最后一步与后一段的第一步之间没有空洞、也没有重叠。这条断言的价值在于它能把前两条的失败定位到具体步数。

三条规则对应三个不同的失败面，我按它们的严重程度排了一下：

这张表我建议直接放进验收模板。三列都是可判定的，"定位难度"那一列是为了告诉评审：最贵的那类错误恰恰是最安静的那类。

"云端常驻"顺手拿走的那个兜底

有一件事值得单独说。

当 Agent 跑在你自己的机器上，出问题最省事的处理是重启——虽然粗鲁，但它把状态清零了，你至少知道自己面对的是一个干净的起点。

当 Agent 常驻在云端、可以被暂停和继续，这个兜底就没了。你面对的是一个带着历史的状态，而历史里可能有半完成的动作。腾讯云官方博客对这个能力的定位是"按需启停、断点续跑、查看运行记录"，社区稿把它的意义概括为"把长程任务从'能跑'变成'能上生产'"。这两句话都成立，但它们描述的是能力，不是保证。

生产上真正需要的是：在什么条件下允许续跑、续跑多少次之后必须人工介入、哪种状态不允许自动续跑。

这三条属于策略，不属于平台。平台给你"能续"，策略决定"该不该续"。我见过的最常见做法是把续跑次数设成无限重试，这在短任务上没害处，在长任务上会把一个偶发错误放大成一串重复动作。

因此我会在验收清单里加一条很笨的检查：把续跑次数上限设成 2，然后人为制造一个必失败的第 3 步，看系统在第 2 次续跑失败后有没有停下来等人。 停不下来，说明策略缺位，这个缺口比模型能力更值得先补。

续跑能测，但"跑得完"仍然测不了（业务推演）

以下是推演，不是腾讯或任何客户的真实案例。

把上面这套东西放到一条客服工单流程上，会暴露一个平台能力解决不了的问题：断点续跑保证的是"从暂停处继续"，它不保证"这条流程最终会结束"。

工单可能卡在第三步——查订单的时候订单系统在维护，Agent 重试了几次没成功，按策略退回等待。这时代理任务处于"已暂停"状态，看起来一切正常，但它永远不会自己动。如果没有人在某个时间点检查"这条流程停了多久"，它会一直躺在那里。

这在测试上意味着：恢复性测试和活性测试是两件事。 前者问"能不能接着跑"，后者问"它会不会一直跑不完"。平台的 Harness 解决前者，后者要你在业务侧加一个超时断言——比如"任何工单在 4 小时内必须处于某个确定状态之一，不允许停留在进行中"。（4 小时为本文示例阈值，无外部来源。）

这一条我特别想强调，因为它是"能力上线"和"质量达标"之间的典型缝隙：产品说明书上写了断点续跑，团队就以为恢复性已经覆盖；实际上，一个永远暂停的任务在监控上和一个正常等待的任务长得一模一样。

今天能做的三步

一，给现有流程画一条步骤轴，标出所有"提交了但回执不确定"的位置。这些位置就是续跑的危险区，通常只占整条链路的一两个点，但决定成败。

二，把上面那张三行表抄进验收模板，每条断言写清"怎么数、看哪张表、失败长什么样"。

三，人为制造一次暂停和一次必失败的续跑，确认系统会停在人工闸而不是无限重试。

这三件事不需要新的平台能力。但如果你的团队正在用类似 ADP 这样的托管 Harness，它们是上手第一天就该做的检查——因为平台把"能续跑"变成了默认值，而默认值最容易被当成保证。