douyin-live-monitor-free 是一份抖音公开直播间监控 Skill让 Agent 通过 Easy WebBridge 按间隔读取页面保存带时间的状态记录。当前仓库主要提供操作合同不能把它当成已经实现完整轮询和通知的独立程序。“我的 100 个开源项目”这次讲直播间快照。想知道某个账号有没有开播单次打开页面就够了想复盘一段时间里的变化才需要连续记录。两者需要的证据不同。它现在实现到了哪一步截至2026年10月6日公开仓库 manifest 为1.0.1。SKILL.md 规定了选定浏览器、建立任务标签组、串行检查多个房间、记录状态以及输出 JSON、CSV 和 Markdown 报告的流程。实际 scripts 目录只有 self-test.mjs。它检查示例链接、状态枚举和时间字符串没有浏览器调用、定时器、文件导出或变化计算代码。因此“按间隔监控”是 Agent 要执行的工作流不能用一条自测命令代替线上采集。仓库也没有现成的常驻监控进程。清单标注 MIT但当前 LICENSE 是简写文本GitHub 标识为 NOASSERTION。这里如实记录许可声明与文本差异不把它写成已核验的完整标准 MIT 文件。开始前输入要明确什么输入至少包括一个或多个直播间链接也可以给账号主页。想连续检查时还要写清间隔、持续时间和输出目录。多浏览器环境要指定已授权的目标不能让 Agent 随便选一个在线账号。可以给 Agent 这样的任务使用 douyin-live-monitor-free检查我指定的公开直播间。每隔5分钟读取一次持续30分钟同一浏览器串行检查。保留每次采集时间、房间链接、页面显示的状态和字段原文。输出 live-snapshots.json、live-snapshots.csv 和 live-summary.md。遇到登录、验证码或安全验证时停止该房间。5分钟和30分钟只是这个任务示例不是项目默认值也不是平台允许的固定频率。实际安排还要考虑页面加载耗时和多房间串行检查一轮采集并不意味着所有房间在同一秒被读取。一条快照应该保留什么合同要求 room_url、creator_name、status、title、visible_metrics 和 collected_at。它们分别回答“读的是哪个房间、谁的页面、看到什么、什么时候看到”。报告还应写清检查间隔与最后一次成功读取时间。一个建议的记录形式如下。这是结构演示没有访问真实直播间{room_url:https://live.douyin.com/example,creator_name:null,status:unavailable,title:null,visible_metrics:{},collected_at:2026-10-06T09:00:0008:00}把读不到的字段留空比填一个估计在线人数更容易复核。页面展示“热度”和“在线人数”时也要保留原标签不能因为都是数字就互相替换。开播、下播和页面不可用怎样区分工作流使用 started、still_live、ended 和 unavailable 记录变化。started 和 ended 需要前后成功读取的状态作依据页面没加载出来只能说明这次不可用不能直接断言主播下播。如果只取得一条正在直播的记录能确定的是采集时页面显示在播。若前一次读取失败就没有证据推算准确开播时间。两次检查之间也可能发生短暂开播或下播快照不会自动补齐间隙。建议在报告里保留采集失败、延迟和空档而不是把时间线画成连续事实。有现成的通知与数据导出命令吗当前合同列出了三种输出文件提醒只写入本地结果不自动发消息。源码尚无完成这些操作的专用 CLI。需要 Agent 整理并保存报告不能宣称项目已经接好邮件、企业微信或手机推送。可以运行仓库自测gitclone https://github.com/xxjrq/douyin-live-monitor-free.gitcddouyin-live-monitor-freenodescripts/self-test.mjs本次按固定提交核验源码并运行上述离线自测通过。它没有连接真实直播间没有验证真实页面字段提取和轮询稳定性也没有生成真实直播数据。第一次使用可以先选一个已授权的公开房间做少量读取核对输出字段与失败记录。看清每条快照的来源和时间边界后再决定是否增加房间。这是使用建议不是本次执行经历。项目入口GitHub。浏览器前提Easy WebBridge。本文只做源码与离线自测核验。