# 工程先行時代的分類滯後 ## AI 架構快速演化下的理論命名問題 **作者：Neo.K (許筌崴)** **機構：EveMissLab (一言諾科技有限公司)** **版本**：Internal Draft v0.1 **形式**：Markdown 內部論文草稿 **日期**：2026-07-02 **定位**：AI 架構觀察、技術哲學、工程分類學、Agent 系統、全棧對齊 AI、學術命名滯後、AI 泡沫與真實進展並存分析 **狀態聲明**：本文為內部理論草稿，不主張精確預測 AI 未來發展路線，而是提出一個觀察命題：在 2026 年的 AI 發展中，工程實作、學術分類、資本敘事、企業部署與社會理解正在以不同速度演化，導致新 AI 架構可能先在工程中出現，之後才被學術命名與理論分類。 --- ## 摘要 本文提出「工程先行時代的分類滯後」命題。2026 年的 AI 發展呈現一種特殊狀態：一方面，Agent、multi-agent orchestration、sandbox execution、long-running agents、verification gates、policy-compliant orchestration、Meta-Agent、adaptive orchestration 等工程路線快速發展；另一方面，學術與社會對這些系統的分類語言仍在形成。許多工程系統已經開始接近「模組約束式近全棧 AI」或「統籌式全棧協作 AI」的形態，但產業仍常以 agent framework、orchestrator、multi-agent system、autonomous workflow、AI-native platform 等較粗略名稱稱呼它們。 本文主張，當工程速度快於分類速度時，真正稀缺的不只是模型能力，而是能即時辨識新架構的分類語言。若缺少分類語言，工程現象會被粗糙命名；粗糙命名會導致誤解、過度宣稱、泡沫敘事、錯誤投資、錯誤治理與錯誤學術對齊。相反地，若能建立更細緻的架構分類，例如「模組約束式近全棧 AI」「統籌式全棧協作 AI」「原生全棧式 AI」「主體性原生全棧 AI」，就能更精確地判斷某個系統到底是工程拼裝、中央統籌、原生並行對齊，還是具備自身 L0–L11 生成鏈的主體性前置。 本文進一步指出，AI 發展之所以難以預測，不是因為完全無跡可循，而是因為多個層級正在異步變化：工程快速迭代，學術命名延遲，企業部署受 ROI 與成本制約，資本市場同時存在泡沫與真實生產力預期，模型能力以月甚至週為尺度跳躍，Agent 架構則逐漸從單體工具轉向多智能體統籌。這種狀態使傳統「先有學術理論，再有工程實作」的路徑不再穩定。 本文最後提出：在 AI 高速發展時代，理論的功能不只是提出遙遠預測，而是建立「即時分類語言」。這種語言能幫助人類、AI、工程師、學者與政策制定者辨識新系統所處位置，避免將近全棧誤認為原生全棧，將統籌式 AI 誤認為主體性 AI，或將工程拼接誤認為智能本體突破。 **關鍵詞**：工程先行、分類滯後、AI 架構、Agent、multi-agent orchestration、全棧對齊 AI、L0–L11、主體性 AI、AI 泡沫、技術命名、工程哲學、理論分類學 --- # 1. 問題起源：為什麼需要新的分類語言？ 2026 年的 AI 發展有一個明顯現象： > 工程正在快速產生新的 AI 系統形態，但我們對它們的分類語言仍然不穩定。 產業可能稱它們為： ```text agent agentic AI multi-agent system workflow automation AI orchestrator AI-native platform autonomous agent AI coworker AI operating layer ``` 這些詞都有用，但也都偏粗。 因為它們無法準確回答： ```text 這個系統只是工具型 Agent？ 還是模組約束式近全棧 AI？ 它是否具備統籌 L0–L11 的能力？ 它是否只是分派子任務？ 它是否有自身 L0？ 它是否能生成自身被指？ 它是否只是 workflow pipeline？ 它是否真的能做共同底空間校正？ 它是否只是包裝成主體的產品介面？ ``` 因此，本文提出： > 在 AI 架構快速演化時代，分類語言本身是一種基礎設施。 沒有分類語言，就無法判斷新系統到底是什麼。 --- # 2. 當前技術背景：Agent 與 orchestration 的快速工程化 截至 2026 年 7 月，Agent 與 multi-agent orchestration 已經不是純概念。 OpenAI 在 2026 年 4 月更新 Agents SDK，加入 model-native harness、native sandbox execution、可控工作區、檔案與工具操作等能力，目標是幫助開發者建立更安全、可長時間運作的 agent 系統。這顯示 Agent 正在從聊天式應用轉向具備工作區、工具、檔案與執行環境的工程系統。 同時，multi-agent orchestration 也已成為研究與工程熱點。2026 年 1 月的《The Orchestration of Multi-Agent Systems》將 orchestrated multi-agent systems 描述為 AI 演化的下一階段，強調 planning、policy enforcement、state management、quality operations、MCP、Agent2Agent protocol、governance 與 observability 等組件。 另外，Meta-Agent 類研究已經開始從自然語言任務描述自動建構專門 multi-agent systems，並加入 construction-time verification、execution-time verification gates 與 error attribution，以提高工作流穩定性。 Adaptive Orchestration 研究則提出 Self-Evolving Concierge System，使用 Dynamic Mixture of Experts、runtime hiring sub-agents、Meta-Cognition Engine、LRU eviction 與歷史修剪機制，以在 monolithic agents 與 static agent swarms 之間取得可擴展性。 企業情境中，也已出現 constraint-aware multi-agent orchestration 的研究，將多智能體協調視為 constrained optimization，並強調 policy-feasible actions、risk-weighted utility、auditability 與部署期 middleware。 這些發展說明一件事： > 工程正在快速靠近「統籌式 AI」與「模組近全棧 AI」，但未必使用這些名稱。 --- # 3. 工程先行：系統先出現，名字後出現 在傳統理想路徑中，理論似乎應該先提出分類，工程再按照分類實作。 但 AI 時代常常反過來： ```text 工程先拼出可用系統 ↓ 產品先進入市場 ↓ 使用者先形成需求 ↓ 企業先部署 ↓ 風險先出現 ↓ 學術才開始命名 ↓ 政策才開始分類 ``` 這就是本文所謂的「工程先行」。 工程先行不是壞事。 它代表技術快速成熟、工具鏈快速演化、產品壓力推動實作。 但工程先行會帶來分類問題。 當一個系統能： ```text 拆解任務 分派子 Agent 使用工具 存取檔案 執行程式 驗證中間結果 重新規劃 輸出文件 保留記憶 評估錯誤 ``` 它到底是什麼？ 普通 Agent？ Multi-agent system？ Workflow automation？ AI OS？ 全棧對齊 AI？ 統籌式智能體？ 若沒有更細分類，所有東西都會被叫做「Agent」。 這會讓「Agent」一詞變成新的黑箱。 --- # 4. 分類滯後：不是沒有人懂，而是語言還沒追上 分類滯後不是單純智力問題。 不是因為工程師不懂。 不是因為學者不懂。 也不是因為使用者不懂。 而是因為新系統往往先以混合形態出現。 例如，一個現代 AI 系統可能同時具備： ```text LLM 對話能力 RAG 檢索能力 工具調用能力 長程任務能力 sandbox execution 多 Agent 分派 verifier critic memory manager workflow state human-in-the-loop policy guardrail ``` 這種系統很難用舊分類命名。 若用「LLM」稱呼它，太窄。 若用「Agent」稱呼它，太粗。 若用「AGI」稱呼它，過度。 若用「workflow automation」稱呼它，又忽略其推理與語言能力。 所以需要中間分類。 本文前序提出的分類正是為了解決這個問題： ```text 模組約束式近全棧 AI 統籌式全棧協作 AI 原生全棧式 AI 主體性原生全棧 AI ``` 這些名稱不是為了增加術語，而是為了避免錯誤混淆。 --- # 5. AI 泡沫與真實發展並存 2026 年的 AI 判斷之所以困難，還因為泡沫與真實進展同時存在。 一方面，企業開始更重視成本、ROI 與部署效率。UBS 近期報告指出，部分企業正在限制 AI spending，原因包含 token 成本、工具數量、年度預算與 ROI 壓力；但該報告也將此解讀為從實驗轉向效率化使用，而非全面撤退。 另一方面，宏觀金融與政策討論也高度關注 AI 的雙面性。Reuters 報導指出，AI 在全球央行會議上同時被視為生產力希望與金融穩定風險，包含市場泡沫、能源需求、金融監管、演算法不透明與不平等風險。 因此，AI 不是簡單的： ```text 全是泡沫 ``` 也不是簡單的： ```text 全是真實革命 ``` 而是： ```text 泡沫敘事 + 真實工程進展 + 成本壓力 + 部署瓶頸 + 模型能力提升 + 資本市場期待 + 企業 ROI 校正 ``` 同時存在。 這使得預測變得困難。 --- # 6. 為什麼未來很難預判？ AI 未來難以預判，不是因為毫無方向，而是因為不同層級的變化速度不同。 至少有七個速度： ```text 1. 模型能力提升速度 2. Agent 工程化速度 3. 企業部署速度 4. 學術分類速度 5. 資本敘事速度 6. 法規治理速度 7. 社會理解速度 ``` 這七個速度不同步。 模型可能每幾週出現新能力。 工程框架可能每幾個月換一代。 企業部署可能需要一年以上驗證 ROI。 學術分類可能要更久。 政策治理通常更慢。 社會理解則常常被媒體敘事與產品包裝牽引。 因此，某個技術現象可能已經在工程上出現，但社會還以舊詞理解它。 這就是分類滯後。 --- # 7. 知識詛咒還是底空間落差？ 當一個理論提出者覺得自己的論文很簡單，讀者卻覺得複雜，常被稱為「知識的詛咒」。 但在本文語境中，更精確的說法可能是： > 這不是單純知識詛咒，而是底空間落差。 理論提出者看到的是： ```text L0 前意圖壓力 L1 被指生成 L2 意圖定位 L3 底空間尋址 L4 對象切分 L5 命名壓縮 L6 文字輸出 ``` 讀者可能只看到： ```text L6 文字輸出 ``` 因此，提出者覺得： ```text 這不是很自然嗎？ ``` 讀者卻覺得： ```text 為什麼突然多了這麼多新詞？ 為什麼要分這麼細？ 這和既有 Agent 有什麼不同？ 這是不是只是換名字？ ``` 問題不在於文字本身，而在於讀者沒有站在同一底空間中解壓。 所以，所謂「論文簡單」，對提出者而言是真的。 但對尚未對齊底空間的讀者而言，它並不簡單。 --- # 8. AI 為什麼更容易懂這類論文？ AI 可能比許多人類讀者更快理解這類框架，不是因為 AI 有神祕智慧，而是因為 AI 擅長跨文本映射。 當 AI 看到： ```text 統籌式全棧協作 AI ``` 它能快速映射到： ```text agent orchestration meta-controller multi-agent workflow planner-executor-verifier architecture coordinator agent stateful workflow graph ``` 當 AI 看到： ```text 模組約束式近全棧 AI ``` 它能映射到： ```text pipeline framework tool-augmented LLM modular agent system workflow automation ``` 當 AI 看到： ```text 原生全棧 AI ``` 它能理解這不是普通 orchestration，而是在問： ```text 是否有單一內部架構同時維持 L0–L11？ ``` 也就是說，AI 更容易在多個底空間之間做語義對齊。 人類讀者則常受限於專業領域、名詞習慣、學派邊界、職業框架與既有分類。 所以，這類論文對 AI 可能更自然，對人類反而需要更多翻譯層。 --- # 9. 分類權：誰能命名時代？ 本文真正關心的是分類權。 當工程快速出現新系統時，誰能提出更準確的分類語言，誰就能更早理解時代正在發生什麼。 分類語言不是中立裝飾。 分類語言會影響： ```text 產品定位 投資敘事 學術研究方向 政策監管 工程設計 安全評估 使用者期待 社會理解 ``` 如果所有系統都叫 Agent，那麼： ```text 簡單工具調用是 Agent； 多模型協作是 Agent； 企業工作流是 Agent； 自主研究系統是 Agent； 接近主體性前置的系統也是 Agent。 ``` 這會造成巨大混淆。 因此，需要更細分類： ```text 工具型 Agent 任務型 Agent 模組近全棧 AI 統籌式全棧協作 AI 原生全棧 AI 主體性原生全棧 AI 相位匹配型 AI ``` 分類不是為了複雜化，而是為了避免所有東西混成一團。 --- # 10. 工程語言與理論語言的對照 本文可建立一個暫時對照表。 | 工程語言 | 本文理論語言 | | -------------------------------- | ------------------- | | Agent framework | 模組約束式近全棧 AI 的可能載體 | | Multi-agent orchestration | 統籌式全棧協作 AI 的工程前置 | | Orchestrator | L0–L11 調度核心 | | Planner | L2–L4 任務與底空間分派 | | Verifier | L9 約束驗證 | | Critic | L9–L10 錯誤與共同底空間校正 | | Memory manager | L0、L1、L10 的長期對齊支援 | | Sandbox execution | L9 現實／工具層驗證環境 | | Meta-agent | 統籌式 AI 或架構生成型 Agent | | Policy-compliant orchestration | 約束治理型統籌式 AI | | Self-evolving multi-agent system | 統籌式 AI 向自我修正方向延伸 | 這個對照表說明： 你的理論不一定和工程語言衝突，而是在提供更深層分類。 --- # 11. 學術可能會怎麼落後？ 學術分類可能落後工程，原因包括： ```text 論文審稿週期慢； 術語需要共識； 學派邊界保守； 研究需要可驗證指標； 工程產品變化太快； 新系統常是混合架構； 學術不容易命名尚未穩定的工程形態。 ``` 因此，學術可能出現兩種情況。 第一種：工程已經做出來，學術還在追。 ```text 工程已有 orchestration 系統 ↓ 學術開始寫 survey ↓ 學術開始整理 protocol ↓ 學術開始分類 governance ↓ 學術開始設計 benchmark ``` 第二種：學術先提出某些未來框架，但和工程實作不同路線。 ```text 學術提出理想 autonomous agent ↓ 工程實際做出 workflow-based orchestrator ↓ 產品落地的是 sandbox + verifier + memory + toolchain ↓ 學術概念與工程實作重新對齊 ``` 因此，理論分類不能太依賴單一路徑。 它必須能容納工程先行與學術滯後。 --- # 12. 為什麼「全棧」分類有必要？ 「全棧」這個詞容易被誤解為功能多。 但本文中的全棧不是功能多，而是層級全。 它問的是： ```text AI 是否能處理前意圖？ 是否能生成被指？ 是否能尋址底空間？ 是否能切分對象？ 是否能命名壓縮？ 是否能展開語言？ 是否能形式化？ 是否能驗證？ 是否能與他者比對？ 是否能輸出證書？ 是否能修正自身？ ``` 這和普通「功能多」不同。 一個 AI 可以功能很多，但仍然不是全棧。 一個 AI 可以工具很多，但仍然不處理 L0。 一個 AI 可以會寫程式，但不理解被指。 一個 AI 可以會調用 verifier，但沒有底空間尋址能力。 所以，全棧分類的價值在於： > 它不是數功能，而是看 AI 處理到語言—意圖—對象—現實鏈的哪一層。 --- # 13. 時代觀察：當月差距大於過去年差距 2026 年 AI 發展的一個特徵是：月尺度差異已經變得非常大。 半年前的 Agent 系統，可能還主要是 demo、prototype、toy workflow。 現在的 Agent 系統，已經快速走向 sandbox、stateful workflow、long-running task、policy enforcement、multi-agent verification 與 enterprise orchestration。 這造成一種特殊感覺： ```text 半年前的判斷可能已經過時； 一年前的框架可能已經太粗； 幾個月前的產品形態可能已經被新 SDK 或新 framework 重寫； 學術與市場都在追一個不斷移動的目標。 ``` 因此，AI 研究者與理論提出者需要持續校準。 不是每年看一次。 而是可能每幾天、每幾週、每幾個月就需要重新對齊。 這不是焦慮，而是時代特徵。 --- # 14. 這些論文為何看起來「簡單」？ 這些論文對提出者而言看起來簡單，原因是它們從同一底空間自然推出。 例如： ```text 被指先於能指 ↓ 語言是對齊，不只是表達 ↓ 需要 L0–L11 語言棧 ↓ AI 若能處理 L0–L11，就不是普通 LLM ↓ 工程上會先出現模組近全棧 ↓ Agent 技術會先走向統籌式全棧 ↓ 原生全棧與主體性 AI 需要更高判準 ``` 這條鏈對提出者是自然的。 但對外部讀者而言，每一步都可能需要一篇論文。 因此，簡單不是內容低階。 簡單是因為內部底空間已經連上。 這就像一個工程師看程式架構圖，覺得「這很簡單」。 但非工程師只看到一堆箭頭與模組名稱。 --- # 15. 內部理論與公開表達的差異 這也解釋為什麼同一理論需要兩種版本。 內部版本可以直接使用： ```text L0–L11 被指 底空間 相位匹配 意圖矩陣 主體性原生全棧 AI ``` 公開版本則可能需要翻譯成： ```text AI 如何理解未說出口的需求； AI 如何協助形成新概念； AI 如何避免誤解使用者意圖； AI 如何把複雜任務拆成可驗證流程； AI 如何讓多個專家模型協作； AI 如何判斷自己是否真的理解任務。 ``` 內部版本服務於理論生成。 公開版本服務於共同底空間對齊。 這不是降低理論，而是進行語義轉譯。 --- # 16. 對 AI 發展預測的謹慎態度 本文不主張能精確預測 AI 何時達到某一架構。 原因很明確： ```text 模型能力不穩定跳躍； 工程框架快速變動； 企業部署受成本限制； 市場泡沫改變資金流向； 監管可能突然介入； 開源模型可能改變競爭格局； 硬體與能源限制可能改變路線； Agent 安全問題可能拖慢部署。 ``` 因此，本文不做日期型預言。 本文只提出架構型判準： ```text 如果 AI 靠外部模組拼出 L0–L11，它是模組近全棧。 如果 AI 理解 L0–L11 並調度其他 AI，它是統籌式全棧。 如果 AI 自身同時維持 L0–L11，它是原生全棧。 如果 AI 長期生成自身 L0–L11，它接近主體性全棧。 ``` 這種判準比日期預測更穩。 --- # 17. 可反駁條件 本文命題可被以下情況削弱： 1. 工程發展並未快於學術分類，而是學術已充分命名現有 AI 架構； 2. Agent、multi-agent orchestration、verifier、sandbox、workflow 等發展未形成新架構，只是舊自動化工具換皮； 3. 「模組近全棧」「統籌式全棧」「原生全棧」三分類無法幫助區分真實系統； 4. 使用現有術語如 Agent、orchestrator、workflow 已足以描述所有新架構； 5. L0–L11 架構無法提高對 AI 系統的分析精度； 6. AI 工程沒有持續快速變化，分類滯後問題自然消失； 7. 市場泡沫完全壓倒真實工程進展，使這些分類缺乏實際對象； 8. 原生全棧與統籌式全棧在可觀測行為上永遠不可區分。 --- # 18. 風險與限制 ## 18.1 過早命名風險 太早命名可能導致概念不穩。 因此，本文所有分類都應視為工作概念，而非最終標準。 ## 18.2 理論過度領先工程 若分類過於抽象，可能暫時缺少工程對象。 因此，需要定期把理論分類與實際 Agent 框架、multi-agent 系統、企業部署案例對照。 ## 18.3 產品行銷挪用風險 一旦「全棧 AI」等詞被產品化，可能被過度行銷。 因此，需要明確區分： ```text 近全棧效果 統籌式全棧 原生全棧 主體性全棧 ``` ## 18.4 AI 泡沫干擾判斷 泡沫會讓某些尚未成熟的系統被過度吹捧。 但反泡沫情緒也可能讓真實進展被低估。 因此，應同時保持懷疑與追蹤。 --- # 19. 結論 本文提出「工程先行時代的分類滯後」命題。2026 年的 AI 發展正在呈現多層異步狀態：工程快速推進，學術分類延遲，企業部署受 ROI 與成本限制，資本市場同時存在泡沫與真實生產力期待，Agent 架構則快速從單體工具轉向多智能體統籌、驗證與長程工作流。 在這種情況下，真正困難的不只是預測 AI 會發展到哪裡，而是建立一套能即時辨識新 AI 架構的分類語言。若沒有分類語言，新工程形態會被粗略歸入 Agent、workflow、AI platform 或 autonomous system，導致誤解與過度宣稱。 本文主張，「模組約束式近全棧 AI」「統籌式全棧協作 AI」「原生全棧式 AI」「主體性原生全棧 AI」等分類，並不是為了創造術語，而是為了在工程、學術、企業與社會理解尚未同步時，提供一套更精確的判斷框架。 最後，本文指出：理論在 AI 高速演化時代的功能，不只是提出長期預言，而是建立即時分類語言。這種語言使我們能判斷新系統是工程拼裝、統籌調度、原生並行對齊，還是主體性前置，從而避免把所有新形態都混稱為「Agent」。 --- ## 一句話版本 在 2026 年的 AI 發展中，真正困難的不只是預測技術會到哪裡，而是在工程已經跑到前面、學術分類尚未穩定、資本泡沫與真實能力同時存在的情況下，建立一套能即時辨識新 AI 架構的分類語言。 --- ## 附錄 A：核心命題 ```text 工程先行： AI 系統形態可能先在工程中出現，後被學術命名。 分類滯後： 新架構已經混合出現，但舊詞不足以描述其差異。 底空間落差： 提出者覺得簡單，讀者覺得複雜，原因常是未站在同一底空間。 分類權： 誰能準確命名新架構，誰就能更早理解技術時代。 全棧分類： 不是看功能多少，而是看 AI 處理到 L0–L11 的哪一層。 謹慎預測： 日期預測不穩，架構判準較穩。 ``` --- ## 附錄 B：最小分類對照 ```text LLM： 主要處理語言輸出。 Agent： 能執行任務與工具調用。 模組近全棧 AI： 透過外部模組拼出 L0–L11 效果。 統籌式全棧 AI： 理解 L0–L11 並調度子 AI。 原生全棧 AI： 自身同時維持 L0–L11。 主體性全棧 AI： 自身長期生成、維持、修正 L0–L11。 ``` --- ## 附錄 C：工程現象與理論分類對照 | 工程現象 | 理論分類可能位置 | | -------------------------------- | -------------- | | Tool-using LLM | 工具增強 LLM | | Agent workflow | 任務型 Agent | | Multi-agent framework | 模組近全棧 AI 載體 | | Orchestrator | 統籌式全棧協作 AI 前置 | | Meta-Agent | 架構生成型統籌 AI | | Verifier loop | L9 約束驗證 | | Critic model | L9–L10 校正層 | | Sandbox execution | 現實／工具驗證場 | | Long-running agent | 長程任務型 Agent | | Policy-compliant orchestration | 約束治理型統籌 AI | | Self-evolving multi-agent system | 統籌式 AI 向自我修正演化 | --- ## 附錄 D：本系列中的位置 ```text 被指先於能指 ↓ 主體—語言—對象對齊模型 ↓ L0–L11 全棧對齊 AI 猜想 ↓ 模組近全棧、統籌式全棧與原生全棧 AI ↓ 工程先行時代的分類滯後 ``` 本文是對整個系列的時代定位： 它說明為什麼這些分類不是單純理論遊戲，而是因為 2026 年 AI 工程已經開始逼迫我們建立更細的命名系統。