Agent Reach：CLI Agent 的联网能力层，不是又一层框架

CLI Agent 联网的真正瓶颈不在"怎么调 API"——这部分各平台文档都写得清楚——而在"接入方式活不长"。推特 API 要付费，Reddit 匿名接口已被封，单平台 CLI 工具说停更就停更（2026 年 3 月就集体停了一波），B 站风控说封就封。Agent Reach 的应对是把每个平台的接入方式做成一条首选加备选的有序后端链：某条路死了就调整链上顺序，用户无感。它自己只做选型、安装、体检、路由，实际读取由 Agent 直接调用上游工具完成。

前置知识：用过至少一种 CLI Agent（Claude Code、Cursor、Windsurf 等），知道 MCP 是什么。

读完这篇文章，你能判断它是否适合你的场景，并知道从哪些零配置渠道开始验证。

来源：GitHub Panniantong/Agent-Reach，MIT 协议。文中仓库数据与源码均于 2026-09-14 对源核实（v1.5.0）。

学习目标

读完这篇文章，你应该能够：

1. 判断适用性：判断 Agent Reach 是否适合你的场景（平台覆盖、桌面还是服务器、费用预算）
2. 理解架构：理解"能力层"定位与多后端路由机制（有序后端链、真实探测、active_backend）
3. 区分渠道类型：区分零配置渠道和需要登录态的渠道，知道每类的配置方式和风险
4. 完成安装验证：按"默认安全检查 → 显式授权安装 → doctor 体检"的顺序在本地跑通
5. 排查常见问题：用 agent-reach doctor --json 定位渠道状态，处理 Cookie 过期、Reddit 403、B 站风控等问题

目录

• 这套系统解决的是什么
• 项目状态
• 15 个渠道：哪些装好即用，哪些要配
• 多后端路由：架构拆解
• OpenCLI：桌面登录态的通用后端
• 一个跨平台调研任务的完整流转
• CLI 命令全景
• 快速上手
• 认证与安全设计
• MCP 模式：状态查询，不是数据面
• 和同类工具的对比
• 适用边界与采用顺序
• 常见问题
• 自测题
• 练习
• 进阶路径
• 资料口径说明

这套系统解决的是什么

CLI Agent 写代码、改文档、管项目都没问题，但让它去网上找点东西就卡住了：推特 API Basic 档 $100/月，Reddit 匿名接口已被封（官方 API 转审批制），小红书必须登录，B 站风控直接拦截通用下载工具。每个平台都有各自的门槛，让 Agent 读一条推文就要先解决认证、抓取、解析三件事。

Agent Reach 官方定位是能力层（capability layer）：比任何具体实现高一层，负责四件事——选型、安装、体检、路由。读取本身不经过它，装好之后 Agent 直接调上游工具，中间没有包装层。

LangChain、CrewAI、AutoGen 的做法是在 Agent 与外部世界之间塞入自己的抽象层，所有调用都从框架里过一遍。Agent Reach 反着来：装好、体检完就退到一边，Agent 调 twitter、yt-dlp、gh 都是上游工具的原生命令。这个取舍带来三个直接后果：调用不增加延迟；任何渠道不满意就替换对应后端；之前会用什么工具，装完继续用什么。

项目状态

这个项目的 star 曲线本身就说明问题：2026 年 6 月本文初稿时约 21,000 stars，三个月后涨到 80,000+。驱动力不是营销，而是它踩中了一个真实痛点——平台接口和第三方工具都在快速失效，“替你盯着换路由"变成了刚需。

15 个渠道：哪些装好即用，哪些要配

渠道分两类，判断依据是平台有没有反爬或登录墙。

零配置（装好即用）

官方文档对"默认激活的 6 个零配置渠道"的列举略有出入（README 列网页、GitHub、YouTube、B 站、Exa、RSS；SKILL.md 列网页、GitHub、YouTube、B 站、V2EX、Exa），上表按"装好即用"宽口径整理。具体哪个渠道在你机器上可用，以 agent-reach doctor 的实际输出为准。

需要 Cookie 或登录态

Cookie 导出流程统一：浏览器登录 → 用 Chrome 插件 Cookie-Editor 手工导出 → agent-reach configure <渠道>-cookies 保存。不需要逐个平台查文档。

选型背后的取舍

• 推特不用官方 API（Basic 档 $100/月），用 twitter-cli + 手工导出的 Cookie。twitter-cli 的 feed、tweet、user-posts 是稳定命令；search 依赖 Twitter 的 GraphQL 端点，平台一改就可能 404。代价是 Cookie 要定期重新导出。
• Reddit 只剩登录态路线。匿名 JSON 接口已被封，官方 API 转审批制。桌面走 OpenCLI 复用浏览器登录态，服务器走 rdt-cli + Cookie。
• B 站已弃用 yt-dlp。2026 年 6 月实测 yt-dlp 被 B 站风控以 412 状态封死，Agent Reach 切换到 bili-cli（无需登录可搜可读），存量用户零操作——这是多后端路由设计的第一次实战验证。
• Facebook、Instagram 只走 OpenCLI。两家平台的 Graph API/Groups API 权限持续收紧，instaloader 这类逆向路径不稳定，浏览器真实登录态是当前最实用的路径。
• 小红书三后端分层：桌面用 OpenCLI（复用已有 Chrome 会话）；服务器用 xiaohongshu-mcp（自包含无头浏览器，首次调用自动下载约 150MB）；xhs-cli 上游 2026 年 3 月起停更，只作为存量安装的兜底。

所有选型都可以换。用户可以用配置键 <渠道>_backend（或环境变量 <CHANNEL>_BACKEND）把指定后端提到链首，无效值会被忽略、不会遮蔽可用后端。这是能力层和框架的区别——框架让你适应它，能力层让你换掉它。

多后端路由：架构拆解

Agent Reach 的核心机制全部围绕一条设计展开：每个渠道是一条有序的后端候选链，backends[0] 是首选，其余是备选；切换接入方式等于调整链上顺序，不是重写代码。

agent_reach/
├── channels/
│ ├── base.py → Channel 基类（backends 有序链 + check 契约）
│ ├── web.py → Jina Reader
│ ├── twitter.py → twitter-cli ▸ OpenCLI ▸ bird CLI (legacy)
│ ├── youtube.py → yt-dlp
│ ├── github.py → gh CLI
│ ├── bilibili.py → bili-cli ▸ OpenCLI ▸ 搜索 API
│ ├── reddit.py → OpenCLI ▸ rdt-cli
│ ├── xiaohongshu.py → OpenCLI ▸ xiaohongshu-mcp ▸ xhs-cli
│ ├── linkedin.py → linkedin-mcp-server ▸ Jina Reader
│ ├── facebook.py / instagram.py → OpenCLI
│ ├── rss.py → feedparser
│ ├── exa_search.py → Exa via mcporter
│ ├── v2ex.py / xueqiu.py / xiaoyuzhou.py → 内置实现
│ ├── mcporter.py → mcporter 配置检查
│ └── __init__.py → 渠道注册表（15 个渠道实例）
├── probe.py → 真实探测（执行轻量命令，而非只看命令存在）
├── cli.py → install / doctor / configure 等命令入口
├── integrations/mcp_server.py → MCP 状态服务
└── skill/ → SKILL.md + 7 个分类参考文档

Channel 基类（channels/base.py）定义了每个渠道的三个要素：

class Channel(ABC):
 name = "twitter" # 渠道名
 backends = ["twitter-cli", "OpenCLI", "bird CLI (legacy)"] # 有序候选链，[0] 为首选
 tier = 1 # 0=零配置, 1=需免费 Key, 2=需配置
 active_backend = None # check() 写入：当前实际服务该渠道的后端

 def can_handle(self, url: str) -> bool: ...
 def check(self, config=None) -> Tuple[str, str]: ...

check() 的契约有两点容易忽视：

1. 真实探测，不是看命令存不存在。shutil.which() 通过不代表能用——一个残留的 venv shim 能通过 which 但无法执行。所以渠道要真的执行一条轻量命令再宣称某后端可用，探测逻辑在 agent_reach/probe.py。
2. Doctor 不替你执行上游平台命令。以 Twitter 为例，twitter status 在凭据缺失或失效时会自动回退读取浏览器 Cookie，这违反"只用 Cookie-Editor 手工导出"的安全策略，所以 doctor 对 twitter-cli 只检查显式凭据是否齐全，不实际调用。相应地，active_backend: null 表示"未实时验证”，不等于"后端不存在"。

实际的数据读取和搜索由 Agent 直接调用上游工具完成，Agent Reach 不参与数据传输。这带来三个后果：

1. 不增加调用延迟——Agent 调 twitter feed 直接走 twitter-cli，没有二次包装
2. 可插拔——任何渠道不满意就替换对应 channel 文件，或用 <渠道>_backend 调整顺序
3. 学习成本低——之前用什么上游工具，装完继续用什么

两次实战：路由机制为什么重要

多后端路由不是纸面设计，上线后已经验证过两次：

• 2026 年 3 月：一批单平台 CLI 集体停更（xhs-cli 的上游仓库最后一次提交停在 2026-03-21）。Agent Reach 把这些工具降级为链上备选，把 OpenCLI、xiaohongshu-mcp 提为首选，存量用户的命令不受影响。
• 2026 年 6 月：yt-dlp 被 B 站风控 412 封死。Agent Reach 把 bilibili 渠道的首选后端从 yt-dlp 切到 bili-cli，README 原话是"用户零操作"。

单平台工具的死法大体相同：平台改接口 → 工具无人修 → 用户被迫迁移。有序后端链把"迁移"这个动作变成了配置项。

OpenCLI：桌面登录态的通用后端

OpenCLI（29.2K ★）的思路是把"任何网站变成 CLI"：它通过 Chrome 扩展复用你已经打开且已登录的浏览器会话，把网站操作封装成命令行调用，例如 opencli xiaohongshu search "query" -f yaml。

它解决了单平台 CLI 的死穴：只要你在浏览器里能正常浏览，OpenCLI 的调用就带着真实的浏览器上下文（登录态、设备指纹），平台很难单独封杀。代价是它需要桌面环境的 Chrome——服务器上探测不到活的 OpenCLI，渠道会自动落到链上的下一个后端。

Agent Reach 对 OpenCLI 的使用有一条硬边界：只使用用户已有且明确控制的 Chrome 会话，不替用户登录，不读取浏览器 Cookie。没有现成会话时，走 Cookie-Editor 手工导出的路线。

一个跨平台调研任务的完整流转

用一个场景把机制串起来：让 Agent 调研某个产品在推特和小红书上的口碑。

用户输入：
"帮我调研一下 MiroFish 在推特和小红书上的口碑，给我一份对比总结"

Agent 拿到指令后的执行路径：

1. 读 SKILL.md → 知道 Twitter 走 twitter-cli，小红书是多后端渠道；
 多后端/登录态平台先体检

2. 运行 agent-reach doctor --json
 → 返回每个渠道的状态和 active_backend
 → 假设小红书的 active_backend 是 "OpenCLI"

3. 执行 twitter search "MiroFish" -n 20（凭据经
 TWITTER_AUTH_TOKEN / TWITTER_CT0 环境变量注入）
 → 若返回 404（搜索依赖的 GraphQL 端点被平台改动），
 按 SKILL.md 的重试链处理：退回稳定命令
 twitter feed -n 20 / twitter user-posts @xxx，或改走备选后端

4. 执行 opencli xiaohongshu search "MiroFish" -f yaml
 → OpenCLI 复用 Chrome 会话，返回 YAML 格式的笔记列表
 → 用搜索结果里的完整 URL 读笔记正文（小红书强制 xsec_token
 机制，不能拿裸 note_id 直接读）

5. 综合两份数据输出对比总结

第 3、4 步里 Agent 直接调上游工具，Agent Reach 不参与数据传输。它出场的时刻只有两个：开头的 doctor 体检，和出错时按渠道参考文档里的重试链定位问题。

更多工作流

读 YouTube 教程并提取要点（零配置）：

yt-dlp --write-sub --write-auto-sub --skip-download -o "/tmp/%(id)s" "URL"

B 站搜索（零配置，bili-cli 无需登录）：

bili search "AI 教程" --type video -n 5

小宇宙播客转文字（需免费 Whisper Key）：

agent-reach transcribe "https://www.xiaoyuzhoufm.com/podcast/episode/xxx"

这些命令都写在 SKILL.md 的分类参考里——描述需求即可，不需要告诉 Agent 用什么命令。

CLI 命令全景

Agent Reach v1.5.0 的命令面已经超出"装完就完"：

快速上手

安装

复制这句话给你的 AI Agent：

帮我安装 Agent Reach：https://raw.githubusercontent.com/Panniantong/agent-reach/main/docs/install.md

Agent 会自己完成：安装 CLI 工具（自带 yt-dlp、feedparser）、检查系统基建（Node.js、gh CLI、mcporter）、检测本地还是服务器环境、注册 SKILL.md。默认只激活零配置渠道；需要登录态的渠道（小红书、Twitter、Reddit、Facebook、Instagram），Agent 会列菜单问你要哪些，点名才配。

两个注意点：

• 不要从 PyPI 安装同名包，它不是本项目；从仓库地址安装
• OpenClaw 用户：默认 messaging 工具配置下 Agent 无法执行 shell 命令，安装前先开 exec 权限：

openclaw config set tools.profile "coding"
# 或在 ~/.openclaw/openclaw.json 中设置 "tools": { "profile": "coding" }
# 设置后重启 Gateway：openclaw gateway restart

默认安全，显式授权

早期版本的 --safe 是"安全模式"开关；现在默认行为就是安全的，--safe 保留为兼容参数，真正要显式传入的是 --system。

装好后的诊断

agent-reach doctor

逐个检测每个渠道：哪个通、当前走哪个后端、不通的怎么修。--json 输出供 Agent 程序化读取。典型输出：

✅ web — Jina Reader 可用
✅ youtube — yt-dlp 可用
✅ github — gh CLI 可用
✅ bilibili — bili-cli 可用（无需登录）
⚠️ twitter — twitter-cli 已安装但没有完整的显式凭据。请用 Cookie-Editor
 从 x.com 导出后运行：agent-reach configure twitter-cookies
❌ reddit — OpenCLI / rdt-cli 均不可用，需要登录态
✅ rss — feedparser 可用

更新和卸载

# 更新（也是一句话）
帮我更新 Agent Reach：https://raw.githubusercontent.com/Panniantong/agent-reach/main/docs/update.md

# 卸载
agent-reach uninstall # 清除 ~/.agent-reach/、skill 文件、mcporter 配置
agent-reach uninstall --dry-run # 只预览不删除
agent-reach uninstall --keep-config # 只删 skill 文件，保留凭据（重装时用）
pip uninstall agent-reach # 卸载 Python 包本身

认证与安全设计

Twitter 的凭据流转值得单独说清，因为它是"安全边界"的具体样子：

1. 用 Cookie-Editor 从 x.com 导出 Cookie（手工操作，工具不经手浏览器）
2. agent-reach configure twitter-cookies 保存——这份凭据只供 doctor 检查配置是否齐全
3. Agent 实际调 twitter 命令前，需要在进程环境显式设置 TWITTER_AUTH_TOKEN 和 TWITTER_CT0（Agent 会从配置注入子进程环境，不污染当前 Shell）

Cookie 安全

用 Cookie 或登录态的平台（Twitter、小红书、Reddit 等），脚本调用存在被平台检测并封号的风险。两条建议：

1. 用专用小号，不要用主账号。Cookie 等同于完整登录权限，小号可以在凭据泄露时限制影响范围
2. 控制调用频率。小红书高频请求（批量搜索、深翻评论）会触发验证码，平台限制无法绕过；每次操作间隔 2-3 秒。不要用 Agent 做批量发帖

MCP 模式：状态查询，不是数据面

Agent Reach 自带一个 MCP 服务，注意它的定位——把 doctor 报告暴露为 MCP 工具，而不是把数据读取包装成 MCP 工具：

# 启动（需要 mcp 可选依赖）
python -m agent_reach.integrations.mcp_server

{
 "mcpServers": {
 "agent-reach": {
 "command": "python",
 "args": ["-m", "agent_reach.integrations.mcp_server"]
 }
 }
}

它只暴露一个工具：

源码注释把边界写得很直白：“Agent Reach is an installer + doctor tool. For actual reading/searching, agents should call upstream tools directly."（Agent Reach 是安装器和体检工具，实际读取搜索请直接调上游工具。）所以 MCP 模式的价值是把"体检报告"接进 Claude Desktop 这类 MCP 客户端，让 Agent 在任何界面里都能先问一句"网络能力现在什么状态”，而不是替代 SKILL.md 的命令路由。

和同类工具的对比

Agent Reach 不是唯一解决"Agent 联网"问题的工具，但定位和其他方案有明显差异：

Crawl4AI、Firecrawl、Stagehand 解决的是"怎么抓一个页面"，Agent Reach 解决的是"15 个平台各自的门槛怎么过"。前者是单点工具，后者是路由层——两者可以共存：Agent Reach 负责选型和体检，抓取环节你照样可以用 Crawl4AI。

Agent Reach 的代价也要说清楚：每个渠道依赖上游工具，平台改接口时要等链上某一级修复。这是登录态方案的固有脆弱性——需要生产级稳定性时，应该考虑官方 API。

登录态方案有三层风险：

1. 平台改接口：Twitter 改 GraphQL 端点，twitter search 就可能 404。yt-dlp 社区大（190.9K ★），修复通常很快；小众工具可能要等几天，甚至永远等不来（xhs-cli 就停在了 2026 年 3 月）。
2. 凭据过期：Cookie 会过期，过期后 Agent 报错，需要重新用 Cookie-Editor 导出。
3. 反爬升级：平台检测到非浏览器流量后可能封 IP 或封号。专用小号 + 控制频率可以降低风险，但不能完全消除。

使用场景是"每天让 Agent 查几次推特、看几个视频"时，这些风险可以接受。需要 7×24 不间断运行的数据采集管线时，应该用官方 API。

适用边界与采用顺序

该用的场景

• 用 CLI Agent（Claude Code、Cursor、OpenClaw、Windsurf）做日常开发，经常需要让 Agent 联网查资料
• 想读推特/小红书/Reddit 但不想自己折腾认证和爬虫
• 需要跨平台调研（比如同时看推特和 Reddit 的讨论）
• 个人或小团队，不想为每个平台单独付 API 费用

不该用的场景

• 只在本机写代码、从不联网——直接用 gh CLI 就够
• 企业内网 Agent——Cookie 导出存在合规风险，需要走审批
• 批量发帖/刷帖——封号风险随频率上升，SKILL.md 明确把写操作排除在设计目标外
• 需要 SLA 保障的生产系统——登录态方案没有稳定性承诺，平台改接口就可能断

采用顺序建议

犹豫要不要装时，按这个顺序判断：

1. 先用零配置渠道：装好后先用网页阅读（Jina Reader）、YouTube 字幕、GitHub 搜索、B 站搜索、V2EX。这些不需要任何凭据，装完就能用，十分钟内可以验证值不值。
2. 桌面装 OpenCLI：这是当前性价比最高的登录态后端——一次安装，小红书、Reddit、Facebook、Instagram 全部解锁，不用逐个配 Cookie。
3. 再配 Twitter Cookie：需要搜推特时，用专用小号走 Cookie-Editor → configure twitter-cookies。注意 search 命令不如 feed/user-posts 稳定。
4. 服务器场景配 xiaohongshu-mcp：OpenCLI 在服务器上不可用，小红书走自包含无头浏览器方案。
5. 最后考虑 MCP 状态服务：用 Claude Desktop 等 MCP 客户端时，把 get_status 接进去，Agent 能随时自查网络能力状态。

Agent Reach 的价值不在覆盖了多少平台，而在把"接入方式会失效"这个持续存在的麻烦接管了：零配置渠道装完即验证，登录态渠道点名才配，某条路死了它调整路由，你不操心。这个试错成本比买任何 API 都低。

常见问题

Reddit 返回 403 怎么办？

Reddit 的匿名 JSON 接口已被封，没有零配置路径。桌面环境装 OpenCLI 复用浏览器登录态；服务器走 rdt-cli + Cookie（rdt login 自动从浏览器提取）。配置后让 Agent 先跑 agent-reach doctor --json 确认 active_backend。

Twitter Cookie 配好了，Agent 调命令还是报凭据缺失？

configure twitter-cookies 保存的凭据只供 doctor 检查。Agent 实际执行 twitter 命令时需要 TWITTER_AUTH_TOKEN 和 TWITTER_CT0 环境变量（Agent 会注入子进程环境）。如果你在 Agent 之外手动运行 twitter 命令，需要自己在当前 Shell 里 export 这两个变量。

B 站用 yt-dlp 下载失败（412）？

正常现象——yt-dlp 已被 B 站风控封死，Agent Reach 也已在 2026 年 6 月弃用这条路径。改用 bili-cli：搜索和视频详情无需登录，字幕通过 OpenCLI 获取。服务器上访问 B 站还需要代理（约 $1/月），本地电脑不受影响。

小红书笔记读不出来？

小红书强制 xsec_token 机制：不能拿裸 note_id 直接读，必须先 search 或 feed 拿到结果里的完整 URL，再用它读正文。三个后端都遵守这个限制。另外新装用户建议走 OpenCLI 或 xiaohongshu-mcp，xhs-cli 上游 2026 年 3 月起已停更。

装完 agent-reach doctor 显示 active_backend: null 是坏了吗？

不一定。null 表示 doctor 为避免触发浏览器 Cookie 读取或远端写入而没有做实时验证，不代表后端不存在。只有当你的任务明确需要该平台时，再按渠道参考文档里的只读命令手动验证。

自测题

1. Agent Reach 的"能力层"定位包含哪四件事？它和 LangChain 类框架的分界线在哪里？

   查看答案

   四件事：选型、安装、体检（doctor）、路由（多后端链）。分界线在调用路径：框架把所有外部调用包进自己的抽象层，Agent Reach 在装好和体检完之后完全退出数据路径，Agent 直接调上游工具的原生命令，没有包装层。

2. 多后端路由是怎么工作的？平台改接口时用户要做什么？

   查看答案

   每个渠道维护一条有序后端候选链（backends[0] 为首选），doctor 按序真实探测，第一个完整可用的当选，并写入 active_backend。用户可以用 <渠道>_backend 配置键调整顺序。平台改接口时，项目维护者调整链上顺序即可，存量用户零操作——2026 年 6 月 yt-dlp 被 B 站封死切换 bili-cli 就是实例。

3. 零配置渠道和登录态渠道的判断依据是什么？各举两个例子。

   查看答案

   判断依据是平台有没有反爬或登录墙。

   • 零配置：网页（Jina Reader）、B 站搜索（bili-cli）、GitHub（gh CLI）、V2EX、雪球、RSS
   • 登录态：Twitter（Cookie-Editor 导出）、Reddit（OpenCLI/rdt-cli）、小红书（OpenCLI/xiaohongshu-mcp）、Facebook 和 Instagram（OpenCLI）

4. agent-reach doctor 对 twitter 渠道为什么不执行 twitter status？

   查看答案

   因为上游 twitter status 在凭据缺失或失效时会自动回退读取浏览器 Cookie，这违反 Agent Reach"只用 Cookie-Editor 手工导出"的凭据策略。所以 doctor 只检查显式凭据（TWITTER_AUTH_TOKEN / TWITTER_CT0）是否齐全，不实际调用上游命令。副作用是 active_backend: null 只表示未实时验证，不代表后端不可用。

5. 什么场景该用 OpenCLI，什么场景该用 xiaohongshu-mcp？

   查看答案

   OpenCLI 需要桌面环境的 Chrome 和扩展，复用已登录的浏览器会话，适合个人电脑，且是 Facebook/Instagram 的唯一后端。xiaohongshu-mcp 自包含无头浏览器（首次调用下载约 150MB），不依赖桌面 Chrome，适合服务器场景。渠道探测会自动处理这个分工：服务器上 OpenCLI 探测不到，自动落到下一个后端。

练习

练习 1：安装并验证 Agent Reach

在你的本地环境安装 Agent Reach，然后运行 agent-reach doctor 查看渠道状态。记录哪些渠道可用、各自走的哪个后端。

帮我安装 Agent Reach：https://raw.githubusercontent.com/Panniantong/agent-reach/main/docs/install.md

练习 2：配置 Twitter 并读取时间线

用 Cookie-Editor 导出 Twitter Cookie，配置后让 Agent 读一条推文和一条时间线。

练习 3：验证多后端自动切换

如果有一台服务器（或 Docker 容器），在服务器上运行 agent-reach doctor --json，对比本地输出的 active_backend 差异。

进阶路径

1. 基础使用：先用零配置渠道（网页、YouTube、GitHub、B 站、V2EX、RSS）熟悉工作方式
2. 登录态渠道：桌面装 OpenCLI，按需配 Twitter Cookie，扩展 Agent 的覆盖面
3. 读渠道源码：channels/ 下每个文件就是一个后端链定义，重点看 base.py 的 ordered_backends() 覆盖机制和 check() 契约
4. 读 SKILL 参考：agent_reach/skill/references/ 按 search/social/career/dev/web/video/finance 七个分类给出每平台命令和重试链
5. MCP 集成：把 get_status 接入 MCP 客户端，让 Agent 具备自查能力
6. 贡献上游：Agent Reach 的命脉在上游工具（twitter-cli、OpenCLI、yt-dlp 等），发现 bug 向上游提 Issue 或 PR 比在 Agent Reach 侧绕过更有长期价值
7. 生产部署：需要 7×24 运行时，评估官方 API 方案（付费但稳定），或给登录态方案加 agent-reach watch 定时体检和告警

资料口径说明

1. 仓库数据：stars、forks、提交数、版本号于 2026-09-14 经 GitHub API 对源核实（v1.5.0，80,400+ stars，375 次提交）。上游工具的 star 数以核实日为准。
2. 渠道与后端链：15 个注册渠道及各渠道后端顺序，对源 agent_reach/channels/__init__.py 与 base.py 核实。早期版本支持过的微博、抖音、微信公众号渠道已不在当前注册表中；Facebook、Instagram 为后加入渠道。
3. MCP 工具面：当前 MCP 服务只暴露 get_status 一个工具，启动方式为 python -m agent_reach.integrations.mcp_server，对源 integrations/mcp_server.py 核实。早期版本的多工具 search 接口与社区 npm 封装已不存在。
4. 费用信息：Twitter 官方 API Basic 档 $100/月为 2023 年起公开的费率，平台此后多次调整，具体以 X 开发者文档为准。登录态方案目前免费，但平台可能随时改变策略。
5. 历史事件：2026 年 3 月单平台 CLI 停更潮、2026 年 6 月 yt-dlp 被 B 站 412 封死，均出自项目 README 的官方记录；xhs-cli 停更时间以其上游仓库最后提交（2026-03-21）为证。
6. Cookie 有效期与封号风险：文中建议（专用小号、控制频率）来自项目官方文档。Cookie 有效期受账号类型、登录频率、平台策略影响，本文不给出具体天数。
7. 适用范围：本文的适用场景和边界基于 CLI Agent 的常见用法。企业内网、高并发采集等特殊场景请结合实际需求评估。

相关项目

• OpenCLI — 浏览器登录态 CLI 桥接（多渠道首选后端）
• twitter-cli — 推特 CLI
• rdt-cli — Reddit CLI
• bili-cli — B 站 CLI（无需登录）
• xiaohongshu-mcp — 小红书 MCP（服务器场景）
• linkedin-mcp-server — LinkedIn MCP
• yt-dlp — 视频下载/字幕提取
• Jina Reader — 网页转 Markdown
• mcporter — MCP 调用桥

许可证：MIT 仓库：Panniantong/Agent-Reach