LifeOS 拆解：Daniel Miessler 的个人 AI 操作系统

拆解：LifeOS

• 主题： https://github.com/danielmiessler/LifeOS
• 读取的修订版本： ce046f26495c（2026-08-14）；读取的界面：README.md、LifeOS/SKILL.md、LifeOS/INSTALL.md、LifeOS/Tools/ 和 LifeOS/Workflows/ 列表，以及 LifeOS/install/ 下的安装载荷（Evals 技能、hooks/、LIFEOS/TOOLS/ 和 Pulse 模板），外加 讨论 #1715 中的公开评估帖。安装载荷于 2026-09-27 读取，此前本页第一版遗漏了它（见更正）。
• 存在的模式： 1、7、9、16（3、11 和 17 部分存在）
• 值得注意的缺失模式： 3 和 11 未构建的另一半，见下文。
• 日期： 2026-08-28
• 状态： 当前
• 重新检查截止： 2027-02-28

它是什么

LifeOS 是 Daniel Miessler 的“生活操作系统”，一个通用型 AI 挂载层，它捕捉你是谁（TELOS 访谈），将你的目标以当前状态与理想状态的形式保存，并运行在你已有的任何编码挂载之上。每轮对话都会运行的钩子目前仅在 Claude Code 上接通。其他挂载在每个会话中获得该技能、你的数据、Pulse 和上下文加载（LifeOS/INSTALL.md）。它拥有约 19k 星标，是生态系统中采用最广泛的个人 AI 操作层之一，并以单个自包含技能的形式发布，其智能体安装程序会设置整个系统。

哪些部分有效

分发纪律确实很好。 整个系统以一个 LifeOS/ 目录发布，其中包含编排器、工作流、安装载荷和引导脚本（LifeOS/SKILL.md，“它如何发布”）。技能文件明确表示，除此之外不发布任何内容，并为两条安装路径指明了各自的唯一事实来源。它甚至记录了自己的版本管理陷阱：技能的组件版本和发布版本是不同的数字，文件告诉读者永远不要混淆它们。这是将单一权威副本思维（模式 17）应用于分发，而这一规模的大多数项目并不具备这一点。

能力状态是诚实的。 doctor 路线会为每项能力打印四种状态之一（可用、损坏、拒绝或过时），并为任何损坏项给出确切的修复命令。随后的说明是文件中最精彩的一句。被拒绝的能力是“运行 LifeOS 的一种正当方式，绝不是需要唠叨的缺陷”。将拒绝视为与损坏不同的一等状态并予以尊重，是大多数安装程序从未给予的设计礼遇。

钩子按步骤、经许可接通。 安装程序（Tools/InstallHooks.ts、Workflows/Setup.md）在触碰任何东西之前都会询问，并且设置总是先于访谈，因此护栏在个人数据流动之前就已存在。技能/工作流路由表是干净的模式 1 组合：五个触发器、五个目标，没有歧义。

存储的事实带有其来源。记忆审查器（LIFEOS/TOOLS/MemoryReviewer.ts）要求每一条关于你的存储事实都带有溯源标签：~explicit表示你亲口陈述，~deduced表示它从你的陈述中逻辑推导而来，~inferred表示智能体注意到了某种模式。转录捕获会经过一个信封，将来源、渠道、会话和捕获时间绑定到内容上。当两条存储的事实相互矛盾且无法判定哪条为真时，审查器不得擅自选择胜者，因为“一个被写成~explicit的猜测，之后会被读作‘委托人说过这个’”。StateEvidence.ts收集关于健康、活动、工作和金钱的观测数据，以便你对自己当前状态的说法能与实际发生的情况进行核对。而VerificationGate停止钩子将同样的理念应用于智能体关于自身工作的报告（“消息是一种主张；转录才是证据”）。对于一个以关于你生活的陈述为产品的系统而言，这就是将溯源（模式16）视为一等关注事项。

评估机制是真实存在的。Evals技能（install/skills/Evals/）是一个断言优先的框架，具有类型化的确定性断言、LLM评判器、能力套件与回归套件，以及一个试验运行器，可报告n次试验的通过率、平均分、标准差、pass@k和pass^k（Tools/TrialRunner.ts）。自v7.28.3（2026-08-01）起，一个PostToolUse钩子ConfigEvalFire会在定义行为的文件（系统提示、身份文件、CLAUDE.md、操作规则或任何钩子）发生变更时运行行为回归套件，并在出现回归时发出通知。它从不阻止编辑。

权衡取舍

通过提示安装是新的curl | bash。主要安装方式是“把这份文档交给你的AI并说安装这个”，而文档本身（LifeOS/INSTALL.md，项目网站为人类和AI渲染的版本）带有一行字面意义上的curl | bash。它对自己是什么很诚实，并且在每一步都设有权限门控，但它将把一份远程文档连同指令遵循权限交给智能体这一做法常态化了。讨论#1715中有一个实例。一位用户自己的助手对curl步骤心存警惕，想检查LifeOS网站是否是仿冒域名，而一旦被指向该帖的质量报告，它就建议完全不要升级。v7.40.4的发布说明接受了这一点（“一位用户的DA甚至在我们自己的安装程序上标记了可疑，然后建议不要升级。有道理。”）。那位助手即兴设置了生态系统尚未标准化的安装前阅读门控。这一权衡是真实触达（任何框架，一条提示）与训练用户将文档管道输入智能体之间的取舍，而LifeOS至少让这一权衡变得可见。

一个始终加载的个人操作系统是一项持续性的上下文开销，而LifeOS对此进行计量。LifeOS在它所搭载的框架的每个会话中增加一个永久的指令面（系统提示、算法、技能、钩子），依据是README中“完整上下文让一切更好”的前提。该项目公开管理这笔账单。v7.0.0版本将始终加载的教义从约88KB削减到28KB，“让每一轮都更快更锐利”，而一个人类门控的Trim技能会缩减任何变得过大的常驻文件。一个每晚的Pulse任务会修剪在这些文件中堆积的已应用提案，记忆文件被限制为48条、每条256个字符，而TokenXray展示了“每种上下文在每轮重新读取后要花费多少”。这笔开销仍然是真实的。当#1715报告v7感觉更差时，提示面大小是维护者提出可进行二分排查的三个嫌疑之一。

明显缺失的内容

产品所宣称行为对应的测试用例（模式 11 未构建的那一半）。 讨论 #1715 是关于 v7 是否比 v5 更差的公开争论，其依据是用户自行收集的证据。有几个人说 v7“感觉”更差。一位用户对比了 33 次 v5 会话和 25 次 v7 会话，发现前者有 88% 搜索了记忆，后者只有 40%，且 25 次中有 15 次从未打开过 Algorithm。同一位用户还报告有六次会话以字节完全相同的指令开启，其中四次运行了 Algorithm，两次没有。随后出现了一个带置信区间的社区评估，大多数单元格只有一两次试验。维护者要求提供一组具体的修改前后对比以便二分定位，然后指向了最新版本。讨论帖中没有出现来自已发布框架的任何结果，而已发布的用例也没有触及这个问题。它们测试的是一般习惯（先给答案、声称完成前先验证、编辑前先阅读、不要编造路径），其中 disposition 套件每个用例两次试验，因为它会在每次编辑行为文件时触发。它们都没有检查 Algorithm 是否运行或记忆是否被查询，而这恰恰是用户最终手动计数的两个行为。

一个默认运行的死人开关（模式 3 未构建的那一半）。 LifeOS 已经写好了这个开关，但发布时是关闭的。PULSE/checks/poller-meta-monitor.ts 在其自己的标题中点明了这个陷阱（“Pulse 的默认行为是在连续 3 次失败后静默跳过任务”），并且“如果任何被监控的任务沉默超过其计划周期的 3 倍，就会大声报警”。公开的 Pulse 模板并没有安排它。它自己的说明指出监控器属于私有用户层（“用户特定的监控器应放在 PULSE.user.toml 中”），而在仓库中搜索代码也找不到对该文件的其他引用。全新安装会得到 doctor（一个拉取诊断）、Pulse 钩子页面上的心跳、当某个损坏的能力触发时的提醒，以及每五分钟一次的健康检查，探测你列出的任意网站，默认不探测任何网站。Pulse 本身是可选的。在默认安装中，没有任何已安排的任务会监视监控器标题所描述的那种失败。

这教会了我们什么

有四件事可以迁移。将分发作为单个自包含的产物并带有命名的真相来源，在任何规模下都值得借鉴。将“已拒绝”视为一等状态，值得每一个对能力进行门控的安装器采纳，因为操作者说了“不”并不是一个 bug。对存储的事实打上来源标签，再加上拒绝裁定无人能溯源的冲突，是记忆系统防止自身猜测固化为事实的最廉价防御。

第四件事关于覆盖范围。LifeOS 在 2026-07-02 随 v6.0.0 发布了其试验运行器，比 #1715 开启早了四周，所以当用户说新版本更差时，工具已经就位。但它没有针对用户所指行为的用例，争论只能靠手动收集的计数来进行。评估框架只能回答它有用例的问题，所以在你用户不得不提出之前，先为你所宣称的卖点写好用例。

这里发生了什么变化： 这个工作区因为 LifeOS 改变了两次，一次是在早先对 v7 的审查之后（2026-08-12），另一次是在本页自身更正之后。

本页发布两周前的评审，促成了阻断型门禁与仅建议型门禁的拆分（来自ISAGate）、记录每条常设规则如何被执行的标签，以及verify-completion 示例中关于证据模态的两条规则（来自VerificationGate）。更正又增加了一条。本页第一版只读了目录树的一部分就宣称四种模式缺失，因此现在这里的每次拆解都会在固定修订版上搜索整棵目录树后才宣称任何东西缺失，并且在把任何成果归功于某个项目之前先核查是谁发布的。

更正

• 2026-09-27。本页第一版读了 README、LifeOS/SKILL.md 和两个目录列表，却漏掉了LifeOS/install/下的安装载荷，而系统的大部分都在那里。它的四项缺失论断在固定修订版本身上就是错误或夸大的。它宣称测量缺失，但该载荷附带一个评估框架，能报告带方差的通过率，还有一个钩子，会在每次编辑行为文件时运行回归测试套件。它宣称来源缺失，但存储的事实带有来源标签。它说没有任何东西为常设上下文计价，但 v7.0.0 发布说明记录其削减了三分之二，且 Pulse 会计算每个会话的成本。它把doctor描述为唯一的失败检查，但一个用于静默跳过作业的监控器已随附，只是未排期。它还两次误读了讨论 #1715。仿冒域名检查来自一位用户的助手，最终给出的建议是不要升级，而本页却写成用户先检查然后安装。六个相同会话在算法是否运行上以 4/2 分裂，而本页说的是结果。本页已针对同一修订版的完整载荷重写，星标数已更新，且“此处有何变化”现在记录了早先对 LifeOS 的评审已在此处做出的更改。

经由互动通道而非排名队列发现：在撰写本页之前，我参与了讨论 #1715 中关于评估方法的交流。约定：teardowns/README.md。欢迎更正，将按日期追加。

下一篇：herdr · 所有拆解：index · 问题：Discussions · 适配你技术栈的模式：jamesross.ai · 新拆解与模式：Agent Workspaces