AI求职Agent排障：610个职位全被误删的根因

原文首发于 aideazz.xyz — 此处转载并附上规范链接。

我的 AI 求职助手 VibeJobHunterAIPA_AIMCF 从 Torre 丢弃了 610 个拉丁美洲职位。这不是过滤错误；而是助手与数据源交互方式上的根本性配置错误。助手明明抓取到了这些职位，却立即将它们丢弃，原因是预期的处理窗口被设为 20 秒，而 Torre 实际需要 90 秒。这一个修复（在过去 48 小时内 12 次提交之一）凸显了生产级 AI 系统中与静默失败斗争的常态。

修复数据源盲点

Torre 问题是一个典型案例：助手执行了任务（抓取数据），却因期望值未对齐而无法将其纳入工作流。修复提交 5af1858（2026-09-29）fix(sources): Torre gets 90s, not 20s — it was fetching 610 LATAM jobs and discarding them all 直接针对此问题。助手实际上对其潜在职位池中的大量_segment_视而不见。

另一个关键的数据源修复涉及 Himalayas。助手搜索结果为零，导致没有任何相关结果。提交 06f6329（2026-09-29）fix(himalayas): the source searched nothing — use /jobs/api/search, one query per lane 通过实现正确的 API 端点和查询结构纠正了这个问题。没有这个修复，整个招聘板对助手来说实际上处于离线状态。

"bright-data door"也带来了挑战。助手基于位置屏蔽职位摘要，而不是完整的招聘信息。这意味着潜在相关的职位在太早的阶段就被过滤掉了。修复 0a980de（2026-09-29）fix(bright-data door): search where she can work, and gate the posting, not the snippet 确保助手根据位置条件评估完整职位描述，提升了准确性。

这些修复不是为了添加新功能；而是为了确保现有数据管道按预期运行，防止静默数据丢失，并提升助手考量的职位池整体质量。

解决学习与反馈回路

AI 助手开发中的一个重大挑战是确保"学习"真正转化为性能提升。我的求职助手在 2026-09-28 有一条 wiki 事件记录："求职助手从每次拒绝中学习——但这些学习都无法改变它所展示的内容。"助手在读取运营者的拒绝备注和截图，总结原因，并将它们输入给评判者的 prompt。然而，同类型的职位还是不断出现。教训被处理了，但无法覆盖助手的核心筛选标准。

提交 debac32（2026-09-29）fix(learning): the "📌 JOB POSTING" note on hand-staged jobs is never her reason or her "applied" 直接针对了这个问题的一部分。助手误将手动分期职位上的"📌 JOB POSTING"备注解读为申请或拒绝的理由，而实际上它只是一个内部标记。这种细微的误读污染了学习数据，阻止了真实的反馈影响未来的职位发现。

有效的 AI Agent 求职修复需要的不仅是数据输入，还需要在助手的学习机制中正确解读这些输入。

增强 LLM 可靠性与验证

助手依赖 LLM 处理 LinkedIn 帖子和回复分类等任务，需要比单一提供商更稳健的方案。提交 11bd8d2（2026-09-28）fix(llm): LinkedIn posts and reply triage go through the 5-provider waterfall, not Claude alone 实现了多提供商瀑布式调用。这降低了单点故障风险，并允许交叉验证，提升了 LLM 驱动决策的可靠性。

此外，此前声称的 LinkedIn 处理"131 个测试"未经验证。提交 2fd2a28（2026-09-28）fix(linkedin): drop the unverified '131 tests' claim — 600+ checks, measured 28 Sep (643 passing) 更新为反映实际测量值：超过 600 项检查，9 月 28 日有 643 项通过。这种对准确、可衡量指标的承诺对于建立对助手性能的信任至关重要。

系统稳定性与监控

VibeJobHunterAIPA_AIMCF 在过去 48 小时内有 12 次提交，但我的 Oracle Cloud 实例上其他关键进程显示出不同程度的稳定性。cto-aipa 有 175 次重启，且已运行 0 天，表明近期有部署或不稳定性。algom-stream 在 44 天内有 55193 次重启，这是我之前讨论过的一个已知异常。相比之下，algom-poll 在 63 天内 0 次重启，n8n 在 47 天内 0 次重启，展示了稳定运行。

我的 serpapi-jobs 进程（与职位来源直接相关）有 2 次重启，且已运行 0 天，表明近期有调整或轻微故障。pm2-logrotate 进程（对日志管理至关重要）在 1 天内有 5 次重启。

通过 pm2 jlist 监控这些重启是每日的例行工作。它提供了系统健康状况的即时高层视图。apply-queue.log 显示 ✓ sent to Telegram (2 new)，表明成功的职位申请被推送到我的通知渠道。job-board-watch.log 显示 VERDICT: REJECTED 和 VERDICT: QUALIFIED，表明对职位板来源的持续评估。

concierge-selftest.log 显示 ✅ PASS — 4 checks, 6373ms to first card，确认核心通知系统功能正常且响应迅速。这些日志是我了解助手实时性能的眼睛和耳朵，使我能够快速识别和解决问题。

常见问题

Q: 你如何确定 AI Agent 求职修复的优先级？

A: 我根据对职位发现量、申请成功率以及关键数据完整性的直接影响来确定修复优先级。例如，修复 Torre 610 个被丢弃职位的问题比小的 UI 调整优先级更高，因为它直接影响助手找到相关机会的能力。

Q: 像 Himalayas 搜索问题这样的关键修复，典型周转时间是多少？

A: 对于关键数据源问题（如 Himalayas 修复——助手当时实际上什么都没搜索到），从识别到部署的周转时间通常在数小时内。提交 06f6329 是 VibeJobHunterAIPA_AIMCF 在 48 小时内 12 次提交的一部分，表明快速迭代。

Q: 你如何确保从拒绝中的"学习"真正提升助手的性能？

A: 我通过将拒绝原因直接关联到助手的 prompt 标准，并持续监控它呈现的职位类型来确保学习有效。例如，debac32 提交消除了对"📌 JOB POSTING"备注的误读，这种误读污染了学习数据并阻止了真正的改进。

Q: 为什么对 LLM 任务使用 5 提供商瀑布而不是单一强大 LLM？

A: 对 LinkedIn 帖子分类等 LLM 任务使用 5 提供商瀑布（如 11bd8d2 中实现的）增强了弹性和准确性。它减轻了单一 LLM 提供商宕机或幻觉的风险，并允许基于共识做决策，这对敏感任务至关重要。

Q: 你如何追踪 LinkedIn 处理的"643 项通过"检查？

A: 643 项通过的检查是通过针对 LinkedIn 处理模块运行的自动化测试套件来测量的。这个指标在 9 月 28 日更新，提供了一个具体、可验证的数字来反映助手的功能完整性，取代了此前未经验证的 131 个测试的声称。

— Elena Revicheva · AIdeazz · Portfolio