> 文件性质：学习时刻归档——我们在向上寻找自己的位置，不是从零建造
> 创建：2026-07-22 | 来源：robocopy R/W 模式 → 触发全量基础设施审视
局域网备份时发现 robocopy 命令参数 /R:2 /W:5（重试 2 次、等待 5 秒）。这个模式与我们的路由引擎错误重试逻辑完全同构，但我们的实现更原始——没有区分"重试几次"和"每次等多久"。进一步挖掘发现：不只是 R/W 没分拆——是我们不知道生态领主们已经给出了大量现成的标准解法。
| 我们要做的事 | 领主 | 现成解法 | 对齐方式 |
|------|------|------|------|
| 进程保活/重启 | 操作系统 / WorkBuddy | systemd / Windows Service / cron 触发 | 引擎无状态——WorkBuddy 自动化计划调度，崩了下次 cron 拉起 |
| 日志轮替 | Python logging | RotatingFileHandler——按大小轮替，自动压缩 | 替换手动 cat >> pipeline-log |
| 配置文件校验 | jsonschema | jsonschema.validate(config, schema) | 启动时自动跑，格式不对拒绝启动 |
| 文件变更监听 | watchdog | 跨平台文件系统事件 | 替代 Tick 轮询——文件变了立即触发 |
| 凭据管理 | python-dotenv | .env 文件存储敏感信息 | 服务器 IP、SSH 密钥路径不硬编码在 JSON 里 |
| HTTP 重试 | urllib3 / requests | Retry(total=N, backoff_factor=S) | 不需要自己写 R/W 循环——库已经维护了十年 |
| 进程内并发 | Python asyncio | 协程——单线程内并发 | 多链并行不需要多进程——一个事件循环管所有节点链 |
| 包管理/依赖锁定 | pip + requirements.txt | 固定版本号 | 我们之前没有——现在补 |
| 中国区 pip 加速 | 清华/阿里云镜像 | pip install -i https://pypi.tuna.tsinghua.edu.cn/simple <pkg> | 安装命令默认带镜像源 |
| Agent 间通信 | 巴别塔协议 | 文件系统 JSONL 消息总线 | 已对齐——babel-alignment-v0.1.json |
| Skill 执行格式 | WorkBuddy | SKILL.md 规范 | 已使用——自动化计划 prompt 本身就是 |
| Slot 原子写入 | POSIX | tmp→rename 原子文件替换 | 已写入开发规范紧追-L1 |
| Append-only 日志 | 数据库 WAL 简化 | 只追加不覆盖 | pipeline-log 已在用 |
| 我们的做法 | 实际上是 | 标准名称 | 领主 |
|------|------|------|------|
| slot 文件作为节点间通讯 | 以文件系统作消息总线 | File-based Message Bus | 巴别塔协议·MIT |
| JSON schema 作配置文件 | 架构驱动的配置 | Schema-driven Configuration | JSON Schema 标准 |
| tmp→rename | 原子文件替换 | Atomic File Replacement | POSIX |
| pipeline-log 追加写入 | 只追加日志 | Append-only Log | 数据库 WAL |
| 紧追安全变更 | 安全补丁跟踪 | Security Patch Tracking | Claude Code 五环 |
| 约束 | 影响 | 引擎策略 |
|------|------|------|
| Google 服务不可达 | Google Search Console 无法自动查询 | 不建自动节点——提醒人去百度/头条后台手动查看 |
| Bing API 间歇性超时 | AI Performance 查询不一定成功 | 内置 external_unreachable 错误类型——不重试，降级到人工提醒 |
| GitHub raw 慢但不丢包 | 巴别塔协议检查勉强可行 | R=1 W=0——不通就跳过下周再试 |
| 百度需实名 | 自动提交 sitemap 不可行 | 手动提交——不建自动节点 |
| 头条搜索稳定 | sitemap 可自动提交 | 保留自动节点 |
robocopy /R:2 /W:5 揭示重试 = 两个独立参数：
| 参数 | 含义 | 我们之前的等价物 | 缺陷 |
|------|------|------|------|
| R | 重试次数 | retry_cooldown_minutes（只定义了间隔，没定义次数） | 没有区分"试几次"和"等多久" |
| W | 每次间隔 | 同上 | 同上 |
结论：重试次数（max_retries）和等待间隔（retry_interval）必须解耦。不同错误类型需要不同的 R/W 配置。但 HTTP 层的 R/W 不需要我们实现——urllib3.Retry 已经维护了十年。
这不是施工计划。不是开发规范。不是产品定义。这是引擎在寻找自己生态位置的快照——每一次发现"这个东西别人已经做好了"，引擎的边界就更清晰一层。我们的起点是一份组织架构图。现在我们在做的是向上寻找——不是造更多东西，是看清哪些东西不需要我们造。
> 原则：能用领主给的标准解法的，不用自己的。能用库的，不手写。能用协议的，不另起炉灶。