问题编排看板EricJiang0423/dsh-orchestrator

English ·

dsh-orchestrator

面向 DeepSeek Harness 的本地优先问题编排器：每个仓库一块看板，每个问题一个全新会话，以及一个自行处理队列的调度器

Cordis 插件 · 工作区范围看板 · 每问题会话 · 自动拉取调度器 · 两道人工审批关卡

功能特性

| 功能特性                  | 描述                                                                                                                                                                                                                                                                         |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 每个仓库一块看板 | 看板绑定到会话的工作目录，而非对话：同一仓库中的两个会话共享一块看板，而另一仓库中的会话看到自己的看板——由宿主进行解析，因此浏览器永远不会混淆项目                                               |
| 每个问题一个全新会话  | “处理此问题”会打开一个全新会话，其中包含该问题的简报，并将问题绑定到该会话，因此每个问题的记录和成本都各自独立——并且可以同时运行多个                                                                                                           |
| 自动拉取调度器      | 调度器最多保持 N 个问题在处理中，并自行从 todo 补充——优先处理最高优先级——看板头部提供并发数和自动拉取开关的实时控制                                                                                             |
| 三道人工关卡 | 智能体永远无法将问题移出 proposed，永远无法将问题标记为 done，也永远无法将其搁置为 archieved：提案需要你的批准，完成的工作需要你的验收，而归档已验收的工作也由你负责——所有这些都在服务层强制执行，而非 UI 层 |
| 持久化审批队列 | 智能体提出的问题会进入 proposed 列，并一直停留在那里，直到人工批准或拒绝——与一次性的审批提示不同，它在重启后依然持久存在 |
| 看板作为聊天对等方 | 看板会注册到对话视图环中，因此它会作为 Chat 和 Trajectory 旁边的标签页出现，而不是一个单独的页面 |

截图

使用示例数据渲染的看板——不包含任何真实部署的项目详情。

看板视图：工作区范围的看板，包含审批队列、调度器条带（自动拉取开关、并行度、实时运行/等待计数），以及正在进行中的问题上的会话标签：

看板视图：proposed、backlog、todo、in progress、in review 和 done 列

问题详情，从卡片展开，显示统一的验收控件——Accept，或 Send back 并附上作为评论落地的原因：

从卡片展开的问题详情，包含验收控件、描述、标签和评论记录

快速开始

前置条件

- Node.js 22.5+
- 一个正在运行的 DeepSeek Harness 配置文件

从源码安装（推荐）

克隆、构建，并将检出目录链接到配置文件中。在检出目录内运行 dsh plugin add . 会注册本地构建，因此之后运行 npm run build 无需重新安装即可被识别：

git clone https://github.com/EricJiang0423/dsh-orchestrator.git
cd dsh-orchestrator
npm install && npm run build
dsh plugin --profile web add .

lib/ 是被 gitignore 的构建输出。当它缺失时，npm test 会自动构建它（pretest 钩子会先运行 npm run build），因此在全新克隆后，你可以在 npm install 之后直接运行测试，无需手动构建。一旦 lib/ 存在，npm test 会跳过重新构建以保持速度——请显式运行 npm run build 来测试你最新的源码更改。

从 npm 安装（注册表）

⚠️ 注册表上未加作用域的 dsh-orchestrator 属于一个无关项目（zibo/dsh-agent-mesh）。本项目发布在某个作用域下：

dsh plugin --profile web add @ericjiang0423/dsh-orchestrator

运行

dsh --profile web

用法

无需离开聊天即可捕获问题

/task Fix the flaky checkout test

从另一个插件调用看板

import type {} from '@ericjiang0423/dsh-orchestrator'
export const inject = ['taskboard']

export function apply(ctx: Context) {
const open = ctx.taskboard.listTasks({ status: 'todo' })
}

调用 RPC 端点

const res = await fetch('/_dsh/taskboard/rpc', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({
method: 'task.update',
params: { id, patch: { status: 'in_review' }, expectedVersion: 3 },
}),
})

配置调度器和规划循环

- id: taskboard
config:
scheduler:
concurrency: 2
autoPull: true
plan:
maxRounds: 16
maxHandoffChars: 8192

架构

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px'}}}%%
graph LR
UI[Board ViewReact] -->|RPC + SSE| SVC[Taskboard ServiceCordis Plugin]
TOOLS[taskboard_* ToolsModel-facing] --> SVC
PLAN[taskboard_planWorkflow Engine] -->|fresh subagents| TOOLS
SVC --> DB[(Storage Domain)]
SVC --> WS[Workspace Registrycwd → workspace]
SCHED[Schedulersession-link] -->|agents.create| ISS[Per-Issue Sessionsctx.agents]
SVC --> SCHED
ISS --> SVC

classDef client fill:#3B82F6,stroke:#2563EB,color:#fff,stroke-width:2px
classDef service fill:#10B981,stroke:#059669,color:#fff,stroke-width:2px
classDef data fill:#8B5CF6,stroke:#7C3AED,color:#fff,stroke-width:2px

class UI client
class SVC,TOOLS,PLAN,SCHED,ISS service
class DB,WS data

浏览器端从不直接与存储通信。每一次读取和写入都经过 ctx.taskboard，无论调用方是看板自身的 RPC 路由、面向模型的工具、规划循环，还是调度器——因此两道人工关卡（不可自行审批、不可自行验收）集中在一处，并对所有调用方生效。调度器是唯一会自行启动工作的组件，并且它只从 todo 中拉取任务，而只有人类才能将议题置入 todo。

配置

| 键                          | 默认值  | 描述                                                                                                                         |
| --------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------- |
| scheduler.concurrency     | 1     | 可同时运行的议题数量；可从看板头部实时更改                                                                                   |
| scheduler.autoPull        | true  | 看板是否自行从 todo 中拉取任务；可从看板头部实时更改                                                                       |
| scheduler.sweepIntervalMs | 30000 | 安全网式清扫，释放被已消失会话占用的槽位                                                                                     |
| plan.subagentProvider     | spawn | 每一轮规划所使用的全新结构化输出子代理提供方                                                                                 |
| plan.maxRounds            | 32    | 单次 taskboard_plan 运行的默认值和上限；调用可以降低它，但绝不能提高它                                        |
| plan.maxHandoffChars      | 16384 | 单轮结构化报告中序列化字符的最大数量；超大的报告会导致运行失败，而不是被截断 |
| plan.maxIssues            | 16    | 单次规划运行中允许纳入的最大问题数量                                                                                |

API

浏览器端通过一个端点 POST /_dsh/taskboard/rpc 与宿主端通信，请求体中包含 { method, params }，而不是为每个资源使用一个 REST 路径。DeepSeek Harness 的类型化 RPC 层需要构建时代码生成，而本插件的构建不会运行该生成，因此该路由被有意设计为显式形式——原因参见 docs/spike-findings.md。

| 方法                | 描述                                                                                    |
| --------------------- | ---------------------------------------------------------------------------------------------- |
| board.view          | 此会话所属的看板（根据其工作区解析），并带有实时调度器状态     |
| project.list        | 列出所有项目                                                                             |
| project.create      | 创建一个项目                                                                               |
| task.list           | 列出问题，可选按项目、状态或会话进行筛选                                |
| task.get            | 读取一个问题及其评论和活动记录                                            |
| task.create         | 创建一个问题                                                                                |
| task.update         | 更改一个问题；拒绝过期的 expectedVersion                                             |
| comment.create      | 向一个问题添加评论                                                                      |
| task.start          | 为某个问题打开一个全新会话，并将工作交给它                                        |
| task.startNext      | 启动下一个 todo 问题——优先级最高者优先——而无需指定具体问题                      |
| task.accept         | 接受已完成的工作（in_review → done）——这是任何代理都无法通过的人工关卡                 |
| task.sendBack       | 将已完成的工作连同原因退回 todo（记录为一条评论），并解除其会话绑定 |
| scheduler.configure | 更改并发数或自动拉取开关；返回结果状态                        |

变更通知通过 GET /_dsh/taskboard/events 以服务器发送事件（Server-Sent Events）的形式流式传输。

目录结构

src/
├── client/              # 浏览器端部分
│   ├── board.tsx         # BoardView：列、卡片、调度器条带、审批 + 验收控件
│   ├── index.tsx          # 客户端插件入口，插槽注册
│   ├── rpc.ts              # 基于 fetch() 的 RPC 客户端 + SSE 订阅
│   └── styles.ts            # 仅布局的 CSS；每种颜色都是主题令牌
├── domain.ts             # Zod schema 和状态机
├── service.ts            # ctx.taskboard：读取、写入、版本 CAS
├── rpc.ts                 # 宿主 RPC 路由 + SSE 变更流
├── tools.ts                # 面向模型的 taskboard_* 工具
├── command.ts               # /task 人类命令
├── plan-loop.ts               # taskboard_plan：固定的规划循环
├── session-link.ts              # 工作区解析、按 issue 的会话、调度器
├── skill.ts                      # 注册 manage-taskboard 技能
├── actors.ts                      # 参与者身份
├── wire.ts                         # 共享的浏览器  宿主 RPC 类型
└── index.ts                        # 插件入口：挂载每一个面
test/                    # node:test 测试套件
skills/manage-taskboard/  # 捆绑的工作约定技能
docs/                     # 扩展点研究笔记

技术栈

运行时

| 技术  | 用途                                                                 |
| ----------- | ----------------------------------------------------------------------- |
| TypeScript  | 插件两半部分的源语言                                  |
| Cordis      | 宿主插件框架：服务、效果、依赖注入          |
| Zod         | 四个存储域表的 schema 验证                    |
| Schemastery | 插件 Config 验证                                              |
| React       | 看板视图渲染（对等依赖，由宿主在运行时提供） |

构建与测试

| 技术          | 用途                                                                  |
| ------------------- | ------------------------------------------------------------------------ |
| esbuild             | 将浏览器半部分打包成宿主所服务的客户端模块封装 |
| Node.js 测试运行器 | node --test，无测试框架依赖                              |

贡献

1. Fork 仓库
2. 创建功能分支（git checkout -b feature/amazing）
3. 提交你的更改（git commit -m 'feat: add amazing feature'）
4. 推送到分支（git push origin feature/amazing）
5. 打开一个 Pull Request

许可证

Apache-2.0。领域模型和 issue 流转规则源自 dashi-taskboard —— 参见 NOTICE。