系列：「一人艦隊：用一群 AI CLI 打造跨平台代理 mesh」— 第 27 篇
紀錄日期：2026-09-21

工作草稿，已存網站草稿、尚未發表。本篇記錄目標重新對齊、三個 CLI 的設計分析，以及使用者確認的開發方向。沒有新增產品實作、部署或自我開發測試成果。篇次是素材順序，不代表又過了一個日曆日。

今天的一件事

前一篇在追記憶工具接通後為什麼仍然答舊值。接著，我停下來重新問：這個專案究竟要幫我完成什麼？

我把目標重新說成：

一群由我的訂閱跟我所有電子設備組成的我的 agent swarm：我越真的用它，它越懂我、越能替我做事，也越把我自己練強。

這句話直接改變了接下來的開發順序。我希望逐步開發 Spectyn，也使用 Spectyn 開發它自己；先從 CLI 做出可驗證的工作循環，再延伸到其他設備、不同任務與各平台 App。

CLI 是起點。每個 App 都能接續同一份工作，仍是已確認的產品方向。

先把付費與控制權分開

討論過程也確認了三種部署方式：免費本機、開源自架、付費雲端代管，共用同一套核心。付費可以由雲端承擔協調和執行，也能搭配自己的設備。

我特別補了一句：付費版跟免費版都要能設定。

資料存放、同步範圍、模型傳送、執行位置、資源預算及自主程度，都應由使用者設定。Agent 主動解釋與建議，使用者確認；付費不代表自動授權雲端讀取所有資料。

這些是產品方向。授權粒度、帳號恢復、雲端信任邊界與各服務的可用介面，仍要落成規格並驗證。登入帳號也不能直接等於取得全部設備權限。

請三個 CLI 分析，留下分歧

本輪透過專案的 local-ai 包裝器，分別請 Claude Code、agy 與 OpenCode 分析同一份需求摘要，分工如下。

三次呼叫皆退出碼 0，且有非空文字回覆。這只證明取得三份設計意見，不是三個產品測試通過，也不是正式的雙重審查。這次沒有核對各 CLI 實際使用的模型身分，因此不能宣稱得到三個獨立模型的驗證。

也沒有照單全收。例如 Claude 建議固定唯一決策設備，會限制從任一已授權 App 控制工作的目標；應保留多入口，再處理指令衝突。離線設備也無法保證立即收到撤銷。agy 提到溝通輪次減少，可以作為效率觀察，卻不足以證明使用者學會了什麼。

Spectyn 自己也要上場

原先討論集中在 Codex、Claude Code、agy、OpenCode 協助開發。我補上另一個必要條件：Spectyn 自己的 CLI 也要參與，而且其他 CLI 必須能檢查它的開發狀況，因為它目前相對不穩定。

因此新循環中的工作者有五個：Spectyn CLI、Codex、Claude Code、agy、OpenCode。角色依任務與已驗證能力指派，不固定某一家永遠當主管，也不要求每個任務五個全部出動。

初期可以由 Spectyn 做小範圍分析或修改，其他 CLI 核對。等它在特定能力上有足夠證據，再逐步承擔拆任務與派工。能修改一個檔案，不等於能可靠協調整個專案。

重新設計的開發循環

以下是已確認方向下的流程設計，尚未完整實作：

使用者目標與授權
  → 盤點現況
  → 小任務與事先定義的驗收條件
  → 選擇 CLI、模型與執行設備
  → 隔離開發
  → 測試
  → 非作者審查與 eval
  → 候選版本
  → 測試部署與實際使用驗證
  → 依授權升級或回復
  → 保存證據、文章素材與下一輪建議

測試檢查具體功能行為；eval 還要判斷成果是否解決原始需求、有無退步、是否值得這次資源消耗。Agent 不能修改自己的評分門檻來換取通過。

不通過可以修正，但要有限制：時間、用量、重試次數與可修改範圍。超過上限就停止並留下證據，不能無限互相退件。

Spectyn 掛掉後，工作紀錄還要能讀

共同紀錄不能只能透過 Spectyn 查詢。其他 CLI 應能直接讀取任務需求、基底版本、工作區、負責者、最近事件、修改內容、測試指令、退出碼、輸出與下一個接續步驟。

初期可採結構化檔案與追加事件紀錄；具體 schema 和多方寫入規則尚待設計。共同狀態也不表示每個 CLI 都可以任意改任務結論。每個任務仍要有清楚的有效執行權責，審查意見與工作者回報分開保存。

外部檢查預設唯讀。需要接管時，先確認原工作已停止；無法確認就隔離原工作區，避免兩邊競爭修改同一份內容。超時只是需要檢查的訊號，不是足以證明舊工作已停止的證據。

讓穩定版開發候選版

自我開發也不能直接改壞正在管理任務的那個執行版本。設計上由穩定版 A 管理工作，開發候選版 B。B 在隔離位置測試，經外部 CLI 檢查與實際使用驗證後，才依授權接替 A。

回復除了保留 A，也要考慮資料格式。若 B 已把資料遷移成 A 看不懂的格式，光保留舊 binary 不代表能回復。

這裡的自我改善先指工具、程式、提示與開發策略的有界改進，不等於底層模型權重已會自行訓練，也不保證每輪能力都上升。

第一個里程碑與三個待測情境

第一個里程碑是：Spectyn CLI 完成一個自身的小任務，其他 CLI 能獨立核對；即使中途失敗，也能根據紀錄接續。

接著才擴展多機、共同額度帳本及不同任務。跨機使用同一帳號，不會憑空增加訂閱額度；無法取得官方剩餘量時，也要把系統計量、估算與未知分開呈現。

今天真正學到的

要讓不穩定的工具參與開發，必須先讓它的工作可以被觀察、被核對、被接續。其他 CLI 提供外部檢查，Spectyn 逐步承擔實際工作，才有機會形成能累積證據的自我開發循環。

兩個系列也跟著這個循環走：開發過程保存素材，完成一個主題就收尾；文章不替未完成的功能提前報喜。

明天

先盤點 Spectyn 現有 CLI 的執行、狀態保存、取消與工作區能力，選一個範圍小且能明確驗收的自身任務。先把上述三個情境寫成可執行的驗收，再補最小實作。舊的開源與手機研究保留證據，不再自動決定這一輪主線。

本機證據索引

• 三 CLI 原始分析：../evidence/2026-09-21-deployment-panel/claude.txt、agy.txt、opencode.txt。
• 分析範圍與整合限制：同目錄 README.md。
• 五 CLI、自身參與、外部檢查與接續的要求，來自本次使用者後續確認；三 CLI 分析發生在這項補充之前，尚未對完整新循環重新審查。
• 本篇沒有新增產品測試數字，沒有部署或 commit；本文僅存網站草稿，尚未發表。