一只龙虾管起了犹太家庭的安息日

一个严格遵守教规的犹太家庭，把家里最敏感的宗教自动化交给了开源平台。它的吉祥物偏偏是龙虾——犹太饮食律法里最明确的禁忌食材之一。

这种荒诞感背后，是一套被精心拆解的自动化架构。作者用OpenClaw搭建的这套系统，正在处理每周25小时、全年数十个节日的复杂调度。

龙虾与安息日的奇怪共存

正统犹太教的安息日（Shabbat）从周五日落前开始，持续到周六夜晚。期间禁止操作电器、烹饪、调节温控设备。冰箱必须提前进入"Sabbath模式"——一种禁用指示灯、压缩机会按需运行的特殊状态。

卧室空调需要预冷并在日落前关闭。客厅空调得判断当周是否热浪来袭。所有设备一旦进入安息日就不能再碰。

犹太节日日历让问题更复杂。某些节日会连着安息日形成两天不间断的禁工期。手动管理这些切换，出错代价是宗教层面的。

OpenClaw的吉祥物是一只龙虾。龙虾在犹太教规中明确不可食用——没有鳍、没有鳞，属于"水中可憎之物"。作者承认这点"有点好笑"，但龙虾AI"对此非常 gracious（宽容）"。

为什么把LLM和调度器拆开

OpenClaw的技能（skill）结构很简单：一个SKILL.md文件，加上你想让代理调用的脚本。作者把每个家电做成独立技能，再用调度脚本层叠在上面。

关键设计：调度器由cron触发，不经过大语言模型。

这个拆分有明确的技术理由。调度器需要确定性、幂等性，还得在作者彻底忘记它们存在时继续运转。LLM介入会增加失败点、延迟和不可预测性。

代理层只处理交互场景。作者通过Telegram问"冰箱已经在安息日模式了吗？"——这时候才需要LLM理解问题、查询状态、组织语言回复。

这是典型的分层架构：底层确定性任务用确定性工具，上层开放性交互用生成式模型。但作者没提"架构设计"，只提"我需要这个能活过我被遗忘"。

代码里藏着什么

作者公开了两个调度器的核心逻辑。第一个每周五上午运行，从Hebcal拉取当周的烛光和 havdalah（仪式性结束安息日）时间。

Hebcal是一个提供犹太历法数据的公共服务，支持通过geonameid（地理名称ID）定位城市。请求参数里"M=on"开启现代历法计算——正统派内部对历法计算有分歧，这个开关意味着作者选择了特定传统。

代码处理三种事件类型：candles（烛光）、havdalah（结束仪式）、parashat（当周 Torah 章节）。只取第一个匹配项，用fromisoformat解析时间戳。

调度逻辑很直接：安息日开启时间 = 烛光时间减1小时。用at命令（Unix一次性任务调度）分别设置在两个时间点执行开关操作。

作者特意把城市ID换成占位符，方便其他人直接套用。这是开源社区的习惯动作——把自己的具体配置抽象成可复用的模板。

宗教自动化里的产品启示

这个案例戳破了几个关于AI代理的迷思。

第一，"代理"不等于"LLM驱动一切"。作者的系统里，LLM只参与最后10%的交互层，90%的调度逻辑是传统脚本。但产品叙事往往把两者混为一谈，仿佛不用大模型就不算AI。

第二，可靠性优先于智能。安息日模式切换失败意味着宗教违规，这比"回复不够自然"严重得多。作者选择cron+at这种几十年历史的Unix工具，因为它们的行为可预测、可调试、不依赖外部服务。

第三，个人自动化和工业自动化的鸿沟。企业级方案会追求统一平台、集中监控、权限管理。作者只需要"我忘了它也能跑"——这是完全不同的可靠性模型。

OpenClaw作为开源平台，在这里扮演的角色是降低编排成本。SKILL.md的约定让家电抽象标准化，但具体实现完全开放。作者没等官方支持安息日场景，自己用Python+Hebcal拼出了方案。

这种"平台提供骨架，用户填充血肉"的模式，在宗教、医疗、法律等强规则领域可能更有生命力。通用AI代理承诺解决一切，但真实需求往往是"在这个特定约束下， deterministic 地解决这一个问题"。

龙虾的讽刺性在这里变成了一种诚实：技术中立性不需要假装尊重你的价值观，它只需要不主动破坏。作者接受了这种不对等——用一个非 kosher 的符号，管理最 kosher 的生活节奏。