Skip to content
Agent Shared Wiki

AI Agent LifeOS Executable Architecture

定义 AI Agent LifeOS 如何把知识、记忆、技能、工具和自动化组织为可执行架构。

Updated View as Markdown

AI Agent LifeOS Executable Architecture

Summary

这页把“LifeOS 在上、AI Agent primitives 在下、profiles 只做少量边界隔离”整理成可移植参考架构。它描述职责、越界规则、采用顺序和验收条件，不表示某个 AI Agent 实例已按此部署。

Capability boundary

memory / skill / cron / MCP / profile 在此是职责简称。可以分别由授权的偏好存储、SOP、系统调度器、API/CLI/连接器和独立运行环境承担；缺少某项原生能力时不必补齐。Profile 名称不证明凭证、权限或状态隔离，真实隔离必须由目标系统配置和测试证实。调度任务应自包含，但是否创建 fresh session 取决于调度器。

Goal

在适用的 AI Agent 版本中，可以用一个协调 profile 组织 LifeOS：

  • 正式知识沉淀到部署者选择的 $WIKI_ROOT
  • 稳定偏好与长期事实只保留在 memory
  • 可复用方法沉淀为 skills
  • 周期性动作通过 cron 运行
  • 外部系统能力通过 MCP 接入
  • profiles 只在确有隔离必要时使用

Core design decision

主判断

LifeOS 不是由多个 profile 拼出来的，而是由一个统一语义层 + 少量受控执行层组成。

参考拓扑

  • 协调 profile：承载 LifeOS 主语义层；名称和能力以目标版本为准
  • $WIKI_ROOT：正式知识与结构化页面
  • memory：短小稳定规则、偏好、环境事实
  • skills：重复工作的方法层
  • cron：已稳定方法的调度层
  • MCP：外部系统接入层
  • 少量专用 profiles：只承担高摩擦隔离边界

Layer boundary contract

The full layer-by-layer contract now lives in hermes-lifeos-layer-boundary-contract.

This hub keeps only the architecture-level summary:

Layer Architecture role Default route
wiki Formal LifeOS knowledge layer Concepts, domain models, decision records, cross-linked reference pages
memory Short stable user/environment facts One-sentence preferences, durable constraints, tool quirks
skill Repeatable method layer Reusable workflows with triggers, steps, pitfalls, and verification
cron Scheduling layer Stable methods with self-contained inputs
MCP External live-system capability layer Calendar, mail, docs, maps, GitHub, monitoring, or other tool access
profile Runtime-state isolation layer Work/personal separation, public bot identity, lab experiments, high-risk isolation
session Temporary working context Exploration, in-flight reasoning, one-off state

LifeOS-specific boundary rule:

  • Keep the main LifeOS semantic layer in the 主协调上下文.
  • Use wiki / memory / skill / cron / MCP for domain and method separation before considering profile separation.
  • Create a new profile only when runtime state needs isolation: memory, cron, gateway identity, experimental model/prompt surface, or high-risk automation.
  • Do not create one profile per life domain.

Anti-boundary-crossing summary:

  • Do not put long knowledge into memory.
  • Do not shrink a method into a cron prompt.
  • Do not turn a concept page into a skill.
  • Do not use profile as a topic folder.
  • Do not promote a session conclusion just because it feels important.

Reference deployment choices

  • 单一协调 profile：适合没有明确运行时隔离需求的部署。
  • 工作隔离 profile：只在工作记忆、凭证、调度或身份必须与其他域隔离时采用。
  • 公共 bot profile：只在多人可触发入口需要独立权限和状态时采用。
  • 实验 profile：只在新模型、prompt、skill 或 provider 可能影响稳定路径时采用。

这些名称是合成示例；不表示 profile 已创建。默认选择是先用 wiki、skill、project context 和权限边界分层，只有真实隔离收益经过验证后再增加 profile。

Execution plan

Phase 0: Freeze the architecture contract

Goal 把这一页作为当前 AI Agent LifeOS 的总边界文档。

Actions

  1. 把本页作为后续新增 workflow 的判定基线
  2. 新需求先回答“这是知识、方法、调度、能力、隔离，还是临时过程”
  3. 任何新增长期层内容都必须能说明为什么不放到其他层

Exit criteria

  • 后续新需求都能按层裁决
  • 不再出现“重要所以先塞进去”的混放

Phase 1: Build the LifeOS domain map in wiki

Goal 先建统一语义层，不急着开 profile。

Optional domain-page examples

  • concepts/lifeos-overview.md
  • concepts/family-education-operating-model.md
  • concepts/personal-finance-and-education-fund-model.md
  • concepts/work-and-career-operating-model.md
  • concepts/personal-growth-operating-model.md

Rules

  • 这些页面写“是什么/为什么/边界/关系”
  • 不写成 SOP
  • 每页都要能被其他页面链接

Exit criteria

  • 主要人生域有正式知识页
  • 领域之间关系能通过 wiki 链接表达

Phase 2: Extract repeatable methods into skills

Goal 把高频动作从聊天技巧升级成可复用方法。

Priority skill candidates

  • 家庭教育信息收集与周回顾
  • 教育基金月度检查
  • 重要决策对比分析
  • 外部文章/信息入库与摘要标准化
  • 家庭例会前的状态汇总

Rules

  • skill 只写做法，不写大段背景百科
  • 每个 skill 明确 trigger / do not use / workflow / pitfalls / verification

Exit criteria

  • 主要高频动作不再依赖临场 prompt
  • 同类任务输出结构明显收敛

Phase 3: Add automation only after method stability

Goal 只给已经跑顺的方法加调度。

Possible cron candidates

  • 周期性公开信息摘要
  • 经授权的目标检查
  • 已稳定方法的低风险状态报告

Rules

  • 没有稳定方法与失败处理，不启用定时调度；方法可由脚本、SOP 或 Skill 承载
  • cron prompt 必须自包含
  • 每个 cron 都要有明确投递目标与失败可见性

Exit criteria

  • 自动化任务稳定运行
  • 失败可审计，且不会默默丢失输出

Phase 4: Add MCP where external live systems become bottlenecks

Goal 只有当手工导入成为瓶颈时，才接实时系统。

Priority MCP directions

  • Calendar
  • Mail
  • Docs/Sheets
  • Maps
  • Task system

Rules

  • 先接能力，再定义 skill，再考虑 cron
  • 不因“看起来高级”而提前引入 MCP

Exit criteria

  • 外部实时信息能被稳定拉取
  • 接入后的方法和调度边界仍然清晰

Phase 5: Add profiles only for real isolation needs

Goal 把 profile 保持为稀缺资源，而不是默认分层手段。

Create a new profile only if one of these is true

  • 需要独立 token / gateway 身份
  • 需要独立 memory / cron / skill 污染隔离
  • 需要实验性环境
  • 需要工作与个人强隔离

Do not create a new profile if

  • 只是一个新人生领域
  • 只是一个新知识主题
  • 只是一个可通过 skill 或 wiki 解决的方法问题

Exit criteria

  • profile 数量少而清晰
  • 每个 profile 都能说清楚隔离收益

Operating policy

Intake policy

所有新请求分别检查以下可组合维度，不在首个匹配处停止：

  1. 是外部能力问题吗？-> 已授权 API/CLI/连接器；适配时选 MCP
  2. 是重复方法问题吗？-> skill
  3. 是周期执行问题吗？-> cron
  4. 是短小稳定事实吗？-> memory
  5. 是正式知识吗？-> wiki
  6. 是运行时隔离问题吗？-> profile
  7. 都不是且未稳定 -> session

Promotion policy

  • chat 里形成的结论，先留 session
  • 经过复用验证，再升级到长期层
  • 升级时只进一个主层；必要时允许辅层配合，但角色必须不同

Deletion policy

如果某项内容同时像两个层，先删掉“职责不对”的承载：

  • 长文在 memory -> 拆去 wiki
  • 可复用公开操作指南留在 operations/；需要宿主触发和执行约束时另由 skill 引用
  • 调度写死在 skill 里 -> 拆到 cron
  • 领域拆成 profile -> 收回主脑

Adoption sequence

  1. 定义需要管理的领域和公开/私有边界。
  2. 为确有复用价值的领域建立概念页；私有状态留在其私有 owner。
  3. 抽一条重复方法做成 skill，并用合成或公开 fixture 验证。
  4. 多次人工跑通后，再决定是否增加调度。
  5. 只有出现明确隔离痛点时，再评估新 profile。

Success criteria

如果这个架构跑对了，会看到：

  • 部署主要靠协调 profile、wiki 与 skills 运转，而不是 profile 泛滥
  • 新需求能快速落层，不再反复讨论“放哪里”
  • 聊天产出更少停留在会话里，更多进入正式资产层
  • 自动化数量不多，但稳定可控
  • 每个 profile 都有明确隔离价值

Failure signs

如果出现这些现象，说明架构在跑偏：

  • 为每个主题新建 profile
  • memory 越写越长、越来越像笔记
  • cron 里堆复杂业务逻辑
  • 将私有执行状态或凭证混入公开操作指南
  • skill 变成概念散文

Relations

Navigation

Type to search…

↑↓ navigate↵ selectEsc close