AWKit Workflow Engine Architecture

概念概覽

AWKit 核心架構特徵

核心知識

AWKit 核心架構特徵

• Principal-Worker 隔離：與 edict 最大的共同點，但 AWKit 的決策引擎是確定性的（deterministic Decide()），而非 LLM 自由發揮
• GitHub Label 狀態機：以 Label 驅動工作流狀態流轉，是 AWKit 的差異化核心
• workflow.yaml config 結構：已包含 worker.backend 和 worker.claude_code.model 欄位，表示模型切換能力已有 80% 基礎

Hot-Switch Model 發現（P0）

原先評估為複雜功能（3-5 天，P4），但因 workflow.yaml 已有相關設定，只需加 awkit config get/set CLI 介面即可，實際工期半天，ROI 最高。

# workflow.yaml 已有的欄位
worker:
  backend: claude_code
  claude_code:
    model: claude-sonnet-4-6

Terminal 佔用問題

workflow 啟動後佔據 terminal，若需執行 awkit config set 需開另一個 terminal/tmux pane，進階解法是 IPC/socket daemon 模式。

分支命名注意

實際分支名為 develop（非 dev），所有 git 操作前需確認。

經驗教訓

• 評估功能工期前應先仔細閱讀現有 config 結構，避免高估複雜度

• terminal 佔用衝突暗示需要 daemon/background 模式，否則 config hot-switch 價值大打折扣

• 功能整合應優先利用現有設定（如 workflow.yaml 已有的欄位），而非從零設計

常見陷阱

• git 操作時分支名用 develop 而非 dev，搞錯會浪費時間

• terminal 佔用問題若不解決，config hot-switch 的實用性大幅降低

最佳實踐

• 新 CLI 指令（awkit config）應整合進現有 doctor 指令，避免功能分散

• lifecycle hooks（on_merge、on_failure）是整合外部通訊層的最低成本切入點

相關概念

• claude-code-channels----dangling-------dangling---
• Claude Code Channels vs Orchestration Layer
• edict Principal-Worker Competitive Analysis
• jenkins-pipeline----dangling-------dangling---

來源 Sessions

日期	Session	貢獻摘要

| 2026-04-08 | a2b9a25e-b4d9-4809-af93-ce7e80298054 | 確立 AWKit 的核心差異化定位：Principal-Worker 隔離、確定性 Decide() 引擎、GitHub Label 狀態機 |

---

本概念頁面由 Semi-Brain Wiki 系統自動維護

最後更新: 2026-04-08