關鍵不是更多 Agent，而是權責分明

多 Agent 開發流程容易出問題，不一定是模型不夠強，而是大家都以為自己有權決定「接下來該做什麼」或「是否算完成」。比較穩健的設計，是讓 Opus Agent 協調整體目標與工作方向，GPT-6-Sol 獨立檢查成果及門禁是否合理，程式負責依核准範圍執行、驗證和保存紀錄；遇到實質性的方案演進，再請人決定。

以下是建議中的架構，不代表這些連線已經實作：

flowchart TB
    H[人：提供線索、審查變更、作出決策]
    UI[統一入口：TUI／可選 IDE 接入]
    P[目前核准的計畫與 ADR 版本]

    subgraph VPS[Linux VPS 工作區]
        O[Opus Orchestrator：整體目標與偏離度協調]
        R[Astra Research：研究、來源與反證]
        C[Pi＋Sonnet：單一任務的編碼與修復]
        A[GPT-6-Sol：獨立審查成果與門禁]
        K[程式執行核心：授權、流程、驗證、紀錄]
        J[Jev：受限的語意判斷輔助]
        D[持久紀錄：整體進度、待決事項、執行證據]
    end

    N[ana-architect：分析選項與影響，整理決策包]

    H --> UI
    UI --> O
    P --> O
    O --> R
    R --> O
    O --> K
    K --> C
    J -. 不授予權限 .-> K
    C --> K
    K --> A
    A --> O
    O --> K
    K --> P
    K --> D
    O --> N
    A --> N
    N --> D
    D --> UI
    UI --> H
    H --> P
    P --> K

• Opus 是認知協調者：掌握整體目標、安排工作重點、辨認偏離，並協調研究或修復；不是只等程式派發任務。
• 程式是執行核心：確認提議是否落在當前授權範圍，管理啟停、驗證與紀錄；不替人決定哪個產品方向更值得做。
• Sol 負責兩種獨立審查：一是成果是否符合驗收條件，二是流程門禁是否與風險相稱。分開記錄兩種結論，才不會把「測試沒過」和「規則應該修改」混為一談。
• ana-architect 是需要時才啟用的分析流程：遇到 Agent 無法自行裁決的取捨，就整理選項與影響，交給人決定，而非成為另一個常駐主控者。

人工授權應跟著方案版本走

一次批准，不應變成永久授權。更清楚的做法，是把工作切成一個個「核准版本與執行範圍」：在範圍內，Agent 可以安排一般任務、修正錯誤並推進下一步；如果需求改變、需要重大重構、要替換重要 ADR 決策，或要調整驗收與關鍵門禁，就提出新提案，等待人確認。

單純更新進度、補上問題定位或保存執行回執，不算方案演進，不必每次都重新審批。這樣既保留自動推進的效率，也避免「啟動一次就一路跑到底」。

待決事項也不該只丟出一句「流程卡住了」。決策包應說清楚卡點、現有門禁要保護什麼、保留或調整門禁的影響、建議選項及其依據，以及批准後會執行哪些工作。如果沒有實際測量或明確評分標準，就不要捏造選項總分。

人可以批准變更驗收條件或門禁，但紀錄中仍應保留原本的失敗事實，並明確指出新條件取代了什麼；不能把「允許修改規則」寫成「原驗證已通過」。

關閉 IDE 後，待決事項不能跟著消失

如果整體情況散落在 Roo 聊天、Pi 工作階段與 tmux 輸出裡，使用者就得自己拼湊進度。多存幾個狀態檔，並不能取代好用的互動入口。統一介面至少應提供三種視圖：

1. 整體進度：目前核准的目標、各 Epic／Task 的進度、正在工作的角色、阻塞原因與最新檢查點。
2. 變更內容：檔案樹、候選差異、相關驗證結果與獨立審查意見。
3. 待決事項：需要人處理的請求，以及批准、拒絕或要求補充分析的操作。

遇到需要人決定的問題時，系統應先保存請求，再暫停受影響的工作。使用者關閉 IDE 後，背景不可能繼續對著已關閉的視窗回報；合理的做法是保存待決事項，等使用者重新連線時，直接呈現目前進度與需要處理的決定，而不是要求他翻找舊對話。

重新連線介面不等於重啟任務，查看待決事項也不等於恢復舊的模型對話。批准應綁定特定提案版本與執行範圍；若方案已改變，舊視窗中的批准不能自動套用。離線通知可以是額外功能，但通知本身不應成為唯一紀錄，也不應把任意訊息當成有效授權。

IDE 使用方式則不必被限制。使用者仍可自行選擇編輯器；系統需要做的是偵測並行編輯造成的衝突、保留人工修改，並在必要時暫停受影響的執行，而不是假裝能禁止人改檔案。

Cline TUI 值得納入控制介面評估

Cline 官方提供互動式終端介面，可在終端中討論、檢視計畫、批准動作並反覆調整；CLI 也支援無頭自動化工作流。107 官方另有 Agent Teams 和具備獨立上下文的 Subagents，但這些功能目前不等同於 VS Code 或 JetBrains 擴充套件所提供的能力。59

因此，「Opus 主 Agent 協調多個角色，再透過終端與人互動」不該在評估前就被排除。可以優先測試由 Cline CLI／TUI 承載協調與互動、Pi 保留為 Sonnet 執行端、Sol 維持獨立審查，並讓既有程式資產退到執行核心的位置。

不過，採用同一個專案來源，不代表遷移一定簡單。方法論文件或許能沿用，但自訂 Agent 模式、工具權限、啟動回執、Pi 的生命週期，以及待決事項如何呈現，都需要逐項對照。官方文件也明確區分擴充套件與 CLI 在多 Agent 能力上的支援範圍，不能假設換個介面就會自動取得相同的協作能力。59

Cline 本身已有 TUI，因此不必先依賴私人分支才能測試終端互動。10 OpenCode 也提供 TUI 與程式化 CLI，但這不足以證明它就是所提到的 Cline 分支。2 在尚未確認分支來源及功能前，應先檢查它能否呈現整條工作流程、保存並恢復待決事項、接入 Pi 與獨立審查，以及確保檔案差異與驗證結果都對應同一個候選版本。

用一個端到端情境驗收

最值得優先驗證的，不是畫面看起來有多漂亮，而是整個人機交接能否走通：關閉本地介面，讓背景任務繼續；Sol 對某項門禁提出疑問；系統整理分析與選項後等待決定；使用者重新連線，在同一處看到整體進展和待決事項；批准指定變更後，再依新核准版本繼續執行。

這套設計的核心，是「Opus 協調目標、Sol 獨立制衡、人按方案版本決策、介面可隨時重連」。它不是讓程式全權調度，也不是一次授權後永不打擾；程式應把執行做可靠，把需要判斷的選擇留在適當的地方。

關鍵不是更多 Agent，而是權責分明

多 Agent 開發流程容易出問題，不一定是模型不夠強，而是大家都以為自己有權決定「接下來該做什麼」或「是否算完成」。比較穩健的設計，是讓 Opus Agent 協調整體目標與工作方向，GPT-6-Sol 獨立檢查成果及門禁是否合理，程式負責依核准範圍執行、驗證和保存紀錄；遇到實質性的方案演進，再請人決定。

以下是建議中的架構，不代表這些連線已經實作：

flowchart TB
    H[人：提供線索、審查變更、作出決策]
    UI[統一入口：TUI／可選 IDE 接入]
    P[目前核准的計畫與 ADR 版本]

    subgraph VPS[Linux VPS 工作區]
        O[Opus Orchestrator：整體目標與偏離度協調]
        R[Astra Research：研究、來源與反證]
        C[Pi＋Sonnet：單一任務的編碼與修復]
        A[GPT-6-Sol：獨立審查成果與門禁]
        K[程式執行核心：授權、流程、驗證、紀錄]
        J[Jev：受限的語意判斷輔助]
        D[持久紀錄：整體進度、待決事項、執行證據]
    end

    N[ana-architect：分析選項與影響，整理決策包]

    H --> UI
    UI --> O
    P --> O
    O --> R
    R --> O
    O --> K
    K --> C
    J -. 不授予權限 .-> K
    C --> K
    K --> A
    A --> O
    O --> K
    K --> P
    K --> D
    O --> N
    A --> N
    N --> D
    D --> UI
    UI --> H
    H --> P
    P --> K

• Opus 是認知協調者：掌握整體目標、安排工作重點、辨認偏離，並協調研究或修復；不是只等程式派發任務。
• 程式是執行核心：確認提議是否落在當前授權範圍，管理啟停、驗證與紀錄；不替人決定哪個產品方向更值得做。
• Sol 負責兩種獨立審查：一是成果是否符合驗收條件，二是流程門禁是否與風險相稱。分開記錄兩種結論，才不會把「測試沒過」和「規則應該修改」混為一談。
• ana-architect 是需要時才啟用的分析流程：遇到 Agent 無法自行裁決的取捨，就整理選項與影響，交給人決定，而非成為另一個常駐主控者。

人工授權應跟著方案版本走

一次批准，不應變成永久授權。更清楚的做法，是把工作切成一個個「核准版本與執行範圍」：在範圍內，Agent 可以安排一般任務、修正錯誤並推進下一步；如果需求改變、需要重大重構、要替換重要 ADR 決策，或要調整驗收與關鍵門禁，就提出新提案，等待人確認。

單純更新進度、補上問題定位或保存執行回執，不算方案演進，不必每次都重新審批。這樣既保留自動推進的效率，也避免「啟動一次就一路跑到底」。

待決事項也不該只丟出一句「流程卡住了」。決策包應說清楚卡點、現有門禁要保護什麼、保留或調整門禁的影響、建議選項及其依據，以及批准後會執行哪些工作。如果沒有實際測量或明確評分標準，就不要捏造選項總分。

人可以批准變更驗收條件或門禁，但紀錄中仍應保留原本的失敗事實，並明確指出新條件取代了什麼；不能把「允許修改規則」寫成「原驗證已通過」。

關閉 IDE 後，待決事項不能跟著消失

如果整體情況散落在 Roo 聊天、Pi 工作階段與 tmux 輸出裡，使用者就得自己拼湊進度。多存幾個狀態檔，並不能取代好用的互動入口。統一介面至少應提供三種視圖：

1. 整體進度：目前核准的目標、各 Epic／Task 的進度、正在工作的角色、阻塞原因與最新檢查點。
2. 變更內容：檔案樹、候選差異、相關驗證結果與獨立審查意見。
3. 待決事項：需要人處理的請求，以及批准、拒絕或要求補充分析的操作。

遇到需要人決定的問題時，系統應先保存請求，再暫停受影響的工作。使用者關閉 IDE 後，背景不可能繼續對著已關閉的視窗回報；合理的做法是保存待決事項，等使用者重新連線時，直接呈現目前進度與需要處理的決定，而不是要求他翻找舊對話。

重新連線介面不等於重啟任務，查看待決事項也不等於恢復舊的模型對話。批准應綁定特定提案版本與執行範圍；若方案已改變，舊視窗中的批准不能自動套用。離線通知可以是額外功能，但通知本身不應成為唯一紀錄，也不應把任意訊息當成有效授權。

IDE 使用方式則不必被限制。使用者仍可自行選擇編輯器；系統需要做的是偵測並行編輯造成的衝突、保留人工修改，並在必要時暫停受影響的執行，而不是假裝能禁止人改檔案。

Cline TUI 值得納入控制介面評估

Cline 官方提供互動式終端介面，可在終端中討論、檢視計畫、批准動作並反覆調整；CLI 也支援無頭自動化工作流。107 官方另有 Agent Teams 和具備獨立上下文的 Subagents，但這些功能目前不等同於 VS Code 或 JetBrains 擴充套件所提供的能力。59

因此，「Opus 主 Agent 協調多個角色，再透過終端與人互動」不該在評估前就被排除。可以優先測試由 Cline CLI／TUI 承載協調與互動、Pi 保留為 Sonnet 執行端、Sol 維持獨立審查，並讓既有程式資產退到執行核心的位置。

不過，採用同一個專案來源，不代表遷移一定簡單。方法論文件或許能沿用，但自訂 Agent 模式、工具權限、啟動回執、Pi 的生命週期，以及待決事項如何呈現，都需要逐項對照。官方文件也明確區分擴充套件與 CLI 在多 Agent 能力上的支援範圍，不能假設換個介面就會自動取得相同的協作能力。59

Cline 本身已有 TUI，因此不必先依賴私人分支才能測試終端互動。10 OpenCode 也提供 TUI 與程式化 CLI，但這不足以證明它就是所提到的 Cline 分支。2 在尚未確認分支來源及功能前，應先檢查它能否呈現整條工作流程、保存並恢復待決事項、接入 Pi 與獨立審查，以及確保檔案差異與驗證結果都對應同一個候選版本。

用一個端到端情境驗收

最值得優先驗證的，不是畫面看起來有多漂亮，而是整個人機交接能否走通：關閉本地介面，讓背景任務繼續；Sol 對某項門禁提出疑問；系統整理分析與選項後等待決定；使用者重新連線，在同一處看到整體進展和待決事項；批准指定變更後，再依新核准版本繼續執行。

這套設計的核心，是「Opus 協調目標、Sol 獨立制衡、人按方案版本決策、介面可隨時重連」。它不是讓程式全權調度，也不是一次授權後永不打擾；程式應把執行做可靠，把需要判斷的選擇留在適當的地方。