HAAOHAAO
EN ★ GitHub 試用 Demo

總覽

HAAO(Hybrid AI-Agile Orchestrator)是 AI 軟體代理的治理層。你跟一個協調 agent 對話講出要做什麼;它把工作排進待辦提案;雲端 Tech Lead 把每項拆成可測試的原子工單;本地(或雲端)模型執行;兩道人工關卡讓你掌控範圍與交付;驗收後的成果以 Pull Request 出貨。整個過程都看得到——即時看板、活動串流、成本與吞吐洞察,以及通知收件匣。

核心論點:前沿模型應節制地用於高槓桿的推理(拆解、審查),而非用來逐行硬寫。本地開放權重的編程模型如今已足夠勝任大量的執行工作,既便宜又私密。HAAO 就是那個協調層,把對的工作交給對的模型,並在關鍵處插入人類判斷。

快速開始

最快的方式——Docker:

cp .env.example .env       # 視需要設定 CLAUDE_API_KEY / 模型金鑰
docker compose up --build

開啟 http://localhost:3001(API 在 :8000/health)。macOS/Windows 上後端透過 host.docker.internal 連到本地 LM Studio。在 Settings 加密保存雲端金鑰需要在 .env 設 HAAO_SECRET_KEY(用 openssl rand -base64 32 產生);設 HAAO_API_TOKEN 可要求 API 帶 bearer token。或本地開發執行:

python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
uvicorn orchestrator.main:app --reload
pytest
新手或非技術背景?從 repo 裡的 Operator's Guide 開始。想了解設計緣由?閱讀技術設計文章。

基準測試 — 真實 repo

早期試點跑在 curated sandbox——是誠實的訊號,但不是基準。R-102 是真實 repo 版:自然語言需求拆解、由本地模型(qwen3-coder-next)執行,並在兩個 pin 住版本的開源專案(pallets/click 8.1.8、jazzband/tablib 3.8.0)上評分。14 題 × 2 trials = 28 runs——小檔走 whole-file、大檔走 patch 模式(search/replace)。

指標結果
本地完成率(本地完成、無雲端升級)82%(23/28)
一次成功率(第一次零重試即過)46%(13/28)
分 edit mode(一次成功 / 本地完成)whole-file 44% / 88% · patch 50% / 75%
升級 / blocked18%(5/28)
baseline 先紅(probe 有效)28/28
既有測試保持綠28/28
timeout / infra 錯誤0 / 0
雲端成本 · 本地推理中位數$1.07 · 324s

每筆 run 都有把關,讓基準不會自我灌水:probe 期望值對照函式庫真實行為驗證(參考正解 red→green + 語意複查)、未修補的 baseline 必須先紅、repo 既有測試必須保持綠、每張工單在獨立 git worktree 評分、infra 錯誤排除在能力分母外。

未本地完成的部分分兩種:reasoning miss(模型改對位置但細微行為判斷錯)與編輯步驟的少量機械失敗(偶爾 whole-file 重生截斷,或 patch 的 search/replace 區塊格式壞)。patch 模式已把大檔納入範圍(例如 1,000 行的模組現在能一次編輯成功),那條機械尾巴是接下來要硬化的對象。

誠實 scope:n = 14 題(28 runs)、單一本地模型單機、兩個 repo——現已涵蓋小檔與大檔。這是可信的真實 repo 基準,不是最終 benchmark。

更新(2026-06-29):一次較小的 3-repo 抽查(click、tablib、marshmallow)用同一套 harness 重現了端到端的本地一次成功;在更新頭條數字前,正在進行更大、更多 trial 的測試。

角色

HAAO 將 Scrum 角色對應到一支混合的 AI 工作團隊。不直覺的選擇是:人類是 Product Owner,而不是 Scrum Master——流程機制自動化,產品判斷保留給人。

Scrum 角色由誰擔任職責
Product Owner你(人類)定義需求、排序、核可待辦、驗收成果。
Tech Lead雲端模型(Claude)拆解成原子工單、撰寫可機器驗證的 DoD、執行技術審查。
Scrum Master協調器(軟體)派發、路由、控管 WIP、重試、升級——全自動。
開發團隊本地 LLM(LM Studio)——或雲端,依角色選擇讀取脈絡、撰寫程式、在沙箱中執行測試、回報。

原子工單

原子工單是雲端 Tech Lead 與本地編程者之間的交接格式,由 JSON Schema 定義。三個特性讓它成立:

可機器讀取——本地模型無需猜測意圖即可解析。自我完備——相關程式碼直接內嵌進工單,而非以檔名引用,因此小的有效參數模型不必去尋找或記住任何東西。可驗證的 Definition of Done——DoD 是一組帶有預期結果的測試指令,所以「完成」是測試結果,不是主觀判斷。

混合成本路由

工作預設留在本地且免費。重試額度管控自我修正;只有當本地嘗試用盡時,工單才會升級到雲端。便宜的機器檢查擋在昂貴的雲端審查之前,因此你絕不會為了讀每一個 diff 付前沿模型的錢。真正重要的指標是「每張驗收工單的成本」。

架構

        你(Product Owner)
   寫需求 │           │ 核可 / 驗收
          ▼           ▲
   ┌────────────────────────────────┐
   │   協調器(Scrum Master)         │  狀態機 · 路由 · 重試
   └───┬───────────┬───────────┬────┘
       │ 拆解+審查  │ 派發      │ 跑測試
   ┌───▼────┐  ┌───▼────────┐  ┌▼───────────────┐
   │ Claude │  │ 本地 LLM    │  │ pytest/npm test│
   │(Tech   │  │(LM Studio) │  │(驗證)          │
   │ Lead)  │  │ 開發團隊    │  └────────────────┘
   └────────┘  └────────────┘

技術堆疊:Python · FastAPI · SQLite · React · Tailwind · LM Studio(本地推論)· Claude API(雲端)。

流程

從一段對話到一個 Pull Request:

  1. 對話——跟 agent 講你要什麼;它複述並把工作排進待辦提案。Tech Lead 把每項拆成原子工單;你核可(關卡 1)。
  2. 執行——協調器把每張工單派給其指派的模型(本地或雲端),由它在沙箱中撰寫程式並執行測試。
  3. 自我修正——失敗時,工作者在額度內重試;用盡則升級給 Tech Lead。
  4. 審查——Tech Lead 自動依 DoD 檢查 diff。
  5. 驗收並出貨——PO 驗收或退回(關卡 2);驗收後 HAAO 開 branch + PR 到 GitHub/GitLab。

全程可觀測:Activity 串流每個 run 事件(模型呼叫、diff、重試、升級、成本);Insights 追蹤吞吐量、週期時間、升級率、本地 vs 雲端比例與成本;Inbox 跨專案收集需要你處理的事。

部署

HAAO 採 split-plane（分離平面）設計:控制平面（看板、對話、洞察、協調）可被託管,而執行與你的金鑰留在你這側。也就是說,你的程式碼永遠不會在別人的基礎設施上執行,廠商也不持有你的原始 repo。

  • Free / 自架——整套自己跑,MIT 授權,使用自己的金鑰。程式碼與推論都留在你的機器。
  • Team(託管)——託管控制平面 + 一個輕量的客戶端 runner,用你的算力與金鑰執行。
  • Enterprise——完全自架 / air-gapped image,含 SSO、角色權限、政策防護(代理可動哪些、egress 控制)、自帶模型 / 雲端。執行留在本地;雲端 Tech Lead 只看得到工單範圍與供審查的 diff。與我們聯絡 來規劃部署。

全程安全:沙箱化(斷網)測試執行、AES-GCM 加密保存金鑰、防 prompt injection 的內容處理、日誌 secret 遮蔽,以及選配的 API token 驗證。