發生了什麼：v0.2.0 與 v0.2.1 在 8 月 25 日接連落地
打開 OpenWorker 的 GitHub releases 頁面，版本序列一目了然：v0.1.4、v0.1.5、v0.1.6、v0.1.7，一路到 v0.2.0 與最新的 v0.2.1。v0.2.1 於 8 月 25 日由 github-actions 發布，對應的提交標注為由 GitHub 驗證金鑰簽署——對一個會自動更新、跑在使用者桌面上的智能體來說，發布鏈本身可驗證，就是安全屬性的一部分。
儲存庫的現況也說明了這個專案的熱度：約 15,700 個 stars、2,200 次 forks、347 次提交，README 標明 MIT 授權，並以顯著篇幅聲明專案仍在 open beta——「fully usable, updates itself, and we’re actively polishing rough edges」。版本落地的同一天晚間，中國科技媒體 OmniTools 刊出報導，隔日 AI HOT 等聚合平台跟進轉傳，這也是這次更新進入華文圈視野的主要管道。
版本報導的重點：三類內建資安智能體
根據 OmniTools 的版本報導，這波 v0.2 更新的重心是安全工作流：新版整合了程式碼漏洞掃描、依賴供應鏈注入檢測、雲端安全設定檢查三類網路安全智能體，且「所有功能支援本地運行開源權重模型，便於在隔離環境中處理敏感程式碼」。報導同時強調，其核心 harness 元件完全開源，安全團隊可以審計、確認沒有後門。
這三個工作流對應的正是當代軟體供應鏈最常見的三種破口：自己寫的程式碼裡的漏洞、第三方依賴被植入的惡意套件，以及雲端服務設定錯誤造成的暴露。把三者包裝成智能體而非單次掃描工具，使用方式也因此是持續性的——讓智能體在開發流程中代為檢查，而不是等出事再手動跑一次掃描。
把資安檢查做成智能體而非一次性掃描器，改變的是檢查的位置與節奏。傳統靜態分析工具交出一份報告，判讀與修復仍靠開發者自己；智能體式的工作流則把掃描、判讀、回報與修法建議串進同一個循環，隨著程式碼推進而持續運行。這種形態成立的前提，恰恰是接下來要談的可審計性——讓一個會主動讀寫程式碼的自動化程序常駐在開發環境裡，它本身的行為邊界必須先被看清楚。
需要畫清楚的一條線是：版本與時點可由 GitHub releases 頁面直接核實，但三類資安智能體的具體內容，目前主要依據媒體對新版的報導；releases 頁面本身只列出版本清單與簽署資訊。
機制：可審計的 harness 才是安全主張的基礎
要理解「harness 完全開源」為什麼被放在這次報導的第一句，得先看 harness 在智能體堆疊裡的位置。模型負責推理，harness 則是包在外面的執行框架：工具呼叫、任務循環、權限控管、檔案存取，全都在這一層。智能體能讀你的程式碼、改你的檔案、代你送出訊息，靠的都是 harness——這也是為什麼 DeepSeek 把自家框架以 MIT 開源時，「一切皆插件」的架構會被視為把這一層變成公共財，見〈DeepSeek 開源 Harness v0.1〉；而北京的智能體新政甚至把 Harness Engineering 直接寫進政策文件，見〈北京智能體新政〉。
OpenWorker 的差異在於它不是框架，而是完整的桌面產品：README 自述為「an open-source AI coworker that lives on your desktop and delivers finished work, not just chat」——住在桌面上、交付成品的開源 AI 同事。整個儲存庫從 coworker 主程式、scripts、packaging 到 reports 全部攤在陽光下，MIT 授權允許任何人審計、修改、自行建置。對資安團隊而言，「可審計、無後門」從此不是對廠商的信任聲明，而是可驗證的主張：原始碼就在那裡，可以自己查。
這在 agent 安全的版圖裡補上一塊常被忽略的拼圖。多數討論聚焦提示注入與權限邊界——Google 開源零信任客服代理時，主張的正是系統提示詞不該被當成資安邊界，見〈Google 開源零信任客服代理〉——但另一個同樣現實的問題是：你裝進公司的那個 agent 本身，是不是乾淨的。
本地跑開源權重模型：敏感程式碼不出門
版本報導的另一個關鍵字是「本地運行開源權重模型」。掃描程式碼漏洞、檢查依賴套件，本質上是把公司最敏感的資產——原始碼、依賴清單、雲端架構設定——完整交給分析工具；若分析發生在雲端 API，等於把大門鑰匙寄給第三方。支援本地開源權重模型，讓整個檢查流程可以在隔離環境內完成，程式碼不必離開自己的機器。
這個設計搭上了本機模型逐漸成熟的一波。Meta 開源的 Muse Glimmer 30B 已示範同尺寸本機代理模型的可行性，見〈Meta 開源 Muse Glimmer 30B〉；macOS 上 llama.cpp 的推理加速也持續提高本機跑模型的實用性，見〈Cua 開源 Metal 能力墊片〉。而 README 對 OpenWorker 的定位本來就是「lives on your desktop」——住在使用者的桌面上；資安工作流支援本地開源權重模型，等於把這個本機定位推進到敏感場景：連分析用的模型都不必外求。
脈絡：從 v0.1.x 修補到 v0.2 功能躍進
把版本序列攤開，這次更新的分量更清楚。releases 頁面上，v0.1.4、v0.1.5、v0.1.6、v0.1.7 之後直接接上 v0.2.0 與 v0.2.1——從修補取向的 v0.1.x 序列，一次跳到功能層級的 v0.2，而且一跳就是連續兩個版本。對照媒體對更新內容的描述，這個編號變化傳達的訊息很明確：開發團隊把資安工作流當成 v0.2 的主題，而不是又一輪錯誤修正；儲存庫目前約 15,700 個 stars 的關注度，也顯示這個仍在 open beta 的專案，已經在開源社群站穩了能見度。
在開源桌面智能體這條賽道上，OpenWorker 並非獨跑。OpenChamber 等專案同樣把智能體環境往桌面與跨裝置推，見〈OpenChamber 開源代理式開發環境〉；差異在於吳恩達團隊把訴求壓在「交付成品而非對話」與「本機優先」這兩件事上。v0.2 選擇強化資安工作流，等於是在本機優先的基礎上，往企業與資安團隊的場景再推一步。
影響：誰該現在關注，誰該再等等
對資安與平台團隊，這次更新值得關注的理由不是「多了三個掃描器」，而是出現了一條可審計的路徑：agent 的原始碼可查、發布鏈有簽署可驗、模型可以在本地跑——三個條件湊齊，敏感程式碼的自動化檢查才有放進公司的可能。實際的下一步很具體：先把儲存庫 clone 下來審計程式碼，在隔離環境以本地模型試跑資安工作流，再觀察 v0.2.x 的迭代節奏，決定是否納入既有流程。
審計一個會自動更新的 agent，重點通常放在三處：它對檔案系統與網路的存取範圍、模型與工具的權限邊界，以及更新機制由誰簽署、能否被驗證。OpenWorker 在這三處目前都有可檢查的線索——原始碼完整公開、發布鏈經 GitHub 簽署、README 對 open beta 與自我更新的行為有明確說明——這也是它與閉源桌面智能體最實質的差距。
對一般開發者，OpenWorker 目前更適合當觀察對象而非日常依賴。README 明言專案仍在 open beta、會自我更新並持續修補粗糙的邊角；各平台安裝檔的提供與簽署狀態，安裝前可先以官方釋出資訊確認。
限制：還未被證實的部分
盤點這次更新，有幾件事已被第一手核實，也有幾件還沒有。已被核實的：v0.2.0 與 v0.2.1 於 8 月 25 日發布、發布鏈經 GitHub 簽署、儲存庫以 MIT 授權完整公開、專案處於 open beta，以及儲存庫目前的 stars 與 forks 數據。未被核實的：三類資安智能體的具體能力——掃描深度、誤報率、底層採用哪些檢測引擎——目前僅見於媒體版本報導，也尚無獨立實測結果。
值得追蹤的後續指標有三：儲存庫內對應資安工作流的程式碼與文件何時出現、v0.2.x 的修補節奏，以及 issue 追蹤器裡資安相關的回報量。若三類資安智能體屬實，這會是開源桌面智能體第一次把資安工作流放進第一方功能列表；在那之前，把它當成「方向已定、細節待驗」的版本更新看待，是最穩妥的讀法。
