Spratt Skills：基于LLM规划与代码执行的OpenClaw家庭自动化架构实践

1. 项目概述Spratt Skills一个为OpenClaw打造的家庭自动化基础设施套件如果你正在使用OpenClaw并且已经厌倦了让LLM大语言模型去处理那些它天生就不擅长的事情——比如定时发送消息、轮询航班状态、或者可靠地写入数据库——那么Spratt Skills就是为你准备的。这不是另一个教你如何写提示词SKILL.md的教程而是一套完整的、经过实战检验的“基础设施”插件。它的核心哲学非常明确让LLM做它最擅长的事理解和规划然后用确定性的代码去执行它最不擅长的事可靠地交付。这个项目源于一个真实家庭的日常需求运行在一台Mac Mini M4上处理着从旅行规划、购物清单到信用卡优惠提醒的一切。它解决了我们在早期使用纯LLM代理时遇到的所有痛点消息发错群聊、航班监控任务神秘消失、购物记录无法关联。Spratt Skills通过引入数据库、守护进程和清晰的工具边界将OpenClaw从一个聪明的聊天机器人转变为一个真正可靠的家庭操作系统核心。想象一下这样的场景你告诉助手“我们下周五去纽约”它不仅能理解还会自动在数据库里创建行程为航班添加监控并预约出发前的提醒消息。当你的特斯拉设置导航去超市时相关的购物清单会自动弹出。每周六系统会检查你信用卡里即将过期的月度消费券并提醒你。所有这些背后都没有LLM在实时决策只有稳定运行的代码在默默工作。2. 核心架构与设计哲学2.1 “LLM规划代码执行”的分层模型Spratt Skills的整个架构都建立在一个简单的二分法上什么是LLM该做的什么是代码该做的。LLM的职责规划层自然语言理解从用户的模糊指令“记得提醒我下周取药”或非结构化数据邮件正文中提取结构化信息。意图识别与路由判断用户是想发消息、查行程、还是记下一个地点并调用正确的工具Tool Routing技能的核心。内容生成撰写友好、个性化的消息正文或者生成复杂的多步骤计划如旅行规划。决策制定基于上下文如购物历史决定“现在需要买牛奶吗”。代码的职责执行层状态管理与持久化所有数据行程、订单、消息队列都写入SQLite数据库。代码负责创建、读取、更新、删除CRUD记录。调度与轮询守护进程Daemon定时检查数据库中的任务如发送消息、查询航班状态并在准确的时间触发操作。外部API调用与FlightAware、Google Places、Microsoft Graph等第三方服务进行稳定、认证的通信。资源管理与错误处理处理网络超时、API限流、浏览器崩溃恢复等一切需要确定性和可靠性的问题。这种分离带来了巨大的稳定性提升。早期我们尝试用OpenClaw的Cron功能让LLM自己轮询航班状态结果它在几次查询后因为无法解析“未找到航班”的状态竟然自己删除了整个监控任务导致一次重要的接机提醒完全遗漏。而现在的flight-monitor守护进程只是一个简单的Python脚本每3分钟查询一次API逻辑清晰永不“理解错误”。2.2 统一的数据层所有数据库归于一处一个早期让我们头疼不已的问题是“数据库去哪儿了”不同的技能脚本将SQLite文件创建在不同的目录./outbox/messages.db,../trips/trips.db, 散落各处。当LLM代理运行时如果它找不到数据库文件sqlite3.connect()会“友好地”在它认为的路径上创建一个全新的空文件。这导致了灾难性的“数据分裂”脚本A写入了一个路径脚本B从另一个空文件读取用户看到的数据莫名其妙消失了。踩坑实录数据库路径的幽灵我们曾三次在两周内遇到这个问题。一次是在调整项目结构后trip-db.py因为相对路径计算错误在用户家目录下创建了一个空的trips.sqlite。所有新添加的行程都进了这个“黑洞”而LLM查询时却从正确的路径读取旧数据导致用户以为行程添加成功实则全部丢失。排查时需要对比多个潜在路径下数据库文件的修改时间非常痛苦。解决方案硬编码的单一数据目录。现在所有Spratt Skills组件都遵循一个铁律所有数据库文件必须位于一个统一的、硬编码的目录下。在我们的配置中就是~/.config/spratt/db/。~/.config/spratt/db/outbox.sqlite- 消息队列~/.config/spratt/db/trips.sqlite- 行程管理~/.config/spratt/db/orders.sqlite- 订单追踪~/.config/spratt/db/cards.sqlite- 信用卡管理...等等每个脚本在连接数据库前都会强制检查文件是否存在。如果不存在不是静默创建而是立即报错退出。这彻底杜绝了因路径错误导致的数据分裂。# 以 outbox.py 中的代码为例 def require_db_file(path, name): 如果SQLite数据库文件不在预期路径则大声报错退出。 if not os.path.exists(path): sys.stderr.write( f\n致命错误: 未找到 {name} 数据库文件于:\n {path}\n\n f拒绝自动创建防止因路径错误导致静默数据丢失。\n\n f请运行初始化命令: python outbox.py init\n ) sys.exit(1) # 在数据库类初始化时调用 class OutboxDB: def __init__(self, db_path~/.config/spratt/db/outbox.sqlite, allow_createFalse): self.db_path os.path.expanduser(db_path) if not allow_create: require_db_file(self.db_path, Outbox) # ... 后续连接逻辑2.3 基于事件的响应式通信而非轮询LLM传统LLM智能体架构中实现定时或事件触发功能通常需要设置一个Cron任务定期唤醒LLM让它检查状态并决定做什么。这在Spratt Skills中被视为一种“反模式”。反例LLM轮询航班状态我们最初的设计是一个Cron任务每30分钟运行一次调用LLM。LLM会读取trips.sqlite找出所有“进行中”的航班然后调用一个“查询航班状态”的工具。这个工具再调用FlightAware API。LLM拿到结果后判断是否有“延误”、“降落”等事件最后调用message工具发送通知。问题1成本每次轮询都需要调用LLM和工具即使航班状态无变化。问题2可靠性LLM对API返回的复杂JSON状态码如“未找到”、“已取消”解析可能出错。问题3状态管理LLM需要维护“上次查询状态”和“本次状态”的对比逻辑复杂且容易在多次调用间丢失上下文。Spratt的解决方案专用守护进程flight-monitor是一个独立的Python守护进程。它直接读取trips.sqlite中的航班数据自己管理一个简单的内存状态如“已通知登机口变更”。它直接调用FlightAware API根据规则时间差、状态变更判断是否需要通知然后直接向outbox.sqlite插入一条消息记录。整个循环中没有LLM参与。优势1高效纯代码逻辑执行速度快成本为零。优势2可靠状态判断是确定性的if-else逻辑不会误解。优势3自适应可以轻松实现智能轮询航班起飞前3分钟查询一次起飞后30分钟查询一次。这个模式被广泛应用outbox的发送守护进程、destination-aware的Tesla导航监听服务都是独立于LLM的、事件驱动或定时轮询的守护进程。3. 核心组件深度解析与实操要点3.1 Outbox发件箱可靠的消息调度中枢它解决了什么问题直接让LLM调用message工具发送定时消息是不可靠的。OpenClaw的Cron任务在触发时会重新实例化一个LLM会话。这个新的LLM会话可能对原始指令有不同的解读。我们遇到过一个“晚餐提醒”本应发到家庭群聊结果Cron触发时LLM将其理解为“向每个家庭成员单独发送”导致晚餐通知变成了刷屏的私信。Outbox模式将“决定发什么”LLM和“在正确的时间发送”代码彻底分离。工作原理写入阶段当LLM需要发送一条定时消息例如“明早8点提醒我带伞”它不再直接调用message而是调用outbox.py schedule工具。这个工具将消息内容、接收者、计划发送时间写入outbox.sqlite的messages表状态为pending。轮询阶段一个名为sender.py的Python守护进程在后台持续运行通过macOS的launchd或Linux的systemd。它每60秒查询一次数据库找出所有状态为pending且send_at时间小于当前时间的消息。发送阶段对于每条待发送消息sender.py调用本地命令行工具imsgBlueBubbles项目的一部分通过iMessage发送。发送成功后将消息状态更新为sent失败则更新为failed并记录错误信息。实操要点与配置数据库初始化首先需要创建数据库和表结构。项目提供了SQL文件但更推荐使用脚本内嵌的初始化命令确保版本一致。cd outbox python outbox.py init # 这会创建数据库文件并写入模式守护进程部署sender.py需要以守护进程形式运行。对于macOS项目提供了com.spratt.outbox.sender.plist文件。你需要将其复制到~/Library/LaunchAgents/并修改其中的路径然后加载它。cp outbox/com.spratt.outbox.sender.plist ~/Library/LaunchAgents/ # 编辑plist文件将 ~/code/spratt-skills 改为你的实际路径 launchctl load ~/Library/LaunchAgents/com.spratt.outbox.sender.plist launchctl start com.spratt.outbox.senderiMessage集成这依赖于 BlueBubbles 和其附带的imsg命令行工具。确保BlueBubbles服务在你的Mac上运行并且imsg在系统路径中。在sender.py中检查IMSG_BIN变量的路径是否正确。错误处理与重试sender.py内置了简单的重试逻辑。对于发送失败的消息可以手动排查原因如iMessage服务未启动然后通过outbox.py retry message_id命令重试。关键设计取消操作的安全性早期版本曾因为一个错误的SQL语句DELETE FROM messages WHERE ...漏掉了WHERE条件导致整个消息历史被清空。现在的设计是取消消息使用UPDATE messages SET statuscancelled WHERE id IN (?,?,?)。永远不使用没有精确WHERE条件的DELETE操作。已取消的消息仍然保留在数据库中用于审计。如果需要清理必须通过一个显式的、独立的管理命令进行。3.2 Trip Manager行程管理器以数据库为中心的旅行自动化它解决了什么问题家庭旅行信息散落在邮件、短信、聊天记录和各种App中。航班时间、酒店确认号、餐厅预订、接送提醒……没有统一视图极易遗忘。Trip Manager为LLM提供了一个结构化的“单一事实来源”Single Source of Truth数据库。核心工作流创建行程用户说“计划一个去西雅图的周末旅行”。LLM调用trip-db.py add-trip创建一条行程记录。自动协调数据库触发器或后续脚本检测到新行程自动通过Outbox向“家庭管理员”发送消息“这是单人旅行还是家庭旅行”。根据回复“solo”或“group”触发不同的自动化脚本。添加详情LLM解析用户的航班确认邮件调用trip-db.py add-flight插入航班信息。同理添加酒店add-hotel、餐厅add-reservation等。自动生成提醒一个独立的脚本trip-outbox-gen.py通常由Cron触发扫描trips.sqlite为即将发生的项目如航班值机、酒店入住生成提醒消息并插入Outbox。关键点这个生成过程是确定性的模板化操作不经过LLM。航班监控联动flight-monitor守护进程会读取trips.sqlite中的航班数据自动开始监控。“查找群聊”的巧思家庭旅行通常有一个对应的iMessage群聊。手动获取群聊的GUID全局唯一标识符非常麻烦。Trip Manager的find-group-chat功能解决了这个问题当行程被标记为“group”时该功能被触发。它使用imsgCLI扫描最近一段时间如7天的iMessage聊天记录。通过分析聊天标题可能包含目的地关键词如“西雅图”和参与者家庭成员用启发式算法匹配最可能的群聊。自动将匹配到的群聊GUID关联到该行程。之后所有针对该行程的群发提醒都会发送到这个聊天。实操心得数据变更与消息同步最初当我们修改一个航班时间时只是简单更新了数据库记录并清空了关联的outbox_msg_id外键指望下次trip-outbox-gen.py运行时生成新消息。但这导致旧消息仍然留在Outbox中处于pending状态最终会和新的提醒一起发送造成重复。解决方案在trip-db.py的任何更新或删除操作中如果会影响已生成的提醒必须首先显式地取消cancelOutbox中对应的旧消息然后再清空或更新关联ID。这确保了数据变更与消息队列状态的原子性。3.3 Flight Monitor航班监控器智能、自适应的状态追踪从爬虫到官方API的演进最初我们使用一个名为FlightRadarAPI的第三方库它本质上是FlightRadar24网站的爬虫。我们发现它对于某些有效航班会返回“未找到”或过时数据稳定性很差。我们果断切换到了FlightAware的AeroAPI。虽然这是付费服务约每月5美元但它提供稳定、权威的航班状态数据包括实时位置、延误、登机口变更、甚至备降信息对于家庭自动化来说可靠性远超成本。守护进程设计详解flight_monitor.py作为守护进程其逻辑比看起来更精细数据源它不维护自己的状态表而是直接读取trips.sqlite中的flights表。这避免了数据同步问题。自适应轮询活跃窗口在航班计划起飞前2小时到计划降落后1小时的时间段内每3分钟查询一次API。这是事件高发期值机、登机、起飞、降落。空闲窗口其他时间每30分钟查询一次。只是为了检测航班是否有重大变动如提前一天取消。事件检测与去重守护进程在内存中为每个监控的航班维护一个“上次通知状态”。只有当API返回的新状态与旧状态相比发生了需要通知的变更如从“计划中”变为“延误”或登机口变更才会生成通知消息。防止因API数据微小波动导致的重复提醒。通知生成检测到事件后守护进程直接构造消息内容例如“UA123航班已降落比计划提前15分钟”并调用outbox.py的Python API插入到消息队列而不是通过LLM。配置关键点API密钥需要在FlightAware网站注册开发者账号获取AeroAPI密钥。将其设置在环境变量FLIGHTAWARE_API_KEY中。守护进程化与Outbox类似使用launchdplist文件。特别注意在plist中配置KeepAlive和RunAtLoad确保进程异常退出后能自动重启并且开机自启。日志务必配置日志重定向到文件如StandardOutPath和StandardErrorPath便于监控和调试。3.4 智能购物与清单体系从邮件到购物车的闭环这一系列组件Email-to-Orders, Instacart Orders, Smart Reorder, Instacart Skill共同构成了一个从订单捕获、分析到自动补货的完整闭环。3.4.1 Email-to-Orders订单信息的统一入口大多数在线购物亚马逊、DoorDash、Instacart都会发送确认邮件。这个组件通过一个定时Cron任务使用LLM通常是轻量级的Haiku模型扫描并解析这些邮件。解析内容提取商家、订单号、日期、金额、商品列表如果邮件中有、物流单号。结构化存储将所有信息写入orders.sqlite。这里的设计重点是扩展性。表结构不仅包含订单头信息还有独立的order_items表存储商品明细以及tracking_events表存储物流状态更新。物流追踪当收到包含物流单号的邮件如“您的包裹已发货”时系统会更新对应订单的物流状态。后续如果收到“已送达”的邮件可以自动触发Outbox通知。3.4.2 Instacart Orders补齐商品信息的最后一块拼图我们发现Instacart的确认邮件里没有商品明细只有一个链接。Instacart Orders技能就是为了解决这个问题。工作原理一个每日运行的Cron任务让OpenClaw启动浏览器自动登录Instacart网站导航到“历史订单”页面。数据抓取使用Playwright等浏览器自动化工具抓取订单详情页上的完整商品列表、单价、数量。数据回填调用order-ingest.py update-items将抓取到的商品明细回填到orders.sqlite中对应的订单记录里。至此我们拥有了完整的、带商品明细的购物历史数据库。3.4.3 Smart Reorder基于历史的智能预测这是数据产生价值的核心。purchase-cadence.py脚本分析orders.sqlite中的数据。商品归类Item Classification这是最大的挑战。收据上的商品名可能是“QFC Vitamin D Whole Milk Half Gallon”、“QFC Vitamin D Milk”、“Organic Valley Whole Milk”。我们需要知道哪些是同一商品的不同表述。这里再次引入LLMHaiku运行一个夜间任务将新的、未分类的商品名归类到“规范商品名”下并记录在item_aliases表中。购买周期计算对于每个“规范商品”计算历史购买间隔的中位数。例如牛奶可能每7天购买一次纸巾每30天一次。补货提醒结合最后购买日期和计算出的周期判断哪些商品“已过期”超过周期或“即将过期”达到周期的80%。这些信息会被后续的Instacart Skill使用。3.4.4 Instacart Skill自动化购物车构建这是面向用户的最终界面。当用户说“我们需要买点 groceries”时LLM调用Instacart Skill。该技能首先调用Smart Reorder获取需要补货的商品列表。然后它控制浏览器打开Instacart使用URL搜索技巧因为发现Playwright直接填充搜索框不稳定将商品逐一加入购物车。它还可以根据食谱meal-planner技能提供添加额外的食材。重要技能只构建购物车不自动结账。最后一步需要用户自己确认商品、选择送货时间并支付。这确保了安全性和用户控制权。实操陷阱浏览器自动化稳定性浏览器自动化Playwright在与复杂网页交互时非常脆弱。元素选择器可能因页面更新而失效登录状态可能过期页面可能加载缓慢。快照优先Snapshot-First在关键操作如点击“结账”按钮前先让浏览器等待页面完全加载并保存一个屏幕截图。如果操作失败截图有助于调试。URL搜索直接导航到如https://www.instacart.com/store/items/search?qmilk这样的搜索URL比在搜索框输入文本更可靠。崩溃恢复在Cron任务中设置超时和重试机制。如果浏览器会话崩溃脚本应能捕获异常清理残留进程然后重新启动任务。3.5 Destination-Aware Reminders目的地感知提醒上下文在正确的时间浮现这是我最喜欢的组件之一它体现了“环境计算”的理念信息在你需要的时候自动出现。传统提醒的局限你在早上7点设置了一个提醒“下午5点去幼儿园接孩子时带上体检表”。到了下午5点你可能正在开会提醒弹出你瞟了一眼心想“好的记得了”。然后你离开办公室开车路上接了电话……到了幼儿园门口你空着手下了车。提醒出现的时间5点整和需要行动的上下文到达幼儿园是脱节的。Spratt的解决方案事件监听destination-daemon.py守护进程通过WebSocket连接到家庭助理Home Assistant。它订阅特斯拉汽车的navigation_destination传感器。目的地解析当你设置导航时特斯拉会将目的地一个地址或POI名称发送给Home Assistant。守护进程捕获到这个事件调用goplacesCLI一个封装了Google Places API的工具将地址解析为结构化的地点信息包括类型如grocery_store,school,doctor。上下文搜集根据地点类型去不同的地方搜集相关信息grocery_store- 查询Smart Reorder中需要补货的商品或meal-planner生成的购物清单。school(daycare) - 查询Apple Reminders中与“幼儿园”、“孩子”相关的待办事项。doctor- 查询日历中即将到来的医疗预约笔记。智能过滤这是关键一步不能把所有的待办事项都塞给用户。系统使用LLMHaiku进行轻量级、分类别的过滤。例如对于超市类别提示词是“从以下待办事项中只挑选出需要购买的商品或与杂货购物直接相关的项目如‘买牛奶’‘记得用优惠券’。忽略所有其他类型的提醒如‘去邮局’‘打电话给妈妈’。” 这样当你导航去超市时你只会看到购物清单而不是一堆无关的提醒。消息发送将过滤后的、简洁的上下文列表通过Outbox发送到你的手机。例如“ 正在前往Whole Foods — 需要购买牛奶、鸡蛋、面包”。技术细节WebSocket连接可靠性家庭助理的WebSocket连接可能因为网络波动而中断。destination-daemon.py实现了“三重活性检测”Ping/Pong定期发送WebSocket Ping帧期待Pong回复。心跳事件定期向Home Assistant发送一个无害的get_services调用。看门狗定时器如果超过一定时间如70秒没有收到任何来自Home Assistant的消息包括事件和Pong则主动断开并重连。 这种设计确保了服务能7x24小时稳定运行应对临时的网络问题。3.6 Card Wallet卡包信用卡优惠与消费优化的智能管家管理多张信用卡的优惠如“每月$20餐饮抵扣”、“季度加油5%返现”和最佳消费策略“吃饭用哪张卡最划算”是一件繁琐且反人性的事。Card Wallet将其自动化。核心功能拆解优惠追踪Card Perks在cards.sqlite的benefits表中记录每张卡的所有优惠信息描述、类型月度/季度/年度、额度、有效期、已使用金额。一个每周六运行的Cron任务card-wallet-check.py会检查所有即将在未来10天内过期的优惠并通过Outbox发送分级提醒紧急3天内过期详细列出优惠、剩余额度、建议用法。本周7天内过期简要提醒。远期30天内合并成一行摘要避免信息过载。消费优化Card Optimizer在reward_rates表中记录每张卡在不同消费类别餐饮、旅游、超市、加油等的返现/积分倍数。当用户问“出去吃饭用哪张卡”时LLM查询此表结合每张卡的季度特定优惠如Chase Freedom本季度餐饮5%计算并推荐返现最高的卡。它还会考虑现实因素比如“这张卡是American Express有些小餐馆可能不收”。信息自动更新信用卡的优惠和返现规则时常变动。一个每月运行的Cron任务card-wallet-refresh.py会调用LLMHaiku让它基于卡的最新公开信息通过网页搜索进行总结和对比如果发现变动则更新数据库并通知用户。数据库设计经验为了支持多持卡人家庭数据库设计需要精细化cards表卡的基本信息银行、卡名、持卡人。benefits表每张卡的优惠与cards表关联。benefit_usage表记录每次优惠的使用情况日期、金额、商户用于计算剩余额度和分析使用习惯。reward_rates表每张卡在不同类别的返现率。quarterly_categories表记录那些有季度轮换优惠的卡如Chase Freedom, Discover It的本季度类别。 这种结构使得查询“用户A有哪些即将过期的餐饮优惠”或“在超市消费全家人的卡中哪张回报最高”变得非常高效。3.7 Tool Routing工具路由为LLM绘制清晰的地图当你的OpenClaw拥有了十几个技能和工具后LLM很容易“迷路”。它应该用message发即时消息还是用outbox发定时消息用户问“我们的计划是什么”它应该查行程数据库、日历还是提醒事项Tool Routing技能就是LLM的“决策手册”。它不是一个工具而是一份“说明书”SKILL.md里面定义了清晰的规则消息发送如果消息需要立即发送- 使用message工具。如果消息需要在未来的特定时间发送- 使用outbox schedule工具。绝对禁止使用Cron来发送消息。“我们的计划是什么”查询这是一个“多源聚合查询”。LLM需要依次检查1)trips.sqlite(未来行程) 2) Outlook日历通过outlook-calendar.sh 3) Apple Reminders通过remindctl然后将结果合并成一份统一的摘要。任务流TaskFlow指引对于复杂的多步骤交互如规划一次旅行Tool Routing定义了标准的模式先创建行程框架然后逐步添加航班、酒店每一步都确认最后生成总结。这保证了复杂任务执行的一致性。为什么这如此重要在没有明确路由规则时我们观察到LLM会出现“工具选择摇摆”。例如对于“明早8点提醒我”它有时会用outbox有时会错误地创建一个Cron任务。Tool Routing通过提供明确的“如果-那么”规则极大地提高了LLM行为的可靠性和可预测性。它本质上是对LLM进行“流程编排”的提示工程。4. 部署、集成与运维实战4.1 系统准备与依赖安装Spratt Skills主要面向macOS环境因其深度集成iMessage和Apple Reminders但核心组件经过设计可以适配Linux。核心依赖Python 3.9大多数脚本的基础。SQLite 3轻量级数据库macOS通常已预装。OpenClaw作为智能中枢需要先安装并运行起来。BlueBubbles imsg用于iMessage发送。在Mac上安装BlueBubbles服务端并确保其命令行工具imsg在PATH中。Home Assistant用于destination-aware技能需要安装Tesla集成。各种API密钥FlightAware AeroAPIGoogle Places API (forgoplaces)Microsoft Graph API (foroutlook-graph)Anthropic Claude API (for Haiku模型用于分类和摘要)环境配置项目使用一个统一的env.sh文件管理所有敏感信息。部署第一步就是复制模板并填写。cd spratt-skills cp shared/env/env.example.sh shared/env/env.sh # 使用文本编辑器打开 env.sh填入你的所有API密钥 # export FLIGHTAWARE_API_KEYyour_key_here # export ANTHROPIC_API_KEYyour_key_here # ...重要确保所有需要环境变量的守护进程如通过launchd运行的都能读取到这个文件。通常需要在plist文件的EnvironmentVariables部分显式设置或者在启动脚本中source这个文件。4.2 数据库初始化与技能注册部署遵循一个清晰的顺序因为组件间有依赖关系。创建统一数据目录mkdir -p ~/.config/spratt/db部署核心基础设施无依赖Outbox初始化数据库部署发送守护进程。这是所有通知的基础应最先设置。Tool Routing将SKILL.md复制到OpenClaw的skills/目录。这为LLM提供了全局指引。部署数据生产者组件Trip Manager初始化数据库。现在LLM就可以开始记录行程了。Email-to-Orders初始化数据库并设置邮件扫描Cron任务。开始积累购物历史。Places初始化数据库。用于保存地点信息。部署数据处理与自动化组件Flight Monitor配置API密钥部署守护进程。它依赖trips.sqlite。Instacart Orders设置每日Cron任务。它依赖orders.sqlite和浏览器登录状态。Smart Reorder运行一次性的历史数据回溯分析生成初始的购买周期数据。部署交互式技能Instacart Skill将SKILL.md复制到技能目录。确保OpenClaw的浏览器配置文件已登录Instacart。Meal Planner配置食谱数据库路径。Card Wallet初始化数据库输入初始的信用卡和优惠信息部署每周/每月Cron任务。Destination-Aware配置Home Assistant连接和API密钥部署守护进程。这是最复杂的之一需仔细测试WebSocket连接。Apple Reminders编译Swift二进制文件并确保remindctl安装正确。4.3 与OpenClaw的集成SKILL.md与CronSpratt Skills与OpenClaw通过两种方式集成1. 技能定义SKILL.md每个面向用户交互的组件如Instacart Skill,Places,Tool Routing都有一个SKILL.md文件。这个文件定义了技能名称和描述LLM如何识别和调用这个技能。可用工具Tools列出了该技能暴露给LLM的所有命令行工具或API端点包括参数说明和示例。工作流程Workflows复杂的多步骤任务应该如何执行。 你需要将这些SKILL.md文件复制到OpenClaw的skills/目录下OpenClaw会在启动时加载它们使LLM知晓这些功能。2. 定时任务CronOpenClaw支持配置Cron任务定期执行某个技能或工具。Spratt Skills中的许多后台作业都通过Cron触发邮件扫描email-to-orders的扫描任务每天运行3次。Instacart订单抓取instacart-orders的抓取任务每天运行1次。智能补货分析smart-reorder的分类任务每天运行1次。信用卡优惠检查card-wallet-check每周运行1次。 你需要在OpenClaw的Cron配置文件中添加这些任务条目。4.4 监控、日志与故障排查一个家庭自动化系统需要保持安静稳定地运行但出问题时必须有迹可循。日志策略守护进程所有守护进程sender.py,flight_monitor.py,destination-daemon.py都应配置将日志输出到文件。在macOS的launchdplist中使用StandardOutPath和StandardErrorPath指定日志文件路径。定期检查这些日志文件的大小和错误信息。Cron任务OpenClaw的Cron执行结果通常会在其主日志中体现。确保OpenClaw的日志级别设置得当能够记录Cron任务的开始、结束和错误。数据库审计关键表如outbox.messages设计了status和error字段。定期查询SELECT * FROM messages WHERE statusfailed;可以快速发现发送失败的消息。健康检查进程存活使用ps aux | grep sender.py或launchctl list | grep spratt检查守护进程是否在运行。数据库连接编写一个简单的健康检查脚本尝试连接所有数据库文件并执行一个简单的SELECT 1;查询。API连通性定期如每周运行一个测试脚本调用FlightAware、Google Places等API验证密钥是否有效。常见故障排查消息未发送检查sender.py守护进程是否运行ps aux | grep sender检查Outbox数据库中消息状态sqlite3 ~/.config/spratt/db/outbox.sqlite SELECT id, status, error FROM messages ORDER BY id DESC LIMIT 5;检查iMessage连接手动运行imsg --text Test --contacts 你的手机号看是否能发送。航班监控无通知检查flight_monitor.py守护进程。检查trips.sqlite中是否有状态为active的航班。检查FlightAware API密钥是否过期查看守护进程日志是否有API错误。LLM找不到技能工具确认SKILL.md文件已正确复制到OpenClaw的skills目录。重启OpenClaw服务以重新加载技能。检查OpenClaw日志看是否有技能加载错误。5. 设计模式总结与演进思考经过一年多的生产环境运行Spratt Skills沉淀出一些超越具体代码的通用设计模式这些模式对于构建任何基于LLM的可靠自动化系统都具有参考价值。模式一LLM作为规划器代码作为执行器这是贯穿始终的最高原则。让LLM处理它擅长的模糊性、创造性和语言任务让确定性代码处理它不擅长的调度、持久化和精确操作。任何违背此原则的设计如让LLM轮询API最终都会在可靠性上付出代价。模式二统一、硬编码的数据存储路径数据存储的混乱是系统腐化的开端。一个明确的、所有组件都遵守的数据存放约定是避免“数据幽灵”和“分裂脑”问题的基石。模式三守护进程化长时间运行任务对于需要持续监控或定时触发的任务消息发送、航班查询、目的地监听将其实现为独立的守护进程而不是依赖LLM Cron。守护进程更轻量、更可控、更容易实现复杂的逻辑如自适应轮询、连接状态管理。模式四显式的工具路由与边界定义当系统工具增多时必须为LLM提供一张清晰的“地图”。Tool Routing技能就是一种显式的边界定义它减少了LLM的决策模糊性提高了整个系统的行为一致性。模式五审计追踪与幂等操作所有关键操作如消息发送、状态更新都应在数据库中有记录。更新操作尽量设计为幂等的多次执行效果相同。删除操作非常谨慎优先使用“软删除”标记为取消或无效而非物理删除。未来的演进方向更细粒度的权限与隐私目前所有家庭数据共享一个数据库。未来可能需要引入简单的用户概念和数据隔离特别是对于提醒、消息等个人化内容。跨平台消息支持目前严重依赖iMessage。可以抽象一个“消息发送器”接口轻松接入Telegram、Slack、微信等平台。机器学习增强预测目前的购买周期分析基于简单中位数。可以引入更复杂的模型考虑季节性、促销等因素实现更精准的预测补货。健康与健身数据集成与Apple Health、Strava等数据源连接实现如“根据本周运动量推荐晚餐食谱”的个性化场景。Spratt Skills不是一个完美的、开箱即用的产品而是一个高度定制化的、模块化的工具箱。它的价值在于展示了一种架构范式如何将前沿的LLM能力与经典的、稳健的软件工程实践相结合构建出真正能为日常生活提供持续、可靠价值的智能系统。部署过程可能需要一些调试但一旦各个齿轮咬合运转起来那种“系统在默默为你打点一切”的感觉无疑是数字生活的一种美好形态。