提示工程 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論文正確説明了關係。循環是圖的一個子情況。當所有工作共享相同上下文且不需要並行時，圖退化為循環。當沒有循環且人類手動執行迭代時，循環退化為提示。層次是嵌套的，不是互斥的。