一、 业务痛点与系统定位
在现代特色民宿与精品酒店的日常经营中，多渠道直销与分销是提升入住率的核心手段。经营者通常需要同时维护：
- 主流 OTA 平台：美团民宿/酒店商家后台（eBooking）、携程商家后台（Ctrip eBooking）、飞猪度假商家中心（Fliggy）；
- 第三方集中管理系统：如国内领先的民宿行业 SaaS“订单来了（DDL）”；
- 本地私有化系统：基于 Cloudstay 自主研发的内部 PMS 系统。
然而，这种多系统并行的常态在实际生产环境中引发了极其严峻的工程难题：
| |
为了彻底终结“多渠道对单繁琐、Cookie 频死掉线、库存超卖风险与暴力脚本失控”的困局，我主导设计并研发了 Cloudstay AIPMS。系统定位于面向多渠道 OTA 与 PMS 的原生桌面控制中枢与智能自动化工作台，底层基于 Electron 43 + React 19 + TypeScript + Vite 6 + Node.js 24+ 架构构建。
二、 桌面端工作台系统界面视界
系统主界面采用响应式分区与沉浸式工作坞设计：
- 左侧快速导航坞（Dock）：无缝切换 AI 工作台、本地 Cloudstay PMS、三渠道 AI 浏览器、订单来了独立工作区、运行日志 与 全局安全设置；
- 中央交互区与热门操作卡片：提供高频业务意图建议（如“查询今天待处理订单”、“查看最近经营数据”、“检查未回复评价”）；
- 安全受控输入栏：醒目标注当前操作渠道（如美团/携程）以及“只读计划”安全防护盾牌，重要写操作必须通过明确的人工确认卡，右侧状态指示灯实时上报底层模型引擎连通状态。
三、 核心架构：会话保险库（Session Vault）与多渠道保活探针
在 Electron 桌面环境中集成多个复杂的外部商业 Web 系统，最大的挑战是：“如何让各平台的登录态长期持久化，而不让经营者每次打开软件都重新扫码或输入短信验证码？”
Chromium 默认将站点派发的会话 Cookie（Session Cookie）保留在内存中，在调用 app.exit(0) 时直接销毁。常规浏览器插件和简单脚本根本无法解决重启丢失登录态的问题。
1. 基于 Windows DPAPI 的加密会话保险库（Session Vault）
Cloudstay AIPMS 构建了专有的会话保险库子系统：
| |
为了彻底防止被 OTA 平台识别为异常爬虫客户端，系统还在网络层做了关键防指纹处理：
- 动态精简 User-Agent：只剔除
Electron/x.y.z敏感特征字段，保留完整原生 Chrome 版本号，既避免被平台风控拦截，又防止因锁定旧版本 UA 撞上平台的“浏览器版本过低”拦截页； - 存储硬契约：将
persist:cloudstay-aipms-pms、persist:cloudstay-aipms-meituan等分区视为不可变数据结构，通过单元测试硬编码锁定，防止升级时会话被意外清空。
2. 四态会话探针与低频无感心跳（Keepalive）
针对 OTA 平台服务端的空闲超时机制，系统设计了精细的四态探测引擎与页面内轻量心跳：
| 会话状态 | 状态定义 | 系统应对策略 |
|---|---|---|
fresh | 探针确认会话处于安全有效状态 | 界面显示绿色常亮指示灯，允许执行库存读取与预备流水线。 |
stale | 网络临时微抖或页面暂时未响应 | 绝不粗暴判定为失效！ 采用指数退避算法逐步拉大探测间隔（最高 60 分钟），杜绝无意义的弹窗误报。 |
expired | 明确检测到被重定向至登录页 | 红色预警，自动阻断后续库存写入，并在界面直接提供「一键打开登录页」引导人工复登。 |
unknown | 启动初始态或尚未探测 | 启动后后台排队依次触发首轮检测。 |
- 无感心跳机制：每隔 10~15 分钟（加入随机抖动），在页面内向当前平台自身发起一次同源只读
GET请求。真实带 Cookie 的请求能够无声刷新服务端的 Session 活跃计时器，不改动 DOM、不刷新页面、不干扰用户当前正在进行的任何手动操作。
四、 双写入目标流水线：Dual Order Sink
当系统从各 OTA 渠道的采集侧（自动轮询器，默认 60 秒间隔）捕获到新订单或订单变更事件后，事件会被推送至核心的 双写入目标流水线（Dual Order Sink）：
| |
- 全分支覆盖：流水线完整适配了新增订单、用户主动取消、平台改单换房、以及通过人工录入单冲抵超卖等高难度边缘场景；
- 防伪回执与写后读回：拒绝将“接口返回 200”或“页面弹窗关闭”视作成功。每次写入操作执行后，流水线必须发起独立的读回请求，确认订单编号与房型在目标系统界面中真实可见，才向系统账本上报
applied状态。
五、 AI 工作台与 Codex 集成：绝对的“安全红线”机制
在涉及酒店房态与真金白银的经营场景下，纯粹由 AI Agent 全自动点击修改房量是不可接受的巨大风险。Cloudstay AIPMS 确立了严格的 “只读计划 -> 预览卡片 -> 人工确认 -> 审计落库 -> 独立读回” 安全红线闭环：
| |
1. Codex 本地配置的绝对隔离
- AI 工作台后端的 Codex 引擎不依赖环境变量乱窜的外部配置，主进程只以项目根目录的
luna.config.toml作为唯一权威标准； - 启动时在系统临时目录建立硬链接作为原生
config.toml，通过codex app-server --listen stdio://标准输入输出直接与主进程建立高性能 RPC 通道，杜绝 Token 复制泄露与配置漂移。
2. 严格的 Phase 1 写入边界
- 当前写入严格限制在
1 × 1 × 1范围（单门店、单房型、单日期）； - 精细区分三种原子操作：
set_inventory：仅调整实际剩余房量，预留房量和房态开关严格保持不变；close_room：仅使用原生单日房态开关关房，严禁以“库存设为 0”伪装关房，并强制校验当前预留房为 0，防止误关已预留房间；open_room：反向开启房态开关。
六、 全链路工程验证与测试指标
为了确保系统在高并发、网络抖动及复杂平台环境下的绝对稳定性，项目构建了完备的自动化测试体系：
| |
- 通道隔离性：通过两个完全独立的 Node 进程与双内存 PMS 实例，验证美团与飞猪在并发事件下的数据零串扰；
- 订单汇聚套件：
test/ddl-order-sink.test.js与test/order-e2e-verifier.test.js共 34 个深度端到端测试用例全部通过； - 合规与隐私审计：全系统所有操作日志均采用字段白名单制，日志中绝不包含任何用户密码、Bearer Token、Cookie 或未脱敏旅客敏感信息。
七、 总结
Cloudstay AIPMS 的实践证明：在外部 SaaS 平台高度碎片化、传统 API 接口封闭且多方博弈的商业环境下，“以现代化 Electron 桌面为宿主、以硬件加密会话保险库解决持久化、以双写入目标保证业务对冲、以受控 AI Agent 严格绑定只读计划与人工确认”，是构建企业级高可靠自动化系统的最优架构范式。