提示工程 vs 迴圈工程 vs 圖工程：每一層發生了什麼變化

現在有三個術語在AI工程職位描述中爭奪同一行。提示工程（Prompt Engineering）是已經確立的。迴圈工程（Loop Engineering）在2025年底進入AI詞彙，並在2026年6月之前主導了開發者討論。圖工程（Graph Engineering）大約六週後緊隨其後。

它們被互換使用。但應該這樣嗎？

這三種不是競爭技術。它們是三個不同的控制單元，層層疊加。一個提示控制一個模型響應。一個迴圈控制一個智慧體的行為週期。一個圖控制多個智慧體的組織。每一層都保留其下的層。一旦圍繞一個提示構建了迴圈，提示並不會消失——它不再是手工輸入的東西。

本文區分了這三個層次：每一層設計什麼，已發表的宣告關於高層何時收回成本，以及懷疑在哪裡是合理的。

一個任務，三個層次

這三個術語不是競爭技術。它們是三種不同的控制單元。以下是同一工作在每一層的處理方式，逐步進行。橙色點標記需要人類參與的時刻。

任務： 修復auth模組中失敗的測試，然後開啟一個拉取請求。

• 第1層：提示工程——你控制一個模型響應。你就是迴圈。你的輪次：0，模型呼叫：0
• 第2層：迴圈工程——你控制一個智慧體的週期。迴圈負責提示。你的輪次：0，模型呼叫：0
• 第3層：圖工程——你控制如何組織多個智慧體。你的輪次：0，節點：0，並行：0

實際差異

| 方面 | 提示工程 | 迴圈工程 | 圖工程 | |------|----------|----------|--------| | 控制單元 | 一個模型響應 | 一個智慧體的行為週期 | 智慧體的組織 | | 你編寫的內容 | 指令、示例、輸出格式 | 觸發、工具、停止條件、重試預算 | 節點、邊、共享狀態、故障路由 | | 誰說“再來一次” | 人類，每輪 | 一個驗證器；迴圈自呼叫 | 預先編寫的路由規則 | | 在哪裡崩潰 | 模糊或過載的指令 | 無法區分完成與卡住 | 上下文從未跨越你忘記畫的邊 | | 何時足夠 | 一次性，人類閱讀結果 | 重複性、機器可檢查、單一領域 | 跨領域工作，帶有並行分支 |

層次順序

每一步在實踐中被命名，然後才出現在供應商文件中。

提示工程涵蓋為單個呼叫編寫和結構化指令。Anthropic的指南是將系統提示分成標記的部分——背景資訊、指令、工具指導、輸出描述——用XML標籤或Markdown標題分隔。建議提供最小必要資訊，但最小並不意味著短。

上下文工程接下來出現。Anthropic將其描述為提示工程的自然演進。問題從找到正確詞彙轉變為決定哪些令牌配置屬於視窗內。上下文是有限資源，工程問題是最佳化這些令牌的效用以符合模型約束。

工具環境工程涵蓋單個智慧體執行的環境：檔案、工具、記憶體、反饋。

迴圈工程位於工具環境工程之上。2026年6月一篇關於建築工程中智慧體AI的arXiv論文明確提出了相同的四步演進：提示、上下文、工具環境、迴圈，最後一層定義了系統如何重複觀察、行動、驗證和恢復。

圖工程是最新的標籤，也是最不穩定的。一份企業報告指出，該術語的起源尚未解決，並且與較早的知識圖譜用法衝突。底層實踐，即基於圖編排，在多智慧體系統研究中有記錄的歷史。

第1層：提示工程

決定性假設是人類每輪都存在。編寫提示，模型響應，判斷輸出，修改提示。

這個假設在以下情況下失效：高容量、多步驟任務、沒有人類可評估輸出、結果自動輸入下一步。任何一種情況，僅靠提示就不再足夠。

提示本身沒有變差。周圍條件變了。

提示工程在高層次中也不會消失。Anthropic的多智慧體研究報告指出，提示工程是修復協調失敗的主要槓桿。早期版本為簡單查詢生成了50個子智慧體，修復方法是提示而非拓撲。

第2層：迴圈工程

框架是：編碼智慧體是尋找解決方案的暴力工具。技藝是設計目標、工具和迴圈，而不僅僅是提示。

該術語在2026年6月進入主流開發者討論，此前一篇廣泛分享的文章認為工程師應該停止提示編碼智慧體，開始設計提示它們的迴圈。Anthropic的Claude Code團隊在同一周描述了這一轉變。

最詳細的公開分解識別了五個原語，外加一個將它們結合在一起的第六元素：

• 自動化：無需監督進行發現和分類的排程或事件
• 工作樹：隔離，使並行智慧體無法編輯相同檔案
• 技能：專案知識寫入SKILL.md，而不是每次會話重新解釋
• 外掛和聯結器：基於MCP的問題跟蹤器、資料庫或暫存API訪問
• 子智慧體：製造者/檢查者分離，因為編寫程式碼的模型評分過於寬鬆
• 狀態：對話外部的Markdown檔案或面板，因為模型在執行間會忘記

兩個會話內功能非常重要：/loop按節奏重新執行；/goal執行直到書面條件為真，每次輪次後由單獨的小模型檢查——因此編寫程式碼的智慧體不是評分的智慧體。Claude Code和Codex應用都提供等效功能。

迴圈不是難的部分。停止條件是。一個無法機械區分完成與卡住的迴圈不會大聲失敗——它只是繼續消耗令牌。

第3層：圖工程

2026年7月，討論從迴圈轉向圖。迴圈使智慧體行為可程式設計。圖使智慧體組織可程式設計。

最常被忽視的結構點是：生產級多智慧體系統同時執行兩個圖。

組織圖是穩定的。長期存在的智慧體擁有命名角色、負責區域並隨時間積累上下文。它在重新部署時變化。

任務圖是臨時的。任務節點僅在工作存在時存在。邊為並行路徑分裂，在收斂時合併，並在證據使分支不必要時消失。

組織圖回答“誰”。任務圖回答“現在做什麼”。

對該標籤的懷疑是合理的。具有明確定義目的的子智慧體已經形成圖，而技術先於詞彙。LangGraph在其術語存在之前很久就釋出了圖API。Anthropic 2024年12月的五個工作流模式——提示鏈、路由、並行化、編排器-工作者、評估器-最佳化器——是用散文描述的圖拓撲。新的是對這些框架始終強制做出的決策的共享名稱：節點是什麼，邊是什麼，狀態中有什麼。

具體工件值得了解。在LangGraph中，StateGraph在狀態模式上宣告。節點用add_node註冊。邊用add_edge和add_conditional_edges連線。標記START和END，然後圖編譯。節點是接收狀態並返回部分更新的普通函式。上下文不會跨節點邊界，除非邊攜帶它。最後一部分描述了整個失敗模式。

如何選擇層次

按順序回答以下問題。第一個“否”通常是答案。

1. 每份輸出在被執行前都有人類閱讀嗎？如果是，提示層足夠。迴圈購買的是無監督執行，而非自主性。
2. “完成”能否由非人類檢查？測試、模式、評分標準、第二個模型。如果不能，就沒有停止條件——只有預算。
3. 任務是否適合單個智慧體上下文和單一領域？如果是，構建迴圈。單一推理軌跡是保持假設一致的最便宜方式。
4. 是否需要同時執行獨立分支？如果是，這是圖問題：宣告節點、邊、共享狀態和故障路由。如果否，在新增智慧體之前擴充套件迴圈的工具。

2026年7月一篇關於編碼智慧體迴圈的arXiv論文正確說明了關係。迴圈是圖的一個子情況。當所有工作共享相同上下文且不需要並行時，圖退化為迴圈。當沒有迴圈且人類手動執行迭代時，迴圈退化為提示。層次是巢狀的，不是互斥的。