Claude Code 讓代理設定變終端工作

我把 Claude Code 和 OpenHands 拆成團隊可直接套用的選型模板，重點放在安裝成本、沙箱、模型政策與採用門檻。

我用這類 agentic coding 工具一陣子了，越用越有一種很煩的感覺：demo 永遠很順，真的丟進日常開發就開始掉漆。不是模型不會寫，是它老是在一些很無聊的地方卡住，像 Docker、權限、環境變數、公司內網、還有那種「理論上能跑，實際上沒人想維護」的流程。你一開始以為自己在選 AI 工具，最後發現自己在選哪個坑比較淺。

這次我重新看 Claude Code 跟 OpenHands 的比較，是因為我想找的不是「誰比較強」這種空話，而是「哪個比較適合放進團隊工作流」。《Claude Code vs OpenHands》這篇原文在 lowcode.agency 把這個張力講得很直接，我覺得很值得拆開來看。官方文件也能對照：Claude Code、OpenHands。

我最後的結論很土：Claude Code 比較像「你真的會每天打開來用」的工具，OpenHands 比較像「你願意花更多工夫換控制權」的系統。這兩個都不是廢物，但如果你是替團隊選，不是替自己玩，差別就很現實了。

這題不是開源對商業，是維運成本對控制權

Claude Code is production-ready: Officially supported by Anthropic, it runs directly in your terminal with no Docker requirement. Docker is the central difference: OpenHands requires Docker; Claude Code does not.

翻譯一下就是：這場比較的核心根本不是「開源比較高尚」或「商業比較穩」，而是你願意吞多少操作成本，去換多少可控性。Claude Code 把東西塞回你熟悉的 terminal，少了一層容器和一堆包裝；OpenHands 則把 agent 包進 Docker sandbox，讓你比較好管，也比較好查。

我自己最有感的是，很多團隊一開始根本不是卡在模型不夠聰明，而是卡在部署太麻煩。工具如果要先拉 image、開 container、處理 volume、設定 port、再補一堆權限，最後大家就會默默回去手動改 code。不是不想用，是太煩。

這裡我會先問三個很土但很重要的問題：

• 它要跑在哪裡？本機 terminal、CI、還是共用 dev box？
• 誰要維護它？平台組、開發者自己，還是沒人想碰？
• 出事時誰要背鍋？能不能在 10 分鐘內看懂它在幹嘛？

實操上，我會先把 agent 的「落點」寫清楚。只要你是要放進日常開發，Claude Code 那種 terminal-native 的路線通常比較容易過關；如果你是要先過資安、先過平台審查、先過內部 fork 流程，那 OpenHands 的 sandbox 就更像正解。

OpenHands 的價值不是開源，是你可以把它抓在手上

OpenHands is fully open-source: It runs in Docker, supports 10+ model providers, and gives teams complete audit and fork rights. OpenHands delivers genuine open-source autonomy.

白話一點，OpenHands 的重點不是「它免費」，而是你真的能看、能改、能 fork、能自己決定下一步。這在很多公司不是小事，尤其是你在碰內部工具、受管制資料、或是任何一個 security review 會皺眉的專案時。你不想把整個 agent 堆疊交給單一供應商，這個想法很合理。

我之前看內部工具時，資安第一句不是問「它聰不聰明」，而是問「它能碰哪些東西」。這問題很煩，但也很實際。OpenHands 用 Docker 把 shell、檔案修改、瀏覽器操作包起來，至少 blast radius 比直接在本機上亂跑小。這種東西不性感，但它會決定你能不能真的上線。

不過我也不想替它洗白。控制權越多，通常代表你要自己扛更多維運。Docker 不是免費午餐，model provider 也不是隨便切切就沒事。你一旦把可觀測性、權限、網路存取、image 更新都算進去，OpenHands 就比較像一個平台專案，不像一個「裝完就能爽用」的工具。

• 適合需要審計、fork、內部改造的團隊。
• 適合想保留模型選擇權的團隊。
• 適合需要 sandbox 隔離、降低失誤外溢的場景。

實操寫法很簡單：如果你是平台組或安全導向團隊，先把「誰能改 agent」「誰能看 log」「誰能接外部模型」列成政策，再決定要不要上 OpenHands。不要先裝，裝了才補規則，通常會很痛。

Claude Code 的優勢很無聊，但很有效：少一層就少一堆事

Claude Code is production-ready... it runs directly in your terminal with no Docker requirement. Zero-setup deployment: Claude Code installs in under two minutes with no Docker requirement.

這段我很認同，因為我真的看過太多工具死在「安裝流程太像在修車」。Claude Code 的好處就是它把很多惱人的東西拿掉了：不用先想 container，不用先處理 image，不用先跟本機環境打架。你打開 terminal、認證、開始做事，這種體驗很無聊，但無聊代表它比較可能被用下去。

原文也提到它的 native MCP support、subagent orchestration，還有跟 Claude Sonnet 4、Opus 4 的整合。這些不是拿來寫簡報好看的字而已，因為 agent 真正有沒有用，常常取決於它能不能順手接到你現有的工具鏈。你要它查文件、跑測試、碰內部服務，如果每一步都要自己縫，最後你不是在用 agent，你是在做整合專案。

我對「模型綁定」這件事其實沒那麼反感。很多人一聽到 vendor lock-in 就先翻白眼，但在 agent 這種場景，太多可變因反而會讓行為飄掉。Claude Code 固定在 Anthropic 生態裡，至少你比較知道它的語氣、推理、工具調用會長什麼樣子。這對要處理多檔案重構的人來說，差很多。

• 適合想快速導入、快速讓工程師真的開始用的團隊。
• 適合不想把維運複雜度再往上疊的環境。
• 適合已經偏向 Claude 模型生態的組織。

實操上，我會把 Claude Code 當成「先讓採用率上來」的選項。你如果連新人在 5 分鐘內跑起來都做不到，後面再多功能也沒用。工具先能用，再談優雅。

模型彈性很好，但也最容易把你搞成治理地獄

OpenHands is model-agnostic and supports Claude, GPT-4o, Gemini, Mistral, and local models via Ollama. Claude Code model support: Anthropic-native only.

這句話表面上看起來像 OpenHands 贏很大，因為它支援很多模型，但我會把它翻成另一種語言：你得到的是選擇權，也拿到更多管理責任。能切 provider 很爽，尤其是你要比成本、比速度、比政策相容性時；但每多一條路，品質漂移、行為不一致、排查困難的機率也會上升。

我看 agent 工具最怕的就是「同一個模型，不同 client，表現差很多」。這種事很多團隊都吃過虧。你以為自己在比較 Claude 跟 GPT，結果其實是在比較不同的 wrapper、不同的上下文處理、不同的工具調用路徑。最後出問題，大家會說是模型不穩，實際上常常是整層系統在搞你。

所以我不會把 model-agnostic 當成絕對優勢。我會把它當成一個需要被證明的能力。你如果真的有政策需求、成本需求、或是本地模型需求，OpenHands 很合理；但如果你只是覺得「可切模型聽起來比較厲害」，那大多數情況只是把決策複雜度往上加。

實操寫法：先定義你的模型政策，再選工具。不要反過來。像這樣列：

• 預設模型是什麼？
• 備援模型是什麼？
• 哪些任務可以用便宜模型，哪些不行？
• 誰有權改 provider 設定？

如果這些答案你現在答不出來，那你其實還沒準備好談「模型彈性」。

browser 能力不是加分題，是工作範圍差很多

Browser interaction: OpenHands can navigate websites, fill forms, read documentation, and interact with web-based tools: Claude Code cannot do this by default.

這裡就很現實了。很多工作不是只有改 repo。你可能要登入後台、看文件、查 dashboard、填表單、讀內部 wiki，甚至在一堆 web-based 工具之間來回切。OpenHands 可以把這些都包在同一個 agent 流程裡，這就讓它的任務範圍比純 terminal 工具大很多。

我之前就碰過這種情境：需求不在 code 裡，需求散在 Jira、文件站、管理介面、和幾個內部網頁工具裡。這種時候，只有 terminal 的 agent 不是不能做，而是它會需要更多人手補洞。你最後會發現自己在幫 agent 搭橋，而不是讓它幫你省事。

但 browser 能力也不是白送的。它會拉高失誤面，因為 agent 多了一個互動層，就多一個地方可能點錯、讀錯、卡錯。我的態度是：如果要開 browser，最好在 sandbox 裡開，不要直接把它丟到真實環境亂跑。這一點上，OpenHands 的設計比較順。

實操寫法很直接：如果你的日常任務包含網頁操作、文件查找、內部系統點選，OpenHands 比較合理；如果你的工作幾乎都在 repo 和 shell 裡，Claude Code 的窄範圍反而比較乾淨。

真正的選型不是看理念，是看你比較怕哪種失敗

The decision maps to priorities: open-source philosophy and sandbox safety point to OpenHands; operational simplicity and reliability point to Claude Code.

這句我覺得可以直接拿來當內部討論的起點。翻譯一下就是：你不是在選一個「最強」工具，你是在選哪種失敗模式你比較能接受。你比較怕被 vendor 綁住、怕審計不清、怕 agent 太自由，那 OpenHands 比較對味。你比較怕團隊根本不想用、怕 setup 太重、怕大家最後又回到手工流程，那 Claude Code 比較省事。

我很常看到團隊先談理念，最後被摩擦打臉。真正會把工具搞死的，通常不是功能少一點，而是每次要用都太麻煩。開發者很現實，工具如果讓人覺得「我還不如自己做」，那它就快沒戲了。

所以我會建議你們先做一頁紙決策，而不是直接開戰。先把 setup、權限、模型政策、browser 需求、CI 整合、審計要求列出來。這些東西寫不出來，代表你現在不是在選工具，你是在選想像。

• OpenHands 偏向控制、沙箱、可 fork。
• Claude Code 偏向速度、採用率、少維運。
• 你要先知道團隊最怕哪一種痛。

實操上，我會要求團隊先跑一個真實任務，不要跑 demo。像是「改三個檔案、跑測試、生成 PR 說明」這種。只要真實任務一上來，誰比較省事、誰比較難維護，會立刻現形。

可抄的模板

# Claude Code vs OpenHands 團隊選型模板

## 1) 我們先選哪個
我們預設選： [Claude Code / OpenHands]

## 2) 我們為什麼選它
- 第一個原因：
- 第二個原因：
- 我們最在意的是：

## 3) 實際運行環境
- 跑在哪裡： [terminal / Docker / CI / 本機開發機]
- 需不需要 browser： [yes / no]
- 需不需要外部工具整合（MCP 或類似機制）： [yes / no]
- 需不需要 sandbox 隔離： [yes / no]

## 4) 模型政策
- 允許的 model provider：
- 預設模型：
- 備援模型：
- 成本上限：

## 5) 資安與治理
- agent 能不能碰 production： [yes / no]
- agent 能不能跑 shell command： [yes / no]
- agent 能不能連外網： [yes / no]
- 稽核要求：

## 6) 團隊採用成本
- 新人第一次成功跑起來要多久：
- 新人要做哪些設定：
- 最可能讓團隊不爽的是什麼：
- 出問題時誰支援：

## 7) Pilot 成功標準
我們會把 pilot 視為成功，如果：
- 它能完成 [任務類型]，而且不需要人工大修
- 安裝與設定時間少於 [時間]
- 團隊真的拿它做了 [數量] 個真實任務
- 資安或平台審查通過

## 8) 最終決策備註
我們選擇 [工具]，因為它最符合我們對 [速度 / 控制權 / 沙箱 / 模型彈性 / 採用率] 的優先順序。

## 9) 會議用一句話
「我們在比較 Claude Code 與 OpenHands，重點是 [優先順序 1]、[優先順序 2]、[優先順序 3]。以我們現在的環境來看，比較適合的預設是 [工具]，我們接受的主要代價是 [tradeoff]。」

這段你可以直接拿去開 team review。我的建議是先填完再開會，不要邊聊邊想，因為那樣最後一定會變成誰聲音大誰贏。你要是最後選 Claude Code，這模板通常會把「少維運、好導入」的理由講清楚；你要是選 OpenHands，它也會逼你把「為什麼值得多這些 plumbing」講明白。

我自己的結論很簡單：agent 工具不是越強越好，是越不煩越會被用。這種東西最後拼的不是口號，是團隊每天願不願意打開它。

原始來源：https://www.lowcode.agency/blog/claude-code-vs-openhands。我這篇是把原文的比較框架拆成團隊決策模板，模板與判斷方式有我的編輯整理與延伸。