Agent Reach：把互联网接入变成 Agent 的能力层

给 Agent 接入互联网，最先要做的不是安装更多渠道，而是建立一套可诊断的运维流程。Agent Reach 的 v1.5.0 把重点放在多后端路由、真实探测和 OpenCLI 桌面后端上，适合拿来研究“外部工具失效后，Agent 如何继续工作”。

先定义成功，不要只看命令在不在 PATH

一个 CLI 文件存在，不代表它能读到内容：Python 升级可能断掉虚拟环境，Cookie 可能过期，浏览器扩展可能未安装，匿名接口可能已经被平台封锁。Agent Reach 的 doctor 会实际运行检查，并通过 `active_backend` 告诉你当前渠道走哪一条路径；`doctor --json` 则便于接入监控或发布前检查。

一套建议的安装验收

第一步用默认模式做只读检查，确认 Python、Node、gh、mcporter 等基础设施；第二步只启用三个高频、低授权渠道；第三步跑真实的读网页、读 YouTube 字幕和读公开 GitHub 仓库；第四步记录失败处方和重装命令。只有这套最小链路稳定，才值得加需要登录态的渠道。

agent-reach install --env=auto --dry-run
agent-reach install --env=auto
agent-reach doctor --json

服务器和桌面不是同一环境

OpenCLI 复用桌面 Chrome 登录态，服务器上通常不存在这个前提；服务器更适合无登录网页、RSS、GitHub 公共内容和明确配置的后端。README 也把代理放在服务器部署场景，而不是本地电脑的默认要求。部署前必须把“本机可用”与“远程可用”分别验收。

故障处理应该围绕路由表

平台换接口时，不要先改 Agent 的业务提示词。先看 doctor 的 active backend、依赖版本、认证状态和最近一次端到端读取，再决定是调整候选顺序、更新上游工具还是撤掉失修渠道。v1.5.0 的发布说明把这类变化直接写成路由调整，说明能力层的维护对象是接入路径，而不是模型本身。

运维中必须保留的记录

每次升级保留版本号、渠道状态、后端选择、执行环境和一组固定样例。对关键研究流程，保存原始 URL、抓取时间与失败日志，但不要把 Cookie 或 Token 写进聊天、CI 日志或共享工单。若无法解释某次结果来自哪条后端，就不能把它当成可复现的研究证据。

适用边界

Agent Reach 可以降低工具维护成本，却不能消除平台风控、认证审批和上游停更。把它作为可观测的接入层，而不是全自动抓取承诺，才是更可靠的部署方式。