AI 工具老是失灵?高手不给 AI 换工具,给 AI 修路由

这两天刷到一个开源项目，冲上了 GitHub 热榜——Agent-Reach，一句话介绍是「给 AI Agent 装上眼睛」：让 AI 能自己去读网页、扒视频字幕、搜全网。看完仓库我反而觉得，它值钱的地方不在「能读多少平台」，而在它揭示了多平台接入这件事的正确姿势。今天展开讲讲。

先交代一句：项目信息来自二手渠道、我已回源 GitHub 仓库逐条核实，榜单热度这类数字发布前仍需人工核对。你重点看结构，别抠细节。

先说多数人用 AI 接外部平台的现状——让它去抓个网页、查个资料，靠什么？靠每次现场发挥。

这次运气好，工具能跑；下回平台改了版，整条链路就断。你让 AI 重来，它又从零踩一遍坑。这阶的短板：路是现走的，没有留下任何能复用的东西。

于是大家开始装工具：抓视频的装一个，读社区的装一个，每个平台配一个趁手的命令行工具。这一阶补上了「现踩坑」——至少每个平台有专门的工具了。

但新的缺口跟着来：每个工具都绑死在一个平台、一种做法上。平台风控一升级，工具说封就封。源仓库里就有个真实案例：抓取类工具被 B 站风控直接封死，之前依赖它的整套流程全部瘫痪，用户只能自己挨个找替身。

再往上，就是这个项目给出的答案——它不发明新工具，而是给每个平台配一张「首选 + 备选」的有序路由表。

比如读推特，路由表写的是：首选 A 工具，不行换 B，再不行还有备选。十五个平台，每个都是这个结构。而且有个关键细节：它不是「看看命令装没装」就标可用，而是挨个真实探测——坏了的后端会直接给出修复处方。

这一阶补上的是「换代」：平台封了某条路？改路由表里一行顺序就行，整体架构一行不动。所谓「接住平台变化」，接的不是运气，是表。

路由表还不算完，这个项目留了一条压舱石命令——doctor 体检。跑一下，它告诉你当前实际走的是哪条路，不是配置文件里「声明」的那条。

这一阶补上的是「自欺」。我这些年反复撞同一堵墙：配置里写了的东西，和实际真跑通的东西，经常是两回事。声明了可用，不代表实测可用——中间差的那一截，往往就是事故。把这两件事拆成两个口径、一条命令就能对账，这是整个设计里我认为值钱的一笔。

最后说回定位。作者原话说得很清楚：这是个能力层，不负责底层读取本身。它只干三件事——选型、部署、体检，真正的抓取动作由 AI 读完它的说明后直接调上游工具完成，不加包装。

这恰好回答了开头的问题：为什么有的 AI 系统三天两头失灵，有的却能长期稳跑？因为前者囤的是「工具」，工具会过期；后者攒的是「怎么接」的章法——路封了换条路，换的是表里一行字，不是推倒重来。

这套范式不只属于开源项目，你自己的 AI 工作流同样能对号入座：一，你的 AI 接外部平台，靠的是每次现踩坑，还是一张写下来的路由表？二，平台规则一变，你是推倒重来，还是改一行顺序就能续命？三，你说的「能跑」，是配置里声明的，还是体检命令实测出来的？

三问里只要有一问答不上，你的 AI 就还停在前两阶——不是工具不够好，是路没修对。AI 帮你读网页、查资料只是起点，让它在平台变脸时依然稳跑，靠的是这套「路由表 + 体检」的笨功夫。你手上的 AI 工作流，断过几回？评论区聊聊。觉得有用点个「在看」，转给那个总在重装工具的朋友。