凌晨一点我还在 B 站和小红书之间来回切换。B 站推给我的是昨天刚看过类型的视频小红书又开始推荐同类穿搭笔记YouTube 那边还在反复出现我已经看过多次的频道内容Twitter 更是顺着几条旧兴趣一路推下去。问题很清楚这些平台推荐流的优化目标不是我而是平台自己的停留时长和互动率。我不是想说“平台算法是坏的”而是想说平台算法的目标函数和你需要的目标函数根本不是同一个。你想看的是“对自己真正有用的内容”平台想让你看的是“能让你继续刷下去的内容”。这两个目标偶尔重合但更多时候不重合。所以当我看到 GitHub 上这个 1500 Star 的开源项目标题是把 B 站、小红书、YouTube、Twitter 的推荐都换成你自己的第一反应不是“又一个爬虫工具”而是“终于有人把内容筛选这件事的主动权交还给用户了”。它做的事情看起来简单但背后是一个完全不同的信息获取思路你定义规则Agent 负责执行平台推荐只是其中一个数据来源而不是你的信息边界。这篇文章我会从信息流重构的视角切入讲清楚这个 Agent 项目真正解决的痛点、它的工作逻辑、怎么在 10 分钟内跑通最小流程、哪些配置决定了运行效果以及从“跑通一次”到“长期使用”还差哪些工程能力。1. 这个 Agent 项目真正解决的不是“换算法”而是“信息源主权”1.1 平台推荐流的两个结构性缺陷先说第一个缺陷平台推荐算法本质上是在优化平台指标不是优化你的信息获取质量。无论 B 站、小红书还是 YouTube推荐系统的核心目标通常是停留时长、互动率、广告展示次数。这些指标和“内容对你有没有用”是两回事。你明明只想看三条深度教程平台会觉得你更喜欢轻松内容于是推给你 30 条轻松内容。你越往下刷离真实需求越远。第二个缺陷是信息茧房是推荐系统的副产品不是 bug而是特性。平台为了让你停留会不断强化你的既有偏好让你反复看到相似内容。时间一长你的信息源会变得非常窄窄到你以为“世界就是这样”其实只是平台认为这样能留住你。手动关注列表能不能解决能解决一部分但也不够。关注列表是静态的平台仍然可以控制排序控制哪些内容优先出现哪些内容沉底。即便你把所有优质创作者都关注了你的信息入口仍然隔着一层平台筛选。1.2 “换成你自己的推荐”到底指什么这个项目给出的方案不是去魔改平台客户端也不是去逆向平台推荐接口而是在平台和你之间加一个“内容代理层”。这个代理层做的事情分成四步从你指定的多平台来源拉取内容包括关注列表、关键词搜索、热门榜等。用 Agent 对内容做清洗、去重、分类、质量判断。根据你预先定义的兴趣规则和评分权重对内容重新打分排序。把最终结果输出成一份你自定义的推荐列表。换句话说平台推荐流现在只是一个候选池真正的排序逻辑由你控制。你可以让 Agent“优先推荐最近一周内、和 AI 编程相关、时长不超过 20 分钟的视频”也可以让它“把深度学习相关的长文排在最前面娱乐内容直接过滤掉”。这些规则过去只能靠手动搜索来实现现在变成了一个可配置、可复现的自动化流程。我理解的关键点在这里**这个项目没有让算法消失而是把“给你定算法”的权力从平台手里拿回来了。**Agent 不是替代你判断而是把你已经有的判断转化成一套可执行的规则。2. 为什么过去这件事很难自动化2.1 多平台采集的碎片化问题看到这里你可能会想这不就是写几个爬虫脚本吗确实如果只是抓取内容这件事很多年前就能做。但真正让“替换推荐流”这件事变得困难的不是单平台抓取而是多平台的碎片化。每个平台的接口、数据结构、限流策略、授权方式都不一样。B 站有开放的 API小红书对第三方访问限制比较严YouTube 有标准的 API 体系Twitter 的接口则经历了多次变更。要把这些平台的数据统一到一个工作流里意味着你要为每个平台写适配层处理不同的字段、不同的分页方式、不同的限流策略。这些工作非常琐碎而且平台接口一变脚本就废。过去很多个人脚本就是这样死的不是功能不行而是维护成本太高。你花了一个周末写的抓取脚本两周后平台改版字段变了脚本就废了。2.2 从采集到判断再到输出的闭环就算把多平台内容都抓回来了也还只是第一步。真正有价值的部分在于“判断”和“排序”。你需要的不是一个“内容仓库”而是一份“推荐列表”。从内容仓库到推荐列表中间要完成去重、分类、过滤、评分、解释这五步操作。例如同一个视频可能同时被多个平台收录你需要去重一个内容到底属于娱乐还是学习需要分类标题里有没有广告味需要过滤内容和你兴趣词的匹配程度是多少需要评分为什么推荐这条需要给出理由。这些操作在过去很难自动化因为它们本质上需要“理解”内容而不只是“匹配关键词”。旧方案往往只能做粗浅的规则过滤比如标题包含某个词就通过不包含就淘汰。这种规则太脆弱稍微换一种表达方式效果就差很多。2.3 Agent 在这里承担的角色Agent 能补上这中间最关键的一环用大模型的文本理解能力来做内容判断。以一个典型场景为例你让 Agent 筛选“AI 编程相关的优质内容”。旧脚本的匹配方式是标题里是否有“AI”或“编程”这两个词。但 Agent 可以做更细的判断它知道你关心的是用 AI 辅助写代码而不是 AI 生成的健身文案它可以在标题模糊的情况下通过描述、标签、甚至正文摘要来判断内容是否匹配。这就是为什么现在这类项目能跑通而以前跑不通。大模型理解能力的提升让“按语义过滤内容”变成了可能。Agent 的作用不是一个“万能脚本”而是把「拉取 → 理解 → 评分 → 排序 → 输出」这个流程串起来的调度器。项目标题里的 10 分钟、0 成本说的就是你已经具备了模型 API 和现成 Agent 框架之后只需要配置兴趣规则就能启动整套流程。3. 10 分钟跑通最小流程3.1 前置条件与依赖准备先泼一盆冷水如果完全没有 API Key、没有平台访问凭证、没有任何编程基础10 分钟可能不够。但如果你已经具备基本条件10 分钟跑通最小流程是很有可能的。需要准备的东西大致如下项目说明Git用于拉取项目仓库代码Python 3.10多数 Agent 项目的运行环境具体看项目文档要求大模型 API Key通常需要 OpenAI 兼容接口或 DeepSeek 等模型接口用于内容理解和评分平台访问凭证不同平台要求不同一般需要申请 Token、Key 或完成 OAuth 授权稳定网络环境不同平台的访问稳定性不同需要确保当前网络能正常访问目标平台如果只是做小规模验证可以选择只接入一两个平台比如先接 B 站和 YouTube配置一条兴趣规则跑通后再逐步扩展。3.2 最小配置示例首先拉取仓库git clone 仓库地址 cd 项目目录 pip install -r requirements.txt具体仓库地址以项目主页为准这里只是一个通用步骤。接下来创建环境变量文件。大多数这类项目都会提供一个.env.example作为模板你需要把它复制一份然后填入自己的凭证cp .env.example .env打开.env文件后常见的配置项包括MODEL_API_KEY你的大模型APIKey MODEL_API_BASEhttps://api.deepseek.com/v1 BILIBILI_COOKIE你的B站Cookie YOUTUBE_API_KEY你的YouTubeAPIKey OUTPUT_FORMATmarkdown这部分不同项目差异很大但思路是一致的模型 API 用于内容判断平台凭证用于拉取数据输出配置决定结果保存方式。3.3 运行与验证配置完成后先用最小规模验证流程是否通畅。我的建议是先不要直接跑全平台批量任务先用一条真实内容做 dry-run 测试python main.py --dry-run --limit 10如果是常见写法这个命令会把每个平台的抓取条数限制在 10 条以内只输出处理结果不生成最终报告。这一步主要是确认三件事平台凭证是否有效能不能拉到内容。模型 API 是否连通能不能完成内容理解。整个流程有没有断点。如果 dry-run 通过再正式运行python main.py --output ./result.md然后打开输出的result.md文件看看推荐结果是否符合你的预期。如果推荐的十条里有七条是相关度很高的内容说明流程基本打通。如果结果和预期偏差很大通常不是逻辑错了而是兴趣规则描述得不够具体。注意不要一上来就把平台数量和抓取条数拉满。先用一条样例确认输入、输出和日志都正常再去扩展范围。这一步能帮你省掉大量排查时间。4. 需要理解的关键配置和参数4.1 数据源配置决定能看到什么数据源配置是整个项目的地基。它决定了 Agent 从哪些平台、哪些账号、哪些关键词去拉取内容。常见的数据源配置项包括配置项作用建议平台开关启用或停用某个平台初期先启用 1-2 个平台账号/用户 ID 列表指定关注某个创作者或账号优先填你真正高频关注的账号关键词列表按关键词搜索内容使用组合词比单个词效果更好时间窗口拉取最近 24 小时还是 7 天初期用 24 小时数据量小速度快最大条数每个平台最多拉取多少条控制在 20-50 条避免请求量过大这里我最想提醒的是时间窗口。很多人第一次跑通后觉得内容太少就拼命扩大时间窗口。结果把 7 天的数据都拉下来又没设置合理的评分阈值最终得到的推荐列表被打分很低的噪音内容淹没。更合理的做法是先用一天的数据验证规则把评分和过滤逻辑调好再扩大到一周。4.2 推荐策略配置决定什么内容排在前面这是整个项目的灵魂。Agent 的能力再强如果你不告诉它“你关心什么”它也只能随机给内容打分。推荐策略配置通常包括兴趣词表你最关心的主题、实体词、产品名、方向。不要只写“编程”要写“Python、深度学习、Agent 开发、RAG”这样具体的词。过滤规则哪些内容必须排除。例如“不包含广告”“时长大于 5 分钟”“不是影视解说”。评分权重兴趣匹配和热度的占比。如果你更看重时效性可以把“发布时间”的权重调高如果你更看重内容本身可以把“兴趣匹配度”权重调高。推荐理由生成让 Agent 在输出中解释每条推荐的原因。这个功能非常有用它不只是给你看还能帮你反过来验证规则是否合理。我建议配置时多花一点时间打磨兴趣词表。这比调任何参数都重要。比如你写“AI”Agent 会把“AI 网红生成的海报”也归进来但你写“AI Agent 应用开发”过滤质量会明显提升。这里有一个值得记住的技巧用兴趣词组合而不是兴趣词堆砌。4.3 输出配置决定结果怎么保存和流转输出配置决定了整条工作流的最终产物。常见的输出方式有Markdown 报告适合人直接阅读每天生成一份推荐列表。JSON / JSONL适合程序进一步处理比如接入其他系统。SQLite 数据库适合有长期数据积累需求的用户可以查询历史推荐记录。语音播报或消息推送部分项目支持把结果推送到 IM 工具适合通勤时听。如果你只是个人使用我建议先用 Markdown然后根据使用频率决定要不要升级到 SQLite 或消息推送。如果你要长期跑定时任务一定要给输出文件加上日期标记避免每天覆盖前一天的记录。提醒一点很多项目默认会把输出写到当前目录长期运行后目录会越来越乱。建议在第一次配置时就规划好输出路径把日志、中间结果、最终报告分目录存放。5. 常见问题排查链路5.1 先看现象别急着改参数跑这类项目的时候最高频的错误不是代码逻辑问题而是环境配置和平台接口问题。我建议遇到问题先按下述链条排查而不是看到一个报错就改一个参数。没有输出先确认是否真的调用了main.py并传了正确的参数再看日志里有没有报错最后看输出目录是否为空。有输出但全部为空大概率是平台侧没拉到数据。检查 Token 或 Cookie 是否过期时间窗口是否太短关键词是否太窄。API 报错检查模型 API Key 是否有效、额度是否用完、API 地址是否填错。有些项目兼容 OpenAI 接口但地址写错会导致认证失败。平台返回 403/429403 通常是凭证无效或没有访问权限429 是请求太频繁。遇到 429降低请求频率增加 sleep 间隔或者减少抓取条数。速度异常慢一般有两种原因一是单条内容都要调用模型 API数量一大就慢二是网络环境不稳定请求超时重试。可以先把数据量调小再把超时时间调低观察是否提速。5.2 逐层排查的具体方法更细一点说我建议你按照「输入 → 环境 → 权限 → 参数 → 资源 → 日志 → 工具边界」这个顺序走一遍。输入检查配置的凭证、路径、关键词、平台开关有没有写错。常见问题是把.env.example复制成.env之后忘了改具体的 Key 值。环境检查 Python 版本是否满足要求依赖是否安装完整。有的项目只支持 Python 3.10如果你还在用 3.8很多新版语法会直接报错。权限检查平台 Token 是否有对应权限。比如一个只有只读权限的 Token可能无法拉取某些私有内容或完整历史记录。参数检查 limit、time_window、score_threshold 这类参数是否设置得太激进。比如打分阈值设成 90而实际内容最高分只有 85推荐列表自然为空。资源检查磁盘空间、内存占用。如果数据量大且输出到 SQLite长期运行会积累大量数据磁盘满了会导致写入失败。日志打开 debug 模式看具体在哪一步失败。这一步通常能快速定位问题。工具边界有些问题是项目本身的功能边界。比如某些平台不再开放公开接口或者平台调整了数据结构旧版本项目可能无法正常工作。这时候可以检查项目有没有新版本或相关 issue。5.3 两个容易误判的边界第一个是“0 成本”。这个项目本身确实是开源、免费可用的但运行过程中会消耗大模型 API 的 token。如果每天跑一次大规模抓取日积月累下来还是会消耗一点 API 费用。好在大部分模型的免费额度或低成本档位足够个人日常使用。第二个是“10 分钟”。10 分钟是指你已经完成环境准备、有可用 API Key、网络畅通的前提下从配置到跑通的最小时间。第一次接触这类项目的用户往往需要更多时间装依赖、配置凭证、处理平台的授权流程。6. 从“跑通”到“长期使用”的工程化建议6.1 先小样本验证再扩大范围跑通一次离“长期使用”还差很远。我更建议按照这个节奏来第一周只用 1 个平台、1-2 个兴趣词、每天跑一次看看输出质量。第二周加入第二个平台调整评分权重比较不同平台的推荐质量。第三周把兴趣词表扩充到 10 个以上设置过滤规则固定输出目录。第四周加入定时任务和失败重试开始积累历史数据。这个节奏看起来慢但对长期使用来说是安全的。很多人一上来就全平台、全关键词跑第二天就发现 API 配额用完了或者某个平台开始限制访问反而放弃了整个项目。6.2 真正值得补的工程能力如果想让这个流程稳定运行以下几点在长期使用中会非常关键定时调度用 cron 或系统计划任务每天固定时间运行。推荐在凌晨低峰时段跑既不影响使用也减少平台限流概率。失败重试网络抖动、API 限流、平台临时接口异常都可能导致任务失败。设置 2-3 次重试每次间隔 30 秒以上能显著提升成功率。日志记录每次运行都保存日志包括成功数、失败数、耗时、平台响应码。这样即使某天输出异常你也可以回溯到具体是哪一步出的问题。数据存储不要只输出 Markdown。建议同时把原始结果存成 JSONL方便后续分析、去重和重新排序。配置版本化把.env和兴趣规则配置写入 Git 仓库方便回滚和对比不同配置的效果。6.3 适合谁、不适合谁任何方案都有边界。这个项目也不例外。比较适合的人群有多个平台信息源想把它们聚合到统一工作流里的内容消费者。对推荐内容有明确偏好且愿意花时间打磨兴趣规则的深度用户。正在研究 Agent 工作流、想通过真实项目理解 Agent 如何连接 API 和模型的开发者。不太适合的人群完全不想处理 API Key、平台凭证、配置文件只想打开就能用的用户。这类项目离成熟产品还有距离。希望完全替代实时推荐流连刷手机的一瞬间都在用这个工具的用户。它的重点不是“刷”而是“定时获取优质内容”。对信息时效性要求极高每五分钟就要更新一轮的用户。受限于平台接口和模型调用速度这类方案更适合日更或周更。7. 这类项目真正的长期价值不在“少刷几分钟”回到开头的问题。这个项目真正值得关注的不是“把推荐流换成你自己的”这个功能本身而是它代表了一种新的信息获取方式。过去十年我们获取信息的方式很大程度上是平台定义的。平台推荐什么我们就看什么。平台没有推荐的内容哪怕质量再高也很难被我们看到。这个项目则提供了一个相反的思路平台只是内容仓库真正的推荐引擎可以由你自己控制。Agent 不代替你做判断它只是把你对“什么是好内容”的理解变成一套可配置、可复现、可调整的流程。这个模式的长期价值在于**你花在定义规则上的时间会随着时间积累产生复利。**你写的每一个兴趣词、每一条过滤规则都会让下一次推荐更精准。这和平台算法的逻辑完全不同平台算法的训练数据是所有用户的行为而你定义的是你自己的信息需求。当然我也想说清楚这不是一个可以一劳永逸的方案。平台接口会变内容生态会变你自己的兴趣也会变。你需要像维护自己的“内容花园”一样定期调整规则、更新词表、清理失效来源。但正是这种持续的调整让你始终保持对信息流的掌控感。如果这个项目给你带来的启发只有一条我希望是**下一次打开推荐流刷到不感兴趣的内容时你可以多问一句——这条内容为什么出现在我的首页是谁在决定它应该出现**而这类开源项目的存在就是在告诉你这个问题你其实可以自己接管一部分。