AI 開發進化論：從 Prompt、Context、Harness、Loop 到 Graph

剛開始用 AI 寫程式時，我最在意的是 Prompt。我要怎麼描述功能？要不要指定技術棧？是不是多補幾個範例，模型就能一次產生比較好的答案？那時候的工作很像在尋找一句正確咒語。

後來專案變大，問題跟著變了。Prompt 寫得更完整，AI 還是會讀錯檔案、忘記既有架構、選錯工具，或在看似完成後留下一段沒有測過的程式。Prompt 依然有用，只是一句話已經裝不下整個工作環境。

五層責任會同時存在

Prompt、Context、Harness、Loop、Graph 常被排成一條技術時間線，好像新名詞出現，上一個就退場。我更習慣把它們看成由內往外增加的五層工程責任。

Graph 裡仍然需要 Prompt，每個節點也需要 Context；Loop 通常跑在 Harness 裡，一張 Graph 又可以包含很多 Loop。這裡說的「進化」，指的是管理範圍一直往外擴。AI 要穩定完成真實工作，光顧好模型的回答已經不夠。

第一層：Prompt Engineering——要怎麼問？

Prompt Engineering 處理的是指令本身。任務是什麼、有哪些限制、要用什麼格式回答、哪些例子代表好結果，都可以寫進 Prompt。對摘要、分類、改寫或一次性的程式片段來說，這一層通常已經足夠。

好的 Prompt 不一定很長。它應該把目標、必要背景、不可違反的限制與成功條件說清楚。當模型變強，反而更不需要把每個微小步驟硬寫成 if-else；過度堆疊規則可能讓指令互相衝突，也會消耗原本能用來理解任務的注意力。

Prompt Engineering 的限制是，它多半假設需要的資訊已經放在眼前。當答案依賴一個持續變動的 codebase、資料庫狀態或前幾次工具結果時，問題就從「怎麼說」變成「此刻應該讓模型看到什麼」。

第二層：Context Engineering——此刻該知道什麼？

Context 不只是使用者剛輸入的那句話。System instructions、工具說明、檔案內容、對話歷史、搜尋結果、錯誤訊息、記憶與範例，都可能進入同一個 context window。Context Engineering 的工作，是在有限注意力裡留下最有用的資訊。

「放越多越好」是這一層最常見的誤解。模型可以讀很長的內容，不代表每一段都會得到同樣的注意。Context Engineering 要管理的是訊號密度：哪些資料現在就放進去，哪些先留檔案路徑或索引，等 Agent 需要時再讀，哪些過時輸出該摘要或丟掉。

對 coding agent 來說，清楚的目錄、可搜尋的規格、版本化的決策和靠近程式碼的文件，都是 Context Engineering。它們不只方便人類接手，也讓 Agent 能在需要時自己找回資訊，而不是由人不斷複製貼上。

第三層：Harness Engineering——能在哪裡做什麼？

模型知道專案背景，不代表它已經能完成工作。它還需要一個可以觀察與行動的環境。檔案系統、terminal、瀏覽器、sandbox、權限、測試、lint、CI、logs、metrics 與部署流程，合起來就是 Harness 的一部分。

Harness 要讓正確行為容易執行，讓錯誤露出來，也把重要邊界變成能強制執行的規則。Agent 看不到錯誤 log，就無法除錯；不能啟動 App，就只能猜 UI；測試沒有明確的失敗訊息，它也不知道下一步該修哪裡。

OpenAI 在 Harness Engineering 的案例裡提到，早期進展不如預期，主因是環境缺少足夠的工具、抽象與內部結構。工程師的工作因此從直接寫每一行 code，轉向設計 Agent 看得懂、用得了，也無法輕易越界的工作場所。

第四層：Loop Engineering——失敗後怎麼繼續？

一次工具呼叫很少等於完成。Agent 真正有用的地方，是它能觀察結果，再決定下一個動作：讀取狀態、規劃、執行、驗證、修正，直到達成目標或碰到停止條件。這就是 Agent Loop。

Loop Engineering 目前不像 Prompt Engineering 一樣是完全定型的職稱或學科，我把它當成一個實用的設計視角。你要決定每輪能取得什麼觀察、錯誤如何回到 context、同一失敗最多重試幾次、什麼證據才算完成，以及什麼情況必須交回人類。

沒有停止條件的 Loop，只是昂貴的無限重試。少了驗證器，它也可能反覆產生外觀看來不同、實際上一樣錯的結果。測試、grader、review、diff、截圖與人工核准，都是決定 Loop 能不能收斂的回饋訊號。

第五層：Graph／Orchestration Engineering——多個步驟如何協作？

單一 Loop 適合處理一個可以反覆修正的目標，真實的軟體流程卻常有分支。研究和 UI 探索可以平行，資料庫 migration 必須先於後端部署，測試失敗要回到實作，資安變更則可能需要人工核准。流程走到這裡，已經不是一條直線。

Graph 把工作拆成節點與邊：每個節點讀取狀態、完成一段有限工作，再根據結果決定下一步。它可以表達 sequence、branch、parallel work、loop、handoff 和 human-in-the-loop。狀態不必全塞進同一段對話，而能由工作流程明確管理。

「Graph Engineering」還不是所有團隊都採用的固定名稱，因此更精確的說法是 Graph／Orchestration Engineering。這一層也不綁 LangGraph 或其他特定框架；它要處理的是原本藏在 Prompt 裡的流程控制，讓流程變成可以觀察、測試與恢復的軟體結構。

START
  → gather_context
  → implement
  → test
      ├─ failed → implement       # loop
      └─ passed → review
                    ├─ changes_requested → implement
                    └─ approved → human_gate → deploy

OpenAI 的 Symphony 把 issue tracker 變成 coding agents 的 control plane；LangGraph 則用共享 state、節點、分支與循環表達 Agent runtime。兩者實作不同，卻指向同一件事：當同時進行的 Agent 工作變多，瓶頸會從生成程式碼轉向工作分配、狀態追蹤與人類注意力。

用「完成登入功能」看五層差異

在 Prompt 階段，我們寫：「請使用目前的 React 與 API 架構完成 Email 登入，保留既有視覺並補測試。」重點是把意圖與成功條件說清楚。

進入 Context，Agent 會讀路由、Auth service、資料 schema、設計規範與過去的安全決策。它不需要一次吞下整個 repository，而是先從高訊號文件開始，再按需要搜尋。

Harness 讓它能建立 branch、修改檔案、啟動開發環境、操作登入畫面、讀取 console、執行測試，並阻止它直接碰 production secrets。

Loop 讓它在測試失敗後讀取錯誤、修正、重新執行，再用瀏覽器確認真實流程。Graph 則能把資料庫檢查、前端實作、後端實作與安全 review 拆開，必要時平行進行，最後在部署前等待人工核准。

不是每個任務都需要一張 Graph

如果只是把一段文字改短，一個清楚 Prompt 就夠了。需要依據專案知識時，再處理 Context；需要改動真實系統時，才值得建立 Harness；工作需要反覆驗證時加入 Loop；只有當分支、平行工作、長期狀態或人工關卡真的出現，Graph 才開始回本。

單次生成              → Prompt
需要專案知識          → Context
需要操作真實環境      → Harness
需要驗證與自我修正    → Loop
需要分支、平行或核准  → Graph

把所有工作都做成多 Agent Graph，不會自動得到更好的結果。更多節點也代表更多延遲、成本、狀態同步與失敗模式。工程上該找的是能穩定完成任務的最小結構，不必永遠往最高一層堆。

工程師的角色沒有消失，只是往外移

AI 能寫的 code 變多後，工程師的價值也往外移。定義正確問題、整理可用 context、建立可執行環境、設計回饋訊號、限制權限，以及判斷哪個結果可以進入下一步，這些能力會直接左右交付品質。

Prompt Engineering 教我們怎麼對模型說話；Graph Engineering 迫使我們回答更難的問題：當模型真的開始做事，整個系統如何知道它仍走在正確的路上？

模型能做的事越多，我們越需要把原本藏在人腦裡的規則，變成它能讀、能執行、能驗證的系統。可靠性也不再押在一次完美回答，而是分散到 Prompt、Context、Harness、Loop 與 Graph 的每一層。