前言¶

用智能体写代码，最容易出问题的往往不是「会不会改文件」，而是流程本身站不住。plan 写了一半就开始动手，QC 变成口头同意，status.json 和真实分支对不上，子代理递归把自己派出去——这些事只靠 prompt 提醒，模型随时可以绕过去。

DeepSeek Harness（dsh）把模型、工具、技能、会话和工作流都做成可替换插件，官方仓库的原话是 everything is a plugin。社区目录 DeepSeek Harness 插件库 是独立站点，与 DeepSeek / 幻方没有从属关系，用来发现这类插件。目录把 mstar-harness 归在「开发与运行时」，维护者是 btspoony。

本文按插件目录页、GitHub 仓库 README / README_CN.md、plugin.json、packages/dsh 文档、CHANGELOG 和官方 deepseek-ai/deepseek-harness 核对后整理：它是什么、门禁怎么执行、在 dsh 上怎么装、三种入口怎么用。

这是什么¶

mstar-harness 在仓库里的产品名是 Morning Star（启明星）。它是面向 harness 工程工作流的 Agent Plugin：TypeScript 引擎 @mstar-harness/engine 强制执行确定性门禁，mstar-* 技能负责角色、门禁判断和工作流编排。目录页的简介是「技能驱动的 Harness/Loop 工程工作流智能体插件」。

仓库归属 GitHub 用户 btspoony，根清单 plugin.json 里的作者是 Bohao Tang，插件包名为 morning-star-harness。许可证是 MIT，主要语言是 TypeScript。GitHub 仓库带有 dsh-plugin topic。截至 2026-08-17 核实时，仓库 46 星，最新发布标签是 v2.3.0（2026-08-16）；根清单、CLI、引擎和 @mstar-harness/dsh 都对齐到这个版本。

它要解决的问题可以收成一句：把「看起来像工作流」变成「引擎真的会挡」。门禁跑在 TypeScript 里，而不是只写在提示词里。判断规则仍以 mstar-* 技能为唯一事实来源（SSOT）。同一套引擎和技能还可以接到 omp、OpenCode、Cursor、Kimi Code、ZCode、Codex；README 给出的推荐宿主顺序是 dsh = omp ≥ OpenCode ≥ Cursor > Kimi = ZCode > Codex。本文只展开 dsh 这一条。

核心功能¶

仓库当前交付四块：

引擎强制执行，判断留在技能里¶

README 把边界写得很清楚：确定性门禁由引擎执行；角色怎么分工、什么时候过闸、迭代怎么收口，仍以技能文本为准。dsh 专用包 @mstar-harness/dsh 是一个 cordis 函数插件，把引擎挂进当前进程，实现 HostAdapter（host: 'dsh'），并且不改 dsh 自带工具本身，只走 seam 上的拒绝 / 咨询通道。

挂载之后，packages/dsh 文档列出的能力包括：

• 状态门禁：校验 {HARNESS_DIR}/status.json 的写入。
• 派发门禁：在 subagent / subagent_fork 执行前校验 Assignment 文本（字段、反递归、默认分支），再加 dsh 侧的 lease 与 worktree 检查。
• 技能与产物 lint：对挂载技能根下的 SKILL.md，以及 DESIGN.md、审计计划、知识文档等写入做引擎级检查。
• bundled 命令：向 ctx.commands 注册 /iteration-start、/iteration-drive、/iteration-loop、/codebase-audit。
• catalog 行：每个组合后的 agent 步骤追加一条 mstar-engine-status，带版本、harness 目录、enforcement，以及 plan / residual / 分支 / lease 等摘要。
• Web 工作流面板：CHANGELOG 写明 web 客户端会挂「MStar 工作流」面板，用 catalog 证据画阶段环和 plan 状态机。

默认是 warn-only：违规会打日志、发 advisory，动作仍继续。要变成真正否决，需要迭代 compass、Assignment 头或插件配置里把 enforcement 设成 hard。文档同时说明：状态 / 技能 lint 在 hard 模式下对「已经不合法的文件」会放行修复写入，避免修文件本身被门禁卡死。

三种工作流入口¶

README 把用法收成三种，不跑迭代时走同一套 per-plan 门禁：

1. 不跑迭代：进入 PM，然后按 Prepare → Execute → QC → QA gate → Done 推进单个 plan 或 hotfix。
2. 跑迭代：Phase 1–5，从方向锁定、compass、集成分支，到执行、收口、开 PR、merge-ready。
3. 代码库审计：只读扫描，产出带优先级的改进计划，不改源码。

消费方 plan 默认落在 .mstar/。进程产物（plans/、iterations/、status.json、sdd/ 等）按约定 gitignore；跟踪进仓库的是 {HARNESS_DIR}/AGENTS.md、knowledge/、specs/。

角色与技能¶

先加载 mstar-harness-core，再按 mstar-roles 按需加载专题技能。角色包括：project-manager（路由、分派、阶段推进）、product-manager、architect、fullstack-dev / fullstack-dev-2、frontend-dev、qa-engineer、code-reviewer、qc-specialist 三审、ops-engineer、writing-specialist、prompt-engineer。

和流程直接相关的技能还有：mstar-phase-gates、mstar-iteration、mstar-dispatch-gates、mstar-sdd、mstar-branch-worktree、mstar-plan-artifacts、mstar-review-qc、mstar-audit、mstar-host，以及 dsh 上的 PM 入口技能 pm。

安装与启用¶

先有 DeepSeek Harness。官方仓库当前的启动方式是：

npx @deepseek-ai/dsh web

官方 README 标明项目仍处于 developer preview，会有破坏性变更。Web UI 默认在 http://127.0.0.1:3080。

社区目录页给出的安装命令原文是：

dsh plugin add github:btspoony/mstar-harness

需要可复现安装时，目录页的写法是把 commit 哈希钉在后面（把 commit 换成真实哈希）：

dsh plugin add github:btspoony/mstar-harness#commit

仓库自己的安装说明和目录页不完全一样，这里以仓库 README 为一手来源。dsh 不走 npx @mstar-harness/cli init（该 CLI 没有 dsh target，只覆盖 omp / OpenCode / Cursor / Kimi / ZCode / Codex）。在 dsh 上，README 和 @mstar-harness/dsh 文档推荐用宿主自带的 profile bundle：

dsh plugin --profile web add @mstar-harness/dsh

这是 npm 上的发布形态，当前版本与仓库 release 2.3.0 对齐，安装时不需要再构建。本地改插件则进入 packages/dsh 后执行 dsh plugin --profile web add .，并且要先 bun run build。

基于角色的 subagent persona 配置是可选能力，文档要求用第二条独立命令安装，不要把它折进 mstar 自己的 bundle：

dsh plugin --profile web add dsh-llm-fallbacks

不装这一条时，mstar 插件仍可启动；persona 会退回到包内 harness-agents/ 镜像或插件配置。

目录页的安全提示需要照读：插件以当前 dsh 进程的权限运行，安装时可能执行代码。安装前检查源码仓库和 MIT 许可证。

典型用法¶

dsh 上 PM 不会自动加载。README 写的是通过 mstar skill 提供者使用 pm 技能。迭代类命令则已经打进 harness-commands/，在 web 客户端里点选后会先把 /命令名 填进输入框，带参数 hint，按 Enter 才提交。

1. 单 plan / hotfix：不跑迭代¶

进入 PM 后，从 status.json 选中一个 active plan，按 Prepare → Execute → QC → QA → Done 走完。QC 默认是三审；QA gate: mandatory 时由 qa-engineer 做验收，否则可以由 PM 按 acceptance 清单收口。还有残留 findings 时，要在 status.json 里登记或明确接受，不能静默标成 Done。

2. 多 plan 迭代¶

三条命令都来自仓库 README 和 commands/：

/iteration-start [direction] [pause]
/iteration-drive
/iteration-loop [direction] [scale]

• /iteration-start：Phase 1 做交互式 grill-me，锁定 compass 和集成分支，然后默认自动进入 Phase 2→5。加上 pause 则停在 Phase 1，之后用 /iteration-drive 续跑。
• /iteration-drive：在已经锁定的迭代上恢复 Phase 2→5。
• /iteration-loop：Phase 1→5 全自动，不做 grill-me；可选 direction，以及规模 S|M|L|XL。

Phase 2 默认是每个 plan 一个 worktree 加 lease，并且 Findings cleanup: zero-residual。只有显式写 Worktree mode: waived 或 Findings cleanup: allow-residual 才能改掉这两条。

3. 只读审计，先搞清楚该做什么¶

/codebase-audit [关键词]

文档强调：只读顾问，不改源码。产出写到 {PLAN_DIR}/audit-.../，可以再喂给 /iteration-start 的 Research，或走普通 Prepare → Execute。

关键词按 README：

• 深度：quick / deep（默认 standard）
• 类别：security、perf、tests 等
• 范围：branch（仅当前分支变更）、next / roadmap（只出方向候选）、simplify（聚焦技术债：死码、重复、投机性、过度构建）

适用场景与注意事项¶

比较适合已经在用 dsh web profile、希望把多智能体交付收成可检查状态机的人：要 plan 登记、分支 / worktree、QC 三审、QA 门禁，并且希望违规时至少能留下引擎级证据。仓库把自己和 omp 并列写成推荐宿主，dsh 上还有 catalog 行和工作流面板，信息会比纯技能文本完整一些。

使用前值得先看这几条边界：

1. 插件跟当前 dsh 进程同权限，能读写工作区、拦截工具调用。不信任源码就不要装。
2. DeepSeek Harness 仍是 developer preview，mstar 的 @deepseek-ai/dsh-* peer 也按 rc 线对齐。升级 dsh 之后，以仓库 CHANGELOG 和 @mstar-harness/dsh 文档为准复查兼容性。
3. 默认 enforcement 是告警不是硬拦截。需要真正挡住派发，必须显式打开 hard。
4. {HARNESS_DIR} 从会话工作区根探测（.mstar/ → .agents/ → .plans/ → plans/），不会从启动 cwd 往上走到 ~/.mstar。仓库根不叫这些名字时，要在插件配置里设 harnessDir。
5. 目录页的 github:btspoony/mstar-harness 和 README 的 @mstar-harness/dsh 是两条安装路径。在 dsh 上优先按仓库当前文档使用 profile bundle；若用目录页命令，装完后确认实际挂上的是预期包。

小结¶

mstar-harness 不是又一份「请按步骤干活」的提示词合集。它把 path、status、lease、dispatch 这些门禁做成 TypeScript 引擎，把判断留在 mstar-* 技能里，并在 dsh 上提供 PM 入口、迭代命令、只读审计和 Web 工作流面板。当前发布面是 2.3.0，MIT 许可。

目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/mstar-harness/

GitHub：https://github.com/btspoony/mstar-harness