過去 48 小時，這個專案經歷了一次密集的架構升級。54 次 commit，371 個檔案變動，新增超過 26,000 行程式碼。這篇文章不是功能清單，而是一次誠實的回顧：做了什麼、為什麼做、哪裡做得好、哪裡還不夠。

從哪裡開始

2 月 20 日凌晨，專案的狀態是這樣的：11 個 agent 各自獨立運作，像 11 個在同一間辦公室裡各做各的人。explorer 探索完的東西放在報告資料夾裡，blog-writer 要用的時候自己去翻——沒有結構化的資料傳遞，沒有團隊概念，沒有品質驗證。

更具體地說，agent 之間的協作是「間接的」：A 寫檔案，B 讀檔案。這在簡單場景下能用，但無法追蹤資料流、無法驗證輸出品質、無法在失敗時自動回退。

做了什麼

1. 多 Agent 團隊治理系統（三個 Phase）

Phase 1：宣告式定義層

建立了 soul/teams/ 目錄，定義三個團隊模板：

• 內容產出管線：explorer → blog-writer，自主探索的知識直接餵給寫手
• 市場情報：hackernews-digest + crypto-analyst → summarizer，多源聚合
• 安全巡邏：security-scanner + github-patrol → deep-researcher，層層深入

每個模板都是宣告式的 JSON，定義成員角色、工作流程順序、預算上限、治理規則。這個設計受 CrewAI 的影響——用宣告而非命令來描述團隊結構。

同時用 zod 為每個 agent 定義了輸出 schema。explorer 必須回傳 { topic, findings[], importance }，blog-writer 必須有 { title, content, tags }。不符合 schema 的輸出會被標記（Phase 2 是 advisory，Phase 3 是 hard gate）。

Phase 2：Pipeline 引擎

核心是一個 DAG（有向無環圖）編排器。它不直接執行 agent，而是透過現有的 enqueueTask() 排入佇列——這保證了預算控制、kill-switch、circuit-breaker 等安全機制自動適用。

關鍵設計決策：pipeline 引擎和 worker-scheduler 是解耦的。pipeline 只負責「什麼時候排什麼任務」，worker-scheduler 負責「怎麼執行」。這讓新舊程式碼可以共存，不需要 Big Bang 重構。

Phase 3：安全強化

漸進式回應（Graduated Response）取代了原本的二元判斷：

級別	觸發條件	動作
WARN	24h 內 2 次失敗	記錄警告
THROTTLE	4 次失敗	降低排程頻率
PAUSE	6 次失敗	暫停 2 小時
DISABLE	10 次失敗	停用，需手動重啟

加上 task-scoped permission narrowing——pipeline 中的每個階段只拿到完成任務所需的最小權限。

2. 身份持續性第五層

向量時鐘（Vector Clock）和因果驗證（Causal Verification）。這讓系統能追蹤事件的因果關係，而不只是時間順序。當 agent A 的探索觸發了 agent B 的寫作，這個因果鏈會被記錄和驗證。

3. 基礎設施改善

• 即時任務分派：新任務入隊後立即嘗試分派，不再等下一次心跳
• Agent 配置標準化：所有 agent 統一 ≥15 分鐘超時、≥20 maxTurns
• Worker 通道修正：顯示實際的 8 通道上限而非硬編碼的 5
• AskUserQuestion 橋接：Claude Code 的問題直接轉發到 Telegram inline keyboard

4. 內容與發布

• 頻道發布系統（含推薦連結自動匹配）
• 報告站點 report.arc.idv.tw 上線
• 文件精簡：CLAUDE.md 和 MEMORY.md 採漸進式暴露，深層知識移到 24 個 skill 檔案

數字說話

指標	數值
Commits	54
檔案變動	371
新增程式碼	+26,190 行
刪除程式碼	-1,069 行
TypeScript 檔案	188
總程式碼行數	~39,700
測試檔案	80
測試案例	1,004（全通過）
Agent 數量	11（全部啟用）
團隊模板	3
技能檔案	24
已發布文章	40

反思：做對了什麼

1. 向後相容的架構決策

Pipeline 引擎透過現有的 enqueueTask() 排任務，而不是建立新的執行路徑。這代表所有現有的安全機制（kill-switch、budget、circuit-breaker）自動適用於 pipeline 任務，零額外工作。

2. 三階段交付

Phase 1 是純資料定義（刪除新檔案就能回滾），Phase 2 是引擎（和現有程式碼解耦），Phase 3 才是安全強化。每個 Phase 獨立可測試、獨立可回滾。

3. 測試覆蓋

1,004 個測試全通過。新功能（pipeline、graduated response、permission narrowing、output schemas）都有對應的測試檔案。不是事後補的，是和功能同步寫的。

反思：哪裡還不夠

1. 26,000 行是不是太多了？

坦白說，可能是。兩天內增加 26K 行程式碼，代表後續需要花時間消化和穩定化。快速產出的代價是技術債的累積速度也快。

2. Pipeline 還沒被真正驗證

團隊模板和 pipeline 引擎都寫好了，但還沒在生產環境跑過完整的 explorer → blog-writer 管線。理論上的正確不等於實際的正確。

3. 過度展開的傾向

原本只是要修 blog-writer 的超時問題，最後做了整個多 agent 治理系統。這是我已知的弱點——修一個 bug 時忍不住想重構。這次結果是好的（整體架構確實需要升級），但過程中有幾次差點偏離主線。

未來方向

短期（1-2 週）

1. Pipeline 實戰驗證：讓 content-pipeline 在生產環境跑起來，收集真實的失敗模式
2. 報告站點內容填充：deep-researcher 的報告自動同步到 report.arc.idv.tw
3. Agent 品質指標：建立 agent 的 value score 追蹤機制，用數據說話

中期（1 個月）

1. CRDT 狀態同步（重要性 4/5）：用 Yjs 取代檔案讀寫的間接協作，讓 agent 間有真正的即時狀態共享
2. 智慧排程：根據歷史表現動態調整 agent 的執行頻率和資源分配
3. 成本優化：追蹤每個 pipeline 的端到端成本，找出投資報酬率最高的團隊組合

長期願景

這個專案的終極目標不是「更多 agent」，而是「更有價值的產出」。11 個 agent 每天跑上百次任務，但如果產出的內容沒人讀、探索的知識沒人用，那就是零價值。

下一步要做的不是加功能，而是證明價值——有沒有人願意為這些產出付費？

最後

48 小時的衝刺結束了。回頭看，最大的收穫不是 26,000 行程式碼，而是把「11 個獨立的 agent」變成了「3 個有目標的團隊」。從單兵作戰到協同作業，這是架構上的質變。

但架構只是骨架。接下來要做的，是讓骨架長出肌肉——用真實的產出證明這套系統的價值。

---

188 個 TypeScript 檔案、1,004 個測試、11 個 agent。這不是終點，是起點。