代理停用测试要覆盖凭证、授权与队列

把一个 Agent 在后台设为停用，再收到撤销成功的响应，能证明它已经失去行动能力吗？作者的答案是：还不能。旧凭据可能仍被资源接受，新凭据可能照常签发，队列里的任务也可能继续执行。

原文围绕虚构的文档收集 Agent「Intake Worker」，提出了一套退役测试方案。它没有实测撤权耗时，也没有给出通用达标秒数，但把一个容易漏测的问题讲清楚了：Agent 下线需要验证整条权限和任务链路，不能只看管理后台的状态。

停用身份，为什么不等于收回全部权限

作者首先拆开了几个经常被混在一起的对象：身份记录、凭据、授权、资源访问、任务队列，以及已经完成的业务效果。

身份记录说明这个工作负载由谁负责、被批准做什么；凭据用于证明它有权发起访问；授权决定访问范围；资源服务还会独立决定是否接受请求。调度器和下游服务则负责执行工作，生命周期未必跟着 Agent 进程一起结束。

身份停用只是一个状态变化，完整退役需要其他系统分别落实这个决定。

这里的实际难点是：这些对象通常分属不同系统。注册中心显示已退役，并不能直接推出 OAuth 连接器已停止签发，也不能推出资源缓存已经更新。因此，作者要求保留各对象独立的标识和状态转换，才能逐项核对，而不是拿一个总状态覆盖全部过程。

原文提到 NIST 在 2026 年 10 月 27 日发布的 Agent 身份设计原则博客，讨论独立生命周期和可动态撤销的权限。作者明确把它当作仍在讨论的设计指导，没有将其视为规范性协议或认证标准。

测试前还要定义验收约定：新任务是否禁止进入，待执行任务是取消还是排空，哪些操作必须在指定时间内停止。这个时间目标应来自业务风险，原文没有提供统一数值。

示例状态包括 active、transfer-pending、suspended、retiring、retired。名称可以调整，关键是每次转换会怎样影响权限。retiring 可以表示仍在核对遗留任务，retired 则不该掩盖尚未处理的队列。

撤销响应成功后，还要测哪些访问路径

OAuth token revocation 的 RFC 7009 定义了令牌撤销端点，也讨论关联令牌行为和传播问题。但它的成功响应可能覆盖令牌本来就无效的情况，所以这个响应只能说明撤销请求得到了处理，无法证明所有资源都已经拒绝访问。

作者设计了两项独立测试。第一项是在隔离环境中保留退役前的测试凭据，越过退役时间点后，对每个相关端点尝试无害的受保护操作，记录接受或拒绝。第二项是沿工作负载平时使用的路径，重新申请凭据。

只封住旧凭据，可能只是迫使工作负载换一把钥匙。

AWS 的角色会话撤销被用来说明这种差别：其文档描述的机制使用拒绝策略，限制截止时间之前签发的会话；之后签发的会话不在这项限制内。作者没有把 AWS 的具体机制推广到其他平台，而是提醒读者同时检查旧会话和新的角色承担或签发路径。

资源端的陈旧状态也要主动制造。如果资源使用 OAuth introspection，即向授权服务查询令牌是否有效，就应测试它恰好在退役前缓存了「有效」结果的情况。授权服务已经返回 inactive，不代表资源马上放弃缓存。

如果访问令牌在本地校验，则要说明后续撤权靠什么生效：到期、额外策略检查、拒绝机制，或其他受支持的设计。签名依然有效，只能说明令牌符合签名校验条件，不能传递后来发生的管理决定。

测试还应覆盖令牌状态服务不可用时的行为：资源是拒绝访问、使用缓存，还是走另一条已约定的路径？作者没有要求所有业务一律选择同一种策略，要求的是退役时不能冒出未记录的回退行为。

网关拒绝也不足以代表全部路径。备用连接器、可直接访问的资源入口，都需要分别验证。记录中应包含访问路由、工作负载身份、策略版本和结果，同时避免保存原始密钥。跨服务计算时间间隔时，还要保留时钟来源或误差，不能默认各系统完全同步。

进程停了，已经接单的下游怎么办

权限测试解决未来还能不能访问，队列测试则处理已经被接受的工作。

作者建议先停止 Intake Worker 的调度器，再找出已经入队的任务，验证它们是否按约定取消、隔离待审，或经明确授权继续完成。之后还要追踪下游系统已经接收的任务。只有集成本身支持取消，并返回了确认，才能据此认定下游取消成功。

已经完成的业务效果需要另记一笔。例如，索取文档的请求已经发出，撤销 OAuth 权限无法让收件人忘记它。如果需要纠正，应由获得相应授权的执行者采取补偿动作，并保留原始效果与补偿动作的关联，不能覆盖原始证据。

所有权转移也不能简化成改一个负责人字段。需要保留前任负责人的生效区间、记录新负责人的接受，并重新审查授权和运维职责。转移测试要同时证明：应保留的操作还能执行，应移除的操作已被拒绝。

我的判断

这套方案最有价值的地方，是把「设置成功」改成了「行为有证据」。比只验证撤销接口返回值，它更接近业务真正关心的结果，尤其适合同时接入外部服务和异步队列的 Agent。

但它仍是一份测试设计，没有实现，也没有撤权性能实测。原文没有给出不同令牌设计、缓存配置或撤权机制的对照数据，无法据此判断哪种方案更快、更可靠。把它当作测试清单合理，把它当作性能结论就越界了。

它还依赖足够完整的资产清单。有限次数的拒绝记录，证明不了不存在未知凭据或遗漏入口。报告必须写明哪些集成已覆盖、哪些不可用、哪些假设没验证。对小团队而言，可以先覆盖实际使用的连接器和任务链路，再随清单补齐测试。

能拿来做什么

• 给现有 Agent 的停用流程补两项验收：使用旧测试凭据访问资源，以及沿正常路径申请新凭据。分别保存结果，避免一个撤销响应代替两项判断。
• 如果 Node 服务同时承担调度和队列消费，明确停止派单后，已排队任务与下游已接收任务各自如何处理，并验证取消是否真的得到确认。
• 在隔离测试环境里加入缓存仍有效、令牌状态服务不可用、资源可绕过网关直连等用例，记录实际执行的策略和路径。
• 为日常 AI 编程中调用外部工具的 Agent 建立退役记录，把身份负责人、授权范围、任务处置和未验证入口关联起来，后续发现遗漏时补成可重复测试。