dsh-kingdom
DSH 里的 Agent 王国:领地、角色绑定/换届/会话归属(含模型/Agent 身份),plan→派发→执行→验收治理闭环(Worker 自述≠完成事实),附本地 GUI 操作台。
安装
dsh plugin --profile web add dsh-kingdom
沙箱测试结果
| 阶段 | 结果 |
|---|---|
| 1 安装 | ✗ |
| 2 列装 | — |
| 3 挂载 | — |
| 4 启动 | — |
dsh: initialized profile web at /home/node/.dsh/profiles/web四阶段在隔离沙箱里跑:安装(有网)→ 列装 → 挂载 → 启动(后三步断网)。
README
<div align="center">
🏰 dsh-Kingdom
在 DeepSeek Harness 里,装一个插件,拥有一个自己的 Agent 王国。





</div>
这是什么?
3.3.0 的日常工作台只有三个入口:运行总览、派发任务、主管设置。先向 DSH 会话说明需求,再由 AI 核对实际任务、领地和角色。绑定或更换主管时,会话准备完整的人类管理窗口命令,你核对预览、确认并读回结果,无需编辑 JSON 或手查内部编号。先看 [当前使用指南](docs/CURRENT-USER-GUIDE.md) 和 [3.3 版本说明](docs/V3.3-RELEASE-NOTES.md)。
3.2.1 修复派发前关联、可靠接受回执与只读恢复对账,收紧受理/验收的换绑窗口,并明确资源占用后的重新请求要求。输入缺失仍为 UNKNOWN,不提供安全作废或自动重发。查看 [3.2.1 版本说明](docs/V3.2.1-RELEASE-NOTES.md)。
3.2.0 把主管与领地完全绑定:任命主管时必须同时指定它的领地,席位与领地主理在同一事务里原子写入(不再可能留下"有主管、没领地"的中间态);一个领地至多一个在任主理,一个主管席位只主理一个领地;退任主管时同时解除其领地主理。同一版还修掉了交付记录区的版面塌陷。查看 [3.2 版本说明](docs/V3.2-RELEASE-NOTES.md)。
更早的 3.0.0 在 2.0 个人工作台之上加入 Owner 交付清单:逐条查看、知悉、核对主管确认的改动证据,并就具体条目向接受交付的主管提问。交付由 Owner 主动查看,宰相目前不会自动上报。查看 [3.0 使用指南](docs/V3.0-USER-GUIDE.md)、[版本说明与验证范围](docs/V3.0-RELEASE-NOTES.md) 和 [功能介绍](docs/DSH-KINGDOM-3.0-ANNOUNCEMENT.md)——3.0.0 的功能是随 3.1.0 一并发布的。已有任务、协作、用量与软预算能力见 [2.0 指南](docs/V2.0-USER-GUIDE.md)。
dsh-Kingdom 是一个 DeepSeek Harness(DSH)插件:产品目标是在不另行部署外部服务、独立数据库或单独 GUI 前端的前提下,在 DSH 中创建并运行一个属于自己的最小王国——
你:初始化王国
DSH:已创建王国「My Kingdom」,你成为 Owner
你:给当前项目建一个 RAG 研发领
DSH:已创建领地「RAG 研发领」
你:让 Chancellor 把"检查测试情况"规划成任务,Supervisor 派给 Worker,
再通过 `kingdom_start_task_governed` 执行并验收
DSH:任务 CREATED → ASSIGNED → RUNNING → REVIEW → DONE ✅
插件实现本地持久化语义:角色、领地、任务和验收记录写入本地 SQLite;正式数据库迁移仍须按对应版本的迁移边界执行。
✨ 核心特性
特性 · 说明
🚀 随包交付 · 从官方 npm 或 GitHub 获取版本包;内置 GUI 随 lib/** 交付,无需独立前端
🧭 三个日常入口(3.3) · 运行总览查看任务、已登记会话、领地和状态;派发任务集中创建、指派与启动;主管设置由目标会话准备绑定或接替引导
🏛 完整角色体系 · Owner / Chancellor / Supervisor / Worker,角色与 Session / 模型解耦
📋 治理闭环语义 · 规划 → 分配 → 独立执行 → 验收,任务状态全程留痕
⚖️ Claim ≠ Fact · Worker 说自己完成了 ≠ 任务完成——完成权只在 Supervisor,代码强制,不是口头约定
🧭 主管与领地完全绑定(3.2) · 任命主管必须同时指定它的领地,席位与领地主理同一事务原子写入;一个领地至多一个在任主理,一个主管只主理一个领地;退任主管时同时解除其领地主理。存量"未隶属领地"的席位不会被自动归属,只在界面上标注待处理
👁️ Owner 逐条知悉与提问(3.0) · 交付摘要和细项独立呈现;知悉只记录 Owner 声明已知道该内容版本,不代替质量认可或任务完成;问题记在接受该交付的主管名下,待其主动读取并回复
🧾 改动证据(3.0) · 主管确认属于本交付的文件改动可展开查看,包括有界的未提交差异快照;标明证据级别,不把 Git 时间窗口误称为 Worker 作者证明
👷 Persistent Governed Worker · canonical headless 路径使用 kingdom_start_task_governed:Worker 绑定长期 DSH Session,结果结构化返回并经 Capability/Lease 治理
🔁 返工留痕 · governed REWORK 复用同一 Worker Persistent Session;每次尝试(attempt)都有独立 Lease/Execution 记录
💾 持久化与恢复语义 · 状态写入本地 SQLite;无法确认原执行时保持恢复核对,由主管先对账,不自动重发
🔄 换届与会话归属(v0.4) · kingdom_unbind_role 解绑 / kingdom_bind_session 把角色绑到独立会话;session-bound 模式下只有被绑定会话能行使职权
🪪 会话身份预留字段(v0.4) · 角色可携带 model_name / agent_name / session_meta(JSON 扩展槽)——现在不必填,未来完整会话逐步填满
🎛 内置本地 GUI(v1.0) · 直接执行 /kingdom gui 打开操作台,进行会话绑定的任务规划、指派、持久治理执行与审查;Owner 配置由人类直接命令或准确激活的管理窗口确认
👑 Persistent Governed Worker(v0.8) · Worker 拥有长期 DSH Session(REWORK 唤醒同一 Worker);Session ↔ Territory Affinity 不可改绑;每次执行经 Capability Gate(仅 GRANTED+ENFORCED 才 dispatch,Runtime 无法 enforce → DENIED + zero execution);Execution Lease 互斥 + Dispatch Intent(crash 可 reconcile,不盲发);terminal 证据来自事件链,Runtime 跑完 ≠ Task DONE(Claim → Supervisor 裁定链不变)。这是 canonical headless 路径
🛡️ Fail-closed 能力治理(v0.8) · 无自授 / 超 Ceiling / scope 外 / 部分 policy 一律拒绝;approval=never 禁扩权;workspace 外写真实拒绝;RECOVERING 状态如实显示,禁止显示成 Done
🧩 Legacy 兼容(v0.8) · kingdom_start_task 仅在用户明确选择时作为 LEGACY_COMPAT one-shot 入口;不会作为默认路径、错误恢复建议或 persistent 失败 fallback
🚀 快速开始
1. 前置要求
- DeepSeek Harness(dsh):本版 peer 声明与 3.1.0 相同,覆盖
0.1.5-rc与0.1.7-0两条线;构建与回归在 CLI0.1.5-rc.1/ 主要组件0.1.5-rc.2上完成。0.1.7-rc.2的实机加载在 3.1.0 已验证(无 bundle 跳过,见 [3.1 版本说明](docs/V3.1-RELEASE-NOTES.md));完整宿主和真人交互验收须以各版记录为准(peer 声明未变,但不要把它当作已验证)。旧宿主请继续使用对应旧版插件 - Node.js ≥
22.19(内置 SQLite,插件零原生依赖) - 一个可用的模型 API key(Worker 执行需要)
2. 安装 v3.3.0
从官方 npm 3.3.0 获取准确版本包,再安装到自己的 DSH Web profile:
npm pack dsh-kingdom@3.3.0 --registry=https://registry.npmjs.org dsh plugin --profile web add ./dsh-kingdom-3.3.0.tgz
也可从 GitHub v3.3.0 Release 下载同名 tgz,执行第二条命令。安装或升级后重启原 Web profile,才会加载新包;使用其他 profile 时替换 web。升级前先核对未决执行并一致备份 SQLite。
内置 GUI 随 lib/** 包含在 tgz 中,不需要额外 GUI zip:
/kingdom gui # 激活短期本地控制会话并打开内置操作台 /kingdom status # 也可以从 DSH 会话查看王国真实状态
Owner 是本机人类操作者,不是 Agent 或 Session。管理操作可由用户直接键入
exact /kingdom Slash,或从 /kingdom owner.gui 准确激活的独立短时管理窗口完成;OWNER.session_id 永远保持 null。Chancellor、Supervisor、
Worker 才使用真实 DSH caller session 的会话绑定(session-bound)角色平面;历史
declarative / local-demo 语义不能解锁产品写入。
3. 用 GUI 完成最小治理闭环
先向 DSH 会话里的 AI 说明需求,完整步骤见 [当前使用指南](docs/CURRENT-USER-GUIDE.md)。历史版本指南保留供对应安装包参考。
1. 向 AI 说:“帮我查看 dsh-Kingdom 当前的王国、领地、角色和任务;先说明缺少哪些配置,再逐项引导我确认。”已有配置就继续使用;缺少配置时,由会话准备准确输入并说明人类确认步骤。
2. 在本地 DSH 会话直接键入 exact /kingdom gui;若本机浏览器完成带 ticket 的导航,一次性入口兑换后会重定向到干净的 /console。若本机打开请求失败,控制会话虽已激活,但命令只显示不含 ticket 的干净 /console 参考地址;该地址不能完成一次性兑换,不要手工拼接或复用启动值,直接重新执行 /kingdom gui。
3. 运行总览查看任务、已登记会话、领地和状态;派发任务集中创建、指派与启动;主管设置复制绑定或更换请求,再到希望接任的会话交给 AI 引导。宰相会话创建任务,任务领地的主管会话指派、启动和审查。网页选择名称不会切换身份;切换会话后从该会话重新打开工作台。
4. Worker 输出只会进入待审状态 REVIEW。Supervisor 选择接受 ACCEPT 后才进入 DONE;返工 REWORK 回到 RUNNING 并保留同一 Assignment,判定失败 FAIL 进入 FAILED。不用时执行 /kingdom gui stop 撤销控制会话并关闭本地 server。
绑定主管可直接向目标会话说“让当前会话负责「前端」”;更换时说“把「前端」主管换成当前会话”。AI 准备完整窗口命令,你直接复制执行,打开链接、核对预览并确认,成功后再读回绑定。更换沿用原席位;如果该席位关联多个领地,引导会列出全部影响,确认后这些领地会一起由新会话负责。只想接替其中一个时停止确认,先让会话说明调整安排。
Owner 专属 JSON Slash 命令只
…(truncated)
以上内容来自 npm 上的 README,我们只做格式化,不改内容。
版本
npm 上共发布:15,最后更新 2026-10-13