代理程式控制平面模式：工單、迴圈、規格與記憶檔案

簡答#

合適的控制平面應採用分層設計；但如果必須由其中一層負責自主工作，那就應該是工單。

工單構成持久的工作圖：要執行什麼、哪些工作受阻、哪些已完成，以及產出了哪些成果。迴圈是讓工作持續推進的執行原語。規格與上下文檔案是政策：規定代理程式在工作範圍內應如何行動。記憶檔案提供權限較低的召回資訊，適合記錄偏好與環境事實，但資訊損失過多且快取更新延遲，因此不適合用來管理自主性。

因此，實用的技術堆疊如下：

層級	最適合的產物	權限
工作選擇	Ticket-Driven Agent Orchestration	多任務自主運作的主要控制平面
執行	Agent Loop Pattern / 常駐工作程序	執行期機制，而非治理機制
政策	`WORKFLOW.md`、`SPEC.md`、`AGENTS.md`、`CLAUDE.md`、`SOUL.md`	版本控管的行為契約
整合邊界	Codex App Server Protocol / 常駐服務閘道	以程式控制生命週期、工具與憑證
召回	有界記憶檔案	便利性狀態，而非真實來源

為什麼工單最適合當主要控制平面#

Ticket-Driven Agent Orchestration 提供了最清楚的答案，因為它將工作單位從工作階段或PR改為交付成果。一張工單可以產生零個、一個或多個 PR，也可以產生筆記、審查資料包或後續工單。這是自主代理程式所需的正確抽象，因為自主運作需要一個持久的外部物件，能在重新啟動、執行失敗、多次嘗試與交接後繼續存在。

關鍵特性都屬於控制平面：

**佇列：**未結工單就是待辦工作清單。
**資格判定：**受阻工單必須等到相依項目進入終止狀態後，才會派送。
**範圍：**工單標題與描述定義目標。
**產物：**PR、筆記、留言、影片與後續工單都會附回工作項目。
**復原：**常駐服務重新啟動後，可透過追蹤系統與檔案系統還原哪些工作正在進行。
**人類治理：**人類整理 Todo 佇列，而不是每一輪都逐步指揮代理程式。

Symphony 是典型實作：Linear 是追蹤系統，每個符合資格的議題都會取得確定性的工作區，並由 Codex App Server 工作階段依據產生的 WORKFLOW.md 提示執行。Symphony 刻意不讓協調器自行寫入追蹤系統狀態；代理程式會用自己的工具更新 Linear。如果提示不夠完善，這種做法會有風險，但整體架構是正確的：追蹤系統是持久的協調介面，而代理程式只是附屬於工單的工作者。

決定性的關鍵在於，工單代表的是目標，而非狀態轉換。Symphony 早期僵化的狀態機設計，對能力更強的模型而言過於侷限。後來的設計讓代理程式使用工具並追求目標，同時保留工作區、並行、終止清理與重試行為等不變條件。這才是適當的分工：限制工作邊界，而不是規定每一個內部步驟。

為什麼光有迴圈還不夠#

Agent Loop Pattern 是必要條件，但並不足夠。迴圈是一種執行模式：重複提示，直到佇列清空、排程觸發，或出現哨兵值。它透過將工作切分為全新工作階段，並讓每次執行維持在較接近 Context Window Smart Zone 的範圍內，讓 AFK 工作得以實現。

但迴圈本身無法回答控制平面的問題：

哪些工作符合執行資格？
哪些工作受阻？
什麼情況才算完成？
產物會存放在哪裡？
誰來審查輸出？
執行失敗後，工作如何重新進入系統？

透過使用 markdown 議題檔案來清空待辦清單的迴圈，可以回答其中一些問題。Cron 迴圈回答得更少：它們只會喚醒並執行提示。Hermes Agent 提供了最清楚的警訊：排程提示會在沒有記憶的全新工作階段中執行，因此每則提示都必須包含所有必要上下文。這讓 Cron 非常適合定期交付成果，卻不適合作為通用工作圖。

正確的理解是：迴圈是致動器。它們負責執行工單、輪詢追蹤系統、重新執行 CI 修復，或交付排程報告。它們不應成為決定什麼最重要的最高權限資訊來源。

為什麼規格與上下文檔案是政策，而非工作圖#

Agent Context Files 目前仍是佔位頁，但預期涵蓋跨廠商的模式：將 CLAUDE.md、AGENTS.md、SOUL.md、WORKFLOW.md、SPEC.md 與 .cursorrules 作為 markdown 控制檔案。現有頁面已呈現出這種分工：

Symphony 使用 SPEC.md 定義產品層級的規格，並以 WORKFLOW.md 作為執行期工作流程契約。
Ticket-Driven Agent Orchestration 將 WORKFLOW.md 視為以提示承載的政策：說明如何處理議題、推進狀態、附上 PR，以及回報完成。
Hermes Agent 將專案上下文放在 AGENTS.md，將全域個性設定放在 SOUL.md，並只在相關時才延遲載入子目錄中的 AGENTS.md。

這些檔案之所以有力，是因為它們有版本控管、可供檢視，且人類與代理程式都能共用。它們適合用來記錄不變條件、慣例、角色界線與流程。但它們並不適合自然地表達工作目前的即時狀態。SPEC.md 可以定義 Symphony，卻無法告訴常駐服務目前哪個議題已解除阻塞。AGENTS.md 可以說明 Hermes 如何運作這個程式碼庫，卻無法決定下一個要處理哪項客戶需求。

因此，規格與上下文檔案應被視為政策平面。它們負責規範由工單／迴圈層啟動的代理程式該如何行動。

為什麼記憶檔案是最弱的控制平面#

Hermes Agent 在所涵蓋的頁面中，記錄了最完善的記憶設計；即使如此，其中的記憶仍明確設有上限，而且有延遲：

MEMORY.md 有容量上限。
USER.md 有容量上限。
填滿的記憶會經過整併，這必然會造成資訊損失。
工作階段期間的記憶編輯，不會影響目前的系統提示，必須等到下一個工作階段才會生效。
Hermes 區分記憶與技能：記憶記錄事實，技能記錄程序。

因此，記憶適合保存穩定資訊：專案位置、使用者偏好、環境細節。它不適合作為權威來源。控制平面需要即時狀態、明確的權責歸屬與可稽核性。有界記憶會刻意壓縮狀態；提示快取可能延遲資訊可見的時間；整併可能抹去細節。這些取捨有利於節省 token，卻不利於自主治理。

因此，記憶應該是建議性上下文，絕不能用來決定要執行哪些工作、允許哪些權限，或任務是否已完成。

執行期邊界同樣重要#

控制平面不只是檔案，也需要執行期整合邊界。Codex App Server Protocol 很重要，因為它讓協調器能以結構化方式控制 Codex 工作階段，而不必擷取終端機畫面：

啟動交握
thread/start
turn/start
串流式輪次事件
在同一個 thread_id 上延續輪次
逾時與停滯偵測
動態工具呼叫

其中較少受到關注的功能是動態工具呼叫：Symphony 可以公開 linear_graphql 工具，同時讓 Linear 權杖留在協調器內。這表示工單層可以維持權威地位，而不必將原始憑證交給每個子代理程式容器。

Hermes 則從使用者角度展示了相似的常駐服務架構：Gateway 工作階段以使用者為單位，授權透過允許清單或 DM 配對進行，Cron 輸出會傳回首頁頻道，而容器可以成為安全邊界。Symphony 的租用戶單位是議題；Hermes 的租用戶單位是使用者。兩者都需要常駐服務邊界，因為自主工作必須能在單一聊天輪次結束後繼續。

判斷原則#

使用最符合自主運作範圍的底層：

情況	適合的控制平面
單一互動式程式設計工作階段	上下文檔案 + 人類引導
重複執行的 AFK 實作任務	以議題檔案或追蹤系統工單驅動的待辦清空迴圈
跨 PR、CI、相依項目與重試的多代理程式軟體工作	工單 + 常駐服務 + 應用程式伺服器協定
排程執行的個人／團隊助理報告	Hermes 式 Cron + 首頁頻道
專案慣例、工作流程規則、個性設定與工具政策	規格／上下文檔案
偏好與環境事實	有界記憶

如果代理程式可以建立、延後、恢復、重試或分派更多工作，控制平面就應採用工單形式。如果代理程式只需要記住偏好，就使用記憶。如果代理程式只需要重複已知操作，就使用迴圈。如果代理程式需要知道該如何行動，就使用規格／上下文檔案。

失效模式#

工單控制平面#

主要風險是工單圖無止境地擴張。Ticket-Driven Agent Orchestration 和 Symphony 都指出這個尚待解答的問題：如果代理程式可以自由建立後續工單，要如何避免工作圖變成自我生成的忙碌工作？目前看來，答案是由人類整理 Todo 佇列並設定相依性限制。這種方式可行，但代表人類瓶頸轉移到了佇列治理。

迴圈控制平面#

迴圈會放大既有驗證機制的效果。Agent Loop Pattern 明確指出：迴圈適用於具有機械式驗證的 AFK 任務。若沒有測試、型別、檢查器或明確的終止條件，迴圈就只是無人看管的偏移。

規格／控制檔案平面#

若必須精確執行政策，以提示承載政策的做法就很脆弱。Symphony 透過在提示之外執行硬性不變條件來降低風險：驗證工作區路徑、限制並行度、清理終止狀態、重試退避，以及代理憑證。規格說明代理程式應該做什麼；協調器仍負責強制執行哪些事情絕不能違反。

記憶平面#

記憶出錯時不會明確示警：它可能已過時、遭到壓縮、不在目前提示中，或容量太小，無法保留所需的細節。對偏好而言可以接受，對工作狀態而言則很危險。

摘要#

對自主代理程式而言，工單應該是主要控制平面；迴圈應該是執行引擎；規格／上下文檔案應該是政策層；記憶檔案則應提供有界召回。

即使在 Codex 之外，清晰的架構也應採用 Symphony 式設計：持久工作圖、版本控管的工作流程政策、各工作獨立隔離的執行環境、結構化延續協定、受限憑證，以及讓系統持續運轉的迴圈／常駐服務。Hermes 則為個人／團隊助理部署展示了相同模式：常駐服務、租用戶、授權、Cron 與有界記憶。共同的教訓很簡單：自主運作需要持久的外部結構。不要把這種結構藏在聊天歷史或記憶裡。