一套面向 AI 編碼 Agent 的工作流程，近日提出修訂方向：唔再由程式控制器代替 Agent 判斷「應該做乜」，而係由 Opus 負責整體目標協調、GPT-6-Sol 獨立審核，程式則專心確保工作喺獲批範圍內安全執行。

另一個重點係人工把關唔應該得兩個極端——每一步都要人撳掣，或者一開始批准之後就一路自動跑。建議做法係：已批範圍內可以自動推進；一旦涉及重大方案演進，就停低交返畀人決定。

四個角色，各自負責乜？

呢個係建議中的目標架構，唔代表各個系統已經接駁完成。

• **Opus Orchestrator：**負責理解整體方向、安排工作重點、識別偏離，以及協調研究和修復。佢係主動判斷嘅協調者，唔係單純等程式派工作。
• **Astra Research：**按需要做研究，整理來源和反證，再交畀 Opus 參考。
• **Pi＋Sonnet：**處理單一任務的編碼或修復；同一個任務可以開新上下文，減少其他工作干擾。
• **GPT-6-Sol Reviewer：**獨立檢查程式是否符合驗收要求，亦審視流程門檻係咪太繁複、同風險是否相稱。

程式本身就做執行內核：檢查工作有冇超出目前授權、啟動或停止任務、跑驗證，同埋保存證據。至於「應唔應該改產品方向」，唔由程式代人決定。Jev 可以協助判斷範圍、風險或故障類型，但唔會因此得到額外權限。

如果 Sol 對驗收門檻有疑問，兩件事要分開記錄：一是今次測試有冇通過，二是現行規則本身係咪合理。前者係驗證結果，後者先係政策取捨。

人工授權應該跟住方案版本走

建議以「已批准版本＋執行範圍」管理工作，而唔係一次批准就授權一條永久運作的長循環。

• 已批範圍內的任務排序、一般修復和下一項工作，可以自動推進。
• 需求有變、涉及重大重構、要取代關鍵 ADR 決定，或者要改重要驗收及門檻，就要整理成新提案，等人決定係咪繼續。
• 更新進度、補充問題位置、保存執行紀錄，唔算方案演進，唔需要每次都重新批核。

如果門檻令工作卡住，決策文件唔應只問「要唔要繼續」。應該講清楚門檻原本保護乜、保留或放寬有咩影響、替代方案係乜，以及批准之後會執行邊個範圍。若果冇實際量度數據或明確評分標準，就唔好整一個貌似精準的總分。

人可以批准更改驗收要求，但要保留原本失敗的紀錄，清楚標明新要求取代咗乜，並按新要求重新驗證。批准修改規則，唔等於舊測試突然變成通過。

介面要處理「重連」，唔係淨係存檔

如果整體狀況分散喺 Roo 聊天、Pi 對話同 tmux 輸出，人就要自己拼返成個局面。單靠加幾個狀態檔，未必解決到呢個問題；真正需要的是一個可以離開再返嚟、而且睇得返全局的人機控制面。

建議統一介面至少有三個視圖：

1. **整體進度：**目前批准的目標、各個 Epic／Task 進展、邊個角色正工作、阻塞原因和最近檢查點。
2. **變更內容：**檔案樹、候選版本的差異、相關驗證結果和獨立審核意見。
3. **待決事項：**目前等緊人決定的提案，以及批准、拒絕或要求補充分析的選項。

如果人關閉 IDE，系統唔可能繼續喺已關閉的視窗顯示訊息。合理做法係先保存決定請求、暫停相關工作，等人重新連接時一眼睇到全局同待辦決定，而唔使翻查舊對話檔案。

幾個概念亦要分清楚：重新連接介面唔等於重新啟動任務；睇到待決事項唔等於恢復舊模型對話；批核亦要綁定具體提案版本和執行範圍，舊視窗的批准唔應套用到已經改過的方案。離線通知可以另行考慮，但通知唔可以取代正式紀錄，亦唔應將任意訊息當成授權。

至於 IDE，使用者仍然可以自由選擇。系統要做的是發現多人或多工具同時改檔造成的衝突，保留人的修改，並暫停受影響的工作，而唔係假設可以限制使用者開邊個編輯器。

Cline CLI／TUI 值得重新評估

Cline 官方文件列出互動式終端介面，可以用嚟討論、檢視計劃、批准操作和繼續迭代；Cline CLI 亦支援無頭自動化工作流程。107 官方亦提供 Agent Teams 和 Subagents 等多 Agent 功能，但相關功能適用於 CLI、SDK 或桌面版，唔等同 VS Code 或 JetBrains 擴充套件的能力。59

所以，「Opus 做主協調者、多個角色分工、再用終端同人互動」唔應該未試過就排除。可優先評估由 Cline CLI／TUI 承載主協調和人機互動，保留 Pi 作 Sonnet 執行端，再接入 Jev 和獨立的 Sol 審核；原有程式則保留做執行內核。

不過，方法論文件可以沿用，唔代表整套系統可以原封不動搬過去。Roo 自訂模式、工具權限、啟動回執、Pi 工作流程，以及待人決定的狀態，都要逐項對照。尤其官方文件已列明 CLI／SDK 和 IDE 擴充套件之間的多 Agent 能力差異，唔好當換個介面就自然得到同一套協調功能。59

目前未有足夠根據判斷遷移規模。與其即刻全量改寫，或者繼續一口否決 Cline，不如先做一條小型接駁測試。

TUI 好唔好用，關鍵係能否看見整條工作流

Cline 官方已有 TUI，所以要用終端操作，唔一定要靠私人分支。10 OpenCode 官方亦提供終端介面和程式化 CLI；但呢點唔能夠證明它就是用家提到的 Cline 分支。2

評估簡潔 TUI 或其他工具時，最重要係睇佢能否顯示整條工作流，而唔只係某一個 Agent 的對話；能否保存並恢復待決事項；以及 Pi 和獨立審核能否接入同一套狀態。檔案樹、差異檢視和驗證結果亦要指向同一個候選版本，否則介面再順手，都可能只係換咗一個地方睇零散資訊。

下一步應該驗收乜？

建議將以下情境作為下一階段的核心測試：關閉本地介面，讓後台繼續處理；Sol 對某個門檻提出疑問後，系統整理分析並等人決定；人重新連接時，可以喺同一處睇到整體進度和待決提案；批准指定變更後，系統再按新版本繼續執行。

呢個方向將「Opus 協調目標、Sol 獨立制衡、人工按版本作決定、介面可重連」放喺核心位置，而唔係由程式全權調度、將 IDE 當成只讀畫面，或者一次批核就放任流程一路跑。呢次整理係架構建議，並無修改檔案或啟動任務。

一套面向 AI 編碼 Agent 的工作流程，近日提出修訂方向：唔再由程式控制器代替 Agent 判斷「應該做乜」，而係由 Opus 負責整體目標協調、GPT-6-Sol 獨立審核，程式則專心確保工作喺獲批範圍內安全執行。

另一個重點係人工把關唔應該得兩個極端——每一步都要人撳掣，或者一開始批准之後就一路自動跑。建議做法係：已批範圍內可以自動推進；一旦涉及重大方案演進，就停低交返畀人決定。

四個角色，各自負責乜？

呢個係建議中的目標架構，唔代表各個系統已經接駁完成。

• **Opus Orchestrator：**負責理解整體方向、安排工作重點、識別偏離，以及協調研究和修復。佢係主動判斷嘅協調者，唔係單純等程式派工作。
• **Astra Research：**按需要做研究，整理來源和反證，再交畀 Opus 參考。
• **Pi＋Sonnet：**處理單一任務的編碼或修復；同一個任務可以開新上下文，減少其他工作干擾。
• **GPT-6-Sol Reviewer：**獨立檢查程式是否符合驗收要求，亦審視流程門檻係咪太繁複、同風險是否相稱。

程式本身就做執行內核：檢查工作有冇超出目前授權、啟動或停止任務、跑驗證，同埋保存證據。至於「應唔應該改產品方向」，唔由程式代人決定。Jev 可以協助判斷範圍、風險或故障類型，但唔會因此得到額外權限。

如果 Sol 對驗收門檻有疑問，兩件事要分開記錄：一是今次測試有冇通過，二是現行規則本身係咪合理。前者係驗證結果，後者先係政策取捨。

人工授權應該跟住方案版本走

建議以「已批准版本＋執行範圍」管理工作，而唔係一次批准就授權一條永久運作的長循環。

• 已批範圍內的任務排序、一般修復和下一項工作，可以自動推進。
• 需求有變、涉及重大重構、要取代關鍵 ADR 決定，或者要改重要驗收及門檻，就要整理成新提案，等人決定係咪繼續。
• 更新進度、補充問題位置、保存執行紀錄，唔算方案演進，唔需要每次都重新批核。

如果門檻令工作卡住，決策文件唔應只問「要唔要繼續」。應該講清楚門檻原本保護乜、保留或放寬有咩影響、替代方案係乜，以及批准之後會執行邊個範圍。若果冇實際量度數據或明確評分標準，就唔好整一個貌似精準的總分。

人可以批准更改驗收要求，但要保留原本失敗的紀錄，清楚標明新要求取代咗乜，並按新要求重新驗證。批准修改規則，唔等於舊測試突然變成通過。

介面要處理「重連」，唔係淨係存檔

如果整體狀況分散喺 Roo 聊天、Pi 對話同 tmux 輸出，人就要自己拼返成個局面。單靠加幾個狀態檔，未必解決到呢個問題；真正需要的是一個可以離開再返嚟、而且睇得返全局的人機控制面。

建議統一介面至少有三個視圖：

1. **整體進度：**目前批准的目標、各個 Epic／Task 進展、邊個角色正工作、阻塞原因和最近檢查點。
2. **變更內容：**檔案樹、候選版本的差異、相關驗證結果和獨立審核意見。
3. **待決事項：**目前等緊人決定的提案，以及批准、拒絕或要求補充分析的選項。

如果人關閉 IDE，系統唔可能繼續喺已關閉的視窗顯示訊息。合理做法係先保存決定請求、暫停相關工作，等人重新連接時一眼睇到全局同待辦決定，而唔使翻查舊對話檔案。

幾個概念亦要分清楚：重新連接介面唔等於重新啟動任務；睇到待決事項唔等於恢復舊模型對話；批核亦要綁定具體提案版本和執行範圍，舊視窗的批准唔應套用到已經改過的方案。離線通知可以另行考慮，但通知唔可以取代正式紀錄，亦唔應將任意訊息當成授權。

至於 IDE，使用者仍然可以自由選擇。系統要做的是發現多人或多工具同時改檔造成的衝突，保留人的修改，並暫停受影響的工作，而唔係假設可以限制使用者開邊個編輯器。

Cline CLI／TUI 值得重新評估

Cline 官方文件列出互動式終端介面，可以用嚟討論、檢視計劃、批准操作和繼續迭代；Cline CLI 亦支援無頭自動化工作流程。107 官方亦提供 Agent Teams 和 Subagents 等多 Agent 功能，但相關功能適用於 CLI、SDK 或桌面版，唔等同 VS Code 或 JetBrains 擴充套件的能力。59

所以，「Opus 做主協調者、多個角色分工、再用終端同人互動」唔應該未試過就排除。可優先評估由 Cline CLI／TUI 承載主協調和人機互動，保留 Pi 作 Sonnet 執行端，再接入 Jev 和獨立的 Sol 審核；原有程式則保留做執行內核。

不過，方法論文件可以沿用，唔代表整套系統可以原封不動搬過去。Roo 自訂模式、工具權限、啟動回執、Pi 工作流程，以及待人決定的狀態，都要逐項對照。尤其官方文件已列明 CLI／SDK 和 IDE 擴充套件之間的多 Agent 能力差異，唔好當換個介面就自然得到同一套協調功能。59

目前未有足夠根據判斷遷移規模。與其即刻全量改寫，或者繼續一口否決 Cline，不如先做一條小型接駁測試。

TUI 好唔好用，關鍵係能否看見整條工作流

Cline 官方已有 TUI，所以要用終端操作，唔一定要靠私人分支。10 OpenCode 官方亦提供終端介面和程式化 CLI；但呢點唔能夠證明它就是用家提到的 Cline 分支。2

評估簡潔 TUI 或其他工具時，最重要係睇佢能否顯示整條工作流，而唔只係某一個 Agent 的對話；能否保存並恢復待決事項；以及 Pi 和獨立審核能否接入同一套狀態。檔案樹、差異檢視和驗證結果亦要指向同一個候選版本，否則介面再順手，都可能只係換咗一個地方睇零散資訊。

下一步應該驗收乜？

建議將以下情境作為下一階段的核心測試：關閉本地介面，讓後台繼續處理；Sol 對某個門檻提出疑問後，系統整理分析並等人決定；人重新連接時，可以喺同一處睇到整體進度和待決提案；批准指定變更後，系統再按新版本繼續執行。

呢個方向將「Opus 協調目標、Sol 獨立制衡、人工按版本作決定、介面可重連」放喺核心位置，而唔係由程式全權調度、將 IDE 當成只讀畫面，或者一次批核就放任流程一路跑。呢次整理係架構建議，並無修改檔案或啟動任務。