当AI遇到404

收到链接  ↓尝试访问  ↓结果分类  ├── 正常访问 → 提取内容  ├── 404 → 进入恢复策略  ├── 403/登录 → 权限策略  ├── 超时 → 重试/换源  └── DNS失败 → 域名推断

目前主流 AI 模型在处理 404、失效链接时，大致分成几类。

第一类是普通聊天模型，只会“访问链接→失败→报错”，通常提示“链接不存在或已失效”。这类系统本质是单轮问答，没有真正的搜索和任务恢复能力，策略也偏保守，宁可停止也不愿猜测。

第二类是搜索增强型模型，例如 Perplexity。它们会在链接失效后重新搜索关键词、寻找相似页面或替代来源，因此比普通聊天模型强很多，适合快速调研和信息聚合。但它们更偏“搜索+摘要”，长链路任务和复杂恢复能力有限。

第三类是 Agent 型系统，例如 ChatGPT、Claude、Google Gemini 的 Deep Research 模式。这类系统已经不是简单回答问题，而是尝试“完成目标”。当出现 404 时，它会继续搜索、重建路径、寻找镜像、交叉验证来源，甚至调整调研计划。OpenAI 系统偏主动恢复，Claude 更谨慎保守，Gemini 则依赖 Google 搜索生态优势。

更进一步的是 Browser/Computer Agent，例如 OpenAI Operator、Claude Computer Use 等，它们已经可以像人一样操作网页：返回首页、重新导航、点击菜单、重新搜索，而不只是分析文本。

不过行业目前仍未完全解决“高可信恢复”问题。很多系统虽然能推断正确方向，但仍可能出现“看起来合理但实际错误”的情况。因此现在最先进的方案通常不是单一模型，而是“LLM + 搜索 + Browser Agent + 验证系统”的组合架构。

以后需要用AI时，除了看跑分，还得看它们的“性格”

你是需要激进的来帮你完成目标，还是保守的尽量不出错

额，我最后又试了下新出的qwen3.7max，它告诉我404，没有瞎猜了

不是固定写死的“404→执行A→执行B”的单一路径，更像是一个动态策略流程。

可以把它理解成：

• 有一层通用的检索/纠错能力（模型本身）

• 外加一套工具调用策略（搜索、打开页面、重试）

• 再结合上下文推理来决定下一步

实际内部更接近下面这种决策链：

收到链接  ↓尝试访问  ↓结果分类  ├── 正常访问 → 提取内容  ├── 404 → 进入恢复策略  ├── 403/登录 → 权限策略  ├── 超时 → 重试/换源  └── DNS失败 → 域名推断

404 时不会只有一种处理方式，而是会动态判断：

这个 URL 像什么？- 官方文档？- GitHub？- 新闻？- PDF？- API？- SaaS 后台？

然后选择不同恢复路线。

例如：

GitHub：

• repo rename？

• branch 改名？

• issue 被关闭？

• release tag 变化？

Docs：

• v1 → v2 文档迁移？

• slug 改写？

• i18n 路径变化？

新闻：

• AMP 页面？

• syndicated 内容？

• archive 镜像？

所以它不是“硬编码流程”，而是：

通用推理 + 模式识别 + 工具策略

再细一点说，内部通常包含几类能力：

• URL 结构推断

• 实体识别（公司/产品/项目）

• 语义相似搜索

• 历史路径猜测

• 页面类型分类

• 来源可信度评估

• 缓存/镜像 fallback

但这些不是你传统理解里的：

if 404:    do_x()

而更像概率式决策：

“这个链接 78% 像文档迁移”→ 优先尝试 docs rewrite“这个像 GitHub rename”→ 优先搜索 repo 新名字

另外一个关键点：

我不会默认“404 就结束”，因为很多真实世界调研里：

• 链接过期

• 页面迁移

• SEO 改版

• CMS 重构

• 域名切换

是常态。

所以调研系统本身会倾向于：“恢复目标内容”而不是“严格依赖原 URL”。

你也可以把它理解成：

目标导向（找到信息）而不是路径导向（必须这个URL成功）

当然，这里面也有限制：

• 需要联网能力

• 某些私有页面无法恢复

• 强登录墙无法突破

• 原文彻底删除时只能找到二级来源

• 无法保证缓存内容100%一致

但整体上，它是“自适应恢复策略”，不是单一固定流程。