DSH-BOOT

English | 简体中文 | 日本語 | Français | Deutsch | Español | Русский | Português

> 在 DSH 内核之上构建企业级 AI Agent 业务系统的平台。
> 你只写业务逻辑。多租户隔离、安全审计、审批、配额计费、会话持久化、演进兼容——这些由平台实现，契约测试钉死，不需要你自己写。

为什么会有这个项目

DSH 开源之后，我一直在思考一个问题：如何把 DSH 的能力引入企业级应用中去？

我一直认为并不是所有公司，都具备开发一套完整 AI Agent 智能体平台的能力；但所有公司在 AI 时代都有同一个诉求——将自身业务场景与 AI 结合，进行本地化服务建设和云平台部署。

DeepSeek harness 不做这些具体的事。基于它「一切皆插件」的理念，我们可以把它当做可以自由支配、无版权风险的 harness 底座平台，并且这个底座平台站在技术最前沿不断在进化——这就免去了很多企业追求新技术的各种成本。

DSH 把单 Agent 的运行时做得非常好——工具沙箱、审批瀑布、预设与插件生态，这些先进理念开箱即得。但企业级应用需要的不止这些：多租户怎么隔离？审计怎么赖不掉？用户要删数据怎么办？有人把资源吃光怎么办？升级怎么不搞坏客户数据？——这些 DSH 内核没有，而每一家企业自己造一遍，就是把同样的坑重新踩一遍。

探索的结论是：需要一个以 DSH 为内核的 harness 平台。DSH 内核已经给了两层边界（能力边界、调用边界），缺的只有最外层（租户/资源隔离）——所以这个项目不重写 DSH，而是在它之上补齐外层、钉死内层与中层，把企业级的"难而正确"做成平台代码。

目标是：企业专注于业务实现的同时，充分享受 DSH 带来的先进理念红利——你定义场景、工具、连接器、技能；隔离、审计、审批、配额计费、持久化与恢复、演进兼容，由平台兜底，并且每一条承诺都有契约测试钉死。是否升级 DSH、何时升级，也由你按情况判断：升级经流水线五道 gate（契约测试、快照 diff、列车一致性、灰度记录、就绪复验）验证后平滑进行，业务不受影响。

你不用再自己解决这些

快速开始

要求：Node ≥ 22、pnpm；Linux 主机（生产多租户仅 Linux——Windows 已实测排除，见边界）。

pnpm install

# 起本地最小拓扑：反向网关桩 + 内存 attest + 种子 Profile
pnpm dev:up          # HTTP 端点在 http://127.0.0.1:7301（JSON API）
pnpm dev:smoke       # 跑一轮完整轮次

先说清几个词

本仓库和 DSH 方案反复使用这几个概念：

• 域（isolation domain）：一个隔离的运行环境，跑着服务于某租户某隔离组的 DSH 实例（生产中在独立容器里）。域与域之间互不可见——这是多租户隔离的基本单位。
• 域内 / 域外：域内 = DSH 实例内部，模型和工具在这里执行，不可信（可能被提示注入或篡改）；域外 = dsh-boot 控制面与网关一侧，可信。所以授权、审计、制品校验、就绪判定都在域外做，域内上报只能作参考——这叫"强制力只来自域外"。
• 门禁（GATE）：进入下一阶段前的强制检查点。每个门禁有可执行的验证（契约测试、演练、实测）和归档的证据；不过就停，不签字放行。
• 契约测试：把平台承诺的每条语义（"跨租户互相不可见""审批失败不自动重试""撕裂尾永不返回给用户"）写成自动化测试。后续任何改动改坏了承诺，测试立即变红。

一套业务系统，三层组成

用你的业务系统做一次会话，从上到下经过三层：

你的用户
│
▼
┌──────────────────────────────────────────────┐
│ 业务系统（你写的）                            │
│ 你的界面（Web/App/CLI）+ 你的业务流程          │
│ + 你定义的场景、工具、连接器、技能              │
└──────────────────┬───────────────────────────┘
│ 调平台 API 发起会话/轮次
▼
┌──────────────────────────────────────────────┐
│ DSH-BOOT（本项目，平台层）                     │
│ 登录鉴权 · 配额计费 · 审批 · 审计取证 ·        │
│ DSR 删除 · 降级 · 升级门禁                    │
└──────────────────┬───────────────────────────┘
│ 把轮次派发到隔离域
▼
┌──────────────────────────────────────────────┐
│ DSH 内核（每个隔离域一个实例）                 │
│ 模型调用 · 工具执行 · 沙箱 · 插件              │
└──────────────────────────────────────────────┘

安全视角下，这三层对应三层边界：内层能力边界、中层调用边界归 DSH 内核与 DSH-BOOT 共同把守，外层租户/资源隔离由 DSH-BOOT 提供——逐层见下表。

DSH-BOOT 与 DSH 的关系：三层边界，只缺最外层

DSH 内核给了单个 Agent 的完整运行时：模型调用（ctx.llm）、工具注册（ctx.tools）、审批瀑布（ctx.approval）、沙箱（dsh-sandbox*）、预设（dsh-agent-preset）。但三层边界它只给了两层——缺的恰好是多租户最需要的外层：

三层齐全，多租户才成立。 只有内层（Agent 有哪些工具）就宣称能隔离，等于把"能力边界"冒充"安全边界"——这是本项目一切架构决策的起点。

那么 DSH-BOOT 到底是什么？它是一个多租户 AI Agent 平台软件，由三部分组成：

1. 控制面服务（TypeScript 包）：身份与 RBAC、配额与公平调度、计费归集、审计与取证、DSR 删除、会话路由与索引——企业平台的后台逻辑；
2. DSH 集成（反向网关桩 + 域桥）：把 DSH 的模型调用、工具注册、审批瀑布接到控制面，并在域外做制品校验与漂移检测——不修改 DSH 内核；
3. 工程门禁（规格集 + 校验工具）：397 条需求、六个门禁、快照 diff——保证上面的承诺不被后续改动悄悄破坏。

它不重写 DSH：每个 Agent 仍由 DSH 内核运行；DSH-BOOT 把很多个这样的 Agent 管成一家企业的多租户平台。部署形态：控制面服务 + 每隔离域一个 DSH 实例（Linux 容器）+ 网关。

DSH-BOOT 与 DSH 之间的交互

每个隔离域里跑一个 DSH 实例，两者之间只有几条明确的通道：

一句话：域内只执行，域外做判定。DSH 实例不知道其他租户的存在；所有跨租户的决策（谁能进、能用什么、干了什么、怎么删）都在 DSH-BOOT 这边。

对应关系一句话：DSH 之于 DSH-BOOT，约等于 JVM 之于 Spring Boot——内核管单实例运行时，平台管多租户的企业级语义。

构建你的业务系统

在 DSH-BOOT 上写业务系统 = 定义四类资产，平台负责其余一切：

最小示例（节选自契约测试，可复制运行）：

import { ScenarioCatalog, ConnectorRegistry } from "../../../../packages/control-plane/src/registry/registries.ts";

// 定义一个场景：presetId + 插件集 + 策略
const scenarios = new ScenarioCatalog();
scenarios.define({
presetId: "preset-1",
pluginSet: ["dsh-base"],
policies: { requireApproval: ["shell"], toolAllowlist: ["fs"] },
});

// 注册一个 MCP 连接器：默认 untrusted，例外归属须安全评审
const registry = new ConnectorRegistry(2);
registry.register({
serverName: "github-mcp",
transport: "stdio",
hosting: "domain",
credentialRef: "credref-1",
trust: "untrusted",
securityReviewPassed: false,
});

业务用户不写任何隔离、审计、配额、持久化代码——定义四类资产，这些由平台提供。

# 12 个契约套件——平台承诺的每条语义都有测试钉死
pnpm contract:llm && pnpm contract:tools && pnpm contract:approval
pnpm contract:ready && pnpm contract:persistence-l1 && pnpm contract:persistence-l2
pnpm contract:pool && pnpm contract:identity-quota && pnpm contract:registry
pnpm contract:session-ops && pnpm contract:lifecycle
pnpm fixtures:selftest

# 规格与文档校验
node tools/lint-specs.mjs && node tools/check-gates.mjs
node tools/validate-contracts.mjs && node tools/lint-docs.mjs

设计原则

1. 强制力只来自域外——层级合法性在 Profile 生成时判定，域内不自我证明（域内自证合规即不通过）。
2. 门禁只接受域外事实——域内上报只能作交叉核验，不一致即摘域。
3. 软依赖绝不阻断执行——计费/一般审计挂了，执行继续；有界丢弃 + 墓碑 + 补传。
4. 做不到就说做不到——每处未完成项都如实登记，不编造数字。

当前状态与边界（诚实版）

• ✅ 六个阶段门禁（GATE-001…006）全部可达，各有证据工件；12 个契约套件全绿。
• ❌ Windows 禁入多租户隔离：容器内 ACL 实测未通过（GATE-002 条件 9，如实 fail）。
• 🔶 演练 3/6：DRL-03/04/06 需要核内组件与多节点拓扑，如实 blocked。
• 🔶 压测参数未回填：PP-01…PP-35 全部为"示例推导值 + 待压测回填"——不编造数字。
• 🚫 无 UI：本仓库交付库与 HTTP API（网关桩），不含产品界面。
• 📦 生产部署需自备执行环境：隔离域的容器/microVM 执行环境不由本仓库实现——部署时由部署者提供基础设施（Linux 容器运行时、企业 IdP、对象存储）并接线；业务用户不受影响。

实现与最初规划的逐层一致性对照（六项全一致，含"Windows 不通过"分支被如实执行），见工程手册。

文档

• 工程手册 — 权威顺序、门禁速查、缺口台账、变更记录（贡献者必读）
• 规格总纲 — 规格集入口
• 故障域矩阵 / 降级阶梯 / DSR 清单

交流群

扫码加入「dsh 企业应用开发技术」微信群，一起讨论 DSH 与 DSH-BOOT 的使用与开发（二维码 10 月 19 日前有效，过期后重新生成）：

License

MIT