haofu-star/pangu-dsh

Pangu DSH

集中智能，分布执行。

让高智能模型决定应该做什么。
让高性价比模型规模化完成具体怎么做。

当前状态：Experimental / Developer Preview

Pangu DSH 是一套实验性的 Agent Control Plane，用于把高智能模型产生的计划，委派给运行在 DeepSeek Harness 上、受到明确能力约束的高性价比执行模型。

它试图回答一个简单的问题：

最适合决定“做什么”的模型，是否真的需要亲自完成后续每一次工具调用？

很多 Agent 系统先给高智能模型大量工具，再通过 sandbox、policy、approval 和 guardrail 约束它不要失控。

Pangu 从另一个方向出发：

将战略智能与执行权分离。

在目标架构中，高智能模型定义意图。
Control Plane 把意图转成结构化任务与权限。
DSH 提供执行运行时。
高性价比模型真正执行任务。
确定性程序负责状态、证据以及能够机械完成的验证。

一句话：

将军有眼睛，但没有手。

为什么做 Pangu？

长程任务里通常混合着两种完全不同的工作。

战略工作需要强智能：

- 理解模糊需求；
- 拆解复杂任务；
- 做架构选择；
- 定义约束；
- 决定什么叫完成。

执行工作往往更机械：

- 读写文件；
- 实现有限修改；
- 跑测试；
- 失败重试；
- 收集证据；
- 完成大量可并行子任务。

Pangu 真正想验证的是：

昂贵智能能不能规划一次，便宜智能执行很多次，同时尽量不丢失原始意图？

因此核心边界是：

Executor 的自由主要体现在“如何完成”，而不是无限制地重新决定“完成什么”。

架构

目标架构（简化）：

高智能 Planner
│
│ 战略 / 意图
▼
┌───────────────┐
│     Pangu     │
│ Control Plane │
│               │
│ TaskSpec      │
│ Capability    │
│ State         │
│ Evidence      │
└───────┬───────┘
│
▼
┌───────────────┐
│      DSH      │
│   执行底座     │
└───────┬───────┘
│
▼
高性价比 Executor
│
▼
结果 + 证据
│
▼
确定性 Verifier

可以把它理解成一套军团工作模式：

将军下达军令，军团负责执行，Pangu 负责让军令在传递过程中尽量不走样，并把战果带回来。

当前已经实现什么？

当前公开仓库是：

可运行的实验基线，而不是完整目标架构。

当前已实现并验证：

- Executor 通过 DSH Adapter 执行；
- Task 级 CapabilityGrant；
- runtime operation 白名单；
- 状态转换权限分离；
- Executor 无法直接声明 DONE；
- 确定性、零 LLM Verifier；
- 持久状态、attempt、lease 与重启恢复；
- append-oriented Event Store 与哈希链；
- 受控写执行链；
- 可选隔离交付；
- 最小端到端示例；
- 多组负向和 failure-path 测试。

Public release 验证基线：

41 个测试文件
286 个测试
285 passed
1 skipped
0 failed
TypeScript typecheck：PASS
Secret scan：0 leaks
最小 DSH E2E：PASS

详细证据：

- Claims Audit
- Known Limitations
- Preflight Report
- Security Review

六个核心协议对象

当前实现围绕六类对象组织：

PlanSpec
TaskSpec
CapabilityGrant
ExecutionResult
EvidenceManifest
VerificationReport

它们分别对应：

意图 → 任务 → 权限 → 执行声明 → 证据 → 验证

核心原则之一是：

执行不等于验收。

完成工作的人，不应该天然拥有定义自己是否成功的最终权力。

当前 Verifier 返回：

PASS
FAIL
UNCHECKED

UNCHECKED 是刻意保留的：如果确定性程序无法证明一件事，就不应该制造一个假的 PASS。

为什么选择 DSH？

Pangu 把 DSH 定位成：

执行底座，而不是 Control Plane。

DSH 的插件化架构非常适合未来的异构执行层：

Task A → Model A → Plugin Set A
Task B → Model B → Plugin Set B
Task C → Model C → Plugin Set C
Task D → 确定性程序

长期方向是：

集中意图，分布执行。

理想情况下，Control Plane 描述“这个任务需要什么能力”，而不是硬编码“哪个模型最好”；执行层再把 capability requirement 映射到具体 worker。

Quick Start

环境要求：

- Node.js ^22.19.0 或 >=24.0.0
- npm
- dsh-v0.1.0-rc.7 的 DeepSeek Harness checkout（见下方构建步骤）

git clone https://github.com/haofu-star/pangu-dsh.git
cd pangu-dsh
npm ci

Control Plane 通过 DSH 执行，DSH 需要先 checkout 并构建：

git clone --depth 1 --branch dsh-v0.1.0-rc.7 https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install --frozen-lockfile   # 需要 pnpm 11.x
npm run build:lib
cd ..

配置 DSH checkout 路径为环境变量（在当前 shell 中 export，使后续命令均可见）：

export CONTROL_PLANE_DSH_REPO=/path/to/deepseek-harness

运行：

npm run build
npm run typecheck
npm test

npm test 依赖 CONTROL_PLANE_DSH_REPO（集成测试会执行真实 DSH）。可选的安全扫描需要先安装 gitleaks：

npm run scan:secrets

最小 E2E（基于真实 DSH，需先 npm run build）：

node examples/minimal-e2e/demo.mjs

examples/minimal-e2e/

demo 会在仓库内生成本地运行时状态（.control-plane/ 与 evidence/，均已 gitignore，不入库）；不会触碰 checkout 之外的任何仓库。

链路如下：

Plan
↓
Task
↓
CapabilityGrant
↓
DSH execution
↓
ExecutionResult
↓
EvidenceManifest
↓
VerificationReport

安全边界

Pangu 不是生产安全边界，也不保证在任意模型失控情况下都能完全兜底。

拥有合法写权限的 Executor 仍然可能写错东西，Verifier 也可能遗漏语义问题，未知 edge case 一定存在。

因此 Pangu 区分：

- Hard Boundary：值得通过确定性机制硬性禁止的行为；
- Controlled Autonomy：Executor 在明确权限内拥有的战术自由；
- Recoverable Failure：更适合通过检测、恢复、重试或升级处理的错误。

目标不是：

阻止一切可能的错误。

而是：

尽量保持上游意图，压缩执行权限，让执行可观察，并对那些值得硬拦截的行为提供确定性边界。

目标方向

完整目标架构还包括：

- 可观察但原则上无直接执行权的高智能 Planner；
- 确定性 Policy Enforcement；
- 多来源、异构 Executor Pool；
- 并行和并发执行；
- 基于 Task capability 的 worker routing；
- 必要时的语义升级；
- 战果重新汇总到战略层。

这些属于目标架构，并不都是当前 public release 已实现能力。

项目状态

Experimental / Developer Preview

当前已经能够运行：

受约束 Task
↓
CapabilityGrant
↓
DSH execution
↓
结果 + Evidence
↓
确定性 Verification
↓
可选 Delivery

适合用于架构研究、实验、批评和继续开发，目前不应被视为生产安全边界。

License

MIT

将军下达军令，军团负责执行，Pangu 负责让军令在传递过程中尽量不走样，并把战果带回来。