前言¶

用 DeepSeek Harness Web GUI 干活的团队，通常会遇到两类具体问题。一是任务缺少落点：只能在对话里口述待办，窗口一关、上下文一冲，任务就丢了；需要自己的任务面板就得再起一个服务，跟 GUI 割裂。二是智能体执行任务缺少交接面：谁来领任务、执行到什么程度、结果如何回写，全靠对话约定，进度和结果不可追溯。下面介绍 hfanshu 维护的 dsh-kanban 插件，它把这两件事收进了 Web GUI：一个多列看板做任务管理，一套原生工具加定时投递让 AI 自己领活、回写状态。

这是什么¶

dsh-kanban 是 DeepSeek Harness Web GUI 的热插拔任务看板插件，资料将它归入工作流分类。它提供任务管理、拖拽排序、状态跟踪和持久化存储，并在此之上拼接了自动任务执行与飞书等远端表格同步。许可证是 MIT，仓库版本 1.1.0，要求的 Node 版本为 ^22.13.0 || >=24.0.0。

核心功能¶

1、多列看板：默认五列，planned（待规划）、todo（待办）、in-progress（进行中）、review（评审中）、done（已完成）；列定义在 cordis.patch.yml 中可改。
2、拖拽排序：卡片可在列间拖动，修改 status 与 order。
3、任务属性：低/中/高/紧急四级优先级，截止日期、描述、标签。
4、SQLite 持久化：路径 $DSH_HOME/dsh-kanban.db，DSH_HOME 缺省为 ~/.dsh；日志模式 WAL + synchronous=NORMAL。插件卸载时会 checkpoint 并关闭连接。
5、自动任务：定时器从「待办」列取任务投递给 AI，AI 通过六个原生 kanban_* 工具（kanban_list / claim / progress / comment / complete / fail）回写状态。
6、远端同步：飞书多维表格与企业微信文档（智能表格）双后端，支持手动导入导出、定时自动拉取、完成时自动推回。

安装与启用¶

安装命令来自仓库 README：

# 从 GitHub 源码安装（推荐）
dsh plugin --profile web add github:hfanshu/dsh-kanban

# 或从本地目录安装（开发模式）
dsh plugin --profile web add link:/path/to/dsh-kanban

官方注明需要 DeepSeek Harness ≥ 0.2.1-rc.3，因为插件使用 sessionController 投递、session/event 事件钩子与原生工具注册。安装后启动 Web GUI，在侧边栏或顶部导航找到「任务看板」入口即可。

插件的配置写入 cordis.patch.yml。仓库实际文件里的 name 是 dsh-kanban-plugin，默认五列：

- insert:
    - id: kanban
      name: 'dsh-kanban-plugin'
      config:
        enabled: true
        maxTasks: 1000
        columns:
          - id: planned
            title: '待规划'
            color: '#9ca3af'
          - id: todo
            title: '待办'
            color: '#60a5fa'
          - id: in-progress
            title: '进行中'
            color: '#a78bfa'
          - id: review
            title: '评审中'
            color: '#fbbf24'
          - id: done
            title: '已完成'
            color: '#34d399'

README 中的示例配置块只写三列且 name 为 dsh-kanban，与仓库当前文件不一致；以仓库文件为准即可。

自动任务是怎么跑的¶

自动任务的机制写在 README.zh.md 中，顺序如下。

1、插件启动时注册六个原生模型工具与一段系统提示词工作流指引。
2、定时器触发时，调度器从「待办」列取第一个任务，按配置的执行方式投递给 AI：默认是「每个任务新建独立会话」，经 sessionController.create() 为任务开一条新对话并挂到任务所属项目下；另一种是「投递到现有会话」，通过 agent.followup() 把任务追加到当前空闲会话，都不空闲则选最新会话排队。
3、AI 在会话中执行任务，用 kanban_* 工具汇报进度、记录结果。
4、事件驱动兑现：轮次干净结束 → 任务自动移入「评审中」并附 AI 结果摘要，人工评审后拖入「已完成」；AI 明确标记失败 → 保持进行中等待重试；基础设施错误 → 自动回到「待办」下个周期重试。
5、带执行会话的任务，在看板点击卡片可直接跳转到对应对话。

注意一个边界：没有任何活跃会话且模式为「投递到现有会话」时，任务保留在「待办」，下一个周期重试；「新建独立会话」模式不依赖已打开的会话。

用 HTTP API 操作任务¶

插件按 /api/dsh-kanban 前缀暴露接口，返回体统一为 { "success": true, "data": ... } 或 { "success": false, "error": "..." }。

# 获取全部任务（按状态分组返回）
curl http://localhost:3080/api/dsh-kanban/tasks

# 创建任务
curl -X POST http://localhost:3080/api/dsh-kanban/tasks \
  -H "Content-Type: application/json" \
  -d '{"title": "新任务", "priority": "high"}'

# 移动任务
curl -X PATCH http://localhost:3080/api/dsh-kanban/tasks/{task_id}/move \
  -H "Content-Type: application/json" \
  -d '{"status": "in-progress", "order": 0}'

# 删除任务
curl -X DELETE http://localhost:3080/api/dsh-kanban/tasks/{task_id}

面向智能体的任务协议还有四个端点，配套的 skills/manage-task/SKILL.md 给出了标准工作流：

# 认领任务：从 todo/planned 移到 in-progress，并发出 task:claimed 事件
curl -X POST http://localhost:3080/api/dsh-kanban/tasks/claim \
  -H "Content-Type: application/json" \
  -d '{"taskId": "abc123", "message": "开始处理"}'

# 汇报中间进度：不改状态，发出 task:executing 事件
curl -X POST http://localhost:3080/api/dsh-kanban/tasks/progress \
  -H "Content-Type: application/json" \
  -d '{"taskId": "abc123", "message": "已完成数据读取，正在写代码"}'

# 记录结果：发出 task:comment 事件
curl -X POST http://localhost:3080/api/dsh-kanban/tasks/comment \
  -H "Content-Type: application/json" \
  -d '{"taskId": "abc123", "message": "改动、验证结论、遗留风险"}'

# 完成任务：移到 done，发出 task:completed 事件
curl -X POST http://localhost:3080/api/dsh-kanban/tasks/complete \
  -H "Content-Type: application/json" \
  -d '{"taskId": "abc123", "message": "完成并验证通过"}'

SKILL.md 明确要求「先认领再动手」：只认领 todo 或 planned 状态的任务，同一时间只认领一个，失败要显式标记而不是把任务留在中间状态。这套约定价值在于把「谁在干活、干到哪了、结果如何」变成结构化状态，而不是散落在对话里。

飞书同步的配置¶

飞书集成的前置条件是飞书开放平台的企业自建应用与一张多维表格，应用需要 bitable:app 权限并已发布版本。在 cordis.patch.yml 中填入凭证与字段映射：

feishu:
  appId: 'cli_xxxxxxxxxx'
  appSecret: 'xxxxxxxxxxxxxxxxxxxx'
  appToken: 'abc123def456'
  tableId: 'tblXXX'
  fieldMapping:
    title: '标题'
    description: '描述'
    status: '状态'
    priority: '优先级'
    tags: '标签'
    assignee: '负责人'
    dueDate: '截止日期'
    project: '项目'

多维表格的字段名需要与 fieldMapping 完全一致（区分大小写）。同步接口有三个：

# 检查飞书连接状态
GET   /api/dsh-kanban/feishu/status

# 从飞书导入任务到看板
POST  /api/dsh-kanban/feishu/sync-from

# 从看板导出任务到飞书
POST  /api/dsh-kanban/feishu/sync-to

也有图形界面入口：看板界面有「从飞书同步」「同步到飞书」按钮。状态值会自动映射，例如飞书的「待规划、规划中」映射到看板 planned，「评审中、评审」映射到 review，其他值（含失败/取消）回落为 todo。README.zh.md 还提到企业微信文档（智能表格）后端，需要自建应用的 corpid 与 secret、可信 IP 配置，以及可访问的智能表格文档。该部分没有独立文档，仓库中仅 feishu.ts 对应飞书实现，企业微信细节建议以源码为准。

适用场景与注意¶

适用的人：已经在用 DSH Web GUI 管理项目、希望任务有持久化面板、并想让 AI 按既定协议认领和回写状态的开发者。它也适合需要把任务表与飞书多维表格对齐的团队。

需要留意的地方：

1、插件以当前 dsh 进程权限运行，自动任务会以该进程身份在对应项目里建会话、执行命令。安装前应先读一遍源码，确认 kanban_* 工具和投递逻辑符合预期。
2、许可证为 MIT，但仓库星标数很低，更新频率未知，选它意味着自己承担后续维护判断。
3、自动任务依赖 sessionController 与 session/event，需 DSH ≥ 0.2.1-rc.3；低版本装不上或功能不完整。
4、历史迁移方面，首次启动会自动导入 dsh-kanban.json（及 auto-task / feishu 旧配置文件），原文件改名为 .bak 保留。USAGE.md 中仍写着旧版 JSON 存储与五列中的旧命名，与 README.zh.md 的 SQLite 说明不一致，判断时以 README 与当前 cordis.patch.yml 为准。
5、API 返回 401 时，相关资料的排查建议是确认已安装并启用 dsh-auth 插件、持有有效 JWT 令牌。

小结¶

dsh-kanban 的价值在于把看板、AI 执行与远端表格串成一条链路：人建任务、AI 认领执行、状态自动流转到评审、结果可同步到飞书。如果你在 DSH Web GUI 里已经并行跑多个会话，它省去了在聊天窗口里记待办的心智负担。目录页见 https://www.skillhub.cn/plugins/hfanshu/dsh-kanban ，源码见 https://github.com/hfanshu/dsh-kanban 。