前言¶
用 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 / 幻方無官方從屬關係。）
