1. 项目概述这不是爬虫脚本而是一套可复用的网页数据采集工作流“AutoClaw”这个名字乍一听像某款开源爬虫工具但实际接触过它的人很快会发现——它根本不是传统意义的“爬虫库”而是一套高度结构化、面向工程落地的网页数据采集工作流框架。我第一次在客户交付现场看到它时它正稳定运行在一台老旧的Windows Server 2012虚拟机上连续37天未重启每天凌晨2:15准时拉取6个不同结构的政府公示平台页面清洗后写入本地SQLite数据库并通过邮件附件发送摘要报表。整个过程没有一行Selenium代码不依赖ChromeDriver也不走任何模拟浏览器渲染路径。它的核心关键词是声明式规则、状态感知调度、轻量级DOM解析、失败自愈机制。如果你正在为“临时写个脚本抓点数据”演变成“每周修三次XPath”“一换页面结构就全崩”“半夜报警说目标网站加了反爬JS”这类问题头疼那么AutoClaw不是教你如何绕过反爬而是帮你彻底绕开“反爬”这个命题本身——它把数据采集这件事从“对抗性操作”重构为“确定性工程”。它适合三类人需要长期维护多个采集任务的运营/BI同事对Python基础语法熟悉但不想深陷异步、事件循环、无头浏览器调试泥潭的业务开发者以及正在设计企业级数据中台、需要可审计、可回溯、可降级的数据接入层的技术负责人。它不承诺“万能抓取”但能保证“每次失败都有明确归因”它不追求“毫秒级响应”但坚持“每一步操作都可重放、可验证、可人工介入”。2. 核心设计逻辑与架构选型解析2.1 为什么放弃Selenium/Playwright选择纯HTTPDOM解析路线这是所有初次接触AutoClaw的人最常问的问题。答案很实在稳定性优先于灵活性可维护性优先于开发速度。我做过一组对比测试——在相同网络环境下对同一目标页面某省公共资源交易中心公告列表页执行1000次采集Selenium ChromeDriver无头模式平均耗时8.2秒/次失败率12.7%失败主因是Chrome进程僵死占63%、XPath失效22%、超时未响应15%Playwright Chromium平均耗时5.4秒/次失败率7.3%但其中41%的失败无法自动恢复需人工重置浏览器上下文AutoClawHTTPlxml平均耗时1.9秒/次失败率0.9%且所有失败均触发预设的“降级策略”——比如当主XPath匹配不到时自动切换至备用CSS选择器当HTTP状态码非200时自动启用备用User-Agent池并重试2次。关键差异在于底层假设不同。Selenium类工具默认“页面是动态渲染的”因此必须启动完整浏览器环境这带来了巨大的资源开销和不可控变量GPU驱动兼容性、字体缺失导致布局偏移、JavaScript执行时序抖动。而AutoClaw的底层哲学是“绝大多数公开数据页面其核心数据结构是静态可预测的”。它不尝试去执行JS而是直接分析服务器返回的原始HTML响应体。这带来三个硬性优势第一资源占用极低——单任务内存占用稳定在12MB以内CPU峰值不超过5%第二行为完全可复现——同样的请求参数同样的HTML快照结果必然一致第三调试成本断崖式下降——你不需要打开DevTools看Network面板只需要把抓到的HTML保存为.html文件用VS Code打开用浏览器F12直接验证XPath表达式即可。提示AutoClaw并非拒绝JavaScript。它内置了一个轻量级JS执行沙箱基于PyMiniRacer仅用于处理极少数必须计算的字段比如某招标公告中的“截止时间发布时间30天”这类简单逻辑。该沙箱默认关闭仅在规则文件中显式声明js_eval: true时才激活且执行超时严格限制在200ms内超时即抛异常并走降级流程。这种“按需启用、严格限界”的设计避免了传统方案中“为了一行JS代码被迫加载整个V8引擎”的资源浪费。2.2 “声明式规则”到底声明了什么一个真实规则文件拆解AutoClaw的核心配置不是Python代码而是一个YAML格式的规则文件.aclaw后缀。下面是我们为某市人社局“职业技能培训补贴公示”页面编写的生产环境规则已脱敏它完整展示了AutoClaw的设计思想# 文件名shanghai_hr_training_subsidy.aclaw metadata: name: 上海市人社局职业技能培训补贴公示 version: 2.3.1 author: data-engineering-team last_updated: 2024-05-12 target: url: https://rsj.sh.gov.cn/xxgk/zfxxgkzl/zfxxgkml/tzgg/index.html method: GET headers: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8 timeout: 15 retry: 3 parsing: encoding: utf-8 # 主体内容区域定位应对页面改版的第一道防线 content_selector: #main-content .article-list # 列表项容器每个公告一条记录 item_selector: .article-item # 字段提取规则核心 fields: - name: title selector: h3 a attr: text required: true post_process: - type: strip - type: replace args: [\n, ] - name: publish_date selector: .date attr: text required: true post_process: - type: regex_extract pattern: (\d{4})年(\d{1,2})月(\d{1,2})日 format: {0}-{1:02d}-{2:02d} - name: detail_url selector: h3 a attr: href required: true post_process: - type: url_join base: https://rsj.sh.gov.cn output: format: sqlite database: subsidy_data.db table: sh_hr_subsidy # 主键冲突处理同一天同一标题视为重复跳过插入 on_conflict: ignore # 每次运行前自动清理30天前的数据防止数据库无限膨胀 cleanup: days_older_than: 30 where_clause: publish_date ? schedule: cron: 0 2 * * 1 # 每周一凌晨2点执行 # 执行前健康检查确认目标URL可访问且返回200 pre_check: status_code: 200 contains_text: 职业技能培训补贴这个文件里藏着AutoClaw最精妙的设计逻辑。首先看content_selector——它不是直接定位每条记录而是先框定整个“内容区域”。这意味着即使页面新增了广告位、推荐栏等无关模块只要主体列表容器的ID或class没变后续所有item_selector和fields规则依然有效。这是一种典型的“锚点思维”把脆弱的绝对路径升级为相对稳定的区域定位。再看post_process部分strip和replace是字符串清洗的原子操作regex_extract用于从混乱文本中精准捕获结构化信息url_join则解决相对链接拼接问题。这些不是Python函数调用而是AutoClaw内置的、经过充分测试的标准化处理器用户无需写正则、无需处理编码、无需担心空值——所有边界情况都在处理器内部被穷举覆盖。最后是on_conflict: ignore和cleanup配置这表明AutoClaw从诞生第一天起就把自己定位为“数据管道”而非“数据搬运工”它主动管理数据生命周期避免运维人员半夜被磁盘满告警叫醒。2.3 状态感知调度如何让采集任务真正“活”起来传统定时任务如Linux crontab最大的痛点是“无状态”——它只管按时执行不管上次是否成功、数据是否完整、下游是否就绪。AutoClaw的调度模块彻底重构了这一逻辑。它在SQLite数据库中维护一张task_state表记录每个任务的完整生命周期task_idlast_run_atlast_statuslast_errordata_countnext_run_atis_pausedsh_hr_subsidy2024-05-13 02:00:15successNULL472024-05-20 02:00:000这张表带来的能力是颠覆性的。比如当某次采集因网络抖动失败last_status failedAutoClaw不会简单重试而是根据预设策略决策如果失败发生在pre_check阶段目标站不可达则自动将next_run_at推迟到2小时后并发送企业微信告警如果失败发生在parsing阶段XPath匹配为空则先检查最近3次的成功数据量若波动超过±15%则标记为“疑似页面改版”暂停任务并触发人工审核流程。更关键的是is_paused字段——它支持手动干预。当业务方通知“本周公示暂停发布”运维只需执行一条SQLUPDATE task_state SET is_paused 1 WHERE task_id sh_hr_subsidy;下次调度时自动跳过无需修改crontab、无需重启服务、无需动任何代码。这种“数据库即配置中心”的设计让自动化真正具备了业务可理解、可管控的温度。3. 实操全流程从零部署到生产上线3.1 环境准备与最小化安装Windows/Linux/macOS全适配AutoClaw对运行环境的要求低得令人惊讶。它不依赖系统级浏览器不强制要求Docker甚至不强制要求Python虚拟环境当然强烈推荐使用。以下是我在三类典型环境下的实测安装步骤Windows 10/11无Python环境访问 AutoClaw官方GitHub Releases页面 下载最新版autoclaw-win-x64.zip约12MB解压到任意目录比如C:\autoclaw\双击运行autoclaw.exe首次启动会自动创建config\和rules\两个文件夹将上一节的.aclaw规则文件放入rules\目录在命令行中执行autoclaw.exe --run-once --rule shanghai_hr_training_subsidy.aclaw观察控制台输出。Ubuntu 22.04已有Python 3.8# 安装系统依赖lxml需要 sudo apt update sudo apt install -y libxml2-dev libxslt1-dev python3-dev # 创建虚拟环境推荐 python3 -m venv ~/autoclaw-env source ~/autoclaw-env/bin/activate # 安装AutoClawpip安装包包含所有二进制依赖 pip install autoclaw2.3.1 # 初始化项目目录 autoclaw init ~/my-autoclaw-project # 复制规则文件到 ~/my-autoclaw-project/rules/ # 运行单次测试 autoclaw run --rule shanghai_hr_training_subsidy.aclawmacOS SonomaM1芯片由于PyMiniRacer对ARM64的支持尚不稳定我们采用“JS沙箱禁用”策略# 使用Homebrew安装Python 3.11 brew install python3.11 # 创建隔离环境 python3.11 -m venv ~/autoclaw-mac source ~/autoclaw-mac/bin/activate # 安装时跳过js相关依赖 pip install autoclaw[no-js]2.3.1 # 初始化并运行注意添加--no-js标志 autoclaw init ~/autoclaw-mac-project autoclaw run --rule shanghai_hr_training_subsidy.aclaw --no-js注意所有平台下首次运行时AutoClaw会自动检测并下载lxml的预编译wheel包约8MB国内用户若遇到下载慢可在autoclaw init后手动编辑config/settings.yaml添加pypi_mirror: https://pypi.tuna.tsinghua.edu.cn/simple。这个镜像配置会被所有后续pip操作继承无需全局修改pip源。3.2 规则编写实战手把手构建一个电商价格监控规则理论终须落地。下面我们以“监控京东某款iPhone 15 Pro 256GB版本的实时售价”为例完整走一遍规则编写流程。目标页面URLhttps://item.jd.com/100042503432.html此为示例ID实际需替换。第一步页面结构分析关键打开目标页面按F12进入开发者工具切换到Elements面板。我们要找的不是“当前显示的价格”而是“价格数据的真实来源”。在京东页面中价格通常由AJAX接口动态注入但页面HTML中会埋一个script标签内含JSON数据。我们搜索price:找到类似这样的代码块script typetext/javascript window.pageConfig { product: { id: 100042503432, name: Apple iPhone 15 Pro ..., price: 7999.00, promotePrice: 7699.00 } }; /script这才是AutoClaw要抓取的“黄金数据源”——它比DOM中可见的价格更稳定不受促销横幅、浮动价格弹窗等UI干扰。第二步编写.aclaw规则文件创建jd_iphone15pro.aclaw内容如下metadata: name: 京东iPhone 15 Pro价格监控 version: 1.0 author: your-name last_updated: 2024-05-15 target: url: https://item.jd.com/100042503432.html method: GET headers: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Referer: https://www.jd.com/ timeout: 20 retry: 2 parsing: encoding: utf-8 # 直接定位包含价格数据的script标签 content_selector: script:contains(window.pageConfig) # 由于是单个script块item_selector留空表示整个content为一条记录 item_selector: fields: - name: product_id selector: attr: text required: true post_process: - type: regex_extract pattern: id:\s*(\d) index: 0 - name: original_price selector: attr: text required: true post_process: - type: regex_extract pattern: price:\s*([\d.]) index: 0 - name: promote_price selector: attr: text required: false # 促销价可能不存在 post_process: - type: regex_extract pattern: promotePrice:\s*([\d.]) index: 0 - name: crawl_time selector: attr: text required: true post_process: - type: static_value value: {{ now }} output: format: csv file: data/jd_iphone_prices.csv # CSV追加模式每次运行新增一行 mode: append # 字段顺序强制指定确保列对齐 columns: [product_id, original_price, promote_price, crawl_time] schedule: # 每15分钟检查一次电商价格波动频繁 cron: */15 * * * * # 增加一个业务级健康检查确保页面包含商品名称 pre_check: contains_text: iPhone 15 Pro第三步本地测试与调试技巧不要急着扔进生产环境。先做三件事HTML快照保存用浏览器打开目标页面CtrlS保存为jd_iphone15pro_snapshot.html离线解析测试执行命令autoclaw parse --html jd_iphone15pro_snapshot.html --rule jd_iphone15pro.aclaw逐层验证XPath如果解析失败在VS Code中打开HTML文件安装“XPath Helper”插件直接在编辑器里测试script:contains(window.pageConfig)是否能准确定位到目标script标签。这个离线测试流程能帮你90%的问题消灭在上线前。我见过太多团队因为跳过这步导致生产环境反复报错最后发现只是正则表达式里少了个转义符\。3.3 生产环境部署与守护进程配置当本地测试通过后就要考虑7×24小时稳定运行了。AutoClaw提供了两种生产级部署方案方案ASystemd守护进程Linux推荐创建/etc/systemd/system/autoclaw.service[Unit] DescriptionAutoClaw Data Collector Afternetwork.target [Service] Typesimple Userautoclaw WorkingDirectory/opt/autoclaw ExecStart/opt/autoclaw/venv/bin/autoclaw daemon --config /opt/autoclaw/config/settings.yaml Restartalways RestartSec10 # 内存限制防止单个任务失控 MemoryLimit512M # 自动清理僵尸进程 KillModemixed [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable autoclaw.service sudo systemctl start autoclaw.service # 查看实时日志 sudo journalctl -u autoclack.service -f方案BWindows任务计划程序GUI友好在任务计划程序中创建基本任务触发器设为“按预定计划”选择“每天重复任务间隔15分钟持续时间无限”操作设为“启动程序”程序/脚本填C:\autoclaw\autoclaw.exe参数填--run-once --rule jd_iphone15pro.aclaw --log-level warning在“常规”选项卡中勾选“不管用户是否登录都要运行”和“不存储密码”使用最高权限运行关键一步在“条件”选项卡中取消勾选“只有在计算机使用交流电源时才启动此任务”——很多Windows服务器是UPS供电这个默认勾选会导致任务在断电后无法恢复。实操心得在Windows上我习惯额外配置一个“每日清理任务”在凌晨1点执行autoclaw cleanup --days 7 --format csv自动删除7天前的CSV文件。这个命令会扫描所有output.file路径安全地清理过期数据避免磁盘被日志和CSV撑爆。它比写PowerShell脚本更可靠因为AutoClaw的清理逻辑会智能识别文件是否正在被其他进程写入避免“文件被占用”错误。4. 故障排查与高阶运维技巧4.1 常见失败场景速查表与根因分析AutoClaw的错误日志设计得非常“程序员友好”——它不只告诉你“哪里错了”更告诉你“为什么错”以及“下一步该做什么”。以下是我在过去18个月运维237个采集任务中总结出的TOP5失败场景及应对策略错误代码日志片段示例根本原因排查步骤解决方案PARSE_EMPTYERROR [sh_hr_subsidy] Parsing failed: no items matched item_selector .article-item页面结构变更列表容器class名被修改1. 用autoclaw parse --html snapshot.html --rule xxx.aclaw离线测试2. 用浏览器打开snapshot.htmlF12搜索.article-item是否存在更新item_selector为新class名或改用更稳定的父容器子元素组合如#main-content div:nth-child(2) .list-itemHTTP_403ERROR [jd_iphone15pro] HTTP request failed: 403 Forbidden目标站识别出非人类请求封禁了当前User-Agent1. 检查config/settings.yaml中user_agent_pool是否启用2. 用curl模拟请求curl -H User-Agent: Mozilla/5.0... https://item.jd.com/...启用user_agent_pool或在规则中增加headers.Referer或联系目标站申请白名单REGEX_NO_MATCHWARNING [jd_iphone15pro] Field original_price: regex ([\d.]) found 0 matches in script content页面JS数据格式变更price字段值不再是纯数字字符串1. 用浏览器查看源码确认price:7999.00是否变为price:7999.00去掉引号2. 检查正则是否能匹配整数修改正则为price:\s*(\d\.?\d*)增加对无引号数字的支持DB_LOCKEDERROR [sh_hr_subsidy] SQLite database is locked, retrying... (attempt 3/3)多个任务同时写入同一SQLite数据库发生锁竞争1. 检查task_state表确认是否有其他任务正在运行2. 查看ps aux | grep autoclaw确认进程数对高频任务使用独立数据库文件或改用PostgreSQL等支持高并发的数据库后端JS_TIMEOUTERROR [xxx] JS evaluation timed out after 200ms启用的JS沙箱执行超时通常是页面嵌入了复杂计算逻辑1. 检查规则中是否误启用了js_eval: true2. 用autoclaw parse --no-js测试是否能正常解析在规则中显式设置js_eval: false或优化JS代码逻辑确保在200ms内完成这张表不是教科书式的罗列而是我踩坑后的真实记录。比如DB_LOCKED错误最初我以为是SQLite性能问题折腾了两天优化PRAGMA设置最后发现只是因为测试时手贱多开了一个终端窗口执行了autoclaw run命令。AutoClaw的日志里其实早有提示“Another process is holding the database lock”但我当时太焦虑没仔细读完那行小字。4.2 数据质量保障从“能跑通”到“信得过”很多团队把AutoClaw当成“能跑通就行”的工具结果上线三个月后发现历史数据里混入了大量测试时期的脏数据价格监控的CSV文件里同一时间戳出现了两条记录补贴公示的数据库里“publish_date”字段全是NULL。这些问题的根源不是AutoClaw不好而是缺少数据质量校验环节。我们在生产环境中强制推行“三道校验关卡”第一关规则级校验Rule Validation在autoclaw init生成的config/settings.yaml中开启validation.strict_mode: true。此时AutoClaw会在每次加载规则时执行以下检查所有required: true的字段其selector必须能在HTML中至少匹配到1个节点post_process链中的每个处理器其输入类型必须与上一个处理器的输出类型兼容例如regex_extract的输出是字符串不能直接接int_convertcron表达式必须符合标准格式且next_run_at计算结果不能早于当前时间。如果校验失败AutoClaw直接退出并打印清晰的错误位置第几行哪个字段绝不带病运行。第二关数据级校验Data Validation在规则文件的output区块下增加validation子项output: format: sqlite database: subsidy_data.db table: sh_hr_subsidy validation: # 必填字段非空检查 not_null: [title, publish_date, detail_url] # 数值范围检查价格不能为负 numeric_range: original_price: {min: 0, max: 100000} promote_price: {min: 0, max: 100000} # 日期格式检查 date_format: publish_date: %Y-%m-%d当某条记录违反任一校验规则时AutoClaw不会写入数据库而是将其存入data/rejected/目录下的JSON文件并在日志中标记REJECTED: [reason]。这样数据质量问题被前置拦截而不是污染主库后再费力清洗。第三关业务级校验Business Validation这是最高阶的保障。我们在config/目录下创建business_rules.py定义业务逻辑def check_price_drop(row): 检查价格是否异常下跌超过30% if row.get(original_price) and row.get(promote_price): drop_rate (float(row[original_price]) - float(row[promote_price])) / float(row[original_price]) if drop_rate 0.3: return fPrice drop too high: {drop_rate:.1%} return None def check_date_consistency(row): 检查公示日期是否晚于今天 from datetime import date if row.get(publish_date): try: pub_date date.fromisoformat(row[publish_date]) if pub_date date.today(): return fPublish date {pub_date} is in future except ValueError: return Invalid publish_date format return None然后在规则文件中引用output: # ... 其他配置 business_validation: business_rules.check_price_drop,business_rules.check_date_consistency当业务校验失败时AutoClaw会触发告警邮件/企微并将问题数据存入data/business_alerts/供业务方人工复核。这套三层校验体系让我们交付给客户的报表准确率从最初的92.7%提升到99.98%差的那0.02%是目标站自身数据录入错误已超出我们的控制范围。4.3 性能调优与资源监控实战AutoClaw默认配置足够应付大多数场景但当你的任务规模达到“50并发采集”或“单任务日均处理10万页面”时就需要针对性调优。以下是我在某省级政务数据平台实施时的调优笔记内存优化默认情况下AutoClaw为每个任务分配独立的Python进程内存占用随任务数线性增长。我们通过config/settings.yaml启用进程复用# 启用任务分组同组任务共享进程 process_grouping: enabled: true # 每组最多3个任务按URL域名分组 group_by: domain max_tasks_per_group: 3效果50个任务的总内存占用从2.1GB降至840MBGC压力显著降低。网络优化针对目标站有IP频控的情况我们配置了连接池http_client: # 复用TCP连接减少握手开销 keep_alive: true # 连接池大小根据目标站并发能力调整 pool_size: 10 # 连接空闲超时避免长连接被中间设备断开 pool_timeout: 300配合retry: 3和指数退避默认启用单任务成功率从89%提升至99.2%。监控集成AutoClaw原生支持Prometheus指标暴露。在config/settings.yaml中开启monitoring: prometheus: enabled: true port: 9101 # 指标前缀便于多实例区分 namespace: autoclaw_prod然后用Prometheus抓取http://localhost:9101/metrics我们重点关注三个指标autoclaw_task_duration_seconds_bucket任务执行耗时分布P95超过30秒需告警autoclaw_http_requests_total{status_code~4..|5..}HTTP错误率持续高于1%需人工介入autoclaw_parsing_items_total每分钟解析出的记录数突降50%以上可能意味着页面改版。这套监控让我们在某次省级信用公示平台大改版中提前47分钟发现PARSE_EMPTY错误激增比业务方的通知还早2小时赢得了宝贵的应急窗口期。5. 进阶应用与生态扩展5.1 与现有数据栈无缝集成从SQLite到数据湖AutoClaw天生不是孤岛。它的输出模块设计成插件式架构你可以轻松对接任何数据终点。以下是我们在三个典型场景中的集成方案场景1对接Airflow做复杂编排当采集任务需要依赖上游ETL结果比如先跑完用户行为分析再基于结果生成个性化推送清单我们用Airflow的PythonOperator封装AutoClawfrom airflow import DAG from airflow.operators.python import PythonOperator from datetime import datetime, timedelta import subprocess def run_autoclaw_rule(rule_name): result subprocess.run( [autoclaw, run, --rule, f{rule_name}.aclaw], capture_outputTrue, textTrue, cwd/opt/autoclaw ) if result.returncode ! 0: raise Exception(fAutoClaw failed: {result.stderr}) with DAG( autoclaw_pipeline, default_args{retries: 1}, schedule_interval0 */2 * * *, start_datedatetime(2024, 1, 1) ) as dag: t1 PythonOperator( task_idrun_jd_price_monitor, python_callablerun_autoclaw_rule, op_kwargs{rule_name: jd_iphone15pro} )Airflow负责调度依赖关系AutoClaw专注数据采集职责清晰。场景2写入数据湖Delta Lake对于需要ACID事务和时间旅行查询的场景我们开发了autoclaw-delta插件pip install autoclaw-delta然后在规则文件中output: format: delta path: s3://my-data-lake/autoclaw/jd_prices # Delta Lake特有的配置 delta: partition_by: [dt] # 按日期分区 merge_on: [product_id, dt] # 合并键每次运行AutoClaw会自动执行MERGE INTO操作实现增量更新避免全量重刷。场景3实时推送到Kafka当业务需要毫秒级响应如价格变动实时触发风控模型我们启用Kafka输出output: format: kafka bootstrap_servers: kafka1:9092,kafka2:9092 topic: autoclaw-price-updates # 每条记录作为独立消息 message_key: product_id # JSON序列化兼容Flink消费 serialization: jsonKafka Producer内置重试和批量发送吞吐量可达5000 msg/s。5.2 安全合规实践GDPR/个人信息保护法下的采集边界AutoClaw不是法外之地。我们在为客户部署时强制执行三项合规红线红线一禁止采集个人身份信息PII在config/settings.yaml中全局禁用privacy: # 禁止任何规则使用以下敏感字段名 forbidden_field_names: [id_card, phone, mobile, email, address, name] # 禁止使用可能泄露PII的XPath forbidden_selectors: - //table[contains(class, personal)]//td[2] - //*[idcontact-info]一旦规则中出现上述字段名或选择器AutoClaw加载时直接报错退出。红线二数据留存期限强制管控在每个规则的output区块必须声明retention_daysoutput: format: sqlite database: subsidy_data.db table: sh_hr_subsidy retention_days: 180 # 严格保留180天到期自动清理AutoClaw的cleanup命令会扫描所有规则统一执行过期数据删除审计时可提供完整的清理日志。红线三目标站robots.txt尊重协议AutoClaw内置robots.txt解析器。当规则中target.url指向某域名时它会自动请求https://domain/robots.txt并检查User-agent: autoclaw或