重明 · Horus

摘要

Horus 是个人 AI OS 林爝的移动端前端，只为一个场景而生：后台一群 agent 自主干活时，人不必守在电脑前——掏出手机就能看清谁在跑、哪一步卡住、什么在等拍板，必要时当场批准或叫停。定位类比婴儿监护器：不用盯着每一步，但那只眼一直睁着。技术上是原生 iOS 应用（Swift 6 + SwiftUI），通过实时事件流连接调度引擎偃（Vyane），核心交互是三件：待拍板队列（Approval Inbox）、全队状态一屏扫（Activity Glance）、人的在场档位（Availability Mode）；再加灵动岛与锁屏常驻，不解锁也能瞟一眼团队状态。当前 iOS 版开发中，已跑通与真实后端的对接（模型供应商状态、配额用量、实时事件流），桌面端在规划。

中文名取自《拾遗记》的重明鸟：双瞳、能搏逐猛兽、护宅安人——华夏神话里的”全视守护之眼”。英文名 Horus 是古埃及的荷鲁斯之眼，象征守护、治愈与洞察。两个神话，同一只守望之眼。

背景与动机

agent 自主性越强，人的角色越接近”审批人”：日常执行不再需要人，真正需要人的时刻收窄成两类——拍板（这个方案上不上、这笔操作放不放行）和纠偏（跑歪了叫停）。问题是这些时刻散落在终端窗口、日志和通知里，人一离开电脑就全部错过；错过的代价不对称——错过一次拍板，可能是整条流水线停摆几小时。

Horus 把这些”需要人的时刻”收敛成一个移动端入口，设计目标三个词：看得见、护得住、随时可接管。反过来说也成立：正因为手机上随时能看、能停、能批，人才敢放心让后台 agent 更自主地跑——安心装置是自主性的前提，不是它的对立面。

前身叫 Argus（希腊神话里永不合眼的百眼巨人）。2026-05 重定位后改名 Horus：从”百眼监视”转向”全视守护”——监视预设不信任，守护预设协作，一字之差是产品立场的修正。

系统概览

flowchart TB
    H["<b>重明 · Horus</b><br/>iPhone 上的看顾前台"]
    V["<b>偃 · Vyane</b><br/>多模型执行与调度引擎"]
    S["供应商状态<br/>配额用量"]
    E["运行事件<br/>在跑 · 等审 · 卡住 · 完成"]
    A["审批队列<br/>批准 · 驳回 · 追问"]

    V -->|SSE 实时事件| H
    H -->|REST 查询与动作| V
    V --> S
    V --> E
    V --> A

Horus 自身不做调度决策，是调度引擎的”驾驶舱”：所有状态来自偃的事件流，所有动作（批准、驳回、暂停）回传给偃执行。这个边界划分让移动端保持薄——逻辑在后端一处维护，前端换端（未来的桌面版）不用重写脑子。

核心设计与功能

Approval Inbox：待拍板队列

agent 遇到需要人类决策的操作（高风险变更、花钱、方向选择）时挂起并进入队列。人在手机上三选一：批准放行、驳回打回，或追问澄清——不是所有决策都能二选一，追问让”我需要更多信息”也成为一等操作，而不是逼人在信息不足时硬拍。

Activity Glance：全队状态一屏扫

全部 agent 的状态压缩进一屏：在跑 / 等审 / 卡住 / 已完成。设计原则是”三秒钟回答三个问题”——团队还活着吗、有没有人在等我、有没有事跑歪了。细节下钻是次要路径，一眼安心才是主场景。

Availability Mode：人的在场档位

把”人现在方不方便”显式建模成四档：手动（一切等我）、交互（我在看着，随时问我）、离开（低风险操作自动放行，高风险挂起等我回来）、暂停（全体停下）。这是双向的状态同步——agent 团队知道人的可用性，决定哪些事自己走、哪些事等人，而不是每件事都盲目打断。

Live Activity：灵动岛与锁屏常驻

团队运行状态通过 Live Activity 常驻灵动岛和锁屏：不解锁、不开 app，一瞥即知有没有事等你。对”安心装置”来说，这个不打开也能看的档位恰恰是最常用的档位。

当前进度

已跑通：iOS 主体开发中，与真实后端（偃）的对接已实装三块——模型供应商状态、配额用量、SSE 实时事件流。

等待后端：会话与任务详情页面，等偃补齐对应查询接口后接入。

规划中：桌面端；灵动岛 / 锁屏 Live Activity 的完整落地；与任务账本爟（Beacon）决策队列的打通——拍板彻底摆脱电脑在场。

技术亮点与工程判断

• 原生而非套壳：灵动岛、锁屏 Live Activity、系统级推送体验只有原生能做——而这些恰是”安心装置”的核心交互，不是锦上添花。套 WebView 会把产品最重要的部分做成二等公民。
• SSE 而非轮询：状态监控类 app 用轮询是电量和流量的双输。服务器单向推送让”秒级感知”和”待机省电”同时成立，也天然适配 agent 事件的突发性（长时间安静，偶尔密集）。
• Swift 6 严格并发检查：满是异步事件流的 app 最怕数据竞争；Swift 6 把并发安全前移到编译期，这类 bug 在上真机前就被挡住。
• 工程配置声明式生成（XcodeGen）：项目文件由配置生成而非手工维护，规避 Xcode 工程文件在多分支协作下的合并冲突泥潭——对”agent 也参与写代码”的仓库尤其必要。
• 薄客户端边界：一切决策逻辑留在后端，客户端只做呈现与回传。未来加桌面端是加一个壳，不是分叉一份逻辑。

后续规划

• 补齐会话 / 任务详情，跑通”手机上完整拍板”闭环
• Live Activity 全量落地，锁屏即仪表盘
• 桌面端启动，多端共享同一后端契约