基于 Graph 的 AI 中台。每个用户有自己的、隔离的 AI agent（pi）和一个对话框； 说出需求，agent 在图上找到能干活的 Worker（也是 pi），动态拉起它们，各自通过统一的门 （Gatekeeper）对接不同系统，把结果和决策带着来龙去脉写回图里，再决定下一步。所有 agent 共享 同一份带类型、双时态、逐边溯源的图，受同一套规则约束，每一步可追溯、可审批、可重建。
- 图既是记忆也是控制面。 Object / Fact / Link 带类型与双时态，每条边记录来源；Decision、
Conflict、Activity 是一等对象，
explain能从任一结论回溯到证据链。 - 每用户一个隔离的常驻 agent。 入口 agent 跑在自己的容器里，靠 Handle 与 Grant 拿到能力， 进程不持任何外部凭证。
- Worker 在图上可发现、按需拉起。
find_workers/invoke_worker是一等能力；Worker 结果 与决策带溯源写回图。 - 门与审批。 每个外部系统经一个 Gatekeeper 接入（SSH / HTTP / Docker / MCP 四种传输）； 触及凭证、内部或有状态系统的动作生成审批卡片，审批通过后才执行，可自动批准的种类由 owner 配置。
- 看得见、接得上。 图有 Explorer（Graph / Decision / Lineage 三工作区）与 MCP gateway： Claude Code 或任何 MCP 客户端凭 Handle 接到同一份图。
2026-10-16 起的主线是两件事，设计与排号见 docs/goal-orchestration-and-admin-agent-plan-2026-10-16.md
与 docs/global-roadmap-2026-10-16.md：
- 目标级执行。 多步、跨系统、需要等待的需求成为一个目标：平台持有计划版本，按依赖开步骤、按需组建 Worker， 根据结果修订分工与流程，由平台执行的验收证据判定完成；用户离开、内核重启、审批跨小时、外部响应丢失时都走到已知状态， 同一业务动作在一步里至多执行一次。
- 平台管理员 Agent。 管理员自己的 agent 能探索、起草、试验并提交平台配置变更（例如接入一个新系统：门实例、Operation 分类、 WorkerDefinition、Skill、本体），不必每次靠外部 AI agent；它只是提议者：变更计划按授权分段（平台段由平台管理员、每个工作区段由该 工作区 owner）干跑、审阅、应用，可回滚，授权扩大项逐项确认，它不能扩大自己的权限，也没有写平台代码的能力。代码层是否开放是 W5 开工前的决策门，部署始终由维护者执行。
当前版本见上方 Release 徽章与 CHANGELOG.md（自 v0.3.0 起已持续发版；README 不再写死版本号）。
S1（对话入图）、S2（审批执行写回）、S3（本体、采集器、Explorer、MCP）以及其后的平台管理、
控制台、运行层、镜像发布等阶段，均已由验收脚本在目标主机通过。进度、当前波次与遗留清单只在一处维护：
docs/STATUS.md（已完成波次的记录在 docs/status-history.md）。
任何会话从那里开始；agent 会话的约束见 CLAUDE.md。
验收脚本（S1 / S2 / S3 / S4）默认跑在 deploy/fake-llm（硬编码的状态机）上，证明的是内核 / 门 /
扩展这一侧的链路成立；真实模型自己选对工具另有 --real 模式的回归，数字与边界见
docs/STATUS.md §2.2 与 docs/runbooks/host-accept-real-model.md。
按 docs/runbooks/README.md 的「① 主机初始化」从上到下走一遍。
前置条件：
- Docker 与 Docker Compose，容器运行时需可用 gVisor（
runsc） - Postgres（compose 内起）
- 构建与 CLI：Node.js 22 与 pnpm（版本由
package.json的packageManager钉死）
环境相关的具体值（主机、网段、数据目录、密钥）只放在 gitignored 的 docs/private/ 与主机的
.env / secrets/；入库文档一律用 <TARGET_HOST>、${NEXTTIME_DATA} 这类占位符。
首次部署装好即有管理员：按 docs/runbooks/host-bootstrap.md「首次登录」读出 kernel 生成的临时密码，
以登录名 admin 登录 web 控制台、改密后落在「概览」页；再用用户名 + 密码登录，在对话框里说出需求。
入口 agent 会在图上找 Worker 并拉起；需要审批的动作以卡片形式出现在「待我审批」，通过后执行，结果与
决策写回图。图的内容在 /explorer 查看。
把外部工具接到同一份图：
- Claude Code：
docs/howto-connect-claude-code.md - 本地 pi：
docs/howto-connect-pi.md
接入新系统或新领域概念：docs/runbooks/add-gatekeeper.md、docs/runbooks/add-domain-pack.md。
全 TypeScript pnpm monorepo。
| 目录 | 内容 |
|---|---|
packages/shared |
领域类型、状态转移表、capability 注册表、线上契约 schema |
packages/kernel |
内核：图存储、本体、epistemic、治理（Policy / 审批 / Grant / Handle）、chat、MCP gateway、Explorer 契约 |
packages/agent-host |
入口容器与内核之间的事件桥 |
packages/worker-supervisor |
拉起与回收 Worker 容器，维护出网白名单 |
packages/platform-extension |
跑在 pi 内的平台扩展，entry / worker / interactive 三种模式 |
packages/gatekeeper-base |
门的协议、基类、四种传输与命令策略表 |
packages/llm-proxy |
模型调用统一出口，agent 不直接持 provider key |
packages/egress-proxy |
容器出网代理，按 Worker 来源放行 |
packages/web |
控制台：对话、任务、审批、治理 |
gatekeepers/ |
预置门实例（docker、ragflow） |
collectors/ |
采集器（host-inventory） |
ontology/ |
领域包（ops-assets-v1） |
explorer/ |
Explorer 静态包构建脚本 |
deploy/ |
caddy、worker-runtime、fake-llm、备份、验收夹具 |
scripts/ |
验收脚本 accept_s{1,2,3}.sh、运维演练、CI 守卫 |
三条设计底线不可降级：
- agent 与 kernel 进程不持凭证；凭证只到门。
- 触及有凭证、内部或有状态系统的动作必经审批。
- 隔离与审计只增不减。
不变量 I1–I16 由内核定时校验并输出指标；混沌演练见 docs/runbooks/host-chaos.md。
pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm test # 有 DATABASE_URL 时跑内核的 Postgres 集成套件
pnpm build
pnpm ci:guards # 内核纯度、pi 版本一致性、词表守卫（先构建 shared）
pnpm contract:check # capability 注册表快照CI 三个 job：guards / quality / test；另有 e2e、CodeQL、Scorecard、镜像扫描与 pi 漂移检测。
改动走分支加 PR，Conventional Commits，单 commit 的 PR 用 squash 合并；release-please 据此生成
CHANGELOG 与版本；依赖升级按计划波次手动进行（Dependabot 安全告警作输入）。测试分层与每层的命令见 docs/testing.md，
线上契约约定见 docs/wire-contract-conventions.md。
进度入口 · 架构设计 · 推进计划 · 任务清单 · Runbooks · 测试 · Changelog
参考项目借概念与协议，不 fork 代码：pi（agent 运行底层）、cloudflare-os（审批与分权蓝本）、
Semantica（Decision / Conflict / PROV-O 一等对象，Explorer 前端与 MCP 工具契约）。分析见
docs/reference-projects-and-oss-landscape.md。