Ticket 驅動的 Agent 協作

coding agent 的瓶頸已從模型能力轉移到人類的注意力。

「人類在哪一層介入」因此成為協作設計的核心問題——這是 OpenAI Symphony 帶來的 paradigm 判斷，比「主 agent 如何拆派子 agent」（機制層，見 Claude-Code-多-Agent-協作）高一個層級。

從管 session 到管 ticket

coding agent 用法演進：auto-complete → 單一互動式 session → 同時開多個 isolated worktree 平行處理。

但人在 3 個以上 session 下會頻繁 context switch、甚至把指令送錯 thread。管多 session 的工具（Superset、Conductor）治標不治本。

關鍵觀察：軟體工作流本來就以 deliverable（issue / ticket / milestone）為單位。工程主管管上千人不是逐 PR 審查，而是看最終產出。

解法：

Scheduler：背景程序定期掃 board，發現 to-do ticket 就建 isolated workspace、起 agent session、管 lifecycle。
WORKFLOW.md：repo 內版控的單一設定檔
- YAML frontmatter = scheduler 設定（撿哪種 status、平行上限、workspace 建好跑哪些 programmatic hook 把環境備好）
- Markdown body = 每回合渲染給 agent 的 system prompt（此 repo 的 ticket SOP、如何驗證、何謂完成、何時找人）
外部 state machine：Linear / Jira / Trello 等，承載 ticket 狀態流轉。

設計刻意保持彈性：不綁 Linear、不綁特定 agent，官方用 SPEC.md 描述設計，可丟給任何 coding agent 改寫到別的 tracker 或語言。

config 與 code 同放、版控、走一般 PR 修改；新增 agent 能力 = 改一份 markdown，其餘流程自動跟上。

OpenAI 給的是 SPEC + Elixir 參考實作，不是 SaaS——任何組織可以自拼：

Tracker：GitHub Issues / Linear / Jira 都行，加 status label 就是 state machine
Scheduler：第一輪人工扮（看到 ready-for-agent 就開 worktree、起 agent）。跑順後再寫 shell script 自動 poll。真的需要 supervisor（pause blocking、restart crashed）才照 SPEC 刻
agent：Claude Code / Codex / 任何 coding agent

先跑一輪再自動化：第一張 ticket 挑低風險、純執行的任務（例如批量 refactor、文件補欄位）——驗證的是流程合不合身，不是 agent 能不能寫複雜功能。

Symphony 能跑的前提是環境調好，讓 agent 拿到所有需要的東西。harness 三件事：

高 ROI 解是 Playwright CLI：

這呼應 vault 反覆出現的立場——通用 CLI / skill 按需呼叫優於常駐 MCP（見 Harness-Engineering）。