AI-Wiki

文档概览

该页正文不是一篇解释 Worker Service 设计、流程或故障处理策略的叙述性文档，而是一段 JSON 结构示例。它更像某一时刻的状态快照，用来展示 Worker Service 当前队列、最近处理完成项以及仍有待处理工作的 session 聚合视图。

从结构上看，顶层共有三个部分：

queue：描述当前队列本身，包括消息列表和统计值。
recentlyProcessed：描述最近处理完成的项目示例。
sessionsWithPendingWork：给出哪些 session 仍然存在待处理工作。

因此，这一来源页的价值主要在于暴露 Worker Service Queue State 的数据形状，而不是解释其业务背景。

关键事实

顶层 JSON 结构

示例 JSON 的顶层键只有三个：

queue
recentlyProcessed
sessionsWithPendingWork

这表明页面关注的是 Worker Service 的运行时状态视图，而不是配置项、部署方式或 API 文档全集。

queue 部分

queue 下包含两类信息：

messages：当前队列中的消息示例数组。
一组统计字段：totalPending、totalProcessing、totalFailed、stuckCount。

queue.messages 中单条消息示例字段

示例消息对象包含以下字段：

id：123
session_db_id：45
claude_session_id："abc123"
message_type："observation"
status："pending"
retry_count：0
created_at_epoch：1730886600000
started_processing_at_epoch：null
completed_at_epoch：null

这些字段至少说明了队列消息会同时携带：

队列项自身标识 id；
所属 session 的数据库标识 session_db_id；
一个独立的 claude_session_id；
消息类别 message_type；
处理状态 status；
重试次数 retry_count；
创建时间与处理起止时间的 epoch 时间戳字段。

消息状态示例所反映的含义

该示例消息的 message_type 为 observation，status 为 pending。同时：

started_processing_at_epoch 是 null；
completed_at_epoch 是 null。

这组取值共同表明，该消息已经进入队列并具有创建时间 1730886600000，但尚未开始处理，也尚未完成。

retry_count=0 进一步说明示例中的这条待处理消息还没有发生重试。

队列统计字段及示例值

queue 中给出了四个统计字段，示例值分别为：

totalPending=5
totalProcessing=2
totalFailed=0
stuckCount=1

这些值表明，示例快照对应的系统状态并非空闲：

有 5 条待处理消息；
有 2 条消息正在处理中；
失败消息数为 0；
但仍有 1 条被标记为 stuck 的项目。

也就是说，即使 totalFailed=0，系统中仍可能存在 stuckCount=1 的异常或卡住状态，两者并不等价。

recentlyProcessed 部分

recentlyProcessed 是一个数组，示例中包含一个最近处理完成的对象。该对象包含字段：

id：122
session_db_id：44
status："processed"
completed_at_epoch：1730886500000

这里的关键点是：

该部分强调“最近完成”的结果视图；
示例状态明确为 processed；
相比 queue.messages 中的待处理项，这里给出了完成时间 completed_at_epoch。

从示例可见，recentlyProcessed 对象字段明显少于 queue.messages 的完整队列消息字段，说明这个视图更偏向结果回顾，而不是完整任务生命周期明细。

sessionsWithPendingWork 部分

sessionsWithPendingWork 的示例值为：

[44, 45, 46]

这说明页面不仅提供逐条消息视图，还提供了按 session 聚合的待处理工作视图。换言之，系统可以直接指出哪些 session_db_id 仍然存在尚未完成的工作，而不要求调用者自行遍历全部消息后再做聚合。

重要细节

这是状态快照示例，不是完整协议说明

原文只有一段 JSON，没有对字段语义、状态转移规则、重试策略、卡住判定标准或时间戳单位之外的附加解释。因此可以确认其用途是“展示结构与样例值”，但不能从这一页单独推出完整的处理机制。

例如：

页面展示了 pending 与 processed 两种状态值，但没有声明状态枚举是否只有这两种；
页面展示了 retry_count，但没有说明最大重试次数；
页面展示了 stuckCount，但没有说明什么条件会把消息归类为 stuck；
页面展示了 epoch 字段，但没有解释时区、精度约束或是否总为毫秒级，不过从数值形态看是毫秒 epoch 示例。

queue 与 recentlyProcessed 代表不同观察面

同一份快照同时给出：

队列中的一条待处理消息；
最近处理完成的一条消息；
仍有待处理工作的 session 列表。

这意味着该状态结构至少试图覆盖三类运维关注点：

当前还有什么任务在排队；
刚刚完成了什么任务；
哪些 session 仍然积压了工作。

示例中的 session 关联关系

示例待处理消息属于 session_db_id=45，而 sessionsWithPendingWork 列表中也包含 45。最近处理完成的消息属于 session_db_id=44，而待处理 session 列表同样包含 44。这说明某个 session 即使已有一条消息被处理完成，仍然可能因为还有其他待处理项而继续出现在 sessionsWithPendingWork 中。

这是一项重要边界信息：recentlyProcessed 中出现的 session，并不因此自动排除在“仍有待处理工作”的 session 列表之外。

Worker Service - Claude-Mem 摘要