OpenHands 與 All Hands AI：給 AI 一台電腦，讓它自己把程式寫完

大多數 AI Agent 框架問的是：「這個 AI 能呼叫哪些工具？」

OpenHands 問的是：「這個 AI 能不能直接坐在電腦前，像真正的工程師一樣把事情做完？」

這一個問題的差距，造就了完全不同的設計路線。OpenHands 不給 AI 一份工具清單，而是給它一台有終端機、有瀏覽器、有 Python 環境的完整開發工作站——然後說：「這個 GitHub Issue，你來解決。」

為什麼你需要認識 All Hands AI？
三位創辦人是誰？
OpenHands 的核心哲學：CodeAct
- 傳統工具呼叫 vs CodeAct
三層核心架構
執行流程架構圖
SWE-bench：它真的能解決真實的工程問題嗎？
OpenHands vs 其他 AI 程式助理
實用建議：三個起步行動
我的反思
參考資料 (References)

為什麼你需要認識 All Hands AI？

在這個系列裡，我們已經看過幾種不同的 Agent 設計哲學：

LangChain 解決「怎麼接 LLM 管道」
CrewAI 解決「怎麼讓多個 AI 分工合作」
OpenClaw 解決「AI 要住在哪裡」

All Hands AI 切入的是另一個維度：AI 能不能直接替工程師寫程式、解 Bug、跑測試、送 PR？

這不是一個新的 Agent 框架，而是一個直接瞄準軟體開發工作流的 AI 軟體工程師平台。

它在 SWE-bench（全球最嚴格的 AI 程式解題基準測試）名列前三，代表它不只是口號——它真的在解決真實的工程問題。

三位創辦人是誰？

All Hands AI 由三個背景截然不同的人共同創辦，而這種組合恰好是 OpenHands 成功的原因之一。

Graham Neubig — Chief Scientist，來自 CMU 的開源信仰者

Graham Neubig 是卡內基美隆大學（CMU）語言技術研究所（LTI）的副教授，長期研究 AI Agent 與大型語言模型在程式碼生成上的應用。

他在學術界有一個鮮明的立場：AI 的突破不應該被封閉在大公司裡，它必須是開放的、可驗證的、可被社群改進的。

這個信念直接決定了 OpenHands 從第一天就選擇完全開源——不只是開放模型，而是開放整個平台架構。

Robert Brennan — CEO，從 Google 到 AI Agent

Robert Brennan 的職涯軌跡是典型的工程師創業路線：Google 資深軟體工程師 → Fairwinds 產品開發副總裁 → All Hands AI 執行長。

他帶進來的不是學術視角，而是工程師真實的痛點：寫測試很煩、Debug 很耗時、Review PR 很機械。這些「低附加值但不得不做」的開發工作，正是 OpenHands 鎖定的目標。

Xingyao Wang — 研究核心，UIUC 博士生

Xingyao Wang 是伊利諾大學香檳分校（UIUC）的電腦科學博士候選人，研究重點是「能與人類互動、透過程式與世界溝通的 AI Agent」。他曾在 Google 研究多模態預訓練，也在 Microsoft 研究單元測試自動生成。

他是 OpenHands 核心架構設計的主要推手之一。

命名的由來：從 OpenDevin 到 OpenHands

OpenHands 最早叫做 OpenDevin，由 Qwen 團隊的 Binyuan Hui 和 Junyang Lin 啟動，最初是一個開源的 Devin（Cognition AI 的 AI 工程師）的替代方案。

Graham Neubig、Robert Brennan、Xingyao Wang 三人後來加入並成立 All Hands AI，專案同步改名為 OpenHands——「全員上手」，象徵 AI 與人類工程師共同協作的願景。

融資里程碑：

2024 年 9 月：500 萬美元種子輪（TechCrunch 報導）
2025 年 11 月：Series A 完成，累計融資達 2,380 萬美元

OpenHands 的核心哲學：CodeAct

OpenHands 最重要的設計決策，叫做 CodeAct。

傳統工具呼叫 vs CodeAct

傳統的 Agent 框架（包括 LangChain、CrewAI）讓 AI 透過呼叫預定義的工具來完成任務：

# 傳統工具呼叫模式
tools = [search_tool, calculator_tool, file_read_tool]
# AI 只能選：我要用哪個工具？參數是什麼？
agent.invoke("找出台積電今年的股價趨勢")
# → 呼叫 search_tool(query="台積電股價 2026")
# → 呼叫 file_read_tool(path="data.csv")

這個模式的天花板很明顯：工具定義了 AI 的能力邊界。工具沒有寫到的事，AI 就做不到。

CodeAct 的思路完全不同：讓 AI 直接寫程式碼來完成任務。

# CodeAct 模式——AI 自己寫程式
# 給定任務：「分析 repo 裡的測試覆蓋率並找出沒有測試的函數」

# AI 生成並執行以下程式碼：
import subprocess
result = subprocess.run(['python', '-m', 'pytest', '--cov=src', '--cov-report=json'], 
                       capture_output=True, text=True)

import json
with open('coverage.json') as f:
    coverage_data = json.load(f)

uncovered = [
    func for func, data in coverage_data['functions'].items()
    if data['covered_lines'] == 0
]
print(f"未覆蓋的函數：{uncovered}")

這段程式碼不是模擬，而是在 Docker 沙盒裡真實執行——輸出結果回傳給 AI，AI 繼續決定下一步。

CodeAct 的本質：用程式碼取代工具清單，讓 AI 的能力上限等於「程式碼能做到的一切」。

三層核心架構

1. Docker 沙盒：安全的執行環境

OpenHands 的所有程式碼執行，都發生在一個隔離的 Docker 容器裡。這個沙盒內建：

工具	用途
Bash Shell	執行系統指令、管理檔案、安裝套件
IPython	執行 Python 程式碼、互動式調試
Web Browser	瀏覽文件、查詢 Stack Overflow、讀取 GitHub
檔案系統	讀寫程式碼、測試結果、設定檔

沙盒確保 AI 的任何操作都不會影響主機環境，但對沙盒內部擁有完整的工程師權限。

2. Event Stream 架構：統一的事件語言

OpenHands 用 事件流（Event Stream） 串連所有組件——使用者介面、Agent 推理引擎、執行環境三者之間，所有通訊都透過事件進行：

用戶輸入 "Fix the failing test in auth.py"
    ↓ [UserMessageEvent]
Agent 推理 → 生成程式碼動作
    ↓ [CodeActEvent: python auth_fix.py]
沙盒執行 → 回傳結果
    ↓ [ObservationEvent: Test passed ✓]
Agent 繼續推理 → 決定提交 PR
    ↓ [BashEvent: git commit -m "Fix auth test"]

這個架構讓 OpenHands 可以支援不同的前端介面（Web UI、VS Code 插件、CLI）、不同的 LLM 後端（Claude、GPT、開源模型），而核心邏輯完全不變。

3. 多 Agent 並行：大型任務的解法

對於大型重構任務（例如把整個前端從 Angular 遷移到 React），OpenHands 支援多個 Agent 同時在獨立沙盒裡處理不同模組，最後合併結果——每個子 Agent 互不干擾，處理速度可以線性提升。

執行流程架構圖

Loading Diagram...

SWE-bench：它真的能解決真實的工程問題嗎？

SWE-bench 是目前最被業界認可的 AI 軟體工程能力評測標準：從真實的 GitHub 開源專案中取出已解決的 Issue，要求 AI 在不知道解法的情況下，獨立修好程式碼。

OpenHands + CodeAct v2.1 + Claude 3.7 Sonnet 在 SWE-bench 排行榜上名列前三，是目前開源框架中成績最好的之一。

在更貼近真實情境的 SWE-bench-Live（使用新發布、尚未被訓練資料污染的 Issue）中，OpenHands 的解題率約為 18-20%——這個數字遠低於封閉基準的 70%+，但它誠實地反映了 AI 解決全新工程問題的真實能力現況。

OpenHands vs 其他 AI 程式助理

面向	GitHub Copilot	Cursor	OpenHands
工作模式	補全建議	對話式編輯	自主執行任務
操作範圍	單檔補全	多檔修改	整個 Repo
執行程式碼	❌	有限	✅（Docker 沙盒）
跑測試	❌	❌	✅
送 PR	❌	❌	✅
開源	❌	❌	✅
適合場景	即時補全	快速修改	完整任務委派

簡單記：Copilot 是你的打字加速器，Cursor 是你的對話式編輯器，OpenHands 是你的自主執行的 AI 工程師。

實用建議：三個起步行動

步驟 1：從一個真實的 GitHub Issue 開始

不要用「寫一個計算機」這種玩具任務測試 OpenHands。找一個你真實 repo 裡的小 Bug 或簡單的功能請求，直接丟給它。真實任務才能讓你感受到 CodeAct 的威力。

步驟 2：善用 Docker 沙盒的完整性

OpenHands 的沙盒裡什麼都有。不要只讓它寫程式——讓它跑測試、查文件、安裝套件、驗證結果。完整的開發循環才是它設計用來支援的使用方式。

步驟 3：搭配 Claude 3.7 Sonnet（目前最佳組合）

OpenHands 支援多種 LLM，但根據 SWE-bench 測試結果，Claude 3.7 Sonnet 目前是推理能力與成本之間最佳的平衡點。如果你想要最好的任務完成率，從這個組合開始。

我的反思

看完 All Hands AI 的設計，重新思考了一個問題：「AI Agent」到底應該是工具，還是同事？

LangChain 把 AI 變成工程師的工具箱。CrewAI 把 AI 組成一個虛擬團隊。OpenClaw 讓 AI 住進你的手機。這些都是在輔助人類工作。

OpenHands 的定位不一樣——它不是輔助你寫程式，而是替你寫程式。你給它一個任務，它回來告訴你「做好了，PR 在這裡」。

這讓我想到 Robert Brennan 的一句話：

"The goal is for OpenHands to become a proactive pair programmer — one that can handle much of the toil of a developer's day-to-day work."

「Toil」這個詞選得很精準。不是所有的工程師工作都需要創意，很大一部分是重複的、機械的、必要但無聊的苦工——寫測試、修 linting 錯誤、更新文件、解簡單的 Bug。

如果 AI 能可靠地處理這些 toil，工程師就能把時間放在真正需要判斷力的地方。

回到這個系列的脈絡：Andrew Ng 定義了 Agent 的思維框架，Shunyu Yao 設計了推理引擎，Harrison Chase 把 LLM 工程化，João Moura 把 Agent 組織化，Peter Steinberger 把 AI 帶進日常通訊，而 Graham Neubig 與 All Hands AI 正在回答最後一個問題：

AI 能不能真正接手一部分工程師的工作？

答案還不是「完全可以」，但已經是「越來越可以」。

參考資料 (References)

官方資源

延伸閱讀

推薦影片

View on GitHub