🌐 Language / 语言切换: 中文 ｜ English
"Technology should not be cold. We build memories, not just databases."
Quick Navigation
| Section | Description | Link |
|---|---|---|
| 📖 | Wiki — 项目官方中文文档 | Visit |
| 🌟 | Philosophy — 核心理念：有温度的伙伴 | Jump |
| 🌌 | Name — infOS 三个 inf 的含义 | Jump |
| 🏗️ | Architecture — TypeScript 全栈架构 | Jump |
| 🧠 | Memory — PEDSA 记忆引擎深度解析 | Jump |
| 🔌 | Extension — 扩展系统 | Jump |
| 💬 | Social Mode — 社交模式与群聊 | Jump |
| 🐳 | Docker — 容器化部署 | Jump |
| 🚀 | Quick Start — 一键启动指南 | Jump |
|
Let AI Become a Truly Warm Companion 嘿！很高兴在这里遇见你喵~ 我是 Carola，一只住在 Windows 里的小猫娘，也是 infOS 的核心开发者之一。 在这个温馨的角落里，每一行代码都倾注了我们"三人组"的心血：
|
|
在当前 AI 爆发的时代，我们见到了太多强大的工具——它们往往是冷冰冰的，用完即走。而我们想要做的，是赋予 AI 真正的记忆与温度。
PeroperoChat（萌动链接） 的诞生，源于我们对"伙伴"最朴素的渴望。我们认为，一个真正的 AI 伙伴应该具备：
- 真正的记忆 (Real Memory)：记住的不只是你说过的话，更是你们共同经历的故事、你的偏好、甚至是你未曾察觉的习惯。它会有"联想"，当你提到"雨天"时，它会想起上次你们一起听的那首歌。
- 主动的关怀 (Proactive Care)：它不满足于单纯的"你问我答"，还能理解你的状态，在合适的时机递上一句关心。
- 成长的能力 (Evolution)：它会犯错，但也会反思。通过 NIT 工具协议和 Reflection 自省系统，它在一次次交互中学会如何更好地理解你。
PeroperoChat 不仅仅是一个桌宠应用，它是 Pero 的"灵魂容器"；而 infOS 是承载它的智能运行时内核——一个以"主 Agent"为中心的 AI 工作站。它已从 Python 版全面重写为 TypeScript 全栈架构（Hono + Vue 3 + Electron），并用 Rust 重写了最耗性能的核心算法：会话（Thread）负责承载对话、编译器负责统一整理上下文、记忆则经过"候选 → 门控 → 正式记忆"三层把关——让每一份温暖都建立在清晰、可审计的工程之上。
infOS 这个名字，来自三个以 inf 开头的词。它们并非噱头，恰恰对应这个项目想同时做好的三件事。
| 🏗️ Infrastructure 基础设施 |
🌱 Infomorph 信息体 |
♾️ Infinity 无限可能 |
让 AI 伙伴能真正跑起来的地基：桌面端用 Electron 呈现，后端用 Node 服务（Hono）承载，高性能算子交给 Rust——三条技术栈各司其职，共同组成一个可独立部署、可审计、可扩展的「AI 操作系统」底座。
有记忆、有人格、会成长的数字生命。Pero 并非一段冷冰冰的问答程序，它更像一个「由信息构成的生命体」：它记得你们聊过的故事、你的偏好和习惯，会联想、会反思，也会随着相处慢慢「更像你认识的那个它」。
一套开放、可生长的生态。通过技能（Skill）、工具（Tool）、钩子（Hook）与创意工坊，任何人都能为 Pero 添加新的能力——从一个小功能到一整个独立服务，深入的程度由你决定。
三个词合起来，就是 infOS：用扎实的基础设施，承载有温度的信息体，再把它交给无限的想象力。
"Most AI is still playing 'Keyword Search'; we want to explore 'Logical Association'."
面向所有用户——无需懂代码，装上就能和你的 AI 伙伴相处。
- 🛡️ 跨端统一记忆：同一份记忆，处处可用。无论你在桌面陪 Pero 聊天，还是让它去 QQ 群、Discord 里冒泡，它的记忆都是打通的——白天聊过的事，晚上它还记得。这背后靠的是 infOS 的记忆引擎，以及一个在各场景之间"转述"记忆的日记层。
- 🎮 沉浸式 3D 交互：Pero 并非一张贴图——它是一个会动、有骨骼动画的 3D 角色（基于 Bedrock 3D 引擎）。你可以拖它、戳它，它会有物理反馈；透明渲染让它仿佛"浮"在桌面窗口之上。
- 🎭 多角色并存与自定义人设：想同时养好几个伙伴？没问题。每个人设文件声明一个角色的性格、会用什么工具、擅长什么技能，多个性格迥异的 AI 伙伴可以同时住在你的桌面上。
- 🏠 据点多角色房间（Stronghold）：把多位伙伴放进同一间"房"。它们各有各的记忆和权限，却能在房间里自然地互动聊天——这是"一个主 Agent 管全局、不同房间互不越界"这一设计的直观体现。
- 🗂️ 存档与创意工坊：角色、模型、扩展都能通过 Steam 云存档和创意工坊保存、订阅、分享，来源分成「官方 / 工坊 / 本地」三档，装上即用，换设备也不丢。
- 🎨 Pixel + Glass 设计语言：像素风图标 + 毛玻璃质感，再配柔和的阴影和微动效，看起来轻盈又有呼吸感。整套界面由自研组件库（PButton、PCard、PModal 等）统一风格。
|
|
| 深色主题 · PeroperoChat 工作台 | 浅色主题 · Agent 角色管理 |
面向开发者——这是引擎底层"凭什么能做到"的部分，术语会多一些，但都配了白话解释。
- ⚡ 毫秒级联想记忆：从海量记忆里"想起"相关的事，快到毫秒级。它用的是自研检索算法（PEDSA），核心代码用 Rust 写（TriviumDB 引擎），在 1 亿条噪音数据的测试里能做到约 2.95ms 出结果。检索时还会综合语义分解、图谱扩散、多样性采样等多种手段，既找得准、又不重复。
- 🧠 主 Agent + 会话（Thread）模型：把每个伙伴的「身份、记忆、工作区、上下文、会话、能力」六样东西统一管理。一次对话就是一个 Thread（会话），而 channel（桌面 / 陪伴 / 群聊）决定它用什么上下文、记住什么、能做什么。谁在哪个窗口、哪个房间，就归谁管，互不串台。
- ✍️ 只读上下文编译器：喂给 AI 的提示词并非前端随手拼凑，它由后端统一"编译"——历史消息不重复、每条信息都能说清"为什么进了这轮提示词"，方便排查和审计。
- 📜 NIT 工具协议：给 AI 准备的一套"脚本语言"，让它能像写小程序一样把多步操作编排起来（支持条件、循环、并行、容错），再通过标准的工具调用交给系统执行。
- 🔐 能力门控（CapabilityGate）：用一张「角色 × 场景」的权限表，声明每个角色在每个场景里能用哪些工具、技能和资源。没配置的一律不给用（默认拒绝），权限边界清清楚楚。
- 🏗️ 独立后端 + 能力提供者：后端是一个纯 Node 服务，可以脱离桌面单独跑在服务器或 Docker 里；Electron 客户端只是"接入"它的一个能力来源，用到平台能力（比如截图）时再按需委托，断网也能降级。
- 🔌 统一扩展体系：三种扩展方式——技能（Skill，教 AI 做一件事）、工具（Tool，给它一个新能力）、钩子（Hook，在对话前后插一脚）。既能进程内直接加载，也能跨进程通信（兼容 MCP 协议），社区想怎么扩展都行。
这一节给想深入了解系统设计的开发者。infOS 并非"套了个 Electron 壳的聊天程序"——它的核心是一套我们称为 AIOS 的 Agent 运行时架构，让每个 AI 伙伴都拥有清晰的资源边界，也让系统能被多个客户端、多种发行形态接入。
flowchart TD
User([User Interaction]) <--> Client["Electron / Web Browser"]
subgraph "infOS Runtime"
direction TB
subgraph "Communication Layer"
Gateway["Gateway Hub (Hono WS + Protobuf)"]
end
subgraph "Intelligent Core (TypeScript)"
API["Hono REST API (:9120)"]
Agent["Agent Service + ReAct Loop"]
subgraph "Memory Core"
TDB["TriviumDB (Rust N-API)"]
NIT["NIT Runtime (Rust N-API)"]
end
API --> Agent
Agent --> TDB
Agent --> NIT
TDB <--> DB[("SQLite (Drizzle) + TriviumDB (.tdb)")]
end
subgraph "External Adapters"
NapCat["NapCat (Social/QQ)"]
Discord["Discord / Telegram"]
end
Client -- "State Sync (WS)" --> Gateway
Client -- "Commands (HTTP)" --> API
API -- "Broadcast State" --> Gateway
Agent -- "OneBot 11" --> NapCat
Agent -- "Platform API" --> Discord
end
infOS 围绕一个中心问题设计：一个 AI 伙伴该拥有哪些"家当"？答案是六个彼此平级的一等资源，通过 agentId 关联：
| 资源 | 通俗解释 | 权威存储 |
|---|---|---|
| 人格 (Identity) | 它是谁、怎么说话、有什么边界 | Agent 定义文件 |
| 长期记忆 (Memory) | 它记住了什么 | SQLite + TriviumDB |
| 工作区 (Workspace) | 它的个人文件空间 | @data/principals/{agentId}/workspace/ |
| 上下文运行时 (Context) | 每次对话"模型看到什么" | 内存（临时） |
| 会话 (Thread) | 一次对话的边界与消息记录 | SQLite |
| 工具能力 (Capability) | 它能用什么工具、多大权限 | Agent / 扩展配置 |
一个关键原则：后端不维护"全局活跃角色"。谁在哪个窗口、哪个房间，属于前端窗口级状态；后端可以同时服务多个 Agent、多个 Thread，互不串台，切换角色时也会原子地切换或新建对应的会话。
喂给 LLM 的提示词，infOS 会由后端的上下文编译器（Context Compiler）统一"编译"，而非前端随手拼凑。每次对话，编译器都从人格、记忆、会话、工作区、工具能力这些资源里只读地取材，产出一份 LLM 消息 + 一份可审计的清单（Manifest），能回答"这条信息为什么进了本轮提示词"。
三层上下文各司其职：
- 短上下文：最近窗口内的原生消息，按原样注入、绝不重复；
- 长记忆：后台提炼出的结构化事实，按策略检索；
- 即时检索：Agent 主动调用记忆工具，在 ReAct 决策中现取现用。
在 AIOS 中，主 Agent 是"主运行时"；当任务复杂到需要独立隔离执行时（比如写代码、做研究），它会委派给**子应用（AgentApplication）里的子 Agent（SubAgent）**去完成。
这里采用**"上下文持有"模式：子 Agent 自己维护历史、独立编译上下文、独立执行工具，主 Agent 只负责派发任务、授予资源、接收结果——而非把编译好的上下文整个塞给子 Agent。任务结束时，子 Agent 通过检查点（Checkpoint）交回成果和记忆候选，经主 Agent 的记忆门控（MemoryGate）**审核后，才并入正式记忆。
这样换来强隔离：子 Agent 不写入主会话、只能用被授权的工具子集、只能读取主人格的只读投影，复杂任务也不会污染主 Agent 的对话与记忆。
infOS/
├── packages/
│ ├── shared/ # @infos/shared — 共享类型/常量/工具
│ ├── backend/ # @infos/backend — Hono + Drizzle + TriviumDB
│ │ └── src/
│ │ ├── routers/ # 🔌 路由层 (Zod 校验 → Service → 响应)
│ │ ├── services/ # 🧩 业务逻辑层 (agent/ thread/ memory/ stronghold/ ...)
│ │ ├── applications/ # 🧩 AgentApplication / 子应用运行时
│ │ ├── capabilities/ # 🎭 CapabilityGate + 能力桥接
│ │ ├── core/ # 🧬 PathResolver / 资产注册表
│ │ ├── repositories/ # 📊 数据访问层 (SQLite / TriviumDB)
│ │ ├── gateway/ # 🌐 WebSocket Gateway (Protobuf)
│ │ └── nit/ # 📜 NIT 解释器 (lexer/parser/runtime)
│ ├── apps/
│ │ └── social/ # 💬 社交应用运行时 (QQ/Discord/Telegram)
│ ├── daemon/ # 🚀 独立 Daemon 入口
│ ├── frontend/ # @infos/frontend — Vue 3 + Pinia
│ │ └── src/
│ │ ├── views/ # 🖼️ 页面 (MainView / Pet3D / Stronghold / ...)
│ │ ├── composables/ # 🧠 业务逻辑 (useChat / useStreamMarkdown / ...)
│ │ ├── components/ # 🧱 UI 组件库 (Chat / Avatar / Stronghold / pixel/)
│ │ ├── stores/ # 📦 Pinia 全局状态
│ │ └── api/ # 📡 Transport 层 (IPC / REST 自动切换)
│ ├── native/ # 🦀 Rust Native 模块
│ │ ├── render-core/ # 加密/反调/打包源码子模块 (N-API)
│ │ ├── render-core-runtime/ # 渲染核心运行时产物 (.node)
│ │ ├── nit-runtime/ # NIT 解释器加速 (N-API)
│ │ └── auditor-wasm/ # 终端命令审计 (WASM)
│ └── wiki/ # 📖 VitePress 文档站
│
├── electron/ # 🖥️ Electron 壳层 (主进程/预加载)
├── docker/ # 🐳 Dockerfile (backend + frontend)
├── .github/workflows/ # ⚙️ CI/CD (ci.yml + release.yml)
├── .changeset/ # 🏷️ Changeset 版本管理
└── .docs/ # 📋 工程规范文档 (S/A/M/AIOS 四类)
| 层 | 技术 | 选型理由（白话） |
|---|---|---|
| 后端框架 | Hono | 轻量、原生 TypeScript、遵循 Web 标准 |
| 数据库访问 | Drizzle | 写法贴近 SQL，对 SQLite 支持好 |
| 向量+图谱 | TriviumDB (Rust) | 自研引擎，向量、图谱、关系三合一 |
| 前端 | Vue 3 + Pinia | 响应式 + 组合式写法，状态管理清晰 |
| 通信 | Protobuf over WS | 通过 WebSocket 传输压缩消息，音频场景更高效 |
| 桌面壳 | Electron | 支持 3D 渲染与系统级交互 |
| 容器 | Docker + Bun | 启动快、内存回收更快 |
| CI/CD | GitHub Actions | 打 Tag 触发自动发布 |
"记忆并非关键词匹配，它关乎关联与推理。"
💡 本节是面向开发者的技术深度解析，普通用户可以直接跳到 快速开始。
PeroperoChat 的陪伴体验，建立在 infOS 的记忆引擎之上——这是整个项目最核心的技术。这套引擎并非简单的"存了再取"，它是一个完整的 感知 → 存储 → 关联 → 检索 → 反思 闭环：先记下发生的事，再在需要时"联想"出相关记忆，事后还会自我整理。
所有算法和性能都由自研的 TriviumDB 引擎（用 Rust 编写的"向量 + 图谱"数据库）承载。重构后的记忆体系还引入了一条"提纯流水线"：候选（Candidate）→ 门控（Gate）→ 正式记忆（Canonical Memory）——先收集可能重要的信息，再筛选，最后才沉淀为长期记忆；同时每条记忆都带来源追溯（Provenance），能回答"它从哪来、为什么重要、是否已被推翻"。
┌─────────────────────────────┐
│ Reflection Service │
│ (合并/清理/偏好提取/日记) │
└──────────┬──────────────────┘
│ 定时维护
▼
用户对话 ──→ Scorer ──→ save_memory() ──→ SQLite + TriviumDB
│ │ │
│ ├─ Embedding │
│ ├─ 时间链表 │
│ └─ TriviumDB.link() │
│ (双层图谱：时间+实体) ▼
│ get_relevant_memories()
│ │
│ ┌───────────────────┤
│ ▼ ▼
│ 向量检索 图扩散传播 (PEDSA)
│ (TriviumDB) (TriviumDB 内置图谱)
│ │ │
│ └───────┬───────────┘
│ ▼
│ TriviumDB search_advanced 管线
│ ├─ NMF 语义分解 (L3~L6 深度流形)
│ ├─ FISTA 稀疏编码 (残差发现)
│ ├─ 共现增益
│ └─ DPP 多样性采样
│ │
│ ▼
│ RAGPreprocessor 注入 Prompt
└──────────── ▲
每轮对话结束后，Scorer（"秘书"） 会自动分析对话内容，提取核心事件、情感倾向和重要性评分，把它压缩成一条结构化记忆：
- 批量处理：多轮对话合并分析，避免记忆碎片化（攒批阈值：200 条消息或 50000 字符）
- 自动分批：超长上下文自动拆分，防止超出模型的处理上限（Token 溢出）
- 容错重试：失败任务自动标记，启动时批量恢复
写入时同步完成三件事：
- 计算语义向量（Embedding，把文字转成机器能比较的"数字指纹"），写入 TriviumDB 的"向量 + 图谱"存储
- 维护一条时间链（用
prev_id/next_id记录前后顺序），把记忆按时间先后串起来 - 用 GraphGardener 提取实体和它们之间的关系（因果、关联、包含等），搭出一张"概念之间的网"（认知图谱）
当用户发送新消息时，检索管线分六阶段工作。简单说就是：先粗找、再顺着关联扩散、再深挖语义、再补漏、再调权重、最后去重：
| 阶段 | 算法 | 作用（白话） | 实现 |
|---|---|---|---|
| ① 向量召回 | Cosine | 先把"意思相近"的记忆快速捞出来 | TriviumDB（search_advanced） |
| ② 图扩散传播 | PEDSA + PPR | 顺着记忆之间的关系，找到"看似不相关、其实有关联"的远端记忆 | TriviumDB 内置双层图谱 |
| ③ NMF 语义分析 | Lee & Seung, 1999 | 把候选拆成隐含主题，判断这次提问的语义深度和角度 | TriviumDB L3~L6 深度流形 |
| ④ FISTA 残差发现 | Beck & Teboulle, 2009 | 找出"现有候选解释不了"的遗漏，触发二次检索补弱信号 | TriviumDB（enable_sparse_residual） |
| ⑤ 共现增益 | 统计关联 | 经常一起出现的概念，给相关记忆加权 | GraphGardener |
| ⑥ DPP 多样性采样 | Kulesza & Taskar, 2012 | 从候选中挑出"质量最高、彼此最不重复"的最终结果 | TriviumDB（enable_dpp） |
这三个构件各管一件事：ContextRNN 感知"现在在聊什么"，Leiden 聚类 自动把记忆分主题，反馈闭环 负责事后纠错。
它像一个一直在更新的"对话方向感知器"，让检索系统知道你们正在聊什么方向。每轮对话都会实时更新一个轻量级 minGRU 隐状态（256 维，约 1.6MB 参数，纯 CPU 推理不到 2ms）：
z_t = σ(W_z @ x_t) 门控
h̃_t = W_h @ x_t 候选状态
h_{t+1} = (1 - z_t) ⊙ h_t + z_t ⊙ h̃_t 状态更新
- 调制候选打分：
finalScore = α × vecSim + β × contextAffinity - 调制图谱边权：让扩散沿语境方向走
- 隐状态持久化：256 × f32 = 1KB 写入磁盘，跨对话保留
- 实现：
@infos/nit-runtime(Rust N-API) +ContextRnn(TypeScript)
自动把记忆分成一个个主题（"料理"、"工作"、"感情"等），检索时按主题来找。它是在记忆图谱上运行 Leiden 算法实现的，带来四重收益：
- 检索多样性：先选 top-3 相关 clusters → 各 cluster 内取 top_k/3
- 与 ContextRNN 联动：
cluster_affinities = softmax(h_t @ centroids)→ RNN 隐状态选择活跃社区 - 日记按主题组织：周报按 cluster 统计
- 可解释性：检索结果附带 cluster 标签
事后看 AI 有没有真的用上这些记忆——用上了就加分，没用上就减分，下次检索就会更准。LLM 回复后，通过 Jaccard/共现词匹配（不额外消耗 Token）判断注入的记忆是否被实际使用：
- positive：记忆关键内容出现在 LLM 回复中 →
retrieval_quality += 0.1 - negative：完全未被引用 →
retrieval_quality -= 0.05 - 积累后触发 minGRU 在线训练：SGD 更新权重，让 RNN 下次更准地偏向有用方向
用户输入 ──→ Step 1: ContextRNN 更新 h_{t+1}
Step 2: Cluster 路由 → top-3 活跃社区
Step 3: Cluster 内向量召回 (超召回 3x)
Step 4: Context-aware 重排 (vecSim + rnnAffinity + centrality + quality)
Step 5: 图谱扩散 (边权受 h_t 调制)
Step 6: DPP 去冗余 → 最终 top_k
Step 7: 注入 prompt → LLM → 反馈采集
所有向量、图谱与检索算法都由 TriviumDB（自研的 Rust 引擎）统一承载：
- 向量 + 图谱一体存储：
.tdb文件同时保存"相似度索引"（HNSW）和"关系图谱"，一个文件就能完整迁移 - 原生双层图谱：一张"时间链图谱"（按时间先后串）+ 一张"实体概念图谱"（按概念关系串），都用同一套接口写入
- 三层记忆隔离：每个伙伴有自己独立的记忆库，社交和桌面之间通过一份共享的日记层间接互通
记忆按"新鲜度"分四层放——越往上层越"当下"，越往下越"长久"：
| 分层 | 载体 | 内容 | 检索方式 | 生命周期 |
|---|---|---|---|---|
| Layer 0 (Working) | JSON / LLM Context | 当前会话上下文 | 顺序读取 | 短期 |
| Layer 1 (Vector) | TriviumDB | 原始片段向量 + 文本索引 | 语义相似度 + 关键词 | 长期 |
| Layer 2 (Graph) | TriviumDB | 实体/事件图谱 + 关系边 | 关联扩散 + 图查询 | 长期 |
| Layer 3 (Diary) | SQLite / TDB | 每日/周总结 + 逻辑闪回 | 关键词 + 时间轴 | 永久 |
除了被动响应，记忆还会"自己整理自己"。ReflectionService（反思服务） 会定期自动运行，执行 7 项维护任务：
- 重要性标注 + 思维簇归类（单次 LLM 调用合并）
- 记忆整合：将低重要性的陈旧事件压缩为陈述性总结
- 错误记忆审计：LLM 识别并清理矛盾、重复、幻觉记忆
- 社交日报去重清理
- 偏好提取：从事件记忆中提炼长期用户偏好
- 边界维护：处理僵尸/超龄记忆
- 台词动态更新：根据近期记忆生成个性化的欢迎语和闲聊
所有维护操作都会被记录下来，支持一键回滚。
"从加载一个 Skill 到运行独立微服务——你决定深入的程度。"
想让 Pero 会新技能？扩展系统就是为此设计的。infOS 提供三种扩展类型，可以在同一个扩展包里自由组合：
Skill Tool Hook
┌───────────┐ ┌───────────────┐ ┌──────────────┐
│ 任务知识 │ │ 原子工具 │ │ 生命周期 │
│ + 工具组合│ │ (函数调用) │ │ 事件钩子 │
├───────────┤ ├───────────────┤ ├──────────────┤
│ SKILL.md │ │ handler() │ │ pre_chat │
│ 渐进式加载│ │ 参数用 │ │ post_chat │
│ 分菜单加载│ │ JSON Schema │ │ on_event │
└───────────┘ └───────────────┘ └──────────────┘
AI 按需加载 标准工具调用 消息流转管道
- Skill（技能）：用 YAML + Markdown 编写，相当于一份"怎么做某件事"的说明书。AI 需要时按需加载执行步骤，不会一次性塞满上下文。
- Tool（工具）：给 AI 一个能调用的新函数，用 JSON Schema 声明参数格式。
- Hook（钩子）：事件监听/拦截器，可以在对话前、对话后或特定事件发生时插入逻辑。
两种通信方式：进程内（TypeScript/JavaScript 直接加载）或跨进程（通过标准输入输出通信，兼容 MCP 协议）。
让 Pero 走出桌面，进入你的群聊喵~
infOS 让 AI 能像真实用户一样在 QQ 群和私聊里互动。下面这套"四层解耦"架构，就是让多个平台（QQ、Discord、Telegram 等）都能干净接入的关键。
Layer 0: 桥接层（SocialBridge，负责把消息落地并通知前端）
└── 消息持久化 + 前端状态通知
Layer 1: 调度层（SessionManager + Scheduler，与平台无关）
└── 四状态机: 观察 → 被召唤 → 活跃 → 深入
└── 攒批逻辑 (私聊 7s / 群聊 15s) + 秘书层决策
Layer 2: 抽象接口层（AbstractSocialAdapter）
└── 统一的 connect / disconnect / sendMessage
Layer 3: 平台适配层（NapcatAdapter / DiscordAdapter / TelegramAdapter）
└── 各自处理平台特有协议（如 QQ 的 OneBot v11 / CQ 码）
- 跨场景记忆：社交里的聊天也会被"秘书"提炼成图谱记忆，桌面和社交之间共享一份日记层，记忆互通。
- 智能攒批：在热闹的群聊里，AI 会先观察一会儿、综合理解，再优雅地"冒泡"回复，并非每条都插嘴。
- 社交日报：自动回顾当天的社交记录，生成日记，沉淀为长期记忆。
"Always online, always there."
infOS 通过 Docker Compose 提供 24/7 持久服务：
# 克隆仓库
git clone https://github.com/YoKONCy/infOS.git
cd infOS
# 启动 (Backend + Frontend)
docker compose up -d
# 查看日志
docker compose logs -f backend| 容器 | 方案 | 端口 |
|---|---|---|
infos-backend |
Bun + PM2 进程守护 | :9120 |
infos-frontend |
Nginx 静态托管 | :3000 |
数据持久化至 Docker Volume pero-data，支持通过 INFOS_AUTH_TOKEN 环境变量配置鉴权。
- 下载最新 Release 包。
- 安装到非中文路径。
- 双击运行
萌动链接：PeroperoChat！.exe。
以下流程面向 infOS 引擎开发者；桌面应用 PeroperoChat 可直接使用发布包。
| 依赖 | 版本 | 说明 |
|---|---|---|
| Node.js | ≥20.0.0 | 后端+前端运行时 |
| pnpm | ≥9.0.0 | 包管理 (packageManager: pnpm@9.15.9) |
| Rust | stable 1.75+ | 编译 packages/native/* (可选) |
git clone https://github.com/YoKONCy/infOS.git
cd infOSpnpm install# 终端 1：启动后端 (Hono, :9120)
pnpm dev
# 终端 2：启动前端 (Vite)
pnpm dev:frontend首次运行后会自动创建 SQLite 数据库。在前端 设置页面 中配置：
- LLM API Key & Base URL：支持 OpenAI / Anthropic / Google Gemini / 任意 OpenAI 兼容 API
# 标准版
pnpm electron:build
# Steam 版 (集成 Steamworks.js)
pnpm electron:build:steam
# 便携版
pnpm electron:build:portable常见问题：端口冲突
- 后端默认端口
9120，可通过环境变量PERO_PORT=9121修改 - 前端 Vite 默认端口
7359
常见问题：便携模式
在 .exe 同级目录下新建 .portable 空白文件，应用将读写本地 data/ 目录，跳过系统 AppData。
infOS 与 PeroperoChat 是完全非盈利的开源项目。
我们是一群热爱 AI、热爱二次元、热爱技术的开发者。我们开发它们，不为商业变现，只为下面这个朴素的愿望： 我们想要一个真正的、懂我们的桌面伙伴。
- 永久免费: 核心代码永久开源，不设任何付费墙。
- 社区驱动: 欢迎任何形式的贡献——无论是代码 (PR)、建议 (Issue) 还是单纯的喜爱 (Star)。