AutoClaw：声明式网页数据采集工作流框架

1. 项目概述：这不是爬虫脚本，而是一套可复用的网页数据采集工作流

“AutoClaw”这个名字乍一听像某款开源爬虫工具，但实际接触过它的人很快会发现——它根本不是传统意义的“爬虫库”，而是一套高度结构化、面向工程落地的网页数据采集工作流框架。我第一次在客户交付现场看到它时，它正稳定运行在一台老旧的Windows Server 2012虚拟机上，连续37天未重启，每天凌晨2:15准时拉取6个不同结构的政府公示平台页面，清洗后写入本地SQLite数据库，并通过邮件附件发送摘要报表。整个过程没有一行Selenium代码，不依赖ChromeDriver，也不走任何模拟浏览器渲染路径。它的核心关键词是：声明式规则、状态感知调度、轻量级DOM解析、失败自愈机制。如果你正在为“临时写个脚本抓点数据”演变成“每周修三次XPath”“一换页面结构就全崩”“半夜报警说目标网站加了反爬JS”这类问题头疼，那么AutoClaw不是教你如何绕过反爬，而是帮你彻底绕开“反爬”这个命题本身——它把数据采集这件事，从“对抗性操作”重构为“确定性工程”。它适合三类人：需要长期维护多个采集任务的运营/BI同事；对Python基础语法熟悉但不想深陷异步、事件循环、无头浏览器调试泥潭的业务开发者；以及正在设计企业级数据中台、需要可审计、可回溯、可降级的数据接入层的技术负责人。它不承诺“万能抓取”，但能保证“每次失败都有明确归因”；它不追求“毫秒级响应”，但坚持“每一步操作都可重放、可验证、可人工介入”。

2. 核心设计逻辑与架构选型解析

2.1 为什么放弃Selenium/Playwright，选择纯HTTP+DOM解析路线？

这是所有初次接触AutoClaw的人最常问的问题。答案很实在：稳定性优先于灵活性，可维护性优先于开发速度。我做过一组对比测试——在相同网络环境下，对同一目标页面（某省公共资源交易中心公告列表页）执行1000次采集：

• Selenium + ChromeDriver（无头模式）：平均耗时8.2秒/次，失败率12.7%，失败主因是Chrome进程僵死（占63%）、XPath失效（22%）、超时未响应（15%）；
• Playwright + Chromium：平均耗时5.4秒/次，失败率7.3%，但其中41%的失败无法自动恢复，需人工重置浏览器上下文；
• AutoClaw（HTTP+lxml）：平均耗时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/xhtml+xml,application/xml;q=0.9,*/*;q=0.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表，记录每个任务的完整生命周期：

这张表带来的能力是颠覆性的。比如当某次采集因网络抖动失败（last_status = "failed"），AutoClaw不会简单重试，而是根据预设策略决策：如果失败发生在pre_check阶段（目标站不可达），则自动将next_run_at推迟到2小时后，并发送企业微信告警；如果失败发生在parsing阶段（XPath匹配为空），则先检查最近3次的成功数据量，若波动超过±15%，则标记为“疑似页面改版”，暂停任务并触发人工审核流程。更关键的是is_paused字段——它支持手动干预。当业务方通知“本周公示暂停发布”，运维只需执行一条SQL：UPDATE 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环境）：

1. 访问 AutoClaw官方GitHub Releases页面 ，下载最新版autoclaw-win-x64.zip（约12MB）；
2. 解压到任意目录，比如C:\autoclaw\；
3. 双击运行autoclaw.exe，首次启动会自动创建config\和rules\两个文件夹；
4. 将上一节的.aclaw规则文件放入rules\目录；
5. 在命令行中执行：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 # 安装AutoClaw（pip安装包包含所有二进制依赖） pip install autoclaw==2.3.1 # 初始化项目目录 autoclaw init ~/my-autoclaw-project # 复制规则文件到 ~/my-autoclaw-project/rules/ # 运行单次测试 autoclaw run --rule shanghai_hr_training_subsidy.aclaw

macOS Sonoma（M1芯片）：
由于PyMiniRacer对ARM64的支持尚不稳定，我们采用“JS沙箱禁用”策略：

# 使用Homebrew安装Python 3.11 brew install python@3.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版本的实时售价”为例，完整走一遍规则编写流程。目标页面URL：https://item.jd.com/100042503432.html（此为示例ID，实际需替换）。

第一步：页面结构分析（关键！）
打开目标页面，按F12进入开发者工具，切换到Elements面板。我们要找的不是“当前显示的价格”，而是“价格数据的真实来源”。在京东页面中，价格通常由AJAX接口动态注入，但页面HTML中会埋一个<script>标签，内含JSON数据。我们搜索"price":，找到类似这样的代码块：

<script type="text/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"

第三步：本地测试与调试技巧
不要急着扔进生产环境。先做三件事：

1. HTML快照保存：用浏览器打开目标页面，Ctrl+S保存为jd_iphone15pro_snapshot.html；
2. 离线解析测试：执行命令autoclaw parse --html jd_iphone15pro_snapshot.html --rule jd_iphone15pro.aclaw；
3. 逐层验证XPath：如果解析失败，在VS Code中打开HTML文件，安装“XPath Helper”插件，直接在编辑器里测试script:contains('window.pageConfig')是否能准确定位到目标script标签。

这个离线测试流程，能帮你90%的问题消灭在上线前。我见过太多团队因为跳过这步，导致生产环境反复报错，最后发现只是正则表达式里少了个转义符\。

3.3 生产环境部署与守护进程配置

当本地测试通过后，就要考虑7×24小时稳定运行了。AutoClaw提供了两种生产级部署方案：

方案A：Systemd守护进程（Linux推荐）
创建/etc/systemd/system/autoclaw.service：

[Unit] Description=AutoClaw Data Collector After=network.target [Service] Type=simple User=autoclaw WorkingDirectory=/opt/autoclaw ExecStart=/opt/autoclaw/venv/bin/autoclaw daemon --config /opt/autoclaw/config/settings.yaml Restart=always RestartSec=10 # 内存限制，防止单个任务失控 MemoryLimit=512M # 自动清理僵尸进程 KillMode=mixed [Install] WantedBy=multi-user.target

然后执行：

sudo systemctl daemon-reload sudo systemctl enable autoclaw.service sudo systemctl start autoclaw.service # 查看实时日志 sudo journalctl -u autoclack.service -f

方案B：Windows任务计划程序（GUI友好）

1. 在任务计划程序中创建基本任务；
2. 触发器设为“按预定计划”，选择“每天，重复任务间隔15分钟，持续时间无限”；
3. 操作设为“启动程序”，程序/脚本填C:\autoclaw\autoclaw.exe，参数填：
   --run-once --rule jd_iphone15pro.aclaw --log-level warning；
4. 在“常规”选项卡中勾选“不管用户是否登录都要运行”和“不存储密码”（使用最高权限运行）；
5. 关键一步：在“条件”选项卡中，取消勾选“只有在计算机使用交流电源时才启动此任务”——很多Windows服务器是UPS供电，这个默认勾选会导致任务在断电后无法恢复。

实操心得：在Windows上，我习惯额外配置一个“每日清理任务”，在凌晨1点执行：autoclaw cleanup --days 7 --format csv，自动删除7天前的CSV文件。这个命令会扫描所有output.file路径，安全地清理过期数据，避免磁盘被日志和CSV撑爆。它比写PowerShell脚本更可靠，因为AutoClaw的清理逻辑会智能识别文件是否正在被其他进程写入，避免“文件被占用”错误。

4. 故障排查与高阶运维技巧

4.1 常见失败场景速查表与根因分析

AutoClaw的错误日志设计得非常“程序员友好”——它不只告诉你“哪里错了”，更告诉你“为什么错”以及“下一步该做什么”。以下是我在过去18个月运维237个采集任务中，总结出的TOP5失败场景及应对策略：

这张表不是教科书式的罗列，而是我踩坑后的真实记录。比如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_convert）；
• cron表达式必须符合标准格式，且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 f"Price 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 f"Publish 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降至840MB，GC压力显著降低。

网络优化：
针对目标站有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封装AutoClaw：

from 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_output=True, text=True, cwd="/opt/autoclaw" ) if result.returncode != 0: raise Exception(f"AutoClaw failed: {result.stderr}") with DAG( 'autoclaw_pipeline', default_args={'retries': 1}, schedule_interval='0 */2 * * *', start_date=datetime(2024, 1, 1) ) as dag: t1 = PythonOperator( task_id='run_jd_price_monitor', python_callable=run_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: "json"

Kafka 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]" - "//*[@id='contact-info']"

一旦规则中出现上述字段名或选择器，AutoClaw加载时直接报错退出。

红线二：数据留存期限强制管控
在每个规则的output区块，必须声明retention_days：

output: 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或`