他花3周搭了套无人求职系统，最后每天只投出2份简历

150条线索自动筛选、公司背调、简历定制、求职信生成——全部无人值守。这套系统跑了两周，作者昨晚拉数据时发现：实际投出去的申请，平均每天2份。

2比150。这就是自动化求职的隐藏瓶颈。

「最难的部分不是研究，是提交」

作者用这套系统做了完整复盘。 intake 层（信息输入层）确实漂亮：机会发现、评分排序、公司研究、材料定制，全流程 cron 定时任务驱动，零人工触发。API 调用、大语言模型（LLM）、基础评分逻辑——这些组合起来，搭建速度比想象中快得多。

但 execution 层（执行层）完全是另一回事。

求职表单对自动化极度不友好。以 Greenhouse 为代表的申请人追踪系统（ATS）需要 headed 浏览器（带图形界面的浏览器）、CAPTCHA 验证、动态字段检测、超时重试机制——每个环节都可能独立崩溃。一次失败，整份申请作废。

作者检查了44份卡住的申请。求职信质量没问题，最后三份人工审核全过；申请链接也有效。它们卡住的原因只有一个：提交层在以「滴灌」模式运行——8个并行转换定时任务，每个一次只处理一份申请，遇到 ATS 表单异常就静默失败，然后继续下一个。

结果是一套「重发现、轻执行」的系统：管道流速很漂亮，但离「拿到面试」这个目标还差得远。

四条架构教训

作者从这次踩坑中提炼了四条规则，适用于任何重复性任务的自动化代理构建。

第一，按失败面（failure surface）评级，而非复杂度。信息输入层失败很干净：调用失败，记录日志，重试即可。执行层失败很脏：表单提交了，确认页加载了，但 ATS 根本没存你的申请。这类问题难调试，静默失败时成本更高。

第二，批量优于滴灌。8个并行滴灌任务创造8个同时失败的窗口。换成单一批次会话——人工监督下集中处理44份待投申请——90分钟的产出可能超过滴灌模式一整周。有时候正确的自动化是「准备好一切，然后一次性人工复核执行」。

第三，转化缺口（conversion gap）才是核心指标。发现速度（每天多少线索）是虚荣指标。真正重要的是转化：从「准备好提交」到「实际提交」。每天发现150个机会却只投2份，这是转化缺口，不是输入问题。别再增加输入层的定时任务了。

第四，静默失败是最坏的失败。它们让你误以为系统在运转，实际上什么都没有发生。

一个被忽视的真相

这个案例戳破了一个常见幻觉：自动化代理的瓶颈永远在「智能」层面——更好的模型、更准的评分、更个性化的内容。

现实是，当基础模型能力已经够用时，真正的摩擦点在「最后一公里」：表单提交、支付流程、邮件发送、日历预约——这些看似低技术含量的动作，往往藏着最复杂的异常处理和最隐蔽的失败模式。

作者没有给出完美解决方案。他只是在数据面前承认：自己的系统目前更适合作为「人工投简历的预处理流水线」，而非完全无人值守的投递机器。

那个每天2份的数字，会不会就是当前技术条件下，全自动求职代理的真实天花板？