前言¶
用 DeepSeek Harness（下文简称 DSH）做智能体开发，迟早会碰到一类任务：目标要跑几天甚至更久，中间会话断了、进程崩了，进度就丢了；即便 agent 一直在跑，它自己报告「做完了」，你也没法确认环境里真的做完了。
单次会话解决不了这两个问题。dsh-mission 的思路是把长期目标拆成任务依赖 DAG，交给一个持久的运行时去推进：跨会话、每个任务独立验证、失败重规划、崩溃可恢复。模型只负责提出和规划，状态变更由运行时裁决和提交。
下面介绍这个插件的定位、核心机制、安装与用法。
这是什么¶
dsh-mission 是 qiaoy01 维护的 DSH 插件，npm 包为 @qiaoy01/mission，版本 0.2.0，MIT 许可证。它是一个纯 TypeScript 的 cordis 插件，以插件形式接入 DSH 组合，提供的正是 DSH 缺失的那一层：长周期自主 mission 运行时。
设计上它遵守一条核心原则：agent 提出、环境裁决、运行时提交。落到执行层面就是 report ≠ verify：
- agent 的计划、执行与认领都不具权威性；
- 报告（report）只是 agent 对环境的一次声明，声明本身不产生 DONE；
- 验证（verify）独立地把声明与环境反馈对齐，只有通过确定性校验、以单个会话事件原子提交的状态变更才算数。
一句话概括：worker 不能自我认证。
核心功能¶
任务依赖 DAG 与状态机¶
先做拆解：mission_plan 提交一张任务依赖 DAG，运行时据此派生每个任务的状态——上游任务完成后，下游任务才进入 READY，否则是 BLOCKED。
状态机分两层。mission 有 CREATED / RUNNING / COMPLETED / FAILED / CANCELLED 五个状态；任务有 PENDING / CLAIMED / DONE / FAILED 四个基础状态，外加派生的 READY / BLOCKED。
事件溯源持久化¶
所有状态变更以 mission/* 会话事件写入，一个事件就是一次原子提交，不需要独立数据库。并发提交用 revision CAS 做版本守卫（镜像 dsh-goal 的 GoalRef 模式），提交计划时 revision 必须等于当前值 + 1。
自主驱动宿主 mission-driver¶
mission-driver 监听 mission/changed 事件，自动执行完整的循环：
claim → subagent 执行 → report → verify → commit
也就是说，plan 提交之后运行时接管：mission-driver 认领任务、派发真实 subagent、独立验证，直到 mission 到达 COMPLETED。README 里明确了一条纪律：模型不应自己执行任务。
租约回收与崩溃恢复¶
认领任务附带租约。过期未上报的 claim 会被惰性回收，任务可以重做；in-flight 任务守卫保证同一个任务不会被重复派发。进程崩溃后，靠这两条机制恢复执行。
失败重规划¶
卡住的 mission 生成新的 revision 进行重规划，规格未变的 DONE 任务保留，不会推倒重来。默认配置下不自动重规划，这是刻意的保守设计，见下一节。
可选模型策略¶
默认配置保守：任务选择用确定性逻辑、不自动重规划，模型成本为零。想让模型参与决策，需要在 profile 行配置里显式启用：
- llmDecider：模型挑选下一个执行的任务；
- llmReplanner：mission 卡住时由模型重规划；
- userApprovalGate：审批门。
触发与配套组件¶
- mission-trigger：软引导提示加
/mission斜杠命令，把会话里的触发语句路由到 mission_create / mission_plan； - mission-invariant：容忍型伴侣组件，存在 invariants 服务时注册审计，否则为 no-op；
- UI 数据面：mission 会话投影单元。Stage E 中投影已完成，浏览器 UI 仍在开发中。
安装与启用¶
npm 包已预构建（lib/），消费者只需要一条命令，把插件装进某个 profile：
dsh plugin --profile <name> add @qiaoy01/mission
比如装进名为 web 的 profile：
dsh plugin --profile web add @qiaoy01/mission
如果想修改或审查代码，再从源码构建：
git clone https://github.com/qiaoy01/dsh-mission.git
cd dsh-mission
npm install
npm run build
dsh plugin --profile <name> add file:.
file:. 指向刚才 cd 进去的仓库根目录。改动源码后，重新执行 npm run build 并重新 add 即可。
依赖方面，插件通过 peerDependencies 声明了对 @deepseek-ai/cordis、@deepseek-ai/dsh-agent、@deepseek-ai/dsh-invariants、@deepseek-ai/dsh-llm、@deepseek-ai/dsh-session、@deepseek-ai/dsh-session-projection、@deepseek-ai/dsh-subagent、@deepseek-ai/dsh-tools、@deepseek-ai/dsh-commands、@deepseek-ai/dsh-system-prompt 以及 zod 的依赖，由运行 DSH 的宿主组合提供。
典型用法¶
经过上面的安装步骤，就可以在会话里使用了。agent 通过四个模型工具操作 mission：
- mission_create：创建 mission；
- mission_plan：提交任务 DAG，revision 必须等于当前值 + 1；
- mission_status：读取当前状态；
- mission_cancel：取消 mission。
README 给了一个 30 秒上手的例子：
# 1. 把插件装进一个 dsh profile
dsh plugin --profile web add @qiaoy01/mission
# 2. 在会话里对 agent 说：
# "mission: build a small web game. Use mission_create, then mission_plan,
# then stop — the runtime will execute the tasks."
流程是：先用 mission_create 建目标，再用 mission_plan 提交任务 DAG，然后模型停下。此后运行时接管，mission-driver 认领任务、派发真实 subagent、逐个独立验证，直到 mission 变成 COMPLETED。模型只负责创建与规划，不执行任务。
按 README 的记录，这条流程已在真实组合中验证过：一个 7 任务 DAG 由真实 subagent 端到端驱动至 COMPLETED，每个任务独立验证，零失败、零重复派发。
默认这套流程零模型成本。要启用模型策略，在 profile 行配置里加：
- id: mission-driver
config:
decider: llm # 模型挑选下一个任务
replan: true # mission 卡住时由模型重规划
适用场景与注意¶
适合的场景：
- 目标跨越多次会话，需要断点续跑；
- 不信任 agent 自报结果，要求每个任务在环境侧独立验证；
- 执行环境会崩溃、重启，需要租约回收与恢复机制。
三点注意：
- 默认配置保守（确定性任务选择、不自动重规划），模型策略需通过 profile 行配置显式启用；
- 浏览器 UI 仍在开发中，当前可用的数据面是 mission 会话投影单元；
- 插件以当前 dsh 进程的权限运行，安装前建议先审查源码与许可证（MIT），确认可信再装。
小结¶
回顾一下：dsh-mission 把长期目标拆成任务依赖 DAG，由 mission-driver 自主推进 claim → 执行 → report → verify → commit 的循环；agent 自报不算数，验证在环境侧完成；失败可重规划、崩溃可恢复，默认配置零模型成本。对需要跨会话推进长期目标的 DSH 用户来说，这是一个装一条命令就能试的运行时。
- 社区目录页：https://www.skillhub.cn/plugins/qiaoy01/dsh-mission
- GitHub 仓库：https://github.com/qiaoy01/dsh-mission
（目录页为社区独立站点，与 DeepSeek / 幻方无官方从属关系。）
