AI队列事故：175条标记完成但零交付的排查实录

一个新添加的数据源按计划运行了一整天，每小时都记录了健康的数量，但下游却什么都没收到。系统报告成功，但输出队列是空的。这不是一次静默失败；而是一次响亮的成功，却什么都没产出。根本原因是去重账本在处理上限生效之前就将项目标记为已处理。我的 AI Agent 队列事故意味着 175 个项目被标记为已完成，却从未被实际处理。

那个交付了"零"的"成功"

然而，下游系统收到了零个项目。负责消费这些项目的 VibeJobHunterAIPA_AIMCF Agent 处于饥饿状态。问题不在于数据缺乏，而在于对"已完成"状态的错误归因。

去重账本如何烧掉了任务

问题的核心在于去重和处理的操作顺序。当新项目从数据源到达时，它们首先经过去重账本。这个账本的作用是防止同一项目的重复处理。如果一个项目已经被见过，它就会被标记为已完成并跳过。

关键缺陷在于这个完成状态是在系统处理上限强制执行之前就被应用了。我的 Pipeline 内置了一个上限来管理资源使用并防止下游服务过载。任何超过给定处理周期上限的项目都应该被留到下一个周期处理。

这就导致了 2026-08-30 日 VibeJobHunterAIPA_AIMCF 中的提交 3d68e45："wellfound: stop reporting success while returning nothing"。Agent 报告成功是因为去重账本说项目已经"完成"，但实际上对大多数项目没有执行任何工作。

修复：重排操作顺序

解决方案涉及这两个关键步骤的重排。处理上限需要在去重账本将项目标记为已完成之前应用。这确保了只有真正通过了处理上限且正在被处理或已完成处理的项目才会被标记为已完成。

这一更改记录在 2026-08-30 日 VibeJobHunterAIPA_AIMCF 的提交 36e985c 中："pipeline: stop burning jobs at the cap, and stop starving the best source"。这次提交直接解决了由于处理上限和去重账本的不正确应用导致项目被"烧掉"（丢弃）的问题。

这次事故凸显了 AI Agent Pipeline 设计中的一个常见陷阱：不同操作层之间的交互。如果不仔细考虑，看似合理的操作顺序可能导致静默的数据丢失。

监控与预防

虽然 immediate fix 是代码更改，但这次事故也强化了对稳健监控的需求——超越简单的"成功"指标。系统报告 ok 是因为去重账本已更新，但实际输出是零。这种差异需要特定的检查。

我目前的监控设置包括：

PM2 进程列表：我有 8 个进程在线，包括 cto-aipa 在 2 天内有 99 次重启，以及 algom-stream 在 14 天内有 55193 次重启。这些高重启次数是更深层问题的标志，但不会直接显示数据丢失。

日志追踪：我定期检查日志，如 concierge-selftest.log 显示 ✅ PASS — 4 checks, 3318ms to first card，以及 hs-watch-manual-emails.log 显示 "ok": true。这些对于即时运营状态很有用，但并不总是能捕捉到逻辑错误。

HubSpot 交易：我追踪"They replied"状态的交易（100）和已成交交易（0）。这些是业务指标，不是直接的 Agent 健康指标。

缺失的是一个直接的"已摄入项目"与"已投递给下游项目"的比较，以及预期的 delta。Wiki 上的 wiki: the queue marked 175 items done before anyone read them 词条现在作为提醒，要求为新数据源实现这个特定的指标。

操作员队列与共享上下文

我目前的操作员队列记录在 /home/ubuntu/cto-aipa/docs/oracle/NOW.md 中，明确说明："Cursor Cloud、Cursor Desktop 和 Claude Code 都在这个仓库上工作，但它们彼此看不到对方的聊天。没有共享对话，Cursor 中没有 Claude MCP，无法向另一个 Agent 发送消息。它们都能读取的唯一东西是 HubSpot 和这个文件。这不是文档。它是当前未运行的 Agent 的工作内存，而下面的协议是关于两个无法对话的 Agent 如何避免"。

这种 AI Agent 与人类操作员之间（甚至不同 AI Agent 之间）共享上下文的缺失，使得调试此类事故更具挑战性。NOW.md 文件充当关键的共享内存，但它是一个手动过程。自动化检测此类逻辑不一致（如"摄入了 X 个项目，投递了 Y 个项目，Y 远小于 X"）是一个优先事项。

常见问题

Q: 如果什么都没有投递，"175 个项目"这个数字是如何确定的？
A: 数据源的内部日志显示 175 个项目被成功摄入并传递到下一阶段，但下游系统的摄入日志显示为零。差额就是被去重账本在处理前标记为已完成的数字。

Q: 什么样的特定监控能更快地发现这个问题？
A: 一个专门比较"进入处理队列的项目"与"在处理前被去重的项目"的指标会立即标记出差异。我还没有测量这个，但现在是一个优先事项。

Q: 这与其他进程中看到的高重启次数有关吗？
A: 不，这次事故是 Pipeline 设计中的逻辑错误，不是稳定性问题。像 algom-stream 在 14 天内 55193 次重启，或 cto-aipa 在 2 天内 99 次重启，表明了不同类别的问题（如内存泄漏、未处理的异常），与这个数据流问题是分开的。

— Elena Revicheva · AIdeazz · Portfolio