New AI coding paradiagm - OpenAI Symphony
三句話摘要
OpenAI 的 Symphony 框架如何透過 Ticket 層級編排，解決多重編碼代理的認知負荷問題。 --- Symphony 透過將代理管理從 session 層級提升至 ticket 層級，配合自動化驗證與 skill 體系，讓人類得以無痛管理無限數量的並行工作，是編碼代理工作流的典範轉變。 從 Session 到 Ticket 的範式轉變：傳統工作流以代理 session 為中心，工程領導無法有效監督。Symphony 借鑒數十年來工程管理的實踐，改為在 Ticket（Issue/Task/Milestone）層級運作，讓人類透過 Linear 這類系統掌握最終交付成果，而非逐個監看 PR。
重點整理
重點- 1
從 Session 到 Ticket 的範式轉變：傳統工作流以代理 session 為中心，工程領導無法有效監督。Symphony 借鑒數十年來工程管理的實踐，改為在 Ticket（Issue/Task/Milestone）層級運作，讓人類透過 Linear 這類系統掌握最終交付成果，而非逐個監看 PR。
- 2
簡單但有效的架構設計：背景進程定期掃描 Linear board，自動為「待辦」票據創建隔離工作空間並啟動代理。整個系統無需中央配置服務或管理面板，所有配置都寫在 workflow.md，使版本控制與協作變得直觀。
- 3
Workflow.md 的雙重角色：上半部 YAML front matter 配置 scheduler（專案 ID、輪詢頻率、並行代理數等），下半部 Markdown 則是代理的標準操作流程（如何規劃、驗證、何時請求人工審查）。同一檔案既控制排程器也指導代理，避免配置散落。
- 4
自動化驗證的關鍵—— Playwright CRI 與 Skill 體系：Playwright CRI 可記錄瀏覽器會話為 MP4/WebM 影片並上傳至 Linear，讓驗證流程可視化。配合自訂 skill（如 Grafana 日誌查詢、本地伺服器啟動等），代理可完全自主地端到端執行任務並提供證據。
- 5
--
實用技巧與重點
乾貨- 檢查頻率：每 30 秒
- 工具與平台：Linear（任務追蹤）、Playwright CRI（視頻錄製）、Code X / Cloud Code（代理）、Elixir / Python 實現版本
- Linear 設定步驟：
- 建立 Linear 帳號 → 新增專案 → 複製專案 slug → 進入設定 > 安全 & 存取 > 新增個人 API 金鑰
- 執行 `linear auth` 全域儲存 API key
- 基本指令：
- `symphony --help`（查看幫助）
- `symphony path/to/workflow.md --background`（啟動背景進程）
- `linear auth <YOUR_API_KEY>`（授權 Linear）
- Ticket 狀態流：待辦 → 進行中 → 人工審查 → 合併（自動觸發 PR）
- 文件清單：workflow.md、spec.md（系統設計規格）、skill 檔案（代理能力庫）、agent.md/CLAUDE.md（文件索引與除錯說明）
- 社群擴展：已有人基於 spec.md 用 Python 重寫、用 Cloud Code 取代 Code X、建立自訂 TUI dashboard
- --
結論
結論“Symphony 透過將代理管理從 session 層級提升至 ticket 層級，配合自動化驗證與 skill 體系，讓人類得以無痛管理無限數量的並行工作，是編碼代理工作流的典範轉變。”
完整解析
詳細編程人員在過去幾個月間，使用編碼代理的方式已發生根本轉變。最初是自動補全，後來演進為實時互動 session，如今多數人同時運行 2 至 3 個並行 session，各自在隔離的工作樹上開發不同功能或修復 bug。雖然 Superset、Conductor 等工具協助管理多個 session，但問題依然存在——人類無法有效切換上下文，甚至誤將指令發送到錯誤的執行緒。瓶頸不再是模型能力，而是人類的認知負荷。
OpenAI 的洞察在於：傳統工作流圍繞 session 和 PR，但軟體組織實際上已數十年圍繞任務單位（Issue、Task、Ticket、Milestone）運作。工程領導不會逐一審查千名員工的 PR，而是透過 Linear、Atlassian 等系統監督最終交付物。Symphony 的核心理念就是「將人類向上提一個層級」——不是管理 2-3 個 session，而是管理 ticket，由代理在 ticket 層級報告進度，人類無須監看個別 session 就能保持掌控。
Symphony 的實現簡潔而高效。啟動一個後台進程，指向 workflow.md 文件，它就永遠運行。每 30 秒，進程掃描 Linear board，發現任何「待辦」ticket 就建立隔離工作環境並啟動代理。系統有三個核心部分：（1）Scheduler——後台進程，輪詢 ticket 並管理 session 生命週期；（2）workflow.md——位於代碼庫內，包含 YAML 配置和代理操作指南；（3）Linear 等外部系統——作為人類與代理互動的狀態機。workflow.md 的 YAML 前置部分配置 scheduler（專案 slug、票據類型、並行代理數、Code X 設定等），Markdown 部分則是代理每次執行的標準操作流程，包括如何規劃任務、驗證成果、何時請求人工審查。由於檔案在代碼庫內版控，任何變更都走 PR 流程，新增能力時只需修改 markdown 檔案即可。
該框架特別靈活——不必使用 Linear，可改用 Trello 或 Jira；不必用 Code X，可用任何代理。OpenAI 提供的 Elixir 實現是起點，若要客製化或改用其他語言，只需指向 spec.md 讓代理自行重建。實施時先克隆 Symphony repo、建立 Linear 專案、獲取 API key（存到全域環境變數 `linear auth`），然後執行 `symphony path/to/workflow.md --background`。Ticket 進入「待辦」時，Symphony 自動將其改為「進行中」並啟動代理；代理完成後改為「人工審查」供人類檢視；最後改為「合併」時，代理自動提起 PR。
關鍵支撐工具是 Playwright CRI，它能錄製瀏覽器會話為 MP4/WebM 並上傳至 Linear ticket，使驗證流程可視化。配合自訂 skill 檔案（如 Grafana 日誌查詢、本地伺服器啟動步驟、Linear API 操作指南），代理可自主完成端到端任務並提供影片證據。許多開源實現已在社群中出現，包括 Python 版本、自訂 TUI 儀表板、Cloud Code 集成等。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
