你嘅 AI Agent 團隊需要一個 Brain：claudectl + Pilot 生產化實戰

2025 年尾仲有人話 AI coding agent 只係 fancy autocomplete，半年後嘅今日，邊個仲敢咁講？GitHub Copilot 嘅 agent mode、Claude Code、Codex CLI 相繼推出，成個生態由「幫你寫一行 function」進化到「幫你 ship 一個 PR」。但現實係：單一 agent 做到嘅嘢好有限。你畀一個 agent 一個 ticket，佢會寫 code，會改 file，但一講到跨 module 重構、多 repo 協調、或者要理解成個 codebase 嘅 architecture，單一個 agent 嘅 context window 同 reasoning 好快就到極限。呢個唔係模型問題，係 orchestration 問題。你需要嘅唔係一個更勁嘅 agent，而係一個可以指揮一班 agent 嘅 brain。

由單兵作戰到 Swarm Orchestration

我哋先睇清楚個問題：點解一個 agent 搞唔掂大型任務？原因好直接 — LLM 嘅 context window 有限，而大型 codebase 嘅 dependency graph 係遠遠超過任何模型可以一次過消化嘅量。你叫一個 agent 「refactor 個 authentication module」，佢可能要睇十幾個 file，理解 middleware chain、DB schema、JWT 實作、仲有前端嘅 token refresh logic。即使 Sonnet 3.5 嘅 200K context 都未必夠用，更唔好講咁多資訊塞埋一齊嘅 confusion。

呢個時候需要嘅係 swarm orchestration：將大型任務拆做細 task，每個 task 由獨立 agent 執行，然後有個 central coordinator 去 merge 結果、處理衝突、確保 quality。claudectl 同 Pilot 就係行呢條路。claudectl 用 Rust 寫，sub-50ms startup，~1MB binary，專注做 Claude Code 嘅 swarm orchestrator。佢嘅 Local-LLM Brain 可以自動 approve 或 deny tool call，唔使下下 call cloud API，對於香港 startup 嚟講，呢個 cost saving 好實際。而 Pilot 就更加進取 — 由 ticket 到 PR 全自動，支援 GitHub、Linear、Jira、GitLab，仲有 Telegram bot 可以 voice command 開 ticket。

Ticket-to-PR：由概念到 Ship 嘅完整 Pipeline

講到 production 化，最關鍵嘅唔係 agent 寫 code 嘅能力，而係成個 pipeline 嘅 reliability。Pilot 嘅做法值得參考：佢唔係就咁叫 agent 寫完 code 就開 PR，而係有完整嘅 quality gate chain — plan → implement → self-review → test → quality gate → PR。每個 stage 有獨立嘅 agent 去做，唔係同一個 agent 又寫 code 又 review（咁樣 self-review 基本上冇意思）。

我特別鍾意 Pilot 嘅 epic decomposition 功能。一個大型 ticket 入到嚟，Pilot 會先拆做 sub-task，然後逐個 dispatch 俾獨立 agent session。呢個做法唔單止解決咗 context window 問題，仲可以 parallel execute — 如果個 epic 有 5 個 independent module，你可以同時跑 5 個 agent，將成個 turnaround time 由幾粒鐘壓到 30 分鐘。對於香港嘅 startup team，呢個 speed 係決定性嘅。你唔需要請 5 個 backend engineer 去做 parallel development，你只要有個 brain 同 5 個 agent。

claudectl 喺呢方面嘅 approach 唔同，但更適合已經用緊 Claude Code 嘅團隊。佢作為 Claude Code plugin inline 整合，你可以喺 concept 緊一個 session 嘅時候，叫佢 spawn 另外一個 agent 去做 background task。佢嘅 coordination layer 有 ownership lease、handoff、interrupt、memory — 呢啲先係真正 production 需要嘅 infrastructure。唔係「我叫你寫個 function」，而係「你負責呢個 module，做完話俾我知，中間如果發現 dependency 有問題就 escalate」。

知識管理同 Memory：Agent 團隊嘅 Collective Brain

單一 agent 最大嘅 weakness 係 stateless。每次新 session 都係一張白紙，之前學到嘅嘢、發現嘅 pattern、做過嘅 decision，全部唔記得住。呢個問題喺 swarm orchestration 入面更加嚴重 — 你唔只係要記住一個 agent 做過乜，而係要成個團隊共享知識。

claudectl 嘅 hive mind 功能就係為咗呢個問題而設。佢做到跨機器知識蒸餾 — agent A 喺一部 machine 學到嘅嘢，可以 distilled 之後同步俾 agent B。仲有 curriculum generation：根據 agent 嘅 performance，自動生成 learning tasks 去填補 knowledge gap。呢個 concept 好 powerful — 你嘅 AI agent team 會隨住時間越做越好，因為佢哋有个 shared brain 不斷累積經驗。

另一方面，cass（coding-agent-search）解決嘅係 session history 嘅 search 問題。佢統一 index 11+ 個 provider 嘅 session history，BM25 + semantic search sub-60ms。對於團隊嚟講，呢個 tool 嘅價值在於 debug：「上個禮拜 Codex 做個個 authentication fix 到底改咗啲乜？」可以 instant search 到。Donmai 更加進一步，用 tree-sitter AST 做 code intelligence，仲有 BM25 search 同 quality ratchet — 每一次 deployment 嘅 quality baseline 只升不跌。

Production 化嘅 Realities 同建議

講咗咁多好嘢，都要講下現實。Agent orchestration 唔係 set 好就唔使理。以下係我喺 production 行咗幾個月之後嘅 concrete advice：

第一，budget control 係必須嘅。 AI agent 可以好快 burn 錢 — 一個 agent 行一個複雜 task，連續 call API 20-30 次，如果唔限住，一個下午可以燒你幾百蚊美金。claudectl 有 spend control + budget kill，Pilot 有 cost controls。開 production 之前一定要 set 好 hard limit。

第二，quality gate 唔可以 skip。 越係自動化，越需要有明確嘅 quality threshold。Pilot 嘅 quality gate chain 係好嘅起點，但你仲需要補 human-in-the-loop review 俾 sensitive code（auth、payment、data privacy）。

第三，start small，先揀一個 module 試水。 唔好一嚟就成個 codebase 交俾 agent orchestration。揀一個 isolation 比較好嘅 microservice 或者一個獨立 module 行先，run 一個 sprint 睇下效果，然後先 scale。

第四，memory 同 documentation 係長期回報最高嘅 investment。 越早開始累積 agent knowledge base，你嘅 swarm 越 smart。claudectl 嘅 curriculum generation 同 Donmai 嘅 quality ratchet 都係越用越好用嘅工具。

如果你嘅團隊仲未開始試 AI agent orchestration，而家係最好嘅時機。Tooling 已經成熟到一個地步 — 唔係「呢個技術得唔得」嘅問題，而係「你點樣 design 你嘅 pipeline」嘅問題。揀一個 tool 開始，由一個 ticket 行到一個 PR，你就會明點解 single agent 永遠唔夠，而你嘅 AI team 真係需要一個 brain。