Agent Reach
为 agent 选择、配置和诊断互联网工具；当前 main 默认 install 只检查，doctor 也更谨慎地区分“配置存在”和“平台可用”。
状态:
active· 总分: 3.5/5 · 推荐度: 3/5
一句话总结
Agent Reach 适合个人研究环境补齐网页、社媒、视频与 GitHub/RSS 工具入口；不要把安装/doctor 的成功等同所有平台真实可用，更不要默认授予账号和系统修改权限 [Docs:install][GH:diff]。
总体评价
它仍是 selector/installer/health-checker/router，而不是每个平台的完整实现。核心价值在管理上游工具和配置的复杂性，不在承诺平台限制永远消失 [GH:main]。
本轮最重要的反例是：latest release 仍为 v1.5.0，不代表没有实质变化。 当前 main 的 install 默认从自动安装改成只检查，系统改动要求 --system；doctor 不再把存在配置或浏览器桥接直接宣称为实际平台可用 [GH:releases][Docs:install][GH:diff]。这些会改变授权与验收方式，不能以版本号不动判 no_change。
推荐度：3/5
目标角色：愿意管理上游工具、低价值账号、浏览器会话与平台波动的个人 agent 用户。建议先在隔离环境检查依赖，明确批准具体系统修改，再对真正要用的渠道做小规模实测。
保留 3/5：默认安全化值得肯定，但本轮没有运行 doctor 或真实渠道，不因文档承诺减少就宣称运行已可靠。main 与六月 release 的代码也应分别锁定，不能仅凭 version=1.5.0 判断安装到的是哪一套行为 [GH:main]。
优势
- 把工具选择、安装、状态检查和路由集中管理，减少逐个平台重复配置 [GH:main]。
- 默认检查与显式
--system将系统改动变成可见授权点 [Docs:install]。 - doctor 逐步区分可执行、配置存在、桥接连接与实际渠道验证，减少误报全绿 [GH:diff]。
- 安装/更新文档对账号、Cookie 和上游共存有具体约束 [Docs:install][Docs:update]。
劣势
- 平台可用性仍依赖 CLI、登录态、代理、反爬与外部服务。
- 一个包的版本号不能完整表达 main 配置/安全行为的变化 [GH:main][GH:releases]。
- README 的“一键全网/完全免费”叙事比真实渠道验收条件更宽 [GH:main]。
- Cookie、MCP 配置、下载与转写程序仍有高权限及供应链风险。
适合什么场景
- 隔离个人研究环境的 web/social/video 工具配置和诊断。
- 需要跨多个渠道，但能接受逐项配置和失败报告的信息工作流。
- 学习只读 doctor、显式系统授权和真实状态分层设计。
不适合什么场景
- 生产主账号、支付或管理后台的无人值守自动化。
- 要求稳定数据 SLA 或把第三方平台条款视为自动获得授权。
- 不愿维护 Cookie、代理、浏览器扩展与上游版本的用户。
与类似项目对比
| 项目 | 定位 | 相对本项目 |
|---|---|---|
| crawl4ai | Python 网页抓取/LLM 输出 | 提供抓取引擎；Agent Reach 更偏选择和管理多个上游工具。 |
| Crawlee | JS/TS crawler framework | 管理 crawler 生命周期与数据；Agent Reach 管理跨平台能力入口。 |
仅比较中心对象，不以本轮不同证据深度判断谁“更可靠” [WikiLocal:comparison]。
它能做什么
能力 4/5。文档覆盖网页、YouTube、RSS、GitHub、搜索及多个社媒渠道的工具入口；实际操作主要由上游 CLI/MCP 完成 [GH:main]。
当前 main 安装模式应读作：
agent-reach install --env=auto：只读检查。--system：显式批准外部/系统安装与配置写入后使用。--safe：兼容旧安全参数，保持检查模式。--dry-run：预览系统模式将做什么 [Docs:install]。
doctor 的 warn/未验证是正常诚实状态，不应强行改成 ok。仅连接 OpenCLI bridge 不证明某个平台登录态和命令已验证 [GH:diff]。
运行环境与资源占用
| 项目 | 判断 |
|---|---|
| 运行时 | Python>=3.10；manifest 仍为1.5.0/Beta |
| 主要依赖 | requests/feedparser/PyYAML/rich/yt-dlp，额外 browser/MCP/cookie 功能按需 |
| CPU/内存 | 上游浏览器、视频/转写与网络任务主导 |
| 存储 | 包、工具、配置、Cookie 和媒体/cache |
| Docker/GPU | 未验证本项目官方用户向 Docker image；基础配置/诊断不要求 GPU |
资源效率 3/5：本体不重，但它管理的能力层无法用单个 CLI 内存概括；当前 yt-dlp 依赖带 default extra，安装足迹也随上游变化 [GH:main]。
上手体验
4/5。安装/更新文档面向 agent，有模式、配置和人工步骤说明；默认只检查降低初次误改系统的风险 [Docs:install]。但安全默认不是“一键已装全”，Cookie、浏览器扩展及真实渠道操作仍需用户参与。
代码质量
4/5。channels/backends/probe 与配置安全 helper 分层可见；compare diff 包括 Windows CI、严格域名匹配、私有文件原子写入及只读诊断改造 [GH:diff]。旧 196 tests 通过只保留为历史，当前这些改造未在本轮运行 [Local:historical-test]，不据此宣称无副作用或无漏洞。
可扩展性
4/5。channel/backends 与指导文档能替换失效上游，但新增平台真正困难往往在账号、Cookie、反爬和真实状态检查，而非多写一个 adapter [GH:main][GH:diff]。
文档质量
4/5。install/update 对默认检查、--system、Cookie 范围与人工操作较具体 [Docs:install][Docs:update]。不足是 README 的强可用性营销与 doctor 的保守状态之间仍有张力，采用时以具体文档、代码和真实命令结果为准。
社区与成熟度
社区 4/5，成熟度 2/5。2026-02 创建，快照 79041 stars、6803 forks、76 issues、54 PRs；本轮比较显示 release 不动而 main 有大量行为变更 [GH:api][GH:diff]。持续维护是正面信号，但账号/平台依赖和变化的授权语义仍不足以支持长期稳定承诺。
安全与风险
安全 3/5。本轮没在项目 GHSA endpoint 查到公开公告，不代表工具、依赖或所调用平台安全 [GH:advisories]。
现文档要求 Twitter 采用用户明确导出的 Cookie；部分可浏览器导入的平台需要指定范围，小红书只使用已有且用户控制的会话或手动 Cookie 配置，不替用户自动登录 [Docs:install]。这些是项目边界说明，本轮未动态验证所有代码路径。
秘密应通过受控输入配置，不粘贴到普通聊天/日志；--system 也不等于无限 sudo 授权。不要把上游工具收录当成对它的供应链担保，亦不要把“已配置”写成“在线可用” [GH:diff]。
学习价值
最值得学的是能力诊断的证据层级：文件存在、可执行、配置存在、bridge 已连、平台请求成功，是不同状态。把它们分开并减少诊断副作用，比增加一个平台 logo 更能提升 agent 工具治理质量 [GH:diff]。