什麼是 agent 執行框架？研究、開源專案與業界實務

兩個 agent 即使使用完全相同的模型，在同一基準測試上的分數也可能天差地遠。OpenAI 直接測得：在 SWE-bench Lite 上，GPT-4 使用一種執行框架時得分為 2.7%，換成另一種則為 28.3%——完全由執行框架造成的 10 倍差距。隨著業界從「哪個模型最聰明」轉向「哪個 agent 真能完成工作」，agent 執行框架便成為可靠性成敗的關鍵層。繼續閱讀，了解 agent 執行框架是什麼、最新論文與基準測試對執行框架設計有何發現、哪些開源執行框架值得投入時間，以及主要 AI 實驗室如何打造自家的執行框架——其中包括 Moonshot AI 與自家執行框架搭配的開放權重模型 Kimi K3.1 Pro。

agent 執行框架是讓大型語言模型能在真實環境中以 agent 身分運作的周邊基礎設施。模型負責產生 token，執行框架則處理其他一切：在每一步建立提示詞、定義可用工具及其呼叫方式、在沙箱或終端機中執行動作、將觀察結果回饋給模型、設定步數與成本上限，並記錄完整軌跡以供評估或除錯。

這個術語源自評估領域——「測試執行框架」是讓系統在受控條件下運行的架構。在 agentic AI 中，這個概念延伸至生產環境：執行框架既是用來衡量 agent 的架構（如 SWE-bench 或 Terminal-Bench），也是用來運行 agent 的架構（如 SWE-agent、OpenHands 或 Claude Code）。

Anthropic 自身的 SWE-bench 研究說得很明白：此基準「評估的不只是孤立的 AI 模型，而是一整個『agent』系統」，其中 agent 是「AI 模型與其周邊軟體支架的組合」。他們升級版的 Claude 3.5 Sonnet 在 SWE-bench Verified 上達到 49%，靠的不是複雜框架，而是只包含一個提示詞與兩項通用工具（Bash 工具與 Edit 工具）的極簡執行框架。

多年來，排行榜上的進步都被歸因於模型規模。近期研究從兩個方向打破了這項假設。

首先是「少即是多」的結果：2025 年 7 月，SWE-bench 團隊發布了 mini-SWE-agent，這是一個約 100 行 Python 的執行框架，除了 bash 外沒有其他工具，訊息歷程完全線性，且每項動作都以獨立的 subprocess.run 呼叫執行。它的基準分數可與複雜得多的框架競爭（詳見下方研究章節）。這項啟示頗具挑戰性：當模型足夠強大時，極度簡單且可預測的執行框架可能勝過重量級框架。Meta、NVIDIA、IBM、Princeton 與 Stanford 已將其用作基準線。

其次是「多即是少」的結果：糟糕的執行框架——雜訊過多的工具輸出、無上限迴圈、錯誤的錯誤復原機制——會讓前沿模型看起來表現平平。OpenAI 發現，清理 SWE-bench 中有缺陷的任務（詳見下方 OpenAI 章節）後，測得的模型效能提升超過一倍。

這也是執行框架工程成為獨立專業的原因。執行框架決定了：

• 模型看到什麼：提示詞結構、工具 schema，以及在上下文視窗中納入多少環境狀態與歷程。

• 模型能做什麼：可用工具（shell、檔案編輯器、瀏覽器、搜尋），以及動作在執行前如何被解析與驗證。

• 如何處理失敗：重試、逾時、視窗填滿時的上下文壓縮，以及妥善終止。

• 如何衡量工作：軌跡記錄、評分與成本核算——缺少這些，就無法評估，也無從形成改進迴圈。

無論是研究基準測試架構還是生產環境的程式設計助理，幾乎所有 agent 執行框架都實作了相同的核心迴圈：

1. 任務接收：讀取 issue、指示或目標，並啟動隔離環境（通常是 Docker 容器或 VM 快照）。

2. 提示詞組裝：結合系統提示詞、工具定義、任務描述，以及持續累積的動作與觀察結果歷程。

3. 動作解析：將模型輸出轉換為具體的工具呼叫——bash 指令、檔案編輯或 API 請求——並拒絕格式錯誤的動作。

4. 執行與觀察：在環境中執行動作、擷取 stdout/stderr 或 UI 狀態，並將其截短以符合內容預算。

5. 控制流程：強制執行步數上限、成本上限與停止條件；判斷何時該詢問人類或結束此次執行。

6. 記錄與評分：儲存完整軌跡並評估最終狀態——例如在 SWE-bench 中執行儲存庫的測試套件。

每一步的設計選擇都會累積影響。光是截斷策略，就足以讓長時程任務的分數明顯波動；因此，認真的團隊會將框架視為可版本控制、可測試的軟體，而非黏合程式碼。

關於智慧體框架的學術文獻，已歸納出少數幾項得來不易的結論。本節不會羅列每一項基準測試，而是追溯那些迫使這個領域正視框架的研究問題。

在進入論文前，先快速說明。一項基準測試是一組固定任務加上一套評分規則，旨在讓不同系統能在相同條件下比較。在智慧體評估中，基準測試由三個可變部分組成：任務集（真實 GitHub issue、終端機指令、網頁任務）、執行環境（Docker 容器、瀏覽器、終端機），以及評分器（測試套件、狀態檢查、人工作業審查）。框架位於模型與這三者之間——它決定模型的能力是否能反映在分數上。

分數實際如何衡量，比醒目的數字更重要。在 SWE-bench 中，智慧體會產生程式碼修補；接著基準測試會執行兩套測試：FAIL_TO_PASS（修正前失敗、修正後必須通過的測試）與 PASS_TO_PASS（修正前已通過、修正後不得失敗的測試）。兩者都通過時，任務才會被計為已解決。這也是為什麼測試執行與 diff 產生等框架功能不是可有可無的附加功能——分數的得失就在這裡。

解讀任何基準測試分數的三項原則：

1. 問問分數掩蓋了什麼。在公開 GitHub 資料上訓練的模型，可能已看過它正在測試的那些 issue——資料汙染可能在沒有真正能力提升的情況下拉高分數。可重現的環境與保留任務集是解方。

2. 留意 Goodhart 定律：當衡量指標成為目標，它就不再是好的衡量指標。為了在某項基準測試取得高分而調校的框架，可能學到的是該基準特有的技巧，而非通用能力——因此，認真的團隊會在不只一項基準測試上評估。

3. 檢查框架，而不只是模型。如本節其餘內容所示，同一個模型依據所用的支撐架構不同，分數可能是 2.7% 或 28.3%。沒有指明框架的分數，只是軼聞，不是測量結果。

最初的 SWE-bench 論文（"Can Language Models Resolve Real-World GitHub Issues?"）提出了如今已成經典的評估方式：給模型一個真實 GitHub issue 與完整儲存庫，並根據其修補是否能讓失敗測試通過來評分。它最常被引用的結果經常遭到誤讀：當時最好的模型 Claude 2 僅解決了 1.96% 的任務。作者自己的說法是，這項基準測試檢驗的是「遠超傳統程式碼生成的複雜推理」；但後續研究清楚指出，落差很大一部分並非推理能力不足，而是缺少能瀏覽儲存庫、執行測試並反覆迭代的框架。換言之，SWE-bench 不只衡量模型；它也揭示了模型周圍的框架正是缺失的一塊。

SWE-agent 論文（"Agent-Computer Interfaces Enable Automated Software Engineering"）是此領域探討框架設計的奠基文件。其核心主張是：介面設計是一階變數。作者提出了 Agent-Computer Interface（ACI）一詞，並證明專門打造的介面——具 linter 防護的檔案編輯器、精簡的 shell 回饋、針對格式錯誤指令的防護機制——可將 SWE-bench 的 pass@1 從個位數百分比提升至當時最先進的 12.5%。這篇論文持久的貢獻，在於主張「LM 智慧體代表了一類新的終端使用者」，需要如同人類需要 IDE 一樣，為它們打造專用軟體。後續每篇框架論文都引用了這項結果。

兩篇 2024 年論文將框架研究從程式碼儲存庫延伸至完整電腦環境。OSWorld打造了首個可擴展的真實電腦環境，涵蓋 Ubuntu、Windows 與 macOS，包含橫跨網頁與桌面應用程式的 369 項任務。其醒目的數據——人類完成 72.36% 的任務，最佳模型僅完成 12.24%——指出 GUI grounding（將模型輸出轉換為正確的點擊與按鍵）是主要失敗模式；這是框架問題，而非知識問題。WebArena則採取不同角度：它提供自架、完全可重現的網頁環境（電商、論壇、GitLab、CMS），其中 GPT-4 的端到端成功率僅為 14.41%，人類則達 78.24%。兩篇論文都確立了一點：框架評估必須以執行結果為準（檢查環境最終狀態），而非依模型輸出進行模式比對。

Sierra 的 τ-bench（"A Benchmark for Tool-Agent-User Interaction in Real-World Domains"）提出了更細微的一點：在生產環境中，框架不只包裹模型與環境——它也調節使用者。此基準測試模擬語言模型使用者與具備領域 API 和政策指南的智慧體之間的動態對話，然後評估最終資料庫狀態。其關鍵指標 pass^k（跨 k 次獨立試驗的成功率）揭露了智慧體有多麼不一致：GPT-4o 單次解決的任務不到 50%，而在零售領域，pass^8 降至 25% 以下。這對框架建構者的啟示是：可靠性是一種分布特性，而非單次執行的特性——只在一次執行中有效的框架，稱不上有效的框架。

METR 的 "Measuring AI Ability to Complete Long Software Tasks"提出了50% 任務完成時間範圍：模型能以 50% 可靠度完成的任務長度（以人類完成時間衡量）。前沿模型在 2019 至 2025 年間，從能完成數分鐘的任務進展至約一小時，約每七個月翻倍一次。對框架工程而言，這是本十年最具影響力的發現：限制 2024 年模型的框架，對 2026 年模型而言就是累贅。Anthropic 的觀點是，框架中的每個元件都蘊含對模型「做不到什麼」的假設——而隨著模型進步，這些假設會過時。

最初的基準測試已發展為一個將這些經驗付諸實行的生態系：

• SWE-bench Verified（與 OpenAI 合作，2024）：由 500 個經人工篩選的實例構成的子集，移除了規格不明或評分不公平的任務——原始資料池有 68.3% 被篩除，測得分數因此增加超過一倍，並成為預設排行榜。

• SWE-smith（2025）：用於產生合成訓練任務的管線，讓模型可針對自主式框架進行訓練，而不只是接受其評估。

• mini-SWE-agent（2025）：這個約 100 行的框架目前在 SWE-bench Verified 上已超過 74%，證明當模型夠強時，採用線性歷史紀錄、僅使用 bash 的精簡迴圈便已足夠——也正成為社群的預設基準。

• Terminal-Bench（Stanford × Laude，2025）：基於 Harbor 框架的終端機任務評估，將框架從程式碼編輯推進至系統管理領域。

• CodeClash（2025）與 ProgramBench（2026）：以目標為導向、從零開始建立軟體，將框架從單一 issue 修正延伸至開放式開發。

貫穿所有這些研究的一致脈絡是：框架不是管線工程，而是研究對象。報告分數時應一併說明框架、維持環境可重現，並對無法檢視其框架的任何結果抱持懷疑。

大多數團隊都從開源框架開始。以下專案兼具龐大的 GitHub 社群（領先者的星數達數萬）與積極維護：

在這些方案之間做選擇時，社群的經驗法則是：採用能表達任務需求的最精簡執行框架（mini-SWE-agent 的理念），只有在量測到失敗情況確實需要時才增加複雜度。DeepSeek Harness 位於光譜的另一端——它是完全由外掛驅動的平台，適合希望每一層都能替換的團隊——但兩者秉持相同原則：以耐用、僅附加的工作階段日誌作為模型所見內容的唯一真實來源。

前沿實驗室將執行框架工程視為核心智慧財產，且有數家以罕見的詳盡程度公開了其思考方式。

Anthropic 公開了最完整的執行框架工程紀錄，其架構可從 Building Effective Agents（2024）、SWE-bench 執行框架文章（2024）及 Managed Agents（2026）的說明中，看作三個同心層次。

執行層刻意維持極簡：以 Bash 工具執行指令，以 Edit 工具檢視及修改檔案。設計心力放在讓這些工具不易出錯——要求使用絕對路徑、截斷過長輸出，且僅在字串唯一匹配時套用修改——使模型很少需要從可避免的工具失敗中復原。

工作階段層是位於模型上下文視窗之外、耐用且僅附加的事件日誌。每一項動作與觀察都會記錄於其中；模型的上下文是該日誌的投影，而非日誌本身。這種分離讓失敗的執行框架程序能重新啟動並從任務中途繼續，也使執行框架成為可隨時替換的「牲畜」，而非需要細心照料的寵物。

協調層——Anthropic 稱之為 「meta-harness」——透過明確介面，將「大腦」（模型及其迴圈）與「雙手」（沙箱與工具）分離。由於大腦不再位於執行容器內，可依需求配置沙箱，憑證則可保存在沙箱永遠無法存取的保管庫中。他們指出，成效屬於結構性而非表面性的改善：首次 token 時間的 p50 降低約 60%，p95 降低超過 90%，因為工作階段不再等待可能永遠用不到的容器。

這三份文件記錄了這項演進：Building Effective Agents（2024）、SWE-bench 執行框架文章（2024）及 Managed Agents（2026）。

OpenAI 與 SWE-bench 團隊合作建立經人工驗證的 Verified 分割集，正是因為執行框架需要乾淨的任務：其標註計畫（93 位開發者、1,699 個樣本）發現，原始基準測試中有 68.3% 的任務存在問題，而移除這些任務後，測得的效能增加了一倍以上。同一篇文章指出，光是選擇不同執行框架，就能讓 GPT-4 在 SWE-bench Lite 上的成績從 2.7% 提升至 28.3%；他們以此差距主張，評估必須將社群建立的執行框架所帶來的進展納入考量。

在開源方面，Codex CLI 提供完整的參考執行框架。它的分層架構與本節其他系統相呼應：核心 agent 迴圈負責規劃與工具呼叫；沙箱層以每項任務可設定的政策隔離執行；工作階段層保存對話，以便繼續、分支或壓縮；工具層則提供本機 shell 存取及基於 MCP 的外部工具。同一引擎並未硬編碼為單一介面，而是透過三種介面提供：供互動式工作的終端機 UI、供 VS Code 等豐富用戶端使用的 JSON-RPC 應用程式伺服器，以及供雲端沙箱使用的遠端程式碼執行服務，因此執行框架可在本機執行或透過程式控制。此設計採取了研究文獻建議的相同取捨：精簡迴圈、強固沙箱、明確的上下文管理，以及模型與外部世界之間清楚的界線。

透過 Agent Development Kit (ADK) 與 Agent2Agent (A2A) protocol——兩者於 2025 年 4 月推出，合作技術夥伴超過 50 家，包括 Atlassian、Salesforce、SAP 與 ServiceNow——Google 正將執行框架層產品化。A2A 將 agent 如何公布能力（透過 JSON「Agent 卡片」）、管理長時間執行的任務、交換產物及協商 UI 格式加以標準化，讓執行框架成為可互通的基礎設施，而非量身打造的黏合程式。它明確設計為補足 Anthropic 的 Model Context Protocol (MCP)，後者將執行框架中的工具端標準化。

Microsoft 的 AutoGen 與 Magentic-One 都提供執行框架，由一個協調 agent 管理事實與進度帳本——這是一種已公開的設計，可避免簡單執行框架常見的無限迴圈。Meta 與 Hugging Face 的 GAIA 建立了一套通用助理基準測試，其執行框架會評測需要網頁瀏覽與檔案處理的真實世界問題；Hugging Face 的 Open Agent Leaderboard 則持續推動可比較、具執行框架意識的排名。

DeepSeek Harness (dsh) 將元執行框架的概念化為可組合的架構。其架構建立於 Cordis framework，而核心主張是：執行框架的每個部分都是可替換的外掛程式——包括模型適配器、工具登錄表、工作階段日誌，甚至 agent 迴圈本身。

這項設計建立在三個基本元件上。第一，是作為模型所見內容唯一事實來源的持久化工作階段日誌；任何送達模型的內容都必須能從日誌重建，並將此要求作為執行階段不變條件。第二，是能力切點：在 agent 與外部世界之間設置可替換的供應者介面，因此只要將檔案系統與子程序供應者指向遠端沙箱，Bash、終端機與語言伺服器的存取便會隨之移轉，無須分叉執行框架。第三，是明確的回合／步驟生命週期，具備具名的擴充事件（agent/pre-step、tools/execute、agent/turn-stopping），讓外掛程式可攔截或改寫迴圈，而不必修改核心程式碼。

其成果是最接近 Anthropic 元執行框架理念的開源實作：其結構不是固定框架，而是可透過設定替換的外掛程式組合。推出首幾個月便獲得超過 17 萬個 GitHub stars，顯示 agent 執行框架正成為獨立的產品類別。

它們共有的模式是：保持迴圈簡單、將一切置於沙箱中、記錄每個步驟，且絕不在沒有產生該分數的執行框架時相信任何分數。

本節至此討論的一切——最小迴圈、持久化工作階段日誌、沙箱化執行、外掛架構——都共享一項假設：agent 的環境是一台電腦，也就是終端機、瀏覽器、檔案系統與程式碼儲存庫。執行框架的存在，是為了讓 agent 能可靠地操作這台機器。

但上述研究脈絡指向另一個方向。τ-bench 將使用者納入執行框架；METR 顯示 agent 承擔的工作橫跨數天而非數分鐘；OSWorld 與 WebArena 則將環境從乾淨的程式碼儲存庫移到雜亂的真實世界。方向一致：當 agent 從程式開發工具轉為實際工作的助理，它們必須周旋的環境不再只是矽晶片，而是人——有期待的使用者、有歷史脈絡的團隊、具備權限與制度知識的組織。

這項轉變主要衝擊一個執行框架子系統：context management。終端機工作階段只有一名操作者，歷史紀錄也有限；長期合作卻可能涉及十名利害關係人、數月的決策，以及持續增長的程式碼儲存庫。檔案系統是被動的；工作關係則充滿隱含承諾、未竟想法與隨口做出的選擇。所有這些內容在送達模型前都必須摘要、壓縮或捨棄，而每一個決定都可能讓 agent 遺失任務所需的資訊。

執行框架可以壓縮，但無法任意壓縮。因此，context window 的大小不再只是模型規格，而成了執行框架的設計參數。

Moonshot AI 的執行框架產品組合，將本文前述的架構對應到一套託管堆疊。針對 Agent × Computer 問題，其執行框架擴展了標準迴圈：Kimi瀏覽器擴充功能 透過 Chrome DevTools Protocol 操控真實瀏覽器工作階段，而非無菌的沙箱；行動前詢問切點在檔案系統層級確保使用者同意；Agent Swarm 則可協調多達 300 個子 agent，以處理長期任務。

驅動該迴圈的是 Kimi K3.1 Pro——K3.1 系列的首款模型，也是 Moonshot AI 至今能力最強、3T 級的開放權重模型，具備 1,048,576 token 的 context window。其三項特性直接影響執行框架設計：

• 足以延後壓縮的大型 context window。 一百萬 token 可同時容納運作中的程式碼儲存庫、持續進行的軌跡與參考文件。執行框架仍會截斷內容——它總是必須如此——但開始摘要而導致資訊損失的門檻被大幅推後，使長期任務不再進行到一半便悄然劣化。

• 將推理投入程度作為執行框架的調整項。 K3.1 Pro 一律會進行思考，且 reasoning_effort 可接受 low、high 或 max，預設為 max。這讓模型的推理成本成為由執行框架為每項任務設定的預算，而非固定的入場成本。

• 在工作階段中途加入的工具。 動態工具載入讓執行框架可在 system message 中注入完整的工具定義，使工具從該訊息起即可使用——無須重新啟動，也不必在從未使用該工具的對話每一回合都為其 schema 付費。

Moonshot 將執行框架與模型一併報告，這正是本文所主張的做法。在 Terminal-Bench 4.0 上——該測試會以嚴格的任務專屬測試，評分 coding agent 在寫實且資源受限的終端機任務中的表現——K3.1 Pro 達到 65.7%，高於 GPT-6 Astra 的 58.2%，僅略低於 Claude Opus 5.5 的 66.4%。在 Kimi Code Bench 3.0 Long-horizon 這項用於評估多步驟執行、工具使用與端到端問題解決的內部基準測試中，其得分為 61.2%，K3 則為 55.95%。文件同樣明確說明反向的耦合關係：temperature 與 top_p 等取樣參數已固定，請求中不得包含；而完整的 assistant message 必須在各回合間原封不動地回傳——若執行框架改寫該訊息，就會遺失下一次工具呼叫所依賴的推理內容。

同一模型覆蓋整個產品介面。你可以透過 Kimi Agent 試用託管網頁版、使用 Kimi Work 在本機執行完整執行框架、透過 Kimi Code 在終端機中工作，或直接透過 Kimi API 呼叫 kimi-k3.1-pro。kimi-k3.1-pro-highspeed 變體以約兩倍的 token 價格，換取兩到三倍的輸出速度。

無論是在評估模型或推出產品，都適用同一份檢查清單：

1. 從任務出發，而非從框架出發。 若 agent 要編輯程式碼，SWE-agent 的 ACI 這類結合 bash 與編輯器的執行框架已有實證。若它們需要操控 GUI 或即時網頁，則需要真實工作階段觀測與點擊層級的操作。

2. 讓環境可重現。 Docker 映像檔、固定版本的相依套件與設有種子的資料，是基準測試與軼事之間的差別。

3. 有意識地規劃 context window 預算。 觀測截斷、歷史摘要與壓縮都是直接影響分數與成本的執行框架功能——也是長 context 模型能減少執行框架必須丟棄內容的原因。

4. 強制設定硬性限制。 每個工作階段的步數上限、實際經過時間逾時限制與金額預算，可確保 agent 安全，也讓評估結果可比較。

5. 從第一天就記錄完整軌跡。 每個嚴謹的改善迴圈——人工審查、失敗群集分析、微調——都需要軌跡資料。Anthropic 的 Managed Agents 與 DeepSeek Harness 更進一步：將工作階段日誌保留在執行框架迴圈之外，作為僅附加的事件串流，如此執行框架本身可隨時替換，模型 context 也永遠能夠重建。

6. 在不只一種執行框架上評估。 若你的 agent 只在單一執行框架中運作，就代表你建構的是特定執行框架的行為，而非能力。

7. 別將憑證放進沙箱——或者乾脆不要放到雲端。 將 agent 的執行環境視為不受信任；把 token 存放在保管庫並透過 proxy 注入，或在本機執行整個工作階段，讓憑證與頁面內容永不離開裝置——這正是 Kimi 在其本機執行框架採取的方式。

agent 執行框架已悄然成為 agentic stack 中最重要的一層。來自 SWE-bench、mini-SWE-agent、Terminal-Bench 與 METR 的研究顯示，執行框架設計的影響可與模型升級相提並論；DeepSeek Harness、OpenHands、SWE-agent 與 Aider 等開源專案，讓所有人都能使用生產等級的執行框架；Anthropic、OpenAI、Google、Microsoft 與 Moonshot AI 現在也都將執行框架工程視為一級工作。

但更深層的轉變在於概念。第一代執行框架解決的是 Agent × Computer：為模型提供可靠的手，操作終端機、瀏覽器與檔案系統。下一代則著手解決這些環境所產生的 context 問題——橫跨數天、利害關係人與程式碼儲存庫的工作，沒有任何摘要工具能無損壓縮。執行框架正從鷹架演變為操作環境，而執行框架必須管理的內容與模型可以直接容納的內容之間的界線持續移動。Kimi K3.1 Pro 的一百萬 token context window 是目前最清楚的例子：一次模型變更，省去了過去必須由執行框架完成的工作。

無論是自行建置、採用開源框架，或運行生產用執行框架，將執行框架視為經過工程化、版本管理且可量測軟體的團隊，才是能讓其 agent 真正完成工作的團隊。