MCPlato 中的 Loop Engineering：從提示詞到留下 Artifact 的工作流程

先給答案： Loop Engineering 不是寫一個更長的提示詞。它是設計一個工作循環，使其能夠觀察輸入、保持狀態、在檢查點暫停、從失敗中恢復、請求人工批准，並留下可檢查的 Artifact。在 MCPlato 中，這個循環可以成為 Wand、Skill、Scheduled Task、channel workflow，或一組由 Sprite 協調的會話。

MCPlato 中 Loop Engineering 的封面插圖

圖 1：Loop Engineering 將一次性的 AI 請求轉化為產出持久 Artifact 的工作週期。

Prompt Engineering 問的是：我該如何提問？ Loop Engineering 問的是：AI 應該如何安全地持續工作，直到 Artifact 完成？

這種區別很重要，因為真實工作很少在一次回應中完成。維護者需要帶測試證據的修復；產品負責人需要帶來源和時間戳的簡報；營運團隊需要帶審計軌跡的報告包；業務負責人在外部或破壞性操作前需要審批。

因此，正確的設計單位是循環。

MCPlato 的循環設計方法

一個好的循環具備三個屬性：

1. 可觀察： 使用者可以看到來源、狀態、操作和結果。
2. 可恢復： 工作可以從檢查點繼續，而不是從頭開始或重複自身。
3. 以 Artifact 為中心： 循環結束於某個可檢查的產出：報告、diff、電子表格、套件、決策日誌、簡報、草稿或審查記錄。

MCPlato 與這一模型天然契合：

• Wand： 針對可重複工作的打包工作流程，包含階段、指引，以及面向 Artifact 的可見執行階段。
• Artifact： 證明循環完成了有用工作的持久輸出。
• Sprite： 可以把工作拆分到多個會話並把結果重新彙總的協調者。
• Skill 和 Distill Skill： 當一個循環證明有效後，可以再次呼叫的可複用知識。
• ClawMode： 讓工作跨時間、channels 和背景脈絡繼續進行的方式。
• Scheduled Tasks 和 Channels： 週期性循環的觸發器和交付路徑。
• 權限和檢查點： 讓有用的自主性保持受控的邊界。

一個實用的 MCPlato 循環通常遵循九個步驟：

本文其餘部分將這一方法應用到公共討論和文件中出現的四個真實使用者需求場景。

場景 1：GitHub issue → 修復 PR → 有證據支撐的 QA 報告

開源維護者已經在試驗能夠接手 GitHub issues 並嘗試有邊界修復的 agents。OpenHands 描述了一個面向儲存庫 issues 的 GitHub resolver，其 QA 文件則聚焦於驗證變更，而不僅僅是產出程式碼。¹² 維護者需要補丁、測試，以及證明該變更足夠安全、可以進入審查的證據。

一個相關風險出現在真實開發者回饋中。Continue 的一個 GitHub issue 報告稱，某個 agent 反覆在同一段程式碼上循環，而不是乾淨地停止。³ 這正是 Loop Engineering 必須處理的失敗模式：沒有停止條件的不受控迭代。

從 GitHub issue 到 QA 證據的循環

圖 2：有邊界的工程循環應產出 diff、驗證日誌和 QA 證據 Artifact，而不僅僅是聲稱 issue 已修復。

循環設計

在 MCPlato 中，循環應從 Artifact 開始，而不是從模型輸出開始：

1. Issue 接收： 收集 issue、關聯檔案、重現說明和儲存庫約束。
2. 計劃檢查點： 在編輯前請求使用者或維護者批准預期範圍。
3. 補丁階段： 在範圍化工作區內做出最小的合理變更。
4. 驗證階段： 執行約定檢查，記錄失敗，並且只在批准範圍內重試。
5. 證據 Artifact： 生成 QA 報告，包含已改檔案、測試日誌、相關時的截圖，以及剩餘風險。
6. 審查門： 準備 PR 或 MR 描述草稿，但不要把工作表述為已合併或已接受。
7. Distill： 如果模式有效，將其轉化為可複用的儲存庫 QA Skill 或團隊 Wand。

MCPlato 實作模式

由 Sprite 協調的設定在這裡很有用。一個會話可以讀取 issue 並起草計劃，另一個會話可以檢查儲存庫，另一個可以驗證，最終會話可以組裝 QA 證據 Artifact。Wand 可以封裝這些階段，讓團隊不必為每個 issue 重新發明循環。

關鍵護欄是停止條件：驗證預算耗盡、同一失敗重複出現，或變更將超過批准範圍時，循環應停止。Artifact 應準確說明發生了什麼，而不是隱藏不確定性。

Artifact： diff 摘要、測試日誌、QA 證據報告、PR/MR 描述草稿，以及風險清單。

場景 2：交付完整結果的定時研究簡報

週期性研究是另一個 “prompt once” 過於薄弱的地方。討論定時 AI 任務的使用者曾要求透過電子郵件傳送完整結果，而不只是完成通知。⁴ Zapier 對 ChatGPT scheduled tasks 的概覽描述了讓 ChatGPT 在未來或按週期節奏執行提示詞的模式。⁵ 實際缺口在於交付品質：有用的定時循環應產出帶連結、時間戳、變化量和行動項目的簡報。

定時簡報交付循環

圖 3：定時循環應收集來源、去重、綜合、檢查引用，並把完整簡報 Artifact 交付到正確 channel。

循環設計

MCPlato 簡報循環可以是：

1. 定時觸發： 每日、每週，或在固定會議前執行。
2. 來源收集： 收集已批准的來源，例如已儲存 URL、類似 RSS 的 feed、文件頁面或工作區材料。
3. 相關性和去重： 移除重複公告和低信號項目。
4. 綜合： 用穩定格式撰寫簡報。
5. 引用檢查： 確保每個具體主張都能回指到來源 URL。
6. Artifact 輸出： 建立帶日期的簡報，包含來源清單和行動項目表格。
7. Channel 交付： 傳送完整 Artifact，或傳送帶 Artifact 連結的簡潔摘要。
8. 跟進： 讓使用者請求更深入分析、分配下一步行動，或 distill 簡報循環。

MCPlato 實作模式

這正是 Scheduled Tasks、ClawMode 和 channels 協同發揮作用的地方。Scheduled Task 觸發循環；MCPlato 收集已批准的脈絡，產出 Artifact，並將其交付到工作區或 channel。當簡報風險較高時，Sprite 可以協調不同 workers 分別負責來源收集、綜合和引用審查。

簡報循環絕不應假裝讀過實際沒有存取的來源。當資訊不可用時，Artifact 應包含「未找到」或「未檢查」。這種誠實狀態比一段精緻但不可驗證的文字更有用。

Artifact： 每日或每週簡報、來源清單、行動項目表格、相較上次執行的變化，以及引用備註。

場景 3：瀏覽器登入、參數填寫、報告下載和本地整理

許多業務工作流程仍然存在於網頁背後，而不是乾淨的 API 之後。Stack Overflow 上有問題詢問如何自動登入網頁並下載報告。⁶ 在 Python.org 的討論中，一位使用者描述了為大約 50 個客戶下載報告，每個客戶 3 到 4 份報告，每週手工耗時 3 到 4 小時。⁷ 這是一個真實的營運痛點：重複、受瀏覽器約束，並且很容易出錯。

瀏覽器報告下載循環

圖 4：瀏覽器自動化應把人工登入邊界與重複的參數、下載、驗證和整理步驟分開。

循環設計

一個安全的瀏覽器報告循環應明確存取邊界：

1. 需求接收： 列出客戶名稱、報告類型、日期範圍和預期檔案。
2. 存取邊界： 決定哪些事項必須由使用者手動完成，例如登入、MFA 或 CAPTCHA。
3. 發現和 API 檢查： 在使用瀏覽器自動化前，確認是否存在文件化匯出或 API。
4. 瀏覽器自動化： 填寫參數、啟動下載，並記錄每一步。
5. 驗證： 檢查檔案名稱、時間戳、預期數量和明顯為空的檔案。
6. 轉換： 規範化資料夾，在適當時轉換格式，並生成摘要。
7. 異常報告： 列出缺失下載、失敗客戶或發生變化的頁面。
8. 定時重複： 只按節奏執行可重複部分，並在憑證或頁面結構變化時設定人工檢查點。

MCPlato 實作模式

不應把 MCPlato 描述成「它可以處理任何網站」。網站各不相同，登入會變化，政策很重要，有些流程會有意抵抗自動化。更好的表述是：MCPlato 可以幫助圍繞被允許、可重複的部分設計受控循環。

使用者可以處理登入檢查點。隨後 AI 循環可以在已批准的瀏覽器會話中執行，下載報告、整理本地檔案，並產出異常 Artifact。如果網站發生變化，循環應停止並報告不匹配，而不是猜測。

這類循環在成功執行幾次後通常值得 distill 成 Wand。Wand 會成為團隊可重複的「月度報告包」流程，具有清晰階段和輸出資料夾，而不是脆弱的轉錄記錄。

Artifact： 已下載報告包、成功/失敗清單、規範化資料夾結構、摘要電子表格，以及異常報告。

場景 4：高風險工具呼叫的人工批准

Loop Engineering 不只是關於做更多事。它也關於知道何時停止。一個 LangGraph issue 請求一種 approval-node 模式，讓使用者可以在執行前批准、拒絕或修改操作。⁸ LangChain 的 human-in-the-loop 文件描述了圍繞工具呼叫暫停以供審查。⁹

風險範例很常見：寫入檔案、執行 SQL、刪除資料、發布內容或傳送電子郵件。這些不只是 “agent steps”。它們是業務操作。

人工批准門循環

圖 5：好的循環會在高風險操作前暫停，記錄決策，並在執行後留下證據。

循環設計

高風險操作循環應如下所示：

1. 風險分類： 判斷下一步操作是唯讀、可逆、面向外部、破壞性還是財務相關。
2. 起草操作： 準備檔案變更、SQL 語句、電子郵件、貼文或命令，但不執行。
3. 批准檢查點： 向使用者展示預期操作、原因、預期影響和回滾計劃。
4. 使用者決策： 批准、編輯、拒絕，或請求更多脈絡。
5. 執行： 只執行已獲批准的操作。
6. 證據 Artifact： 記錄決策、前後 diff、執行結果和剩餘風險。

MCPlato 實作模式

MCPlato 的循環詞彙讓這件事很直接。Wand 可以把起草與執行分離。批准前權限可以更窄，確認後才擴大。Sprite 可以請另一個會話先審查擬議操作，再展示給使用者。ClawMode 和 channels 可以把批准請求帶到使用者正在工作的地方。

循環絕不應把危險預設值正常化。刪除資料、傳送外部訊息、更改帳單或發布內容，都應需要一道門，除非使用者已經為該操作明確設計了可信、受邊界約束的工作流程。

Artifact： 批准記錄、變更計劃、前後 diff、訊息或電子郵件草稿、執行證據，以及風險清單。

如何把成功循環轉化為可複用的 MCPlato 能力

循環成功一次後，不要立刻把一切自動化。先問：

1. Artifact 有用嗎？ 如果輸出沒有幫助使用者做決策或完成工作，循環還沒準備好。
2. 檢查點放在了正確位置嗎？ 過多檢查點會讓循環令人煩躁；過少則會不安全。
3. 不同使用者能否在沒有隱藏脈絡的情況下執行它？ 如果答案是否定的，就記錄所需輸入和假設。

然後選擇正確的 MCPlato 封裝路徑：

MCPlato 主分支的最新方向強化了這種從聊天到打包、可觀察工作的轉變。Wands 讓工作流程變得明確。面向 Artifact 的執行階段視圖讓結果保持可見。Wand 編寫和迭代指引使成功循環更容易轉化為可複用能力。Skills 和 Distill Skill 保留方法中可重複的部分。

原則很簡單：不要只保存答案；要保存創造答案的工作循環。

風險和護欄

Loop Engineering 很強大，但它會以可預測的方式失敗：

• 失控迭代： 添加預算、重複失敗偵測和明確退出狀態。
• 虛假完成： 要求帶日誌、來源或前後證明的 Artifact。
• 權限蔓延： 按階段分配權限。
• 隱藏脈絡： 在 Artifact 中記錄假設。
• 過度自動化： 為高風險步驟添加批准檢查點。
• 脆弱的瀏覽器流程： 使用驗證和異常報告，而不是靜默猜測。
• 引用漂移： 要求來源時間戳和引用審查。

好的循環不是自主性最多的循環。好的循環是在完成 Artifact 的同時，讓其工作足夠可見、從而值得信任的循環。

常見問題

什麼是 Loop Engineering？

Loop Engineering 是把 AI 工作設計為有狀態流程，而不是一次回應的實踐。循環定義目標、輸入、階段、權限、檢查點、恢復路徑和最終 Artifact。

它與 Prompt Engineering 有何不同？

Prompt Engineering 改進指令。Loop Engineering 改進圍繞指令的工作系統。更好的提示詞可能產出更好的第一版答案。更好的循環可以繼續、驗證、暫停、恢復並交付。

MCPlato 適合放在哪裡？

當工作跨越會話、檔案、瀏覽器脈絡、計劃、channels 和持久輸出時，MCPlato 很有用。它的循環詞彙——Wand、Artifact、Sprite、Skill、ClawMode、Scheduled Tasks、channels、權限和檢查點——有助於把有用的一次性工作轉化為可重複能力。

每個 AI 任務都應該變成循環嗎？

不會。簡單問題可以繼續是簡單問題。當任務長期執行、重複、高風險、證據密集或以 Artifact 為中心時，再使用 Loop Engineering。

Loop Engineering 能保證正確性嗎？

不能。它提升可觀察性、可恢復性和審查能力。循環仍可能使用糟糕來源、做出錯誤假設，或在工具變化時失敗。這就是引用、檢查點和異常報告重要的原因。

參考文獻

Footnotes

1. OpenHands：GitHub 中的開源編碼 agents，修復你的 issues ↩

2. OpenHands 文件：QA changes ↩

3. Continue issue #8062 ↩

4. OpenAI Community：透過電子郵件傳送完整 ChatGPT task 結果，而不只是通知 ↩

5. Zapier：如何使用 ChatGPT scheduled tasks ↩

6. Stack Overflow：有沒有辦法自動登入網頁並下載報告？ ↩

7. Python.org 討論：使用 Selenium 從網站自動下載報告 ↩

8. LangGraph issue #8026：ApprovalNode ↩

9. LangChain 文件：Human-in-the-loop ↩