架构
上级:standmeet · 仓库:
backend/+app/+sdk/+builder/+im-bridge/+infra/
事实来源(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 + MinIO
- 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 下的一个节点,承载着它的组件、代码路径、状态和设计页面:
- 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)。 - capabilities ——agent 的手(能力平面)。 我们是 MCP host:capreg、五个已外置的 server、ext-mcp、skills、
ui://卡片。留在进程内的那部分,正是外置化迁移要吃掉的目标。(相反的那个平面——我们作为 MCP server——是 service-handle,作为单独的节点保留。) - connector ——带凭证的边界。 Hub + 分类契约;openapi/protocol 两种类型;可安装的 connector 已落地(fixme 尾巴已清理——还剩 11 个 mock 基础设施的 TODO);sync-mode 也已落地 ——
connector.NewSyncConnector+SyncIngester能力把"同步/摄入"变成一等的连接器种类,/obsidian/import现在经它走(1 与 3 之间那道接缝,已合上)。 - monitor ——调用时的遥测。 最单薄的一根支柱;迷你 Zabbix 式的系统面板已于 2026-09-04 上线(a5e1cada9 真实系统观测;e3af33a1c 读 backend 自己的 cgroup、不挂 docker socket——
backend/internal/infra/selfstat/selfstat.go;4a082689a 于 2026-09-05 加了约 1 次/秒的实时刷新)。 - agent-core ——循环本身。 eino + Bridge/Driver(已落地)、不区分入口、把 eval 当作一种消费者对待。
- access-control ——阀门。 邀请码、冻结的角色快照、三层纯 AND 的 ACL、BYOAI、Ed25519。
- 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)。
路线图(大板块,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里的updatersidecar 按 backend 写下的信号文件重建整个栈(deployment)。
关键设计
- key-designs ——那些不显眼、却承重的决定
- confusables ——那些看着像却不是一回事的术语:两个 MCP 平面、两条插件轴线、writings 与 corpus、frozen 与 live,等等
部署
- deployment ——自托管、单租户、单机;读多写少;为什么"不能水平扩展"是刻意的设计