01 · 开源插件 · 2026.10 至今
CLI Worker Now
DeepSeek Harness 的多智能体协作插件：在主对话里派遣 Codex、Claude Code 等 13 种 AI CLI 分工协作，每个 Worker 有名字、有角色，可以按名字续聊，过程在侧栏统一查看。
- 我的角色
- 产品负责人（个人开源项目）
- 技术与平台
- DSH 插件 · TypeScript / React · macOS / Windows
- 当前版本
- v0.8.4，持续迭代
- 用户反馈
- 7 个外部 Issue 全部关闭
按 DeepSeek Harness 桌面端的真实界面还原，数据为本地示例，不连接真实 CLI。
- 派遣 Worker：在主对话点示例指令或输入后发送，右侧出现新卡片，状态从排队中到运行中再到已完成。
- 查看 Worker：点卡片进入 Worker 的原生对话，可在里面继续派活，再返回列表。
- 切换权限与模型：在 Worker 输入框下切换访问模式、模型与推理等级。
- 打开设置：点右上角齿轮，看调度与时限、智能体预设和 13 种 CLI 的连接页。
从一个痛点到持续迭代
从自己的使用痛点出发，经过 PRD、MVP 和方案转向，走到外部用户反馈闭环。
- 01
问题
我在 DeepSeek Harness（DSH）里把多个 AI CLI 当作子 Agent 使用时，每个 CLI 的对话散落在不同地方，谁在做什么、做到哪一步，很难追踪。动手之前，我横向调研了 herdr 等同类产品，看清楚这类工具各自怎么组织多个 Agent。
- 02
产品思路
主对话负责派遣和接收结果，侧栏统一展示每个 Worker 的过程和状态。每个 Worker 有唯一的名字，可以套用角色预设；任务结束后，在主对话里点名就能接着做。CLI 仍使用各自的账号、模型和原生会话，插件只负责把它们组织起来。
- 03
需求文档
与 AI Agent 协作撰写 PRD，梳理用户问题、功能范围、权限规则与验收标准；开发中用 OpenSpec 管理 22 份能力规格、164 条需求、527 个验收场景。
- 04
协作开发
把开发任务交给 AI Agent 执行，按能力规格和验收场景对照实现结果。
- 05
发布与验收
从首个 Release v0.6.5 到 v0.8.4 共发布 10 个正式版本；v0.8.4 的 macOS 自动回归 4,702 项通过、0 失败，Windows 全量回归仍有失败项，单独记录、继续跟进。
- 06
反馈与运营
按自身需求与外部 Issue 排期；7 个外部 Issue 全部关闭，从提出到关闭中位约 1 天；发布 5 篇介绍与教程，建立了用户交流群。
方案转向：从自绘对话页到桥接原生会话
第一版能跑起来，但用下来发现方向不对。我没有在原方案上继续打补丁，而是重新评估后换了实现路线。
- MVP：用 JSON 流式输出自绘对话页读取各 CLI 的 JSON 流式输出，自己画一套对话界面，先验证“主对话派遣 + 侧栏查看”成立。
- 首个 Release v0.6.5第一个正式版本在 GitHub 开源发布。
- 自绘页面越做越吃力问题集中在四点，见下方对照。
- v0.8.1：桥接 Harness 原生会话参考 codex-host、Codingns4DSH 的做法，让每个 Worker 直接使用 Harness 原生对话视图。
- 难以还原 CLI 的工作状态：流式输出里的信息，拼不回 CLI 原本的工作过程。
- 不能插入图片或文件：用户没法把图片、文件交给 CLI 读取。
- 与原生对话页有差距：交互和观感总和 Harness 自己的对话页差一截。
- 维护负担大：每多一个功能，就要在自绘页面里再实现一遍。
- 界面交给宿主：子会话直接使用 Harness 的对话视图、输入框、模型与权限控件和“+”菜单。
- 能力跟着原生走：图片和文件通过原生输入框交给 CLI，排队、停止和续聊与原生一致。
- 插件专注组织：只负责派遣、命名、角色、权限和状态汇总，不再重复造对话页。
关键数据
数据取自 2026-10-30；下载次数不等于用户数。