任务启动一切看起来都很顺利Chrome 调试端口 9222 在线知乎和头条号两平台登录态正常系统自动开始抓取。基线 596 条任务结束后变成 619 条——新增 23 条全部 pending历史 596 条状态变更 0、移除 0。铁律核验通过全程只抓取 生成草稿未 approve未 publish。但真正值得记录的不是这次顺利的结果而是系统背后那套铁律 分级 复扫的三层守护机制以及一次 LLM 熔断切换的实战经验。铁律核验为什么只抓不发布是底线自动发布系统最容易踩的坑就是抓得太快发得太猛。一旦审核逻辑有漏洞错误内容会瞬间扩散到多个平台。本次任务的铁律设计是抓取阶段只生成草稿不触发任何 approve 或 publish 操作。所有决策必须经过人工或二次审核才能进入发布队列。这套机制的价值在后续的高危存量复扫中得到了验证——如果没有这层铁律48 条 approved 内容中命中高危的 7 条可能已经真发出去了。内容分级实战23 条新增如何决策本次抓取的 23 条内容全部来自头条号模块知乎目标领域命中 0负向拦截 1 条。内容分级结果如下✅ 建议批准 22 条10 条评论回复Vue2 技术讨论、厨房油污清理、医院缴费流程、对联创作等12 条主动互动高铁候补经验、机车赛事、宇树机器人、网红训狗师败诉等无敏感漏网❌ 建议拒绝 1 条某条 engage 内容正文点名敏感政治机构scrape 选题期漏网post-hoc 内容过滤判 block这个案例说明了一个关键问题选题期过滤无法覆盖所有内容风险必须在发布前增加 post-hoc 内容审查层。即使 LLM 在选题阶段判断为安全最终审核环节仍有可能拦截高危内容。存量高危处理48 条 approved 复扫的警示本次任务最触目惊心的发现是 48 条已 approved 的存量内容中复扫命中 7 条高危。其中 1 条被标记为必降级/reject某重要政治人物诞辰纪念大会相关内容。6 条 caution涉及卫星发射、外轮碰撞纠纷、地方通报、相亲话题、明星相关等。这批高危内容如果执行批量 publish --execute会直接发出去。这暴露了一个系统性风险approved 状态不等于安全存量内容需要定期复扫。当前积压情况pending 562 approved 48 610 条未消费。抓取速度远快于消费速度建议优先处理高危存量再恢复抓取。稳定性保障LLM 熔断切换与代理配置本次任务中agnes-2.0-flash 模型持续触发 429 熔断。系统自动切换到 mimo-v2.5-pro通过 max_tokens 截断加预算重试恢复未发生子步降级铁律修复机制持续有效。代理配置方面也踩了一个坑会话自带 HTTP_PROXY但 CDP 连接需要直连。通过 export NO_PROXY‘localhost,127.0.0.1’ 绕过代理后CDP 才正常连通。这个细节提醒我们自动化系统中不同组件的网络需求可能不同proxy 配置需要精细化区分。可带走的方法论基于本次任务总结出以下可复用的经验铁律优先自动发布系统必须做到抓取与发布分离草稿生成和正式发出之间必须有明确的状态闸门多层过滤选题期过滤 post-hoc 内容审查 高危存量复扫三层机制缺一不可存量优先当 pending approved 积压超过阈值时暂停新抓取先消化高危存量熔断预案LLM 服务不稳定时自动降级到备用模型但必须保证核心逻辑如铁律核验不降级网络隔离CDP、API、代理等不同网络需求要区分配置避免一刀切的 proxy 设置做自动化这几年最耗时间的从来不是写代码是摸清每个平台的脾气。这篇里提到的坑都是真金白银踩出来的。如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作——可以在评论区说说你的场景我看看能不能自动化掉。