workflow / schedule / plan / todo：編排原語的取捨

四個真實場景，每個場景選一個原語。選錯也沒關係，判詞會講清楚為什麼。點「播放」可以看自動講解，自己點卡片可以隨時搶答。

先給結論：這四個原語沒有共享一個任務引擎，它們連持久化形態都不一樣。workflow 是一次性的：模型寫一段 JS 腳本，引擎在 node:worker_threads 的 vm 裡執行，腳本裡的 agent() 打回宿主起子 Agent，跑完只留結果與展示記錄，邏輯本身不落成持久狀態機。schedule 是持久的：create、dispatch、delete 都是 schedule/change 會話事件，回放日誌就能重建全部提醒狀態。plan 更輕，就是一個 plan/mode 布林事件的日誌摺疊。todo 是快照：每次 todo_write 整表替換，UI 靠投影渲染最新一份。

大綱裡那個問題「多步編排應該是模型寫腳本還是框架狀態機」，DSH 的回答是兩個都要，但分工明確。執行編排交給模型寫腳本，因為編排邏輯千變萬化，框架預設不完；時間、姿態、展示交給框架狀態機，因為這三樣需要跨輪次甚至跨重啟的確定性，模型的腳本給不了。workflow 文件自己說了，它的 meta 欄位詞彙與 Claude Code 的 dynamic workflows 對齊（workflow.zh.md 第 41、49 行），思路同源，落點不同。

還有一條容易忽略的紀律。workflow 腳本裡拼錯一個 agent() 選項，拋的是 fatal: true 的 WorkflowError，parallel() 組合器對它直接重拋、終止整個腳本；只有子 Agent 真實的執行失敗才對映成逐項的 null（workflow.zh.md 第 116 行）。寫錯程式碼和執行失敗是兩類錯誤，混在一起腳本就沒法調了。

先看 schedule 的固定速率決策，這是本課唯一值得整段看的程式碼：會話離線錯過了 N 個到期時點，恢復後不逐個補發，一次除法直接算出最新一次到期，再把記錄推進到未來。不列舉、不回放、不積壓：

  const steps = Math.floor((acceptedAt - target) / interval)
  const occurrence = target + steps * interval
  /* v8 ignore next -- bounded operands and a quotient-derived product stay safe. */
  if (!Number.isSafeInteger(occurrence) || occurrence < target || occurrence > acceptedAt) {
    throw new ScheduleLogError('every occurrence arithmetic must stay within the accepted interval')
  }
  const occurrenceAt = new Date(occurrence).toISOString()
  const next = occurrence + interval

第二條邊界是 plan mode 的生效時機，邏輯用文字講。使用者在模型流式輸出時點了切換，外掛不立刻寫日誌，選擇先掛在行程記憶體的 pending 裡，等下一個輪內 pre-step 邊界才動手。順序講究得很：監聽器先 await next() 問下游這一步收不收，下游拒絕、訊號已取消或者沒有 pending，都原樣放行；三關都過了才把選擇追加進日誌。追加萬一失敗，只記一條 warn 日誌然後放行這一步，絕不因為一次姿態切換失敗就阻塞整個輪次。這也回答了崩潰語義：pending 只活在行程記憶體，切換還沒落日誌時崩潰，重啟後 plan mode 維持切換前的狀態。

出處：packages/plan/plan-mode/src/index.ts 第 205 至 218 行的 agent/pre-step 監聽器，核對日期 2026-08-13。

todo 那條最有態度的設計不用貼程式碼：allowParallelInProgress 是必填配置，schema 裡寫的是 z.boolean().required()，沒有預設值（packages/todo/tool-todo/src/index.ts 第 41 至 43 行）。允不允許多個任務同時進行中，取決於這個部署跑不跑併發子 Agent，工具自己觀測不到，所以強制部署方表態。設成 false 後，模型多標一個進行中就吃 Error: invalid todos: at most one task may be in_progress（第 107 至 109 行）。

Claude Code 走的是聚合路線：七種非同步工作（shell 命令、本地子 Agent、遠端 Agent、Teammate、工作流、MCP 監控、記憶整合）統一掛在一個 Task 框架下，共享 registerTask、updateTaskState、kill 一套生命週期（書稿 study/chapters/06-task-system.md 第 27 至 47 行引 tasks/types.ts）。DSH 相反，subagent 文件明確寫著可繼續路徑「不會建立 Task，也不會建立承載中間結果的包裝層」，四個編排原語更是各有各的持久化形態。聚合換來統一的進度 UI 和管理入口，拆分換來每個原語能把自己的語義說到底，比如 schedule 的錯過合併、plan 的 pending 切換，塞進統一框架裡都得妥協。

todo 這個小工具上的分歧最能看出兩家的脾氣。Claude Code 的 TodoWrite 在提示詞裡硬編碼了紀律：「Exactly ONE task must be in_progress at any time (not less, not more)」，條目還要求 content 加 activeForm 雙形態，執行中顯示進行時文案（書稿 study/chapters/14-all-prompts.md 第 1243 至 1293 行引 TodoWriteTool/prompt.ts 原文）。DSH 把同一條紀律做成了必填的部署配置：跑併發子 Agent 的組合選 true，單執行緒紀律選 false，選了 false 就由程式碼拒絕而非提示詞勸告；條目形狀刻意最小，只有 content 和三態 status。一個用提示詞約束模型，一個用 schema 約束部署，然後讓程式碼執行。