人工智能AI AgentMCP 服务AI 技能CLI【免费下载链接】Agent-Reach给你的 AI Agent 一键装上互联网能力。13 个平台网页/GitHub/YouTube/小红书/B站/Twitter/Reddit 等多后端路由当下最稳的接入方式替你选好、装好、体检好。GitHub 主仓库同步镜像。项目地址https://gitcode.com/Panniantong/Agent-Reach点击查看免费下载本文以 Agent-Reach 仓库根目录下的 CHANGELOG.md 为骨架逐版本拆解该项目从 1.0.0 首次发布到 Unreleased 阶段的演进脉络重点剖析 Boss直聘双凭据登录态误判的修复、雪球 400 错误的三级 Cookie 策略、V2EX 零配置渠道的设计以及 Instagram 渠道移除背后的反爬现实并结合 agent_reach/channels/boss.py、agent_reach/channels/xueqiu.py、agent_reach/channels/v2ex.py 等源码还原每次变更的底层实现与真实调用链。读完本文你将理解 Agent-Reach「每个平台 首选 备选有序后端列表」的能力层设计为何依赖一个严谨的 changelog也能直接复用其中的登录态判定与 Cookie 加载策略来解决自己的多平台接入问题。一、版本时间线一个能力层项目的演进骨架Agent-Reach 的更新日志遵循 Keep a Changelog 惯例按时间倒序记录「所有重要变更」当前仓库中的记录跨度如下版本时间核心事件[Unreleased]未发布Boss直聘 channel 上线 登录态误判修复1.3.12026-03-27雪球Xueqiu全面修复1.3.02026-03-12新增 V2EX 渠道渠道数 14 → 151.1.02025-02-25移除 Instagram新增 LinkedIn、Boss直聘渠道数 9 → 121.0.02025-02-24首次发布9 个渠道 CLI 统一渠道接口 doctor值得注意的是agent_reach/init.py 中的__version__已推进到1.5.0说明 CHANGELOG 顶部的 Unreleased 条目Boss channel 相关在实际开发中已经陆续合入 master——这一点在源码层面可以得到直接印证agent_reach/channels/boss.py 与 agent_reach/channels/init.py 中均已存在BossChannel的完整实现与注册条目。从时间线可以清晰读出项目的三个设计主题渠道不是一次性接入而是持续维护的资产——每个渠道都有「首选 备选」后端接入方式失效就换下一个如 B站从 yt-dlp 切换到 bili-cli登录态判定是最容易踩坑的工程问题——Boss 的双凭据存储、雪球的动态 Cookie 生成都是真实的反直觉案例零配置是渠道设计的最高优先级——V2EX 无需认证、无需代理、无需 API Key 即可使用。二、Boss直聘双凭据存储误判与四层 CDP 只读探测2.1 问题根因两个互不代表的登录态存储CHANGELOG 的 Unreleased 部分记录了 Boss直聘 channel 上线过程中最棘手的一个 Bug登录态误判。其根因是 Boss 存在两个互不代表的登录态存储本地凭据库~/.boss-agent/auth/session.enc由boss status/status --live校验浏览器 Cookie专用 Chrome profile 内的浏览器 cookieCDP 严格模式下的搜索实际携带的凭据。在 agent_reach/channels/boss.py 的文件头注释L11-L24中源码给出了完整的三条结论session.enc是硬性门槛_get_browser()无条件调用get_token()读不到就抛AuthRequired因此不能删除——CDP 搜索会在连上浏览器之前就失败但它不是搜索的认证凭据CDP 连上真 Chrome 后复用contexts[0]其 cookies 只在「没有任何 context」的分支才注入httpx 通道status/detail/cities/job_card_httpx等低危操作才真正使用它的 cookies stoken。于是出现了经典的误导场景本地有旧凭据 浏览器未登录时boss status会报logged_in: trueAgent 跳过登录直接搜索最终撞上AUTH_EXPIRED而旧 runbook 又禁止把_security_check当成未登录处理两条规则叠加把 Agent 推向「反爬滑块」的错误分支。2.2 修复方案第 4 层只读探测以浏览器为准修复的核心思路是以浏览器为准。check()新增第 4 层只读探测_cdp_zhipin_login_cookie()boss.py直接询问 CDP 浏览器本体是否存在 zhipin 域的wt2登录 cookie。从源码看这一探测的实现非常克制刻意避免引入新依赖和副作用纯标准库实现的最小 WebSocket 客户端不使用 websocket 第三方库手写握手Sec-WebSocket-KeySHA1 固定 GUID与文本帧收发boss.py支持 16 位/64 位长度帧、帧内 leftover 字节处理忽略 ping/pong只读仅调用Storage.getCookies不拉起浏览器、不执行搜索、不验证 cookie 的服务端有效性注释明确说明只证明浏览器 profile 登录过本地回环假设CDP 仅绑定127.0.0.1探测显式使用空ProxyHandler绕过系统代理boss.py避免 localhost 探测被代理拦截。check()的完整四层探测链boss.py为层 1boss-agent-cli装没装probe_command(boss, [--version])层 2CDP 调试端口 9222 通不通_cdp_json(/json/version)层 3有无可复用的 zhipin.com 页签/json页签枚举 精确 hostname 校验层 4浏览器内有无wt2登录 cookieWebSocket 问 CDP 本体。三值语义设计值得借鉴True 有 cookieFalse 没有浏览器未登录搜索必报AUTH_EXPIREDNone 探测失败登录态未知。这避免了探测失败被误判为未登录的第二类误导。2.3 Runbook 修正与状态机治理修复不止于代码还重构了 Agent 的决策规则Runbook删除「判断登录态只信boss status」的误导规则改为以 doctor 的浏览器 cookie 探测为准拉起专用 Chrome 后强制暂停让用户肉眼确认登录状态AUTH_EXPIRED定为 ground truth——直接走登录流程禁止往安全校验方向解释_security_check仅在无AUTH_EXPIRED时按滑块处理boss.py 中对安全校验页的判定也遵循此原则这是 Boss 反爬挑战与登录无关——已登录也会出现不代表未登录。2.4 上游依赖锁定从 fork 快照到固定 commitCHANGELOG 还记录了依赖治理的细节固定依赖从 fork 快照8ff6bd3切换到上游 commit4c991b7上游 PR #403-#407 已合并入 master。在 agent_reach/cli.py 中可以看到对应的常量_BOSS_AGENT_CLI_PR_COMMIT 4c991b77086a203173bf08a4cb64a23af6514fe6 _BOSS_AGENT_CLI_SOURCE ( githttps://github.com/can4hou6joeng4/boss-agent-cli.git _BOSS_AGENT_CLI_PR_COMMIT )安装器_install_boss_deps()cli.py通过pipx install --force或uv tool install --force强制安装该固定提交版本——因为 PyPI 1.18.0 暴露的boss可执行文件缺少本渠道所需的严格 CDP 公开 API。注释中明确了治理原则绝不把安装器指向移动分支moving branch上游发布包含 #403/#404/#406 的正式版后再切回版本约束。由此可以总结 Boss 渠道的完整工作流# 1. 安装锁定上游 commit 的 boss-agent-cli需显式 --system 授权 agent-reach install --system --channelsboss # 2. 启动仅监听回环地址的专用 ChromemacOS / Windows / Linux 各有对应命令 # boss.py 的 _chrome_launch_command() 会给出当前平台的命令 # 3. 用户在该 Chrome 窗口手动登录 zhipin.com # 4. 同步登录态到本地凭据库 boss --cdp-url http://localhost:9222 login --cdp # 5. 体检四层只读探测不搜索、不拉起浏览器 agent-reach doctor # 6. 搜索时强制复用现有浏览器禁止 headless 降级 boss --browser-source existing-browser --cdp-url http://localhost:9222 search ...三、雪球 1.3.1400 错误根因与三级 Cookie 加载策略3.1 根因分析acw_tc与xq_a_token的本质区别1.3.1 版本修复了雪球渠道的 400 错误。CHANGELOG 给出的根因非常精准_ensure_cookies()仅访问首页只能获取acw_tc防 DDoS token而xq_a_token由雪球前端 JS 动态生成无法通过纯 HTTP 请求获取。在 agent_reach/channels/xueqiu.py 的源码中可以看到这一策略的实现def _ensure_cookies(configNone) - None: Populate session cookies without touching browser credential stores. Priority order: 1. Saved cookie string in ~/.agent-reach/config.yaml (set by configure --from-browser) 2. Homepage visit fallback (only yields public session cookies and may not be sufficient when Xueqiu requires a logged-in session) 三级策略的完整链路是① 读取 config 文件configure --from-browser保存的xueqiu_cookie→② 自动从本地 Chrome 浏览器提取需安装 browser-cookie3→③ homepage fallback仅够公开接口使用。_load_cookies_from_config()xueqiu.py通过Config.get(xueqiu_cookie)读取并用http.cookiejar.Cookie注入.xueqiu.com域domain_initial_dotTrue、secureTrue。3.2 三处请求头修复User-Agentagent-reach/1.0被雪球反爬识别拒绝改为真实 Chrome UAxueqiu.py——这与 V2EX 渠道仍使用agent-reach/1.0UAv2ex.py形成对比说明 UA 策略需按平台反爬强度单独定制Referer所有 API 请求加上Referer: https://xueqiu.com/xueqiu.pyquote 模块修正urllib.request.quote→urllib.parse.quote明确使用正确的标准库模块。3.3 热帖端点迁移与 JSON 解析get_hot_posts()xueqiu.py放弃了已废弃的/statuses/hot/listV3.json返回空 body改用https://xueqiu.com/v4/statuses/public_timeline_by_category.json?since_id-1max_id-1count{limit}category-1新端点的数据结构更反直觉每个item.data字段是一个 JSON 字符串需要二次json.loads才能拿到真正的帖子载荷title/description/user/like_count/target并对data非字符串或解析失败做了容错。同时limit被钳制在 50 以内支持 0 与负数校验。3.4 配置链路与文档修正PLATFORM_SPECS加入 Xueqiu使configure --from-browser能检测xq_a_token存在才保存CLI 侧配置入口见 cli.py 的--from-browser--platform xueqiu校验逻辑修正文档误导README/SKILL.md 中「无需配置 / public API, no login required」的描述被纠正为需要 browser cookiecheck()失败时提示改为configure --from-browser chrome替代原先含糊的「可能需要代理」——错误信息从猜测升级为处方。雪球渠道当前支持的能力xueqiu.pyget_stock_quote股票代码支持 SH/SZ/AAPL/00700 等格式、search_stock、get_hot_posts、get_hot_stocksstock_type10人气榜、12关注榜。四、V2EX 1.3.0零配置渠道的设计样板1.3.0 新增 V2EX 渠道渠道数 14 → 15。CHANGELOG 明确其特性为Hot topics、node topics、topic detail replies、user profile全部通过公开 JSON API零配置——无认证、无代理、无 API Key。4.1 API 白名单校验agent_reach/channels/v2ex.py 中的_validate_api_url()体现了安全设计只允许 V2EX 公开 HTTPS JSON API——scheme 必须是https、hostname 必须是v2ex.com/www.v2ex.com、端口只能是 443、不允许 URL 内嵌用户名密码、路径必须以/api/开头。任何偏差直接抛ValueError。这把请求第三方 API变成了一个封闭、可审计的集合。4.2 双栈请求与 TLS EOF 兜底_get_json()v2ex.py采用Python 标准库优先 curl 兜底的双栈设计首选urllib.request发起请求响应有 1 MiB 安全上限_MAX_RESPONSE_BYTES若异常链中出现unexpected_eof_while_reading/eof occurred in violation of protocol这类可重试的 TLS EOF通过_is_unexpected_tls_eof()递归遍历__cause__/__context__判定则改用系统 curl 的 TLS 栈重试证书校验错误ssl.SSLCertVerificationError被显式排除不降级重试——这是安全边界。curl 兜底同样受限--proto https、--connect-timeout 5、--max-time 10、--max-filesize 1MiB并通过utf8_subprocess_env()保证编码一致性。4.3 数据方法清单方法端点说明get_hot_topics(limit)/api/topics/hot.json热门帖子返回 title/url/replies/node/content内容截断 200 字符get_node_topics(node_name, limit)/api/topics/show.json?node_namepage1按节点如 python/tech/jobs取最新帖get_topic(id)/api/topics/show.json?id/api/replies/show.json?topic_id帖子详情 第一页回复get_user(username)/api/members/show.json?username用户资料含 github/twitter/location/bio/avatar值得注意的是search()v2ex.py诚实地返回不可用V2EX 公开 API 不提供搜索端点方法返回明确的 error 提示并引导改用站内/?q或 Exa channel 的site:v2ex.com搜索——这是零配置渠道在能力边界上保持诚实的良好示范。五、1.1.0 的取舍Instagram 移除与 LinkedIn/Boss 新增1.1.0 是一次渠道组合的大扫除5.1 Instagram 移除——反爬的现实教育CHANGELOG 记录了移除原因Instagram 激进的反爬措施导致所有开源工具instaloader 等失效上游恢复后会重新加回。这是 Agent-Reach「接入方式会换代」理念的直接案例——渠道是活的生命体平台封了就要退役而不是硬撑。5.2 LinkedInMCP 优先 多级兜底LinkedIn 渠道采用「linkedin-scraper-mcp 读取个人 Profile、公司页面、职位详情 → MCP 搜索人才和职位Exa 兜底→ 未配置 MCP 时 fallback 到 Jina Reader」的三级路由并新增search-linkedin、search-bosszhipinCLI 子命令。5.3 同期改进agent-reach doctor从检测 9 个渠道扩展到检测全部 12 个渠道安装指南同步新增新渠道的配置说明。六、从 changelog 到架构渠道注册与 doctor 体检机制CHANGELOG 中反复出现的agent-reach doctor其架构实现是理解本项目的关键。在 agent_reach/channels/init.py 中所有渠道被注册进ALL_CHANNELS列表当前 16 个ALL_CHANNELS: List[Channel] [ GitHubChannel(), TwitterChannel(), YouTubeChannel(), RedditChannel(), FacebookChannel(), InstagramChannel(), BilibiliChannel(), XiaoHongShuChannel(), LinkedInChannel(), BossChannel(), XiaoyuzhouChannel(), V2EXChannel(), XueqiuChannel(), RSSChannel(), ExaSearchChannel(), WebChannel(), ]agent_reach/doctor.py 的check_all()体现了每个 channel 自己知道如何体检自己doctor 只是收集结果的分层思想单渠道异常不会拖垮整个报告——异常被降级为statuserror并附带「体检异常」信息所有渠道消息在输出前统一经过scrub_url_credentials()清洗防止上游探测输出回显配置的 URL 凭据format_report()doctor.py按 tier 分层渲染tier 0 装好即用、tier 1 可选已安装、tier 2 复杂配置当某渠道有多个候选后端时展示当前实际服役的后端active_backend这正是换接入方式 调整列表顺序不是重写代码的可视化呈现报告末尾还会做一次安全自检Unix 下检查~/.agent-reach/config.yaml文件权限是否为 600过宽则提示修复。七、1.0.0 首发能力层的初心首次发布确立了 Agent-Reach 的核心设计这些约定至今不变9 个渠道Web、Twitter/X、YouTube、Bilibili、GitHub、Reddit、XiaoHongShu、RSS、Exa Search统一渠道接口每个平台是一个独立、可插拔的 Python 文件channels/*.pyCLI 四件套read、search、doctor、install环境自感知自动检测本地 vs 服务器环境cli.py 的_detect_environment()综合 SSH 会话、容器标志、无显示环境、云厂商标识、systemd-detect-virt 打分内置诊断agent-reach doctor一条命令体检全部渠道Skill 注册支持 Claude Code / OpenClaw / Cursor 等 Agent 客户端cli.py 的_install_skill()会向~/.agents/skills、~/.config/opencode/skills、~/.openclaw/skills、~/.claude/skills等目录安装 SKILL.md 与 references 目录并按AGENT_REACH_LANG/LC_ALL等环境变量自动选择中英文版本。八、对使用者的启示登录态判定永远是双存储重灾区Boss 案例证明boss status报的logged_in只代表本地凭据库不代表浏览器登录态。任何涉及本地凭据 浏览器 Cookie双通道的平台体检逻辑都必须以浏览器本体为准且探测失败与未登录要区分对待。Cookie 策略要按平台反爬机制定制雪球告诉我们acw_tc与xq_a_token的获取方式完全不同——纯 HTTP 无法模拟前端 JS 动态生成的 token必须走configure --from-browser的浏览器提取链路。零配置渠道要诚实标注能力边界V2EX 没有硬撑一个假的搜索接口而是明确返回不可用并给出替代路径。依赖锁定要瞄准固定 commit而非移动分支Boss 的4c991b7锁定与 rdt-cli 的5e4fb372锁定cli.py都是同一治理哲学上游未发正式版前用固定提交保证可复现正式版发布后再切换版本约束。changelog 是架构决策的活档案本文揭示的每一次修复背后都是完整的根因分析双凭据误判、动态 token、废弃端点、UA 识别这些记录比代码注释更容易帮助后来者理解为什么这样设计。若想验证以上分析可直接在仓库中对照阅读CHANGELOG.md、agent_reach/channels/boss.py、agent_reach/channels/xueqiu.py、agent_reach/channels/v2ex.py、agent_reach/channels/init.py、agent_reach/doctor.py 与 agent_reach/cli.py以及 tests/test_boss_channel.py、tests/test_xueqiu_channel.py、tests/test_v2ex_channel.py 等测试用例。赞分享人工智能AI AgentMCP 服务AI 技能CLI【免费下载链接】Agent-Reach给你的 AI Agent 一键装上互联网能力。13 个平台网页/GitHub/YouTube/小红书/B站/Twitter/Reddit 等多后端路由当下最稳的接入方式替你选好、装好、体检好。GitHub 主仓库同步镜像。项目地址https://gitcode.com/Panniantong/Agent-Reach点击查看免费下载相关推荐Agent Reach 更新日志解析从 1.0 到 1.3.1渠道演进与雪球渠道反爬修复全记录Agent Reach 更新日志解析从 1.0 到 1.3.1渠道演进与雪球渠道反爬修复全记录 Agent Reach agent reach 的 CH人工智能AI Agent工具调用AI 技能MCP 服务网页爬虫RVC 变声器完整实战指南10 分钟语音从零训出专属 AI 音色RVC 变声器完整实战指南10 分钟语音从零训出专属 AI 音色 想让游戏角色开口说话、却又不想录一整天的音Retrieval based Voice Co人工智能AI 应用语音音频深度学习ai-memory 变更日志深度解读Agent 长期记忆系统的版本演进与工程实践ai memory 变更日志深度解读Agent 长期记忆系统的版本演进与工程实践 导读 本篇文章以 ai memory 项目官方 CHANGELOG.md h人工智能AI 应用Agent 记忆MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
