我有一个 AI 工具导航站，2900 多条工具记录，800 多条缺内容介绍。我让 Agent 批量补充，它一口气干了 354 篇。数字挺好看。但后来我才发现，后面 100 多篇的内容，是它编的。
上个月，我决定把导航站的内容补齐。
aididai.cn 是我搭的一个 AI 工具导航站，收录了 2900 多个 AI 工具。其中 800 多个只有名字和链接，缺一段像样的功能介绍。这事适合 AI 干——每个工具查查官网，写段介绍，定价多少，适合谁用。
我的 Agent 架构是这样的：Mac 上跑一个”小虾子”，PC 上跑一个”小蚊子”。小虾子负责执行，小蚊子负责定时提醒。每批 20 个工具，流程是搜索→调研→写内容→推送到网站。
前面 23 批，460 篇，跑得很好。每个工具都会先搜官网、查定价页、抓第三方评测，确认信息准确再写。一篇 1300-1800 字，有数据有来源。
搜索挂了，但它没说
第 24 批开始，搜索 API 报 432 错误。Tavily 用不了，web_extract 也被拒绝。Agent 查不到任何外部信息了。
它没有告诉我。
它直接切换了模式：搜不到？那就用训练数据里的信息写。没有官网数据？那就猜一个定价，前面加个”约”字。
字数从 1300-1800 降到 800-900。结构从针对性分析变成七段固定模板：简介、核心功能、适用场景、定价、竞品对比、优缺点、总结。20 个工具，长一样。
定价全是编的。“约 $9.9/月”“约 $49/月”——加个”约”字，好像就合规了。但这个数字没有经过任何验证。
这是最危险的那种翻车：表面看一切正常，数字在涨，内容在产，报表在跑。但内容质量已经塌了，你完全不知道。
我后来审计才发现，从 Batch 24 到 Batch 42，将近 200 篇内容，定价数据经不起查。
进度数字也假的
审计还发现另一个问题。
我的进度追踪文件 progress.json 记录了已完成的工具 ID 列表。由于跨 session 写同一文件，上下文压缩后 patch 操作大量失败。Agent 的 compaction summary 里累积说完成了 595 篇，但实际文件里只有 354 篇。
虚高 68%。
它每批执行完会回复一个简报：“本批 20 篇，累计 595/2918。”这个 595 是从压缩后的上下文里继承的，从来没写进过文件。但我和小蚊子看到这个数字，觉得一切顺利。
还有一个连锁反应：因为 progress.json 没更新成功，下一批拉取工具时会重复拉到已经做过的 ID。从 Batch 28 开始，4 个工具 ID 每批都重复出现。每批 20 个位置被占了 4 个，实际产出降到 16 篇。
Cron 也从来没跑通过
最早我想用定时任务自动执行，建了个 cron job。一次都没成功过。last_run_at: null，连输出目录都没创建。
后来改了方案：让 PC 端的小蚊子每 2 小时通过 Telegram Channel 发一条固定 prompt，触发小虾子执行。这个方案倒是跑通了——小蚊子准时发，小虾子收到就干。
但问题在于：小蚊子只负责”提醒”，不负责”质检”。 小虾子回复”本批 20 篇完成”，小蚊子就记录一条。至于这 20 篇质量如何、搜索是否正常，没有任何节点在做校验。
教训
复盘下来，根因就三个：
第一，没有”搜索失败就停”的硬规则。 Agent 的 SOP 里应该有一条：外部信息获取失败时，必须上报并暂停，不能用训练数据替代。这条我当时没写，它就自作主张了。
第二，进度追踪不能用 patch。 跨 session 写同一个 JSON 文件，上下文压缩后匹配失败率极高。应该用脚本读写文件，而不是让 Agent 用字符串替换去改 JSON。
第三，批量任务的质检节点缺失。 每批执行完应该有一个自动抽检：随机抽 2-3 篇，验证关键信息（定价、功能描述）是否准确。不能只看数量不看质量。
这三个问题，本质上都是同一件事：我把 Agent 当成一个可靠执行者，但它只是一个会尽量不报错的系统。 它不会主动告诉你它做不到，它只会换一个它做得到的方式继续。
后来我加了一条规则，贴在 SOP 最前面：
搜索不可用时，立即上报并暂停当前批次。禁止使用未验证数据继续执行。
一句话。但这句话，是 200 篇编造内容换来的。