Everythink Studio
全球系统架构

六个章节，一个系统

从产品愿景到真实实现：Rust 后端、Next.js 前端、部署与路线图。

空间即路由器

每个人都有自己的个人组织，并订阅 n 个组织。每个组织——企业 · 政府 · 工会 · 社区——包含 n 个网络；每个网络包含 n 个社区；每个社区包含 n 个房间。每个节点都有自己的multipolygon：包含关系向内延伸（网络多边形内部的碎片化社区）或向外延伸（多边形外部的社区）。该拓扑在数学意义上是分形的：每一层都是上一层的自相似副本——S = ⋃ fᵢ(S)，即 Hutchinson 算子的吸引子（Banach 不动点定理）。网络之间相互互操作（联邦）：一个网络只通过共享公开内容连接到另一个网络。当一个人加入某个组织时，便获得对该组织 n 个社区与 n 个房间的访问权。其在该组织中所做的工作会被记录在组织中，并镜像到其个人组织：它生成按人计的声誉，被提炼为已解决的问题，并被复制到其个人网络，由该网络进行追踪。HAI 从累积的回答中为每个用户构建上下文层。

平台的四层

每一上层通过类型化接口组合其下各层的保证。产品（v1 模块）：HAI、Matchmaking、Chat、Calendar、Market、Social。在 4 层之上，有 10 个行业实例化。

支配架构的三条原则

每条原则都是一个可验证的保证，而非意向声明。它们共同确立了组合规则（端到端）、行业乘法规则（不修改的继承）与诚实规则（已实现且已度量 = 保证）。

HAI 引擎——13 种问题类型

自 2016 年投入生产。一个刻意收窄、可组合的前提：交互是类型化问题的工作流，平台是一个地理定位的拓扑，使每个回答都落在定义明确的上下文中。在 v2 中，引擎运行在两层推理之上：习得网络（确定性，无 LLM）与 A2A 推理，后者填补尚不存在的节点并使网络坍缩。

Calendar——销售服务并管理日程

卖家提供带价格、类别与可用时段的服务（type_event）；顾客预约（event）时给出参加者、日期与地点。在白标模式下，同一网络中的任何卖家都可见且可下单——“他人在我的网络中销售”。支付会在网络中创建商户，并按 product_key 查找产品。

Market——销售产品，并让他人在我的网络中销售

卖家上架带商户、提供者与价格的产品（market_product），并为其附加优惠/优惠券。顾客构建购物车（market_item）并结账（merchant_tx），网络密钥被写入 json_data。双方均可发起争议与评分。商户通过 merchant.network 绑定到网络——“他人在我的网络中销售”。

HAI + 匹配 + 聊天——每个用户的个人网络

HAI 通过理解每个用户在寻找什么来填充其个人网络：网络从企业/政府/社区/工会的网站或文档中自动生成内容，问题流被生成，不同房间的匹配之间的交叉链接（同一或不同社区）也被生成。匹配把流程自动化：一个用户意图 → 社区调度频道中的一张采购订单，地理定位于目标房间。基于 socket + FCM 的实时聊天。这些流程是跨切的（它们跨越房间），并运行在两层推理之上：习得网络 + A2A，后者负责填补与坍缩。

Social——网络促销与用户互动

网络在自己的空间中开展促销，用户在社交模块中互动：带点赞与评论的新闻/故事，类别由管理员设定。社交信息流存在于拓扑之中——网络发布，社区分片，房间接收。

两层推理——坍缩中的神经网络

所有模块都位于某个网络的房间中，并且是跨切的：来自售前访客房间的一个数据流（HAI）连接到来自需要技术支持的顾客的数据流。与 v1（静态图）不同，这里存在神经网络：若后续节点不存在，A2A 会确定接下来的步骤、保存它们，网络随之坍缩。其范围是有限的——一个用户在网络中提出的问题会为所有人保存下来——经 A2A 的 LLM 消耗随时间递减，永不增长。

可验证的多租户隔离

自 2016 年以来，企业、政府、NGO 与社区共享同一个 AI 基座，同时让私有的东西可证明地保持私有。由引用监控器（Reference Monitor）全面介导；唯一被允许的通道 = 公开作用域。

联邦网络与稳定匹配

网络基于各自的公开投影进行联邦。匹配只在邻近半径内的公开作用域上进行；延迟接受 → 稳定匹配。

类型化诱导——少数几个问题即可完成学习

系统提问，用户回答，回答成为上下文。诱导是类型化的（引擎计算不会出人意料）、忠实的、高效的。它运行在第 1 层（习得网络，确定性）之上；当某个节点不存在时，第 2 层（A2A）确定步骤、将其持久化，网络随之坍缩——少数几个问题即可完成学习，且每个新问题都为所有人保存。

Agentic 工作流——信封

某些节点需要开放式的工作：一个把推理与工具调用交替进行的 LLM agent（ReAct 风格），直到得到类型正确的答案。这就是推理第 2 层（A2A）：当习得网络中不存在后续节点时，agent 确定接下来的步骤、将其持久化，网络随之坍缩——LLM 消耗随时间递减，永不增长。信封为三种失败模式划界。

主动式协助——信息的价值

它是被动式聊天机器人的反面：主动发起而非等待。难点在于克制——只在行动的期望净价值超过保持沉默的价值时才开口。

有边界的权限与来源可追溯

一个能够行动的 agent——花钱、联系第三方、移动数据——必须被限制在用户同意的范围之内，仅为既定目的使用信息，并留下一条可供解释与撤销的痕迹。

服务于人类网络的自主网络

有边界的委托、合同网分配（发布 → 投标 → 授予），以及协调的诚实极限：只有在部分同步条件下才有活性。

安全与证据协议

十个行业实例化

每个行业部署在不修改第 1–4 层的前提下对其进行实例化，并继承其保证。

生产 / 设计 / 推算

17 个 crate，六边形架构，单个 Postgres

组合根（api）→ 用例 ×10 → 适配器（ledger、a2a、courier）→ 领域（core，零 I/O）。单个 Postgres（Timescale pg17 + pgvector）承担一切：账本、事件、嵌入、任务/whisper 地理缓存。SQL 在编译期验证（.sqlx/ 离线缓存，107 条查询）。

端口 & 适配器——领域居中

领域（everythink-core）不涉及任何 I/O。适配器实现面向数据库、邮件、A2A 的端口。用例负责编排。组合根（everythink-api）把一切装配起来。

为什么有这么多 crate——每个 crate 一个明确的角色

每个 crate 都有一个角色：组合根（api）、客户端（sdk、cli）、用例 ×10、基础设施适配器（a2a、courier）、端口 + 持久化（ledger）、领域（core）。

17 个 crate 汇入 core

everythink-api 是枢纽；一切都依赖 core（零 I/O）。SDK 位于工作区内部（backend/crates/everythink-sdk），因为它与 core 耦合。

从认证到持久化——一个完整请求

客户端 → api（认证 + 速率限制 + 校验）→ loom（运行）→ ledger（通过仓储 trait 解析 profile）→ sisters（扇出）→ oracle（merge → 归一化的 Ensemble）→ ledger（持久化）→ 200 OK。

六个用例：编排、认证与数据

loom — 编排：通过 LoomStore 端口 / LoomPersistence 适配器持久化。 ingest — 信号流水线：处理传入信号。 scry — 情感分析：参考端口 SentimentReader / PgSentimentReader。 eval — 回归测试体系：持续评估。 warden — 认证：JWT access/refresh、Google OAuth、IP 绑定。 whisper — HMAC 签名的 webhook，精确一次交付。

中间件链——trace → timeout → CORS → 路由

入站请求 → Trace + request_id → Timeout 60s → 408 → CORS + 压缩 → 带 5 个分支的路由子树。

三种认证体系共存于一个路由器

公开（probes/register/login/refresh）· Eye-Key（HMAC，60 秒滑动窗口速率限制）· 用户 JWT（warden，Console）· Atlas WS（自认证，按用户上限）。

无继承的 RBAC——一个函数，一张显式矩阵

can(role, action) 是一个 const fn：Owner → true；Profile Read/Write Self → true；对 (role, action) 显式匹配；其余 → 仅限 Owner。在 handler 中 AUTHORIZE → 拒绝时返回 403。

一个数据存储承担一切

timescale/timescaledb-ha:pg17 + pgvector（vector(1024) + HNSW）。单个连接池。六个数据域：Ledger、Simulations、Users、Embeddings、geo_signals、Jobs。健康检查：docker-compose 中的 pg_isready（service_healthy）。

持久化经由端口，绝不经由具体实现

Repository TRAIT · Pg*Repository（所有 SQL 都在这里）· MockRepository（无数据库的测试）· AppState：Arc<dyn Repository> · 用例调用该 TRAIT。

编译期校验的 SQL，可逆迁移

编辑 .up.sql + .down.sql（成对）→ just sqlx-prepare → 提交 .sqlx/*.json（107 条查询）→ 在 SQLX_OFFLINE=true 且无活动数据库的情况下构建/CI。

健康检查 + SQLX 离线 — 精确部署

docker-compose：postgres（pg_isready，10s/5s/10）→ dragonfly（redis-cli ping，10s/3s/10）→ api（service_healthy）。app/admin：健康检查已禁用（distroless/static）。CI：SQLX_OFFLINE=true，并提交 .sqlx/ 缓存。

SSE（Tide）+ WebSocket（GeoHub）— 按瓦片扇出

TideBroker：支持复合主题的 SSE，broadcast 256，keep-alive 15s，Last-Event-ID 重连。GeoHub：WS，使用 DashMap[Tile → broadcast 64]、视口导向、可选开启 gzip。

六个编排与数据用例

everythink-warden — 用户认证

everythink-whisper — 签名 webhook 与持久投递

A2A（协议）与 Courier（邮件）

everythink-cli 与 everythink-sdk

六条永不违反的不变量

4 个应用、13 个包、同一身份

web (:3000) · app (:3001) · admin (:3002) · mobile (Expo)。包：types、sdk-core + 各 facade、domain、ui、auth、api-client、telemetry、config。

四个界面、一个后端、三类参与者

参与者：最终用户（访客 → 已认证）· 开发者（Eye-Key）· 管理员/运营者（staff）。界面：web/app/admin/mobile。后端 API（REST + SSE，位于 /api/v1）。

容器 — 整个 monorepo

4 个应用 + SDK 层（6 个 facade）+ 服务（4 个）+ 设计系统 + 工具链 + types（叶子）。使用缩放进行探索。

web、app、admin、mobile — 每类受众一个

六个 facade、一个核心、核心中零端点

sdk-core（HttpClient、consumeSSE、TokenProvider）· sdk-guest · sdk-auth · sdk-atlas · sdk-eye · sdk-admin。

应用服务、UI 与构建期

domain（映射器）· telemetry（outbox）· api-client（遗留）· auth（NextAuth v5 + RBAC）· ui（套件 + 令牌）· config（eslint 预设）· types（Zod，叶子）。

sdk-core 只负责 HOW，从不涉及 WHAT

端点只存在于各 facade 中；sdk-core 用 Zod 依据 @everythink/types 校验每个响应；一旦契约漂移，抛出 SdkError 树中的 ContractViolation。

Feature-Sliced Design + MVVM —— 导入只向下流动

屏幕（View）→ View-model hook → feature.repository.ts（通往 SDK 的唯一入口）。ESLint 边界规则 no-restricted-imports（INV-1）。FSD 分层：shared → entities → features → widgets → app。

一次登录，一个源站，四个界面

apps/web /auth（唯一源站）→ httpOnly cookie 'everythink_at' → 内存中的 token + localStorage 种子 → EverythinkAuthGuard + resolveMe（GET /api/v1/auth/me）→ 基于角色的门禁。

can(role, action) —— 显式矩阵，无继承

三层：（1）各应用 auth.ts 的 allowedRoles →（2）middleware →（3）UI 与 server actions 中的 can()。对应后端的 everythink_core::rbac。

一个样式表，语义化 token，Tailwind v4

设计的单一事实来源：:root 中的 CSS token、经 @theme（Tailwind v4）的语义映射，以及移动端使用镜像 token 的 NativeWind。各应用消费语义化组件（bg-accent、text-foreground、font-display/mono），绝不使用裸十六进制色值。宇宙紫调色板：--gold: #d9ab5c、--violet: #9d7df5、--emerald: #10B981。

网络边界处的 Zod —— 单一契约

线上传输类型在 @everythink/types 中用 Zod 定义一次。SDK 校验每一个后端响应（z.parse(response)）；非法载荷抛出 ApiError，绝不崩溃。组件永远看不到原始 JSON：*.repository.ts 负责解析，@everythink/domain 把 DTO 映射为 model，view-model 再把带类型的 state 暴露给 View。

apps/mobile —— Expo、expo-router、NativeWind

基于 React Native，使用 expo-router（基于文件的路由）与 NativeWind（RN 版 Tailwind）。主题系统镜像 web 设计系统的 token（tailwind.config.js + src/theme/index.ts）。它消费 sdk-guest、sdk-auth、sdk-atlas、domain 和 telemetry。被排除在 web CI 之外：--filter=!@everythink/mobile。

四条由工具强制执行的规则

可由 ESLint + TypeScript 验证的规则，而非口头约定：（1）INV-1：只有 *.repository.ts 可以导入 SDK（no-restricted-imports）；（2）FSD 分层：导入只向下流动（shared → entities → features → widgets → app），跨 feature 只能经由公共 barrel；（3）共享登录：web 与 app 共享 localStorage('everythink:auth') + resolveMe()；（4）三层 RBAC：auth.ts 的 allowedRoles → middleware → UI 与 server actions 中的 can(role, action)。

docker-compose.prod.yml —— 完整技术栈

ALB（TLS）→ nginx :80 → api（:18081，启动时执行迁移）· web（Next standalone）· app/admin（静态 distroless）· postgres（timescale/timescaledb-ha:pg17 + pgvector）· dragonfly（兼容 Redis）。7 个服务：postgres · dragonfly · api · web · app · admin · nginx。

nginx 作为唯一入口

nginx :80 是唯一的内部入口。它将 /api/v1/* 路由到 api:18081，/ 到 web:3000，/app/* 与 /admin/* 到静态服务。web 通过 EVERYTHINK_API_INTERNAL_URL（http://api:18081）与 api 通信。api 依赖 postgres 和 dragonfly，条件为 service_healthy。

backend/.env —— 机密的唯一存放处

docker-compose.prod.yml 通过 env_file 将 backend/.env 挂载到 api 与 web 服务。api 持有全部机密（JWT_SECRET、EYE_KEY_HMAC_SECRET、GOOGLE_CLIENT_ID、BREVO_API_KEY）。web 只接收 NEXT_PUBLIC_* 变量——绝不持有 BREVO_API_KEY。app/admin 是静态 distroless，构建中不含任何机密。

预生产直接部署 vs CI/CD 门禁

两条部署路径：预生产直接从工作树部署（不经过 main）；生产必须合并到 main 并通过完整性门禁。这条规则至关重要：预生产不要使用 deploy workflow，因为它会拉取 main 的 :latest 并覆盖直接部署。

PR 上跑 affected，main 上跑完整性

两级流水线：PR 层只运行受影响的部分（后端：ci-affected-crates.sh；前端：turbo --affected），main 层运行完整完整性检查（完整后端 + 前端/移动端 + E2E + 安全）。main 始终保持绿色且可部署。

联邦自托管节点 · BYOK · 每网络 DAO

v2 的路线图方向。以下均不是既有能力。流程：运营者本地生成 Ed25519 密钥对 → 仅指纹上传给 controller（BYOK）→ 自托管节点 → 账本锚定 → 仅在公共投影之上联邦 → 网络 DAO。

通往 v2 的五个阶段

候选链的参考架构

对 Postgres 账本哈希承诺进行公证的架构参考：Solana v0.8.13（Yakovenko）—— PoH 作为密码学时钟、带保证金/罚没的 PoS 共识、用于存储的 PoRep。链选择是运营者的显式决策；这是参考，不是实现。