Agent 看不了推文、读不了小红书，差的不只是一个爬虫，差的是一个「选工具的人」

你让 Agent 搜一下 Twitter 上大家怎么看某个新产品。Agent 说，我没有 API key。

你让它去小红书翻翻某款护肤品的真实口碑。Agent 说，这个网站要登录，我打不开。

你让它去 B 站找个技术教程，总结一下讲了什么。Agent 说，B 站的反爬把我拦了，yt-dlp 返回 412。

这不是你的 Agent 不行。是你差了一个帮它选工具的人。

你想想看，Agent 读互联网这件事，本质上是一个「选型 + 运维」问题。每个平台都需要一个工具来读：Twitter 用 twitter-cli，Reddit 用 rdt-cli，B 站用 bili-cli，YouTube 用 yt-dlp。这些工具散落在 GitHub 上，有的活跃维护，有的已经停更，有的被平台风控封死了。你让 Agent 自己去发现、安装、调试这些工具，跟让一个实习生从零搭建公司内部系统一样不现实。

Agent Reach 做的事，就是把「选工具的人」这个角色，做成了一行命令。

15 个平台，一个路由器

Agent Reach 的定位很明确：它是一个能力层，不是又一个工具。

它比任何具体实现都高一层，负责选型、安装、体检、路由，不负责底层读取本身。读取由 Agent 直接调用上游工具完成，没有包装层。你可以把它理解成一个互联网能力的路由器，Agent 想知道什么，路由器告诉它走哪条路最快。

当前覆盖 15 个平台，6 个零配置开箱即用：网页用 Jina Reader，YouTube 字幕用 yt-dlp，RSS 用 feedparser，GitHub 公开仓库用 gh CLI，V2EX 用 API，雪球也直接调接口。其余 9 个平台需要登录态，但配置方式也简化成了一句话：「帮我配 Twitter」。

每个平台背后不是一个工具，而是一个有序的后端列表。首选 + 备选，按优先级排列。拿 Twitter 来说，channels/twitter.py 里定义的后端顺序是 ["twitter-cli", "OpenCLI", "bird CLI (legacy)"]。B 站是 ["bili-cli", "OpenCLI", "B站搜索 API"]。小红书是 ["OpenCLI", "xiaohongshu-mcp", "xhs-cli"]。

换接入方式就是调整这个列表顺序，不是重写代码。channels/base.py 里的 ordered_backends() 方法还支持用户通过配置或环境变量强制指定某个后端，排在列表最前面，其余备选兜底。如果指定的后端不存在，也不会屏蔽其他后端，只是忽略这个覆盖。

从上到下看这张图，Agent Reach 分了六层，每层都是它价值链条上的一环。最上层是 Agent 接入，Agent 读 SKILL.md 知道该调什么命令，不记路由表。然后 CLI 生命周期把 install、doctor、configure 这些操作统一成一行命令。体检引擎是核心基础设施，probe.py 的 probe_command() 真的执行 --version，而不是只看 which() 过不过。再往下是渠道路由层，每层就是一份选型结论。最下面是后端桥接和安全底座，管连接上游工具和凭据保护。

其实吧，这个设计最妙的地方不在「有备选」，而在备选切换是自动的，用户无感。

yh-dlp 曾经是 B 站的默认后端。2026 年 6 月，B 站的风控系统升级，yt-dlp 的所有请求被 412 全面封死。最新版本、直连、代理、预热 Cookie，全试过了，全挂。Agent Reach 直接把 yt-dlp 从 B 站后端列表里移除，换成了 bili-cli。用户什么都没做，Agent 继续正常读 B 站。

probe.py 的 probe_command() 函数是这一切的基石。它不只看命令存不存在，而是真的执行一遍 --version，把结果分成四种状态：ok（可用）、missing（没装）、broken（装了但跑不了，通常是因为系统 Python 升级后 venv 的 shebang 断链）、timeout/error（装了但跑不动）。shutil.which() 只能告诉你命令在不在 PATH 上，但一个断链的 venv shim 也会出现在 PATH 里，which() 返回 true，执行却直接报 FileNotFoundError。probe 的注释里明确写了这一点：「A stale venv shim passes which() but cannot execute」。

翻译成人话，一张图说清楚：先从 PATH 上找命令，找不到就是 missing。找到了就真的执行一遍 --version，如果 exec 失败（FileNotFoundError）就是 broken，通常是 venv 断链。如果进程挂了超时是 timeout，进程跑完但退出码非零是 error。只有退出码 0 才算 ok，这时才设置 active_backend，告诉 Agent 这个后端可以用。

一句「帮我配 Twitter」，背后在保护你的 Cookie

Agent Reach 的安全性设计值得单独讲。

凭据只存在 ~/.agent-reach/config.yaml，文件权限 600，只有当前用户可读写。下载安装默认只读不写，必须显式传 --system 才会修改系统。config.py 的读写逻辑里，到处是 ensure_no_symlink_path 调用——读取配置前检查路径的每一个组件是否经过符号链接，防止通过软链接把凭据重定向到攻击者控制的文件。

原子写入也是标配。_atomic_write_yaml() 先把新内容写到临时文件，fchmod 设成 600，fsync 落盘，再用 os.replace 原子替换。如果中间任何一步失败，临时文件会被清理，原始配置完好无损。

说真的，更让我印象深刻的是对 Cookie 读取的克制。

Twitter 的 twitter-cli 有一个特性：当凭据缺失或无效时，twitter status 命令会自动读取浏览器的 Cookie。Agent Reach 的 doctor 怎么处理？它不执行 twitter status。channels/twitter.py 的 _check_twitter_cli() 方法只检查显式传入的环境变量 TWITTER_AUTH_TOKEN 和 TWITTER_CT0，没有就走 warn 分支，绝不去触发上游的浏览器 Cookie 自动读取。

Reddit 的 rdt-cli 同理。_check_rdt() 方法只读 ~/.config/rdt-cli/credential.json 文件，用 read_small_text_no_follow 安全读取，检查 Cookie 是否存在、是否过期（7 天 TTL）。它也不执行 rdt status，因为 rdt status 会自动刷新 Cookie。代码注释明确写着：「Doctor 不会运行会自动读取浏览器并写文件的 rdt status」。

OpenCLI 的探测也花了心思。opencli_status() 不调用 opencli doctor，因为这个命令有副作用——会自动启动 daemon。它改用 HTTP 直接读 daemon 的 loopback 状态接口 http://127.0.0.1:19825/status，再加磁盘文件检查浏览器扩展是否安装。注释里还写了另一个细节：OpenCLI 在 0.1.35 版本注入了一个不兼容的环境变量，1.8.5 以上版本遇到这个变量会直接拒绝执行。Doctor 在探测时主动 strip 掉这个变量，保证探测不受历史版本残留影响。

拆开看，它其实是一个「选型结论集」

从源码角度看，Agent Reach 真正的价值不在代码量，在它沉淀下来的选型决策。

每个 channels/*.py 文件其实就是一份选型结论，而且带着理由。Reddit 的模块注释直接写了：「没有零配置路径，匿名 .json 接口已被封（403 anti-bot），官方 API 在 2025-11 年关闭了自助注册（改为人工审批），所以每一个能用的后端都依赖登录态」。B 站模块注释里写了 yt-dlp 被删除的具体原因和测试时间。Twitter 模块注释写了为什么首选 twitter-cli 而不是 OpenCLI：「实测搜索稳定」。

这些信息如果你自己从头去踩，至少要花几天时间。每个平台都要试两三个工具，排除掉停更的、被封的、需要付费 API 的。Agent Reach 把这些坑都踩过了，沉淀成一份活文档。

channels/base.py 里还有一个值得注意的细节：check() 方法必须设置 self.active_backend。这是 doctor 报告里「当前后端」字段的数据来源。ordered_backends() 的覆盖逻辑也写得很收敛：只把用户指定的后端提到列表最前面，如果指定的名字不存在就忽略，永远不屏蔽其他后端。这个设计防止了一个很常见的坑——用户配置了一个过时的后端名，结果所有备选都被屏蔽了。

但它的 bus factor 是 1

诚实地看，Agent Reach 有一个绕不开的问题：维护者集中度。

30 个贡献者里，Panniantong 一个人贡献了 320 次提交，第二名只有 9 次。bus factor = 1，意味着如果作者停止维护，这个项目会立刻进入无人维护状态。

作者自己在 README 里也写了：「这个项目我自己每天在用，所以我会一直维护它」。这句话透露了两个信息：第一，项目确实是他一个人在扛；第二，他靠这个项目吃饭——README 里有 4 个赞助商（BrowserAct、腾讯云、CoreClaw、优刻得），赞助位明码标价，README 底部还有业务合作联系方式。商业模式是赞助 + 接外包，项目本身开源免费。

v1.5.0 是 2026 年 6 月 11 日发的，之后两个月没有新 release。最近的 commit 集中在 8 月，主要是 README 修改和 sponsor 文案更新，没有大的功能迭代。

坦白讲，这也正常。一个 GitHub 项目冲到 76K Star 之后，维护压力会指数级增长。15 个平台，每个平台背后都依赖上游工具，上游工具随时可能被平台风控封死。B 站 yt-dlp 的例子就说明，维护一个「能力路由器」不是在维护自己的代码，是在维护 15 个平台的接入稳定性。

还有一个更隐蔽的问题：issue #566 反映，v1.5.0 实测 15 个渠道，YouTube 字幕路由已失效，doctor 对登录态平台给不出明确的后端，transcribe.sh 在 Windows 上完全不可用。issue #498 说小红书用了两天就收到封号警告。

这些都不是 Agent Reach 的代码 bug，而是它依赖的上游工具在与平台风控的对抗中落了下风。但这恰恰是「能力路由器」这个定位最脆弱的地方：你的价值在选型，一旦选型结论失效，用户感受就是「坏了」。

一份活着的选型文档

Agent Reach 给我的启发不在代码层面，在它回答了一个问题：AI Agent 时代，工具链的管理应该怎么做。

传统的做法是每个项目自己维护一份依赖清单，出问题了自己修。Agent Reach 的做法是把这份清单变成一个共享的、持续更新的服务。这个思路跟 npm 的包管理、Homebrew 的 formula 管理本质上是同一件事：把分散的运维知识集中起来，让每个人都能复用。

不过它的局限也很明显。15 个平台，bus factor = 1，依赖 10+ 个上游开源工具，每个上游都可能突然停更或被封。这个模型的可持续性，取决于作者能坚持多久，以及社区能不能分摊维护压力。

如果你的 Agent 需要读互联网，Agent Reach 是当前最快的起步方式，一行的命令就能让 Agent 装上 6 个零配置渠道。但如果你需要稳定生产环境，最好理解它背后的选型逻辑，而不是只把它当黑盒用。因为当某个平台突然读不了的时候，你至少知道去 agent-reach doctor 看一眼，是哪个后端挂了，有没有备选在兜底。