Open SWE：把非同步編碼代理接進 GitHub、Slack 與 Linear 的軟體工廠

它要解決的不是補全，是交付

多數人講編碼代理，講的是游標旁邊那幾行建議。Open SWE 的 README 開頭寫的是另一件事：把工程工作變成可重複的系統。你從 dashboard、GitHub、Slack 或 Linear 丟一個 code-change task 進去，它在隔離環境裡理解 codebase、改動、驗證，最後交出一個 pull request。

差別在終點。補全工具的終點是編輯器緩衝區，Open SWE 的終點是 PR。這代表它必須處理 commit、push、branch 延續、CI 狀態，以及 PR 上的後續留言。README 把這條路徑畫成一個迴圈：issues、conversations、PRs、schedules 進來，規劃與調查，在沙箱裡實作，驗證並交付 PR，然後進入 review、CI 與 feedback，再回到規劃。

目標讀者因此不是個人開發者。README 反覆出現的字是 team、organization、repository instructions、organization-wide review guidelines。這是給有 repo 治理需求、想讓審查標準沉澱下來的團隊用的。

Deep Agents 當骨架，LangGraph 當執行時

Open SWE 自己沒有從零寫一套 agent harness。README 說明它用 Deep Agents 組裝 agent，由後者提供 planning、file operations、shell access、skills、state 與 subagent 這些原語；Open SWE 在上層加上軟體工程工具、prompts、middleware、integrations、authorization 與產品介面。

這個切法有好處也有代價。好處是底層 LangChain agent stack 的改進會往上繼承。代價是你的除錯路徑變長：一個 subagent 行為不如預期，問題可能落在 Open SWE 的 prompt 與 middleware，也可能落在 Deep Agents 的 primitive。

執行時是 LangGraph，負責 durable execution 與 thread state。README 列出目前出貨五個 graph entrypoint：Agent 負責規劃、實作、驗證與交付；Reviewer 做唯讀 PR 審查；Analyzer 學 repo 的審查風格；Chat 回答 PR 相關問題但不動程式碼；Scheduler 派送週期性任務與 CI 監控工作。用 graph entrypoint 而不是單一 agent 迴圈，意味著審查與學習被拆成獨立路徑，Reviewer 不會順手改到程式碼，Analyzer 的產出是規則而不是 patch。

沙箱綁執行緒，壞掉不偷偷換一個

雲端任務跑在隔離的 Linux 沙箱裡，開發工具由設定的 environment 或 snapshot 提供。這裡有個設計判斷值得單獨講：sandbox 跟著 thread 存活，但當一個 coding sandbox 變得不可達時，Open SWE 不會默默換一個新的，而是 fail safely。README 給的理由是避免丟棄未提交的工作。

對照組很容易想像：換一個乾淨沙箱重跑，使用者體驗比較順，但未 commit 的改動就沒了。Open SWE 選了反方向，代價是任務會停在那裡等人處理。這對長時間執行的重構任務是對的，對只想快速拿結果的輕量任務就顯得笨重。

沙箱供應商方面，LangSmith 是預設的 sandbox 與 tracing provider。README 另外點名 Modal、Daytona、Runloop、E2B 與本地執行，並說有可插拔介面可以再接其他供應商。本地執行對應的是 desktop 路徑，README 標為 experimental，打包版本目前只針對 macOS，原始碼建置也支援 Windows 與 Linux。

還有一個不對稱的細節：唯讀的 PR chat 不需要沙箱，desktop 任務則可以直接跑在 allowlist 過的本地專案上。

從 repo 到第一個 PR：安裝與設定面

README 沒有在提供的內容裡給出完整的安裝指令，只說 Open SWE 可部署在你自己的基礎設施上。實際要跑起來，你得自己去 repo 找安裝段落，這點先講清楚。

能從材料確認的設定面有幾類。模型與 reasoning effort 是可選的，README 說可以選擇 agents 與 reviewers 能用的模型與推理強度。整合與工具集是策展過的，觀測性與 MCP 整合只在設定且授權後才載入。授權層包含 GitHub App 安裝邊界與可選的 per-user OAuth，以及組織與 repo 的 allowlist。

可以自訂的插槽包括 sandbox provider、middleware、skills 與 triggers、delivery policies。個人與 repo 層級的 coding instructions、組織層級的 review guidelines 也各自有位置。

觸發面則是 dashboard、GitHub issue、Slack channel 或 thread 或 code channel、Linear issue，以及排程。CI 監控走的是 `/baby-sit` 這個指令，README 說它會監控 opted-in 的 PR、診斷 CI 失敗，並且只重跑有證據支持的 flaky job。

如果你的團隊已經在用 LangSmith，預設路徑最短；否則第一件要決定的事就是 sandbox provider 選哪個，因為它會牽動環境映像怎麼準備。

審查風格學習與 CI 重跑的分寸

Reviewer 與 Analyzer 這兩個 entrypoint 放在一起看才有意思。Reviewer 做唯讀審查，可以按需或自動執行；Analyzer 從歷史回饋裡學 repo 特定的審查偏好。README 說審查結果會 grounded in the diff，並發布回 GitHub。

把「學審查風格」獨立成一個 graph，等於承認審查偏好是組織資產，不是每次 prompt 臨時塞進去的東西。但這也帶出一個現實問題：學到的規則是什麼形式、放在哪裡、誰能改，README 沒有交代，提供的材料裡看不到。這是採用前該去 repo 確認的具體項目。

CI 那一側的分寸也值得注意。`/baby-sit` 只重跑有證據支持的 flaky job，這句話反過來讀就是：沒有證據的失敗不會被自動重試。這是刻意的保守，好處是不會用重跑掩蓋真實的測試失敗，壞處是遇到基礎設施層的偶發問題時，你還是得自己動手。

另外，PR chat 是唯讀的，這讓「先問清楚再改」有一條不需要沙箱的便宜路徑。

什麼時候它會是錯的工具

第一個限制寫在 README 的 NOTE 裡：Open SWE is under active development，APIs、setup 與產品介面都可能持續變動。release 清單也印證這點，最近幾筆都是 desktop-v0.2.7-nightly 系列，時間戳密集到同一天出現三次。nightly 命名代表這條線不是穩定版節奏。

第二個限制是維運成本。你要自己部署、自己接 GitHub App、自己維護 allowlist 與授權邊界、自己處理沙箱供應商的環境映像。README 把這一切寫成能力清單，但每一項在實際運作中都是要有人負責的東西。

第三是失敗模式的不對稱。沙箱不可達時系統選擇停下而不是換一個，這對長任務正確，對短任務就變成卡住。如果你的團隊期待的是一個隨手可丟、失敗就重來的工具，這個設計會讓你反覆處理中斷的 thread。

第四是範圍。它處理的是 repo 層級的變更交付，不是即時補全，也不是單檔小修。把 Open SWE 用在「幫我改這個函式的變數名」上，你付出的是沙箱啟動與 PR 流程的成本。

最後，desktop 路徑標為 experimental 且打包只針對 macOS，Windows 與 Linux 使用者得走原始碼建置。

對照 Claude Code 與同類代理：差在治理層

同類工具裡，Claude Code 是 README 的 topics 直接點名的對象之一，它的形態是終端機裡的互動式代理，你在本機 repo 裡跟它對話，它改檔、跑指令，工作留在你的機器上。Open SWE 走的是另一條路：工作在隔離沙箱裡跑，交付物是 PR，觸發點是 issue、Slack 訊息或排程。

差別不在模型能力，在治理層的位置。Claude Code 把授權邊界交給你的本機權限與你當下的判斷；Open SWE 把它做成 GitHub App 安裝邊界、per-user OAuth、組織與 repo allowlist，以及可替換的 delivery policies。前者適合個人或小團隊的即時協作，後者適合需要留下審計軌跡、需要多人共用同一套規則的組織。

代價也對應。Claude Code 幾乎沒有部署成本，Open SWE 要你先決定 sandbox provider 並準備環境。反過來說，Claude Code 不會幫你記住這個 repo 的審查風格，Open SWE 的 Analyzer 就是為了這件事存在的。

這不是誰取代誰的問題。如果你的工作大部分發生在單一開發者的機器上，多一層沙箱只是多一層延遲。

授權、升級節奏與採用前該確認的事

授權是 MIT，README 的 badge 指向 opensource.org/licenses/MIT。這對內部部署相對寬鬆，但要提醒的是，MIT 只涵蓋 Open SWE 本身的程式碼；它依賴的 Deep Agents 與 LangGraph 是另外的授權，沙箱供應商各有自己的條款與計費方式，LangSmith 作為預設 provider 也不例外。這些要各自確認，本文不構成法律意見。

升級成本主要來自兩處。一是 nightly 節奏，desktop-v0.2.7-nightly 系列在 2026 年 9 月 9 日當天就出現多筆，跟著 nightly 走意味著你要有能力快速驗證回歸。二是它繼承 Deep Agents 的改進，底層變動會往上傳，你的 middleware 與 prompts 可能需要跟著調整。

採用前具體該確認的：你的 sandbox provider 是否在 LangSmith、Modal、Daytona、Runloop、E2B 或本地執行這份清單內；GitHub App 的安裝邊界能不能對上你要的組織與 repo allowlist；Analyzer 學到的審查偏好以什麼形式存在、能不能人工檢視與修改；以及 `/baby-sit` 只重跑有證據支持的 flaky job 這個保守策略，跟你的 CI 現況合不合。這四項都能在 repo 裡查到答案，查不到就代表還不到採用的時候。

編輯結論

Open SWE 適合已經有 GitHub App 治理流程、願意自己維運沙箱與 LangGraph 執行環境的團隊，尤其是想把 code review 風格沉澱成可重複規則的那種組織。如果只是想在 IDE 裡補幾行函式，或不想承擔沙箱供應商費用與 nightly 版本變動，這個專案會是負擔。採用前先確認三件事：你的沙箱供應商是否在支援清單內、GitHub App 的安裝邊界能否對上組織與 repo 的 allowlist、以及你能否接受 APIs 與 setup 持續變動。最後一項最現實，release 頁面上掛的是 desktop-v0.2.7-nightly 系列，日期與 commit 同日推進。

官方來源

1. langchain-ai/open-swe on GitHub
2. License: MIT
3. Project website
4. README
5. Releases