这次我们来看一个 GitHub 上已经超过 1500 Star 的开源 Agent 项目。它要解决的问题很直接B 站、小红书、YouTube、Twitter 这些平台的推荐流内容永远是平台算法说了算而不是你说了算。这个项目用 Agent 的机制把各个平台的推荐内容“换成你自己的”——你配置一份兴趣清单Agent 按这份清单判断每一条推荐值不值得看然后在页面上执行隐藏、降权、置顶或重排。整个方案是浏览器扩展配合本地 Agent 服务实现的不依赖服务器也不产生额外订阅费用。这个项目比较典型的亮点是“0 成本”和“低门槛”。项目本身开源免费推荐判断既可以接云端大模型 API可以用各家免费额度也可以接本地 Ollama 小模型硬件上不需要独立 GPU能跑 Python 和 Chrome/Edge 就能用。整体搭建流程如果按文档走熟练的话大约 10 分钟第一次会慢一些。把这个思路展开后它的技术底座其实是“浏览器自动化 LLM 决策 配置化规则引擎”所以对 Agent 应用开发者来说也是一个很好的参考案例。这篇文章会带你完整走一遍核心能力速览、Agent 工作原理和适用边界、环境准备、安装部署、功能测试、接口 API 与批量任务、资源占用、常见问题排查、最佳实践与合规建议。看完之后你既能快速判断它适不适合自己也能照着步骤把服务跑起来。1. 核心能力速览先给出一份能力速览方便你在继续阅读之前快速判断这个项目是否符合你的需求。能力项说明项目类型开源 Agent 工具浏览器扩展 本地服务主要功能将 B 站、小红书、YouTube、Twitter 等平台首页推荐流替换为用户自定义兴趣内容判断机制关键词规则 LLM 兴趣打分两部分联合决策硬件要求CPU 即可运行如果接本地 LLM则需要按模型实际大小准备显存操作系统Windows / macOS / Linux需支持 Python 和 Chrome/Edge 扩展启动方式命令行启动本地 Agent 服务再在浏览器中加载扩展接口能力本地 HTTP API可用于批量判断、二次开发和自动化任务批量任务支持对页面推荐卡片批量打分、批量重排、批量导出成本开源免费LLM 可选免费额度或本地开源模型适合人群内容消费者、资讯整理者、Agent 应用开发者、自媒体运营需要说明的是上表中的“是否支持某平台、API 路径、选择器配置”应以你 clone 下来的项目 README 和配置文件为准。不同版本可能对平台适配有增减本文会给出一套通用验证流程。2. Agent 的工作原理与使用边界这个项目从架构上分为两部分浏览器扩展和本地 Agent 服务。浏览器扩展注入到你已打开的页面里读取当前推荐流中的卡片信息例如标题、作者、标签、封面文本等。然后把这些内容批量发给本地 Agent 服务。本地 Agent 服务根据你配置的用户兴趣文件先做关键词规则过滤再做 LLM 打分判断。最终返回每张卡片的动作展示、隐藏、置顶、降权或重新排序。扩展收到结果后直接在页面 DOM 上执行对应操作于是屏幕上看到的就是“以你的兴趣为中心”的推荐流。从实现角度看这个项目有几个值得关注的技术点配置化兴趣文件用户用 JSON 维护自己的兴趣清单可以随时切换多套 profile。规则优先LLM 兜底关键词命中就直接判断没有命中的内容才交给大模型这样能明显降低 API 调用频率。批量合并请求页面上的推荐卡不是一条一条请求而是批量打包发给本地服务减少网络往返。反馈循环用户手动标“不感兴趣”后项目可以把反馈记录写入本地长期看判断会更符合个人口味。使用边界方面需要明确以下几点它处理的是本地页面已经渲染出来的内容不是全站爬虫不适合用来批量获取他人数据。它做的是“兴趣过滤 重排”不是全部拦截也不是内容抓取。平台页面改版可能导致卡片选择器失效需要同步更新配置。海外平台是否可正常访问取决于你的网络与服务区域本文不讨论任何访问方式。使用任何自动化工具都应遵守平台服务条款不绕过登录、付费墙、验证码不用于刷量、引流等违规操作。3. 环境准备与前置条件在部署之前先确认本机环境是否满足要求。由于原始项目文档中没有给出非常具体的版本号建议你在 clone 项目后先看 README 的 requirements下面给出一套通用检查清单。3.1 基础软件Python 3.10建议 3.10 到 3.12 之间的稳定版本pip 和 venv 模块可用Chrome 或 Edge 浏览器建议更新到较新版本Node.js 可选部分扩展构建流程可能用到3.2 模型与 API本地 Agent 服务本身不包含大模型它需要调用一个 LLM 来做人话判断。你可以选择云端 APIOpenAI、DeepSeek、通义、Moonshot 等按项目支持的供应商配置 API Key。大多数供应商有新手免费额度“0 成本”指的就是这类方式。本地 Ollama安装 Ollama 后拉取一个小模型例如 qwen2.5:7b 或 llama3.2:3b全部请求都在本机完成不需要 API Key但推理速度取决于 CPU 或显卡性能。如果你的电脑只有 CPU建议先走云端 API 路线资源占用最低如果你有独立显卡再尝试本地模型体验会更完整。3.3 磁盘和端口项目源码和依赖通常只需要几百 MB模型另算。本地服务默认绑定一个本地端口启动前要注意端口是否被占用。3.4 目录规划建议单独建一个目录把所有文件集中管理agent-feed-project/ ├── source/ # 项目源码 ├── profiles/ # 兴趣配置文件 ├── logs/ # 运行日志 ├── data/ # 缓存和导出结果这样的好处是以后切换模型、备份配置、清理日志都方便。4. 安装部署与启动服务这个项目不是一键双击包而是标准的命令行启动方式。整体流程分为三步拉取代码、安装依赖、启动本地服务并加载扩展。4.1 拉取项目git clone 项目仓库地址 cd 项目目录注意仓库地址以项目页面为准。如果你所在网络访问 GitHub 不稳定可以先尝试镜像站或稍后重试不要使用任何非正规工具。4.2 创建虚拟环境并安装依赖python -m venv .venv # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate pip install -r requirements.txt如果安装依赖时出现网络超时可以临时使用国内 pip 镜像pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple4.3 配置兴趣文件和模型参数项目根目录下通常有config.example.yaml或类似文件复制为config.yaml后编辑。server: host: 127.0.0.1 port: 8765 llm: provider: deepseek # openai / deepseek / ollama 等按项目支持的供应商写 api_key: ${LLM_API_KEY} model: deepseek-chat timeout: 30 interest: profile_file: ./profiles/my_interest.json max_cards_per_page: 30 cache_ttl: 600 platforms: bilibili: enabled: true selectors: card: .feed-card title: .title author: .up-name xiaohongshu: enabled: true如果使用 Ollama可以把 provider 改成ollama模型填你本地已拉取的名称例如qwen2.5:7b。api_key字段可以省略或填ollama。建议同时检查profiles/my_interest.json这是你的兴趣配置文件。先用一个简单版本测试{ prefer_keywords: [AI, 开源, Python, Agent, 效率工具, 编程教程], block_keywords: [八卦, 带货, 低质剪辑, 标题党], prefer_authors: [你关注的作者A, 你关注的作者B], block_authors: [], min_score: 0.6 }min_score表示当 LLM 无法明确判断时低于 0.6 分的内容会隐藏你可以根据自己的接受程度调整。4.4 启动本地 Agent 服务python main.py --config config.yaml看到类似Running on http://127.0.0.1:8765的日志后说明服务已经就绪。4.5 加载浏览器扩展打开 Chrome 或 Edge 的扩展管理页面开启“开发者模式”然后选择“加载已解压的扩展程序”选中项目中的扩展目录。加载成功后扩展图标会出现在浏览器工具栏。此时访问目标平台页面扩展会自动读取推荐流内容并发送到本地服务。如果页面没有立刻变化可以先手动点击扩展图标里的“刷新判断”按钮。5. 功能测试与效果验证部署完成之后不要急着看完整效果先从最简单的功能开始验证。5.1 验证规则过滤是否生效打开 B 站首页观察扩展的输出。预期结果是标题包含“AI”“Python”“开源”等关键词的卡片被保留甚至置顶。标题包含“八卦”“带货”等屏蔽词的卡片被隐藏或置灰。在 1 到 3 秒内页面完成首轮变化。判断成功的标准页面变化稳定本地服务日志能看到judge请求返回且返回中的action为hide或show。如果页面完全没有变化先检查扩展是否在目标页面启用了再检查本地服务日志是否收到请求。5.2 验证 LLM 兜底判断关键词规则只能处理明确命中的内容。对于没有命中任何关键词的卡片Agent 会把标题、作者、标签等信息发给 LLM返回一个 0 到 1 之间的兴趣分。低于min_score的卡片会被隐藏。判断成功的标准日志中出现类似LLM decision: score0.82, actionshow的记录。5.3 验证用户反馈循环在扩展面板中对一条被保留的内容点击“不感兴趣”。观察本地服务日志应能记录这条反馈。下次再遇到同一作者或相似标题时Agent 会降低权重。5.4 验证批量导出扩展面板通常提供一个“导出当前推荐”功能把当前页面的推荐卡片、判断结果、分数导出为 JSON 或 CSV。这样可以不依赖页面直接分析推荐流质量。# 示例导出结果 cat data/feed_result.json{ platform: bilibili, generated_at: 2025-01-01T12:00:00, items: [ {title: 用 Agent 写自动化脚本, score: 0.95, action: boost}, {title: 某明星私生活爆料, score: 0.08, action: hide} ] }5.5 与默认推荐流做对比在无痕窗口打开同一个平台不加载扩展对比推荐流差异。这个对比可以直观看出 Agent 对内容的干预程度。你可能会发现平台默认推荐里有大量同类内容而经过 Agent 过滤之后内容多样性更高。5.6 验证不同平台适配按同样方法在已配置的其他平台测试。因为不同平台的页面结构不同判断效率和选择器稳定性会有差异。第一次迁移到新平台时先小范围验证不要一次处理太多卡片。6. 接口 API 与批量任务如果只是手动浏览推荐流扩展面板已经够用了。但如果你想把“兴趣判断”能力接到自己的脚本、定时任务或内容管理系统里就需要直接调用本地服务暴露的 API。这里给出一套通用接口调用模板实际路由和字段以项目 README 为准。6.1 单批内容判断接口核心接口通常是一个POST请求把平台信息和候选内容列表发给本地服务返回判断结果。curl -X POST http://127.0.0.1:8765/api/v1/judge \ -H Content-Type: application/json \ -d { platform: bilibili, profile: my_interest.json, items: [ {id: 123, title: 10分钟部署本地AI助手, author: abc, tags: [AI, 教程]}, {id: 456, title: 热门八卦合集, author: def, tags: [娱乐]} ] }接口返回示例{ results: [ { id: 123, action: boost, score: 0.92, reason: 匹配 AI 编程兴趣 }, { id: 456, action: hide, score: 0.10, reason: 与兴趣清单无关 } ] }6.2 Python 批量调用示例本地服务可以处理一个items数组因此批量调用不需要并发请求直接分批发送即可。import requests import time API_URL http://127.0.0.1:8765/api/v1/judge def batch_judge(items, profilemy_interest.json, batch_size10): results [] for i in range(0, len(items), batch_size): batch items[i:i batch_size] response requests.post( API_URL, json{ platform: bilibili, profile: profile, items: batch, }, timeout60, ) response.raise_for_status() results.extend(response.json()[results]) time.sleep(0.5) # 简单限速避免触发 API 频率限制 return results if __name__ __main__: items [ {id: 1, title: Python 爬虫实战, author: A, tags: [Python]}, {id: 2, title: 某品牌直播带货, author: B, tags: [购物]}, ] result batch_judge(items) for item in result: print(item[id], item[action], item[score], item[reason])6.3 批量任务目录设计如果你想把判断能力接入自己已有的内容流建议这样组织任务data/ ├── input/ # 待判断内容例如 feed-items.json ├── output/ # 判断结果例如 sorted-items.json └── failed/ # 失败重试后仍然失败的原始数据任务流程脚本从平台页面或自己的数据源读取候选内容写入data/input/feed-items.json。调用本地 API分批判断并写入data/output/sorted-items.json。对失败项记录日志重试最多 2 次仍然失败就放进data/failed/。生成一份摘要包括总条数、隐藏条数、置顶条数和平均分数。设计时注意给每条 item 保留稳定 ID方便后续做去重和增量更新。6.4 失败重试建议对单条请求失败不要立刻重试整批而是记录失败的 item 索引最后统一重试。超时时间要根据模型响应速度调整云端 API 建议 30 到 60 秒本地模型可以适当调大。批量任务要记录上下文日志至少包含开始时间、结束时间、成功数和失败数。7. 资源占用与性能优化这个项目的资源占用分两个层面本地 Agent 服务和浏览器扩展。浏览器扩展本身很轻主要负责读取页面 DOM 和发送 HTTP 请求几乎不占 CPU内存占用几十 MB 左右。本地 Agent 服务如果在跑 FastAPI 或 Flask进程内存通常在 100 到 300 MB 区间具体以实际实现为准。LLM 的选择会明显影响资源占用使用云端 API本地不需要 GPU显存占用为 0API 调用量决定了成本。对个人用户来说每天几次页面判断产生的 token 消耗很小。使用本地 Ollama模型加载到内存或显存后才开始推理。以 7B 量化模型为例通常需要 6 到 8 GB 显存3B 小模型会低一些但理解能力也会下降。显存不足时可以尝试纯 CPU 推理只是速度会慢很多。性能优化可以从这几个方向入手规则优先关键词能判断的内容不调用 LLM这是最有效的降本手段。加缓存相同标题、作者和标签组合在cache_ttl时间内不重复调用。刷新页面时大部分结果可以直接命中缓存。限制卡片数量每页处理 15 到 30 张卡片足够太多会拖慢首屏速度。批量合并不要一条内容一次请求而是按数组发送。本地服务只监听 127.0.0.1避免局域网内其他人访问你的本地接口。8. 常见问题与排查方法这类工具最容易出问题的环节集中在扩展加载、选择器过期、API Key 配置和端口占用。下面是常见问题排查表问题现象可能原因排查方式解决方案扩展加载后页面无变化content script 未匹配目标域名打开扩展详情查看“已允许访问的站点”在扩展设置中允许目标站点本地服务启动失败端口被占用查看启动日志使用netstat -ano查端口修改 config 端口或关闭占用进程提示模型 API Key 无效Key 配错或账号欠费检查 config 中环境变量和日志报错重新配置 API Key确认剩余额度LLM 请求超时网络慢或模型响应慢调大 config 中timeout单独测试模型连通性换供应商或先用关键词规则兜底部分卡片未隐藏页面选择器已失效在开发者工具中检查卡片实际 class更新对应平台的 selectors 配置刷新页面后配置丢失profile 文件路径写错检查 config 中profile_file路径改用绝对路径确认 JSON 格式正确页面频繁闪动服务返回慢且扩展重复请求查看扩展日志观察请求间隔增加防抖、缓存和请求间隔批量任务卡住单个 item 超时或异常查看任务日志找到卡住的 item增加单条超时和失败重试机制如果你在 B 站有页面变化但小红书没有优先检查对应平台是否在配置中启用了以及选择器是否匹配当前页面结构。内容平台前端经常改版选择器过期是使用这类工具时最高频的问题。9. 最佳实践与合规建议从工程和日常使用两个角度整理几条建议。9.1 工程实践第一次只启用一个平台跑通后再扩展。不要一开始就把所有平台全开否则出问题时不好定位。把你的 profile 文件保留一份备份。兴趣配置是你最核心的数据换电脑或重装后可以直接恢复。目录里单独放一份README-local.md记录你修改过的配置项例如端口、模型供应商、profile 路径。批量任务要加日志和失败重试。即使本地服务很稳定网络抖动和平台页面改版也可能导致单条数据异常。接口服务不要暴露在公网。即使只在内网使用也建议加一个简单 token 校验避免局域网内其他设备随意调用。9.2 合规与安全本项目读取的是你自己已登录、已打开的页面内容不要拿它采集非公开数据或个人隐私信息。不要绕过任何登录、付费墙、验证码或访问频率限制。不要用扩展的隐藏、置顶功能做刷量、刷屏、营销引流等行为这违反平台条款也可能涉及不正当竞争。如果项目后续增加了对版权内容的处理能力只用于本地浏览辅助不制作、不传播未授权内容。涉及人脸、声音、品牌素材时必须确认具备合法授权后再做二次处理。工具本身是中性的但这个思路放大之后涉及隐私、版权和平台规则。使用范围限定在“优化个人浏览体验”会比较安全。10. 总结与下一步这个项目最值得尝试的点在于它把“平台推荐”这件事从被动接受变成了主动配置并且实现成本很低。浏览器扩展 本地服务 LLM 判断的架构对普通用户和开发者都有参考价值。建议你先在 B 站或小红书跑通单页测试确认规则过滤、LLM 打分、反馈循环都能正常工作再决定要不要扩展到其他平台。最容易踩的坑集中在三个地方平台页面改版导致选择器失效、API Key 配置错误、本地端口被占用。把这三个问题提前避开整个部署过程会顺畅很多。后续可以扩展的方向也很多你可以把同样一套判断逻辑接到自己的 RSS 阅读器、邮件过滤、知识库整理脚本里也可以把 profile 做成多套按工作、学习、娱乐场景切换还可以把导出的判断结果接入数据看板分析自己长期关注的内容分布。先把单页跑通后面的一切都好说。建议收藏备用。如果你已经在用这个项目欢迎在评论区交流你踩过的坑。