OpenHands Software Agent SDK：OpenHands V1 底層那套事件溯源、從本機到遠端的基礎架構
— 次瀏覽
一套乾淨、模組化的 Python/REST SDK，用來打造程式碼 agent — 它是 OpenHands V1、CLI 與 OpenHands Cloud 背後的引擎。事件溯源狀態、本機優先並可按需開沙箱、MCP 工具。v1.26.0 於 2026 年 6 月 5 日推出。
pip install -U openhands-sdk openhands-tools它是什麼
OpenHands Software Agent SDK 是一組 Python 與 REST API，用來打造處理程式碼的 agent。它是 OpenHands V1 的核心 — 一次徹底的重新設計，把 agent 核心與建構在其上的應用程式拆開（OpenHands CLI 與 OpenHands Cloud 都跑在這套 SDK 上）。此 repo 採 MIT 授權，迭代很快：最新的 tag v1.26.0 在 2026 年 6 月 5 日落地，緊接在 v1.25.0（6 月 4 日）與 v1.24.0（5 月 27 日）之後。
它的賣點是：同一份 agent 定義應該能在你的筆電上做原型開發，也能在正式環境的容器化沙箱裡執行，幾乎不需要改動程式碼。你組合一個 LLM、一份具型別的 Tool 清單，以及一個綁定到工作區的 Conversation，然後用訊息來驅動它。
為什麼這套架構值得關注
隨附的論文（arXiv 2511.03690，同時是 MLSys 2026 口頭報告）提出四項設計原則，就算你永遠不採用這套 SDK，也值得借鏡：
- 可選的隔離 — 本機優先、按需開沙箱。只有在你真的需要隔離時，才付出 Docker/Kubernetes 的代價。
- 無狀態元件，搭配不可變設定與事件溯源狀態，讓你能對一次執行做確定性重播。
- agent 核心與消費它的應用程式之間嚴格分離。
- 跨四個套件 — SDK、Tools、Workspace、Server — 的雙層可組合性，元件具型別、可替換，並整合 MCP。
事件溯源加上不可變設定，是低調的重點。如果每一次狀態轉換都是一筆附加的事件，你就能確定性地重播一次失敗的 agent 執行，而不必試著從日誌重現一個非確定性的迴圈。
安裝與執行
pip install -U openhands-sdk openhands-tools文件明確指出 openhands-sdk 與 openhands-tools 是一組搭配套件 — 用一道指令一起安裝並升級，讓版本保持對齊。若要使用沙箱化的工作區與隨附的伺服器，再加上 openhands-workspace openhands-agent-server。
| 套件 | 角色 |
|---|---|
| openhands-sdk | 核心 agent/conversation/LLM API |
| openhands-tools | 內建的終端機、檔案編輯器、任務追蹤工具 |
| openhands-workspace | Docker / 遠端沙箱化工作區 |
| openhands-agent-server | REST/WebSocket agent 伺服器 |
一次極簡的執行會把終端機、檔案編輯器與任務追蹤器接進同一個 agent，把它指向當前目錄，然後送出一道指令 — agent 自行規劃、呼叫工具，並自己停下來。
實務者筆記
把這四個套件的拆分當成真正的產品，而不是樣板。先只用 openhands-sdk + openhands-tools 對著本機工作區去感受那個迴圈，等到你需要在隔離環境裡執行不受信任的編輯時，再去動用 openhands-workspace。因為工具具型別、可替換並支援 MCP，你可以塞進自己的工具而不必 fork 核心 — 這正是「一個你拿來擴充的函式庫」與「一個你拿來對抗的框架」之間的差別。
被低估的角度
大多數「agent SDK」的報導都緊盯它呼叫哪個模型。這裡更耐久的賭注是事件溯源的狀態模型：確定性重播把不穩定的 agent 執行，變成可以 diff、稽核並做回歸測試的可重現產物。這把 agent 從一段聊天工作階段，重新框定成更接近一條建構管線的東西 — 而這正是團隊在敢於信任它去重構真正的程式碼之前所需要的。