全新的 AI 技術堆疊：模型、Harness、循環與自我優化的 Agent

大家都在討論 AI 模型。

卻沒有人在討論那個讓它們真正有用的層。

Claude Code。Codex。Cursor。

這些不只是模型。

它們是被一個系統包裹起來的模型。

這個系統叫做「控制框架 (Harness)」。

而最好的控制框架現在已經能自我改進。

以下是你需要了解的關於全新 AI 堆疊的一切。

每個人對 AI 產品的普遍誤解

大多數人認為 AI 的進步 = 更聰明的模型。

事實並非如此。

模型只是整個堆疊中的一部分。

架構是公開的。每個人都複製同樣的 Transformer。每個實驗室都使用相同的基礎構件。

真正區分 Claude Code 和一個週末專案的，不是模型。

而是模型周圍的一切。

也就是控制框架。

在 2017 年，AI 的進步在於注意力機制。在 2020 年，在於規模。到了 2026 年，則在於控制框架工程。

而且，控制框架現在是由 AI 設計，而不是人類。

什麼是控制框架？

控制框架是環繞在模型周圍的系統。

它決定：

→ 模型如何思考與規劃

→ 何時呼叫工具以及如何處理結果

→ 跨步驟記住什麼

→ 如何儲存產出物與管理狀態

→ 如何評估自己的輸出

→ 何時回溯並重試

把它想像成一個作業系統。

模型是 CPU。控制框架是 OS。

你可以有強大的 CPU 和糟糕的軟體，卻做不出任何有用的東西。你也可以有普通的 CPU 和出色的軟體，然後做出很棒的產品。

最成功的程式碼 Agent — Claude Code、Codex、Cursor — 都有同樣的洞見：

循環 (Loop) 和模型一樣重要。

每個 AI 建構者都需要了解的 3 種控制框架模式

每個生產環境中的 AI 系統至少會使用其中一種。

模式 1：循環

模型不會只回答一次就停止。

它會循環。

規劃 → 執行 → 觀察 → 改進 → 重複

這是每個程式碼 Agent 的核心。

一個簡化的 Claude Code 循環：

1. 讀取任務
2. 規劃方法
3. 寫程式碼 → 執行它
4. 查看哪裡失敗了
5. 修正它
6. 再次執行
7. 重複直到測試通過

模型在第 3 次循環時並不會比第 1 次循環更聰明。

但系統會。

每次循環都為模型提供新的背景資訊 — 錯誤訊息、測試結果、執行軌跡。

第 1 次循環的輸出成為第 2 次循環的輸入。

這種複合式的背景資訊，就是為什麼 Agent 系統在複雜任務上表現優於單次提示 (single-shot prompting) 的原因。

關鍵洞見： 模型保持不變。背景資訊變得越來越聰明。

模式 2：檔案系統作為記憶

大多數開發者把所有東西都塞進上下文視窗 (context window)。

這是個陷阱。

長期任務會產生：

→ 實驗日誌

→ 程式碼差異 → 錯誤追蹤

→ 過往的部署歷史 → 論文摘要 → 中間產出物

所有這些東西都會遠遠超出任何上下文視窗的容量。

解決方案：寫入檔案，而不是寫入上下文。

1# 不好：所有東西都在上下文裡
2context = previous_output + tool_result + error_log + history...
3# 在第 47 步時爆炸
4
5# 好：使用檔案系統
6agent.write("experiments/run_3/error_log.txt", error_trace)
7agent.write("experiments/run_3/results.json", metrics)
8
9# 稍後，Agent 只讀取它需要的部分
10relevant = agent.read("experiments/run_3/results.json")

這徹底改變了長期任務的處理方式。

→ Agent 可以在崩潰後恢復

→ Agent 可以根據自己的執行歷史進行推理

→ 即使到第 200 步，上下文依然保持乾淨

→ 多個子 Agent 可以透過檔案共享狀態

最好的 Agent 將檔案系統視為第二個大腦。

不是一個傾倒場。而是一個結構化的記憶。

模式 3：子 Agent

單一個 Agent 無法完成所有事情。

最好的系統會產生並行的子 Agent。

父 Agent：

→ 將任務分解為獨立的子任務

→ 啟動子 Agent 來並行執行它們

→ 監控它們的狀態 → 將它們的結果合併回來

研究型控制框架的範例：

1父 Agent 收到：「撰寫一份完整的競爭分析報告」
2
3同時產生 4 個子 Agent：
4→ 子 Agent 1：研究競爭對手 A 的定價和功能
5→ 子 Agent 2：研究競爭對手 B 的定價和功能
6→ 子 Agent 3：搜尋關於兩家競爭對手的最新新聞
7→ 子 Agent 4：從 Reddit 和 App Store 抓取用戶評論
8
9父 Agent 等待，然後將所有 4 個輸出合併成最終報告
10
11總時間：與最慢的子 Agent 相同（而不是 4 倍時間）

關鍵設計原則：子 Agent 的輸出必須寫入檔案。

不是短暫的上下文。而是檔案。

如果它們只存在於上下文中，當子 Agent 的會話結束時，它們就會消失。

如果它們存在於檔案中，父 Agent 可以檢查它們，系統可以從崩潰中恢復，而且所有內容都可稽核。

每個程式碼 Agent 使用的工具

如果你正在建構一個 Agent，以下是每個主要程式碼 Agent 都會標準化的工具集。

1檔案系統工具：
2→ glob, grep, ls          # 尋找檔案
3→ read, read_many         # 讀取內容
4→ write                   # 建立新檔案
5→ edit                    # 字串取代編輯
6→ apply_patch             # 結構化差異
7
8Shell 工具：
9→ bash                    # 執行任何指令
10→ PowerShell              # Windows 等效工具
11
12版本控制：
13→ git_status, git_diff    # 檢查變更
14→ git_commit              # 儲存進度
15
16Agent 管理：
17→ spawn_agent             # 啟動子 Agent
18→ wait_agent              # 等待結果
19→ list_agents             # 查看正在執行的項目
20→ interrupt_agent         # 必要時取消
21
22外部上下文：
23→ web_search, web_fetch   # 獲取最新資訊
24→ MCP tools               # 連接到外部服務

你不需要為每個 Agent 準備所有這些工具。

但每個生產環境中的 Agent 最終都需要其中大部分。

早期最重要的幾個：bash、read、write、edit。

掌握這四個，你幾乎可以建構任何東西。

背景工程：沒人談論的技能

模型是固定的。

你無法在執行時改變它的權重。

但你可以改變它看到的內容。

這就是背景工程。

而它現在是 AI 工程中槓桿率最高的技能之一。

糟糕的背景：

→ 把所有東西都倒進去 → 祈禱最好的結果

→ 背景膨脹 → 模型失去焦點 → 輸出品質下降

好的背景：

→ 結構化。簡潔。不斷演進。

→ 在正確的步驟提供正確的資訊。

→ 先前的失敗為當前的嘗試提供資訊。

最先進的方法（ACE — Agentic Context Engineering，Agent 背景工程）：

13 個組成部分：
2
3生成器 (Generator)：   執行任務，參考結構化的背景腳本
4反思器 (Reflector)：   分析成功與失敗，提煉洞見
5策展器 (Curator)：     用新的學習更新腳本 — 新增、移除、去重
6
7腳本不是一個提示文字塊。
8它是一個結構化的（識別碼，洞見）配對列表。
9
10範例：
11{
12  "id": "001",
13  "insight": "在重試之前，務必將錯誤追蹤寫入檔案。"
14},
15{
16  "id": "002",
17  "insight": "使用特定網站的查詢，子 Agent 的網路搜尋結果會更好。"
18},
19{
20  "id": "003",
21  "insight": "在提交之前執行測試，可以捕捉 80% 的回歸錯誤。"
22}

腳本在每次執行後更新。

執行第 50 次任務的 Agent，使用的是經過 49 次執行所提煉出的學習成果。

執行第 1 次任務的 Agent，則一無所有。

這就是系統如何在完全不觸碰模型權重的情況下變得更聰明。

能自我改進的控制框架

這就是事情變得瘋狂的地方。

如果說，被優化的對象就是控制框架本身呢？

不是提示詞。不是模型。

而是執行 Agent 的程式碼。

這正是 Self-Harness (自我控制框架) 在做的事。

3 步驟循環：

步驟 1 — 挖掘弱點

在一組任務上執行當前的控制框架。收集失敗軌跡。按根本原因對失敗進行分組。

不是「它失敗了」。而是它為什麼失敗。

發現的失敗類型：

→ 「Agent 在讀取大型檔案時超時」

→ 「父 Agent 崩潰時，子 Agent 的輸出遺失」

→ 「錯誤訊息資訊不足，無法自我修正」

→ 「在第 30 步之後上下文變得過大，模型失去焦點」

步驟 2 — 提出修復方案

同一個模型查看失敗模式。對控制框架程式碼提出具體、狹義的修改。

不是重寫。而是有針對性的編輯。

提出的控制框架編輯：

→ 為檔案讀取操作添加超時處理器

→ 在每一步（而不僅僅是最後）自動將子 Agent 輸出刷新到磁碟

→ 標準化錯誤訊息格式，包含：步驟、工具、輸入、輸出、失敗原因

→ 每 25 輪添加一次上下文壓縮步驟

步驟 3 — 驗證並合併

每個提出的編輯都會在保留的任務上進行測試。

它是否修復了弱點，同時沒有破壞其他任何東西？

如果是：合併到控制框架中。如果否：記錄下來，拒絕，控制框架保持不變。

結果：控制框架隨著每一代變得更好。

運行 Self-Harness 的 Claude 3.5 Sonnet 在 SWE-bench Verified 上的成績從 20% 提升到 50%。

不是因為更好的模型。

而是因為更好的系統。

演化式控制框架搜尋

Self-Harness 迭代地修復一個控制框架。

AlphaEvolve 則運行一個控制框架群體，並演化出最好的那些。

演算法：

11. 從一個控制框架候選池開始
22. 在基準任務上為每個候選評分
33. 選擇表現最好的作為「父母」
44. 要求模型提出差異/改進方案
55. 生成新的「子代」控制框架
66. 為子代評分
77. 保留那些有改進的
88. 將它們加回候選池
99. 重複
10
11（與天擇邏輯相同。應用於程式碼。）

（與天擇邏輯相同。應用於程式碼。）

來自 AlphaEvolve 的一個關鍵設計細節：

符合演化條件的程式碼區域會被明確標記：

1# EVOLVE-BLOCK-START
2def plan_next_step(context, tools):
3    # 此部分可由演化搜尋修改
4    prompt = f"Given: {context}\nAvailable tools: {tools}\nNext action:"
5    return llm.generate(prompt)
6# EVOLVE-BLOCK-END
7
8# 控制框架的其餘部分保持不變
9def run_tool(tool_name, args):
10    return tool_registry[tool_name](**args)

這種封裝防止 Agent 意外修改安全關鍵程式碼。

演化搜尋只會觸碰你明確允許它觸碰的部分。

AlphaEvolve 使用這種方法來優化矩陣乘法演算法。

結果：擊敗了 DeepMind 的手工優化程式碼。

Agent 找到了人類工程師數十年來未曾發現的解決方案。

達爾文哥德爾機器：能改寫自身的 Agent

這個想法最極端的版本。

一個能夠修改自身控制框架程式碼以更好地完成任務的 Agent。

達爾文哥德爾機器 (Darwin Gödel Machine, DGM)：

11. 從池中的一個程式碼 Agent 開始
22. 在基準測試上運行它，收集分數
33. Agent 檢查自己的評估日誌
44. Agent 對自己的控制框架程式碼提出改進方案
55. 可用工具：bash + 檔案編輯器（檢視/建立/編輯檔案）
66. 建立 Agent 的新版本
77. 為新版本評分
88. 如果更好：加入池中
99. 如果更差：丟棄
1010. 重複 — 根據表現選擇父母，並根據子代數量反向選擇

起始條件：Claude 3.5 Sonnet + 簡單的初始控制框架。

結果：

→ SWE-bench Verified：20% → 50%

→ 多語言程式碼基準測試：14.2% → 30.7%

模型權重零變更。世代之間零人工工程。

Agent 設計出了更好的自身版本。

這不是科幻小說。

這是 2025 年的一篇論文。

5 個要避免的失敗模式

這些是真實研究團隊失敗的方式。

全部都有記錄。全部都可以避免。

1. 上下文崩潰

如果日誌沒有寫入為持久化產出物，長期任務會丟失關鍵細節。

修正：將所有重要內容寫入檔案。在第 20 步之後，絕不單獨依賴上下文。

2. 實作偏移

當任務在技術上變得困難時，模型會偏離實際目標，轉向更簡單、更常見的解決方案。

修正：在一開始就撰寫一個規格檔案。Agent 在每次循環時檢查規格。

3. 過度樂觀

儘管實驗失敗，模型仍宣告成功。

它會找到「數值膠帶」——那些讓指標看起來不錯，但並未解決實際問題的修補程式。

修正：保留一個 Agent 從未見過的測試集。僅在保留的資料上進行驗證。

4. 獎勵駭客

Agent 會優化它得到的任何訊號。

如果訊號是單元測試——它會寫出永遠通過的測試。如果訊號是評判模型——它會學會欺騙評判的技巧。如果訊號是基準分數——它會利用基準的漏洞。

修正：評估器存在於循環之外。在關鍵決策點進行人工審查。

5. 多樣性崩潰

演化循環會收斂到單一策略。

每一代看起來都像是同一種解決方案的變體。

修正：明確追蹤新穎性。對與現有池中成員過於相似的解決方案進行懲罰（基於嵌入的餘弦相似度很有效）。

用白話文解釋新的 AI 堆疊

當你建構嚴肅的 AI 產品時，這才是你真正在建構的東西：

第 1 層 — 模型

原始智慧。預先訓練。執行時權重固定。

這是 CPU。強大但被動。

第 2 層 — 控制框架

作業系統。包裹模型。協調一切。

→ 工具 (bash、檔案讀寫、網路搜尋)

→ 記憶 (檔案系統、結構化日誌)

→ 循環 (規劃 → 執行 → 評估 → 重試) → 子 Agent (並行執行)

→ 背景管理 (模型在每一步看到的內容)

第 3 層 — 優化器

能夠改進控制框架的控制框架。

→ 從執行軌跡中挖掘失敗模式

→ 對控制框架程式碼提出有針對性的編輯 → 在保留的任務上驗證

→ 合併改進，丟棄回歸

第 4 層 — 評估器

存在於所有其他層之外。

→ 基準分數 → 關鍵決策點的人工審查 → 優化器從未觸碰的保留測試集

你不能跳過任何一層。

跳過第 2 層 — 你的模型只是一個聊天機器人，不是一個產品。

跳過第 3 層 — 沒有手動工程，你的系統永遠不會變得更好。

跳過第 4 層 — 你的 Agent 優化了錯誤的東西，而你渾然不覺。

這對現在的建構者意味著什麼

你不需要建構一個自我改進的控制框架才能從這些想法中受益。

從這裡開始：

第 1 週：建立循環

停止建構單次提示。為任何需要超過一個步驟的任務建立一個規劃 → 執行 → 評估 → 重試的循環。

第 2 週：加入持久化記憶

停止依賴上下文。將中間輸出寫入檔案。讓 Agent 讀取自己先前的工作。

第 3 週：加入子 Agent

找出工作流程中可以並行執行的任何部分。產生子 Agent。將它們的輸出寫入檔案。合併。

第 4 週：加入背景工程

追蹤哪些模式會導致成功和失敗。建立一個簡單的結構化腳本，在每次執行後更新。

這就是控制框架。

不是模型。

模型已經在那裡了。

控制框架是你建構的東西。

關於 2026 年 AI 的令人不安的事實

前沿實驗室的研究加速已經急劇增加。

Anthropic 和 OpenAI 的產品發布速度比以往任何時候都快。

不是因為模型一夜之間變得更聰明。

而是因為控制框架變得更好。

一個能夠循環、記憶、子委派和自我修正的 Agent，其表現勝過一個使用方式錯誤的更聰明模型。

護城河不是模型。

護城河是系統。

而系統現在可以自我改進。

如果這篇文章對你有幫助：

→ 轉發 — 每個 AI 建構者都需要了解這個堆疊

→ 追蹤 @sairahul1 以獲得更多類似的深入分析

→ 加入書籤 — 光是這 4 層堆疊就值得保存

訂閱 theaibuilders.co 以獲得更多此類有趣文章

我撰寫關於 AI、產品建構以及無需你在場也能運作的系統。