事實
術語 · LLM 工程 · AI 代理 · AI 人工智慧 · 說明這個名詞與這種做法，2024 年 1 月至 2026 年 8 月
五篇之五 · 來了兩次的那一個
同一個詞被命名了兩次，相隔兩週——贏的是那個玩笑
2026 年 7 月 4 日，Josh C. Simmons 發表一篇嚴謹、附有出處的文章，造出「graph engineering」（圖結構工程）一詞：把代理系統設計成一張明確的圖——節點、邊、每一步都存檔的狀態——而不是讓一個模型在迴圈裡打轉。十四天後，7 月 18 日 00:34（UTC），Peter Steinberger 在 X 上問：「Are we still talking loops or did we shift to graphs yet?」（我們還在談迴圈，還是已經改談圖了？），瀏覽 310 萬次。再過四個半小時，Hamel Husain 發表一篇題為〈Loop Engineering Is Dead. Enter Graph Engineering〉（迴圈工程已死，圖結構工程登場）的文章。全文只有一張寫著「Stop it.」的動圖，和一個句點。讓這個詞出名的是那個玩笑。而這種做法比兩者都早：2024 年 1 月已有論文把「flow engineering」（流程工程）與提示工程對舉，七月那篇文章引用的綜述也說，這種做法「常被稱為 flow engineering」。
這個想法有共識，亂的是名字 每一個替它下定義的出處，描述的都是同一個三段式結構。分歧在於它該叫什麼、是誰命名的，以及它到底新不新。
- 14天：從造出這個詞的嚴謹文章，到讓它傳開的那個玩笑
- 12個英文字：就是那則貼文——一個問句，什麼也沒主張
- 1張動圖加一個句點：宣告迴圈工程已死的那篇文章，全文就是這樣
- 2024年：一篇論文的標題把「flow engineering」與提示工程對舉——這是找得到的最早用例
- 0項量測：比較「圖」與「迴圈」孰優孰劣
節點
「好的節點是無聊的」
- 在 Simmons 的定義裡，節點可以是一個跑著「思考—行動—觀察」循環的模型、一個單純的確定性函式、一個檢索步驟，或是一個人。它只做一件事，可以單獨測試，也可以整個換掉而不驚動其他部分。
- LangChain 描述自家框架時也是同一套說法：節點可以是確定性的程式碼、一次模型呼叫、一次工具呼叫，或是一個自帶內部迴圈的完整代理。
邊
邊就是決策
- 一條帶著狀態、有型別的轉移。有些是確定的——「測試通過就部署」；有些交由模型判斷——「這張單子該送帳務還是檢舉部門」。用 Simmons 的話說，工作就是分清楚哪個是哪個，「並且在負擔得起的地方一律預設用確定的那種」。
- 據 Turing Post 轉述，Google 為 Agent Development Kit 2.0 提出的論點也一樣：「可預測的路由交給程式碼控制，需要詮釋或判斷的步驟才交給模型。」
狀態
一份綱要，每過一條邊就存檔
- 好用的性質都從這裡來。失敗不再是「整輪重跑」，而是「重試那個節點」；一件工作可以等三天等人簽核，而不必一直扣著一個脈絡視窗。
- 預算也放在狀態裡——token、金錢、實際時間——並在邊上強制執行。「如果你沒辦法在花費達到上限時把代理停下來，你跑的就不是自主系統，你只是在累積帳單。」台灣對這個詞的介紹，用幾乎相同的話講了同一件事。
驗證
驗證必須來自外部
- Louis-François Bouchard：「叫模型檢查自己的答案仍然有用，但那不是外部驗證。測試執行器、執行結果、一筆交易、客戶的實際結果，或是專家的人工審閱，才是從系統自身推理之外給出的證據。」
- 他把背後的警告歸功於 Carlos Perez：一張由代理檢查代理的圖，「可能產出極有條理的胡說八道」，因為同樣構造的模型讀著同一份有瑕疵的脈絡，往往彼此附和。
每一項有多確定 依確定程度排列：文件本身呈現的，其次是文件僅止於宣稱的，再來是被有日期的出處反駁的，最後是本文自己的解讀。
| 確定程度 | 內容 | 依據 |
|---|---|---|
| 已讀原文 | 這個詞，以三部分定義——無聊的節點、有型別的邊、存檔的狀態——以及「迴圈沒有死，只是被降級了」。 | Josh C. Simmons，2026 年 7 月 4 日 |
| 已讀原文 | 那十二個字與 310 萬次瀏覽；最早的回覆都是玩笑——「im tired boss」「bro stop I'm on vacation」 | Peter Steinberger 於 X，2026 年 7 月 18 日 00:34（UTC） |
| 已讀原文 | 〈Loop Engineering Is Dead. Enter Graph Engineering〉：一張封面插圖、一張寫著「Stop it.」的動圖、一個句點。此外什麼都沒有 | Hamel Husain，X 文章，2026 年 7 月 18 日 05:09（UTC） |
| 已讀原文 | 「flow engineering」出現在一篇論文的標題裡，與提示工程對舉 | Ridnik、Kredo 與 Friedman，arXiv，2024 年 1 月 16 日 |
| 已讀原文 | 一份綜述裡談圖式編排的章節，說這種做法「常被稱為 flow engineering」——而造詞的那篇文章，正是為了這一點把這份綜述列在自己的出處裡 | Arunkumar V、Gangadharan 與 Buyya，arXiv，2026 年 1 月 18 日；Simmons 的出處清單 |
| 已讀原文 | 「迴圈本來就是一張圖，只不過是一張路徑會回到先前節點的圖。」 | Ksenia Se，Turing Post，2026 年 7 月 20 日 |
| 已讀原文 | 「兩則推文都是玩笑」——以及「這個玩笑之所以奏效，是因為它指向了真實的東西」 | Louis-François Bouchard，2026 年 7 月 22 日 |
| 已讀原文 | 把迴圈看成「就緒集合只有一個」的排程器——以及論文自己的聲明：「並非生產實作，也沒有實證結果」 | Hu Wei，arXiv，2026 年 4 月 13 日 |
| 文件自己的宣稱 | 圖結構工程是「一種新穎的工程範式」 | 一份 35 位作者的綜述，arXiv，2026 年 8 月 21 日 |
| 被有日期的出處反駁 | 在七月那篇文章「追溯命名」之前，沒有人替迴圈工程取過名字 | Simmons，2026 年 7 月 4 日；對照 2026 年 4 月至 6 月的貼文與文章 |
| 本文的解讀 | 這個詞有兩個起點，而傳開的是那個玩笑 | 標明為解讀，並非有出處的事實 |
時序
先有做法和名字，再來新名字，然後是一個玩笑 爆紅的過程只有十六個小時，位在一條始於 2023 年的鏈條末段。7 月 18 日的時間均為 UTC。
- 2023 年 8 月一個給代理用的圖框架起步。LangChain 的 LangGraph 程式庫建立。第一個版本在 2024 年 1 月 8 日發布——所以 LangChain 在 2026 年 7 月說它有三年歷史，別人卻把它的推出定在 2024 年 1 月，兩者並不矛盾。
- 2024 年 1 月 16 日「flow engineering」，出現在標題裡。CodiumAI 的一篇論文題為〈From Prompt Engineering to Flow Engineering〉（從提示工程到流程工程）：不靠一段精心寫好的提示，而是一條分階段、以測試驅動的流程，產生、執行、修正程式碼。在它自己的基準上，GPT-4 每題五次嘗試可解出 44% 的驗證題，單一提示只有 19%。
- 2025 年 10 月LangGraph 1.0。這些出處最常提到的圖框架，推出第一個主要版本。
- 2026 年 1 月 18 日這種做法，在一份綜述裡有了名字。一份代理式 AI 綜述有一節題為「Graph based orchestration and flow engineering」（圖式編排與流程工程）：生產系統把工作流程建模「成狀態機，節點代表工具呼叫或 LLM 調用，邊代表允許的轉移。這種做法常被稱為 flow engineering。」
- 2026 年 4 月 13 日反對迴圈的正式論證。一篇單一作者的立場論文把代理迴圈描述為「單一就緒單元排程器」，下一步「出自不透明的 LLM 推論，而非可檢視的策略」，並提出「Structured Graph Harness」（結構化圖駕馭框架）。摘要最後一句是：並非生產實作，也沒有實證結果。
- 2026 年 4 月 15 日先有迴圈，後有這個詞。在舊金山的 Acquired Unplugged 台上，主導 Claude Code 的 Boris Cherny 說他的工作就是寫迴圈——Addy Osmani 後來引述他的話：「我的工作就是寫迴圈。」當晚他在 X 上向主持人道謝。
- 2026 年 6 月 7 日迴圈工程有了名字。Peter Steinberger 發文說，你應該「設計去對代理下提示的迴圈」；同一天 Addy Osmani 發表題為〈Loop Engineering〉的文章。
- 2026 年 6 月 30 日一個流行詞。吳恩達（Andrew Ng）稱迴圈工程是「當紅的流行詞」；Anthropic 的 Claude Code 團隊發表迴圈入門指南。
- 2026 年 7 月 4 日認真的造詞。Josh C. Simmons 發表〈We Are Entering the Graph Engineering Phase〉（我們正進入圖結構工程階段）：三部分的定義、七條實踐，和六項出處——其中一項正是那份一月綜述，引用理由是「圖式編排與 flow engineering」。同一篇文章寫道：「所以做法已經收斂，詞彙卻沒有。好吧，詞彙在這裡：graph engineering。」
- 7 月 18 日 · 00:34十二個字。Peter Steinberger 在 X 上寫道：「Are we still talking loops or did we shift to graphs yet?」它什麼也沒提出，卻達到 310 萬次瀏覽。最早的幾則回覆：「im tired boss」（老闆我累了）、「bro stop I'm on vacation」（兄弟別鬧，我在度假）、「接下來三週的 YouTube：『為什麼你該跑圖而不是跑迴圈』」。
- 7 月 18 日 · 02:10第一次試著賦予意義。Shubham Saboo：「圖到底是什麼鬼。迴圈讓代理的行為可以程式化，圖讓代理組織可以程式化。」
- 7 月 18 日 · 05:09訃聞。Hamel Husain 發表一篇 X 文章：〈Loop Engineering Is Dead. Enter Graph Engineering〉。封面是一個迴圈展開成網絡的插圖，底下內文是一張寫著「Stop it.」的反應動圖，和一個句點。
- 7 月 18 日 · 05:16眨眼暗示。Husain 引用自己的文章：「如果我在動態上看到這個，我自己都會怕得不敢點。但我保證，它不是你想的那樣。」
- 7 月 18 日 · 16:26口號。Santiago：「迴圈工程已死，圖結構工程萬歲！」九分鐘後，Husain 再次引用自己的文章：「被加入書籤 100 次 🤣🤣」。
- 2026 年 7 月 20 日它是真的嗎？Turing Post 把那則起頭的貼文讀成玩笑——「Peter 在玩」——報導到了週日已經冒出「課程、路線圖、工具組合」，數出人們口中的「圖」有四種不同意思，並落下整個論證的關鍵一句：迴圈本來就是一張圖。
- 2026 年 7 月 22 日有人說破了，而且說了兩次。Louis-François Bouchard：「這大多只是圍繞造新詞的一場大型迷因」——以及「這個玩笑之所以奏效，是因為它指向了真實的東西」；同一天較長的版本裡則說「兩則推文都是玩笑」。同樣在這一天，LangChain 的創辦人寫道，圖結構工程「不是新點子，只是一種早已成熟做法的最新名字」。
- 2026 年 7 月 28 日它以詞彙之姿抵達台灣。《數位時代》把它當成五種 AI 工程術語之一刊出，出處註明 X 與 Josh C. Simmons，揭露初稿由 AI 撰寫，並直說這五層怎麼排「目前還沒有定論」。
- 2026 年 8 月 21 日又被「提出」了一次，而且說是新的。一份 35 位作者的綜述：「我們提出 Graph Engineering，一種新穎的工程範式」。它完全沒提七月的那些貼文，也沒提「flow engineering」這個說法，而且已經點名下一層：本體工程（ontology engineering）。修訂版在 8 月 26 日發布。
論點
他手上有舊名字，卻選了新名字 造詞的那篇文章對論文很謹慎，對前一個詞卻說錯了，而且它知道這種做法早就有名字。
Josh C. Simmons 的文章是嚴謹的那一篇。兩個 arXiv 引用，都是真的；一個 60% 的綜述數字，引得準確；對某篇論文某一節的概括，和那一節自己的標題幾乎一字不差。
有意思的正是那個概括。他在出處清單裡列了那份一月綜述，理由是「graph orchestration and flow engineering as an identified industry shift」（圖式編排與流程工程，一個已被辨識出的產業轉向）——而那份綜述談這件事的章節說，這種做法「常被稱為 flow engineering」。在文章正文裡，他寫道：「所以做法已經收斂，詞彙卻沒有。好吧，詞彙在這裡：graph engineering。」這種做法有名字，他讀過，然後提出了另一個。
同一篇文章對前一個詞卻說錯了。「沒有人替這門功夫取名……那就讓我追溯地替它命名：loop engineering。」它四週前就有名字了。Boris Cherny 4 月 15 日在舊金山的台上說他的工作就是寫迴圈；Peter Steinberger 與 Addy Osmani 在 6 月 7 日把「設計迴圈」和「loop engineering」這個說法公開提出；6 月 30 日，吳恩達稱之為「當紅的流行詞」，Anthropic 的 Claude Code 團隊也發表了入門指南。Turing Post 在這篇文章兩週後，把這個詞的年紀定為「大約六週」。
沒有任何跡象顯示惡意，本文也不作此指控。本文提出的解讀，並標明為解讀：一位仔細讀論文、卻錯過了一個月 X 的作者，正好說明了這套詞彙活在哪裡。它活在動態時間軸上，以天為單位移動；一個新名字，可以在善意之下，被提給一個早就有名字的東西。
那篇訃聞裡什麼都沒有 宣告迴圈工程已死的那篇文章，是一個標題、一張插圖，和一張寫著「Stop it.」的動圖。
那篇文章發表十四天後，7 月 18 日 00:34（UTC），Peter Steinberger 在 X 上問了十二個字：「Are we still talking loops or did we shift to graphs yet?」它得到 310 萬次瀏覽，回覆也都是同一種語氣。
四個半小時後，Hamel Husain 發表一篇 X 文章，題為〈Loop Engineering Is Dead. Enter Graph Engineering〉。標題下方是一張插圖：一個環狀箭頭展開成節點網絡。插圖下方是一張寫著「Stop it.」的反應動圖，和一個句點。整篇文章就是這樣。幾分鐘後他寫道：「如果我在動態上看到這個，我自己都會怕得不敢點。但我保證，它不是你想的那樣。」十一個小時後，他再次引用它：「被加入書籤 100 次 🤣🤣」。
回覆說明了它是怎麼傳開的。「這是 AI 版的『被 Rick Roll 了』。」還有：「這招完全對我有效。我看到它，連點都沒點，就開始跟身邊的人嘲諷它，哈。」標題自己在流傳。到了傍晚，Santiago 貼出「迴圈工程已死，圖結構工程萬歲！」；據 Turing Post 報導，到了週日已經冒出「課程、路線圖、工具組合」，以及聲稱 Microsoft、Stanford、Anthropic 同時發現了圖結構工程的長串討論——還附帶一個「準確率高 18%、成本低 85%」的說法，Turing Post 追查出它來自一項針對工業工程圖的狹窄研究。
本文的解讀，並標明為解讀：讓這個詞出名的兩則貼文，都沒有定義——一則是問句，另一則是叫你住手的動圖。定義來自別處，主要是那篇兩週前的文章，台灣的介紹也註明了它；而 Turing Post 在幾天之內就數出人們口中的「圖」有四種不同意思。這個玩笑講的是這個領域改名改得有多快，結果卻被當成了又一次改名。
補充
實際上要做的是什麼 Josh C. Simmons 的七條實踐，台灣的介紹把它濃縮成三條。把那兩週拿掉，底下的建議很具體，而且比這個名字還老。
- 1寫提示之前，先畫出狀態狀態綱要就是架構。「如果你寫不出系統在一次執行的每個時間點知道些什麼，你手上的只是展示品。」
- 2讓節點保持無聊每個只做一件事，才能測試、快取、重試、替換。「一個做五件事的節點，就是多了幾個步驟的迴圈。」
- 3把判斷放在邊上，並且好好觀測圖系統的聰明之處在於路由，所以交給模型判斷的邊，恰恰就是它會出錯的地方。
- 4每過一條邊就存檔失敗變成「重試那個節點」，而不是「整輪重跑」；一張圖也可以等三天等人簽核。
- 5把人當成節點一條邊進、一條邊出，中間是一個人。把核准硬接成例外處理，「就是你得到『名義上有監督、實際上沒有』的系統的方式。」
- 6把預算放進狀態token、金錢與實際時間都放在狀態物件裡，並在邊上強制執行。
- 7評估軌跡，不只評估輸出「輸出評估告訴你這次執行結局不錯；軌跡評估告訴你它有沒有以合理的成本走上合理的路，而你下一個失敗就藏在路上。」
誰的階梯，有幾階 每一把階梯最底下都是提示，靠近頂端都是圖。分歧在於「駕馭」（harness）——而最新的那一把，已經在圖之上又加了一階。
| 誰的 | 階梯 | 有沒有駕馭？ |
|---|---|---|
| Josh C. Simmons · 7 月 4 日 | 提示 → 情境 → 迴圈 → 圖 | 沒有。「每一階都是抽象層次的一次提升」 |
| Louis-François Bouchard · 7 月 22 日 | 提示、情境、駕馭、迴圈、圖 | 有。它們「大幅重疊，即使並不完全相同」 |
| LangChain · 7 月 22 日 | 提示、情境、駕馭、迴圈、圖 | 有，稱之為「X 那座 AI 內容工廠最新產出的詞」 |
| 《數位時代》 · 7 月 28 日 | 提示、情境、駕馭、迴圈、圖 | 有——而且哪一層包住哪一層，「目前還沒有定論」 |
| 35 位作者的綜述 · 8 月 21 日 | 提示、情境 → 駕馭、迴圈 → 圖 → 本體 | 有：「Agent = Loop(LLM + Harness)」 |
| Hu Wei · 4 月 13 日 | 沒有階梯——這是一份設計提案 | 它把自己的設計命名為「Structured Graph Harness」——四階階梯上漏掉的那個字，正出現在那把階梯所引用之設計的名稱裡 |
反駁之間的共識，比宣告之間的還多。
Turing Post：「迴圈本來就是一張圖，只不過是一張路徑會回到先前節點的圖。」這些出處最常提到的框架 LangGraph 出自 LangChain，他們從另一頭說了同樣的話——「迴圈是簡單的圖」，以及「代理的圖通常不是 DAG（有向無環圖）」，因為生產環境中的代理會重試、會發問、會修改、會暫停。Bouchard：「圖裡面包含迴圈。」Simmons 最早提出這一點：迴圈沒有死，只是被降級了，它仍在每一個節點裡運轉。
這些都不新，出處自己也這麼說。狀態機、DAG 與工作流程引擎「已經以各種形式做這件事幾十年了」（Turing Post）；Anthropic 2024 年那份打造代理的指南，早已畫出串接、路由、平行工作者與評估迴圈（Bouchard）；LangGraph 的程式庫始於 2023 年 8 月。LangChain 自己的結論——「這只是一種早已成熟做法的最新名字」——出自一家在文末推薦自家產品的公司。
有兩個警告值得記住。「圖」至少有四種意思：決定下一步跑什麼的控制圖、由實體與關係構成的知識圖（GraphRAG）、一次執行的軌跡，以及一張由互相檢查的迴圈組成的圖——而圖結構工程講的只有第一種。還有，大多數代理根本不需要圖：「如果工作流程是線性的，就讓它保持線性。」
而且至今沒有任何量測 那篇正式論文聲明自己沒有實證結果；提出這個範式的綜述也說，所需的量測還不存在。
這個想法最嚴謹的表述，是 Hu Wei 四月那篇立場論文，它這樣形容自己：「這是一篇立場論文與設計提案……並非生產實作，也沒有實證結果。」它的比較表把自己的設計評為「只有設計，未經實證驗證」，旁邊的 LangGraph 則是「廣泛部署，經社群驗證」，表頭寫著「公平性聲明」。
從它流傳出去的唯一數字——70 個開源代理專案中有 60% 是單純的迴圈——確實是論文自己的數字，而論文稱這份調查「未經同儕審查」，是「質性證據，而非量化證明」。它的數字彼此對不上。正文說 70 個中有 42 個；附錄標題說 41 個；附錄在那個標題下列了 50 個專案，其中 8 個同時列在另一個類別——而 50 減 8 正好是正文的 42。五個類別合計，清單列出 69 個不重複的專案，各標題數字加總為 68，另一張表則給狀態機 10%，附錄給的是 6%。
八月那份 35 位作者、把圖結構工程作為範式提出的綜述，對這個缺口說得很直白：效能提升「可能來自更強的基礎模型、更長的脈絡、更多的推理樣本或更多運算成本，而非更有效的任務組織」，未來的基準應提供「對等的執行預算」。這整條脈絡裡唯一有量測的結果，是 AlphaCodium 2024 年 1 月的數字：GPT-4 用分階段流程解出 44% 的驗證題，單一提示只有 19%。那是流程對上提示，題目是程式競賽，量測者是打造該流程的公司——不是圖對上迴圈。
結論
該帶走什麼 想法站得住腳。推出的方式是個玩笑，而那個玩笑講的正是命名。把兩者分開。
評判想法，不是評判推出方式
兩則起頭的貼文都是玩笑，於是很容易就下結論說這個詞毫無價值。Bouchard 拒絕走這一步，本文也是。造詞的文章、LangChain 的創辦人、Turing Post 和台灣媒體，描述的是同樣的節點、同樣承載決策的邊、同樣會存檔的狀態，也都同意什麼時候不該用它。這是對想法的收斂。分歧只在它該叫什麼。
打開那份起頭的文件
宣告迴圈工程已死的那篇文章，內容是一張寫著「Stop it.」的動圖，作者也保證它不是看起來那樣。只靠標題被轉傳，它就成了又一次改名。本文的解讀，並標明為解讀：當一個詞以這種方式到來，先打開那份起頭的文件，再決定要不要轉述——這次只需要點一下，而點下去就真相大白。
這種做法早有名字，造詞者還引用了它
「flow engineering」出現在 2024 年 1 月的一篇論文標題裡，也出現在 2026 年 1 月一份綜述的章節標題裡，而七月那篇文章在提出新名字之前，已把那份綜述列進出處。八月，一份 35 位作者的綜述把圖結構工程當成「一種新穎的工程範式」提出，既沒提七月的貼文，也沒提那個較舊的說法，還點名了下一階：本體工程。名字以週為單位在變，做法本身幾乎沒動。
仍然沒有量測
圖結構工程沒有屬於自己的量測。它最嚴謹的論文聲明沒有實證結果，它最常被引用的數字來自一份作者自稱屬質性的調查，而提出這個範式的綜述也說，結構帶來的好處還沒和更多運算帶來的好處分開來。本系列寫到第五個詞，詞彙依然跑得比證據快。
無法查證的部分
「傳言」——「flow engineering」曾是圖結構代理工作流程的通用名稱。一份 2026 年 1 月的綜述說這種做法「常被稱為」如此，但為此引用的只有兩個框架的程式庫，而它們都沒有用這個說法；一篇 2024 年的論文曾把它放進標題。找不到更廣泛使用的證據。
核心要點與來源
- Tal Ridnik、Dedy Kredo 與 Itamar Friedman，〈AlphaCodium〉，arXiv（2024 年 1 月 16 日）
- LangGraph 程式庫，GitHub（2023 年 8 月 9 日建立）
- LangGraph 版本紀錄，PyPI（2024 年 1 月 8 日至 2025 年 10 月）
- Arunkumar V、Gangadharan G.R. 與 Rajkumar Buyya，arXiv（2026 年 1 月 18 日）
- Hu Wei，arXiv（2026 年 4 月 13 日）
- WorkOS，Acquired Unplugged 活動頁（2026 年 4 月 15 日）
- Boris Cherny 於 X（2026 年 4 月 16 日，UTC）
- Peter Steinberger 於 X（2026 年 6 月 7 日）
- Addy Osmani（2026 年 6 月 7 日）
- Andrew Ng 於 X（2026 年 6 月 30 日）
- Delba de Oliveira 與 Michael Segner，Claude 部落格（2026 年 6 月 30 日）
- Josh C. Simmons（2026 年 7 月 4 日）
- Peter Steinberger 於 X（2026 年 7 月 18 日 00:34，UTC）
- Shubham Saboo 於 X（7 月 18 日 02:10，UTC）
- Hamel Husain，X 文章（7 月 18 日 05:09，UTC）與貼文（05:16 與 16:35，UTC）
- Santiago 於 X（7 月 18 日 16:26，UTC）
- Ksenia Se，Turing Post（2026 年 7 月 20 日）
- Louis-François Bouchard，Substack 與 louisbouchard.ai（2026 年 7 月 22 日）
- Sydney Runkle 與 Harrison Chase，LangChain（2026 年 7 月 22 日）
- 陳建鈞，《數位時代》（2026 年 7 月 28 日；依其文末說明，初稿由 AI 撰寫）
- Yuyuan Feng 等 35 位作者，arXiv（2026 年 8 月 21 日，8 月 26 日修訂）。皆於 2026 年 9 月 28 日讀取。本詞是常設主題〈LLM 工程〉涵蓋的五個名詞之一，該頁把它與另外四個並排。