给 Agent 喂数据这件事，我已经重复配置了三遍

我手上有四五个跑在不同 agent 里的小工具，Claude Code、Cursor 各占一个，还有两个自己缝的脚本。它们要干的活儿其实重叠：让 agent 能读到外部世界——抓一条 YouTube 字幕、扒一段 Bilibili 简介、拿一篇网页正文。结果就是同一套接入逻辑，我在四个地方各写了一遍，Cookie 在三处各贴了一份，某个站点改了反爬策略，我得挨个回去补。

这种重复让我别扭很久了。给 agent 接外部数据，从工程角度看应该是一次性的事——像水电入户，接好了谁来都能用。它不该随人、随项目、随 agent 换个壳就重交一次。可现实里它偏偏成了每个用 agent 的人各自扛的一笔重复配置成本，扛得还心安理得，因为大家默认"接数据本来就麻烦"。

麻烦是真的，但麻烦不等于该重复。这两件事被混为一谈，是这笔成本一直降不下来的原因。

接数据为什么没能变成一次建好的地基

地基的意思是：接口稳定、上层随便换。给 agent 接数据天然具备这个条件——下游无非是几十个常见数据源，字幕、网页、社交内容，接入方式几年没大变；上游无非是各家 agent，而它们越来越统一地认 MCP 这套协议。中间这层完全可以抽出来，做成一个谁都能调的服务。

那为什么没人这么用？我观察下来是两个惯性。一是工具大多绑死在某个 agent 的插件市场里，换个 agent 就得重找；二是接数据这事被默认是"项目级"的，每开一个新项目就当新问题重做一遍，没人把它当基础设施沉淀下来。

最近一个挺火的开源 CLI 让我意识到这层地基其实可以一次建好。它把几十个数据源的接入收成一个命令行工具，对上以 MCP 暴露，任何认 MCP 的 agent 直接挂上就能用——一次接好，Claude Code 用、Cursor 用、自己写的脚本也用，不必各配一遍。它的安装方式也有意思，你不手动配环境，把下面这行丢给你的 agent：

curl -fsSL https://raw.githubusercontent.com/Panniantong/agent-reach/main/docs/install.md

agent 读着这份说明自己把依赖、路径、运行环境装好。装这件事本身也变成了地基的一部分，不再是你的体力活。

评估这类工具，先问它断了之后干什么

但"能一次接好"只解决了一半。接外部数据这种活儿，最大的特点是它一定会断——站点改版、限流、封 IP、Cookie 过期，这些不是异常，是日常。所以判断一个数据接入工具靠不靠谱，我现在第一个看的，是某条路走不通的时候它做什么。

这里有个分水岭，我吃过亏才看清。

一类工具失效时会闷声返回空数据。它内部可能只做了"静态检查"——看一眼某个命令在不在、某个 key 配没配，过了就算通，真去拉数据时拉不到也不告诉你。在本地跑没问题，一上生产环境，网络一变，它就开始安静地交白卷，而 agent 拿着空数据继续往下推理，错得无声无息，等你发现已经是好几层之后的事了。

另一类失效时会自动换路。它对每条通路做的是"真探测"——真发一次请求确认这条到底通不通，通就走，不通就降级到下一个可用方案，实在都不行才明确报错。这两种做法平时看不出区别，出事时天差地别。

前面那个 CLI 我之所以留着用，正是因为它走的是后一种。它带一条诊断命令：

agent-reach doctor

跑一遍，几十条通路挨个真探测一次，哪条通、哪条断、断在哪，一屏列清楚。这条命令本身就是态度的证明——它默认链路会坏，并把"坏在哪"当成必须告诉你的信息。

所以如果你也在挑这类给 agent 接数据、接插件的工具，我给的判断很简单：别先看它支持多少源、兼容多少 agent，先看它失效时怎么办。真探测加自动降级的，可以放进生产；只做静态检查的，本地玩玩可以，上线迟早闷声给你挖坑。支持的源再多，断了不吭声，都是负债。

地基这东西，平时感觉不到它的存在，只有断了才知道当初是怎么建的。接数据这层地基值得一次性建好，也值得在建之前先问清楚：它坏的时候，会不会喊一声。