Quark Lazy Cli

核心用法

quark-lazy-cli 是面向 Agent 的夸克网盘追剧维护 Skill，内置 qslazy CLI 工具。它依赖 QAS（夸克网盘自动转存项目）后端，聚焦解决"订阅失效后如何智能修复"的痛点。

主要工作流：
1. 状态检查：qslazy task list/status 查看订阅列表和缺集情况
2. 智能搜索：当 QAS 订阅失效时，自动搜索候选资源、探查多级目录
3. 决策转存：通过四种顾问模式（code/llm/agent/human）选择最优资源，按用户偏好（如更高清晰度）转存新集或补全缺失剧集

四种运行模式：

• code：代码规则自动决策，适合规范资源，零 Token 消耗
• llm：大模型后台决策，适合多版本编号冲突等复杂场景
• agent：当前 Agent 交互式判断，适合复杂订阅的临时维护
• human：用户人工确认，适合需要亲自把关的场景

显著优点

• 订阅修复能力强：即使原订阅失效，也能重新搜索资源、探查多级目录，自动匹配最新剧集
• 多维度优选：支持按清晰度、更新进度等用户偏好筛选候选资源
• Agent 原生设计：专为 Claude Code、Codex Agent、OpenClaw 等设计，支持定时任务和自动汇报
• 灵活决策机制：从全自动到人工确认，四种模式覆盖不同复杂度场景
• 权限控制严格：更新操作需用户明确授权，避免误操作

潜在缺点与局限性

• 依赖 QAS 后端：必须自建或已有 QAS 服务，无法独立运行
• Python 环境要求：CLI 工具需要 Python 运行环境，对纯前端用户不够友好
• 网盘生态锁定：专为夸克网盘设计，不兼容其他网盘平台
• 资源质量依赖：转存效果取决于网盘分享资源的发布规范程度
• Token 消耗权衡：llm/agent 模式虽智能，但会消耗额外 API 费用

适合人群

• 使用夸克网盘追剧追番的重度用户
• 已部署 QAS 服务、希望自动化维护订阅的进阶玩家
• 使用 Claude Code、OpenClaw 等 Agent 工具的开发者
• 愿意配置 Python 环境和定时任务的自托管爱好者
• 对剧集更新时效性有要求、希望减少手动检查操作的用户

常规风险

• API Token 泄露风险：需妥善保管 QAS API Token，避免写入日志或示例代码
• 误转存风险：尽管有授权机制，仍需注意 update 命令的目标确认
• 资源失效风险：网盘分享链接可能随时失效，导致转存失败
• 存储空间占用：自动转存可能快速消耗网盘容量，需定期清理
• 版权合规风险：自动转存网盘分享资源需注意当地版权法规

使用建议

建议新用户先以 code 模式熟悉基础功能，遇到资源命名混乱时切换至 llm 或 agent 模式。配置定时任务前，务必先用 task status 充分测试订阅状态识别的准确性。

核心用法

quark-lazy-cli 是一款专为 Agent 设计的夸克网盘追剧追番自动化工具，通过封装 QAS（夸克网盘自动转存项目）后端能力，实现订阅状态的智能监控与自动修复。用户可通过 qslazy CLI 工具或交由 OpenClaw、Hermes Agent 等 AI Agent 执行定时任务。

该 Skill 提供四大核心能力：一是订阅状态巡检，通过 task list 和 task status 查看订阅健康度；二是缺集自动补全，智能比对已存资源与目标剧集，识别缺失内容；三是候选资源搜索，当原订阅失效时自动探查多级目录寻找替代资源；四是智能转存决策，支持 code/llm/agent/human 四种顾问模式，按清晰度等用户偏好选择最优资源。

典型工作流为：Agent 定期运行状态检查 → 发现缺集或订阅失效 → 搜索候选资源 → 按配置模式决策 → 用户授权后执行转存 → 生成汇报反馈。进阶用户还可配置 OpenClaw 定时任务，实现完全无人值守的订阅维护。

显著优点

自动化程度高：从状态监控、资源搜索到转存执行形成完整闭环，大幅降低人工维护成本，特别适合追番数量多、更新频繁的重度用户。

决策机制灵活：四种顾问模式覆盖全场景——code 模式零 Token 消耗适合规范资源；llm 模式处理复杂编号冲突；agent 模式支持交互式决策；human 模式保留最终控制权。

安全设计规范：敏感信息（QAS API Token）通过环境变量隔离，具备完善的日志脱敏机制，网络请求均使用 TLS 加密，无数据外泄风险。

Agent 原生友好：Skill 文档结构清晰，内置完整的参考手册体系（顾问模式、环境变量、定时任务、每日汇报），Agent 可自主阅读并执行复杂维护策略。

开源透明可审计：MIT 许可证，代码完全开源，依赖均为 requests、click 等主流成熟库，无可疑行为模式。

潜在缺点与局限性

依赖 QAS 后端：该 Skill 并非独立解决方案，必须配套部署 QAS 服务才能运行，增加了前期基础设施投入成本。

配置门槛较高：需要正确配置 QAS_HOST、API Token、日志目录等多组环境变量，对非技术用户存在学习曲线。

LLM 模式有额外成本：使用 llm 顾问模式时需配置外部大模型 API，会产生额外的 Token 消耗和服务费用。

个人开发者维护：当前由 GitHub 个人账号维护（T2 来源），相比企业级项目存在长期维护持续性风险，建议用户关注更新动态或考虑 Fork 自主维护。

资源命名依赖：code 模式依赖资源发布方的命名规范，遇到命名混乱场景需降级至 llm 或 agent 模式，增加决策成本。

适合的目标群体

重度网盘追剧/追番用户：订阅数量多、更新频繁，需要自动化工具减少手动维护负担的影视爱好者。

已有 QAS 部署的技术用户：已完成 QAS 后端搭建，希望进一步提升订阅维护效率的进阶玩家。

Agent 自动化爱好者：希望通过 OpenClaw、Claude Code 等 Agent 实现定时任务、自动汇报、智能修复的自动化工作流构建者。

Python 开发者：具备 Python 运行环境，希望将工具作为命令行实用程序集成到个人工作流的工程师。

使用风险

授权机制风险：update new/all 命令会实际修改网盘内容，Skill 内置「先观察再行动」铁律，但用户仍需确保 Agent 正确理解授权边界，避免误操作。

API Token 泄露风险：QAS_API_TOKEN 具备网盘操作权限，需确保 .env 文件权限正确，避免提交至 Git 仓库或暴露于日志。

依赖服务稳定性：QAS 后端或 LLM API 服务异常会导致 Skill 功能失效，建议配置健康检查和降级策略。

资源版权合规：该 Skill 仅提供技术工具，用户需自行确保转存资源的合法合规性，遵守所在地区版权法规。

Token 消耗不可控：llm 模式下复杂资源选择可能产生较高 Token 消耗，建议设置用量监控或预算上限。