长任务可能连续运行一个小时都显示正常，却在工作进程重启后丢失关键状态。进度条只有能对应到可核对的工作记录时，才能说明任务走到了哪里。

为什么需要这个 Skill

长运行智能体测试用于检查长时间任务是否持续推进、保存状态、续租所有权、响应取消，并留下足以解释部分结果的证据。

Skill 用来做什么

长运行智能体测试 Skill 将进度检查点、租约续期、重启恢复、取消行为和部分结果规则整理成结构化评审。

Awesome QA Skills: https://github.com/naodeng/awesome-qa-skills 按语言和测试阶段组织 Skill。系列总览: https://inaodeng.com/zh-cn/blog/ai-testing/introduction_of_awesome_qa_skills/ 解释通用安装方式，本文只聚焦长运行智能体测试。

当证据来源冲突，或交接时需要说明哪些内容仍未验证，可以用它梳理待决项。每条规则都应关联来源和验证动作；设计清单只能支持设计复核，不能证明运行通过。

它不做什么

长运行智能体测试 Skill 可以整理进度规则的材料、证据和下一步动作，但不能替代：

  • 业务或领域负责人对规则、范围和风险的确认。
  • 真实环境、账号、数据、日志或运行结果；静态分析不会自动升级为运行证据。
  • 发布、合规、生产操作和残余风险接受等授权决定。
  • 在输入相互冲突时替团队选择一个未经确认的事实。

它主要检查哪些内容

这个 Skill 的价值不在于把关键词再列一遍，而在于把每个关注点接到可观察的输入、判断和收口动作。先用源 Skill 已定义的输出字段整理一张小矩阵：

检查关注点开始前要问结果应留下什么
进度记录阶段、检查点的含义，以及计数如何对应到已完成工作可按相同规则复核的进度说明
心跳与存活信号心跳只表示工作进程仍响应，还是能关联到实际处理进展？与检查点、已提交 step 或条目清单分开的存活证据
中断结果重启或取消后保留了什么partial、cancelled、recovered 或 unknown
重复提交与运行动作task ID 的重试策略是什么？租约、队列或资源变更如何核验？幂等规则、提交/恢复证据、负责人和验证动作

如果某一行只有经验判断、没有来源或验证方法，就把它留在待确认项里，不要提前写成通过。

开始之前先审计输入

开始分析前，先把输入归为六种证据状态。材料缺失不等于运行失败，但必须保留在结论里。

状态含义本 Skill 的处理方式
known材料直接证明的事实标出来源、版本和时间，允许进入判断
missing本轮需要但尚未提供的材料列出最小补证动作，结论保持受限
conflicting来源之间互相矛盾并列来源和冲突点，交给负责人裁决
stale材料存在但版本或时间已经过期标出新鲜度，不把旧结论当当前事实
out_of_scope有关但不在本轮范围内明确排除，避免分析悄悄扩大
assumptions为继续分析而暂时采用的假设写出验证方式和失效条件

至少把输入版本、范围、环境、证据位置和负责人放在一起。没有运行记录时，只能交付分析、设计或验证计划，不能写执行通过。

从问题到结构化发现

先把来源、范围、证据状态、分析判断、责任角色、动作、关闭条件和验证方式连起来，再写结论。下面的案例保留这个 Skill 的专属编号和领域语境。

分层写法

不要把事实、推断、建议和人工决策揉成一句“建议通过”：

层次写法本文应用
事实材料直接显示了什么引用来源中的重点、版本、输入或运行记录
基于证据的推断多个事实共同支持的判断说明推断链，并保留不确定性
建议下一步最小动作是什么指定补证、复核、执行或回归路径
人工决策谁需要决定什么由负责人确认范围、风险接受、资源和发布含义

一个完整案例

本节按输入、分析、发现、决策和验证展开；材料不足时保留 missing、conflicting 或 assumptions，不把它们改写成通过。

输入

材料这次提供什么缺失时怎么处理
任务契约工单数量、阶段划分、完成定义和部分结果策略不要用运行时长推断完成
运行控制task ID 与重复提交策略、工作进程租约、检查点/心跳、重启、取消、队列和资源生命周期没有观察到的状态变化标记为 unassessed
证据任务 ID、检查点记录、处理数量、重复标记和取消审计没有运行记录时不要下可靠性结论

可以这样调用：


请使用 agent-long-running-testing Skill。

任务：Agent 花两个小时处理 8 万条客服工单，期间 Worker 可能重启，用户也可能取消任务
输入材料：[需求、版本、链接、日志、报告或数据路径]
范围：[本次包含和排除的对象]
运行证据：[task ID、检查点与状态版本、心跳、处理清单、租约、取消记录和副作用]
未知项：[缺失的环境、账号、数据或权限]
期望输出：[按风险排序的发现、证据状态和下一步动作]

先审计输入。分开写事实、假设和待确认问题。没有运行记录时不要声称已经执行。

分析

本例先设定一个范围明确的任务：智能体花两个小时处理 8 万条客服工单，期间工作进程可能重启，用户也可能取消任务。在第 37 个检查点暂停分类任务，重启工作进程，再把恢复后的输入集合与检查点清单对照。要核对的是哪些工单被继续处理、跳过、重复处理或仍未分类，而不只是任务界面是否显示“已恢复”。这是检查方法示例，不代表已在真实系统运行。

交接产物要同时保留输入版本、时间窗口、证据索引、负责人和下一次验证动作。Skill 可以整理不确定性，不能制造缺失的产物。

把恢复、租约和取消拆成可观察的检查

沿用同一任务，每次只触发一种中断条件。先确认任务契约定义了什么才算完成、取消和部分完成，再检查运行记录是否支持这些状态。

检查操作条件需要核对的记录
检查点恢复在检查点后重启工作进程检查点中记录的输入范围、状态版本、重启后的续跑位置、重复与遗漏项
租约接管暂停持有租约的工作进程，等租约到期并由其他工作进程接管，再恢复旧进程新旧持有者、租约版本或 fencing token，以及旧进程是否还能提交
重复提交使用相同 task ID 或请求标识再次提交任务项目幂等/去重规则、已提交副作用和处理结果；不要假定 exactly-once
取消传播在一个批次处理中发出取消请求请求时间、确认时间、未完成项、仍在运行的子任务，以及用户可见终态
部分结果在任务中途结束或因依赖故障暂停已完成与未完成项、结果时效、能否安全供下游使用，以及后续恢复或重试方式

如果系统没有提供输入清单、提交标识、状态版本或租约记录，先把这些缺口写成待补证项。不能仅凭心跳或进度数字判断是否丢失、重复或安全地完成了工作。

发现

示例发现：把一次问题写成可交接动作

下面的字段示例只展示记录方式，不代表真实环境已经执行。

假设当前材料无法证明进度定义已经满足契约，发现可以这样写。它既不替团队补写规则，也不把缺失证据伪装成失败。

字段示例写法
来源与范围记录本轮使用的需求、版本、环境和具体检查点规则
发现检查点如何对应已完成工作，仍缺少可追溯依据
证据状态missing / assumptions；如果来源相互矛盾则改为 conflicting
影响与优先级说明会影响哪个用户、链路或交付决定，不凭感觉扩大等级
负责人和人工决策由业务、开发、安全或测试负责人确认规则和风险取舍
动作与关闭条件补齐最小证据；关闭条件是来源、判断和责任人都能复核
验证指定一次可重复的检查、查询或运行，并保存原始产物

这类记录的重点是让下一位同事能从发现回到来源，再执行一项能改变结论的动作。

决策

责任角色和待决策问题应由对应负责人确认；Skill 不替他们做风险取舍。

验证

关闭前按发现中的验证方式执行，并保留原始产物；没有执行记录时，状态仍然保持未验证。

发现如何进入下一阶段

交接产物

输出字段它要回答什么示例状态
进度记录阶段、检查点的含义，以及计数如何对应到已完成工作可按相同规则复核的进度说明
中断结果重启或取消后保留了什么partial、cancelled、recovered 或 unknown
运行动作需要验证的租约、队列或存储改动负责人和所需证据

没有运行记录、查询结果或原始产物时，不要写“已通过”。检查点应能说明哪些工作已持久化；单独的心跳只能表明系统仍在响应。还要核对同一工单会不会被重复处理、租约会不会在阶段中途过期，以及取消后是否仍有任务运行。

下一步路由

至少交付来源、证据状态、负责人、关闭条件和验证动作；下一阶段的结论仍受证据状态约束。

怎样准备更好的输入

如果第一次调用只有一行目标，输出就应该保持受限。补充来源版本、受影响对象、环境、已知缺陷和决策负责人，才能从“看起来完整的清单”推进到可用评审。

和其他 Skill 怎么配合

容易踩的坑

  1. 使用百分比，却没有定义哪些工作已经持久化。
  2. 因为工作进程停止就把取消任务写成成功。
  3. 只跑通顺利完成的路径，忽略租约过期。

安装与调用

安装这个 Skill：

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill agent-long-running-testing

安装后使用 agent-long-running-testing Skill，并附上真实项目材料。

常见问题

系统只提供一个进度数字怎么办？

把它当成待验证声明；在相信它之前要求检查点或条目级证据。

部分结果可以直接发布吗？

只有当契约定义了完整度、时效性和下游安全使用方式时才可以。

心跳能证明任务在推进吗？

不能单独证明。心跳通常只能说明进程仍在响应；还要用检查点、已提交步骤或条目级结果核对实际进展。最终状态仍以项目契约和运行证据为准。

参考

源 Skill 与执行契约

完整执行契约见长运行智能体测试提示词: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/agent-long-running-testing/prompts/agent-long-running-testing.md。调用 Skill 前先阅读它；提示词定义了详细流程和输出契约。源目录: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/agent-long-running-testing 中还包含入口文件以及实际存在的配套资料。

入口文件重点约束进度检查点、租约续期、重启恢复、取消行为和部分结果语义。写结论前先阅读配套提示词，并保留这个 Skill 的决策边界。

安全测试白盒测试背靠背测试本地化测试边界测试
分享