跳到主要內容

Vibe Coding 協作到自建 Dev Agent?從 Claude / Codex 到 OpenHands

過去一年,越來越多工程師開始把 AI 真正帶進工作流程。從一開始用 ChatGPT、Claude 來問語法問題,到後來很多人愛上 Cursor,直接在編輯器裡讓 AI 幫忙改 code、補 test case、甚至自動整理 PR。這樣的開發體驗,已經大大改變了我們寫程式的方式。

更現實的是,在很多企業內部、政府單位、或涉及機密資料的專案裡,其實根本不能直接用 Cursor 或雲端 LLM 工具。 

畢竟這些服務通常會把資料傳到雲端模型做處理,萬一專案裡有未公開的技術、敏感客戶資料,或是受限於法規(像金融、醫療、政府標案),直接用雲端 AI 工具就會踩紅線。 

因此,許多團隊反而更希望「自己架一套 Dev Agent」,可以在內網執行,資料完全掌握在自己手上,該整合的內部工具、該讀的私有 repo、該串的 CI/CD pipeline,全部客製化、安全可控。

這時候,像 OpenHands 這樣的開源 Dev Agent 框架就特別有價值。它的出發點不是單純的 AI 助手,而是讓你能夠打造出一個真的可以跑在自己環境裡、可以理解整個開發流程的 AI 工程師。從建置到部署,從 CLI 操作到瀏覽器查詢,從多檔案編輯到自動測試,全部都能自己完成,甚至還能針對不同專案調整專屬的工作流。

對很多開始探索 AI 協作開發的團隊來說,這是一條 從「AI 幫你寫一段程式」,走向「AI 幫你解決一整個任務」的進化路徑。而且,還是在可控、可自定義、安全的環境裡完成的。

🧩 主要概述

OpenHands 是由 All‑Hands AI 開發的開源「軟體開發代理人平台」,能模仿人類工程師從建立程式、修改程式碼、執行指令,到瀏覽網頁、呼叫 API……等一整套開發流程

它提供雲端(OpenHands Cloud)與本地 Docker 運行版本,用戶能配置 LLM(如 Claude、OpenAI、Gemini…)

📚 核心特性與怎麼使用

代理人的工具能力

支援代碼編輯、命令行、執行環境、網頁瀏覽、API 呼叫—接近人類開發者完整技能。其中 OpenHands Cloud 版本提供 $50 試用額度讓大家方便使用,又或者如果自己本機有 docker 的話,可以自己Local 版本透過 Docker 自架環境。

使用流程

快速上手:啟動 Cloud 或 Docker 映像後,選擇 LLM、輸入 API Key Hello World 教學:打個 Hello Script、調整語法、執行跑測試由簡入繁掌握 agent 運作 。 

https://docs.all-hands.dev/usage/installation

Web 應用建立:從無到有建構完整功能(例如 React 前端 TODO 應用),官方有一系列說明,讓使用者可以快速入門,讓 AI Agent 快速打造出來應用。

整合於現有專案:可新增 route、Action、Component、重構 function 等 ,當然同時也具備了除錯與 TDD 測試驅動:支援生成測試 Testing、診斷 bug 問題、透過迭代過程改進 。 

https://docs.all-hands.dev/usage/getting-started

高度可視化 UI

這部分是我自己覺得最特別的地方,提供的 web ui 介面,包含 chat 對話視窗、檔案異動視圖、終端、VS Code、Jupyter Notebook、Web app 及瀏覽記錄等模組 。

支援多種大型語言模型

可以支援自己建立的大型語言模型端點,同時也支援常見 LLM 模型(推薦使用 Claude-sonnet-4 及 o4-mini、Gemini、OpenHands LM) 

https://docs.all-hands.dev/usage/llms/llms

質化 prompt 精準、範疇限定、提供具體檔案與行號等建議使用法

https://docs.all-hands.dev/usage/prompting/prompting-best-practices

📈 成果與效能

Benchmark:在 SWE‑Bench 等程式開發基準測試中,OpenHands 解決率達 50% 以上 。同時新一代 Versa Agent:最新研究(2025/06/03)指出其多模式瀏覽與檔案操作能力,在三項 benchmark 中平均比同級專用型 agent 高出 9% 成功率 。

在討論技術社群的討論中其實也持續獲得肯定,Reddit 分享 CodeAct 2.1 版本突破 SWE‑Bench 50% 門檻,具里程碑意義 。

實際案例

教學案例:網路上實際有示範用 Docker 啟動、結合 LLM 建立 FastAPI + Jinja 應用,agent 支援編寫、測試與推 Git的流程可提供查看 。

德國大型團隊實測:Senior Developer 實測 Docker + OpenHands + Ollama/OpenAI,協助升級微服務依賴與生成沙盒,但是測試修復與 PR 評論處理上仍有侷限,需人為介入 prompt 調整與回饋。

這段官方影片大家也可以快速了解一下應用的方式,

後記

目前大部分的 coding agent 多屬於封閉的模式,除了深入查看程式碼之外,很難知道在伺服器端或者參數端做了什麼調整,也很難用於較為私密的環境中。

OpenHands 是一個完全開源且正在快速進展的開源 AI 開發代理平台,具高度的工具整合能力與 benchmark 實力,尤其適合需要 自動化程式碼生成、CI/CD 任務與小規模專案初期開發 的使用者。目前仍建議配合人類協作使用,並透過精準 prompt 與逐步迭代強化效果。

🔥 工商服務時間 🔥

本月份將有一場 Vibe Coding 台中實體活動,

歡迎對 AI 工具、Coding Flow 有興趣的朋友們一起來 vibe 一下 🎧💻!

📅 活動資訊 👉 https://codingbear.kktix.cc/events/ai-vibe-coding-2025-06-taichung

這次我們會分享最新 AI 開發模式、實戰 Demo、現場互動 Q&A —— 一起交流、一起玩,現場 vibe 爆棚 🕺!

有興趣的夥伴趕快手刀報名 💥,名額有限!


Vibe Coding 是近來開發圈很火紅的 AI 協作開發模式,結合我們自家 Cympack AI 製造平台,幫助了不少客戶「從想法 → 打樣 → 量產 → 上市」整個新產品流程 🚀。

如果你也有: 

✅ 想開發新產品 

✅ 想做新產品開發、小量客製、快速打樣 

✅ 想了解 AI 協作 + 製造流程怎麼整合

都歡迎來聊聊,我們團隊很樂意協助! 

可以聯絡我,或者來信 

📩 聯絡信箱 👉 service@cympotekc.om 

https://www.cympotek.com/

✨ 讓 AI 幫你加速產品落地。

留言

這個網誌中的熱門文章

Vibe Coding:為什麼 Junior 更快上手?Senior 要如何追趕?

現象層面(市場觀察) 最近有篇文章討論 junior & senior 開發者在 AI 時代的角色轉變,非常熱門。 身為 Cympack 產品開發團隊 ,我們也一直關注這個議題,在閱讀這篇文章時觀察到一些有趣的現象,對我們來說,這正好反映出 AI 正在改變開發生態,junior 借力 AI 快速成長、senior 則需要在 「架構思維」 與 「多 agent 協作」 中找到新定位,其中有些啟發(insight) 可以跟大家分享。 為什麼 Junior 更容易上手 vibe coding? 心智負擔低 → Junior 沒有太多傳統 code workflow 的框架包袱 敢於嘗鮮 → Gen Z / 年輕工程師天生習慣用 prompt-based 工具、跟 LLM 互動 少「優雅程式設計」的束縛 → 不太糾結「這樣寫會不會不夠優雅」,反而 embrace 快速迭代、快速出成果 反觀 Senior: 熟悉大型系統設計 有豐富的「工程正統流程」知識(架構設計、測試策略、效能優化、設計模式) 對 AI 生成 code 的品質 / 維護性通常比較保留 部分 10+ 年資深工程師,對 prompt engineering 沒那麼熟練,還在觀望 技能面(未來的關鍵能力) Vibe coding 本質上 = prompt engineering + AI co-pilot 管理能力 能力項目 誰目前比較有優勢? Prompt 撰寫 / AI 互動 Junior 較強(熟悉 chat-based 流程) 系統設計 / 架構把關 Senior 較強 AI 生成 code 驗證 / Bug 察覺能力 Senior 較強(能看出潛在問題) 快速疊代 / Hackathon 式開發 Junior 較強 長期維護性 / 穩定性 Senior 較強 總結 Junior 確實更快適應 vibe coding,並且更習慣以 「chat-based coding」 的工作流開發。 Senior 擁有驗證 AI 產物與系統設計的深度能力,但若不主動練習 vibe coding,長期會逐漸落後於新一波開發潮流。 就如同在 GAI 技術年會分享,希望帶給各位的感受, 『與 AI 協...

RAG 和 Prompt 原理超簡單解說!想知道 AI 怎麼找答案看這篇

這篇文章是給對於你已經開始使用所謂的 ChatGPT / Claude / Gemini 之類的 AI 服務,甚至是 Siri (嘿丟,他也是一種 AI 應用服務喔) 簡單來說是非 技術人員, PM,小白,想要趕快惡補的人 ,直接花十分鐘可以看完的一篇科普業配文章。 或者是概念僅止於,AI 這東西會幻想,會有誤差,會對於生活有些幫助但沒有幫助的人們,做個簡單又不是太簡單的介紹,希望用一個非常入門的方式讓你們有個了解。 當然,這篇文章目的很簡單, 就是引流 ,如果你身邊有已經對於 Web 技術開發的人員,歡迎報名分享給他,年末出國不如學一技在身,參加今年我們舉辦最後一場 RAG 實作工作坊,報名連結 , https://exma.kktix.cc/events/ai-for-dev-course-rag-2 注意: 接下來每個大段落結束都會有一段工商導入,但文章絕對精彩,請注意! 為了讓各位容易想像,我們將整個世界的資訊,先濃縮到這本『西遊記』的世界觀當中,我們整個世界都在這個 『西遊記』 ,而 大型語言模型 我們用 『書精靈』 來描述。 PS. 我們先預設各位,應該都有聽過,西遊記!如果沒有聽過西遊記的,請右轉出去,謝謝! 先來談談向量 在《西遊記》的世界裡,我們可以把 向量想像成一種「內容座標」 ,讓系統知道每個角色、場景、法術等的 「位置」和「距離」 。向量幫助語言模型知道不同內容之間的關聯程度。 向量就像內容的「距離」和「位置」 比方說,唐三藏的 「位置」(向量)會接近「佛經」和「取經」 的概念,因為他一路上都是為了取經而前進。孫悟空的 向量位置則會更靠近「金箍棒」和「七十二變」 這些概念,因為這些是他的特徵。 相似內容靠得更近:像「佛經」和「取經」會靠近唐三藏的向量,因為它們彼此有很強的關聯。 相差較大內容會離得較遠:像「取經」和「妖怪」「妖怪的寶藏」就距離比較遠,因為妖怪的寶藏和取經的目標關聯性不大。 是誰決定的這些位置? 簡單來說,這些位置和關係是模型自己學出來的。語言模型會閱讀大量的資料和這世界觀的資訊,觀察哪些詞語經常一起出現,根據「共同出現的頻率」來決定它們的關係,並且自動生成向量。例如: 如果模型看到 「唐三藏」 總是和 「取經」 一起出現,它就會讓「唐三藏」的向量靠近「取經」。 ...