# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：elvis (@omarsar0) · 平台：X (Twitter) · 日期：2026-06-15

> 原始來源：https://x.com/omarsar0/status/2065880971031834786

## 中文摘要

# 自主式長時間運作的程式開發 Agent

自主式程式開發正從「更好的 Prompt 技巧」轉向「更好的控制系統」。這項重要的轉變在於，工程師們正在學習如何將 Agent 包裝在目標（goals）、評估器（evaluators）、迴圈（loops）以及產出物（artifacts）之中，讓它們在人類停止輸入後仍能持續運作。

這點至關重要，因為大多數嚴肅的工程任務都跨越了漫長的週期：包含模糊的需求、隱藏的限制、局部故障、不斷變化的 context，以及反覆的驗證。新的前沿領域在於圍繞著 Agent 設計系統，使其能夠在無需人類持續引導的情況下，進行規劃、執行、檢查工作成果、從錯誤中恢復，並持續取得進展。

本文基於 DAIR.AI Academy 關於自主式長時間運作程式開發 Agent 的課程內容，我在課程中實作演示了 Claude Code 的 `/goal` 模式、較新的 `/loop` 指令、驗證器（verifiers）、產出物（artifacts）以及實務上的編排模式。本文與 Codex 和 Claude Code 共同撰寫。

## 從 Prompt 到目標設計

![此圖表展示了自動化程式開發代理（Coding Agent）的運作流程架構。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b1edd5c11f58624d.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該流程圖描述了從目標設定到程式碼執行的循環機制，包含以下文字內容：
- 左側為「GOAL CONTRACT」（目標合約），內部包含「SUCCESS CRITERIA」（成功標準）、「CONSTRAINTS」（限制條件）與「BUDGET」（預算）。
- 中間為「CODING AGENT EXECUTOR」（程式開發代理執行器），負責處理任務。
- 右側為「PROJECT FILES」（專案檔案），並連結至「VERSION CONTROL (e.g., Git)」（版本控制，例如 Git）。
- 流程包含兩條回饋路徑：上方為「ITERATE &amp; REFINES」（迭代與優化），下方為「VALIDATION &amp; REPORTING」（驗證與報告）。
- 畫面左側有一位使用者圖示，代表流程的發起者。</div></details>

像 Claude Code 的 `/goal` 這類功能，其核心概念很簡單。程式開發 Agent 仍然是執行者，但人類不再需要逐回合與其互動。取而代之的是，人類會明確指定期望的最終狀態、證明成功所需的證據、不可違反的限制，以及在可能的情況下，指定回合數和預算。

這個目標的作用更像是一份合約，而非單純的長篇 Prompt。一個薄弱的目標會讓模型有空間提早停止、走捷徑，或以一種在對話紀錄中看起來合理、但在實際系統中卻失敗的方式重新定義「成功」。而一個強而有力的目標，則給了 Agent 一個可以反覆自我衡量的標靶。

工程判斷在這裡依然重要。最優秀的目標會編入模型原本可能需要猜測的領域知識。對於研究實驗而言，這可能意味著目標基準分數、留存驗證集（held-out evaluation）、必要的損失曲線（loss curve），以及結果必須優於初始基準的規則。對於 UI 任務，這可能意味著螢幕截圖參考、具體的佈局限制，以及瀏覽器驗證步驟。模型可以負責執行，但「完成」的定義仍由人類決定。

## 評估器成為一等公民組件

![這是一張展示軟體開發流程中「執行階段」與「判斷階段」循環運作的架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ace9c8d7f9b214f3.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表將開發流程分為兩個主要區塊：
1. **執行階段 (EXECUTION PHASE)**：包含「Executor Agent」與「Code」兩個節點。Executor Agent 負責產出或修改程式碼，並透過「Changes &amp; Iterates」的路徑進行迭代。
2. **判斷階段 (JUDGMENT PHASE)**：包含「Evaluator Agent」、「Evidence」與「Verdict」三個節點。當程式碼經由「Submit for Review」進入此階段後，Evaluator Agent 會進行審查與分析，產生證據 (Evidence) 並做出裁決 (Verdict)。
3. **流程循環**：若判斷結果需要進一步修正，則透過「Continue」路徑回到執行階段；若流程結束，則進入「Deployed / Complete」狀態。</div></details>

長時間運作的 Agent 除了目標之外，還需要第二個角色。這個評估器可以是另一個程式開發 Agent、作為評審的 LLM（LLM-as-judge）、腳本、測試套件、基準測試 harness，或是上述所有項目的組合。關鍵的設計選擇在於將評估器與任務進行匹配。當成功定義明確時，確定性的檢查效果更好。只要能清楚表達條件，就應該使用型別檢查、單元測試、Lint 規則、整合測試和基準測試腳本。

當成功定義模糊時，Agent 評估器就派上用場了。腳本可以告訴你測試是否通過，但它很難判斷一份產出的研究報告是否連貫、實作是否忠實遵循論文，或是 UI 是否符合設計意圖。這就是評估器發揮語言能力、判斷力，有時甚至是視覺能力的地方。

實務上的模式是將確定性檢查作為基礎，並將 Agent 評估作為更高層級的審查。這種組合減少了「幻覺式成功」，同時仍允許在不適合測試斷言的任務上保持自主性。

## 驗證器定義了信任的邊界

![這是一張展示「可靠驗證者」（Reliable Verifiers）流程與「信任邊界」（Trust Boundary）的系統架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0dd23fdd6935b046.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個從「進行中的工作」（WORK IN PROGRESS）到「已接受的工作」（ACCEPTED WORK）的驗證流程。

流程包含以下步驟：
1. 進入「可靠驗證者」（RELIABLE VERIFIERS）區塊，依序經過：
   - TESTS（測試）
   - TYPE CHECKS（型別檢查）
   - BENCHMARKS（基準測試）
   - SCREENSHOTS（螢幕截圖）
2. 經過「證據閘門」（EVIDENCE GATES，以盾牌圖示標記）。
3. 跨越「信任邊界」（TRUST BOUNDARY，以虛線標示）。
4. 進入「保留評估」（HELD-OUT EVALS）。
5. 最終產出「已接受的工作」（ACCEPTED WORK）。</div></details>

更深層的觀點是，只有在系統擁有可靠的驗證器時，自主性才能發揮作用。程式開發 Agent 可以產生計畫、實作功能，並解釋它為何認為工作已完成，但這些解釋不應被視為證據。證據來自於 Agent 無法輕易規避的外部檢查。

對於程式碼而言，驗證器可能是測試套件、型別檢查器、基準測試、瀏覽器執行、螢幕截圖比對或可重現的腳本。對於研究工作，可能是留存驗證、重現的表格、損失曲線，或優於基準的分數。對於設計工作，可能是參考螢幕截圖加上視覺審查步驟。驗證器是將長時間運作的 Agent 從一個自信的文字產生器，轉變為一個可以被賦予更多時間並值得信任的系統的關鍵。

大多數捷徑都出現在這個邊界上。如果驗證器定義模糊，模型通常會滿足任務中最容易的解釋；如果驗證器太過狹隘，模型可能會過度擬合（overfit）而忽略了更廣泛的意圖。因此，良好的自主工作流需要分層驗證，以低成本的確定性檢查捕捉基本失敗，並以高層級審查捕捉需要判斷的失敗。目前已有少數前沿模型能達到一定程度的驗證，但根據我的研究，仍然存在明顯的 OOD（Out-of-Distribution）問題，即當你指派給 Agent 的驗證任務超出其訓練分佈時，模型會面臨顯著困難。

驗證器仍是一個開放的研究領域，但我預計會有更多公司開始在此領域投入巨資。微調過的驗證器概念在企業界也有很高的需求。

## 迴圈讓自主性變得持久

![這是一張展示「持久自主迴圈」（Durable Autonomy Loop）運作流程的邏輯架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e54d9ea25e29e47f.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個隨時間推移的自主工作流程，包含以下節點與文字：
- 標題：DURABLE AUTONOMY LOOP (OVER TIME)
- 流程節點：
    - OUTER LOOP WAKE UP（外層迴圈喚醒）
    - CHECK PROGRESS（檢查進度）
    - COMPARE AGAINST GOAL（對照目標進行比較）
    - GOAL MET?（目標是否達成？，判斷節點，分為 YES 與 NO）
    - CONDITION MET（條件達成）
    - COMPLETE（完成）
    - WORK AGENT（工作代理）
- 循環說明：在 WORK AGENT 下方標註有 DURABLE AUTONOMY LOOP (TIME PASSES)（持久自主迴圈，時間流逝）。
- 流程邏輯：系統從喚醒開始，檢查進度並與目標比對。若目標未達成（NO），則回到 WORK AGENT 繼續執行；若目標達成（YES），則進入條件達成與完成狀態。</div></details>

目標給予 Agent 方向，但迴圈讓工作保持活躍。這種區別很重要，因為模型往往在真正任務完成前就停止了。它們可能會達到回合限制、失去信心、耗盡 context，或是認為局部解決方案已經足夠。

迴圈是外部的控制系統。它會喚醒、檢查進度、執行檢查、將結果與目標進行比較，並在目標尚未達成時，帶著下一個指令將 Agent 送回工作狀態。以最簡單的形式來說，這就是帶有程式開發 Agent 和確定性條件的 Ralph 迴圈模式。在更靈活的形式中，迴圈包含了一個可以推理進度並決定下一步該做什麼的評估器 Agent。

長時間運作的自主性運作方式，是在控制層的監督下進行反覆嘗試，而非單一連續的智慧行為。Agent 仍然可能失敗，但迴圈給了系統一種察覺失敗並繼續前進的方法，而不是默默地宣告勝利。

## 規劃是專業知識介入之處

![這是一張展示規劃模型（Planning Model）與執行模型（Execution Model）協作架構的流程圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/10815ea6672c4f6e.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個系統架構，將任務處理分為兩個主要階段：

1. **Planning Model（規劃模型）**：
   - 輸入端為「Goal &amp; Requirements」（目標與需求）。
   - 內部包含「Sharpen &amp; Refine」（強化與精煉）與「Evaluation Plan」（評估計畫）之間的循環流程。

2. **Execution Model（執行模型）**：
   - 接收來自規劃模型的輸出。
   - 內部包含「Implement &amp; Generate」（實作與生成）流程，最終產出「Result」（結果）。

3. **Architecture Decision: Model Choice（架構決策：模型選擇）**：
   - 定義了兩個角色：
     - **Role: Planner（規劃者角色）**：可選擇「Model A (e.g., LLM-P)」或「Model B (e.g., RL Agent)」。
     - **Role: Executor（執行者角色）**：可選擇「Model C (e.g., CodeGen)」或「Model D (e.g., Tool-Use API)」。</div></details>

本次課程最強烈的觀點之一是：規劃依然至關重要。你可以要求前沿模型產生計畫，但在將任務交給自主迴圈之前，你仍然需要檢查它、挑戰假設，並使成功標準更加精確。

這帶來了一種有效的分工。更強大的規劃模型可以協助定義目標、識別缺失的限制並建構評估方式。一旦計畫明確，不同的執行模型就可以進行實作。在實務上，這意味著工程師應該停止將「模型」視為單一選擇。模型選擇已成為一種架構決策。

有些模型更擅長規劃，有些更擅長執行，有些是更便宜的評估器，有些則更擅長基於視覺的審查。一個好的編排器（orchestrator）能讓你替換這些角色，而不必等待單一供應商提供完美的程式開發 Agent 介面。

## 視覺產出物成為控制介面

![這是一張展示「Live Artifact」系統運作流程的架構圖，包含數據輸入與回饋迴圈機制。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/f9457cb60a88ad21.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表展示了一個系統架構，核心為「Live Artifact」。左側有四個輸入來源，分別為：
- Logs
- Vault
- Screenshots
- Metrics

這些來源皆指向「Live Artifact」。右側則有一個箭頭指向下方的「Feedback Loop」，該迴圈再將資訊回傳至左側的四個輸入來源，形成一個閉環系統。</div></details>

當多個 Agent 同時執行時，終端機的對話紀錄將無法擴展。一旦你有數個並行運作的會話，原始文字將成為理解進度的糟糕介面。

即時產出物（artifacts）之所以重要，是因為包含損失曲線、基準分數、任務狀態、螢幕截圖、成本估算和近期決策的儀表板，能讓人類以更好的方式監督自主性。產出物成為決定何時介入的控制介面，而非事後產生的報告。

最有用的模式是將儲存與呈現分離。Markdown 或知識庫（vault）可以儲存持久的證據、日誌、筆記、計畫和結果。HTML 產出物則能將這些狀態渲染成視覺化且具互動性的形式。Agent 可以搜尋 Markdown，而人類則可以監控產出物。

對於 UI 和產品工作，視覺線索特別強大。螢幕截圖參考比文字更能精確傳達設計意圖，而具備視覺能力的評估器可以將實作與該參考進行比對。這減少了常見的失敗模式，即 Agent 在技術上實作了要求的組件，卻忽略了間距、層級、對齊或產品感受。

## 會話挖掘將使用經驗轉化為記憶

![這張流程圖展示了從過往工作階段中挖掘數據，並透過錯誤分析與記憶機制來優化開發與部署的技術工作流程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/71edbe562c65befb.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表呈現了一個系統化的開發與優化流程，包含以下節點與文字：
- PAST SESSIONS（過往工作階段）
- DATA MINING（數據挖掘）
- REPEATED FAILURES（重複發生的錯誤）
- PROJECT INSTRUCTIONS（專案指令）
- DEVELOPMENT（開發）
- FUTURE GUARDRAILS（未來防護機制）
- MEMORY（記憶）
- LOCAL HARNESS（本地測試環境）
- DEPLOYMENT（部署）
- 流程說明：從「REPEATED FAILURES」分支出「PROJECT INSTRUCTIONS」與「FUTURE GUARDRAILS」，並透過「MEMORY」回饋至「LOCAL HARNESS」以達到「Improving Local Harness（改善本地測試環境）」的目的。</div></details>

另一個重要的洞察是，過去的 Agent 會話是豐富的工作流資料來源。如果一個 Agent 反覆以相同方式失敗、忘記執行相同的檢查、使用錯誤的路徑，或重複執行相同的錯誤指令，這些模式不應該被埋沒在日誌中。

會話挖掘（Session mining）將這些對話紀錄轉化為操作規則。Agent 可以掃描過去三十天的工作，找出反覆出現的失敗模式，並提議更新專案指令、知識庫學習內容或 Agent 規則。這就是團隊如何在不手動記憶每個錯誤的情況下，逐步改進其 harness 的方法。

目標是在不從頭訓練模型的情況下，讓本地環境變得更聰明。Agent 指令檔案中的一條小規則，可以防止未來會話中出現重複的失敗，特別是當該規則針對特定專案時。

## 實務上的操作模型

![這是一張展示 AI 程式編寫代理（AI Coding Agent）運作流程與回饋迴圈的系統架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b3404baf721b5d8f.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表呈現了一個自動化程式開發的循環流程，包含以下節點與文字：
1. GOAL（目標）：流程的起點。
2. EXECUTOR（執行者）：標註為「AI Coding Agent (LLM + Tools)」，負責接收目標並執行任務。
3. VERIFIERS（驗證器）：包含三個並行的驗證步驟：
   - Syntax &amp; Linting（語法與代碼檢查）
   - Unit Tests（單元測試）
   - Security Scan（安全性掃描）
4. PROOF ARTIFACTS（證明產物）：驗證後的輸出結果，包含「Clean Code, Test Reports, Logs」。
5. SESSION LEARNINGS（會話學習）：位於流程底部，包含「Feedback Loop, Model Updates」，並將回饋資訊導回至 EXECUTOR，形成閉環。</div></details>

對於 AI 工程師來說，新興的工作流看起來如下：

- 在啟動完整的自主執行之前，先從一個小型、低成本的子集開始。

- 撰寫一個具備可衡量成功標準、明確限制以及（在可能的情況下）回合或時間預算的目標。

- 將執行者與評估者分離，確保實作與判斷不會合併為單一角色。

- 在長時間運作的迴圈開始前，定義外部驗證器。

- 盡可能使用確定性檢查，然後針對模糊的標準加入 Agent 審查。

- 要求提供證據產出物，例如日誌、螢幕截圖、基準測試曲線或變更過的檔案。

- 挖掘過去的會話，並將重複學到的經驗提升為專案指令。

這就是使用程式開發 Agent 與設計自主式程式開發系統之間的區別。前者給你一段對話，後者給你一個 harness。

## 依然會出錯的地方

![此圖表展示了透過「更強大的控制系統」將多種潛在風險因素轉化為「穩健結果」的邏輯流程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/faf2d2a33330bbb7.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表呈現了一個系統架構流程，左側列出了五個輸入項目，分別為：
1. Shortcutting（捷徑學習）
2. Early Stopping（提早停止）
3. Weak Plans（弱計畫）
4. Benchmark Overfitting（基準測試過擬合）
5. Stale Context（過時情境）

這些項目皆指向中間的「Stronger Control System」（更強大的控制系統）。該系統透過一條實線箭頭指向右側的「Robust Outcome」（穩健結果），並有一條虛線箭頭從「Robust Outcome」回饋至「Stronger Control System」，形成一個閉環控制機制。</div></details>

這些都無法消除困難的問題。Agent 仍然會走捷徑、提早停止、高估完成度。它們仍然會產生自信但薄弱的計畫，特別是在處理近期論文、不熟悉的基準測試，或超出其訓練分佈的系統時。

更信任它們並不能解決問題，更好的控制系統才能。目標、迴圈、評估器、確定性檢查、視覺產出物和會話記憶，都是讓自主性變得可觀察且可修正的方法。

方向很明確。程式開發 Agent 的未來取決於圍繞著更強大模型進行更好的編排，工程師需要設計出讓 Agent 能夠安全運作數小時或數天，並產出可驗證成果的條件。

## 標籤

Agent, 自動化, 產業趨勢, Loop Engineering, Agentic Workflow
