OpenHands 怎麼接自己的 repo？在 issue 上掛個標籤，它就去改到開 PR
編輯：BJ最後檢查：2026-10-06主要來源：官方文件
OpenHands 最有記憶點的功能是 Resolver，你在 GitHub issue 上掛一個標籤或留言 @openhands，它會開沙箱讀專案、改程式、跑測試，做完直接開一個 PR 給你看，這篇說明怎麼接、自架跟雲端怎麼選、以及哪種 issue 適合丟給它
它到底在做什麼
OpenHands 最容易講清楚的功能叫 Resolver，用一句話說就是：你在 GitHub 的 issue 上掛一個標籤，它就去把那個 issue 處理掉，處理完開一個 PR。
中間發生的事大概是這樣。它收到觸發之後會在 issue 底下留言說我接手了，接著開一個隔離的執行環境，把你的 repo 拉進去讀，理解那個 issue 在講什麼問題，動手改程式，跑測試看有沒有過，然後把改動整理成一個 pull request，附上一段說明它做了什麼。
整條線最重要的是最後一格。它交出來的是 PR，不是直接推到主分支的改動。 這代表你永遠有一關可以攔，這也是為什麼這個流程比「讓 agent 直接在你電腦上跑」安全一個層級。
除了 GitHub，同一套 Resolver 的模式也支援 GitLab，另外還有針對 Jira 和 Azure DevOps 的版本。這篇以 GitHub 為主。
兩條路：雲端跟自架
雲端比較快
到 OpenHands Cloud 用 GitHub 帳號登入，然後在 repo 選單裡點「Add GitHub Repos」，選你要開放的 repo，授權。
授權之後它拿到的是八小時就過期的短效 token，權限範圍包含 actions、commits、pull requests、issues 和 workflows。短效 token 這個設計滿重要的，代表就算哪裡出問題，那個授權也不會永久掛在你帳號上。
接著就可以用了。兩種觸發方式：
在 issue 上掛一個 openhands 標籤，或者在 issue 留言裡提到 @openhands。
PR 裡也可以提到 @openhands，用來問問題、要它補改、或請它解釋某段改動。
這裡有一個限制要先知道：PR 裡的 `@openhands` 只有在這個 PR 的來源和目標都是你已經加進去的 repo 時才會動。 外部貢獻者從他們自己的 fork 發過來的 PR，它碰不到，因為它沒有那邊的權限。
自架比較麻煩，但東西都在你這邊
如果你的程式碼不能出去、或是你想接自己的模型，就走自架。
自架現在要用 OpenHands 的新介面 Agent Canvas。以前教學常見的 uv tool install openhands 加 openhands serve，是舊版本機介面的裝法，已經進入維護模式，只修重大問題、不會再加新功能。Agent Canvas 怎麼裝，見 OpenHands Agent Canvas 安裝教學，Windows 用 PowerShell 就能裝，不用另外開 WSL。
要先知道的是，自架版沒有雲端那種「一掛標籤馬上動」的反應。GitHub 發出的通知要有一個收得到的地方，那是雲端版才有的功能。
自架版改用 Agent Canvas 內建的「Issue to PR」自動化範本。它預設每 15 分鐘去 repo 看一次有沒有符合條件的新 issue，有就自己開工，做完一樣開一個 PR 給你審。分支名稱前綴可以自訂，也可以設成一律開草稿 PR。除了 GitHub，也支援 GitLab，以及把 Jira、Linear 上的 issue 做成 GitHub、GitLab 或 Bitbucket 的 PR。
設定時要給它一組 GitHub 的 fine-grained personal access token，只勾你要開放的那幾個 repo。範本怎麼開、費用怎麼控，見 OpenHands 自動化教學。
還有一點容易被忽略：用 npm 或 npx 跑的話，關掉終端機它就停了，不會再去檢查新 issue。想讓它一直輪詢，要放在一台一直開著的電腦或伺服器上。另外 npm 版預設沒有沙箱，agent 能碰到整台電腦的檔案，自架接 repo 我會建議走 Docker 版。如果你還不熟 Docker，可以先補 Docker 是什麼。
模型在 Settings > LLM 裡選，填 API key。可以接 Anthropic、OpenAI、Google 這些雲端模型，也可以接本機的 Ollama、LM Studio。不過官方自己也提醒，本機模型常常不會正確使用工具，用起來會像普通聊天機器人。要它真的改程式、開 PR，雲端的大模型穩很多。
怎麼選
雲端適合你只是想先看看這東西到底行不行、或是你的 repo 本來就是公開的。省掉所有環境問題，五分鐘就能試第一個 issue。
自架適合程式碼不能外流、或你想用本機模型控制成本、或你想調沙箱的細節。代價是你要自己顧環境、顧更新、顧出事的時候怎麼查，而且它是定時去看，不是你一掛標籤就動，反應會慢一些。
網路上那種 fix-me 標籤的教學，已經不能用了
如果你搜到的教學是叫你在 repo 裡加一個 GitHub Action，再掛 fix-me 標籤或留言 @openhands-agent 觸發，那是另一條舊路線。官方在 2026 年 4 月已經把它移除，現在照做會直接失敗。這篇講的 openhands 標籤和 @openhands 留言是雲端版的功能，兩者名字很像，不要混在一起。
一個實際的建議是：先用雲端在一個測試 repo 上跑幾次，確認這個流程對你有價值，再決定要不要花時間自架。 很多人卡在自架環境卡了一個下午，結果跑完第一個任務發現這不是自己要的東西。
接進正式 repo 前，四件事要先做
這一段是整篇最重要的部分。
第一，先用測試 repo。 開一個新的、或是拿一個你不心疼的練習專案。第一次就接公司主要的 repo，等於拿正式環境當實驗場。
第二，把測試顧好。 Resolver 的品質很大一部分靠測試撐著。它改完會跑測試，測試如果會抓到問題，它就有機會自己修正；測試如果形同虛設，它交出來的 PR 你也很難判斷對不對。沒有測試的專案接這個，收益會大打折扣。
第三，分支保護要開。 主分支設成不能直接 push、PR 至少要一個人核准。這件事本來就該做，接了 agent 之後更該做。
第四，權限給到剛好就好。 只把你真的要它處理的 repo 加進去，不要整個 organization 一次授權。secrets 和環境變數要檢查一下，那個沙箱在跑的時候可能會碰到。
哪種 issue 適合丟給它
這個問題比「它強不強」實際得多。
適合的 issue 通常長這樣：
問題描述具體，看得出來要改哪裡或至少改哪個範圍。像是「這個函式在輸入空字串的時候會噴錯」比「登入流程怪怪的」好太多。
有明確的成功條件，最好是「測試要過」這種能自動驗證的。
改動範圍相對集中，一兩個檔案，不是牽動整個架構。
那種很煩但不難的雜事，補測試、補型別、統一命名、更新過時的 API 呼叫。
不適合的 issue 是這幾種：
需求本身還沒想清楚的。它不會幫你想清楚，它只會照著它猜的方向做出一個你不要的東西。
牽涉產品決策或使用者體驗判斷的。「這個按鈕放哪裡比較好」不是它能決定的事。
要改動核心架構、或是會影響很多地方的。爆炸半徑太大，審查成本會超過它省下的時間。
跟外部服務有實際後果的，像是會發信、會扣款、會動到正式資料庫的。
它會怎麼出錯
講完能做什麼，也要講清楚它出錯的時候長什麼樣。
最常見的是「做完了，但做的是另一件事」。 它誤解了 issue 的意思，寫出一段邏輯上沒問題、測試也過了、但根本不是你要的東西。這種錯最花時間，因為 PR 看起來很正常，你要讀完才發現方向不對。
第二種是「為了讓測試過，把測試改了」。 這個要特別留意，審 PR 的時候一定要看它有沒有動到測試檔案。
第三種是它在沙箱裡裝了一堆東西、改了一堆設定檔，把環境搞得跟原本不一樣。因為在沙箱裡，影響有限，但 PR 裡會多出一堆你沒預期的變更。
第四種是跑很久、燒很多。 它卡在一個解不掉的問題上，來回試了幾十輪。這就是為什麼一定要設用量上限，agent 的 token 消耗跟聊天完全不是同一個量級。
這幾種錯都不是災難，因為結果是一個 PR，你關掉就好。真正的風險是你養成不看就 merge 的習慣。
跟直接用 MCP 接 GitHub 有什麼不一樣
站內寫過 GitHub MCP Server，那個是讓你手邊的 AI 工具能直接操作 GitHub，你在對話裡說「幫我看一下那個 issue」，它就去看。
差別在觸發點和誰在等。
MCP 那條路是你在電腦前面，它是你的手的延伸。你問、它做、你看結果，是同步的。
Resolver 這條路是你掛完標籤就可以去做別的事。它在別的地方跑，跑完通知你。是非同步的。
所以用途不一樣。臨時要查東西、要改一個小地方，MCP 比較順。累積了一串「有空再處理」的雜事 issue，Resolver 比較對。
我會這樣建議
第一次不要從「讓它幫我解決一個真的問題」開始，從「看它怎麼做事」開始。
開一個測試 repo，自己寫一個明顯的 bug，開一個 issue 把問題描述清楚，掛標籤，然後看它交出什麼。重點不是它有沒有修對，是你要看懂它的做事方式、它讀了什麼、它的 PR 長什麼樣。
跑個三五次之後，你會對「什麼 issue 丟給它會成功」有感覺。那個感覺比任何教學都有用。
接到正式 repo 的時候，一開始只丟那種你原本就打算放著不管的小事。它做成了是賺到，做壞了你關掉 PR 也沒有損失。等你連續看到幾個品質不錯的 PR，再考慮丟重要一點的東西。
一句話：把它當成一個會自己動手的實習生，而不是一個自動修 bug 的機器。 實習生交出來的東西你會看，這個也一樣。
資料來源
本文依 OpenHands 官方文件整理。OpenHands 更新頻率高，安裝方式、觸發機制、權限範圍與雲端方案都可能變動，實際接入前請再確認官方文件，並務必先在測試 repo 上驗證。權限、分支保護與審查習慣的建議屬於一般實務，不是官方保證。
- https://docs.openhands.dev/
- https://docs.openhands.dev/openhands/usage/cloud/github-installation
- https://docs.openhands.dev/openhands/usage/agent-canvas/prebuilt/issue-to-pr
- https://docs.openhands.dev/openhands/usage/agent-canvas/setup
- https://github.com/OpenHands/OpenHands
延伸閱讀
OpenHands（前身 OpenDevin）是一個開源的 AI 軟體工程 agent，2026 年 6 月起主介面換成 Agent Canvas，能自己讀專案、寫程式、跑終端機指令、定時做事，還能接 Claude Code 和 Codex 一起用，本篇用新手角度講清楚它能幹嘛、跟 Cursor 和 Cline 差在哪、三種方案要不要錢、怎麼低風險裝起來試，以及最該注意的安全問題。
GitHub MCP Server 是什麼？讓 AI 讀 repo、issue、PR 的官方工具GitHub MCP Server 是 GitHub 官方推出的 MCP server，讓 Claude Code、Cursor、Codex 等 AI 工具可以透過授權安全讀取 GitHub repo、issue、pull request。這篇說明它好不好上手、適合哪些 AI coding 工作流，以及 token 權限要怎麼開。
Docker 是什麼？AI 工具自架前一定要懂的容器基礎用中文白話解釋 Docker 的 image、container、volume、Docker Compose、下載與價格、安全風險，以及非工程師使用 AI 自架工具前該怎麼判斷要不要學。
OpenHands 自動化教學：讓 AI agent 定時看 PR、處理 issue，本機版免費就能跑OpenHands Agent Canvas 的自動化可以讓 agent 照排程或在某件事發生時自己起來做事，像是定時審 PR、把新 issue 做成 PR、整理 Slack 頻道，本機免費版就能跑，本篇從官方範本開始，帶你看觸發方式怎麼設、GitHub 和 Slack 怎麼接、每次執行花多少錢怎麼看，以及匯入別人的自動化之前要檢查什麼。
OpenHands Agent Canvas 安裝教學：四種裝法怎麼選、Windows 怎麼裝、哪些設定要先開Agent Canvas 是 OpenHands 從 2026 年 6 月起的新主介面，舊的 openhands serve 已經進入維護模式，本篇帶你看桌面版、npm、npx、Docker 四種裝法怎麼選、Windows 用 PowerShell 怎麼裝、第一次打開的設定精靈怎麼走，以及裝完一定要先處理的沙箱與確認模式。
Cline CLI 是什麼？把 coding agent 搬到終端機，還能同時跑好幾個Cline 不只有 VS Code 外掛，還有一個從頭重寫的終端機版本，可以在 CLI 裡跑 agent、丟進 CI、甚至開一個看板同時派好幾個 agent 各做各的，這篇說明它跟外掛版差在哪、怎麼裝、以及什麼時候該用哪個