架构

更新于 · 在 sijie.xyz 查看原条目 ↗

事实来源（2026 年 7 月）

代码是唯一的事实来源；本 wiki 是活的文档。 仓库里的 docs/ 只是权威性会不断衰减的输入材料——可以当线索用，绝不能当作现状：

  • 根目录 README.md：2026-09-05 按已发布状态重写（00c22ab3b）——现在是镜像部署指南；仍是种子，不是现状。
  • docs/design/* + docs/roadmap.md：历史设计记录 + 执行追踪表——"已建成/未建成"的说法早已漂移（一条"OAuth 流程尚未设计"的记录，在 OAuth 上线之后依然留在文档里）。每条说法都要对照代码核实。
  • docs/protocols.md + docs/theory-foundations.md：死文件——忽略它们。

技术栈（已核实）

  • Go 1.26.3，chi/v5 + sqlc（单一的 backend/db/schema.sql）
  • Postgres/pgvector + Redis + Silo (S3 object store; the MinIO fork)
  • AI 核心 = CloudWego eino v0.9.2（eino/adk 循环；Anthropic → 原生 Messages API 适配器，其余所有供应商 → OpenAI 兼容适配器）
  • Next.js 是薄的 SSE 消费端（agent 循环完全跑在后端一侧）
  • SDK = 5 个 npm 包：@standmeet/{sdk-core, agent-core, sdk, embed, mcp-client}（sdk/packages/{core, agent-core, react, embed, mcp-client}/package.json——没有 @standmeet/react；React 包发布名就是 @standmeet/sdk）
  • 注： 残留的空目录 backend/internal/mcp/ 在 36789537d 已不存在

七大支柱

每根支柱都是 key-designs 下的一个节点，承载着它的组件、代码路径、状态和设计页面：

  1. corpus ——资产。 一张 corpus_notes 表带 genre 列（与 vault 同构的 raw→wiki→output），派生路径树，note_refs 反向链接边表；三个面（feed / crawl / render）都已落地——vault 的 SyncVault 按顶层文件夹路由到 genre（backend/internal/corpus/obsidian/sync.go），corpus_links 沿 note_refs 走图（mcp-servers/retrieval/main.go:42）。
  2. capabilities ——agent 的手（能力平面）。 我们是 MCP host：capreg、五个已外置的 server、ext-mcp、skills、ui:// 卡片。留在进程内的那部分，正是外置化迁移要吃掉的目标。（相反的那个平面——我们作为 MCP server——是 service-handle，作为单独的节点保留。）
  3. connector ——带凭证的边界。 Hub + 分类契约；openapi/protocol 两种类型；可安装的 connector 已落地（fixme 尾巴已清理——还剩 11 个 mock 基础设施的 TODO）；sync-mode 也已落地 —— connector.NewSyncConnector + SyncIngester 能力把"同步/摄入"变成一等的连接器种类，/obsidian/import 现在经它走（1 与 3 之间那道接缝，已合上）。
  4. monitor ——调用时的遥测。 最单薄的一根支柱；迷你 Zabbix 式的系统面板已于 2026-09-04 上线（a5e1cada9 真实系统观测；e3af33a1c 读 backend 自己的 cgroup、不挂 docker socket——backend/internal/infra/selfstat/selfstat.go；4a082689a 于 2026-09-05 加了约 1 次/秒的实时刷新）。
  5. agent-core ——循环本身。 eino + Bridge/Driver（已落地）、不区分入口、把 eval 当作一种消费者对待。
  6. access-control ——阀门。 邀请码、冻结的角色快照、三层纯 AND 的 ACL、BYOAI、Ed25519。
  7. structure ——地基与纪律。 分层、单一 schema、错误信封、沙箱、机械式护栏 + 判断式审计。

此外还有对外的一面，刻意不归到任何一根支柱之下：service-handle——StandMeet 作为 MCP server（/mcp/*，Sigv1），owner 的 AI 在这里推送，其他 agent 在这里读取。

更新——everything-is-a-block（eiab），2026-09-13 → 2026-09-18

在本节点 2026-09-07 那次核对之后才落地，所以上面支柱 2 和 3 在机制上已被取代（意图不变）：

  • 支柱 2 + 3 合并成同一套 block 模型。 visitor/leaf 能力（ask_visitor、summarize_conversation、calendar.book、corpus.retrieval、mail.send）和每一个 connector（caldav、smtp、google-calendar、telegram）现在都是沙箱 JS block——backend/blocks/*/manifest.yaml + 一个 JS MCP server，没有 per-capability Go。capabilities/cap* 词汇改名为 plugin/block*（backend/internal/plugin/{blockstore,blockconfig,blockquota,blockload}）；me/seo/codes 变成域 fp.Op，经 convergence/dispatcher 投影。
  • backend/internal/connector/ 现在是空的（0 个 Go 文件）——独立的 connector 支柱没了。所以支柱 3 那句"sync-mode connector 已落地 / /obsidian/import 经它走"是双重过时：既没有 connector 模块，vault 同步也仍是一个bespoke admin 端点（backend/internal/routes/admin/obsidian.go），从未并进 connector（roadmap 1e）。
  • 仍在核心内（还没做成 block）： jobs/resume/applications（仍 MustRegister），所以 MustRegister + 进程内 registry 还在；mermaid 里的 mcp-servers/ stdio 子进程、以及 capreg / Connector Hub 那几个框，画的都是 eiab 之前的形状。

支柱如何连接

agent 核心（5）读取 corpus（1）、调用 MCP 能力（2）；能力所依赖的东西由 connector（3）提供；access control（6）在会话入口处给一切装上阀门；monitor（4）盯着调用时刻；structure（7）把这一切都撑起来；corpus 的同步已于 2026-07-08 并入 connector 的 sync-mode（1→3）（d51805372，backend/internal/connector/sync.go:61）。

flowchart TB
  V["visitor (QR / access code)"] --> APP
  OW["owner (admin)"] --> APP
  EV["eval-harness (EvalDriver)
same repo, separate go.mod"] -. "same launch handle" .-> CORE
  subgraph SM["StandMeet — our box"]
    subgraph FE["app — Next.js (frontend)"]
      APP["thin SSE shell + reader pages"]
    end
    subgraph BE["backend — Go (one process)"]
      RT["routes"] --> AC{"6 · Access control
global ∧ role ∧ ¬code-deny"}
      AC --> CORE["5 · Agent core
eino loop via Bridge/Driver"]
      CORE --> CAP["2 · Capabilities (capreg)"]
      CORE --> CORPUS[("1 · Corpus
corpus_notes (genre raw → wiki → output) + note_refs")]
      CAP --> CONN["3 · Connector Hub"]
      OBS["4 · Monitor (call-time)"] -. watches .-> CORE
      ST["7 · Structure: chi · sqlc · pg · redis · minio · sandbox · apierr"] ~~~ CORPUS
    end
    subgraph PROC["stdio child processes (own go.mods, sandboxed)"]
      MS["mcp-servers/
ask-visitor · booker · mail-sender · retrieval · summarize"]
    end
    APP --> RT
    CAP --> MS
  end
  CONN --> EXT["external world
GCal · SMTP · CalDAV · Telegram …"]
  OW -- "writes / promotes" --> CORPUS

路线图（大板块，2026 年 7 月——状态截至 2026-09-07）

  • corpus-as-vault 板块（= 支柱 1）： 已落地——三个面都建完；crawl 面是 Meilisearch 作词法入口 + corpus_links（沿 note_refs 走 1 跳，深度由 agent 决定），刻意不用向量（见 corpus-retrieval）。
  • platform 板块（= 支柱 2 + 5）： 外置化迁移（进程内注册表 → 独立的 MCP server；功能底线不能下降），以及把 inject-and-launch 提升为一等公民的运行时。
  • 支柱 4 = 系统面板——2026-09-04 已上线（a5e1cada9、e3af33a1c；monitor）。
  • 一键部署计划（auto-LE）——2026 年 7 月被砍掉——owner 自己在其服务商那边绑定域名/证书。取而代之上线的是（2026-09-04，7a3a749e7 / 3c9fb6113 / 3d1ce1aaf）：产品自有的原地升级——infra/deploy/docker-compose.yml 里的 updater sidecar 按 backend 写下的信号文件重建整个栈（deployment）。

关键设计

  • key-designs ——那些不显眼、却承重的决定
  • confusables ——那些看着像却不是一回事的术语：两个 MCP 平面、两条插件轴线、writings 与 corpus、frozen 与 live，等等

部署

  • deployment ——自托管、单租户、单机；读多写少；为什么"不能水平扩展"是刻意的设计

相关笔记